如何减少测试返工保障项目质量？

在互联网产品中，每个产品的迭代速度越来越快，项目中的测试同学面临着前期需求摇摆不定，后面发布时间卡在那里，项目的前期阶段似乎总是在压榨着测试的执行时间。如何减少测试返工，测试阶段的工作量的同时，保障项目质量呢?

一、立项前

项目目标要明确，最好有量化指标。产品需求是否为项目目标服务?有些项目，目标定的很好，但是需求列表，经不住推敲，与项目目标关联不强。特别是很多东西是基于假设，而这种假设是站不住脚的。可以在项目前期，果断的拒绝这类项目，或砍掉部分不现实的需求。减少项目后期的需求变更。这样做，还可以减少上线后不必要的修复、N次迭代和解释工作。

二、需求阶段

需求一定是有优先级和重要程度的。对于尝试性的需求，在保障质量的同时，尽量少的投入工作量。对重要程度高的功能，优先保障自动化覆盖，无论是在本次项目中，还是下几个版本的迭代中可以不断的进行重复测试，保障最核心功能的质量。测试人在需求分析阶段尽可能的分解需求，通过场景法及各种异常情况下，产品的功能是否完善，提前发现问题。

同时，在这个阶段，测试可以发挥自己的逻辑性强的优势，帮助产品经理和开发们理清细节逻辑，让产品更丰满清晰，而不是干瘪瘪主流程，这样会让项目后期更可控，减少后面不必要的产品经理、开发、交互、测试之间的细节确认时间，减少后面的需要变更次数。

不合理的需要可以大胆的去砍掉。有多少上线后就无人问津的生僻功能，这些产品的功能如果能在需求阶段就砍掉，不知要省多少人工成本。测试同学可以更自信些，敢于挑战不合理的需求。

三、设计阶段

提高可测性设计，在设计阶段，除关注产品的实现外，测试人员必须关注可测性设计。一个可测性设计好的产品，在测试执行过程中，可以大大减少测试执行时间，bug原因定位时间，测试验证时间。

四、编码阶段

保障自动化的覆盖率

一定程度的自动化覆盖率，可以减少项目过程中不断的修复，迭代提交测试的重复测试。

测试驱动开发

这里的测试驱动开发不是严格意义上的。因为在短平快的项目中，在一个未发展完全的团队中，我们还不能在编写某个功能代码前，先编写测试代码。至于为什么不能，就不在这里赘述了。我想说的测试驱动开发是指利用测试的逻辑严密性，逻辑完善性，来指导开发编码代码。具体做法，在 UC产出后，测试人员第一时间产出TC，并完成TC评审。这里指的评审是开发和测试、PD都在的外审。确保大家对需求的理解一致，对产品功能的处理方式理解一致，这一点非常重要。之后，开发在编码时，可以参考测试TC尽可能完善的考虑各种场景，异常流等。减少后期发现bug、提交bug、修复bug、再重复验证bug等一系列返工。

代码走读

在开发编码过程中，必要时进行代码走读，补充测试TC。这个过程，早期发现开发代码级bug，又增加测试覆盖度，从而减少测试过程中的反复，减少测试返工。

五、提测后

基本上还是常规做法。

以上内容为大家介绍了如何减少测试返工保障项目质量，本文由多测师亲自撰写，希望对大家有所帮助。https://www.duoceshi.com/xwzx-hydt/1551.html