5.1节前忙测试

最近公司的产品一直忙于测试，看着每天的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状态的缺陷是否正确，这个很主要，因为开发部刚刚修正，如果没有验证通过，程序员可以立刻进行修订，如果过了很长时间才通知没有通过，那么可能程序员还得重新理解和分析代码。

8、一个缺陷报告包含多个缺陷

有些时候测试人员在一个测试报告中，包含N（N>=1）个缺陷，结果程序员修订了其中一个，另一个需要拒绝掉，结果缺陷的状态就失去效果了，因此一个缺陷记录只能包含一个缺陷，如果存在多个就是测试人员的责任了。

9、交叉测试的重要性

我们最初安排测试的时候，是某个测试人员只测试其中一部分，另外的测试人员测试另外一部分，过了几天后发现，每个测试人员的Bug检测数量都下降了，原来，测试人员对自己部分已经发现不出来缺陷了，后来采用了交叉测试的方式，就是测试人员交换测试工作，结果不同的人从不同的角度进行测试，结果一些缺陷又发现了，因此交叉测试很重要。

10、测试经验的总结

测试的过程很枯燥，而测试过程中发现的测试经验是十分重要的，不断的调整测试的策略、流程，多总结和借鉴别人的测试经验，会更好的提高测试质量。