laily/.pouch
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b94aa597ca9ec63dd7d3cd5996a8be17702cd0d0
.pouch/skills/tester/README.md
T

7.8 KiB
Raw Blame History

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 用例验证。

使用示例

<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 会做什么

  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：

<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 运行记录和汇总校验。

移动 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，使用显式路径汇总：

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

Reference in New Issue View Git Blame Copy Permalink