07 · 测试 · 每次构建
手工点过的重放，下次合并不应该再靠记忆
自动化测试工程师守的是已经讲清的规则，不是把所有按钮都录一遍。第一次探索和文字是否读得懂，仍由手工完成。
- 提交 截单。 截单后同一门店再提交，断言状态仍锁定，不产生第二张单。
- 合并前 权限。 错误门店的账号被拒绝，响应里没有别人的数量。
- 夜间 回写。 模拟超时，本地状态保持待回写，库存不变。
自动化测试把回归从记忆里拿出来
规则已稳定的路径，下一周改个无关功能时可能被破坏。自动化测试工程师的特点是选择那些规则稳定、人工又容易漏的检查，收成构建的一部分。幂等、权限、状态机，适合自动化。经常改文案的营销页、还在争论的口径，不适合。他把断言写在业务结果上：流水行数、单据状态、是否产生外部单号。只断言页面上有「成功」两个字，文案一改就全红，真正的双记却断言不到。
他维护数据准备。用例自己创建单据并在结束时清理，不依赖昨天手工留下的那张单。依赖脏数据的自动化，红了也无法判断是缺陷还是环境。不稳定的用例他会停掉并标原因，不让团队习惯性重跑直到变绿。
和手工测试的边界
第一次探索、文字是否读得懂、工位屏站位，仍由手工测试和设计师完成。自动化不替代这些。它保证已经定稿的规则没有退步。失败时他提供请求号和响应，让开发能复现，而不是只丢一张截图。截图看不出重放了哪一次。
收进流水线的三道门
截单锁定曾经在 hotfix 里被改坏，因为当时只有手工记录。自动化测试工程师把截单重放、越权门店和回写超时收进合并前检查。有一次改动让超时分支又去增加订货数量，构建变红，没有进主干。这比上线后对账便宜。用例的准备数据用脚本生成次日订货，不借用生产拷贝里的真实会员。
用例数量不是成绩。三道门如果稳定地挡住错误，比三百个点按钮的脚本有用。每条失败留请求号和数据库断言。他每周看一次失败分类：真缺陷、环境、用例过时。过时的用例当天改或停。流水线里的测试数据每天重建。门禁失败时，合并页面必须让人看到是哪一笔业务失败：同一请求号产生了两行流水。看到这样的标题，开发会先查提交，而不是先点重跑。
截单用例自己拨测试时钟，不依赖谁记得去改服务器时间。权限用例自己创建只能看一家店的账号，跑完删除。回写用例自己造一张待回写，模拟超时时断言本地数量不变。三道门的数据准备都写在脚本里，换一台机器也能红在同一笔业务上。准备如果还靠手工留下的那张单，红了只能猜环境。他每周把失败分成真缺陷、环境和用例过时。过时当天改或停。通过率很高但没人说得出防了哪一笔账，等于没有门禁。第一次探索仍由手工做；自动化只守已经定稿、又怕被改坏的那三道。
经常改文案的营销页、还在争论的口径，不收进构建。断言写在状态和行数上，不写在「成功」两个字上。截图看不出流水有几行。失败标题写成业务句子，合并页上先看见哪一笔坏了，而不是一个红色阶段。红色阶段会诱导人先重跑。