一、发现问题
之所以是“发现问题”而不是“发现BUG”，是因为在确认是BUG之前，测试人员发现不正常的现象不可以武断的认为一定是BUG，因为很有可能是环境问题或自己对需求或设计有误解。
1、发现问题的心态
测试过程中，如果有问题（可能是BUG）产生，我第一个想到的是为什么会这样，单靠我自己实在是解决不了这个问题的情况下，我这才去问开发人员，而且不是提交BUG的方式，而是抱着一种学习的心态的去请教他（请教问题比直接提出BUG要委婉的多，即使我能明确一定是BUG，而且连BUG产生原因都已经知道，但在我和开发人员沟通时，都尽量让开发人员自己发现原来这是个BUG，需要修改，而不是我提出来的。）。总之，在测试过程中，发现BUG反而不像是我的目的了，测试目的更像是去探索一个陌生的事物，因为我始终认为开发人员身上有很多值得学习的地方。
2、静态测试发现，动态测试确认
使用静态白盒测试发现了一个BUG，然后用动态测试的方法暴露出这个BUG，这个是否可以称为错误推断？和黄某讨论之后得出结论，应该不属于，用动态的方法去显示，只是更具有说服力（实际上，是因为静态的方式让我更有把握认为这是个BUG），让开发人员清楚的看到的确是BUG。错误推断，只是一种经验，凭经验认为某个位置或某段代码可能产生问题，然后用某种手段去试。
那么如何提交这种BUG呢？首先向开发人员描述问题的现象，等他理解错误现象之后，再以猜测的方式告诉他错误可能出现的代码位置和原因（这样他就知道你在看代码进行测试，增加对你的信任度），这样就非常快的定位到BUG原因了，当然不排除自己推断错误的情况，所以是以猜测的方式告诉他BUG的出处，这样即使错误了，也会被原谅。
二、定位问题
1、定位问题的好处
发现问题之后，帮开发人员定位问题原因的好处多多，这是肯定的，1.提高自己的能力；2.对被测系统的实现更了解；3.不会因为环境问题而提交不是BUG的“BUG”；4.开发人员修改BUG的效率变高；5.满足了测试人员的好奇心（既然看到了程序中奇怪的地方，即使认为肯定不是程序的BUG，但是还是要去寻找奇怪现象的原因。这也是我个人认为测试过程中最兴奋最有成就感的地方）。
举个例子，查询报表时数据出不来，寻找为什么会显示不出数据，以及如何才能显示数据的角度出发，从代码中理解该功能的实现原理，然后想办法让报表有数据产生，也许这的确是个BUG，等到你发现是BUG的时候，很有可能已经知道了BUG产生的原因，向开发人员提出时将非常具有说服力，即使不是BUG，也锻炼了你的学习能力和逻辑思维能力，对该功能设计也更了解了，搞不好还能设计出其他有效的测试用例和数据，何乐而不为呢？所以，当发现问题时，首先想到为什么会出现问题，然后去寻找答案，这样比单单提交BUG要有意义的多。还有，如果发现的问题的确对程序影响并不大，又理解为什么，这样更能理解开发人不修复该问题的理由，相互理解是良好合作的前提。
但是即使自己的编程技术超过了开发人员，也最好不要给开放人员如何修改BUG的建议，这样会局限开发人员自己的思路，而且如果修改的不好，反而是测试人员的错。这里有两篇不错文章，推荐！
http://www.51testing.com/html/71/n-91571.html
http://bbs.51testing.com/viewthread.php?tid=5226
2、DEBUG技术
当程序出现问题的时候，以我以往的解决这种问题的经验来看，单凭表面现象的提示信息是很难定位到问题原因的，因为可能程序中很多处的错误码返回都是这个提示信息，那怎么从这个相同提示信息定位到其中某个具体代码的位置呢？所以开发人员在自测的时候，会使用DEBUG来进行问题的定位，比如说写日志、标准错误输出、打印错误信息等等，其中有个很好定位的方法是输出问题所在源文件名和代码位置（在UNIX下的C编程中使用宏__FILE__和__LINE__），这样比提示信息要详细的多，
据我了解，UNIX下的C编程的程序，调试代码的方式无非就是2个，1个是写（fwrite)日志文件中，另1个是printf出来，方法都是在程序运行时，将一些中间过程和中间变量实时的输出，根据具体的情况来增加新的输出语句，这样遇到问题时，能根据这些输出语句得到运行时经过的代码。
本文出自caicai1724的51Testing软件测试博客：http://www.51testing.com/?25347
3、后台问题定位
当后台返回错误时，如何定位错误？下面是我的经验总结：
a.想办法让后台打印出调试信息，因为调试信息比错误日志更详细，开发人员可以从调试信息入手，我们也可以充分利用调试信息来帮忙定位问题。
b.从调试信息中，定位到具体的源文件
c.如果调试信息中有错误所在的行数，则直接定位到该行去检查，如果只有错误码，则根据错误码找出所有可能返回这个错误的多处
d.如果错误码出现的地方太多，而无法确定是哪一个，则加入printf代码到返回各个错误码语句的前面，要有所区别，使得可以得出程序运行时，执行了哪些语句，是返回了哪一行的错误码
e.如果能确定是哪一行返回的错误，则顺藤摸瓜，根据函数调用的关系，找到返回错误的最原始语句（很有可能是个判断条件），这个时候还可以加printf语句来帮忙定位（打印出其中一些重要变量的值），试着去理解出错处代码的功能意义，然后得出错误产生的原因。如果重要变量的值来自与共享内存或二进制文件，则去寻找是哪个程序同步到了共享内存或文件，追踪到该程序的同步代码或者是数据库中某表的某个字段。
