一开始我还很疑惑，难道回归测试不就是确认测试吗？回归测试不就是在确认bug修改有没有生效吗？但是，实际上大错特错。确认测试是在修复缺陷后，在软件的新版本上，重新执行之前因该缺陷而导致失败的测试用例，来确认缺陷被解决。
而回归测试是在确认测试完成的基础上，确保缺陷修复不会产生副作用，也就是说不会产生修改引入。
首先，评估bug管理修改的影响程度。如果改动大，影响到底层或者影响到系统框架，那肯定要做全面的回归测试，甚至要做详细的回归测试分析和测试设计。如果改动较小，就可以酌情只做确认测试即可。
其次，要评估bug涉及到的功能的重要性和使用频率。如果是核心功能模块，一定要做回归测试。如果是不常用功能模块，也可以酌情只做确认测试。
另外，负责修改bug的开发人员了解bug的来龙去脉，所以，跟开发人员沟通交流，讨论bug的根因、修改方案及修改影响，结合开发人员的测试建议，再结合测试人员自身的经验，输出相关测试用例。这种回归过程是比较精准的一种回归测试的途径。
当然，什么时候选择确认测试类型，什么时候选择回归测试类型，很多情况下，会根据项目的整体情况，基于风险对回归测试做取舍，这不仅仅是技术层面的事情了，涉及到测试策略方面的调整。
推荐阅读：
sales@spasvo.com
