一、回归测试和确认测试的误区
其实我在之前的工作当中一直都经常说“回归测试”，基本上没有提到过“确认测试”。正式接触到“确认测试”还是从学习ISTQB认证开始。ISTQB基础级大纲中就提到了确认测试和回归测试的区别。
一开始我还很疑惑，难道回归测试不就是确认测试吗？回归测试不就是在确认bug修改有没有生效吗？但是，实际上大错特错。确认测试是在修复缺陷后，在软件的最新版本上，重新执行之前因该缺陷而导致失败的测试用例，来确认缺陷被解决。而回归测试是在确认测试完成的基础上，确保缺陷修复不会产生副作用，也就是说不会产生修改引入。
二、回归测试和确认测试的案例
案例一：
Bug概述：一个公司官网web页面，在介绍公司主营产品的页面出现了错别字，把“智能”显示成了“只能”。
针对这个bug，基于风险及改动大小进行初步判断，这个bug只是涉及到web前端显示问题，并且修改该bug只是需要把文案修正即可，不会涉及到代码逻辑或者底层函数的变动。所以，该bug可以只做确认测试即可。
不过，虽然不需要进行回归测试（重点指修改影响测试），可以针对这个错误，举一反三，进行扩展测试。因为“智能”这个用词可能是官网文案中的一个高频词，那么很有可能其他地方也出现一样的错误。
案例二：
Bug概述：一个公司官网web页面，用户进入商务合作页面，录入商务合作信息（例如，姓名、电话等）后，点击提交按钮，没有任何反应。
针对这个bug进行分析：该bug相关的模块为重点模块，且该bug明显是基本功能存在问题，影响重大。所以，一定要做回归测试。具体的回归测试用例可以结合bug根因和修改点进行输出。该bug的原因是Web前端发送接口请求，后端响应超时。那么，针对这个bug，我们不仅要进行确认测试（测试bug解决），还要进行回归测试（避免修改引入）。用例示例如下：
1）填写商务合作人员信息中的必填字段，然后点击提交按钮（确认测试）；
2）商务合作人员信息中的必填字段和选填字段都填写，然后点击提交按钮；
3）商务合作人员信息填写内容达到各个字段的最大长度，然后点击提交按钮；
4）商务合作人员信息填写内容存在特殊字符，然后点击提交按钮；
5）针对提交按钮调用的接口进行并发测试，观察记录接口响应时间。
三、回归测试和确认测试的应用场景
如果你是测试工程师，我相信你一定会经常遇到这种情况，领导说你问题单回归的太不充分了，没办法避免修改引入。那么，在这个场景下，一般是你虽然名义上做的是回归测试，但是实际上你可能只做了确认测试。
那么既然回归测试的测试覆盖大于确认测试，是不是任何时候都不能只做确认测试，一定要做回归测试呢。当然不是。
我觉得，这个主要是基于以下几方面考虑：
首先，评估bug修改的影响程度。如果改动大，影响到底层或者影响到系统框架，那肯定要做全面的回归测试，甚至要做详细的回归测试分析和测试设计。如果改动较小，就可以酌情只做确认测试即可。
其次，要评估bug涉及到的功能的重要性和使用频率。如果是核心功能模块，一定要做回归测试。如果是不常用功能模块，也可以酌情只做确认测试。
另外，负责修改bug的开发人员最了解bug的来龙去脉，所以，最好跟开发人员沟通交流，讨论bug的根因、修改方案及修改影响，结合开发人员的测试建议，再结合测试人员自身的经验，输出相关测试用例。这种回归过程是比较精准的一种回归测试的途径。
当然，什么时候选择确认测试类型，什么时候选择回归测试类型，很多情况下，会根据项目的整体情况，基于风险对回归测试做取舍，这不仅仅是技术层面的事情了，涉及到测试策略方面的调整。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
