手工回归测试还有必要吗
最近和一个做前端的朋友吃饭，他吐槽说公司新来了个技术主管，一上来就砍掉了所有手工回归测试环节，说“都自动化时代了，谁还手动点页面？”结果两周后线上出了个低级 bug——用户登录后头像不显示，原因竟是接口字段名拼写错了。这问题其实在提测第一天就能发现，但因为没人手动过一遍核心流程，愣是等到用户投诉才暴露。
这事儿让我想到，现在很多人觉得自动化测试能解决一切，手工回归成了“落后”的代名词。可现实真这么简单吗？
自动化不是万能的
自动化测试确实高效，尤其适合重复执行的场景。比如每天构建后跑几百个用例，机器几秒就完事。但它的前提是：用例得写对，规则得明确。可很多业务逻辑是模糊的，比如“页面看起来要正常”，这种主观判断，目前还没法靠脚本搞定。
再比如，某个按钮点击后应该弹出提示并跳转，自动化可以验证跳转是否成功，但弹窗样式错位、文字重叠这类问题，往往需要人眼才能发现。我见过一个案例，自动化跑得绿油油，结果上线后用户反馈“页面乱成一团”，就是因为 CSS 加载顺序变了，而脚本根本不检查视觉。
手工测试在关键节点不可替代
尤其是版本发布前，哪怕自动化覆盖率高达90%，我还是建议安排一次简短的手工回归。重点走核心路径：登录、下单、支付、退出。这些流程一旦出问题，直接影响用户体验。
有个电商项目，每次大促前都会组织“人工巡检”。十几个人同时操作不同角色账号，在预发环境快速过一遍主流程。虽然耗时不到一小时，但几乎每次都能揪出一两个漏网之鱼。有一次，一个优惠券叠加逻辑的 bug 就是这么被发现的——自动化用例没覆盖这个组合，但真人测试员顺手试了下就崩了。
什么时候可以减少手工投入
如果产品已经非常稳定，核心功能多年不变，且自动化体系健全，那可以大幅压缩手工回归的范围。但新产品、频繁迭代的项目，完全依赖自动化风险太大。
另外，团队刚起步做自动化时，别急着砍手工。先把高频、稳定的场景覆盖好，再逐步过渡。不然就是“脚没站稳就学跑步”，摔跤是迟早的事。
说到底，手工回归测试有没有必要，不看趋势，看实际。工具是为人服务的，不是反过来。该点的页面，还是得亲手点一下，心里才踏实。