问题1：测试是否真实有效？——测试有效性
第一个关键问题，我想知道我的测试是否都真实有效。乍看上去像个伪问题，其实不然。可以扪心自问一下：我能保证软件所有的测试都是有效的测试吗？不见得吧……对这个问题心里有底的测试人员值得好好表扬一下。基于真实经验和数据不难得出结论，有效测试的比例并不高，甚至在某些场景下，测试人员都没有考虑过“大量执行的测试是否真的有效”这个问题。
如何评估测试有效性呢？可以从测试策略、测试反馈、可测性等角度来逐一盘点。
测试策略
测试金字塔
首先评估测试策略的有效性，可按照测试分层模型“测试金字塔”来逐层盘点：
1. 总共分几层：采取哪些测试
2. 各层占多大比例：测试重点
3. 各层测试目标：不同的测试服务于不同的测试目标
4. 各层覆盖要求：不同测试应覆盖哪些问题，覆盖率的要求
然后评估测试用例和用例集的有效性：
1. 不管是手工测试用例还是自动化测试用例，每个测试都需要是有效的测试
2. 不同的测试用例集能真实的服务于不同的测试目标
3. 消除重复的测试或各层之间重复覆盖的测试点，避免浪费
4. 测试覆盖相对完备：不片面追求覆盖率数值，而强调对业务场景的覆盖程度
5. 建立测试下沉机制：在金字塔上层发现缺陷，评估是否从下层逃逸，如是应在下层补测试
测试反馈
为了使测试能有效的反馈代码质量，适量的测试应在合适的时机进行，且能有效反馈代码质量，并能起到门禁作用，避免低质代码流入下游。解释一下这句话中的关键信息：
1. 适量的测试：不同测试应有不同量级的用例被执行，保证覆盖的情况下越少越好
2. 合适的时机：不同的测试可按需周期测、随时测，或放到流水线上时时跑着
3. 有效反馈：合理预期，正确断言，确保能真实反馈软件表现
4. 门禁作用：当测试不通过时应及时截断，避免低质代码继续流转
可测性
软件可测性指被测软件在给定测试环境下，可支持测试的程度。软件可测性有较多参考因素，如：可控制、可观测、隔离性、可读性、自动化程度等。软件可测性是确保测试有效性的必要条件，当可测性较高时，测试有效性才有可能维持较高的水平。
一般当聊到可测性时，可能会根据测试类型的不同做以下区分：
1. 前端可测性：指软件对前端测试的支持程度，如UI规范、前端代码规范等
2. 后端可测性：指软件对后端测试的支持程度，如高内聚低耦合，提供测试接口、执行步骤可控可观测等
3. 完善的日志系统：提供可观测、可追踪的日志系统，便于快速定位问题
便于观测的日志系统
问题2：测试能否高效执行？——测试效率
当确保了测试有效性，就需要关注测试执行的效率如何了。毕竟是测试基于有限时间窗的活动，所以我们不光要追求测试都是有效的，还追求能高效的执行这些测试。而这又依赖于环境和设施的底层支持，以及持续的关注和改进测试执行效率的具体行动。
测试环境支持
我们对测试环境的使用过程可大致分为以下步骤：
准备测试资源 → 测试环境部署 → 测试服务部署 → 环境验证 → 环境使用 → 环境销毁
实际工作场景中，测试环境往往是阻碍测试效率的一大难题。为了达成不同的测试目标，测试所需要的环境、数据、集成情况可能都不一样，我们期望测试环境能“专款专用”，有效隔离，避免不同测试种类、不同测试人员、不同实践活动、不同测试数据之间相互掣肘。
吐槽测试环境
理想丰满，现实骨感。当测试人员在申请环境资源时，经常遇到各种阻碍，如环境资源的高成本，或者环境申请的长链复杂流程。测试人员期待的环境支持应满足以下几个条件：部署和维护成本低、按需扩展、即用即抛，不同测试间的环境和数据隔离，让测试人员能够从各种繁杂的排查环境问题中真正解脱出来，聚焦业务测试。
想要新环境？不存在的
测试基础设施
想要获得较高的测试效率，必不可少的关键因素是持续集成。测试效率要想提高，需要相对理想的测试策略：少量的手动探索式测试 + 大量的自动化回归测试 + 基于需求的专项测试，这其中大量的自动化回归测试就需要有效集成到持续集成流水线中去。可按照以下检查点来评估：
1. 有大量有效的自动化测试
2. 自动化测试添加到持续集成流水线
3. 基于每次代码提交的测试，如核心模块的单元测试，或核心业务流程的回归测试，应加到对应服务的pipeline中作为独立step，有效反馈提交代码的质量
4. 其他业务回归类的自动化测试，也需要定期频繁执行，关键时间节点必执行
5. 有测试执行的可视化报表或监控机制，确保问题及时被处理
除了持续集成，有效的测试也依赖于测试套件的快速准备，服务于不同测试目标的数据生成，以及测试工具或平台级的支持。
测试执行效率
不论测试的环境和设施支持是否完备（毕竟这不只是测试的决策），测试人员都需要持续的持续的关注和改进测试效率：
1. 手工探索：是否有助于在有限时间内发现缺陷，探索执行的测试是否需要加到常规用例中
2. 自动化测试：执行周期合理，执行时长相对稳定，通过率维持一定水平
问题3：测试价值体现在何处？——测试价值
内建质量
如果说以前测试的职责是发现软件的缺陷，那么现在我们聊的质量内建，其实是发现和纠正流程的缺陷。任何可能降低软件质量的工作方式，也可以是我们关注和改进的对象。而在质量内建的过程中，测试人员贡献的最大价值就是帮助全团队建立质量意识，由“测试和质量是QA的事儿”转变为“测试和质量是大家的事儿”。思维的转变是最难的，但也是一旦转变发生了，就会在各个工作点滴中迅速汇集效果的根本。
全程质量内建
暴露风险
测试的另一个重要职责是充分暴露风险。这里的风险有三类：质量风险、交付风险和生产环境风险。
通过缺陷建模、缺陷数据分析、根因分析和缺陷预防等实践，测试人员可以充分了解质量风险，从而对即将投产的软件进行质量风险上的预测。这种基于历史经验的预判有助于降低生产环境的质量风险。
在以往和测试人员交流的过程中，大家表示对风险的干预程度可能较低。但其实这里测试人员的价值在于充分的暴露风险：需要把风险点是什么、测试人员给出的预判、潜在风险可能产生的损失、风险干预的手段和因此产生的成本等等这些信息，全部同步给团队，并在团队进行风险干预时进行一定的输入和引导。
测试人员的职责：识别和暴露风险
捍卫门禁
测试人员的话语权体现在对质量门禁的捍卫上。人当有所为，有所不为，团队也一样。测试人员一定要捍卫质量门禁，不通过就是不通过，需要明确给出测试结论，尽量避免任何模棱两可的质量结论。
一些明确的质量结论示例：
l “某功能经过充分的测试和相关回归，测试通过，可以上线。上线后需观测……”
l “时间过紧，某功能只经过验收标准的测试，尚未充分的回归和探索，不建议在当前热更上线。可以安排在下次热更上线，我们就有充分的时间完成测试。”
l “如不可抗力必须上线，可能面临的质量风险有……建议采取以下几种措施进行干预和快速恢复，上线后建议相关角色持续观测……，确保第一时间捕捉线上问题。”
质量门禁需要捍卫，如果有原因导致门禁失效，那也是团队共同决策的结果，团队整体需共同承担质量风险，并尽所有人的努力把损失降到最低。
