qa-manual-istqb

QA 测试设计与 ISTQB 工件

符合 ISTQB Foundation Level (CTFL) 的完整工作流，面向 QA 测试工程师，涵盖： 测试计划 → 测试分析 → 测试设计 → 测试实现 → 测试执行 → 测试完成

何时使用此技能

• 根据需求、用户故事或验收标准，起草可直接填写的 QA 交付物
• 创建或评审测试计划和测试策略
• 根据需求生成测试条件和测试用例
• 应用测试设计技术（EP、BVA、决策表、状态转换、用例）
• 编写缺陷报告并管理缺陷生命周期
• 根据风险选择测试用例，构建回归测试套件
• 创建可追溯性矩阵（需求 ↔ 测试 ↔ 缺陷）
• 使用测试章程开展探索式测试
• 使用 ISTQB 技术估算测试工作量
• 通过静态测试实践评审测试工件
• 选择适合自动化的候选项，并准备可追溯的 Playwright 脚手架

不适用场景

• 编写或维护有版本控制的 Playwright 规格代码（请使用 playwright-e2e-testing）。
• 编写 Selenium/Java 测试（请使用 webapp-selenium-testing）。
• 操作实时浏览器进行调试（请使用 playwright-cli），或管理现有回归测试套件的 CI（请使用 playwright-regression-testing）。
• 对抗式策略评审——这是 grill-me-qa 技能的用途；此技能用于产出工件，而非质询工件。

前置条件

要求	说明
Node.js 18+	CLI 脚本和 Playwright 所需
Playwright	使用 npm init playwright@latest 进行自动化
文本编辑器	用于创建/编辑 Markdown 和 CSV 工件
Git	建议用于测试工件的版本控制

快速入门（任选一项）

• 创建测试计划：使用 templates/test-plan.md 作为起点。
• 创建测试总结报告：使用 templates/test-summary-report.md。
• 生成测试用例：使用 templates/test-cases.csv，并根据测试依据（需求、用户故事、验收标准）填写。
• 创建缺陷报告：使用 templates/bug-report.md。
• 创建缺陷日志：使用 templates/bug-log.csv。
• 创建可追溯性矩阵：使用 templates/traceability-matrix.csv。
• 构建回归测试套件定义：使用 templates/regression-suite.md。
• 搭建 Playwright 测试脚手架：使用 templates/playwright-spec.ts，并根据被测系统进行调整。
• 开展探索式测试：使用 templates/exploratory-charter.md 设置时间限制并记录结果。

如果在本地运行，请使用随附的 CLI 生成工件：

node scripts/qa_artifacts.mjs list
node scripts/qa_artifacts.mjs create test-plan --out specs --project "My App" --release "R1"
node scripts/qa_artifacts.mjs create test-cases --out specs --feature "Checkout"
node scripts/qa_artifacts.mjs create bug-report --out specs/bugs --title "Search returns 500"

需收集的输入（缺少时请询问）

• 测试依据：需求、用户故事、验收标准、设计、风险登记册、缺陷历史。
• 范围：范围内/范围外的功能、目标平台/浏览器/设备、语言区域、无障碍、集成。
• 质量风险：可能出现的故障、影响、可能性、法规/合规要求、关键用户旅程。
• 约束条件：截止日期、环境、数据可用性、工具、访问权限/角色、CI/CD 预期。
• 定义：严重程度与优先级等级、需覆盖的测试级别和测试类型、进入/退出标准。

工作流

1) 创建测试计划（和/或测试策略）

1. 根据测试依据确定测试目标、范围、假设和约束条件。
2. 定义测试级别和类型（视情况包括功能测试、与变更相关的测试及关键非功能测试）。
3. 为各个领域选择测试设计技术（参见 references/test-design-techniques.md）。
4. 明确环境、测试数据、工具和配置管理需求。
5. 定义进入/退出标准、交付物以及报告频率/指标。
6. 添加风险矩阵和缓解措施；据此确定测试优先级（基于风险的测试）。

使用：templates/test-plan.md（包含详细章节和检查清单）。

2）生成测试条件和测试用例

1. 在编写分步用例之前，先将测试依据转换为测试条件（要测试什么）。
2. 针对每个条件选择一种技术：
   • 对输入／验证使用等价类划分和边界值。
   • 对规则组合使用决策表。
   • 对生命周期／流程使用状态转换。
   • 对端到端旅程使用用例／场景测试。
   • 使用探索式测试会话快速了解情况（参见 templates/exploratory-charter.md）。
3. 编写原子性强、清晰明确且可追溯到需求／用户故事 ID 的测试用例。
4. 添加可观察、可衡量的预期结果（定义测试预言）。
5. 添加优先级和风险标签，以支持基于风险的回归测试选择。
6. 根据稳定性和价值标准标记自动化候选项（参见 references/automation-playwright-best-practices.md）。

使用：templates/test-cases.csv。

3）准备自动化候选项和 Playwright 脚手架

1. 根据稳定性、价值和风险标准选择候选项（参见 references/automation-playwright-best-practices.md）。
2. 从 templates/playwright-spec.ts 创建可追溯的脚手架，其中包含测试用例 ID 和套件标签。
3. 使用 playwright-e2e-testing 实现并维护版本化的 UI 规格、固件和测试基础设施。

4）构建和维护回归测试套件

1. 定义套件层级（示例）：smoke（关键路径）、sanity（构建验证）、regression（广泛覆盖）、full（发布）。
2. 根据风险、频率、关键性和缺陷历史选择测试（而非仅依据覆盖率）。
3. 统一标记测试，并记录选择规则和负责人。
4. 定期审查套件：移除过时的覆盖，补充对漏检缺陷和高风险变更的覆盖。

使用：templates/regression-suite.md 和 references/regression-suite-strategy.md。

