回归测试
Regression Test
中级通用回归测试（Regression Test）是在代码或配置发生变化后，重新检查原本正常的功能是否仍然正常。它解决的是“修好一处、弄坏另一处”的问题，比如修改优惠券计算后，再检查订单总价和退款金额。
你可能会说：「我改了优惠券逻辑，想让 AI 帮我检查原来能用的下单和退款功能有没有被影响。」
读之前建议先了解
动手看看优惠券改动的回归检查
切换代码版本，再关闭并打开运行开关模拟重跑；展开金额核对，看同一套断言在两个版本里的结果。这里展示的是预设结果，不会执行真实代码。
优惠券修好了，退款却重复扣掉二十元。只验证修复点会漏掉它；重跑已有用例，才发现原本正常的功能被改坏了。
要点改完功能后，回归测试怎么做？
- 1
从改动影响范围选检查项
你改了登录状态的保存方式，就可以先查登录、退出和需要登录才能访问的页面。因为这些流程共用同一段状态逻辑，比把全站每个按钮都点一遍更容易找到相关问题。
- 2
用原有行为作为判断依据
回归测试关心的是旧功能有没有被意外改变。比如调整搜索排序后，我们仍要确认筛选条件能生效、翻页不会丢失条件；判断结果时，要对照已有需求或此前确认过的行为。
- 3
手动检查和自动运行都可以
一次回归测试可以是你手动走完购买流程，也可以是让测试脚本在每次合并代码时运行。重复频繁、结果容易判断的检查适合自动化；界面体验等问题仍可能需要人来看。
容易混淆的地方
回归测试说的是测试目的，不是测试层级：单元测试、集成测试和端到端测试，都可能用来检查改动有没有破坏旧功能。它也不等于冒烟测试；冒烟测试只想快速确认关键流程大体可用，回归测试则会围绕改动影响，检查已有行为是否保持正确。
什么时候用
适合用
- AI Agent 修改了购物车价格计算后，你想检查优惠券、运费和订单总价这些已有计算是否仍然正确。
- 团队升级登录依赖后，你想重新检查登录、退出和会话过期等已有流程。
- 修复一个线上 bug 后，你想确认问题不再出现，同时检查相邻功能没有被这次修复带坏。
不适合用
- 一个全新页面还没有确定该做什么、也没有可对照的旧行为时，先明确验收标准，再测试新功能。
- 网站刚部署完，你只想快速知道它能否打开、关键入口能否使用时，先做冒烟测试。
- 你想知道网站能承受多少人同时访问时，做负载测试；回归测试不回答容量问题。
练一练选一个答案，看看解释
你让 AI Agent 修改了后台的订单搜索接口。新搜索条件已经测试通过，接下来怎样检查这次改动有没有破坏旧功能？
让 AI 帮你做复制给 AI Agent 直接用
请为这次订单搜索接口改动做回归测试：先查看改动和现有测试，列出可能受影响的原有筛选、分页及详情入口；补充必要的测试并运行。请说明测试结果、未覆盖的风险，不要把新功能测试当作全部回归测试。