如何准备自动化验收测试？

判断“能用”需要共同标准

某项自动化读取文件并生成报价表。开发者在屏幕上看到结果，认为工作已经完成，企业却发现少了几行。双方对同一结果作出不同判断，是因为一开始没有约定验收标准。验收测试用双方都能核查的方式说明：哪些输入应产生哪些输出。这样，交付讨论就不再只靠印象。

不要等软件完成后才开始测试，应在设计流程时就着手准备。与业务负责人建立一个小型样例数据集，并手动说明正确结果。写明报价计算应读取哪些字段、什么时候跳过记录，以及哪些操作需要人工批准。让开发者使用同一组示例，之后就更容易判断新发现的情况属于范围变化，还是违反了已有规则。

选择有代表性的数据

只测试规范记录很简单，但日常工作并非如此。样例应包含空字段、重复记录、错误日期、意外字符和同名的不同客户，并说明选择每个示例的原因。不要不必要地把真实个人数据搬进测试环境。制作代表性数据时，应保留真实系统的字段长度与格式，使样例接近应用将遇到的情况。

文件行数不能单独证明正确性。还应检查源字段与目标字段的对应、合计计算方式，以及无效记录保存在哪里。跳过记录的原因应可查看。重新运行流程不能把同一记录创建两次。可以与开发者共享部分样例，另留一部分用于交付检查，但所有预期仍须基于明确的业务规则。

写下预期结果

每个测试条目应包括场景、输入、操作、预期输出和实际结果。例如，没有产品代码的记录可能应进入待审核清单，而不是生成报价。预期结果还要解释错误信息的含义，让用户知道该修改哪个字段。防止错误操作与生成正确输出文件一样，都是验收的一部分。

在舍入、日期和文本比较上避免模糊表述，用具体示例展示业务负责人认可的规则。价格来源或不同货币的处理方式未明确时，测试结果也无法正确解释。如果软件无法决定时必须停止或转交有权处理的人，应单独测试这种行为。凭猜测继续执行，并不适合所有流程。

不要遗漏错误和中断场景

写清文件缺失、网络断开或外部服务不响应时应该怎样处理。操作完成一半后重启，会不会破坏之前的记录？用户能否看到错误？操作日志是否显示哪些记录已完成？这些问题不仅测试成功路径，还检查企业是否保有控制权。中断试验应在不会产生真实业务操作的测试环境中进行。

恢复计划也要具体。产生错误输出时，源数据是否保留，旧结果能否归档，哪些步骤可以撤销？对于不可逆操作，应考虑在自动执行前设置人工批准或单独检查点。明确标注测试记录只是示例。向真实客户发送试验通知，或启动真实付款，都不是验收测试的合适捷径。

把权限和用户流程一起测试

只用管理员账户测试可能掩盖普通用户遇到的问题。应使用相关角色检查可打开的页面和可执行的操作。未获授权的用户不仅不应看到按钮，也必须无法实际执行操作。在报告中记录测试使用的角色，否则不能假设某角色的成功结果适用于其他员工。

从头到尾跟踪用户步骤：选取数据、预检查、运行、查看结果、处理例外。如果其他应用将使用自动化输出，也要测试传输过程。文件成功生成可能还不够。业务负责人能否在日常工作中使用结果，并识别错误输出？围绕这些交付点定义自动化工作流程。

让交付报告支持决策

测试结束时，分别列出通过、失败和未执行的场景。对于剩余错误，说明影响、临时解决办法和重新测试的条件。不要把尚未解决的情况算作成功。业务负责人应能据此决定接受交付或要求修改。记录版本、测试日期和数据集，也便于确定新版本需要重复哪些检查。

首次验收后，每个小改动未必都要求重测整个系统。重新执行与变更规则相关的测试和核心流程即可。以前通过的结果不是新版本的证据。数据类工作中，应将批量数据传输与记录对比一起考虑。一组规模小、清晰、可重复的测试，可以逐渐成为企业变更控制的一部分。

注意：演示不等于验收

预先制作的视频中流程顺畅，不能代替真实验收测试。测试必须能使用确定的版本和数据重复执行。如果有性能要求，应说明环境与测量方法，不要承诺未经验证的耗时或成功率。目的在于明确交付边界、记录企业认可的行为，而不是宣称完美。

完成后，把使用的示例与最终决定保存在一起，让下一位同事理解为什么选择这种做法。与负责人共同澄清不确定之处，不要隐藏问题。一次小规模实践可能比一份看似全面却无人使用的文档提供更多信息，再通过定期反馈改进这次实践。

常见问题

第一步是什么？

选择一项真实任务和一个有代表性的示例，说明预期结果。

由谁核验？

流程负责人应与使用应用的员工共同检查。

什么时候更新？

流程或应用发生变化时，重新核验受影响的步骤。