5）创建 Bug 报告并有效记录 Bug

1. 确保能够稳定复现；将步骤精简到最少；记录波动情况（频率）和影响范围。
2. 记录环境详情（构建／应用版本、操作系统、浏览器／设备、账户／角色、数据条件）。
3. 描述预期行为与实际行为；说明影响；统一设置严重性和优先级。
4. 附上证据（屏幕截图、控制台日志、网络跟踪、Playwright 跟踪），并链接相关测试／需求。
5. 跟踪生命周期：分类记录、负责人、修复版本、验证步骤和结果、关闭标准。

使用：templates/bug-report.md 和 references/bug-report-quality.md。

6）开展静态测试（评审）

1. 尽早安排评审（左移）：需求、设计、测试计划、测试用例。
2. 使用检查清单确保一致性（参见 references/static-testing.md）。
3. 记录发现的问题及其严重性和可执行性。
4. 单独跟踪静态测试发现的缺陷（预防与检测）。

使用：references/static-testing.md 中的评审检查清单和技术。

7）估算测试工作量

1. 确定影响因素：范围、复杂度、风险、团队经验、工具成熟度。
2. 应用估算技术（参见 references/test-estimation.md）：
   • 专家判断／历史数据
   • 测试点分析
   • 工作分解结构
3. 为风险和未知因素预留应急余量。
4. 随着项目推进，审查并完善估算。

使用：references/test-estimation.md 中的技术和公式。

8）监控测试进度和指标

1. 跟踪执行指标：计划数、已执行数、通过数、失败数、阻塞数。
2. 监控缺陷指标：按严重性／优先级统计发现数、已修复数、未解决数。
3. 计算测试覆盖率：已覆盖的需求、已测试的风险区域。
4. 定期报告状态，并尽早升级上报阻塞问题。

使用：references/test-monitoring-metrics.md 中的指标定义和仪表板。

质量关卡（自检）

• 测试计划包含范围、方法、风险、环境、进入／退出标准、交付物和度量指标。
• 测试用例可追溯、原子化、确定，并包含明确的判定依据和数据。
• 自动化易于维护（定位器稳定、偶发失败极少、测试相互独立、断言清晰）。
• 回归测试基于风险、带有标签，并经过筛选，且有明确的添加／移除规则。
• 缺陷报告可复现、可执行，并包含证据、环境和影响。
• 静态测试审查有文档记录，且跟踪发现项直至解决。
• 估算包含缓冲时间，并随着范围明确而逐步细化。

故障排查

问题	原因	解决方案
测试用例缺乏可追溯性	缺少需求 ID	添加 requirement_id 列；关联用户故事／验收标准
缺陷报告被拒绝	复现步骤不足	使用最少步骤；包含确切数据和环境
回归测试套件太慢	测试太多，缺少优先级划分	按风险筛选；分为冒烟／健全性／完整测试
自动化测试不稳定	定位器或时序不稳定	使用 data-testid；避免休眠；使用 Playwright 自动等待
测试估算不准确	范围蔓延、遗漏风险	增加缓冲时间；范围变更时重新估算
审查未发现缺陷	审查浮于表面	使用检查清单；安排充足时间；轮换审查人员
测试判定依据不明确	缺少预期结果	根据需求、规则或参考系统定义判定依据

捆绑资源

模板（templates/）

模板	用途
test-plan.md	符合 ISTQB 的测试计划结构
test-summary-report.md	测试周期结束总结和签署确认
test-cases.csv	带有可追溯性的测试用例库
test-conditions.md	根据测试依据推导出的测试条件
traceability-matrix.csv	需求 ↔ 测试 ↔ 缺陷映射
bug-report.md	详细缺陷报告
bug-log.csv	缺陷跟踪日志
regression-suite.md	测试套件定义和筛选规则
exploratory-charter.md	基于会话的探索性测试
playwright-spec.ts	Playwright 测试脚手架
test-environment-checklist.md	环境就绪情况验证
risk-assessment-matrix.md	质量风险识别和优先级排序

参考资料（references/）

参考资料	内容
test-design-techniques.md	等价类划分、边界值分析、决策表、状态转换、用例
experience-based-techniques.md	错误猜测、基于检查清单的测试、探索性测试
static-testing.md	评审、走查、检查
test-levels-types.md	单元、集成、系统、验收；功能、非功能
test-estimation.md	估算技术与影响因素
test-monitoring-metrics.md	进度跟踪与质量指标
risk-based-testing.md	风险识别、分析与缓解
istqb-glossary.md	ISTQB 关键术语
test-process-and-deliverables.md	测试流程阶段与产出
automation-playwright-best-practices.md	Playwright 实现指南
regression-suite-strategy.md	测试套件管理与优化
bug-report-quality.md	有效缺陷报告
defect-lifecycle.md	缺陷状态与工作流

脚本（scripts/）

脚本	用途
qa_artifacts.mjs	从模板生成 QA 工件的命令行工具

---

危险信号

• 生成的测试用例未关联需求或风险——无法追溯的覆盖只是表面功夫。
• 缺少复现步骤、预期结果与实际结果或环境信息的 Bug 报告——开发人员无法使用。
• 凭直觉而非风险／变更分析选择回归测试套件——既浪费精力，也会遗漏回归问题。
• 测试计划没有进入／退出标准或工作量估算——无法管理测试执行。
• 将此工件生成技能与策略评审混为一谈（对抗性评审请使用 grill-me-qa）。

---

验证

• 测试用例符合 ISTQB 结构——每个用例都包含：ID、描述、前置条件、步骤、预期结果（执行后填写实际结果）
• 维护覆盖矩阵——将需求映射到测试用例；确保没有未覆盖的需求
• 维护可追溯性——每个测试用例都关联一个需求或用户故事