软件测试中可测性一般是指对系统的可控性、可观测性进行的评估，借以反映系统设计、实现对测试的友好程度和相应的测试成本。可测性在测试阶段会对系统的测试成本及关联产品代码的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掉了。无法观测到执行结果集带来的后果是无法精确的预期测试结果。
而相应的改进措施就是解决上面提到的问题。
