手工回归测试还有必要吗
最近在一家做电商系统的公司听到一个讨论：新版本上线前，要不要继续花大量人力去做手工回归测试？团队里有人觉得自动化已经覆盖了80%的核心流程，剩下的交给机器就行，人工点来点去太浪费时间。可上线后偏偏在一个优惠券叠加的场景出了问题——用户能同时用两张本该互斥的券，直接导致公司一天损失好几万。
这个问题出在哪？恰好就在那“不重要”的20%里，而那段流程，恰恰没人手工测到。
自动化不是万能钥匙
很多人一提回归测试，第一反应就是上自动化。脚本跑得快，还能7×24小时执行，听着确实高效。但现实是，很多业务逻辑复杂、交互多变的系统，比如金融审批、医疗挂号、会员等级变动，光靠自动化很难覆盖所有边界情况。
举个例子，一个后台配置改了默认值，前端原本显示“暂无数据”的地方变成了空字符串。自动化脚本可能只检查接口返回码和字段是否存在，根本不会发现这个视觉上的“小问题”。但用户会发现——而且会觉得系统“出bug了”。
这类问题，往往得靠人眼去看，靠经验去判断。机器知道“对不对”，但人知道“好不好”。
手工测试在关键节点不可替代
有些场景，自动化短期没法搞定。比如UI大改版，页面元素结构全变了，原来的定位方式全部失效。这时候重写自动化脚本的时间，可能比手工过一遍主流程还长。
再比如临时加的需求，开发下午5点提测，明天上午就得上线。这种节奏下，写自动化用例根本不现实。但产品老板还是会问：“你测了吗？”这时候，靠谱的手工测试人员半小时就能把核心路径走完，给出初步反馈。
还有探索性测试，完全依赖测试人员的直觉和创造力。比如模拟一个着急下单的用户，连点三下支付按钮，看看系统会不会重复扣款。这种“非标准操作”，脚本通常不会写，但真实用户天天都在干。
什么时候可以减少手工回归
也不是说手工测试就必须一直做下去。如果一个模块长期稳定、逻辑清晰、自动化覆盖率高，比如登录、注册、商品列表分页，完全可以交给CI/CD流水线自动跑，手工只在大版本时抽查。
我们见过做得好的团队，把手工回归拆成“高频+低频”两部分。高频部分（如购物车、下单）自动化覆盖，低频部分（如退款审核、权限切换）保留手工检查清单。这样既保证效率，又不漏关键点。
甚至有些团队用“手工测试探路，自动化收尾”的模式：新功能上线前，先由人工完整走一遍，确认流程通了，再补自动化用例，为下次回归做准备。
人的价值在判断力
自动化能跑1000条用例，但未必能发现一个颜色对比度不符合无障碍标准的问题。手工测试的价值，不在于“点得准”，而在于“想得细”。
一个老测试员看到表单提交失败，会下意识去看网络请求、看错误提示文案、看有没有日志上报；而脚本只会告诉你“断言失败”。前者能快速定位是前端校验漏了，还是后端接口炸了；后者只能等开发来查。
说到底，手工回归测试有没有必要，不取决于技术多先进，而取决于业务多复杂、变化多快。只要软件还在不断迭代，只要用户行为还充满不确定性，手工测试就不会彻底退出舞台。
它不再是主力，但仍是最后一道防线。