敏捷测试理论以及实践 - 7(全文完)

【本篇是《敏捷测试理论以及实践》第七篇,(第一篇第二篇第三篇第四篇第五篇第六篇第七篇)】

 

 

5. 传统测试阶段

当开发完成了所有的功能点,测试那个时候也差不多完成了这些功能点的测试,我们就会有一个阶段性的最终版给客户评估,让客户看看需要的功能是不是都已经可以了,如果觉得没什么问题,一般情况下就不进行功能添加与更改了。(当然,真的要更改我们还是会欢迎的,不过一般客户也知道,频繁的更改不能保证产品的质量,所以到最后他们一般有不紧急的更改也会要求放在下一个版本里的)

到目前为止,真正意义上的敏捷测试阶段其实已经完成了,要开始进入一些传统的测试了,比如系统测试,性能测试,压力测试等。这些就会用到之前说的DevTest里管理的测试用例,通过这些测试用例,我们会生成测试任务,然后通过手工和自动的方式,把这些任务完成,当然,可能要进行几轮,第一轮测试最仔细,覆盖面最大,所以时间也最长,第二轮主要是对开发修Bug的确认以及可能影响到的功能的测试,最后还有一轮验收测试,主要对基本的功能进行测试,确保不会出现明显的问题。

这些测试都完成以后,差不多产品也就可以发布了,当然能不能发布,领导们还是会有一个会议研究通过的,不过也就是通过 DevTrack 和 DevTest 来导出一些报表看看测试情况来了解产品质量。

以上差不多就是我们公司现在的一个流程,从严格意义上来说,不是完全的敏捷测试,只是算一部分,但是如果从以前的瀑布来看看,已经算很敏捷了。而且,从现在这个流程分析,如果把那些传统意义上的测试继续敏捷化,我们觉得对产品的质量没法保证,所以基本上,目前这个模式,可以算是我们公司特色的敏捷测试了,之后应该不太会有大的更改了。

 

接下来我再总结一下我们公司的模式,以及补充一些之前没提到的,因为之前写得太急,有时候很难想得太全。

 

我们公司测试模式按照顺序主要有以下这么几步组成:

1. 需求阶段测试研究设计方案是否符合要求

2. 开发编码期间完成测试用例

3. 开发完成一个功能的编码,测试就需要开始测试,并且确保能在一个迭代周期中完成测试,并且确认严重Bug的修复

4. 所有迭代周期完成后,开始进入集成测试,系统测试,验收测试以及压力测试,性能测试

 

差不多测试需要参与的工作就是这几步了,下面就是有一些细节点讨论一下,我会以问答形式来介绍:

1. 问:发现了很多Bug,测试人员怎么知道哪些Bug要马上修,哪些可以推迟修呢?

答:首先,我们会规定什么样子的Bug需要什么样的优先级,比如报错优先级就会比较高,每个测试人员都有这么一个文档让他们来判断这个 Bug 是什么级别。其次,我们会有专门的人员对这些Bug进行二次过滤,由他们来觉得这个Bug是否需要在这个迭代周期中进行修复,这种专门的人员的能力需要很高,因为他们需要能了解这个Bug的重要性以及这个Bug修复起来所需人力物力是否能在这个迭代中解决,所以一般这个角色会有测试主管或者项目经理来承担。

 

2. 问:整个测试期间,就专职的测试人员参与测试就行了吗?

答:不是的,首先开发肯定需要进行单元测试;然后设计人员和项目经理也要参与测试,因为只有他们最清楚这个功能设计的初衷,才能真正知道现在做完的是不是真的符合当初的初衷;再次,客户也会参与测试,因为产品说到底最终是给客户使用的,他们当然想拿到一个他们满意的产品,所以我们会定期给客户版本,让他们对做好的功能点进行简单的试用,让他们来看看产品是否符合他们的需要,这样就是最直接的用户体验了,发现的问题也是最真实的。

 

3. 问:测试过程中是否需要开会?

答:需要,测试人员也会有每日立会,跟开发差不多,也是介绍,昨天做了什么,今天要做什么,之前碰到什么问题。会议效果很好,首先让大家知道其他人在测啥,然后如果有问题的话,大家一起讨论就可以共同进步。另外测试也需要有反思会,看看这一轮发生的问题,为什么有些Bug没有找到之类的。

 

4. 问:敏捷是否需要特别的测试技术?

答:不需要,敏捷只是一种思想,有一些价值观,它不会教你用什么方法去测试一个产品,只会教你以怎么样的一种态度去做测试,以怎么样的时间安排去开展测试。

 

5. 问:敏捷是否还是需要回归测试?

答:需要,回归测试仍然属于一个比较重要的环节,不管是敏捷还是传统的测试,只是由于敏捷测试中对时间的要求越来越高,使得本来需要大量时间的回归测试越来越难实施,所以目前的趋势是尽可能把回归测试用自动化测试来实现。对于我们公司而言,这也是一个方向,有些部分也在开始,但是由于产品逻辑比较复杂,很多功能有自动化测试实现会比较麻烦,所以现在我们的回归测试有相当一部分还是人工的方式,当然最终必然是会大部分采用自动化测试的。

 

6. 问:对于重复的Bug,怎么去处理?

答:其实我也咨询过不少公司,很多公司是不允许重复提交Bug的,所以提交之前需要先去确认是否其他人提交过,我相信这个确认过程应该会花费不少时间,不过对于开发而言应该会减少时间,因为不会出现重复的Bug;当然也有一些公司允许重复提交的Bug,原因也很简单,觉得对于Bug而言,只要是必须修的,发现了就得提,别人提过当然最好,但是就怕别人没提过,你却认为提过就不提了,最后客户发现就惨了。所谓“宁可错杀一千,不可放过一个”就是这个道理了,呵呵。我们公司是允许提重复Bug的,当然是在不知道有其他人提过的前提的,你如果已经知道别人提过了,当然就不能再去提了。

 

敏捷测试差不多就讲到这里了,也许有人清楚有人迷惑,水平有限,也没法讲得太好,望见谅。如有问题,可以私聊。谢谢大家一直看完!

 

 

(全文完)

 

 

 

你可能感兴趣的:(测试,单元测试,敏捷,任务,报表,产品)