之前有人问过我一个问题：如果开发的质量比较高了，测试没有发现缺陷，那是不是就可以减少测试？看着好像是这样子的，但总感觉哪里不对。最近又看到有人在讨论没有发现缺陷的测试是否有价值。结合自己的经历，尝试系统地思考下这个问题。先说结论：肯定是有价值的。
测试没有发现缺陷，存在两种情况：1. 没有深入的测试 2. 研发交付的质量高。
针对没有深入的测试这种场景，在《迭代测试发现不了问题，怎么办》一文中做过探讨，有几点针对性的措施，这里不再展开。
本文重点讨论第二种情况，业务需求明确，研发个人能力强，做过充分的自测，交付质量很好，经过几个迭代的测试，发现的缺陷较少或者没有，那这个人提交的代码还要不要测试？测试人员的投入是否还有价值。
结合个人的经历和思考，我觉得第二种情况的测试投入还是必要的。测试的价值不仅仅是发现缺陷，至少还有以下几点直观的价值：
a. 建立测试资产：测试设计、测试用例等测试过程资产的沉淀还是非常有必要的。如果不投入测试资源，对应的需求分析和用例都将缺失，后续如果其他人想要介入，就缺少对应的 IT 资产。
b. 评估风险：经过系统的测试，哪怕没有发现缺陷，那也是经过经验，可以有效地评估风险。如果没有测试，仅凭过去的经验，对于这部分的上线风险评估是缺失的。
c. 检查需求理解：测试人员的测试范围不仅仅是代码是否正确，还需要验证研发对需求的理解是否准确，是否符合业务场景，是否有场景遗漏等内容，这部分研发考虑的会比较少。
在思考这个问题的过程中，也调研了部分开发人员的意见，包含那边代码能力优秀的人，普遍给的反馈是：还是需要经过测试验证的。原因有以下几点：
a. 充分验证：不论是单元测试还是 TDD，成本都比较高，现在更落地的做法是测试人员提供自测用例，开发人员进行更充分的自测，效率更高。
b. 需求对齐：虽然经过多轮的需求澄清，但大家对于需求的理解和影响范围考虑总有不全面的时候，需要有测试人员进行进一步确认和补齐。
c. 个人波动：个体不是机器，也会波动。不能保证自己的产出每次都经过那么严格的测试，如果不测试而引发生产事故，后果比较严重。
从团队管理的角度上看，我们更希望构建一套完整的质量保障体系，这个体系需要减少对个体能力的依赖，保障交付质量的下限。通过标准规范化的操作，做好每一步的过程监控，以期望达到一个比较好的交付质量。如果因为部分人员的个人能力，绕开了这个体系（不需要测试），那么，最终的结果就是会有越来越多的人走这条捷径（破窗效应？）
很多团队都有设置紧急需求处理通道，结果就是多数情况下，需求都是紧急的。
这话其实很没说服力，当下的多数情况，测试还是总被轻视。但作为测试人，我还是要想多说些。测试这个行业经过这么多年的发展（参考下图），很多人的行动都还是停留在测试是为了 “确保程序解决了它该解决的问题” 上，而不是以预防为主的质量内建上（虽然都这么说，但并没有真实地意识到，毕竟质量是昂贵的，质量是可以用非技术的手段去解决的）。
测试人员还需努力，做好向上管理，给老板画好质量的 “饼”。
共勉。
