验收用例要能被别人重复执行
请 ChatGPT 生成验收测试时，先给已经确认的规则和界面范围，要求每条用例写前置条件、输入、操作、预期结果。本文是自拟器材借用表单：课程成员可一次借一件，编号不能为空，申请成功后显示申请编号；借用规则与画面都是演示材料，本站没有真实系统可测，也没有实际通过记录。
将规则变为可判定的预期
[R1] 已登记成员可提交；未登记成员不可提交。[R2] 每人同时只能有一件未归还器材。[R3] 器材编号必填。[R4] 成功提交后显示申请编号。材料没有写错误提示的精确文案，也没说明申请编号的格式。因此用例可以预期“阻止提交并提示原因”，但不能要求一条自造的文案或编号前缀。
先用正常路径确认系统的主要用途，再故意触碰每个边界。若规则R2说的是“同时”，测试数据应覆盖已有一件未归还和已有一件已归还，不能把“曾经借过”一概禁止。
四条自拟参考用例
T1 正常：已登记、当前无未归还、器材编号X1；提交一次。预期系统接受并显示申请编号，申请与成员关联。这里编号的具体格式未知。
T2 资格失败：未登记、无未归还、编号X1；尝试提交。预期不创建申请并提示资格不足。必须检查后台是否真的没有新增记录，仅见页面提示不够。
T3 数量边界：已登记、已有一件未归还、编号X2；尝试提交。预期第二件不被接受。另设T3b：已有一件已归还，再申请X2，R2不应阻止，前提是其余条件符合。
T4 必填失败：已登记、无未归还、编号为空；提交。预期阻止提交并说明缺失编号。空格是否等同空值未在规则里确定，单列待确认，不把自己猜的清洗逻辑写成验收标准。
从“预期”到“实际”需另有记录
这些是测试设计，不是执行结果。真实执行时要记录环境版本、时间、输入数据、实际显示、后台记录和通过与否。T2、T3若页面显示错误但后台仍创建申请，仍应判失败。若申请编号出现但请求实际未保存，也不能只凭UI当作通过。
让模型自己检查用例是否只改动一个条件，避免一个失败同时包含“未登记”和“空编号”，导致无法判断是哪条规则起作用。需求改变后按编号重新审查相关用例，保留真实缺陷证据与复测日期。
交付前核查规则缺口
R1–R4没有规定提交重复点击、网络中断、编号不存在或权限跨账户的细则，不能因为这些很常见就自行写成“系统必须如此”。可以把它们列入待产品负责人确认的风险用例。分清已确认要求和待讨论要求，才能让验收用例有客观依据。