可测性是设计方案的必选项

功能性，健壮性等这些特性是系统设计方案中常见的要求和体现。

设计出的系统能够持续运行多长时间，支撑多少的业务并发量，容忍多少种异常业务场景是评价一个设计人员的设计功力的重要指标。同时我们也越来越多的感受到一个良好的设计是简单的，可重用的；“高内聚，低耦合”，“开闭原则”等等一系列的设计指导原则成为设计人员的座右铭和口头禅。

但是，鲜有“可测性”的要求见诸方案评审的场合。

可测性意味着，研发人员产出的系统设计和编码，能够且易于被测试。为什么要有这条要求呢？

首先，容易测试的设计和代码表明在结构上更清晰，在自测的过程中更容易发现和修正问题，能够有效节省开发过程中的自测成本，一种实现方式花费了1人日的时间开发完成，却用了5人日的时间，都没有自测完成，这种时候实际上要从方案的设计本身来思考问题了；

其次，能够节省质量保证人员的时间成本，这也就意味着他们花费同样的时间，却能够为开发人员保证更高的质量，是一种双赢的局面；如果一种设计方案在底层的数据层和上层的展示层都会有可预见的变更，在中间的抽象层却无法进行有效的持续集成，一旦方案产生变更，留给测试人员的是难以完成的回归量，留给开发人员的是迅速膨胀的线上问题需要排查和解决。

再次，其实很多时候容易被忽略但也是最重要的一点，测试团队和开发团队的协作，尤其是精神层面的相互配合，在可测性上，如果双方能够达成和谐一致的状态，考虑彼此的核心诉求，对最终的项目产出是1+1>2的效果。

曾经在看一个测试分析理论的公开课时，有段表述记忆很深刻，使用路径分析法对一段逻辑进行测试用例覆盖，包括单条的顺序链路，分支链路，循环链路，其中举了一个极端的例子，一段逻辑分析下来，各种组合下来链路超过百条，这时，其实要做的不是苦苦地去测试分析，用例覆盖，而是通知设计人员--re-design.