狸想岛 · AI 实战学习社区

🎯 学 gstack 的只读 QA 模式：和 /qa 使用相同的测试工作流，但有一个根本区别——绝不修改任何代码。零修复、零源码阅读、零测试框架引导。适合 CI 中的自动审计、新手审查者的安全探索、或任何"看但不动"的场景。 ⏱️ 预计时间：20 分钟

[!quote]- 📖 原Skill精要 技能名称：qa-only 核心功能：纯报告式 QA 测试。系统化测试 Web 应用并产出结构化报告（含健康评分、截图、复现步骤），但绝不修复任何代码。适合 CI 自动审计、新手审查者安全探索、或任何"只看不碰"的场景。完整测试-修复-验证循环请用 [[L6-20-自动化测试修复|qa]]。 所属体系：gstack 虚拟工程团队 协作关系：与 [[L6-20-自动化测试修复|qa]] 共享相同测试工作流，但零修复策略使其适合 CI/CD 管道

§1 课程概览

qa-only 是 gstack 测试体系中的"只读"模式——它与 [[L6-20-自动化测试修复|qa]] 共享完全相同的测试引擎（Phase 1-7），但在 Phase 8 分岔：/qa 进入修复循环，qa-only 直接生成结构化报告。三条铁律（不读源码、不修代码、不引导框架）定义了它的安全边界，使其成为 CI 管道中可无人值守运行的审计工具。健康评分门禁（85/70 阈值）将"感觉代码质量还行"变成了自动化的工程决策。对不熟悉代码库的审查者而言，qa-only 提供了"全方位了解质量但不冒险"的安全探索路径。

[!tip] 白话小课堂 qa-only 就像一个"只看病不开药"的体检——它帮你跑完所有测试、分析失败、算出健康分，但绝不动你一行代码。和 /qa 的唯一区别就是报告措辞：一个输出 "fixed"（已修），一个输出 "needs attention"（需关注）。

§2 qa-only 的核心哲学——看，但不碰

qa-only vs qa 的根本区别

/qa 的核心循环：测试 → 分诊 → 修复 → 重测 → 报告

/qa-only 的核心循环：测试 → 文档化 → 报告

一个改动代码，一个不改动。就这么简单。

为什么需要只读模式？

三种典型场景：

CI 管道中的自动审计 → PR 合并前自动运行 qa-only → 生成质量报告但不自动修复 → 人类审查者基于报告做决策
不熟悉代码库的审查者 → 你想了解代码质量但不确定改动后果 → qa-only 给你全貌而不冒险 → 你可以手动选择修复哪些
学习与探索 → 在新项目上运行 qa-only 了解测试状态 → 理解质量基线而不改变任何东西 → 为后续 /qa 修复工作做侦察

💡 白话小课堂：qa-only 就像一个"只看病不开药"的体检——它帮你做完所有检查（跑测试、分析失败、算健康分），但绝不动你的代码。

§3 与 /qa 相同的部分——测试引擎不变

共享的工作流阶段

qa-only 复用 /qa 的前半部分流程：

Phase 1-4: 完全相同

→ Initialize: 技术栈检测 → tier 参数设置 → Authenticate: 环境变量检测 → 认证模式 → Orient: 目录扫描 → 测试类型识别 → 覆盖率地图 → Explore: diff-aware 模式 → 测试执行计划

Phase 5-7: 完全相同

→ Execute: 运行测试套件 → 解析结果 → 捕获失败 → Document: 结构化失败报告 → 去重 → 分类 → Wrap Up: 摘要 → 健康评分 → 建议

在这里分岔

/qa: Phase 5-7 → Phase 8 (Triage) → Phase 9 (Fix Loop) → Phase 10 (Final QA) → Phase 11 (Report) qa-only: Phase 5-7 → Phase 11 (Report & Persist) → 结束

§4 严格禁令——qa-only 绝对不能做的事

三条铁律

1. 永不读取源代码

→ /qa 在修复循环中读取被测代码来理解失败原因 → qa-only 只看测试文件和测试输出 → 即使看到明显的拼写错误——不读源码就不能确认 → 目的：完全隔离——阅读源码是"修改"的第一步

2. 永不建议修复

→ /qa 会生成修复建议（diff 格式） → qa-only 只描述失败现象 → 例：/qa 说"将 resul 改为 result" → qa-only 说"变量 resul 未定义——可能是拼写错误" → 注意差异：一个给方案，一个给线索

3. 永不引导测试框架

→ /qa 在无测试框架时创建配置文件 → qa-only 只报告"未检测到测试框架" → 包管理器永不交互（不安装、不更新、不检查）

铁律背后的理由

→ 保证 qa-only 永远不会意外修改代码 → 适合在 CI 中无需人工审查自动运行 → 让审查者放心——这个命令是安全的

⚠️ 避坑指南：三条铁律中最容易被忽略的是第一条——"不读源码"。你可能会想："我就看一眼源码确认一下这个拼写错误，不动它总行吧？

§5 输出差异——报告 vs 行动

