回归测试（regression testing）是指在系统改动后，重新验证原本正常的功能，确认它们依然可以正常使用。“回归”指的是原本正确的功能在更新后出了问题，而出问题的位置往往不在这次计划改动的范围内。对企业来说，可能是预约确认页不再显示、某个浏览器无法登录，或者报表合计突然出错。
为什么没改动的地方也会出问题
业务系统由多个相互关联的部分组成。一处小改动的影响，可能比预想的更广：
- 代码共用：负责日期格式或价格计算的同一段代码，可能被多个页面调用。为一个页面修复它，另一个页面的结果也可能随之变化。
- 数据结构变化：新增字段、修改状态名称或调整数据库规则，都可能影响读取同一批数据的报表、导出功能和系统集成。
- 依赖项更新：代码库、框架、浏览器和手机操作系统都会更新，现有代码的表现可能因此改变。
- 外部服务变化：支付、消息或 ERP 系统可能更新 API 或运行方式，与之对接的部分就需要相应调整。
只测试新功能，发现不了这些连带影响。回归测试关注的是原本已经正常的部分。
回归测试检查哪些内容
回归测试会重复执行一组约定的步骤，并将结果与预期结果对比。最值得纳入的，是对业务和用户影响最大的流程，例如：
- 登录和重置密码；
- 提交表单、预约或订单，并收到确认；
- 角色权限，例如确认员工账户无法进入仅限管理员使用的页面；
- 涉及金额或库存的计算，例如价格、折扣或余额；
- 与其他系统之间传递的数据。
以下示例仅用于说明：团队调整预约页面布局，加入一个促销横幅。横幅显示正常，但在较小的屏幕上，这次改动让一个按钮错位，用户无法再点击。如果有一项回归检查会在手机屏幕尺寸下走完整个预约流程，就能在客户遇到之前发现这个问题。
手动与自动化回归测试
回归测试可以由测试人员按书面清单逐步执行，也可以由自动化脚本在浏览器或手机 App 上重复同一组步骤。两种方式可以配合使用。
- 手动检查适合经常变动、需要人工判断或很少执行的流程。效果取决于测试人员是否有足够时间，以及每轮是否按相同步骤执行。
- 自动化检查适合稳定、重要且需要反复执行的流程，例如每次发布前都要检查的步骤。它每次以相同方式运行，并能保留截图和步骤日志等证据；但当流程本身有意调整时，测试脚本也要同步更新。
不少团队会先为最重要的流程整理一份简短的手动检查清单，再把重复最频繁的部分自动化。
从哪里入手
测试每一个页面和按钮，通常并不现实。更可行的做法是：
- 列出关键流程：也就是一旦失效，就会导致销售、预约、支付或日常运营中断的步骤。
- 写明每一步的预期结果，让“正常”有清晰的定义。
- 准备安全的测试数据和账户，避免检查时产生真实订单、发送真实消息或涉及真实资金。
- 确定执行时机：每次发布前、依赖项或系统集成更新后，以及在约定的情况下，在生产环境按计划执行非破坏性检查。
- 约定由谁处理失败结果，以及通过什么方式通报。
回归测试的局限
回归测试通过，只说明被检查的步骤在测试环境中符合预期，并不能证明系统没有任何缺陷。回归测试也不能替代安全、性能、无障碍或易用性测试，这些都需要各自的方法。应把它看作多道防线中的一道，并在系统变化时重新评估测试范围。
如果系统已有支持安排，可以在软件支持 SLA 中写明发布前会重新检查哪些流程。连接多个系统的项目，也应在每个集成点加入回归检查，可阅读系统集成说明。
如需了解服务范围，可以查看 technine.io 的自动化 UI 及用户流程测试服务。
常见问题
回归测试和新功能测试是一回事吗？
不是。新功能测试确认新增的行为是否正确；回归测试确认原有功能在改动后是否依然正常。一次发布通常两者都需要。
回归测试应该多久执行一次？
至少应在改动上线给用户之前执行。不少团队在更新代码库、平台或外部服务后也会再执行一次。合适的频率取决于系统改动的频繁程度，以及故障可能造成的损失。
中小企业需要自动化回归测试吗？
不一定。如果系统很少改动，为几个关键流程准备一份书面清单可能就够了。当发布越来越频繁，或者同一组检查靠人工重复耗时太长时，自动化的价值会更明显。