您的位置:知识库 » 软件测试

在短平快项目中如何减少测试返工

作者: 绣云  来源: 淘测试  发布时间: 2014-05-20 08:28  阅读: 1875 次  推荐: 3   原文链接   [收藏]  

  在互联网产品中,每个产品的迭代速度越来越快,项目中的测试同学面临着前期需求摇摆不定,后面发布时间卡在那里,项目的前期阶段似乎总是在压榨着测试的执行时间。

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

  在说下面内容前,我必须感慨下,测试是个伟大的职业,是技术上的全才,是项目中的大管家。什么编码能力,测试技能,产品思想,设计架构等十八般武艺样样都会。       

  Ø  立项前

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

  Ø  需求阶段

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

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

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

  Ø  设计阶段  

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

  Ø  编码阶段

  保障自动化的覆盖率

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

  测试驱动开发    

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

  代码走读

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

  Ø  提测后 

  基本上还是常规做法。

  大家会看到,在测试执行阶段减少的工时,被我们大大的拉到项目前期去了。也是永远不变的那句话“测试往前走,越早发现问题越好”。

3
0
标签:测试

软件测试热门文章

    软件测试最新文章

      最新新闻

        热门新闻