做这个工作也有一段时间，总结几点经验，大家分享一下：
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、测试经验的总结
测试的过程很枯燥，而测试过程中发现的测试经验是十分重要的，不断的调整测试的策略、流程，多总结和借鉴别人的测试经验，会更好的提高测试质量。
以上是个人意见，供大家分享
文章来源于领测软件测试网 https://www.ltesting.net/
