软件测试干货——敏捷测试流程

胖虎

对于一个三个月的项目说，产品把需求分析完了给开发，然后产品就没事儿了；开发开发完成之后给测试，然后开发人员也不忙了。测试完成之后上线。那么在产品分析的阶段，开发和测试都是没事干的（这里只对单一项目）。开发阶段，产品和测试也基本没事儿。同样在测试阶段，产品与开发也是没什么事儿的。


这不是一个该有的测试态度！

　　敏捷测试的一个核心是迭代，在每个时间点上，所有项目人员都是有事可做的。


1、下面是敏捷测试流程图：

第一阶段：

　　通过上面的流程图，对于一个月的需求分析，在敏捷中，可能三五天就确定下来。这个需求定得会很模糊，但整体框架确定。产品对其中某一模块功能确认，开发人员开始对确认的功能编码，开发人员编码的过程中，测试进行功能分解，因为根据模糊的需求很难写出具体的用例，所以，只能尽量对功能进行分析得细些，标注需要验证的内容。

第二阶段：

　　开发完成后交给测试人员进行测试，开发人员继续开发新的功能。那么测试人员发现的问题怎么办呢？会从开发团队中抽出一个人员来用于解决测试发现的问题。但开发进度并没有因为测试而停止。

流程分析：

　　在这个流程中弱化了文档，强调了各个人员的沟通，通过这种迭代的方式，三个月的项目，可以能两个月和两个半月就会完成。

但这种流程并非完美，加入一个功能在需求分析阶段就是错误的，因为它是一个迭代渐进的过程。也只能一路错下去。


2、对测试问题的处理

      需要说明的是，敏捷测试在国外很流程，在内容，雷声大雨点小，推行的人很多，真正有公司引入的不多。我们所在公司千差万别，测试流程也可能有很大的不同。希望大家不要被思想局限，所以，请努力冲破一个又一个的局限吧——这正是我们这一行业的魅力啊！

applepen

"测试进行功能分解，因为根据模糊的需求很难写出具体的用例，所以，只能尽量对功能进行分析得细些，标注需要验证的内容。" 这个是重中之重啊。但是很多细节在前期根本敲不定。