[技术思考] 软件可测性分析和实践

软件测试中可测性通常是指对系统的可控性、可观测性进行的评估，借以反映系统设计、实现对测试的友好程度和相应的测试成本。可测性在测试阶段会对系统的测试成本及关联产品代码的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. 测试人员深度了解被测系统，可以在可测性出现问题的时候及时指出问题所在。只有深度了解被测系统，详细分析系统实现逻辑和代码，作到可黑盒、可白盒测试的程度，才能提早预测可测性薄弱环节，提早预防这样的事情发生。在可测性出现问题时，及时介入和提出建设性意见。在须要进行测试代码植入以方便测试流畅进行等方面亲自动手，协助开发人员解决问题。

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

欢迎你们关注公号, 一块儿在技术领域互动和讨论.