Back to Details

test-changes

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Test Changes

测试变更

Produce a practical handoff for manually verifying the work completed in the current conversation.
提供一份实用的交接文档，用于手动验证本次对话中完成的工作。

1. Establish the test surface

1. 确定测试范围

Reconstruct the delivered outcome from the conversation, including later corrections and failed or partial attempts. Treat the current workspace, connected systems, and running environment as confirmation of the final state, not as a substitute for the conversation.
Inspect read-only evidence where useful: changed files, 
git diff
, repository status, available scripts, project documentation, generated artifacts, external records, and already-running services. Account for every user-visible behaviour, artifact, or external state changed by the completed work. Separate unrelated pre-existing changes.
If no completed or inspectable change exists, say so and identify what must be completed before manual testing is meaningful.
Completion criterion: every change made in this conversation is mapped to something the user can inspect or exercise, or explicitly marked as having no manual test surface.
重构对话中交付的成果，包括后续的修正以及失败或部分尝试的内容。将当前工作区、关联系统和运行环境视为最终状态的确认依据，而非对话内容的替代。
在有用的情况下检查只读证据：已更改的文件、
git diff
、仓库状态、可用脚本、项目文档、生成的工件、外部记录以及已在运行的服务。覆盖所有因已完成工作而改变的用户可见行为、工件或外部状态。区分无关的预先存在的变更。
如果不存在已完成或可检查的变更，请说明这一点，并指出在手动测试有意义之前必须完成的内容。
完成标准：本次对话中做出的每一项变更都对应到用户可以检查或操作的内容，或明确标记为无手动测试范围。

2. Build the shortest valid test path

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

Start with what the user can see right now, before asking them to run anything. Include existing files, rendered artifacts, open applications, running services, URLs, or visible state only when confirmed.
Then provide the minimum prerequisites and commands needed to reach the test surface. Use PowerShell syntax for terminal commands:
  • Begin from the correct directory with 
    Set-Location
    .
  • Give commands in execution order and make each block directly copyable.
  • Use the repository's real scripts, project names, ports, and paths.
  • Include dependency installation, build, migration, seed, server, or authentication steps only when required.
  • State whether a long-running command occupies the terminal and when a second PowerShell window is needed.
  • Prefer the smallest command that exercises the changed area; add broader checks only when they expose materially different risk.
  • Mark any value the user must supply, such as 
    <ApiKey>
    , and say where it comes from.
Link directly to local artifacts and external pages when they can be opened from the response. When no terminal step is relevant, give direct inspection actions without manufacturing a PowerShell command.
Do not mutate application data merely to prepare the explanation. When the test itself changes data, warn the user and give a cleanup or reset step when one is available.
Completion criterion: following the commands from a clean PowerShell window reaches every testable changed surface without hidden steps.
从用户当前能看到的内容开始，在要求用户运行任何命令之前。仅在确认的情况下包含现有文件、渲染后的工件、打开的应用程序、运行的服务、URL或可见状态。
然后提供到达测试范围所需的最低前提条件和命令。使用PowerShell语法编写终端命令：
  • 使用
    Set-Location
    切换到正确目录。
  • 按执行顺序给出命令，确保每个代码块可直接复制。
  • 使用仓库的真实脚本、项目名称、端口和路径。
  • 仅在需要时包含依赖安装、构建、迁移、数据填充、服务器启动或身份验证步骤。
  • 说明长时间运行的命令是否会占用终端，以及何时需要第二个PowerShell窗口。
  • 优先选择能覆盖变更区域的最小命令；仅当更广泛的检查能暴露显著不同的风险时才添加。
  • 标记用户必须提供的任何值，例如
    <ApiKey>
    ，并说明其来源。
当可以从响应中直接打开本地工件和外部页面时，提供直接链接。当终端步骤无关时，给出直接检查操作，无需强行编写PowerShell命令。
不要仅为了准备说明而修改应用程序数据。当测试本身会更改数据时，警告用户，并在可用时提供清理或重置步骤。
完成标准：从干净的PowerShell窗口执行命令后，无需隐藏步骤即可覆盖所有可测试的变更范围。

3. Specify observations

3. 明确观察要点

For each test, state:
  1. The exact action to perform.
  2. The exact result to expect.
  3. The detail that proves the new or changed behaviour, including relevant text, controls, values, files, logs, status codes, or before/after differences.
  4. A meaningful failure signal.
Cover the happy path first, then changed edge cases and regressions justified by the work. Describe observable behaviour rather than implementation details. Do not invent certainty: label inferred expectations and state any limitation that prevents a complete manual test.
Completion criterion: the user can decide pass or fail for every test without interpreting vague phrases such as “works correctly.”
对于每项测试，说明：
  1. 要执行的确切操作。
  2. 预期的确切结果。
  3. 证明新行为或变更行为的细节，包括相关文本、控件、值、文件、日志、状态码或前后差异。
  4. 明确的失败信号。
首先覆盖正常流程，然后是因工作内容而需要关注的变更边缘情况和回归问题。描述可观察的行为而非实现细节。不要凭空确定：标记推断的预期，并说明任何导致无法完成完整手动测试的限制。
完成标准：用户无需解读“正常工作”这类模糊表述，即可判定每项测试的通过或失败。

Response format

响应格式

Omit empty sections.
md
undefined
省略空章节。
md
undefined

What you can see now

当前可见内容

  • <Confirmed immediately visible state, and where to find it>
  • <已确认的即时可见状态及其位置>

Start or prepare

启动或准备

<Copyable PowerShell commands, plus terminal/window guidance>
<可复制的PowerShell命令，以及终端/窗口使用说明>

Manual tests

手动测试

1. <Behaviour or artifact>

1. <行为或工件>

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>
<停止服务或恢复测试数据所需的PowerShell命令或操作>

Limitations

限制

  • <Anything unconfirmed, untestable manually, or requiring unavailable access>

Keep the handoff concise, but include every changed test surface. Do not repeat automated test results unless they help the user interpret a manual test.
  • <任何未确认、无法手动测试或需要未获取权限的内容>

保持交接文档简洁，但需覆盖所有变更的测试范围。除非有助于用户解读手动测试结果，否则不要重复自动化测试结果。