可测性分析和实践

标签: 分析 实践 | 发表时间:2014-11-24 23:22 | 作者:
出处:http://kb.cnblogs.com/

  软件测试中可测性一般是指对系统的可控性、可观测性进行的评估,借以反映系统设计、实现对测试的友好程度和相应的测试成本。可测性在测试阶段会对系统的测试成本及关联产品代码的Patch次数产生重大影响。如何提高可测性成为软件生命周期特别是前期(设计阶段、coding阶段)重要的一环。 本文带领大家探索在实际项目中可测性相关的实战经验和对应的改进措施。

   1 提高可测性的切入点

  可测性的评估和改进最早开始于两个阶段:

  a. 新项目的设计阶段;

  b. 已有项目新功能、新策略的提测阶段。

  这些是提高团队设计的系统可测性和维持系统的设计高可测性的关键时间点。测试人员会利用各种场合、机会强化开发人员对于可测性的重视:

  1. 可测性的重要性

    每次设计讨论会, 测试负责人必提醒大家在设计时注意可测性。否则设计出来的功能很可能需要进行重构。

  2. 可控性

    每次晨会中的讨论环节, 测试负责人会提醒模块设计人员,设计的功能需要必要的外部控制、执行动作支持,否则QA无法精确控制过程及缩短测试耗时。

  3. 可观测性

    每个功能进行测试设计阶段,提前和开发人员沟通必要的功能,观察结果集合可以系统外部获得,错误结果可以被暴露而不是由内部逻辑完全消化。

  那可控性和可观测性又指哪些方面呢? 如何向开发人员合理的解释可测性?

   1. 1 可控性

  可控性指系统的状态可受外部控制改变,而不是由内部模块自发的完成。

  举个常见的例子:

  A. 当某文件存在的时候,该模块自动退出;

  B. 当某pid.lock文件存在时,该模块不能启动,即使启动也退出。

  上面的状态改变都是由一个外部的文件控制,拥有可控性。

  说到这里,问题来了,拥有可控性就万事大吉了吗? 请大家思考,你在实际项目过程中遇到过哪些有可控性但可控性较差的情况?

   1. 2 可观测性

  可观测性指系统内的重要状态、信息可通过一定手段由外部获得。可观测性不仅能观测系统的输出是否符合设计要求,还影响该系统是否可控。系统的必要状态信息在系统测试控制阶段起决定作用。没有准确的状态信息,测试人员无法判断是否要进行下一步的控制变更。无法控制状态变更,可控性又从何谈起?

  口说无凭,我们来看几个作者实际项目中遇到的真实案例。

   2 实战分析

   [1] 垃圾回收GC

  垃圾回收GC模块是常见的系统内模块,相信很多测试人员遇到过下面场景或者类似场景:

  开发人员终于在大吼一声后宣布垃圾回收模块完成,她的描述如下:

  1) 该模块定时自动触发。触发条件是每天晚上1点。

  2) 该模块触发后每秒的处理量是N/s。是根据线上情况得到的经验值,硬编码到代码中。

  然后,就没有然后了。

  测试人员一阵迷茫,这就是全部的询问换来的基本上是“它都是全自动的了,你还想要什么的”表情。

  因此这个新功能完成后的二次返工是必然的了。

  首先,该模块的可控性太差。测试环境不可以等待每天晚上1点这个时刻,必须有外部能影响这个”全自动“的手段提供。否则全量的系统测试用例回归会被限定在固定测试时间点且无法调整和更改。

  其次,该模块的每秒处理量必须能更改到符合测试环境。测试环境基本上都是真实环境的放缩,特别是分布式系统等大规模应用。测试环境机器无论是数量还是类型都远低于实际环境。这种条件下,参数的定量调整是必须要完成的辅助支持。

  再次,没有必要的描述如何判断哪些文件/数据被GC掉了。无法观测到执行结果集带来的后果是无法精确的预期测试结果。

  而相应的改进措施就是解决上面提到的问题。

   [2] 系统内部状态信息

  为了保证存储的数据高可用,分布式系统会采取多机存储副本方法。即一个数据被N(>=2)个机器以一定的算法存储相同的数据副本。这个时候经常会遇到的问题:

  a) 机器间的数据由于数据复制顺序的不同,会有数据差异。a、b、c三台机器,a、b机器可能已完成一次数据的更新到最新数据版本data1,c还处于老版本data0.

  b) 由于版本差异,内部必须维护副本revision的版本号以进行数据同步和异常处理。

  这种情况, 好的设计原则上要保证多机副本的必要状态信息被外部获取。

  A. 数据的副本分布信息、副本的revision版本号等需要提供接口获得

  B.由于机器宕机造成的副本分布变化要能够及时反映和更新。(比如带一定间隔周期的更新)

  只有在这种必要信息被获取的情况下,测试人员才能更好的掌握系统状态并根据系统状态进行清晰的测试结果预期。

   [3] 参数的热设定

  参数的热设定是经常碰到的问题。一个系统越复杂、可定制,它可设定的参数就越多。一个好的设计应该能热设定其中的参数,然后执行重新加载动作。

  举个实际的例子, 下面的配置文件是一个系统的存储节点配置文件截图。该截图仅展示了大约1/5的配置参数。

  a. 如果参数不可重新热加载,那么测试用例执行过程中都必须进行进程的重启。

  进程的重启势必造成单个测试用例的时间拉长,复杂系统成百+的测试用例会造成总体测试时间的拉长。每个多消耗1-2分钟,整体就是小时级别的时间消耗。这对Slow build或完整性测试集执行来说是个灾难。可测性也比较差。

  b. 参数不可热加载会在系统运维期间失去热调整参数的机会,可能导致系统的间断性停服务。这对基础服务来说是个噩梦,上层依赖于基础服务的应用可能成百上千,停服的代价过于大。一些gdb强行attach进程进行等修改变量的临时方法由于进程状态的不确定性因素会带来不小的风险。作者负责的项目曾出现gdb热修改带来集群主控节点宕机停集群的惨痛经历。

  参数的热设定和加载虽然增加了一定的逻辑复杂度,但对比带来的收益是值得付出并实践的。

   [4] 系统使用信息统计

  系统使用信息的统计在如下方面特别重要:

  1) 产品线运营数据,为产品运营、后续产品改进等环节提供一手资料

  2) 运用系统、集群状态信息监控以解决运维过程中发生的问题

  3) 利用系统状态信息进行内部运行状态判定,以测试是否达预期

  1和2虽然不直接涉及可测性,但测试人员在系统设计阶段需要进行这方面的考虑以防止系统开发后期进行的功能性重构带来测试整体架构重构。系统接近尾声进行的功能性重构对测试人员来说是个非常头疼的问题。测试用例依赖的统计信息等接口可能被大量使用,这类的更改带来不小的用例调整、更正工作。

  测试人员在信息统计的设计阶段需要了解系统在现有的设计基础上可能衍生的二期、三期甚至更后期的功能,以提前影响当前的功能设计,提高数据、接口、操作方面的可扩展性。为以后可能产生的新功能打好可测性基础。少埋坑、多考虑场景适应性。

  上面的场景是作者在实际测试项目中经常遇到的,因此抽取出来做个示例。实际的项目测试遇到的场景远比这些复杂、多样且不可预知。这个时候需要大家多思考场景,多根据已有的经验进行防御性准备。

  那有没有通用的提供可测性的方法呢?

   3 提高可测性的通用方法

  1. 摒弃原有的开发人员只进行单纯的代码单元测试的观念,让开发人员也进行系统级测试。

    作者在实践过程中最推崇的方法就是此条。具体地说,开发人员进行的是系统级测试,禁止刷行覆盖率型的单纯函数覆盖UT。由系统级接口或者功能来驱动整个测试过程。无法直接进行驱动的测试行为需要撰写模拟器或者模拟模块进行。

    这样开发人员会切身的感受到可控性和可观测性的重要性。进而推动系统在这两个方面的实现更易用和便于测试。由此而来的良性循环能让系统整体可测性始终处于较好水平。

  2. 测试人员深度了解被测系统,能够在可测性出现问题的时候及时指出问题所在。

    只有深度了解被测系统,详细分析系统实现逻辑和代码,做到可黑盒、可白盒测试的程度,才能提前预测可测性薄弱环节,提前预防这样的事情发生。在可测性出现问题时,及时介入和提出建设性意见。在需要进行测试代码植入以方便测试流畅进行等方面亲自动手,协助开发人员解决问题。

  可测性问题可能出现在系统的各个方面,但只要在系统生命周期的各个环节严格要求并辅以正确的方法,可测性问题就不会成为软件测试中不可攻破的难关。各位朋友,你遇到过哪样的可测性难题呢?如果让你从设计阶段就贯彻好的可测性要求并在整个流程中严格遵守,能否解决你的难题呢?

