上周跟在电商团队做测试的老陈吃烧烤，他半杯啤酒下肚就开始吐槽，说上个月刚上线的那套自动化测试套件，现在已经没人敢碰了。当初领导拍板要做，说要把回归测试的人力砍一半，组里两个同事熬了三周写了两百多个UI用例，结果这两周改前端布局，一百三十个脚本集体报错，光调元素定位的时间，比手动跑一遍回归还久。
先把投入的账算明白
很多人对自动化测试的认知还停留在“写个脚本自动点鼠标，以后就不用人测了”的阶段，根本没算过完整的成本账。写一个稳定、可维护的自动化用例，花的时间往往是写手动测试用例的三到五倍——你得考虑不同浏览器的兼容性，得处理随机弹出的登录框、广告弹窗，得适配不同分辨率下的元素位置，还得给脚本加异常捕获，不然哪天网络波动，脚本报错你都不知道是业务出了问题，还是网断了。
很多团队立项的时候，只会算“上线之后每次回归能省多少人天”，从来不算前期写脚本的时间成本、后期每次迭代要跟进调整的维护成本，更不算脚本失效之后排查问题的隐形成本。不要为了自动化而自动化，这话说出来容易，真落到项目上，十有八九的团队会忽略这一点。
之前帮一个团队算过一笔账，10个测试人员的规模，要把核心业务的自动化覆盖率做到70%，至少要抽两个全职的人专门负责写脚本、调脚本，这两个人一年的人力成本，比他们能省下来的回归测试人力成本高了快一倍。算到最后，这钱花得还不如多请两个手动测试，能测更多边缘场景。
这些场景碰了就是亏
不是所有测试场景都适合自动化，有些场景你硬往里塞，最后肯定是赔本赚吆喝。
比如快速迭代的新业务。刚上线的功能，每周都要改个两三版需求，你这周花三天写好的脚本，下周产品把整个交互流程换了，之前写的代码全得删，连个水花都溅不起来。我见过最夸张的一个项目，团队给新用户注册流程写了八层自动化校验，结果三个月后注册流程改成了微信一键授权，之前写的三百多行代码直接全进了回收站。
再比如临时上线的运营活动页。从开发到上线可能就一周，活动跑两周就下线，你花时间把活动页的测试流程写成自动化，刚把脚本调顺，活动都结束了。还有那种需要大量人工主观判断的场景，比如设计稿的颜色是不是准确，页面的动效是不是流畅，这些靠脚本根本测不出来，硬写的用例也只是凑数。
说句不好听的，太多团队为了给老板交差，硬把这些不适合的场景塞进自动化套件里，最后跑出来的结果一半是误报，大家看到脚本飘红都麻木了，真出了业务bug反而没人信。
能落地的都懂做减法
真正能长期跑起来的自动化测试，从来不是追求覆盖率有多高，而是盯着最痛的那个点下手。
比如做了五六年的成熟核心业务，像支付、下单、库存扣减这类链路，每次发版都要反复跑十几遍，流程半年都不会有大改动，这种场景写自动化就特别划算。而且别上来就盯着UI层写脚本，接口层的测试性价比远高于UI层——UI层的脚本要找按钮、输账号、校验页面显示，稍微改个元素id就报错，不如直接在接口层把参数、返回值、业务逻辑全校验了，跑一遍只要几分钟，还不容易失效。
还有个很多人踩过的坑：脚本的维护成本远高于编写成本。当初写脚本的人如果离职了，剩下的人根本看不懂那堆堆出来的代码，出了错也分不清是业务bug还是脚本本身的问题，最后这套套件就成了办公室里没人敢碰的电子摆设。所以真要做，就别追求大而全，先从最费时间的三个高频回归场景下手，写最简洁的脚本，让所有测试人员都能看懂、能自己调整，而不是把脚本藏在某个人的私有仓库里。
不过话说回来，自动化测试也不是什么洪水猛兽，我见过最聪明的一个团队，根本不追求什么覆盖率指标，就把每次回归里最容易漏测、最费时间的三个步骤做成自动化，每次发版前跑一遍，省下来的时间全用来测那些没人顾得到的边缘场景，效果比那些吹着90%覆盖率的团队好太多。
说白了，自动化测试就是个工具，跟你手里的鼠标、测试用例本没什么区别，能帮你省力气就用，帮不上忙就扔，别为了凑什么“技术先进”的名头，硬砸钱搞一堆中看不中用的东西。对吧？