测试阶段发现缺陷多怎么办？

在做精益敏捷咨询的时候，时常发现研发团队在测试阶段发现缺陷多，此时往往表现瓶颈在测试处，需求无法快速完成验证。如何找到 Quick Win 的方法，来明显减少测试阶段的缺陷呢？

针对测试阶段发现缺陷多的问题，进行了分析，如下图

测试阶段发现缺陷多，一般有两个原因：1）需求提测质量差 2）测试同学技能强，其中第 2 点是咱们期望的，那咱们来分析第 1 点。

需求提测质量差，一般表现原因为：1）代码质量差 2）开发和测试对需求理解不一致 3）开发自测不全面、提测标准不明确 4）针对已有问题，缺陷引入原因不清晰

接下来对这些原因逐一的分析

1、代码质量差

有可能是开发技能差，也有可能是没有进行代码评审或代码评审效果差、没有进行代码静态和安全等检查、没有测试机制保障等导致的。

开发技能差，很明显的解决办法是做开发人员的技能进行培养，技能培养没有 3-6 个月是表现不出来的，是一个漫长的过程，是重要而不紧急的事情，需要做，但无法 Quick Win。

对于代码没有评审、没有检查机制和测试保障的问题，不管是阿里内部还是业界，都有比较好自动化检查工具可视使用，譬如阿里巴巴的代码规约插件，业界的静态扫描工具等度可以快速发挥价值，所以引入一套自动化的代码检查工具，可以低成本快速的发现现有代码中的问题。这是一个可以投入少产出快并可长期保障的实践，是一种 Quick Win 的方法。

记得在阿里某 BU 只启用了 Findbugs 的检测空指针判断功能，同时对这些问题做了修复，就为某 APP 的 Crash 率降低了 1 个百分点，对于数亿用户的 APP 说，这是投入产出比是相当可观的。

2、开发和测试对需求理解不一致

开发和测试对需求理解不一致，很可能会出现，产品、开发和测试对这三位需求理解也不一致。

研发团队普遍采用需求评审的方式，产品经理讲解需求，开发和测试听并对有问题的地方进行确认和沟通。在需求评审通过后，产品、开发和测试都认为自己对需求理解了，同时也认为对方也理解了需求，且理解一致了。真的是这样吗？此时是否有人可以拍拍胸脯说，我认为现在产品、开发和测试需求理解一致了，往往没有人敢这么说。而结果往往，如下图

We all agree, but.

如何真正做到产品、开发和测试对需求理解一致呢？采用测试即需求（测试验收驱动开发）的方式可以快速让这三方达成一致，是一种 Quick Win 的方式，关于如果执行落地，会在第 3 点进行讲解。

3、开发自测不全面、提测标准不明确

作为曾经的开发工程师，知道开发工程师和测试工程师的思维逻辑是不一样的。开发更多的考虑如何把正常的逻辑先跑通，然后考虑相对简单的异常场景，然后这些都自测以后，就认为自测通过了其他，可到测试同学哪里，发现漏洞百出，可以说自测往往是不全面的。

当年带领一个团队开发一个 VPN 客户端，准备通过 TR4，在提测前咱们做了多轮的验证和自测，所有功能都自测通过了。可提测后的当天就被打回来了，原因是测试同学一上来就灌了大流量，该客户端很快就挂了。咱们自测的时候，完全没有考虑大流量的问题，到时被测试打回。

那如何让开发能进行全面的自测，比较好的方式是让测试同学提前提供冒烟测试用例给开发。

测试同学提前提供冒烟测试用例给到开发，开发对照冒烟用例进行自测，可以让自测更加全面，同时冒烟用例通过后，才可以提测，让提测的标准也明确化。

很多团队估计已经这么做了，但往往冒烟用例是在是在开发提测前提供的，而用例也是在这个阶段评审的，可偏偏在评审的时候发现了需求的问题或者是几方理解不一致的问题。

如何解决呢，一种 Quick Win 方式就是测试即需求，那如何落地呢？如下图：

1）在需求评审完成后，测试同学在 1-2 天内就把功能验收用例用 Xmind 写出来，并选择一定数量的用例作为验收冒烟用例，然后邀请产品和开发一起评审，测试用例评审通过后，这个测试用例就可以作为需求的验收标准。

为什么要需求评审完后的 1-2 天就进行测试用例评审呢？为了更早的发现需求的问题和明确需求的验收标准，同时减少开发返工的可能。

2) 在开发阶段，验收冒烟用例作为开发自测的依据，如果这个验收冒烟用例能自动化就更加理想了。验收冒烟用例的明确，也要开发提测的标准也完全明确化。

3) 在测试阶段，由于需求的提测质量明确了，测试同学会有更多的时间做其他的测试，譬如探索性测试，压力测试和各种异常测试等等。

把上面的三步加起来，我们称之为测试即需求，用了测试即需求后，可以确保产品、开发和测试对需求理解一致，同时提供需求准入准出开发的质量。这也是一种 Quick Win 的实践，同时能进行规模化复制。

更多关于需求澄清的文章，可以参考何勉老师写的《实例化需求：不可或缺的精益、敏捷需求实践》，讲的生动同时也有实例，是需求澄清很好的实践，同时对团队来说，有一定的门槛。

4、针对已有问题，缺陷引入原因不清晰

针对已经的问题，做引入原因或根因分析分析归类，针对引入问题最多是的点进行优化，防止问题的再次引入，从而降低提测阶段的缺陷数量。

综上所述：

要减少测试阶段缺陷，测试即需求和引入自动化的代码检查工具，是降低测试阶段缺陷数量的 Quick Win 的两个实践，同时也是可以规模化复制的实践。

当然通过建立分层自动化测试的持续集成持续部署流水线，可以持续保障代码和制品的质量，让团队可以有信心的进行部署和发布。

如果觉得本文对你有帮助，可以在你团队中进行探索和实践。欢迎分享实践成果。