3、 回归与更改点有关的基本功能，用户常用功能或操作；

　　3、 开发人员在修改bug状态的时候，要注明修改了哪个模块的哪些函数，这些信息有助于懂代码的测试人员去分析判断该bug是否真的修复好并对系统产生哪些影响。

　　测试人员:

　　4、 开发改好BUG后，先在开发环境下自行调试，然后安装版本到真实环境下，对更改点进行确认及按更改点影响到的功能点进行smoking test。控制好提交测试的版本，不出现影响测试进度的低级问题，如执行正常功能时失效，死机等。

　开发解决了一个BUG，但同时引入了新BUG，测试人员在回归BUG时没有及时发现，这就叫回归不充分。这种现象不管对开发人员，还是测试人员都是相当痛心疾首的事。该如何彻底解决此类问题呢？有如下建议：

　　1、 首先开发解决问题时，须全面考虑，把更改方案记录来，并作好更改的影响分析，包括此更改对本模块、其他模块的影响，提出对测试的建议。

　　2、 在故障库上的BUG解决说明中附上更改说明及对测试的建议，对测试很有用，时间长了，需要时追溯起问题来特别有用。

　　2、 及时更新测试方案与测试用例，严格按用例执行；

　　5、 测试人员主动找开发人员、需求人员沟通，加深对系统业务，设计原理的理解，可以就回归BUG的测试点或测试路径与开发一起交流，扩展或缩小回归路径；

　　4、 在故障库的“验证记录”中列出所有回归的路径及内容（即bug回归路径的测试用例简述）；

　　以上步骤都已完成，问题不再出现，验证通过，关闭此问题，置“关闭”状态。

　　6、 测试技术经理或主管对测试回归充分性进行监督与审核（回归不完善可能引发出系统严重问题，,故障库上留下的回归信息也方便项目组其他相关人员分析）。

　　开发人员：

　　1、 熟悉系统，各模块的关联关系，更改点会影响到的地方作好用户层的影响分析；

　　关键点：解决BUG的彻底性，回归BUG的全面性，与解决BUG的开发人员，回归BUG的测试人员对系统业务、软件系统逻辑的熟悉程度有很大关系。