关于如何做好回归测试，大体上的人都是认为是先验证bug，然后回归和本次修改相关的地方，但如何评估和此次修改相关的风险，这是一个相对重要且考验对系统认知度的问题。在我们平时的回归测试中，是如何做这一点呢?
(1)和项目中的开发以及项目负责人沟通确认。
这是一个很关键的环节，好的开发人员在提交测试时就会注明可能影响的地方。
(2)关键点的测试。
就是很重要的部分，即使看着和本次修改无太直接关联，也最好能走一下基本流程。因为这是客户最关心的地方点，也是盈利的所在。比如测试的重点：bug修改，关联功能，新增加功能，修改功能呢个，上一轮测试bug多的功能。(测试人员要了解开发在这一轮修改了哪些bug，要注意 (3)对开发人员能力的评估。
好的开发人员，修改缺陷时，会修改过程中注意对其它地方的修改。但能力不足的开发人员可能考虑较少。导致修改后，引起的2次bug较多，这个时候就需要加大测试力度，可能的话要整个模块基本功能进行回归。
(4)项目初期对测试用例的维护。
一个项目在开始时，编写测试用例时往往是对这个系统全面了解的过程，这个时候时间也较为充裕，所以写测试用例时，尽可能标注关联测试用例。这在大型项目里是尤其重要的。
(5)变换测试人员，回归比较繁琐，可以通过测试人员的轮流进行减轻一个人做回归的厌倦。
