菜单
Expert guidance on scoping test automation investments, assigning ownership, choosing quality metrics, and keeping a mobile test suite economically viable. Use when asked "what should our test strategy be?" or when the test suite is becoming a cost center.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Expert guidance on detecting mobile performance regressions — startup time, frame jank, scroll performance, binary size — with baselines and noise-aware thresholds. Use when setting up perf gates in CI or when a release is suspected of regressing.
Measure code coverage honestly across mobile stacks — JaCoCo (JVM), llvm-cov (iOS), lcov (Flutter), Jest (RN) — and report it to Codecov / Coveralls without chasing meaningless numbers. Use when setting up coverage or when asked to raise a coverage gate.
Expert guidance on running mobile test suites in CI — matrix design, caching, sharding, artifacts, required checks — without paying for slow, flaky runs. Use when configuring GitHub Actions, GitLab CI, Bitrise, or Codemagic for mobile testing.
Expert guidance on automated and manual accessibility testing for mobile apps — Espresso AccessibilityChecks, XCTest accessibility audits, Flutter a11y guidelines, RN a11y assertions. Use when adding a11y coverage or when asked how to catch accessibility regressions in CI.
Expert guidance on snapshot / golden image testing across mobile stacks — Paparazzi (Android), swift-snapshot-testing (iOS), golden_toolkit (Flutter), and RN snapshot tests. Use when asked to lock down UI visuals or catch unintended rendering regressions.
Compare and apply UI test tooling across mobile — Espresso, XCUITest, flutter_test / integration_test, Detox, and Maestro. Use when deciding which UI test layer fits a feature and how to structure selectors, waits, and page objects.
| name | test-automation-strategy |
| description | Expert guidance on scoping test automation investments, assigning ownership, choosing quality metrics, and keeping a mobile test suite economically viable. Use when asked "what should our test strategy be?" or when the test suite is becoming a cost center. |
A test suite is an asset until it is not. Once maintenance cost exceeds the bugs caught, the suite is a liability. Strategy is about keeping the suite on the asset side of that line.
List the top risks for the app, ordered by impact and likelihood:
Every risk maps to exactly one test layer that should catch it first. Avoid covering the same risk at three layers — you pay three times and still get one signal.
| Layer | Cost to Run | Cost to Maintain | Signal |
|---|---|---|---|
| Unit | Lowest | Lowest | Logic correctness |
| Integration | Low | Low-Medium | Wiring and serialization |
| UI component | Medium | Medium | Component behavior and a11y |
| Contract | Low | Low | Client/server mismatch |
| Snapshot | Low | Medium (review cost) | Visual regressions |
| E2E | Highest | Highest | End-to-end wiring, release-blockers |
Aim for ~70/20/10 (unit+integration / UI / E2E) by test count. Measure it; do not guess.
Every test file has exactly one owning team, declared explicitly:
// @owner: payments
// MARK: owner: identity
Unowned tests rot. When an owning team dissolves, the tests migrate or are deleted within one sprint.
Track these; publish them monthly:
Coverage as a gate number (e.g., "80 %") by itself is a weak signal. Track it, but do not fail builds on it.
Use this triage loop each quarter:
When a feature is planned, the automation plan accompanies the design:
A feature without an automation plan is not ready to merge.
Tests are code and deserve the same review discipline:
@Ignore / xit without a linked ticket and a deadline.Delete aggressively. Candidates:
Deleting tests is a positive act; the remaining suite becomes more trusted.
Make these visible, not tribal: