软件测试项目，资深测试经验：快速迭代的项目如何减少返工......

---

前言

是人就是要无的，是机器就是会坏的，是程序就是要出bug的。

真的勇士，就是要敢于直面惨淡的warning、敢于正视淋漓的error。

删除的代码是没有 Bug 的代码

有人喜欢创造世界，他们做了开发者；有的人喜欢开发者，他们做了测试员。

测试工程师承担的任务角色决定工作内容和承担的任务。测试工程师的角色应该承担什么任务呢？这没有统一的答案。因为，这与软件公司的规模，软件项目管理制度，公司领导和项目经理的管理风格，以及具体软件项目自身的特点有很大关系。而且，测试工程师也有普通和高级之分。

很显然，软件测试并不是一个找bug的岗位，而是以确保软件质量，保证软件能正常运转，面向大众需求的岗位，在一个项目流程中，测试是识别软件产品和服务的准确性和质量的过程。

一、概述

在互联网产品中，产品的迭代速度越来越快，项目中的软件测试同学面临着前期需求摇摆不定，中间各种开发进度死锁，而发布时间却无法推迟。项目的前期阶段似乎总是在压榨着测试的执行时间。

如何减少测试返工，测试阶段的工作量的同时，保障项目质量？

二、立项后

项目目标要明确，最好有量化指标。

产品需求是否为项目目标服务？

有些项目，目标定的很好，但是需求列表，经不住推敲，与项目目标弱关联甚至没有关联。乃至于很多需求都是基于假设，但这种假设却经不起推敲。我们测试人员可以在项目前期，果断的拒绝这类项目，或砍掉部分不现实的需求。

减少项目后期的需求变更。这样做，还可以减少上线后不必要的修复、缩减N次迭代，避免扯皮。

三、需求分析阶段

需求一定要有优先级和重要程度。对于尝试性的需求，在保障质量的同时，尽量减少投入工作量。对核心功能，优先保障自动化覆盖。无论是在本次项目中，还是后续版本的迭代中需要不断的进行重复测试，保障最核心功能的质量。

测试人在需求分析阶段尽可能细的拆分需求，通过场景法及各种异常分支流，验证产品的功能是否完善，提前发现问题。

在这个阶段，测试需要发挥自己的逻辑性思维优势，帮助产品经理和开发们理清细节逻辑，让产品更丰满清晰，而不是干瘪瘪走主流程。

这样会让项目后期风险更可控，减少后期产品经理、开发、交互、测试之间的“交流”时间，减少需要变更次数。

不合理的需求要大胆的砍掉。试问有多少上线后就无人问津的生僻功能在前期白白浪费了大家的时间？这些产品的功能如果能在需求阶段就砍掉，不知道可以节省多少人力成本。测试同学们可以更自信些，敢于向不合理的需求说NO。

四、设计阶段

提高可测性设计，在设计阶段，除关注产品的实现外，测试人员必须关注可测性设计。

一个可测性设计好的产品，在测试执行过程中，可以大大减少测试执行时间，bug原因定位时间，测试验证时间。

五、编码阶段

测试驱动开发

这里的测试驱动开发不是严格意义上的。

因为在短平快的项目中，在一个未发展完全的团队中，我们还不能在编写某个功能代码前，先编写测试代码。

这里的测试驱动开发是指利用测试的逻辑严密性，逻辑完善性，来指导开发编码代码。

具体做法，测试人员第一时间产出业务逻辑导图，并完成导图评审。这里指的评审是开发和测试、产品都参加的评审。

确保大家对需求的理解一致，产品功能的处理方式理解一致，这一点非常重要。之后，开发在编码时，可以尽可能完善的考虑各种场景，异常流等。减少后期发现bug、提交bug、修复bug、再重复验证bug等一系列返工。

六、代码走读

在开发编码过程中，必要时进行代码走读，补充测试。

这个过程，早起发现开发代码级bug，又增加测试覆盖度，从而减少测试过程中反复，减少测试返工。

七、提测后

现在是测试人员发挥的时间了

大家会开导，在测试执行阶段浪费的工时，被我们大大的拉到项目前期去了。还是那句话“测试尽量往前走，越早暴露问题越好”。

bug越晚修复，付出的成本越高，代价越大。

八、总结

当你打算放弃梦想时，告诉自己，再多撑一天一个星期一个月，再多撑一年吧。你会发现，拒绝退场的结果令人惊讶。

奋斗是这么个过程，当时不觉累，事后不会悔。走一段再回头，会发现一个更强的自己，宛如新生。

生活中，应对困境，咱们常常会有走投无路的感觉。不好气馁，坚持下去，要坚信年轻的人生没有绝路，困境在前方，期望在拐角。只要咱们有了正确的思路，就必须能少走弯路，找到出路！