/qa 的输出结构

QA Complete — Health Score: 82/100 Test: 45/50 passed (90%) Coverage: 78% Critical: 0 High: 2 fixed, 0 remaining Medium: 3 fixed, 1 skipped Fixes applied: 5 Regression tests: 3 generated

Remaining issues: M-1: utils.test.js:42 — async assertion timeout (skipped)


## qa-only 的输出结构

QA Audit Complete — Health Score: 82/100 Test: 45/50 passed (90%) Coverage: 78% Critical: 0 High: 2 (needs attention) Medium: 1 (lower priority)

Issues found (NOT fixed): H-1: auth.test.js:128 — Token expiry assertion fails at boundary H-2: api.test.js:56 — Response body shape changed M-1: utils.test.js:42 — Async operation timeout Recommendation: Run /qa to fix the 2 HIGH issues


## 关键差异
  → /qa 说"fixed"——行动已完成
  → qa-only 说"needs attention"——需要人的决定
  → /qa 报告"做了什么"
  → qa-only 报告"看到了什么"

§6 在 CI 中嵌入 qa-only

自动化审计流程

典型的 CI 集成：

PR 提交 → CI 触发
gstack qa-only 运行
生成质量报告
健康评分 < 阈值 → PR 被标记为"需要关注"
人类审查者看报告决定： → 健康评分高 → 跳过 /qa，直接审查 → 健康评分中 → 运行 /qa quick 修复明显问题 → 健康评分低 → 发送回开发者

质量门禁建议

→ Health Score >= 85 → 自动通过 → 70 <= Score < 85 → 警告但允许继续 → Score < 70 → 阻止合入（require /qa 修复）

📊 为什么是 85 和 70？ 这两个阈值不是拍脑袋定的。85+ 意味着代码在可维护性、测试覆盖、复杂度等维度上没有显著问题，人工审查的边际收益低。70 以下意味着技术债已经开始拖累团队效率——根据 gstack 对 200+ 项目的基准数据，70 分以下的代码库，平均每个 PR 的审查时间是 85+ 的 2.7 倍。70-85 是"有瑕疵但可接受"的灰色地带，需要人工判断。

与其他 CI 工具的协调

→ ESLint / Rubocop → 风格检查 → qa-only → 测试质量检查 → /health → 代码结构质量 → 三层门禁形成完整的代码质量防线

🔑 核心秘诀：qa-only 在 CI 管道中的价值不是"发现问题"——lint 工具也能发现问题。

§7 人类审查者如何使用 qa-only

审查工作流中的 qa-only

收到 PR 审查请求 ↓ 运行 gstack qa-only (2-5 min) ↓ 查看健康评分 /
≥85 <85 ↓ ↓ 信心高仔细看 HIGH 和 MEDIUM 问题直接审代码 ↓ ↓ 决定行动：快速 approve A) gstack qa quick 自动修 B) 手动标记需修复的问题 C) 确认问题可接受后 approve


## qa-only 对审查者的价值
  → 不替代审查——增强审查
  → 审查者专注于逻辑、设计、架构
  → qa-only 处理机械的质量检查
  → 人机分工：AI 做测试验证，人做工程判断

§8 结构拆解

qa-only 结构模板

核心特征

管理对象: 测试套件的运行结果与失败报告（只读）
核心原则: 零修改铁律——不读源码、不修代码、不引导测试框架
关键设计: 复用 /qa 的 Phase 1-7 测试引擎，在 Phase 8 分岔为纯报告路径；输出措辞从 "fixed" 变为 "needs attention"

通用结构

测试执行层 (Phase 1-4): Initialize → Authenticate → Orient → Explore
结果收集层 (Phase 5-7): Execute → Document → Wrap Up
报告输出层 (Phase 11): Report & Persist → 健康评分 → 结构化建议
CI 门禁层: 健康评分阈值门禁（>=85 通过 / 70-85 警告 / <70 阻止）
审查增强层: 人类审查者基于报告做决策，AI 做机械检查、人做工程判断

§8.5 电商 Skill 案例：全站购买流程端到端自动化验收

🛒 实战案例：某电商平台Q3上线了全新购物车+结算页，需要确保全站购买流程（浏览商品→加购→结算→选择支付方式→确认订单）端到端无回归。之前纯手动验收需要QA工程师花3小时走完所有路径，且只能覆盖happy path。使用/qa-only exhaustive建立自动化端到端验收流水线——只报告不修改代码。

测试覆盖范围：5条关键路径——(1)标准购买流程（浏览→加购→结算→微信支付→成功页）；(2)多商品购买（3件不同商品→购物车→修改数量→使用优惠券→结算）；(3)游客→登录购买（浏览→加购→结算时提示登录→登录→继续结算→支付宝→成功）；(4)变体选择购买（商品详情页→选择颜色/尺码→加购→结算）；(5)优惠券叠加购买（满200-30券+免运费券→验证叠加后金额计算正确）。覆盖桌面端+移动端2个viewport，总计10个测试场景。

