agentleFS
Sign inStart free
peterwangzepeterwangze/software-project-governance/skills/stage-testing/SKILL.md

stage-testing

Skill2 starsChanged 5 months agoMITView on GitHub

测试与质量保障——集成、系统、性能、安全测试。阶段子工作流，可独立使用。

The file

Create a free account to mount
Files
SKILL.md

测试与质量保障 — 子工作流

本文件定义"测试与质量保障"阶段的独立子工作流。用户可单独加载本文件执行测试阶段。

阶段目标

验证系统满足功能和非功能需求。测试阶段的核心产出是"测试报告"——用数据说明系统质量是否达到发布标准。不接受"测试通过了"——只接受带数字的结论。

AI 编程场景特有风险

在 AI 辅助编程项目中，测试阶段存在以下特有风险：

风险说明缓解方向
AI 写的测试太浅AI 生成的测试用例偏向 happy path，缺少边界 case、异常路径和并发场景测试用例审查必须覆盖：边界值、null/空值、并发、超时、异常恢复
测试本身有 bugAI 可能生成"永远通过"的测试（断言太松、mock 过度、未验证真实行为）测试审查：检查断言是否真正验证了预期行为；检查 mock 是否正确模拟了依赖
测试覆盖假象AI 可能生成大量形式化测试（覆盖率数字好看但不验证核心逻辑）覆盖率 ≠ 测试质量；核心路径必须有行为验证测试而非仅存在性测试
性能测试被跳过AI 倾向于只做功能测试，性能和安全测试被忽略强制非功能测试清单；性能基线必须有量化数据
AI 对缺陷的乐观判定AI 倾向于将"不确定"的测试结果判定为"通过"，或降低严重级别缺陷严重级别由用户确认；AI 不可单独将缺陷从"阻塞"降级

独立使用时的目标锚定

当本子工作流被独立加载（非通过 main-workflow.md 总入口加载）时，MUST 在执行阶段活动前完成：

  1. 目标确认：读取 .governance/plan-tracker.md，确认项目立项时定义的量化成功标准
  2. 偏离检查：对照成功标准，确认测试覆盖维度与项目质量目标一致。如发现偏离，MUST 先记录到 .governance/decision-log.md 再继续
  3. 质量底线：测试报告必须包含量化数据（覆盖率/通过率/性能 vs 基线），不接受"测试通过了"（参考 profile 质量要求）

进入条件

  • 开发已完成（G6 通过或条件通过）
  • 有测试计划或测试策略
  • 自动化门禁（lint/test/coverage/security）已通过

活动清单

1. 测试计划确认

活动描述交互边界企业实践
确认测试范围哪些功能需要测试、哪些可以跳过（附跳过理由）需用户确认：测试优先级和跳过决策[Amazon] 显式记录"不测什么"和理由
确认测试类型功能测试、性能测试、安全测试、兼容性测试、AI 代码专项测试自动推荐：基于非功能需求和 AI 项目特征 → 需用户确认通用 + AI 专项
确认通过标准缺陷密度上限、覆盖率阈值、性能基线、安全扫描级别需用户确认[ByteDance 数据驱动] 每个标准必须有数字
PR/FAQ 验证计划对照立项阶段的"用户价值陈述"（PR/FAQ），确认测试如何验证"用户得到了承诺的价值"需用户确认[Amazon Working Backwards] 回头验证是否交付了 PR/FAQ 中承诺的用户价值

2. 功能测试

活动描述交互边界企业实践
测试用例设计基于需求和设计文档编写测试用例，强制覆盖：边界值、null/空、超时、并发、异常恢复自动AI 专项：边界和异常路径不是可选项
测试用例审查检查测试用例是否：断言有意义（非形式化）、mock 正确、覆盖非 happy path自动：静态检查 → 需人工判断[Google] 测试代码与生产代码同等审查标准
功能测试执行逐用例执行并记录结果自动通用实践
缺陷记录每个缺陷有：严重级别、复现步骤、预期结果、实际结果、AI 生成代码标记（如是 AI 生成的代码引入的缺陷）自动：严重级别由 agent 初判 → 需用户确认[华为] 缺陷 48 小时内分配处理人；[ByteDance] 缺陷数据量化统计

3. 非功能测试

活动描述交互边界企业实践
性能测试响应时间（P50/P95/P99）、吞吐量、资源占用 vs 基线自动：执行性能测试套件[ByteDance A/B] 性能数据必须与基线对比
安全测试OWASP Top 10 + API 安全 + 敏感数据暴露自动：运行安全扫描工具[Google] 安全测试是合并门禁的一部分
兼容性测试浏览器/设备/平台/依赖版本兼容性需用户输入：目标平台列表通用实践
AI 代码安全专项检查 AI 生成代码的常见安全问题：提示注入、幻觉 API 调用、不安全的默认配置自动：专项扫描规则AI 专项

4. 测试报告

活动描述交互边界企业实践
汇总测试结果通过率（%）、缺陷统计（按严重级别和模块）、覆盖率（%）、性能数据（vs 基线）自动[ByteDance] 不接受"测试通过了"——必须有数字
评估质量状态逐项对比通过标准：是否达标/未达标/临界自动：与 profile 阈值对比[华为 IPD] 量化评分，≥3 分通过
PR/FAQ 达成验证对照立项时的用户价值陈述，逐条验证是否已实现自动：逐项对照 → 需用户确认[Amazon Working Backwards] 验证是否交付了承诺
输出测试报告包含量化结果、缺陷分析、PR/FAQ 达成、发布建议自动通用实践

