149 lines
7.7 KiB
Markdown
149 lines
7.7 KiB
Markdown
# 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 原值仍保留，必须用 test-preflight 的真实能力检查和
|
||
cleanup/rollback 保证安全。
|
||
|
||
## 使用示例
|
||
|
||
```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 缺失/未知状态
|
||
时返回非零并输出诊断。校验成功才表示这份汇总可作为运行报告；非零表示报告不一致，
|
||
不能据此判定产品失败。
|