执行结果：10个E2E测试场景中——8个PASS、2个FAIL。FAIL #1: 游客→登录购买流程，"登录后继续结算"按钮点击后redirect到首页而非结算页（会话未保存购物车状态）。FAIL #2: 优惠券叠加场景，满200-30和免运费券同时使用时，最终金额=原始价-30而非(原始价-30)+免运费（优惠券叠加计算顺序错误——应该先满减再免运费但代码先免运费再满减导致满减条件不满足）。初始Health Score 62/100⚠️。

qa-only特有优势：qa-only不会尝试修复这2个FAIL——它只报告"这2个场景失败了，原因是什么，出现在哪个文件中，堆栈是什么"。工程师基于报告自行修复——登录后继续结算的session丢失问题（修复：CartContext持久化到localStorage，登录后恢复）和优惠券叠加顺序问题（修复：调整promotion-engine中券排序器先计算满减再计算免运费）。修复后重新运行qa-only→10/10 PASS→Health Score 95/100✅。

CI门禁配置：qa-only嵌入CI pipeline——每次PR合入前自动运行这10个E2E场景→Health Score >= 85才允许合入。运行3个月拦截了4次可能逃逸到生产的购买流程回归bug（平均每月1.3次拦截）。

🔑 启示：qa-only的"只读模式"不是/qa的简化版——它是为不同场景设计的正确工具。当你在CI中运行时，你绝对不希望一个AI自动修改你的生产代码。qa-only做机械检查（运行测试→报告结果），人做工程判断（分析根因→修复代码）——CI门禁中的责任边界必须清晰。

[!info] 参考来源端到端测试自动化参考了 Playwright 的 E2E 测试最佳实践和 Cypress 的 CI 集成模式。

§9 掌握检验

Q1：qa-only 的三条铁律中，"永不读取源代码"为什么被列为第一条？

A) 因为源代码通常不包含有用信息
B) 因为读源码是修改意图的第一步——看了源码后报告措辞会从"观察到"滑向"应该修复为"
C) 因为源代码太大无法读取
D) 因为测试文件已经包含了所有需要的信息

Q2：qa-only 报告的措辞和 /qa 报告的根本差异是什么？

A) /qa 说 "fixed"（行动已完成），qa-only 说 "needs attention"（需要人的决定）
B) qa-only 不生成任何报告
C) /qa 报告更短
D) 两者措辞完全相同

Q3：qa-only 输出中的一个 HIGH 级别问题是"Token expiry assertion fails at boundary"。请分析：qa-only 为什么不能像 /qa 那样建议"将过期时间从 3600 改为 3599 以消除边界竞争"？

Q4：在 CI 管道中嵌入 qa-only 时，建议的门禁阈值是 Health >= 85 自动通过、70-85 警告、<70 阻止。请分析为什么是 85 和 70 这两个阈值——它们分别代表什么工程含义？为什么不设为 90/80 或 80/60？

Q5：人类审查者收到一份 qa-only 报告显示 Health Score 72（FAIR），但手动 inspect 代码后发现逻辑没有问题。审查者应该相信 qa-only 的报告还是自己的判断？请从"qa-only 的角色定位"角度分析这个场景下的正确决策流程。

§10 答案

点击查看答案

Q1：B —— 一旦你读取了源码并确认"确实是一个拼写错误"，你的报告措辞会不可控地从"观察到变量 resul 未定义"滑向"变量 resul 应为 result"——你已经越过了"只报"和"要修"的边界。

Q2：A —— 措辞差异是设计意图而非语义习惯。

Q3：因为 qa-only 不知道 Token 过期的业务语义——是故意设为 3600（1 小时标准规则）还是有特殊理由。如果贸然建议改为 3599，可能"修好"了测试但违反了业务规则（如法规要求 3600 秒）。qa-only 只能描述"测试在边界处失败"，不能判断"边界值应该是多少"——这是人类审查者的决策领域。

Q4：85 分以上 = "非常健康"水平，代表机械质量检查没有发现显著问题，手动审查可以信任。70 分以下 = "技术债务累积到了影响可维护性的程度"，需要干预而非忽视。85/70 而非 90/80——因为 90 太严格会导致大量无辜 PR 被标记（正常的测试波动也可能扣到 90 以下），80 作为下限太宽松（某些类型的 bug 在 80 分时可能仍然存在）。85/70 是灵敏度和特异度的平衡。

Q5：qa-only 的角色是"增强"而非"替代"审查判断。正确的流程：相信自己的代码逻辑判断，但查看 qa-only 报告中 72 分的具体扣分项——是哪些维度拖低了分数？如果扣分项是"Test Coverage 低"（因为大规模重构删了大量旧测试）——这是有上下文解释的合理降分，审查者可决定继续。如果扣分项是"Critical failures: 2"——那即使代码逻辑看起来正确，也应该进一步调查为什么测试失败了。qa-only 提供的是信号，人类做的是解读信号的判断。

（4/5 通过）

L6-21：纯报告式QA —— 只告诉你哪里有问题但不乱改代码