回归测试总结

 

在进行full regression testing之前，对以前的版本进行了Mini测试，这种测试需要执行的case非常少，每人只有几个case的任务量。

从7.31号开始到8.08号截止，完全回归测试的Case已执行完毕，比计划提前了一周时间。其间没有加过一天班，一般都能在下午5点以前完成当天任务。在测试开始的头几天，由于测试环境未完全配置好，导致测试进行得不太顺利，此后有了很大改观。

我做了什么

对于测试以及现在的项目，我是个新手，因此主要工作是执行Case，而且由于ID的问题，即便发现defect也不能由自己直接上报。

1.        分析cases。在测试之前分析即将执行的case，并做一些补充和修改。

2.        执行Case。分配任务37个，执行通过37个，失败1个，另有1个因为环境原因不能进行测试。

3.        发现Defect。在测试之前就发现1个页面错误，后经确认属于误保，因为测试环境是韩文，不是很理解一些文字的真正含义。后来测试新添加的功能，发现1个。另外也发现一个较严重的问题，页面上缺失了一个按钮，可惜超出我们的测试范围，让其他Team捡个便宜。

       跑了这么多Case，没有发现几个defect，实在有些令人沮丧。一本经典的软件测试书上讲，一个好的Tester不是发现最多的defect的人，而是督促developer更正defect最多的人。我现在还没有权限开defect，当然也没法去督促developer。那么衡量工作的原则就落在发现defect数量上。在任何时候，程序中始终存在defect，发现不了它意味着tester工作的失败。发现不了defect或者defect数量很少，是值得developer庆贺的事，但决不是tester该高兴的事！

       除了执行Case，我还做了另一些额外的工作，比如两次发现daily test report中的问题。其实我现在最想做的是，找到一种方法可以帮助发现更多的defect，以及改进team目前所采用的测试方式，提高整个team工作效率（如减少执行case之外的时间消耗）和质量（如发现更多的defect），尽量避免工作中人为的失误（一些工作由人手工来做，失误不可避免）。人为失误包括（这些都发生在实际测试过程中）：

1.        两人跑了同一个Case，或者跑错了Case。

2.        Team成员间信息沟通不够通畅。比如当A执行某个Case时，发生失效并找到defect，应该及时通知执行类似Case的人。还有，当defect被修复，也要及时通知defect reporter关闭defect。

3.        统计Case执行情况时数量上有出入，比如漏掉某些case。

4.        忘记更新test report的某些部分。

存在的问题

       第一次执行这么多case，担心在限定期限内完不成任务，所以一个劲地完全按照case描述的步骤来执行，这样可能忽略页面其他地方出现的错误。实际的测试需要执行的步骤比case里描述得应该要多些。

       对case的熟悉程度不够，制定的每天工作任务并不均衡。从这次测试中吸取到的一条经验是，在测试的最初阶段，由于测试环境未完全配置好，一些较复杂的case不能顺利通过或者要花很多时间才能通过，此时宜先执行较简单的case。

以后要做的事

       我们这个team的工作一直都不忙，最忙时要数full regression testing，但也不用加班。有很多的free time用来学习、研究自己感兴趣的问题和技术，部门经理和team leader对此很支持。我选择研究ODC（正交缺陷分析），目的是通过学习它，能帮助自己提高找到defect的经验和技能。遗憾的是，没有实践ODC的机会，只能在理论上做一些研究。

       上面提到了team在这轮测试过程中表现出来的一些工作失误，我认为这些失误其实都是可以避免的，方法即是采用某种tool来管理case。上周和leader谈到case management system，得到的信息是，自己去开发一个CMS并不受支持，原因有二：其一，现在一些tool有此项功能，其二，leader和老员工已经很熟悉case，并且习惯Excel 管理case的方式。尽管后者是低效且容易出错的。既然能拿到100分，为什么要得90呢？对此，我有两个对策，一是学习使用一种tool来管理case，二是开发个人版CMS。先提高个人的工作效率和质量，然后再影响其他人，最后推动整个team的改变。

       我还想做的一件事，是分析以前所有发现的defect，总结出一些可帮助在未来的测试中找到更多defect。

测试体会

       （1）在进行full regression testing之前，我就想到，目前的产品既然已经很成熟，那么defect可能较多出现在界面上，特别是显眼却常不被注意到的地方，其次是新添加的功能。从最后结果看，找到的defect可以分为三类：前面提到的两种情况，另加受新增功能影响的原有功能。

        （2）在测试的最初阶段，由于测试环境未完全配置好，一些较复杂的case不能顺利通过或者要花很多时间才能通过，此时宜先执行较简单的case。