1. 测试前细化需求，保证对需求理解正确，避免提交存在歧义的缺陷：
测试人员不能在测试时仅仅凭自己的经验、想法来随意提交缺陷，每个缺陷必须有对应的需求作为支撑。如果认为是需求存在歧义，这样的情况，应该是在测试前与项目组成员进行沟通，达成一致观点。尽量减少理解上的歧义，力争尽早消除无效或争议的软件缺陷。
2. 对于自己把握不准的缺陷，提交前进行讨论：
在测试过程中，特别是介入项目时间较短的测试人员，由于对业务或需求理解不深，很有可能遇到对缺陷把握不准的情况，这个bug是否该提交呢？这种情况，最好是跟有经验的测试人员或者需求人员讨论一下，在大家意见一致时再提交。否则，项目中出现了这样的bug，不仅很难说服开发人员去修改，还有可能让开发人员怀疑你的能力。
3. 在提交bug之前，一定要保证bug能够重现，并且在bug中清楚的描述重现步骤：
有些测试人员在一发现bug，就马上提交到缺陷系统，甚至连bug出现的环境，重现的步骤都没有搞清楚，结果到后来开发人员看不明白，自己也无法重现。这种情况出现多了，提交缺陷的认可度就会大大降低。所以，在提交bug之前，最好自己多次重现这个bug，搞清楚是在什么情况下，按什么步骤会出现这个问题（最好是找出重现 bug的最简单步骤），另外，一定需要有截图，让开发人员认识到这个问题的确存在，增强说服力，并且也让开发人员更加容易定位缺陷。
对于较难重现的bug，需要截图，并且说明在什么情况下出现的概率，最好是在保留测试环境的情况下，及时找开发人员跟踪，弄清楚原因。
4. 保证测试环境的准确性，并且做好版本的配置管理：
有些bug只有在测试环境中才可以出现，而在开发环境下是不能重现的。这样的缺陷很容易让开发人员认为是提交了无效的缺陷，实际上是开发与测试的版本不一致。对于这种情况，我们需要做好版本的配置管理，保证测试环境版本的正确，测试环境部署正确，以及测试环境的独立性。只有这样，才可以减少一些不必要的沟通，轻松说服开发人员修改bug。
（以上言论仅代表作者的个人观点，不代表51Testing观点）
版权声明：本文出自moonlike79的51Testing软件测试博客：http://www.51testing.com/?26944
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
