程序可测性

什么是可测性？我的理解，可测性可以指代一个功能的测试切入点、验证点的多与寡，测试过程的简单与复杂。

测试切入点简单点说，就是能否更加全面地掌控数据的流转，举个例子，现有有一个类要测试，整个类

只给你暴露一个接口，你只能针对这一个接口给它输入验证它的输出，除此之外你无法获取更多信息，你不知道数据运算中间状态对不对、不知道过程有没有异常被错误捕捉、不知道数据有无完整落盘、不知道资源消耗是否不符预期……尤其是中间出现ABA的问题，是完全无法辨别的。这就是一个十分没有可测性的例子，是测试切入点太少，可验证性太差。

再举个例子，如果测试一个功能，你通过N步前置操作终于触发了这个功能，此时你还需要N步操作才能去验证这个功能是否正确，然而这个只是一个比较简单的功能，没有包含太多的复杂流程逻辑，那也是没有可测性，这是测试过程过于复杂，可操作性性低。

其实上面说的，都可以叫测试手段。不同的需求会导致不同的产品形态，不同的产品形态又会有不同的测试手段，测试手段的多与少就会影响可测性。

咱们改一下，对于一开始的那个类，如果它从只暴露单一接口改为提供多个debug接口，或者拆分功能让我们自己调用中间过程，或者提供了详细日志跟踪中间状态，可测性就有明显提高，这就是增加测试切入点；如果还是只暴露单一接口，有了自动化框架只需要简单添加配置文件就能自动灌数据验证结果，这就是降低测试过程复杂度。

这里列举一些增加可测性的方法：

• 可验证性
  • 添加必要的日志
  • 因输入导致变更的点就是输出，输出全部可查看（正例：中间数据的落盘）
  • 提示信息可读，意义明确且唯一（反例：返回码意义不明确且多个不同错误用同一个返回码）
• 可操作性
  • 简化测试准备和测试清理（正例：几个flag变量组合的条件判断，一键完成flag变量设置）
  • 测试过程有易用的配套工具
• 可控制性
  • 所有影响输出的因素都可控（反例：多线程死锁，难以构造死锁现场；难以构造的内部错误）
  • 可直接控制中间状态的数据
• 可分解性
  • 大系统中可以针对小模块独立测试
• 可理解性
  • 文档明确且随时update
  • 提供修改背景和影响范围

QA拿到测试需求，在了解完需求背景和功能点后，最先要明白的就是可测性，尽量在case评审之前摆平可测性低的问题，这样测试过程才流畅。所以，反过来往往需要我们在case编写时就对被测对象有清晰的了解，才知道要怎么测它，而不是模模糊糊只有个概念，或者到了评审完case真正开始测试时发现不少case因为自己不了解细节而写得不到位（必须要抛弃觉得RD会指出case遗漏的侥幸心理）。

当然可测性还有更多的拓展意义，比如文档友好、接口清晰、模块解耦、数据可控blabla，甚至可以反过来指导RD编写具备可测性的代码，存在有效的中间过程记录，复杂流程适度拆分，让功能模块之间尽量做到职责单一，某种感觉上是软件工程在QA视角的映射。