# 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`）。默认
  `standard` 只跑最低档 `readonly`。隔离、可重置的 Writes 类环境在 catalog 设置
  `execution_profile: isolated-full` 后，所有 active 自动化用例都进入执行，不因
  `AUTHORIZE_MUTATING`、`AUTHORIZE_DESTRUCTIVE`、`AUTHORIZE_ALBUM` 或
  `AUTHORIZE_PASSWORD` skipped；risk 原值仍保留。设备、产物、服务和 cleanup/rollback
  由 test-preflight 保证；客户端相册、权限和中文输入能力默认具备，由 journey 用例验证。

## 使用示例

```bash
<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` 才允许单平台继续。

```text
列出测试用例
```

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

```text
跑 INF 分类的 smoke
```

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

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

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

## Agent 会做什么

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

```bash
<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`。标准生命周期是：

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

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

移动 preflight 还必须在实际 tester 节点验证相册 picker、照片权限与测试图片，以及中文
拼音的真实 composition 和候选词选择；缺失时所有 testcase 都保留 `not-run` +
`blocked_by`，不会静默 `skipped`。

失败回流使用 run YAML 顶层 `defects`/`test_issues` 与 `feedback`：PR 触发先更新 PR/关联
issue、通知 dispatcher 重新分配开发；需求/bug 触发直接回开发流程。可用
`scripts/record_issues.py` 生成同名 CSV 的结构化 issue 列。

### 汇总已有运行结果

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

```bash
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 缺失/未知状态
时返回非零并输出诊断。校验成功才表示这份汇总可作为运行报告；非零表示报告不一致，
不能据此判定产品失败。