Testhub

## 任务目标

请依据真实执行证据编写简明版本测试报告。报告供业务负责人判断交付准备情况。

以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。

## 输入信息（选填）

两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。

报告版本：优先采用当前待交付版本；未明确时，从已有执行记录选择最近一组可确认构建与环境的结果编写报告，并将其他版本结果分列，不将当前代码版本自动视为已测版本。
执行与验收资料：读取当前工程或已授权项目资料中的测试计划、测试产物、缺陷及复测记录、需求范围和验收约定，自动提取版本、时间、终端、角色与统计口径。

## 信息不完整时

先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。

### 优先确认

- 定位已有测试报告及原始执行记录，核对用例、构建、环境、终端、角色和关键数据集的组合。
- 关联需求清单与执行证据，区分构建检查、静态检查、前端检查和真实业务验证。
- 核对未关闭缺陷和修复版本的复测证据，查找团队已经约定的版本验收条件。

### 可采用的默认处理

- 默认只读汇总证据，同组重复执行保留历史，跨终端或跨角色的通过结果不覆盖其他组失败。
- 没有明确验收门槛时给出准备情况和条件建议，不自行设定门槛后宣布验收通过。
- 统计同时写清用例数与执行实例数，未执行、阻塞和缺证据分别保留，不纳入通过项。

### 必须有依据的事项

- 执行记录无法识别版本或统计分组时，不能生成该版本的确定性通过数量；先交付可确认组别的结果。
- 业务验收条件未确定或存在相互冲突的正式要求时，不能代替业务签收或批准发布。

只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。

### 资料仍不足时的交付

- 没有执行数据时交付按需求组织的报告框架、证据登记口径和未测范围，不填示例通过率。
- 只有部分记录时完成对应版本与场景的局部结论，列明剩余证据、遗留缺陷及重新评价条件。

## 执行要求

报告中的用例和缺陷应能追溯到测试计划与执行记录；版本结论按团队验收条件判断，不代替业务签收或上线批准。

1. 明确报告对象、版本、测试环境、执行时间和数据截止时间，核对每份记录所属版本。不同构建或环境的结果分别列出，不用旧版本通过结果替代当前版本。
2. 按用例 ID、构建版本、环境、终端、角色及关键数据集组合分组，仅在同组内归并重复执行并保留历史。跨组失败分别保留，不能用 Vue 端或管理员通过覆盖小程序端或普通角色失败。统计区分用例数与执行实例数，明确通过、失败、阻塞和未执行口径，给出可复算数量。
3. 将已确认需求逐项映射到对应执行证据，列出没有用例、没有执行记录、只有静态检查或只测前端的范围。构建成功、页面可打开和核心业务通过应分别表述。
4. 整理未关闭缺陷的影响对象、业务后果、临时措施和复核状态，检查所谓已修复是否有对应版本的复测证据。只有修复说明而没有执行记录时标为待验证。
5. 按团队已提供的验收条件逐项判定满足、不满足或证据不足。条件缺失时提出建议并单独列出，不能先自行设门槛再宣称版本已经满足业务验收。
6. 生成发布准备建议和后续工作，每项写责任角色、所需证据和重新评估条件。需要正式业务确认的事项清楚列出，不冒充项目负责人已经批准发布。

## 交付与验收

输出：版本与环境、覆盖范围、执行数量及统计口径、需求验证表、遗留缺陷、未测或阻塞范围、验收条件判定、交付建议与后续动作。用短句和必要表格，不添加夸大总结。

验收：所有数字可从执行记录复算；未测和阻塞不会计为通过；所有通过结论对应当前版本证据；风险可理解可追踪；没有伪造性能、兼容性或安全结论。

信息边界：没有执行数据时只输出待填写框架和材料缺口，不填示例通过率；本任务不自动发布版本、替业务签收或向团队发通知。

### 本条完成检查

- 所有数量可从真实记录复算，统计分组、分母和数据截止时间明确。
- 通过、失败、阻塞、未测和待复核分别有据，旧版本或管理员结果不覆盖其他范围。
- 交付建议逐项对应团队条件和遗留风险，报告不替代正式业务签收。

按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。

## 参考资料与适用边界

