在软件研发领域，我们常常把可测试性（Testability）定义为一个技术性的指标：代码是否容易被测试。

本篇我们换个视角来讨论：可测试性，其实不仅仅关乎代码，更关乎人性。

传统视角下的可测试性

在多数技术交流中，可测试性被限定在一个狭窄的范畴里。我们讨论模块化、依赖注入、日志记录、接口设计，这些都是为了让代码更容易被自动化脚本或单元测试覆盖。

这种关注并无可厚非，因为一个设计良好的系统确实能降低测试成本。

然而，仅仅止步于此，则只看到了冰山一角。

一个软件产品的成功，最终依赖于它能否在现实世界中稳定运行，而这个现实世界，充满了复杂的人为因素和环境挑战。

如果我们的可测试性只关注于代码好不好测，那我们就忽略了最关键的问题：

对于一个具体的人，在特定的情境下，要测试一个具体的产品，到底有多容易？

真正的可测试性

测试工程师应该熟悉以下一些场景：

• 自动化测试工程师耗费大半天时间，不是在写脚本，而是在处理不稳定的测试环境。网络波动、服务宕机、数据污染，这些与代码本身无关的因素，却会让测试变得寸步难行。等终于准备好环境时，往往一整天的精力已消耗殆尽

• 测试团队需要经过复杂的配置和依赖安装步骤才能开始进行某些测试，这使得手动测试和探索性测试变得极为低效。在时间压力下，团队成员可能必须放弃某些测试，或者只能进行最表面的功能验证。

• 开发人员和测试人员之间缺乏顺畅的沟通。当一个功能因为代码耦合度高而难以测试时，测试人员常常陷入困境，而开发人员很难意识到这种测试时产生的困境，未能及时提供协助。

以上这些问题，其实无一例外指向一个事实：

真正的可测试性，往往并不在于代码的复杂性，而在于围绕产品构建的整个生态系统，以及身处其中的人。

一个难以测试的产品，带来的不仅仅是发布延迟。更会消耗团队的能量，扼杀测试人员的好奇心和探索欲望。

此外，它甚至还会制造出一种“产品很稳定”的虚假安全感。当那些本应被发现的缺陷因测试困难而被遗漏时，最终影响的还是发布后的质量和终端用户。

如何提升可测试性

在理解了可测试性的人文属性后，我们该如何解决这个问题？

其实焦点就是从“让代码更易测”转向“让测试人员更易测”。

1. 重新定义“易于测试”

在定义产品功能时，更全面地考量：

• 工具支持：测试人员是否有趁手的工具？
• 团队文化：团队是否鼓励分享测试痛点并共同解决？
• 业务知识：测试人员是否充分理解业务需求？
• 工作环境：测试环境是否稳定可靠？

2. 将阻碍降到最低

在快速迭代的节奏下，我们总以为“速度”是第一要义。但需要注意的是，真正的瓶颈不是速度，而是各种阻碍。减少测试过程中的阻力，比单纯提高测试执行速度更有价值。包括：

• 简化环境搭建：利用容器化技术（如Docker）或自动化脚本，让测试环境的部署变得一键化。
• 清晰的文档：为复杂的系统提供清晰的架构图、API文档和测试指南，让新人也能快速上手。
• 工具链整合：确保测试工具、CI/CD流程和报告系统能无缝协同工作。

3.通过合理的指标跟踪可测程度

可以通过收集和跟踪一些测试过程数据来反映测试中的可测程度

• 环境就绪时间：平均需要多长时间才能准备好一个可用的测试环境？
• 缺陷重现成本：重现一个生产环境发现的缺陷需要多少步骤和时间？
• 新功能测试用时：一个功能从开发完成到测试通过，需要多长时间？

这些指标能够更帮助我们更直接地衡量可测试性，并帮助我们进行针对性的改进。

总结

可测试性，本质上是一个关于同理心和人本主义的话题。

我们应该从产品属性的视角，转移到支持测试人员的视角，再扩展到整个团队的协作视角。

技术是为人服务的，而软件质量的最终保障，源于对人的尊重和支持。