二、定位问题

1、定位问题的好处

发现问题之后，帮开发人员定位问题原因的好处多多，这是肯定的，1.提高自己的能力；2.对被测系统的实现更了解；3.不会因为环境问题而提交不是 BUG的“BUG”；4.开发人员修改BUG的效率变高；5.满足了测试人员的好奇心（既然看到了程序中奇怪的地方，即使认为肯定不是程序的BUG，但是还是要去寻找奇怪现象的原因。这也是我个人认为测试过程中兴奋有成感的地方）。

举个例子，查询报表时数据出不来，寻找为什么会显示不出数据，以及如何才能显示数据的角度出发，从代码中理解该功能的实现原理，然后想办法让报表有数据产生，也许这的确是个BUG，等到你发现是BUG的时候，很有可能已经知道了BUG产生的原因，向开发人员提出时将非常具有说服力，即使不是BUG，也锻炼了你的学习能力和逻辑思维能力，对该功能设计也更了解了，搞不好还能设计出其他有效的测试用例和数据，何乐而不为呢？所以，当发现问题时，首先想到为什么会出现问题，然后去寻找答案，这样比单单提交BUG要有意义的多。还有，如果发现的问题的确对程序影响并不大，又理解为什么，这样更能理解开发人不修复该问题的理由，相互理解是良好合作的前提。

但是即使自己的编程技术超过了开发人员，也好不要给开放人员如何修改BUG的建议，这样会局限开发人员自己的思路，而且如果修改的不好，反而是测试人员的错。

2、DEBUG技术

当程序出现问题的时候，以我以往的解决这种问题的经验来看，单凭表面现象的提示信息是很难定位到问题原因的，因为可能程序中很多处的错误码返回都是这个提示信息，那怎么从这个相同提示信息定位到其中某个具体代码的位置呢？所以开发人员在自测的时候，会使用DEBUG来进行问题的定位，比如说写日志、标准错误输出、打印错误信息等等，其中有个很好定位的方法是输出问题所在源文件名和代码位置（在UNIX下的C编程中使用宏__FILE__和__LINE__），这样比提示信息要详细的多，

据我了解，UNIX下的C编程的程序，调试代码的方式无非是2个，1个是写（fwrite)日志文件中，另1个是printf出来，方法都是在程序运行时，将一些中间过程和中间变量实时的输出，根据具体的情况来增加新的输出语句，这样遇到问题时，能根据这些输出语句得到运行时经过的代码。

3、后台问题定位

当后台返回错误时，如何定位错误？下面是我的经验总结：

a.想办法让后台打印出调试信息，因为调试信息比错误日志更详细，开发人员可以从调试信息入手，我们也可以充分利用调试信息来帮忙定位问题。

b.从调试信息中，定位到具体的源文件

c.如果调试信息中有错误所在的行数，则直接定位到该行去检查，如果只有错误码，则根据错误码找出所有可能返回这个错误的多处

d.如果错误码出现的地方太多，而无法确定是哪一个，则加入printf代码到返回各个错误码语句的前面，要有所区别，使得可以得出程序运行时，执行了哪些语句，是返回了哪一行的错误码

e.如果能确定是哪一行返回的错误，则顺藤摸瓜，根据函数调用的关系，找到返回错误的原始语句（很有可能是个判断条件），这个时候还可以加 printf语句来帮忙定位（打印出其中一些重要变量的值），试着去理解出错处代码的功能意义，然后得出错误产生的原因。如果重要变量的值来自与共享内存或二进制文件，则去寻找是哪个程序同步到了共享内存或文件，追踪到该程序的同步代码或者是数据库中某表的某个字段。