软件测试中可测性一般是指对系统的可控性、可观测性进行的评估，借以反映系统设计、实现对测试的友好程度和相应的测试成本。可测性在测试阶段会对系统的测试成本及关联产品代码的 Patch 次数产生重大影响。如何提高可测性成为软件生命周期特别是前期（设计阶段、coding 阶段）重要的一环。 本文带领大家探索在实际项目中可测性相关的实战经验和对应的改进措施。
1 提高可测性的切入点
可测性的评估和改进最早开始于两个阶段：
a. 新项目的设计阶段；
b. 已有项目新功能、新策略的提测阶段。
这些是提高团队设计的系统可测性和维持系统的设计高可测性的关键时间点。测试人员会利用各种场合、机会强化开发人员对于可测性的重视：
- 可测性的重要性
每次设计讨论会， 测试负责人必提醒大家在设计时注意可测性。否则设计出来的功能很可能需要进行重构。
- 可控性
每次晨会中的讨论环节， 测试负责人会提醒模块设计人员，设计的功能需要必要的外部控制、执行动作支持，否则 QA 无法精确控制过程及缩短测试耗时。
- 可观测性
每个功能进行测试设计阶段，提前和开发人员沟通必要的功能，观察结果集合可以系统外部获得，错误结果可以被暴露而不是由内部逻辑完全消化。
那可控性和可观测性又指哪些方面呢？ 如何向开发人员合理的解释可测性？
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 提高可测性的通用方法
-
摒弃原有的开发人员只进行单纯的代码单元测试的观念，让开发人员也进行系统级测试。
作者在实践过程中最推崇的方法就是此条。具体地说，开发人员进行的是系统级测试，禁止刷行覆盖率型的单纯函数覆盖 UT。由系统级接口或者功能来驱动整个测试过程。无法直接进行驱动的测试行为需要撰写模拟器或者模拟模块进行。
这样开发人员会切身的感受到可控性和可观测性的重要性。进而推动系统在这两个方面的实现更易用和便于测试。由此而来的良性循环能让系统整体可测性始终处于较好水平。
-
测试人员深度了解被测系统，能够在可测性出现问题的时候及时指出问题所在。
只有深度了解被测系统，详细分析系统实现逻辑和代码，做到可黑盒、可白盒测试的程度，才能提前预测可测性薄弱环节，提前预防这样的事情发生。在可测性出现问题时，及时介入和提出建设性意见。在需要进行测试代码植入以方便测试流畅进行等方面亲自动手，协助开发人员解决问题。
可测性问题可能出现在系统的各个方面，但只要在系统生命周期的各个环节严格要求并辅以正确的方法，可测性问题就不会成为软件测试中不可攻破的难关。各位朋友，你遇到过哪样的可测性难题呢？如果让你从设计阶段就贯彻好的可测性要求并在整个流程中严格遵守，能否解决你的难题呢？