tester

维护并执行项目里的黑盒测试目录。用例按分类放在 .pouch/tester/，可以列出、增改，也可以按分类或编号去跑。术语、命名与设计理由见 references/concepts.md。

什么时候使用

「列出测试」「一共有哪些用例」
「加一条相机开盖的测试」「完善 TC-CAM-003 的验证」
「跑 smoke」「测 CAM」「跑 TC-INF-001 和 TC-CAM-001」
「现场复测」
「用这个 APK/IPA 地址跑 Android+iOS」

不管 ACK。这是项目自己的测试目录。

使用前准备

目录在目标测试项目根的 .pouch/tester/。父仓库和 app 等 Git submodule 可以各自有 catalog；先运行 catalog.py roots --root <repo-root> 发现它们，不要把两个项目的 cases 合并。没有任何 catalog 才说「初始化 tester」。
从父仓库直接执行 tester 命令时，只有一个子 catalog 会自动选中；多个子 catalog 会自动 fan-out，逐个执行且不合并 cases。无需在根 .pouch 里增加未定义的 include。
跑真实环境前，复制 .pouch/tester/local.yaml.example 为 local.yaml；模板默认 HOST: "127.0.0.1"。如果目标不是本机，显式改成目标地址。也可以用环境变量 HOST 覆盖。
测试默认在当前项目执行。也可以直接提供 Orca project id、项目名称或 terminal id； tester 会自动解析 Agent、环境、项目和目录，写入 local.yaml.agent，并输出更新后的配置列表。每轮测试会创建新的 terminal，结束后自动关闭；不会复用或关闭已有 terminal。
测试环境部署由 deployer 在本机 Compose 中触发；正式环境部署由本机 ~/code/app00 项目的 fresh Agent terminal 触发，tester 不直接 SSH 或执行正式 Compose。
会动硬件、会改数据的用例带风险级别（readonly / mutating / destructive）。默认只跑最低档 readonly。要跑更高风险，需要你明确说，例如「风险到 mutating」；碰哪个子系统另由 gate（如 hardware / weld）控制。

使用示例

<skill-dir>/tester run \
  --artifact android=<path-or-url> \
  --artifact ios=<path-or-url> \
  --platform android,ios

调用方必须给出每个平台的产物位置，可以是本地文件或下载地址。tester 按这个输入取用或下载 APK/IPA，为本轮创建隔离 worktree，在 Android 和 iOS tester 节点安装并验证身份，然后交给真实移动 session 执行 catalog。默认全量闸门，只有显式 --partial 才允许单平台继续。

列出测试用例

加一条测试：分类 CAM，风险 mutating，开盖再关盖，用脚本打 /api/camera_3d

跑 INF 分类的 smoke

用 terminal term_2cfb291c-8769-4613-af52-1fcc2f209eaa 的环境跑 iOS smoke，先把 Agent 配置列出来确认

用 Orca project temp-macmini 跑移动测试，自动初始化 tester Agent 配置并先确认

跑 TC-CAM-001,TC-CAM-005，风险保持默认

Agent 会做什么

用脚本读 .pouch/tester/，按分类统计或筛出你点名的用例，不会把整库塞进对话。
改用例前先给你看将要写入的内容，你确认再保存。
执行时先建立“产物 × 平台 × tester 绑定 × 执行环境”矩阵，并把平台、产物和 binding 传给 catalog.py select 做硬性校验，再对矩阵全部行做 preflight。任一产物、平台或环境不可用，都先返回完整阻塞清单，不创建测试 session、不执行可用平台；只有全部可用才按目标环境走 deployer 路由、解析 Agent、输出生效列表、准备 Orca 项目并创建临时 terminal。脚本类、浏览器和移动模拟器都在对应 Agent 环境中执行。builder.<platform> 不能替代 tester.<platform>。
超出你允许的风险级别会跳过，不会偷偷执行。
无论测试成功、失败或异常，都会关闭本轮创建的 terminal；跑完给出按分类计数的结果，以及 pass / fail / environment-fail / skipped / not-run。

如何判断完成

列出：能看到分类表和总条数；.pouch/tester/cases.csv 已由 skill 里的 generate_cases_csv.py 从 cases/ 重新生成。每次运行的结果保存在独立的 .pouch/tester/runs/<run-id>.* 文件中。
维护：目标 id 能 查看 到，且检查通过。
运行：有本次 runs/*.yaml 快照和同名 .csv 成绩单（executed 列区分已跑 / 未跑）；没填 HOST 时会停，而不是编造失败。

客户端用户旅程

测试用例支持两种顶层类型：test_type: integration 和 test_type: journey。集成套件至少包括 api-contract、authorization、build-contract；客户端套件仍是 client-smoke、client-regression、safety。没有显式范围时默认不选择 integration。

执行顺序固定为 test-preflight -> integration -> journey。preflight 状态为 blocked 或 environment-fail 时不创建客户端 session；integration 失败时依赖 journey 为 not-run。服务不可达是 environment-fail，契约断言错误是 integration fail，正确账号登录失败仍是 journey fail。tester run/bundle 必须传入 caller 提供的 matrix：

<skill-dir>/tester run --preflight-config /abs/preflight.yaml \
  --artifact android=/abs/app.apk --artifact ios=/abs/app.ipa

没有真实 deployer、Mac 或设备时，只能使用 test-preflight 的 command-contract mock fixture 验证协议，不能把 mock 结果写成真实运行成功。

客户端 E2E 用例使用 client_suite: client-smoke | client-regression | safety，并明确 journey、fixture、session、cleanup、platform。标准生命周期是：

preflight → 启动 → 登录 → 旅程 → 断言 → 清理 → 报告

正确测试账号登录失败记 fail；设备、产物或服务不可达记 environment-fail。fixture 或 cleanup 缺失会在开始前阻断；前置失败后的剩余用例是 not-run，明确排除才是 skipped。 safety 必须显式选择和授权，不进入默认 smoke/full。它与普通 tester 用例共用原有 CSV/YAML 运行记录和汇总校验。

汇总已有运行结果

对已经生成的同一运行 CSV/YAML，使用显式路径汇总：

python3 <skill-dir>/scripts/summarize_run.py \
  --csv .pouch/tester/runs/<run-id>.csv \
  --yaml .pouch/tester/runs/<run-id>.yaml

脚本只从 CSV 的 result 列计算 pass、fail、environment-fail、skipped、 not-run 五类状态，并要求五类计数和等于 CSV 数据行数。YAML 只用于校验 results 数量和 testcase id 集合；数量、集合、重复/缺失 id 或 CSV 缺失/未知状态时返回非零并输出诊断。校验成功才表示这份汇总可作为运行报告；非零表示报告不一致，不能据此判定产品失败。

6.8 KiB Raw Blame History Unescape Escape