/sdlc-qa-report — 只报告 QA 测试 Skill

/sdlc-qa-report — 只报告 QA 测试

系统化测试 Web 应用，生成包含证据的结构化报告。NEVER 修复任何问题。

与 /sdlc-testing 的区别

| Skill | 功能 | 使用场景 | |------|------|----------| | /sdlc-qa-report | 只报告 | "我想知道有哪些 bug"、"QA 报告"、"检查问题" | | /sdlc-testing | 测+修+验 | "帮我修好这些 bug"、"测试并修复"、"完整 QA 流程" |

参数

| 参数 | 默认值 | 示例 | |------|--------|------| | 目标 URL | 自动检测或必需 | https://myapp.com, http://localhost:3000 | | 模式 | full | --quick | | 输出目录 | .gstack/qa-reports/ | /tmp/qa | | 范围 | 全应用 | 聚焦于结算页面 | | 认证 | 无 | 登录 user@example.com |

模式

Full（提供 URL 时的默认值）

系统性探索。访问每个可达页面。记录 5-10 个有证据的问题。生成健康分数。根据应用大小需要 5-15 分钟。

Quick（`--quick`）

30 秒冒烟测试。访问首页 + 前 5 个导航目标。检查：页面加载？控制台错误？断链？生成健康分数。无详细问题记录。

Diff-aware（特性分支无 URL 时自动）

主要模式 —— 当用户在特性分支上运行 /sdlc-qa-report 而自动：

分析分支 diff 了解变更：

git diff main...HEAD --name-only
git log main..HEAD --oneline

识别受影响页面/路由：
- Controller/路由文件 → 它们服务的 URL 路径
- View/模板/组件文件 → 渲染它们的页面
- Model/Service 文件 → 使用这些模型的页面
- CSS/样式文件 → 包含这些样式表的页面
测试每个受影响页面：
- 导航到页面
- 截图
- 检查控制台错误
- 测试交互（如果有）
报告发现，范围限定在分支变更：
- "测试的变更：N 个受此分支影响的页面/路由"
- 每个页面：是否正常？截图证据
- 相邻页面是否有回归？

工作流

Phase 1: 初始化

检查是否需要浏览工具（如 sdlc-qa-browse）

创建输出目录：

mkdir -p .gstack/qa-reports/screenshots

启动计时器

Phase 2: 认证（如需要）

如果用户指定了认证凭据：

# 导航到登录页
# 填写表单
# 提交
# 验证登录成功

如果用户提供了 cookie 文件：

# 导入 cookies
# 导航到目标 URL

Phase 3: 定向

获取应用地图：

# 导航到目标 URL
# 截图
# 获取链接结构
# 检查控制台错误

检测框架（在报告元数据中记录）：

__next 或 _next/data → Next.js
csrf-token → Rails
wp-content → WordPress
客户端路由 → SPA

Phase 4: 探索

系统性地访问页面。在每个页面：

# 导航到页面
# 截图
# 检查控制台错误

每页探索清单：

视觉扫描 — 查看截图中的布局问题
交互元素 — 点击按钮、链接、控件
表单 — 填写并提交。测试空值、无效值、边界情况
导航 — 检查所有进出路径
状态 — 空状态、加载中、错误、溢出
控制台 — 交互后是否有新的 JS 错误？
响应式 — 检查移动端视口

深度判断： 核心功能（首页、仪表盘、结算、搜索）花更多时间，次要页面（关于、条款、隐私）花更少时间。

Phase 5: 记录

发现问题时立即记录 —— 不要批量处理。

两类证据：

交互 bug（流程中断、按钮失效、表单失败）：

操作前截图
执行操作
结果截图
使用 diff 验证变更效果
编写复现步骤

静态 bug（错别字、布局问题、图片缺失）：

单张标注截图
描述问题

Phase 6: 总结

计算健康分数
编写"Top 3 需修复的问题"
编写控制台健康摘要
更新严重程度计数
填写报告元数据

保存基线：

{
  "date": "YYYY-MM-DD",
  "url": "<target>",
  "healthScore": N,
  "issues": [...],
  "categoryScores": {...}
}

健康分数评分标准

计算每个类别分数（0-100），然后加权平均。

控制台（权重：15%）

0 错误 → 100
1-3 错误 → 70
4-10 错误 → 40
10+ 错误 → 10

链接（权重：10%）

0 断链 → 100
每个断链 → -15（最低 0）

每类别评分（视觉、功能、UX、内容、性能、可访问性）

每个类别从 100 开始。每个发现扣分：

严重问题 → -25
高 → -15
中 → -8
低 → -3 最低 0 分。

权重

| 类别 | 权重 | |------|------| | 控制台 | 15% | | 链接 | 10% | | 视觉 | 10% | | 功能 | 20% | | UX | 15% | | 性能 | 10% | | 内容 | 5% | | 可访问性 | 15% |

最终分数

score = Σ (类别分数 × 权重)

问题严重程度分类

| 严重程度 | 描述 | 示例 | |----------|------|------| | 严重 | 阻止核心功能 | 结算失败、登录中断、数据丢失 | | 高 | 影响重要功能 | 表单验证错误、导航断裂、API 超时 | | 中 | 影响用户体验 | 布局错位、加载缓慢、小 UI bug | | 低 | 视觉/文案问题 | 错别字、间距不一致、小样式问题 |

重要规则

复现是关键。 每个问题至少需要一张截图。无例外。
记录前验证。 重试一次确认问题可复现，不是偶然。
不要包含凭据。 复现步骤中的密码写 [REDACTED]。
增量记录。 发现问题时立即追加到报告。不要批量。
不读源码。 作为用户测试，不是开发者。
每次交互后检查控制台。 不浮出水面的 JS 错误仍然是 bug。
像用户一样测试。 使用真实数据。端到端走完完整流程。
深度优于广度。 5-10 个有证据的问题 > 20 个模糊描述。
不删除输出文件。 截图和报告会累积 —— 这是有意的。
NEVER 修复任何问题。 这是 /sdlc-qa-report 的核心规则。只报告。如需修复，使用 /sdlc-testing。

输出结构

.gstack/qa-reports/
├── qa-report-{domain}-{YYYY-MM-DD}.md
├── screenshots/
│   ├── initial.png
│   ├── issue-001-step-1.png
│   ├── issue-001-result.png
│   └── ...
└── baseline.json

与其他 Skills 的配合

| Skill | 使用场景 | |-------|----------| | /sdlc-qa-report | 只报告 bug | | /sdlc-testing | 测试 + 修复 + 验证 | | /sdlc-code-review | 代码审查 | | /sdlc-qa-browse | 浏览器自动化 |

下一步

发现问题后，如需修复：

/sdlc-testing

Agent Skills: /sdlc-qa-report — 只报告 QA 测试

Install this agent skill to your local

Skill Files