软件测试过程中的开发过程总结

最近公司的产品一直忙于测试，看着每天的Bug不断的增加和修正，真是痛并快乐着，痛苦是因为Bug不断的出现，快乐是看着Bug一个一个的被消灭，把这些天的测试开发过程总结一下。

1、测试要尽早

        公司的产品已经修订一段时间了，但是由于任务繁忙和人手不足，因此测试一直拖后，因此当进行集中测试的时候Bug集中爆发，因此感觉更加的繁忙，另外由于很多功能和修订，都已经修改了很长的时间，因此程序员再次进入修改的时候，往往需要重新分析和理解，造成Bug的修复周期延长了很多。

        建议当完成功能修订后，要尽快进入测试状态，以缩短Bug的存在时间，降低程序员修订成本。

2、使用好的缺陷管理工具

        之前公司只是使用一个BBS作为缺陷的跟踪和管理工具，但是，效果很不理想，虽然缺陷管理的工具很多，但是都有自己的长处和短处，后来使用了TD，效果的确好的多。

3、缺陷描述要准确

        很多测试人员反馈的缺陷，程序员读起来十分的费劲，甚至比理解缺陷本身还要难懂，因此，如果缺陷后，在登记的时候，一定要尽量描述准确和清晰，以免造成错误的理解，反而更加干扰缺陷的修订。如果缺陷的确很难描述，可以将缺陷的发生过程录制下来，或者干脆手工给程序员演示一遍，效果就更好了。

4、缺陷描述不完整

        很多缺陷都是有前世和今生的，因此把缺陷产生的出发条件描述的完整，对解决缺陷起着很重要的作用。

5、缺陷要分等级

        缺陷都是要优先级别的，严重的当然要尽快解决，低级别的放一放。

6、开发和测试最好不同步

        公司是早上8：30上班，一般是9：00左右才能给测试部一个新的测试版本，而如果Build出现意外，则新的版本发布就会推迟，因此开发和测试一定要有个时间差，开发部最好在早上第1时间给测试部一个最新的测试版本。一种是开发部早点来，一种是晚点走，最后我们的约定是下午4:30分开发部Build版本给测试部明天使用。

7、优先验证Fixed状态的缺陷

        测试部每天最优先的任务就是验证新版本中Fixed状态的缺陷是否正确，这个很主要，因为开发部刚刚修正，如果没有验证通过，程序员可以立刻进行修订，如果过了很长时间才通知没有通过，那么可能程序员还得重新理解和分析代码。

原文转自：http://www.ltesting.net