1、定位bug产生的过程
测试用例的执行，基本上是程序运行过程bug产生的开始，若测试结果与期望结果有出入，即出现了错误征兆，定位bug过程首先要找出bug产生的原因，然后对bug进行修正。因此定位bug过程有两种可能：一种可能是找到了bug产生原因并提给开发去纠正；另一种可能是测试过程中程序产生的bug原因不明，测试或开发人员只得做某种推测，然后再设计测试用例证实这种推测，若一次推测失败，再做第二次推测，直到发现并纠正bug。
定位查找bug是一个相当艰苦的过程，究其原因除了开发人员心理方面的障碍外，还因为隐藏在程序中的错误具有下列特殊的性质：
(1)错误的外部征兆远离引起错误的内部原因，对于高度耦合的程序结构此类现象更为严重;
(2)纠正一个bug造成了另一bug现象(暂时)的消失;
(3)某些bug征兆只是假象;
(4)因操作时疏忽造成的某些bug征兆不易追踪;
(5)bug是不是程序引起的;
(6)输入条件难以精确地再构造(例如，某些实时应用的输入次序不确定);
(7)bug征兆时有时无，此现象对嵌入式系统尤其普遍;
(8)bug是由于把任务分布在若干台不同处理机上运行而造的。
在软件bug定位过程中，可能遇到大大小小、形形色色的问题，随着问题的增多，测试人员的压力也随之增大，过分地紧张致使开发人员在解决一个问题的同时又引入更多的新问题。
尽管查找bug，定位bug不是一门好学的技术(有时人们更愿意称之为艺术)，但还是有若干行之有效的方法和策略，下面介绍几种bug定位方法。
2、定位方法
无论采用哪种定位方法，目标只有一个，即发现并排除引起错误的原因，这要求测试人员能把直观想象与系统评估很好的结合起来。
常用的定位策略分为三类：
①原始类(brute force)
②回溯类(backtracking)
③排除类(causeeliminations)
原始类定位方法是最常用也是最低效的方法，只有在万般无奈的情况下才使用它，主要思想是“通过计算机找错”。例如输出存储器、寄存器的内容，在程序安排若干输出语句等，凭借大量的现场信息，从中找到出错的线索，虽然最终也能成功，但难免要耗费大量的时间和精力。
回溯法能成功地用于程序的排错。方法是从出现bug征兆处开始，人工地沿控制流程往回追踪，直至发现出错的根源，不幸的是程序变大后，可能的回溯路线显著增加，以致人工进行完全回溯到望而不可及。
排除法基于归纳和演绎原理，采用“分治”的概念，首先确定所有与bug出现有关的所有数据，设想一个导致bug的原因，用这些数据证明或反驳它;或者一次列出所有可能的原因，通过测试一一排除。只要某次测试结果说明某种假设已呈现倪端，则立即精化数据，乘胜追击。
上述每一类方法均可利用一些测试工具，开发工具。目前，调试编译器、动态调试器(“追踪器”)、测试用例自动生成器、存储器映象及交叉访问示图等到一系列工具已广为使用。然而，无论什么工具也替代不了一个开发人员在对完整的设计文档和清晰的源代码进行认真审阅和推敲之后所起的作用。此外，不应省略掉代码走查过程中最有价值的一个资源，那就是开发小组中其他成员的评价和忠告，正所谓“当事者迷，旁观者清”。
前面有提到，修改一处老问题可能引入几处新问题，有时程序越改越乱，但若能做到每次纠错前都扪心自问三个问题，情况将大为改观：
①导致这个错误的原因在程序其他部分还可能存在吗?
②本次修改可能对程序中相关的逻辑和数据造成什么影响?引起什么问题?
③上次遇到的类似问题是如何排除的?为什么这次又重新出现了？
文章内容略有作修改，引自http://wenku.baidu.com/view/543a89cf482fb4daa48d4b49
