test-changes

测试变更

为手动验证当前对话中完成的工作，编写一份实用的交接说明。

1. 确定测试范围

根据对话重建交付成果，包括后续更正以及失败或未完成的尝试。将当前工作区、已连接的系统和运行环境视为确认最终状态的依据，而不是对话内容的替代。

必要时检查只读证据：已变更文件、git diff、仓库状态、可用脚本、项目文档、生成的产物、外部记录以及已在运行的服务。覆盖已完成工作所改变的所有用户可见行为、产物或外部状态。将无关的既有变更单独列出。

如果没有已完成或可检查的变更，请说明这一点，并指出在手动测试有意义之前必须完成什么。

完成标准：将本次对话中所做的每项变更对应到用户可检查或操作的内容，或明确标记其没有手动测试范围。

2. 构建最短有效测试路径

先说明用户现在就能看到的内容，然后再要求其运行任何命令。仅在确认存在时，才列出已有文件、已渲染的产物、已打开的应用、正在运行的服务、URL 或可见状态。

接着提供到达测试范围所需的最少前提条件和命令。终端命令使用 PowerShell 语法：

• 从正确目录开始，使用 Set-Location。
• 按执行顺序给出命令，并确保每个代码块都可直接复制。
• 使用仓库实际的脚本、项目名称、端口和路径。
• 仅在需要时包含依赖安装、构建、迁移、种子数据、服务器或身份验证步骤。
• 说明长时间运行的命令是否会占用终端，以及何时需要打开第二个 PowerShell 窗口。
• 优先使用能够测试变更区域的最简命令；只有在可揭示实质性不同风险时，才添加更广泛的检查。
• 标明任何需要用户提供的值，例如 <ApiKey>，并说明其来源。

如果可直接从回复打开，请提供本地文件和外部页面的直接链接。当终端操作无关时，直接说明检查步骤，不要凭空编造 PowerShell 命令。

不要为了准备说明而修改应用数据。如果测试本身会修改数据，请提醒用户，并在有可用方法时提供清理或重置步骤。

完成标准：用户从全新的 PowerShell 窗口按命令操作，无需任何未说明的步骤，即可到达所有可测试的变更范围。

3. 说明观察结果

对每项测试，说明：

1. 要执行的确切操作。
2. 预期的确切结果。
3. 能证明新增或变更行为的细节，包括相关文本、控件、数值、文件、日志、状态码或前后差异。
4. 有意义的失败信号。

先覆盖成功路径，再覆盖有工作依据的变更边界情况和回归风险。描述可观察行为，而不是实现细节。不要凭空断定结果；应标明推断出的预期，并说明妨碍完整手动测试的限制。

完成标准：用户无需揣测“正常运行”等含糊说法，即可判断每项测试通过或失败。

响应格式

省略空章节。

## What you can see now
- <Confirmed immediately visible state, and where to find it>

## Start or prepare
<Copyable PowerShell commands, plus terminal/window guidance>

## Manual tests
### 1. <Behaviour or artifact>
**Action:** <Exact interaction>
**Expected:** <Specific observable result>
**Changed:** <What is new or different>
**Failure:** <Specific sign of failure>

## Cleanup
<PowerShell commands or actions needed to stop services or revert test data>

## Limitations
- <Anything unconfirmed, untestable manually, or requiring unavailable access>

交接说明应简洁，但须涵盖所有变更的测试范围。除非有助于用户理解手动测试，否则不要重复自动化测试结果。

说明重要的验证缺口，以及运行时、数据或配置变更的恢复操作。适用时指出不可逆操作；不要编造回滚方案。审查修复后，依据最终变更更新相关预期和命令。遵循调用方现有的审查要求，不要再重复一份。