几位同学在讨论测试左移右移相关的话题，其中提到了一个词：可测性。
这个词在很多质量保障相关的文章中出现过，大家也觉得可测性是质量保障工作开展很重要的一个前提。但是可测性到底该如何理解？可测性有没有一个具体的定义？如果有，在软件的整个生命周期中，可测性在不同环节又是如何体现的？
这篇文章，我想谈谈我对于可测性的理解和思考。
如何理解可测性？
软件测试最基本的工作，就是通过各种不同的方法，从各个维度验证研发交付的软件系统功能、性能、安全等方面是否符合预期。这里的预期结果是有一个标准定义的，无论是需求描述的功能逻辑要实现什么效果，还是安全或者性能角度的技术指标，最终交付物一定要满足这个标准，才可以视为软件系统达到了线上发布要求。
即我们假设在整个软件生命周期的不同阶段，它都要满足不同的标准，才能视为达标，流转到下一个环节。所谓的可测性就是，在测试需要介入的不同环节，评估是否可以正常开展测试活动的前置条件。满足了这个条件，测试活动才能正常开展下去。
可测性在不同阶段的表现形式
从软件的整个生命周期来看，大体可以分为如下几个阶段：
需求阶段
在需求阶段，测试介入的时间点一般都是需求评审环节，近几年开始有了需求测试这个名词，其实是对需求可测性的进一步描述。需求测试的核心在于明确“测试什么”，即被测对象中的什么需要测试，通过需求评审环节，对需求进行细化和拆解，最终产出可测试的内容。
可测试的内容必须有一个明确的预期结果，或者需求最终的实现必须满足可观察可验证的要求。可测性在需求阶段，指的是满足需求要求的正常前置条件，同时也应该说明不满足要求时的错误情况。
设计阶段
设计阶段的可测性，主要指的是技术实现方案和测试用例两方面。技术方案，主要关注的是方案的实现是否存在可能的性能问题或者安全问题；而测试用例的可测性，最主要体现在用例评审或者show case(用例描述的输入输出，和需求描述以及研发实现是否一致)。举个我自己遇到的技术方案可测性的例子：
需求背景：电商业务，订单详情页要实时展示物流信息。
技术方案：订单详情页调用物流接口，访问一次详情，下游调用物流信息4次。
已知情况：订单详情接口线上QPS约为5000，99RT约为40ms；物流服务接口的99RT约为150ms，依赖外部的三方服务，且这个需求的实现是下游强依赖。
这个案例很明显，如果按照该技术方案实现，就会影响订单详情业务场景的性能表现，简单理解就是技术方案的预期实现结果不符合更核心业务的要求，这里的预期结果以订单详情的线上99RT为准。
研发测试阶段
到了研发测试阶段，可测性其实都是大家熟知的事情了。
比如提测时候要求冒烟测试通过率100%，冒烟测试的基准则是本次迭代需求的P0用例；比如在进行全面的功能测试之前，大家现在更习惯先进行接口测试，确保数据交互和逻辑处理的正确性；再比如进入系统测试阶段的前置条件，就是各子系统之间的交互部分，要提前约定好且测试通过才能进行系统测试。
线上发布阶段
到了线上发布阶段，这里的可测性大概分为两部分：
变更测试：线上发布需要进行很多的配置和变更操作，可测性指的是所有涉及的变更都需要在测试环境测试通过，且线上变更部分需要多方评审通过才能进行线上变更和发布。
线上验证：线上发布完成后，要对本次需求迭代范围内的场景进行测试，要求测试结果符合预期；还有一点容易被忽略的是，要假设本次上线可能会出现问题，针对不满足条件的错误情况，要有对应的应对策略和方案，并在测试环境验证该策略和方案有效。
其实所谓的可测性，和质量门禁在本质上没有太多区别。唯一的区别在于：可测性是前置要求，质量门禁是前置要求的具体定义。
感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
