## 任务目标
请依据真实执行证据编写简明版本测试报告。报告供业务负责人判断交付准备情况。
以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。
## 输入信息（选填）
两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。
报告版本：
执行与验收资料：
## 信息不完整时
先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。
### 优先确认
- 定位已有测试报告及原始执行记录，核对用例、构建、环境、终端、角色和关键数据集的组合。
- 关联需求清单与执行证据，区分构建检查、静态检查、前端检查和真实业务验证。
- 核对未关闭缺陷和修复版本的复测证据，查找团队已经约定的版本验收条件。
### 可采用的默认处理
- 默认只读汇总证据，同组重复执行保留历史，跨终端或跨角色的通过结果不覆盖其他组失败。
- 没有明确验收门槛时给出准备情况和条件建议，不自行设定门槛后宣布验收通过。
- 统计同时写清用例数与执行实例数，未执行、阻塞和缺证据分别保留，不纳入通过项。
### 必须有依据的事项
- 执行记录无法识别版本或统计分组时，不能生成该版本的确定性通过数量；先交付可确认组别的结果。
- 业务验收条件未确定或存在相互冲突的正式要求时，不能代替业务签收或批准发布。
只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。
### 资料仍不足时的交付
- 没有执行数据时交付按需求组织的报告框架、证据登记口径和未测范围，不填示例通过率。
- 只有部分记录时完成对应版本与场景的局部结论，列明剩余证据、遗留缺陷及重新评价条件。
## 执行要求
报告中的用例和缺陷应能追溯到测试计划与执行记录；版本结论按团队验收条件判断，不代替业务签收或上线批准。
1. 明确报告对象、版本、测试环境、执行时间和数据截止时间，核对每份记录所属版本。不同构建或环境的结果分别列出，不用旧版本通过结果替代当前版本。
2. 按用例 ID、构建版本、环境、终端、角色及关键数据集组合分组，仅在同组内归并重复执行并保留历史。跨组失败分别保留，不能用 Vue 端或管理员通过覆盖小程序端或普通角色失败。统计区分用例数与执行实例数，明确通过、失败、阻塞和未执行口径，给出可复算数量。
3. 将已确认需求逐项映射到对应执行证据，列出没有用例、没有执行记录、只有静态检查或只测前端的范围。构建成功、页面可打开和核心业务通过应分别表述。
4. 整理未关闭缺陷的影响对象、业务后果、临时措施和复核状态，检查所谓已修复是否有对应版本的复测证据。只有修复说明而没有执行记录时标为待验证。
5. 按团队已提供的验收条件逐项判定满足、不满足或证据不足。条件缺失时提出建议并单独列出，不能先自行设门槛再宣称版本已经满足业务验收。
6. 生成发布准备建议和后续工作，每项写责任角色、所需证据和重新评估条件。需要正式业务确认的事项清楚列出，不冒充项目负责人已经批准发布。
## 交付与验收
输出：版本与环境、覆盖范围、执行数量及统计口径、需求验证表、遗留缺陷、未测或阻塞范围、验收条件判定、交付建议与后续动作。用短句和必要表格，不添加夸大总结。
验收：所有数字可从执行记录复算；未测和阻塞不会计为通过；所有通过结论对应当前版本证据；风险可理解可追踪；没有伪造性能、兼容性或安全结论。
信息边界：没有执行数据时只输出待填写框架和材料缺口，不填示例通过率；本任务不自动发布版本、替业务签收或向团队发通知。
### 本条完成检查
- 所有数量可从真实记录复算，统计分组、分母和数据截止时间明确。
- 通过、失败、阻塞、未测和待复核分别有据，旧版本或管理员结果不覆盖其他范围。
- 交付建议逐项对应团队条件和遗留风险，报告不替代正式业务签收。
按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。
## 参考资料与适用边界
参考来源（核验于 2026-09-08）：
- [云效 Testhub：快速入门](https://help.aliyun.com/zh/yunxiao/user-guide/quick-start)
