本文共计约字，建议阅读时间：16~17分钟。
阅读本文你将收获：
1、软件可测试性的详细概念；
2、软件可测试性差会引发哪些问题；
3、提高软件可测试性有哪些好处；
4、软件可测试性的四个维度；
5、不同级别的可测试性与工程实践
前言：随着云原生技术的加速普及与快速发展，软件系统的规模和复杂性不断水涨船高。与此相对应，在软件研发过程中，为测试而设计（Designfortesting）,为部署而设计（Designfordeployment）,为监控而设计（Designformonitor）,为扩展而设计（Designforscale）和为失效而设计（Designforfailure）正在变得越来越重要，甚至成为了衡量软件组织核心研发能力的主要标尺。
作者简介:茹炳晟，业界知名实战派软件研发效能和软件质量双领域专家，硅谷先进研发效能理念在国内的技术布道者，中国计算机学会（CCF）TF研发效能SIG主席；现任腾讯TechLead，腾讯研究院特约研究员，腾讯技术委员会委员。“研发效能宣言”发起人，中国商业联合会互联网应用技术委员会智库专家，IT图书年度最具影响力作者；多本技术畅销书作者，著有《测试工程师全栈技术进阶与实践》、《软件研发效能提升之美》和《高效自动化测试平台设计与开发实战》等图书，极客时间“软件测试52讲”作者，团体标准“软件研发效能度量规范”核心编写专家；国内外各大软件技术峰会的联席主席，技术委员会委员和专题出品人。
本文重点探讨“为测试而设计”的理念，以软件可测试性（Testability）作为主线，为大家阐述软件可测试性的方方面面以及软件组织在这个方向上的一些最佳实践与探索。
软件可测试性对软件研发和质量保障有着至关重要的作用，是实现高质量、高效率交付的基础。可测试性差，会直接增加测试成本，让测试的结果验证变得困难，进而会让工程师不愿意做测试，或者让测试活动延迟发生，这些都违背了“持续测试，尽早以低成本发现问题”的原则。为此我们有必要对可测试性进行一次深入浅出的探讨，主要内容包含以下5个方面。
可测试性的定义
可测试性差引发的问题
可测试性的三个核心观点
可测试性的四个维度
不同级别的可测试性与工程实践
01可测试性的定义
软件的可测试性是指在一定时间和成本前提下，进行测试设计、测试执行以此来发现软件的问题，以及发现故障并隔离、定位其故障的能力特点。各种组织对可测试性有不同的定义（如图1），我认为其本质是相通的，都是在说一个软件系统能够被测试的难易程度，或者是说软件系统可以被确认的能力。
我个人比较喜欢的定义是来自JamesBach的版本：“可测试性就是一个计算机程序能够被测试的容易程度”。
图1：可测试性的各种定义
测试设计能力，暨创造性地设想各种可能性，并设计相应场景是每个软件测试人员的核心技能，但是如何根据测试设计构造出所需要的测试条件，如何高效执行测试，以及测试执行过程中如何对结果进行实时的观察和验证，则是可测试性需要解决的问题。
02可测试性差引发的问题
可测试性似乎是个新命题，在软件测试发展的很长一段时间里，这个概念似乎并没有被广泛提及。那是因为以前的软件测试是偏粗狂式的黑盒模式，而且测试团队和开发团队是分离，测试工程师往往在研发后期才会介入，测试始终处于被动接受的状态。并且大量的测试与验证都是偏向黑盒功能，所以可测试性的矛盾并没有被凸显出来。但是在今天，随着测试左移，开发者自测，测试与开发融合以及精准测试的广泛普及，这种粗狂式的黑盒验证已经无法满足软件的质量要求。
如果继续忽视可测试性，不从源头上对可测试性予以重视，将会导致研发过程中系统不可测，或者测试成本过高的窘境。可以说，忽视可测试性就是在累积技术债务。更何况，今天大行其道的DevOps全程都离不开测试，测试成为了拉通持续集成与持续发布（CI/CD）各个阶段的“连接器”，如果可测试性不行，整个持续集成与发布的效率也会大受影响。
为了帮助大家更好地理解可测试性，这里先列举一些实际的可测试性问题作为抛砖引玉。
（01）GUI测试层面：
·登录场景下的图片验证码：图片验证码虽然不影响手工测试，但是对自动化测试的可测试性就很不友好，用OCR技术识别图片验证码不够稳定，如果能够实现稳定识别反而说明验证码机制有问题。如果登录实现不了自动化就会影响很多其他的自动化测试场景。对于登录过程中的短信验证码也有类似的可测试性问题。
·页面控件没有统一且稳定的ID标识：如果页面控件没有统一并且稳定（不随版本发布而变化）的ID，自动化测试脚本中控件识别的稳定性就会大打折扣，虽然测试脚本可以通过组合属性、模糊识别等技术手段来提升识别的稳定性，但是测试的成本就会变高。
·非标准控件的识别：非标准的前端页面控件无法通过GUI自动化测试识别，这个常见于Client端的测试。
·需要对图片格式的输出进行验证：图片的验证缺乏有效的工具支持，即使通过像素对比方案其稳定性也很差。
·业务流程过长难以分解：业务流程和业务场景过长，很难拆解后进行局部的验证。
·不可控的随机弹窗：有些应用会有随机弹窗的功能，比如弹窗广告，或者用户满意度调查等，这类不可控的弹窗会直接影响自动化测试的可测试性。
（02）接口测试层面：
·接口测试缺乏详细的设计文档：接口测试如果没有设计契约文档作为衡量测试结果的依据，就会造成测试沟通成本高，无法有效开展结果验证，开发和测试来回扯皮的尴尬窘境。即使有了文档，还必须保持文档能够及时更新，否则会造成误导。
·构建Mock服务的成本过高：微服务架构下，如果构建Mock服务的难度和成本过高，会直接造成不可测或者测试成本过高。
·接口调用的结果验证困难：接口成功调用后，判断接口行为是否符合预期的验证点难易获取。
·接口调用不具有幂等性：接口内部处理逻辑依赖与未决因素，比如时间、不可控输入、后台批处理job、随机变量等，破坏接口调用的幂等性。
·接口参数设计过于复杂，暴露了很多不必要的参数：很多内部参数不应该在接口参数上暴露出来，这些参数应该做到无感知，需要保持接口设计的简单性。
·使用定制化的私有协议：非标的私有化协议会提升测试的难度，通用类的工具无法直接使用。
（03）代码层面：
·私有函数的调用：在代码级测试中，私有函数无法直接调用。
·私有变量的访问：私有变量缺乏访问手段，以至于无法进行结果验证。
·函数功能的多样性：一个函数如果颗粒度太大，同时实现了好几个功能，会大大提升测试的难度，一来这是因为功能多必然入参也多，测试的时候参数初始化难度就会变大，二来结果验证的