5. 缺陷管理

活动描述交互边界企业实践
缺陷优先级排序阻塞 > 关键 > 重要 > 一般 > 建议自动初判 → 需用户确认[华为] 阻塞/关键缺陷 48 小时内处理
缺陷根因分析对阻塞和关键级别缺陷做 5-Why 分析自动：对阻塞/关键缺陷自动触发[华为 RCA] 根因分析，不修复表象
缺陷分配每个缺陷有明确的处理人和截止时间需用户确认[华为] 听得见炮声的人呼唤炮火

产出物标准

产出物格式要求质量标准企业实践来源
测试计划覆盖功能+非功能+AI 专项测试；明确跳过项及理由测试范围明确；通过标准每个有数字[ByteDance] 数据驱动标准
测试用例每个用例有前置条件、步骤、预期结果；覆盖边界/异常路径覆盖核心路径+边界+异常；断言有意义AI 专项 + [Google] 测试同等标准
缺陷清单每个缺陷有严重级别、状态、5-Why（阻塞/关键级）、AI 代码标记阻塞/关键级 = 0；严重级别经用户确认[华为 IPD] + AI 专项
测试报告包含：通过率、覆盖率、性能 vs 基线、缺陷分布、PR/FAQ 达成、发布建议全部量化数据；PR/FAQ 逐条验证结论[Amazon PR/FAQ] + [ByteDance 数据]

退出条件

  • 阻塞/关键缺陷已关闭（= 0），且严重级别经用户确认
  • 回归测试通过（通过率 = 100%）
  • 性能指标达标（各项 vs 基线在可接受范围）
  • 安全测试通过（无 HIGH/CRITICAL 漏洞；AI 安全专项无高危）
  • 测试报告已输出（含全部量化数据 + PR/FAQ 达成验证）
  • 阻塞/关键缺陷已完成 5-Why 根因分析

Gate 映射

本阶段对应 G7 — 测试通过。

Gate 检查项对应活动判定标准自动化判定
阻塞/关键缺陷是否已关闭？缺陷管理阻塞和关键级别缺陷数 = 0，严重级别经用户确认可自动：计数值（严重级别确认需人工）
回归测试是否 100% 通过？功能测试回归测试套件通过率 = 100%可自动：解析测试结果
性能指标是否达标？性能测试P50/P95/P99 在目标范围内，各项 vs 基线不劣化可自动：阈值对比
安全测试是否通过？安全测试无 HIGH/CRITICAL 漏洞；AI 安全专项无高危可自动：解析安全扫描报告
AI 测试用例是否覆盖边界/异常？功能测试测试用例包含边界值、null/空、超时、并发、异常恢复分类可自动：测试用例标签检查
PR/FAQ 是否验证达成？测试报告立项时的用户价值逐条有验证结论可自动：逐项对照 → 需人工判断达成质量
阻塞/关键缺陷是否完成根因分析？缺陷管理每个阻塞/关键缺陷有 5-Why 记录可自动：检查 5-Why 字段完整性

企业实践溯源

本子工作流的设计参考了以下企业实践，每条实践已映射到具体活动步骤：

企业核心实践映射到本工作流
AmazonWorking Backwards (PR/FAQ 验证)测试计划→PR/FAQ 验证计划；测试报告→PR/FAQ 达成验证
Amazon显式记录"不测什么"测试计划→跳过项必须附理由
Google测试代码与生产代码同等审查测试用例审查→断言有意义、非形式化
GoogleBlameless Postmortem缺陷根因分析→5-Why 聚焦流程改进而非追责
Google安全测试是门禁的一部分安全测试→OWASP + AI 安全专项
华为IPD 门控量化评分测试报告→逐项量化对比通过标准
华为RCA 5-Why 根因分析缺陷管理→阻塞/关键缺陷强制 5-Why
华为48 小时缺陷响应缺陷管理→阻塞/关键缺陷 48 小时分配处理人
字节跳动数据驱动——不接受无数字的结论测试报告→全部量化数据；通过率、覆盖率、性能 vs 基线
字节跳动A/B Test 效果对比性能测试→性能 vs 基线对比（新版 vs 旧版）
—AI 编程专项测试用例→强制边界/异常覆盖；测试审查→反浅层测试；安全→AI 代码专项扫描

本项目测试类型对应

本项目（software-project-governance）的资产类型不同于传统软件项目，测试策略适配如下：

传统项目本项目对应工具/方法
单元测试（函数级）verify_workflow.py 子命令的单元测试——测试每个 check 函数的输入/输出infra/tests/test_verify_workflow.py (pytest)
集成测试（模块间）端到端验证——在独立测试项目中运行 governance-init → verify 全流程infra/tests/e2e/
回归测试（bug fix）每次修复 bug 后 MUST 新增 verify 检查项、测试用例 或 e2e 场景在对应修复的 task 中执行
性能测试不适用（skill 加载性能取决于 LLM）—
安全测试Agent 行为安全——prompt injection 抗性检查 + M5 合规verify_workflow.py Check 10

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free