敏捷测试理论以及实践（7）

敏捷测试理论以及实践（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的，当然是在不知道有其他人提过的前提的，你如果已经知道别人提过了，当然就不能再去提了。

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

　　（全文完）