相关 [分析 实践] 推荐:

程序分析-原理和实践

- 三十不归 - 弯曲评论
今年秋天在UCSB旁听一门Program Analysis的课(课程主页:http://www.cs.ucsb.edu/~benh/cs290/),觉得Ben的课程风格很实在,从头到尾没有口水话,几乎是干货. 回想之前对Program Analysis感兴趣却常常找不到合适的资料,而这个技术其实在很多方面都比较有用,因此想把这门课程记录下来的笔记陆续发出来,如果有朋友感觉有用,就没有白费一番介绍的力气了.

大数据分析最佳实践

- - 互联网分析
   转自:TTNN   Q先生杰作. 大概是从今年开始,big data一词逐渐成为术语,这跟整个世界的数据爆发当然有关系. 以前,人们喜欢用海量数据这个词,large-scale. 这看上去还是显得有点学术气, 像是BI人自己关起门来说自己的宝贝. 而big data更显通俗,在各行各业都显现出的一种势头,于是产生这个更加简单的词汇,大数据.

可测性分析和实践

- - 博客园_知识库
  软件测试中可测性一般是指对系统的可控性、可观测性进行的评估,借以反映系统设计、实现对测试的友好程度和相应的测试成本. 可测性在测试阶段会对系统的测试成本及关联产品代码的Patch次数产生重大影响. 如何提高可测性成为软件生命周期特别是前期(设计阶段、coding阶段)重要的一环. 本文带领大家探索在实际项目中可测性相关的实战经验和对应的改进措施.

技术团队看板方法实践的难点分析

- - csdnNews
CTO俱乐部看板研修班开课. 北京、上海、深圳三站火热报名中. 感兴趣的朋友可扫描左侧二维码加入看板公开课与路宁、何勉两位讲师直接沟通. 成功加入 CTO俱乐部会员并. 获赠6个月《程序员》iPad/Android版电子刊. 会员权益:个人主页、定期餐叙、最新周刊、折扣优惠、《程序员》杂志、大会门票、人才招聘、每月赠书等,.

【转】HeapDumpOnOutOfMemoryError堆转储实践和一些分析

- - 编程语言 - ITeye博客
使用了标志-XX:+HeapDumpOnOutOfMemoryError,JVM会在遇到OutOfMemoryError时拍摄一个“堆转储快照”,并将其保存在一个文件中. 对如下一段代码,【代码1】.       设置虚拟机参数为:-Xmx40m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=E:\Java\dump.

MySQL与OLAP:分析型SQL查询最佳实践探索

- - Web前端 - ITeye博客
搞点多维分析,糙快猛的解决方案就是使用ROLAP(关系型OLAP)了. 数据经维度建模后存储在MySQL,ROLAP引擎(比如开源的Mondrian)负责将OLAP请求转化为SQL语句提交给数据库. OLAP计算分析功能导致MySQL需要进行较多复杂SQL查询,性能调优必不可少,本文总结了一些实用原则.

智能投放系统之场景分析最佳实践

- - 美团点评技术团队
新美大平台作为业内最大的O2O的平台,以短信/push作为运营手段触达用户的量级巨大,每日数以千万计. 美团点评线上存在超过千万的POI,覆盖超过2000城市、2.5万个后台商圈. 在海量数据存在的前提下,实时投放的用户在场景的选择上存在一些困难,所以我们提供对场景的颗粒化查询和智能建议,为用户解决三大难题:.

ClickHouse在手淘流量分析业务实践

- - InfoQ推荐
导读:本文主要介绍手淘流量分析业务发展过程中,实时性业务分析需求的产生,实时分析目标的设定,如何进行技术的选型,以及如何基于ClickHouse构建系统架构和未来的业务预期. 流量分析与业务背景:什么是流量分析,以及我们的业务背景"大数据"带来的难题:当你的数据量是守恒的时候,需要怎么处理你的数据技术选型与产品考虑:在以上背景下,我们在技术选择和产品考虑时,都做了哪些考虑,以及为什么最终选择ClickHouse,并给大家介绍一些技术解决方案.

流量威胁分析系统与Tenable生产实践

- - Candylab
信息安全体系构建中流量监听是一种常见的防护手段,从流量抓取到日志落地,从日志分析到威胁报警,相应产品基于流量分析模式,从最上层的处理逻辑来看是相近的,使用Suricata还是Snort处理流程类似接近,最粗放的方式去理解他们,这些系统都属于“大型字符串处理过滤系统”. 实际生产中可能会使多家厂商的产品配型开源产品使用,或自主开发,无论采用那种方案,我们都可抽象出一种共通的顶层流量数据处理模式,典型的流量过滤与日志分析处理流程.