1.3.3 可测试性的3个核心观点

在正式讨论可测试性的技术细节之前，很有必要先介绍可测试性的核心观点。笔者认为可测试性有3个核心观点（如图1-10所示）。

图1-10 可测试性的3个核心观点

1. 可测试性是设计出来的

毋庸置疑，可测试性不是与生俱来的，而是被设计出来的。可测试性必须被明确地设计，

并且正式纳入需求管理的范畴。在研发团队内，测试架构师应该牵头推动可测试性的建设，并与软件架构师、开发工程师和测试工程师达成一致。测试工程师和测试架构师应该是可测试性需求的提出者，并且负责可测试性方案的评估和确认。在研发过程中，可测试性的评估要尽早开始，一般始于需求分析和设计阶段，并贯穿研发全流程，所以可测试性不再只是测试工程师的职责，而是整个研发团队的职责。

2. 提升可测试性可以节省研发成本

良好的可测试性意味着测试的时间成本和技术成本都会降低，还能提升自动化测试的可靠性与稳定性。今天在可测试性上的前期投资，会带来后续测试成本的大幅度降低。今天多花的一块钱可以为将来节省十块钱，这再次证明了“很多时候选择比努力更重要”。

3. 关注可测试性可以提升软件质量

可测试性好的软件必然拥有高内聚、低耦合、接口定义明确、行为意图清晰的设计。在准备写新代码时，要问自己一些问题：我将如何测试我的代码？我将如何在尽量不考虑运行环境因素的前提下编写自动化测试用例来验证代码的正确性？如果你无法回答好这些问题，那么请重新设计你的接口和代码。当你开发软件时，时常问自己如何验证软件的行为是否符合预期，并且愿意为了达成这个目标而对软件进行良好的设计，作为回报，你将得到一个具有良好结构的系统。

要让研发团队重视可测试性是件很难的事情，究其根本原因，在于研发团队“不够痛”。

长久以来，测试团队和开发团队一直是独立的两个团队，开发工程师往往更关注功能的实现，其次才会关注一些类似性能、安全和兼容性相关的非功能需求，可测试性基本是没有任何关注优先级的，因为测试工作并不是由开发工程师自己完成的，可测试性的价值开发工程师往往感受不到。而测试工程师虽然饱受可测试性的各种折磨，却苦于处于软件研发生命周期的后期，对此也无能为力，因为很多可测试性需求是需要在设计阶段就考虑并实现的，到了最后的测试阶段很多事情为时已晚。

很多时候，你不想改是因为你不痛，你不愿意改是因为你不够痛，只有真正痛过才知道改的价值。所以应该让开发工程师自己承担测试工作，这样开发工程师才会切身地感受到可测试性的重要性与价值，进而在设计与开发阶段赋予系统更优秀的可测试性，由此形成的良性循环能让系统整体的可测试性始终处于较高水平。