关于本文
本文是通过利用生成式 AI 的自动生成流程创建的。我们于 2026 年 11 月 3 日确认了微软官方资料，并梳理了从虚拟预订规范中构思验收测试的步骤。Copilot 的执行结果尚未经过验证。验证状态：📘 已确认官方信息，未确认提示词执行结果
首先通过 3 个操作进行尝试
打开组织允许使用的 Copilot Chat，并粘贴下方“从小型虚拟规范创建测试表”中的提示词。
在生成的表格中，确认人数的边界值“0、1、10、11”是否与 S4 的“未定义”被明确区分开来。
将 S1 的上限更改为“12人”，并在新的对话中进行测试，比较 12 人和 13 人的处理方式。
操作后请参考此处：期望整理出的结果为：0 人和 11 人超出条件，1 人和 10 人符合条件，重复预订 S4 则属于未定义。实际的 Copilot 输出尚未经验证，切勿将 AI 编写的预期结果作为已执行测试的通过记录。
| 确认要点 | 预期的变化 |
|---|---|
| 原上限为 10 人 | 10 人符合条件，11 人超出条件 |
| 更改上限为 12 人 | 12 人符合条件，13 人超出条件 |
| 未定义的 S4 | AI 不决定是否允许重复预订 |
对应环境、功能及限制事项（官方确认日期：2026年11月3日）
| 项目 | 本示例的对象与范围 |
|---|---|
| 产品与入口 | 面向工作场所的 Microsoft Copilot Chat（原名 Microsoft 365 Copilot Chat）。网页版的常规聊天场景 |
| 账户与合同 | 组织授权的工作账户。请确认您的合同和管理员设置是否允许使用。个人版 Copilot 不在本示例范围内 |
| 追加合同与计费 | 本示例不使用 Office 应用内的附加功能或按使用量计费的智能体。请勿理解为可以使用需要追加合同的功能 |
| 输入与保存位置 | 直接粘贴虚构的文本。请勿连接本地路径、OneDrive、SharePoint 或收件箱 |
| 尝试的操作 | 对输入的内容进行参考、整理、比较和草稿创建。内容需由人工与原文进行核对 |
| 本示例不包含 | 文件搜索、直接编辑/移动/删除文档、发送邮件、在业务系统中进行注册 |
| 上限与提供状态 | 不以预览功能为前提。未确认输入长度、次数、地区、界面差异的数值以及实际设备版本。长文本输入请分段，是否可用请以界面为准 |
| 信息管理 | 最初仅使用虚构数据。若要扩展至业务信息，请确认组织的许可和信息分类。切勿将提示词本身作为访问控制或停止网页搜索的保证 |
从规格备忘录创建测试项时，仅靠正常输入很难发现缺陷。另一方面，如果将未提及的行为设定为预期结果，测试就会变成在制定新规格。我们将让 Copilot Chat 分别列出可确认的预期结果以及需要确认规格的情况。
从简短的虚拟规格中创建测试表
目标是一个虚拟的设备预约表单。不访问实际界面，也不执行代码。这里制作的是测试设计的草稿。将输入值与预期结果并列，以便人工能够确认其与规格的一致性。
次の架空仕様だけから、受入テストの候補を作ってください。 列：ID／観点／入力／期待結果／根拠仕様／仕様確認が必要な点。 正常系、境界値、異常系を含めてください。 期待結果が仕様にない場合は「未定義」とし、動作を創作しないでください。 自動テストコードや実行済み結果は出さないでください。 S1：予約人数は整数で、1人以上10人以下。 S2：予約名は必須で、30文字以内。 S3：受付完了後、予約番号を画面表示する。 S4：同じ時間帯で重複予約できるかは未決定。
人数的一人和十人是允许范围的边缘。零人和十一人是范围外。预约名是比较三十个字符和三十一个字符的候选项。然而，仅凭此备忘录无法决定是否将纯空白输入视为违反必填项，也无法决定如何计算表情符号的字符数。
边界值不仅限于“上限”
边界值是指将允许范围的边缘与其正外部进行比较的方法。就人数而言，不仅要确认 1 和 10，还要确认 0 和 11。即使 AI 输出了很多“正常的 5 人”，也不能说明已经涵盖了边界视角。
| 视角 | 输入示例 | 从规格中可读出的预期 |
|---|---|---|
| 人数下限 | 1 | 满足人数条件 |
| 下限之外 | 0 | 不满足人数条件 |
| 上限 | 10 | 满足人数条件 |
| 上限之外 | 11 | 不满足人数条件 |
| 整数条件 | 1.5 | 不满足人数条件 |
| 名称上限 | 重复“啊”30次 | 满足长度条件 |
| 超出名称上限 | 重复“啊”31次 | 不满足长度条件 |
此表并未决定错误消息的措辞或显示位置，因为规范中没有相关规定。如果AI补充了诸如“保存按钮变为无效”、“显示红色字体的消息”之类的界面操作，则将其从实现事实还原为确认候选。
逐一更改条件以锁定原因
如果同时将人数和名称设为无效值，会很难分清是哪个条件导致了失败。首先，将名称固定为正常值，只改变人数。接下来，将人数固定为正常值，只改变名称长度。与增加用例数量相比，这更是一种便于解释结果的设计。
并不一定需要尝试所有组合。如果条件之间存在关联，则需要进行组合确认，但如果是独立的输入，则可以从单独的边界值开始。人工会根据对象风险和规范来决定测试范围。
将“可以正常注册”的预期也进行细分。受理通过、显示预约编号、以及之后可以查询预约，这些都是不同的事情。S3所示的仅到界面显示为止，并没有写明邮件通知或反映到列表中的内容。
不要通过测试来确定未定义的规范
S4的重复预约尚未决定。即使AI写了“如果重复则报错”，也不能将该预期结果放入已批准的测试中。在确认了重复的单位、例外情况以及对使用者的提示后，再确定预期动作。
将未定义的项目放在单独的栏中，就能看出设计评审中应该回答的问题。从这份备忘录中也无法得知“相同时间段”是指开始时间一致，还是预约期间重叠。将模糊的词语替换为具体的输入示例，将更便于做出判断。
长度规范也是如此。三十个字符是按界面上的外观、字符编码上的单位、还是按存储端的限制来计算，其边界可能会有所不同。这里通过重复“啊”来确认基本边界，而复杂字符的处理则作为其他确认事项保留。
修改一行，调查应添加的用例
仅将 S1 的上限从 10 人更改为 12 人，并使用新的对话创建一个测试表。预期的变化是出现边界情况：允许 12 人，并将 13 人视为超出范围。如果 10 人仍然保持非法状态，则说明还拖着旧条件。
在此，不仅要重新制作测试用例，还要让 AI 解释更改的影响。通过列出“要更改、添加或删除的 ID”，可以确认与现有用例的对应关系。但是，AI 分配的 ID 并不会自动反映到实际的测试管理台账中。
没有理由因为上限的更改而连带改变预约名称的长度或预约编号显示的条件。在修订时，也应将检查不相关的预期结果是否被改写纳入确认范围。将差异控制在较小范围内，有助于明确评审范围。
通过与规范的对应关系检查遗漏和重复
测试表创建完成后，按规范编号汇总对应的用例。S1 有多个关于人数的边界，而 S3 需要确认受理完成后的显示。即使行数很多，如果没有与 S3 对应的项目，该规范就不会得到确认。让 AI 制作按编号分类的对应一览表，可以缩小复查范围。
也不能仅凭输入值相同来判断重复。即使输入的都是 10 人，用于确认预约编号显示的用例和用于确认人数上限的用例，其目的也是不同的。虽然有时可以通过一次操作集中确认，但预期结果栏中仍需保留这两个视角。
对于非法输入，需要区分“已被拒绝”和“现有数据未发生更改”。是否应将后者加入测试中，需在确认保存处理的规范和影响后决定。AI 作为安全措施建议的项目，应与基于已批准规范的预期结果分开管理。
用例的优先级也不应仅由自动评分来决定。人数错误导致预约的影响与消息显示差异的权重是不同的。人工需要确认业务上的影响、发生概率以及与更改部位的关系，从而决定在有限的时间内优先测试哪些部分。
如果在执行过程中发现规范不足，请不要当场改写预期结果并将其判定为通过。应记录问题和回答，并将规范和测试表两部分更新为相同的一致内容。在继续测试之前，还要确认更改是否会对其他用例产生影响。
区分测试设计与执行记录
在表刚刚创建好的阶段，测试尚未执行。只有记录了执行日期、目标版本、操作环境、实际结果和证据后，才能判定通过与否。不要将 AI 写的“通过”输出直接当作执行记录处理。
在尝试实际输入时，请使用验证环境和虚拟预约名称。这并不意味着可以立即根据本文在业务的生产画面上进行大量注册或占用预约的测试。应先确认目标环境的使用规则和清理方法。
输入规范时也要注意。如果包含未公开的画面、内部规则、交易信息，应在组织允许的范围内进行处理。先用虚拟规范测试表的形状，然后在传递实际信息时确认输入对象和共享对象的顺序，这才是实务的做法。
评估的不是项目数量。我们要看的是：每个规范是否对应至少一个确认项，是否存在边界的内侧和外侧，未定义项是否混入了通过条件中。在增加候选项目之后，由人工来整理重复项和优先级。
验收测试旨在确认实现是否满足规范。虽然 Copilot 发挥着扩大候选范围的作用，但预期结果应与已达成一致的规范相联系。如果能将未定义项保持原样，测试表就可以同时用于执行准备和规范确认。
官方信息与一手信息
产品范围和输入方法参考了官方资料。虚拟数据、提示词、期望示例和检查表是本文的验证方案，并非微软保证的输出示例。