参考来源（核验于 2026-09-08）：
- [云效 Testhub：快速入门](https://help.aliyun.com/zh/yunxiao/user-guide/quick-start)

## 任务目标

请制定本次迭代可执行的测试与回归计划。计划范围必须与真实变更相对应。

交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。

## 输入信息（选填）

两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。

迭代测试目标：从当前迭代、待合入改动或版本说明识别测试目标；未给范围时，以当前已确认工程的本次变更及其直接关联业务链路作为计划范围，明确比较基准和排除项。
变更与用例资料：读取现有需求、代码差异、配置与数据变更、用例库、已知缺陷和测试安排，自动识别终端、依赖与环境前提。

## 信息不完整时

先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。

### 优先确认

- 核对版本标识和实际比较基准，读取模块、配置、数据结构及依赖变化。
- 从用例库和历史高风险缺陷中寻找与变更链路相关的场景，记录入选和排除依据。
- 查项目已有测试环境、账号角色、终端矩阵、责任安排及发布时间约束，不推测人员可用性。

### 可采用的默认处理

- 按业务阻断、数据正确性、权限边界和常用路径安排优先顺序，再区分冒烟、功能验证与回归。
- 人员和窗口未知时使用责任角色与依赖顺序，不编造具体姓名、工期或发布日期。
- 默认只制定计划，不启动测试或改变工作项状态；计划中未执行、失败和阻塞的记录方式提前明确。

### 必须有依据的事项

- 变更前后基准无法识别时，不能声称已覆盖完整回归范围；先按已见需求和文件列出局部影响。
- 关键业务流程或跨系统依赖存在冲突而无法确定预期结果时，需确认对应规则后再将该场景设为正式通过条件。

只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。

### 资料仍不足时的交付

- 没有代码差异时，依据需求变更生成业务链路测试计划，标明尚待技术影响分析的模块。
- 没有环境或人员安排时交付用例选择、优先级、前置数据、环境需求和分组执行顺序。

## 执行要求

将测试计划关联到当前项目和迭代，按变更选择用例并记录状态及缺陷；执行优先级、准入和退出条件以项目约定为准。

1. 确认版本标识、变更模块、配置和数据变化，建立变更到业务链路的影响关系。缺少代码差异或依赖信息时列出证据缺口，不声称已经覆盖所有受影响模块。
2. 从用例库选择新功能、变更功能、关联功能和历史高风险缺陷对应的用例，记录入选原因与需求关联。未选中的相关用例说明理由，避免把回归范围简单设为全部或随意抽查。
3. 按业务阻断、数据正确性、权限边界和常用路径安排顺序，区分冒烟、功能验证和回归。结合接口、后台页面、小程序等真实终端列出环境和账号需求。
4. 为每组用例设置责任角色、执行窗口、前置数据和依赖，资源未知时使用待分配项，不编造具体人员承诺。环境、证书、域名和组件版本须对应被测版本。
5. 定义未执行、执行中、通过、失败和阻塞的含义，并说明失败与阻塞如何记录证据、关联缺陷及安排复测。复测只能覆盖实际修复版本，保留先前失败记录。
6. 提出本次版本的完成条件和剩余风险处理方法，统计状态时明确分母及去重方式。阻塞、暂缓或跳过不能被计作通过，不用高通过率掩盖核心场景未执行。

## 交付与验收

输出：测试范围与排除项、变更影响表、用例选择及顺序、环境和人员安排、执行记录规则、复测计划、完成条件、风险与缺口。时间安排注明依据与可调整条件。

验收：范围可追溯到变更；关键场景有负责人和前提；状态含义无歧义；回归对象明确；计划中的能力和资源有依据；未执行项可见。

信息边界：该任务产出计划，不自动执行测试或改动工作项状态；如果用户另行授权执行，必须依据真实运行记录更新结果。

### 本条完成检查

- 每组用例可追溯到变更、需求或历史风险，排除项有理由。
- 终端、版本、环境、账号和数据前提明确，未知资源保留待分配状态。
- 复测与完成条件能实际执行，统计不把暂缓、阻塞或跳过计为通过。

按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。

## 参考资料与适用边界

参考来源（核验于 2026-09-08）：
- [云效 Testhub：测试计划](https://help.aliyun.com/zh/yunxiao/user-guide/test-plan-1)

## 任务目标

请根据真实需求设计业务测试用例。产出可供人工执行或继续编写自动化测试，不把编写用例等同于执行通过。

交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。

## 输入信息（选填）

两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。

被测业务：从当前需求或最近明确的功能改动识别被测业务；未指定功能时，以现有页面到接口的一条完整业务链路为起点，先覆盖有明确规则的正常流程与关键异常。
需求与工程资料：读取当前目标模块的需求、页面、接口定义、字典、权限与已有用例，自动提取角色、状态、字段边界和终端范围。

## 信息不完整时

先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。

### 优先确认

- 定位需求编号、字段规则和状态转换，核对页面、接口与文档是否存在预期冲突。
- 查已有用例及测试数据构造方式，复用相同验证目的的记录并保留真正不同的边界。
- 沿列表、详情、写入、导出和统计读取数据范围与授权校验，识别跨租户和普通角色场景。

### 可采用的默认处理

- 每个已确认规则先生成最小正常用例，再按实际适用性补充空值、边界、异常、并发及权限场景，不靠数量凑覆盖。
- 初始执行状态统一为未执行，优先级由业务损失与使用路径决定；代码现状与需求冲突时不默认现状正确。
- 测试数据采用可清理的隔离记录，真实支付、删除与生产写入只列必要隔离前提，不直接执行。

### 必须有依据的事项

- 核心计算、状态转换或字段含义缺乏明确依据时，不能自行写成正式预期；继续完成其他有规则的用例。
- 角色或组织的数据归属无法确定时，不能猜测合法可见范围，应把相关用例列为权限规则待确认。

只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。

### 资料仍不足时的交付

- 只有需求没有工程时，交付带来源位置的业务用例、规则缺口与接口验证需求。
- 没有环境时仍交付可执行的前置条件、数据、步骤、预期和清理要求，并标明自动化候选的依赖。

## 执行要求

按产品模块组织用例，写清前置条件、操作步骤和预期结果；覆盖范围应与当前工程需求对应。

1. 从需求提取可验证的业务规则，为每项规则保留需求编号及原文位置。区分正常功能、错误处理、权限、数据和兼容性，标注没有定义预期结果的规则缺口。
2. 按产品、模块、功能和场景组织用例，检查现有用例能否复用。删除仅名称不同但验证内容相同的重复项，并保留真正不同的业务边界。
3. 为关键业务写正常路径，注明角色、登录状态、组织、测试数据和前置记录。每一步操作应可重复执行，预期结果同时包含页面表现与必要的数据变化。
4. 补充必填、范围上下界、空值、重复、状态不合法、并发修改、网络中断和接口失败等适用条件。不存在业务需求的场景标为建议核实，不为凑数量添加无效用例。
5. 针对多组织或多租户系统，分别验证列表、详情、接口、导出和统计的数据边界。前端隐藏按钮不能替代服务端拒绝越权请求的预期结果。
6. 根据业务影响确定执行优先级和自动化候选，注明环境依赖及数据清理方式。涉及支付、删除或生产写入的验证先设计隔离条件，避免用真实业务记录凑测试材料。

## 交付与验收

输出用例表：编号、需求编号、模块、标题、优先级及理由、前置条件、测试数据、操作步骤、预期结果、环境依赖、执行状态。初始执行状态统一为未执行；另列规则缺口和建议。

验收：每项已确认规则有对应验证；步骤可复现；预期结果可观察；角色和组织边界明确；无伪造结果、截图或接口响应；不以用例数量代替覆盖质量。

信息边界：没有环境或执行权限时只生成用例；未知规则不能自行变成验收标准，自动化适用性也应说明依赖。

### 本条完成检查

- 已确认规则都有可观察的预期与来源，用例步骤可复现且数据前提明确。
- 角色、组织、状态及关键异常得到针对性覆盖，重复用例已合理归并。
- 用例设计与执行结果明确区分，没有伪造截图、响应或测试通过状态。

按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。

## 参考资料与适用边界

参考来源（核验于 2026-09-08）：
- [云效 Testhub：快速入门](https://help.aliyun.com/zh/yunxiao/user-guide/quick-start)