社区修理站准备上线预约表单。需求规定每个场次最多接收八件物品，每人每场可登记一件，开场前两小时停止在线预约。验收人员可以让 AI 草拟用例，但必须交付三样东西：可回查需求的用例表、覆盖边界和异常的补充清单，以及可重复生成的测试数据。以此判断下一版改动是否破坏了已有行为。
从需求文档提取可以验证的规则
先固定需求版本，给每条规则编号。比如 R01 是场次上限，R02 是同一人每场限一件，R03 是预约截止。让 AI 为每条规则提取输入、系统状态、用户动作和可观察结果。若需求只说“人满时提示”，把提示出现的位置和内容是否有约束标为待确认。测试人员可以先验证请求被拒绝且名额保持不变，具体文案等产品负责人确认。
要求输出可直接执行的用例表，包含编号、需求编号、前置状态、输入、动作、预期页面反馈和预期记录变化。以 R01 为例，准备剩一个名额的场次，使用新测试账号提交，预期获得确认编号、剩余名额归零。再次使用另一个账号提交，预期拒绝且数据库或获准的后台查询仍显示原有八条有效记录。记录检查方式，避免把“显示成功”误当成实际写入。
需求转换类技能适合整理规则与用例映射。输入前确认支持文档的实际格式，尤其检查扫描 PDF 是否有可用文字、表格脚注是否被提取。先给一小段规则和两条人工用例做样例，检查生成结果能否回链。若团队用思维导图审查分支，可导出用于评审，同时保留具备用例编号的可执行表，方便和缺陷记录对照。
把正常路径扩展到边界与异常
对容量分别安排零条、七条、八条记录的场次。重点检查第八条能否成功、第九条能否被拒绝。让两个测试账号同时抢最后一个名额，预期恰好一个成功。测试截止时点要固定时区和测试时钟，分别检查前一秒、恰好截止和后一秒。如果规则没有明确“恰好”是否允许，留下需求问题，不直接猜一个结果作为发布门槛。
再把预约看成状态变化。待提交、已确认、已取消都应有明确的允许动作。例如取消后容量是否释放，重复点击取消是否再次释放，取消后能否重约。对弱网和重复点击，检查页面和后台是否都只有一条有效登记。若只有前端弹窗能看见，记录这个用例只能验证页面反馈，另安排接口或后台核对状态。
测试设计能力适合提议等价类、边界值和状态转移。把每条新增用例关联到它区分的故障，避免把同一分支用十种近似输入重复执行。在获准的测试站点，用关联的 Webapp Testing 执行页面用例，输入测试网址、虚构账号和预期反馈，保存失败截图与复现步骤。并发和后台记录应由有相应访问权的测试环境另外核实。
造数时同时设计复跑与清理
把数据拆成账号、场次和预约三张表。给每轮加运行标记，先创建账号和场次，再生成关联预约。可给一组场次配置七条有效预约、另一组配置八条有效预约，第三组包含已取消记录。检查数据只覆盖测试环境的编号范围，确认脚本不会触发正式短信。格式校验用的联系方式采用团队批准的测试值，避免生成可能联系到真实人员的号码。
如果需要批量生成，写清字段格式、引用关系、总量、随机种子和异常值占比。先用少量记录验证导入，再扩大规模。生成后对账每个场次的有效人数、唯一账号和孤立引用数量。清理按运行标记执行，只删除本轮生成的记录，并先查看将影响的条数。容量边界数据适合固定维护，压测用数据单独生成，避免一次随机变化就使日常回归失去稳定基线。
一次改动怎样验收
修理站上线候补功能后，先重跑原有的第八条成功和第九条处理用例。产品负责人明确第九条现在应进入候补，不能占用正式名额。补充取消后候补转正用例，核对转正只执行一次，同时记录通知在测试环境中的接收情况。将旧用例的预期变更标在需求版本上，保留原结果，方便分辨行为变化和回归缺陷。
如果两个账号都收到成功提示，先暂停继续批量执行。保存请求时间、返回结果和场次编号，再核对正式登记数。若数据库仍只有一条，检查另一个页面为什么显示成功。若实际写入了两条，就用相同数据与两个同步请求复现。两种故障需要不同修复，也需要不同的回归证据。
常见问题
为什么生成了许多用例，覆盖还不全？
先检查每条规则有没有明确的通过和失败判据，再对照边界、状态迁移和失败恢复。缺了真实预期的用例先放在待澄清栏。以规则覆盖和风险优先级安排执行，避免用例数量掩盖未验证的并发或时间问题。
可以直接把真实预约表交给造数工具吗？
先制作能保留字段关系和分布的合成样例。确认运行位置、连接目标和通知设置。需要复现生产问题时，只提取经过授权且足以复现的条件，例如容量、预约时间顺序和状态，使用新的虚构标识构造用例。
测试页显示通过，为什么发布仍需要复核？
先看通过的是哪一层。页面验证可以确认反馈和可见状态，接口或后台检查才能确认写入与名额对账。对实际会影响预约的路径，两个层面的结果应能互相解释。测试站点用的时间、语言与权限也应记录，方便判断结果适用于哪个发布环境。