近两周都在做回归测试，发现大的工作量是测试环境的恢复和新发现缺陷的定位。测试环境的恢复正在寻求好的解决方案，那么先总结下对于缺陷定位的思考和方法吧。

　　有一种心理暗示，不知大家是否认同。第一次测试一个系统，当发现了问题大多时候会第一感觉会是认为这是个缺陷，即使定位错误也许开发人员或其他成员会认为你由于对系统还不太熟悉，作为开脱理由。

　　回归测试却不同，至少已经完成了一轮以上的测试，这时候发现新的问题，尤其是与新版本新特性无明显关联的问题，一般情况下第一感觉会反思自己是不是哪里设置有误，这是个Bug吗？常会有这样的疑问。还会担心如果把错误的定位反馈给开发人员，会不会对自己产生不好的影响。

　　那么在回归测试中如何定位缺陷呢？

　　1、在旧的版本上验证：同样的数据和环境设置，执行旧版本的系统或软件，查看结果是否仍然有误。如果旧版本的结果是正确的，而新版本的结果是错误的，已经基本可以说明是新产生的缺陷了。当然还要排除新问题是由于新特性导致原来正确的数据或环境设置在新版本产生异常的情况。

　　2、查看系统日志：如果通过旧版本验证后还是不能确认，那么接下来查看日志。如果是计算错误类型的缺陷，尤其是复杂的计算过程，能否在日志中查到相应的过程及结果数据，只能凭运气了。基于此我建议测试人员可以提前提供给开发人员需要哪些关键的中间数据结果信息，在测试版本的系统日志中打印出来，方便测试人员查看。

　　3、反推法：适用于某些特性的测试，正确的数据设置产生了错误的期望结果，那么反之错误的数据设置会产生正确的期望结果。那么这时可以通过尝试不同的错误的基础数据设置，来寻求得到正确的结果。一旦得到期望的结果，可以通过与原有版本的基础数据设置来逐一对比，从而查找出是由于哪个错误的数据设置产生的问题。

　　4、查看或调试代码：保险的方法，但是有时常常由于某些原因而无法实现。比如测试客户方的系统，无法看到代码，或者测试人员的阅读代码能力有限。当然如果是我们实在无法确认的问题，可以交给开发人员来查看或调试代码。

　　缺陷定位中，有优势的是对于业务需求和系统架构能够充分掌握的测试人员，那么我们也可以来请教这样的人或者自己来努力成为这样的人。