Back to Details

sdlc-testing

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Platform Notes

平台说明

  • Optional helper plugins may help in some environments, but they must not be treated as required for this skill.
  • 可选的辅助插件可能在部分环境中提供帮助，但不得将其视为使用本技能的必需条件。

SDLC Testing Skill

SDLC测试技能

<!-- dual-compat-start -->
<!-- dual-compat-start -->

Use When

适用场景

  • Generate Testing & Quality documentation for SDLC projects. Compliant with BS ISO/IEC/IEEE 29119-3:2013 (supersedes IEEE 829:2008 and BS 7925-2:1998). Covers Software Test Plan, Test Case Specifications (with normative 29119-3 fields), V&V Plan...
  • The task needs reusable judgment, domain constraints, or a proven workflow rather than ad hoc advice.
  • 为SDLC项目生成测试与质量文档。符合BS ISO/IEC/IEEE 29119-3:2013标准（取代IEEE 829:2008和BS 7925-2:1998）。涵盖软件测试计划、测试用例规范（包含29119-3标准规定的必填字段）、验证与确认（V&V）计划……
  • 任务需要可复用的判断逻辑、领域约束或经过验证的工作流，而非临时建议。

Do Not Use When

不适用场景

  • The task is unrelated to 
    sdlc-testing
    or would be better handled by a more specific companion skill.
  • The request only needs a trivial answer and none of this skill's constraints or references materially help.
  • 任务与
    sdlc-testing
    无关，或更适合由更专业的配套技能处理。
  • 请求仅需要简单答案，本技能的约束条件或参考资料无法提供实质性帮助。

Required Inputs

必需输入

  • Gather relevant project context, constraints, and the concrete problem to solve; load 
    templates
    only as needed.
  • Confirm the desired deliverable: design, code, review, migration plan, audit, or documentation.
  • 收集相关项目背景、约束条件以及具体要解决的问题；仅在需要时加载
    templates
    模板。
  • 确认期望的交付物：设计方案、代码、评审报告、迁移计划、审计报告或文档。

Workflow

工作流

  • Read this 
    SKILL.md
    first, then load only the referenced deep-dive files that are necessary for the task.
  • Apply the ordered guidance, checklists, and decision rules in this skill instead of cherry-picking isolated snippets.
  • Produce the deliverable with assumptions, risks, and follow-up work made explicit when they matter.
  • 首先阅读本
    SKILL.md
    文档，然后仅加载完成任务所需的相关深度参考文件。
  • 应用本技能中有序的指导、检查清单和决策规则，而非随意挑选孤立的片段。
  • 生成交付物时，若相关需明确说明假设条件、风险以及后续工作。

Quality Standards

质量标准

  • Keep outputs execution-oriented, concise, and aligned with the repository's baseline engineering standards.
  • Preserve compatibility with existing project conventions unless the skill explicitly requires a stronger standard.
  • Prefer deterministic, reviewable steps over vague advice or tool-specific magic.
  • 输出内容需以执行为导向、简洁明了，并与仓库的基础工程标准保持一致。
  • 除非技能明确要求更高标准，否则需与现有项目约定保持兼容。
  • 优先采用可确定、可评审的步骤，而非模糊建议或工具专属的“魔法操作”。

Anti-Patterns

反模式

  • Treating examples as copy-paste truth without checking fit, constraints, or failure modes.
  • Loading every reference file by default instead of using progressive disclosure.
  • 将示例视为可直接复制粘贴的标准内容，而不检查是否适配、约束条件或失败模式。
  • 默认加载所有参考文件，而非逐步按需披露。

Outputs

输出物

  • A concrete result that fits the task: implementation guidance, review findings, architecture decisions, templates, or generated artifacts.
  • Clear assumptions, tradeoffs, or unresolved gaps when the task cannot be completed from available context alone.
  • References used, companion skills, or follow-up actions when they materially improve execution.
  • 符合任务要求的具体结果：实施指导、评审发现、架构决策、模板或生成的工件。
  • 若仅通过现有上下文无法完成任务，需明确说明假设条件、权衡方案或未解决的缺口。
  • 列出使用的参考资料、配套技能或后续行动，若它们能实质性提升执行效果。

Evidence Produced

生成的证据

CategoryArtifactFormatExample
CorrectnessTest plan compliant with BS ISO/IEC/IEEE 29119-3:2013Markdown doc per 
skill-composition-standards/references/test-plan-template.md
aligned to the IEEE testing standard
docs/sdlc/test-plan-checkout.md
类别工件格式示例
正确性符合BS ISO/IEC/IEEE 29119-3:2013标准的测试计划遵循IEEE测试标准的Markdown文档，参考
skill-composition-standards/references/test-plan-template.md
docs/sdlc/test-plan-checkout.md

References

参考资料

  • Use the 
    templates/
    directory when the task needs a structured deliverable.
<!-- dual-compat-end -->
Generate a complete Testing & Quality documentation suite for software development projects. This skill produces 5 documents that establish the testing baseline, define test cases, verify and validate the system, report results, and standardize peer reviews.
  • 当任务需要结构化交付物时，使用
    templates/
    目录下的模板。
<!-- dual-compat-end -->
为软件开发项目生成完整的测试与质量文档套件。本技能可生成5类文档，用于建立测试基准、定义测试用例、验证系统、报告结果以及标准化同行评审流程。

Load Order

加载顺序

  1. Load 
    world-class-engineering
    .
  2. Load 
    advanced-testing-strategy
    .
  3. Load this skill to produce formal test documentation and release evidence.
  1. 加载
    world-class-engineering
    。
  2. 加载
    advanced-testing-strategy
    。
  3. 加载本技能以生成正式测试文档和发布证据。

Executable Testing Standard

可执行测试标准

Testing documentation must make these explicit:
  • commit-stage checks versus deeper validation
  • deterministic evidence and residual risk
  • telemetry that will detect escaped failure after release
  • Go/No-Go inputs, rollback assumptions, and observation windows
测试文档必须明确以下内容：
  • 提交阶段检查与深度验证的区别
  • 确定性证据与剩余风险
  • 可检测发布后逃逸故障的遥测机制
  • 上线/不上线（Go/No-Go）输入条件、回滚假设以及观察窗口

When to Use

适用场景

  • Establishing a testing strategy for a SaaS project
  • Writing formal test plans aligned with IEEE 829
  • Creating test case specifications with traceability to requirements
  • Planning verification and validation activities (V&V)
  • Documenting validation test results for release decisions
  • Standardizing peer review and code inspection processes
  • Preparing for phase gate reviews that require test evidence
  • 为SaaS项目制定测试策略
  • 编写符合IEEE 829标准的正式测试计划
  • 创建可追溯至需求的测试用例规范
  • 规划**验证与确认（V&V）**活动
  • 为发布决策记录验证测试结果
  • 标准化同行评审与代码检查流程
  • 为需要测试证据的阶段门评审做准备

When NOT to Use

不适用场景

  • Writing actual test code (unit tests, integration tests) -- use 
    android-tdd
    skill instead
  • Validating AI-generated code -- use 
    ai-error-handling
    skill (5-layer validation)
  • Planning security testing only -- use 
    vibe-security-skill
    for security patterns
  • Planning a single feature -- use 
    feature-planning
    skill (includes testing strategy)
  • Creating project plans -- use 
    sdlc-planning
    skill (SDP, QA Plan, SRS)
  • Designing architecture -- use 
    sdlc-design
    skill
  • 编写实际测试代码（单元测试、集成测试）——请改用
    android-tdd
    技能
  • 验证AI生成的代码——请改用
    ai-error-handling
    技能（5层验证机制）
  • 仅规划安全测试——请使用
    vibe-security-skill
    获取安全模式
  • 规划单个功能——请使用
    feature-planning
    技能（包含测试策略）
  • 创建项目计划——请使用
    sdlc-planning
    技能（SDP、QA计划、SRS）
  • 设计架构——请使用
    sdlc-design
    技能

Document Inventory

文档清单

#DocumentFilePurposeAudiencePhase
1Software Test Plan
templates/software-test-plan.md
Testing strategy, tools, environments, schedule, completion criteriaQA leads, PMs, devsAfter SRS + SDD
2Test Case Specifications
templates/test-case-specifications.md
Normative 29119-3 test cases: ID, objective, priority, traceability, preconditions, input, expected resultTest engineers, devsDuring development
3Validation & Verification Plan
templates/validation-verification-plan.md
V&V approach (built right + right product)QA mgrs, PMs, complianceAfter SRS + SDD
4Validation Test Report
templates/validation-test-report.md
Test execution results and Go/No-Go release decisionPMs, stakeholders, QABefore release
5Peer Review Report
templates/peer-review-report.md
Code, design, and document review findingsDev team, tech leadsThroughout SDLC
6Incident Report
templates/incident-report.md
Anomaly record: ID, timing, context, description, impact, urgency, statusQA, dev leadsDuring execution
7Test Completion Report
templates/test-completion-report.md
Test summary, deviations, completion criteria met, residual risks, lessons learnedPMs, stakeholders, complianceEnd of test phase
序号文档名称文件用途受众阶段
1软件测试计划
templates/software-test-plan.md
测试策略、工具、环境、进度、完成标准QA负责人、项目经理、开发人员SRS与SDD完成后
2测试用例规范
templates/test-case-specifications.md
符合29119-3标准的测试用例：ID、目标、优先级、可追溯性、前置条件、输入、预期结果测试工程师、开发人员开发过程中
3验证与确认计划
templates/validation-verification-plan.md
V&V方法（正确构建+构建正确产品）QA经理、项目经理、合规人员SRS与SDD完成后
4验证测试报告
templates/validation-test-report.md
测试执行结果与上线/不上线（Go/No-Go）发布决策项目经理、利益相关者、QA发布前
5同行评审报告
templates/peer-review-report.md
代码、设计与文档评审发现开发团队、技术负责人SDLC全流程
6事件报告
templates/incident-report.md
异常记录：ID、时间、上下文、描述、影响、紧急程度、状态QA、开发负责人执行过程中
7测试完成报告
templates/test-completion-report.md
测试总结、偏差、完成标准达成情况、剩余风险、经验教训项目经理、利益相关者、合规人员测试阶段结束时

Standards Basis

标准依据

This skill generates documentation compliant with BS ISO/IEC/IEEE 29119-3:2013, the current international standard for software test documentation. It supersedes IEEE 829:2008 and BS 7925-2:1998. Key structural difference: 29119-3 defines a strict document hierarchy — Organizational Test Strategy → Project Test Plan → Sub-process Test Plans → Test Design Specification → Test Case Specification → Incident Report → Test Completion Report. Annex T provides clause-level cross-walks from legacy standards for migration.
Normative Test Case Fields (BS 29119-3 §7.3): Every test case must include: (1) Unique ID, (2) Objective/Purpose, (3) Priority (H/M/L), (4) Traceability to requirement ID, (5) Preconditions (exact system state), (6) Input (exact stimulus), (7) Expected Result (deterministic pass/fail — the test oracle), (8) Actual Result (populated during execution), (9) Test Result (Pass / Incident Report number).
Test Oracle Rule: Every expected result must be specific enough to yield an unambiguous Pass or Fail without interpretation. If the expected result depends on judgment ("the response looks reasonable"), the requirement has not been adequately specified — flag 
[VERIFIABILITY-FAIL]
and return to Skill 05 for clarification.
本技能生成的文档符合BS ISO/IEC/IEEE 29119-3:2013，即当前软件测试文档的国际标准。它取代了IEEE 829:2008和BS 7925-2:1998。核心结构差异：29119-3定义了严格的文档层级——组织测试策略→项目测试计划→子流程测试计划→测试设计规范→测试用例规范→事件报告→测试完成报告。附录T提供了从旧标准迁移的条款级对照表。
**29119-3标准规定的测试用例必填字段（BS 29119-3 §7.3）：**每个测试用例必须包含：(1) 唯一ID，(2) 目标/用途，(3) 优先级（高/中/低），(4) 与需求ID的可追溯性，(5) 前置条件（精确系统状态），(6) 输入（精确刺激），(7) 预期结果（确定性通过/失败——测试准则），(8) 实际结果（执行时填写），(9) 测试结果（通过 / 事件报告编号）。
**测试准则规则：**每个预期结果必须足够具体，以明确判定通过或失败，无需主观解读。若预期结果依赖判断（如“响应看起来合理”），则需求未被充分定义——标记
[VERIFIABILITY-FAIL]
并返回至Skill 05以获取澄清。

Testing Philosophy

测试理念

TDD-First Development

优先采用TDD开发

All production code follows the Red-Green-Refactor cycle. Tests are written before implementation. Reference the 
android-tdd
skill for the complete TDD workflow.
所有生产代码遵循红-绿-重构循环。先编写测试再实现功能。完整TDD工作流请参考
android-tdd
技能。

Test Pyramid (70/20/10)

测试金字塔（70/20/10）

        /  UI/E2E  \       10% - Compose Testing, Espresso, browser E2E
       /------------\
      / Integration  \     20% - Room+MockWebServer, API with real DB
     /----------------\
    /   Unit Tests     \   70% - JUnit 5, MockK, PHPUnit (fast, isolated)
   /====================\
        /  UI/E2E  \       10% - Compose Testing、Espresso、浏览器端E2E测试
       /------------\
      / 集成测试  \     20% - Room+MockWebServer、带真实数据库的API测试
     /----------------\
    /   单元测试     \   70% - JUnit 5、MockK、PHPUnit（快速、隔离）
   /====================\

Shift-Left Testing

左移测试

Move testing activities as early as possible in the SDLC:
ActivityTraditional PhaseShift-Left Phase
Unit testingAfter codingDuring coding (TDD)
Security testingPre-releaseDuring design + development
Performance testingPre-releaseDuring development (benchmarks)
Code reviewAfter feature completePer-commit (PR-based)
Requirements reviewAfter SRS finalizedDuring requirements gathering
尽可能将测试活动提前至SDLC的早期阶段：
活动传统阶段左移后阶段
单元测试编码后编码期间（TDD）
安全测试发布前设计与开发期间
性能测试发布前开发期间（基准测试）
代码评审功能完成后每次提交（基于PR）
需求评审SRS定稿后需求收集期间

Generation Workflow

生成工作流

Generate documents in this order. Each builds on the previous.
Prerequisite: SRS from sdlc-planning + SDD from sdlc-design
    |
Step 1: Software Test Plan (overall strategy)
    |
Step 2: Validation & Verification Plan (V&V approach)
    |
Step 3: Test Case Specifications (detailed test cases)
    |
    [--- Development & testing execution happens here ---]
    |
Step 4: Peer Review Reports (during development)
    |
Step 5: Validation Test Report (before release)
按以下顺序生成文档，每个文档基于前一个文档构建。
前置条件：来自sdlc-planning的SRS + 来自sdlc-design的SDD
    |
步骤1：软件测试计划（整体策略）
    |
步骤2：验证与确认计划（V&V方法）
    |
步骤3：测试用例规范（详细测试用例）
    |
    [--- 开发与测试执行在此阶段进行 ---]
    |
步骤4：同行评审报告（开发期间）
    |
步骤5：验证测试报告（发布前）

Prerequisites

前置条件

InputSourceRequired?
Software Requirements Spec (SRS)
sdlc-planning
output		Yes
Software Design Document (SDD)
sdlc-design
output		Recommended
Quality Assurance Plan
sdlc-planning
output		Recommended
Risk Management Plan
sdlc-planning
output		Recommended
Feature specifications
feature-planning
output		If feature-level
输入来源是否必需？
软件需求规格说明书（SRS）
sdlc-planning
输出		是
软件设计文档（SDD）
sdlc-design
输出		推荐
质量保证计划
sdlc-planning
输出		推荐
风险管理计划
sdlc-planning
输出		推荐
功能规格说明
feature-planning
输出		若为功能级需求则需要

Testing Layers Overview

测试层概述

Unit Testing

单元测试

PlatformFrameworkScopeSpeed
AndroidJUnit 5 + MockK + TurbineViewModels, UseCases, Repositories, Mappers<1ms each
PHPPHPUnitServices, validators, business logic, helpers<10ms each
平台框架范围速度
AndroidJUnit 5 + MockK + TurbineViewModels、UseCases、Repositories、Mappers每个<1ms
PHPPHPUnit服务、验证器、业务逻辑、辅助工具每个<10ms

Integration Testing

集成测试

PlatformFrameworkScope
AndroidRoom in-memory DB + MockWebServerDAO queries, API contracts, auth flows
PHPPHPUnit + real MySQL test DBAPI endpoints, stored procedures, multi-table ops
平台框架范围
AndroidRoom内存数据库 + MockWebServerDAO查询、API契约、认证流程
PHPPHPUnit + 真实MySQL测试数据库API端点、存储过程、多表操作

UI / E2E Testing

UI / E2E测试

PlatformFrameworkScope
AndroidCompose Testing + EspressoScreen rendering, navigation, user flows
WebBrowser testing (manual + automated)CRUD workflows, form validation, responsive layout
平台框架范围
AndroidCompose Testing + Espresso屏幕渲染、导航、用户流程
Web浏览器测试（手动+自动化）CRUD工作流、表单验证、响应式布局

User Acceptance Testing (UAT)

用户验收测试（UAT）

Distinguish Alpha and Beta testing explicitly in the Test Plan:
StageLocationTestersFocus
AlphaControlled environment (internal/QA lab)Internal testers, stakeholdersFunctional correctness, defect discovery
BetaReal-world environment (staging/limited production)Selected external usersReal-world usability, edge-case discovery, performance under real load
在测试计划中明确区分Alpha和Beta测试：
阶段地点测试人员重点
Alpha受控环境（内部/QA实验室）内部测试人员、利益相关者功能正确性、缺陷发现
Beta真实环境（预发布/有限生产环境）选定的外部用户真实场景可用性、边缘案例发现、真实负载下的性能

Seven-Step Defect Resolution Protocol (Rex Black, 2009)

七步缺陷解决流程 (Rex Black, 2009)

Every bug report triggers this handoff sequence. The boundary between Step 3 and Step 4 is the critical management line — testers own isolation; developers own debugging.
StepOwnerAction
1TesterReproduce — determine exact minimal sequence; check for intermittence
2TesterDiscriminate — test bug or system bug?
3TesterIsolate — identify external factors (config, data, workflows) affecting symptoms
4DeveloperRoot cause — find cause in code, hardware, network, or environment
5DeveloperRepair — fix without introducing new problems
6DeveloperVerify fix — confirm the fix is clean before handoff
7TesterConfirm + Regression — does it pass the failing test? Does everything else still work?
If the fix fails Step 7: reopen the bug report. If it passes but breaks a different test: open a new bug report.
每个Bug报告都会触发以下交接流程。步骤3和步骤4之间的界限是关键管理节点——测试人员负责隔离问题；开发人员负责调试。
步骤负责人操作
1测试人员重现 ——确定精确的最小操作序列；检查是否存在间歇性问题
2测试人员区分 ——是测试Bug还是系统Bug？
3测试人员隔离 ——识别影响症状的外部因素（配置、数据、工作流）
4开发人员根本原因 ——在代码、硬件、网络或环境中找到问题根源
5开发人员修复 ——修复问题且不引入新问题
6开发人员验证修复 ——在交接前确认修复干净
7测试人员确认+回归测试 ——修复后是否通过之前失败的测试？其他功能是否仍正常工作？
若修复未通过步骤7：重新打开Bug报告。若修复通过但破坏了其他测试：新建Bug报告。

Regression Testing

回归测试

Regression testing is a first-class test type and must be documented separately in the Test Plan. Define: the regression suite scope (which previously-passing test cases are re-run), the trigger conditions (every PR merge, every release candidate), and the acceptable pass rate before proceeding.
回归测试是一级测试类型，必须在测试计划中单独记录。定义：回归套件范围（重新运行哪些之前通过的测试用例）、触发条件（每次PR合并、每个发布候选版本）以及继续执行前的可接受通过率。

Test Data Management

测试数据管理

The Test Plan must include a 
## Test Data Management
section covering: how test fixtures are created, how tenant isolation is maintained in test data (separate 
franchise_id
values per test scenario), how sensitive data is anonymized in non-production environments, and who owns test data lifecycle.
测试计划必须包含
## 测试数据管理
章节，涵盖：测试固定数据的创建方式、测试数据中的租户隔离如何维护（每个测试场景使用独立的
franchise_id
值）、非生产环境中敏感数据如何匿名化，以及测试数据生命周期的负责人。

Test Data Readiness Report (B-08)

测试数据就绪报告（B-08）

Before test execution begins, confirm:
  • Test fixtures created for all scenarios (normal, boundary, error)
  • Tenant isolation verified — each test scenario uses a distinct 
    franchise_id
    (or equivalent)
  • Sensitive production data anonymised in all non-production environments
  • Test data owner identified and data lifecycle documented
  • Rollback/reset procedure defined for test data after execution
测试执行开始前，确认：
  • 已为所有场景（正常、边界、错误）创建测试固定数据
  • 已验证租户隔离——每个测试场景使用不同的
    franchise_id
    （或等效标识）
  • 所有非生产环境中的敏感生产数据已匿名化
  • 已确定测试数据负责人并记录数据生命周期
  • 已定义测试执行后的测试数据回滚/重置流程

Test Environment Readiness Report (B-08)

测试环境就绪报告（B-08）

Before test execution begins, confirm:
  • All hardware/software components match production specifications
  • All software components under formal CM control with release notes
  • Test environment access provisioned for all testers
  • Monitoring and logging enabled in test environment
  • Smoke test completed successfully (entry criterion for system test phase)
  • Config ID documented (coded identifier for the exact environment composition)
测试执行开始前，确认：
  • 所有硬件/软件组件与生产规格匹配
  • 所有软件组件处于正式配置管理（CM）控制下并附带发布说明
  • 已为所有测试人员提供测试环境访问权限
  • 测试环境已启用监控与日志功能
  • 已成功完成冒烟测试（系统测试阶段的进入标准）
  • 已记录配置ID（精确环境组成的编码标识）

Security Testing

安全测试

AreaMethodReference
Tenant isolationAutomated + manual: cross-tenant access denied
vibe-security-skill
Auth bypassToken manipulation, session hijacking attempts
dual-auth-rbac
InjectionSQL injection, XSS, CSRF payloadsOWASP Top 10
Data exposureAPI response auditing, error message review
vibe-security-skill
领域方法参考
租户隔离自动化+手动测试：禁止跨租户访问
vibe-security-skill
认证绕过令牌篡改、会话劫持尝试
dual-auth-rbac
注入攻击SQL注入、XSS、CSRF载荷OWASP Top 10
数据泄露API响应审计、错误消息审查
vibe-security-skill

Performance Testing

性能测试

MetricTargetTool
API response time< 500ms (P95)curl timing, load test tools
Web page load< 2s (first contentful paint)Browser DevTools, Lighthouse
Android cold start< 3sAndroid Profiler
Database query< 100ms (P95)MySQL slow query log, EXPLAIN
指标目标工具
API响应时间< 500ms（P95）curl计时、负载测试工具
网页加载时间< 2s（首次内容绘制）浏览器开发者工具、Lighthouse
Android冷启动时间< 3sAndroid Profiler
数据库查询时间< 100ms（P95）MySQL慢查询日志、EXPLAIN

Cross-References to Existing Skills

与现有技能的交叉引用

Upstream Skills (use BEFORE this skill)

上游技能（在本技能之前使用）

SkillRelationship
sdlc-planning
Provides SRS (requirement IDs for traceability), QA Plan (quality standards), Risk Plan (test-specific risks).
sdlc-design
Provides SDD (architecture to verify), database design (schema to test), API design (contracts to validate).
project-requirements
Raw requirements gathered via interview. Feed into SRS before creating test docs.
技能关系
sdlc-planning
提供SRS（用于可追溯性的需求ID）、QA计划（质量标准）、风险计划（测试特定风险）。
sdlc-design
提供SDD（待验证的架构）、数据库设计（待测试的 schema）、API设计（待验证的契约）。
project-requirements
通过访谈收集的原始需求。在创建测试文档前需输入至SRS。

Parallel Skills (use ALONGSIDE this skill)

并行技能（与本技能同时使用）

SkillRelationship
android-tdd
Actual TDD implementation patterns (Red-Green-Refactor, layer-specific tests). This skill documents; 
android-tdd
implements.
ai-error-handling
5-layer validation stack for AI-generated code. Complements this skill's formal V&V processes.
ai-error-prevention
"Trust but verify" patterns. Use alongside peer review processes.
vibe-security-skill
Security testing patterns, OWASP mapping. Reference in test plans and security test cases.
feature-planning
Feature-level testing strategy. This skill covers project-level testing.
技能关系
android-tdd
实际TDD实现模式（红-绿-重构、分层测试）。本技能负责文档记录；
android-tdd
负责落地实现。
ai-error-handling
AI生成代码的5层验证栈。补充本技能的正式V&V流程。
ai-error-prevention
“信任但验证”模式。与同行评审流程配合使用。
vibe-security-skill
安全测试模式、OWASP映射。在测试计划和安全测试用例中参考。
feature-planning
功能级测试策略。本技能覆盖项目级测试。

Downstream Skills (use AFTER this skill)

下游技能（在本技能之后使用）

SkillRelationship
google-play-store-review
Play Store compliance testing. Uses test results from this skill's reports.
技能关系
google-play-store-review
Google Play商店合规测试。使用本技能报告中的测试结果。

Sibling SDLC Skills

同属SDLC的技能

SkillPhaseStatus
sdlc-planning
Planning & ManagementAvailable
sdlc-design
Design & ArchitectureAvailable
sdlc-testing
Testing & QualityThis Skill
sdlc-user-deploy
Delivery & DeploymentAvailable
技能阶段状态
sdlc-planning
规划与管理可用
sdlc-design
设计与架构可用
sdlc-testing
测试与质量本技能
sdlc-user-deploy
交付与部署可用

Adaptation Rules

适配规则

SaaS vs Standalone

SaaS vs 独立应用

AspectMulti-Tenant SaaSStandalone App
Tenant isolation testsRequired (franchise_id in every query)Not applicable
RBAC test casesFull matrix (super_admin, owner, staff)Simple role tests
Cross-tenant securityDedicated test suiteOmit
Test data setupPer-tenant fixtures (franchise_id = 1, 2)Single dataset
方面多租户SaaS独立应用
租户隔离测试必需（每个查询包含franchise_id）不适用
RBAC测试用例完整矩阵（超级管理员、所有者、员工）简单角色测试
跨租户安全专用测试套件省略
测试数据设置按租户准备固定数据（franchise_id = 1、2）单一数据集

Android + Web vs Web-Only

Android + Web vs 仅Web

AspectAndroid + WebWeb-Only
Test frameworksJUnit 5, MockK, Compose Testing + PHPUnitPHPUnit only
UI testingCompose tests + browser testsBrowser tests only
Offline testingRoom caching, network error scenariosN/A
Device matrixAPI levels 26-35, multiple screen sizesBrowser matrix
方面Android + Web仅Web
测试框架JUnit 5、MockK、Compose Testing + PHPUnit仅PHPUnit
UI测试Compose测试 + 浏览器测试仅浏览器测试
离线测试Room缓存、网络错误场景不适用
设备矩阵API级别26-35、多种屏幕尺寸浏览器矩阵

CI/CD Integration

CI/CD集成

StageTriggerTests Run
Pre-commitLocal commitUnit tests (fast)
PR validationPR created/updatedUnit + integration tests
Merge to developPR mergedFull test suite + coverage
Release candidateTag createdFull suite + security + performance
Post-deployProduction deploySmoke tests only
阶段触发条件运行的测试
提交前本地提交单元测试（快速）
PR验证PR创建/更新单元+集成测试
合并至develop分支PR合并完整测试套件+覆盖率测试
发布候选版本创建标签完整套件+安全+性能测试
部署后生产环境部署仅冒烟测试

Quality Checklist

质量检查清单

  • All 7 documents generated (or justified why one was skipped)
  • Each document stays under 500 lines
  • Test Plan references SRS requirement IDs for traceability
  • Test Plan includes: risk register, completion criteria, suspension/resumption criteria, communication plan, environment requirements, roles (per 29119-3 §6.2)
  • Test cases use naming convention TC-[MODULE]-[TYPE]-[###]
  • Every test case has the 9 normative 29119-3 fields (ID, objective, priority, traceability, preconditions, input, expected result, actual result, test result)
  • Every expected result is a deterministic test oracle — no judgment calls
  • Every SRS requirement ID (FR-xxx, NFR-xxx) is traced to at least one test case
  • V&V Plan covers both verification (built right) and validation (right product)
  • Test Plan distinguishes Alpha UAT (internal controlled) from Beta UAT (real-world users)
  • Regression testing section covers: suite scope, trigger conditions, pass rate threshold
  • Test Data Management section covers: fixture creation, tenant isolation, data anonymization
  • Test Data Readiness Report completed before execution begins
  • Test Environment Readiness Report completed before execution begins
  • Test Report includes pass rates, coverage, defect resolution protocol, and Go/No-Go recommendation
  • Incident Report template populated for every detected anomaly
  • Test Completion Report produced at phase close: summary, deviations, residual risks, lessons learned
  • Release evidence and post-deploy watch signals are stated for risky changes
  • Peer Review Report includes tech-stack-specific checklists
  • Multi-tenant isolation addressed in test cases and V&V plan
  • Test environments match deployment environments (Windows/Ubuntu/Debian)
  • Security test cases reference 
    vibe-security-skill
    OWASP mapping
  • Performance benchmarks have numeric targets (not vague language)
  • Documents cross-reference each other and upstream SRS/SDD
  • 已生成全部7类文档（或说明跳过某类的理由）
  • 每个文档行数不超过500行
  • 测试计划引用SRS需求ID以实现可追溯性
  • 测试计划包含：风险登记册、完成标准、暂停/恢复标准、沟通计划、环境要求、角色（符合29119-3 §6.2）
  • 测试用例采用命名规范TC-[模块]-[类型]-[###]
  • 每个测试用例包含29119-3标准规定的9个必填字段（ID、目标、优先级、可追溯性、前置条件、输入、预期结果、实际结果、测试结果）
  • 每个预期结果都是确定性测试准则——无主观判断
  • 每个SRS需求ID（FR-xxx、NFR-xxx）至少关联一个测试用例
  • V&V计划同时覆盖验证（正确构建）和确认（构建正确产品）
  • 测试计划区分Alpha UAT（内部受控）和Beta UAT（真实用户）
  • 回归测试章节涵盖：套件范围、触发条件、通过率阈值
  • 测试数据管理章节涵盖：固定数据创建、租户隔离、数据匿名化
  • 测试执行开始前已完成测试数据就绪报告
  • 测试执行开始前已完成测试环境就绪报告
  • 测试报告包含通过率、覆盖率、缺陷解决流程以及上线/不上线（Go/No-Go）建议
  • 为每个检测到的异常填写事件报告模板
  • 阶段结束时生成测试完成报告：总结、偏差、剩余风险、经验教训
  • 针对高风险变更明确发布证据和部署后监控信号
  • 同行评审报告包含技术栈专属检查清单
  • 测试用例和V&V计划中涉及多租户隔离
  • 测试环境与部署环境匹配（Windows/Ubuntu/Debian）
  • 安全测试用例参考
    vibe-security-skill
    的OWASP映射
  • 性能基准有明确数值目标（非模糊表述）
  • 文档之间以及与上游SRS/SDD之间存在交叉引用

Anti-Patterns

反模式

Anti-PatternWhy It FailsDo This Instead
No formal test planAd-hoc testing misses critical pathsWrite STP before testing begins
Test cases without expected resultsCan't determine pass/failEvery TC has explicit expected results (test oracle)
Vague expected results ("response looks OK")Not a test oracle; tester must interpretState exact output: value, format, timing, error code
No traceability to requirementsCan't prove coverageMap every TC to FR-xxx or NFR-xxx
Testing only happy pathsEdge cases cause production failuresInclude negative, boundary, and error cases
No test data strategyInconsistent, flaky testsDefine fixtures, factories, seed data with tenant isolation
Skipping security testingVulnerabilities ship to productionInclude security test suite in every release
No peer review processBugs caught late, inconsistent codeStandardize reviews with checklists
Rubber-stamp reviewsReviews provide no valueRequire findings documented, metrics tracked
Testing in production onlyUsers find bugs, not testersTest in staging first, smoke test prod
No regression suitePassing tests break silently between releasesDefine regression suite, trigger on every RC
No incident trackingAnomalies lose contextOpen an Incident Report for every anomaly during execution
No Test Completion ReportPhase never formally closesProduce TCR before passing to next lifecycle phase
反模式失败原因正确做法
无正式测试计划临时测试会遗漏关键路径测试开始前编写软件测试计划（STP）
测试用例无预期结果无法判定通过/失败每个测试用例（TC）都有明确的预期结果（测试准则）
模糊的预期结果（如“响应看起来正常”）不属于测试准则；测试人员需主观解读明确输出内容：数值、格式、时间、错误码
与需求无关联无法证明覆盖范围将每个测试用例映射至FR-xxx或NFR-xxx
仅测试正常路径边缘案例会导致生产故障包含负面、边界和错误案例
无测试数据策略测试结果不一致、不稳定定义固定数据、工厂类、种子数据并实现租户隔离
跳过安全测试漏洞会被发布至生产环境每个版本都包含安全测试套件
无同行评审流程Bug发现晚、代码不一致使用检查清单标准化评审流程
形式化评审评审无实际价值要求记录发现问题、跟踪指标
仅在生产环境测试用户发现Bug而非测试人员先在预发布环境测试，生产环境仅做冒烟测试
无回归套件通过的测试会在版本间无声失效定义回归套件，每个发布候选版本触发回归测试
无事件跟踪异常会丢失上下文执行过程中为每个异常创建事件报告
无测试完成报告阶段从未正式结束进入下一个生命周期阶段前生成测试完成报告（TCR）

Template Files

模板文件

Each template provides the complete structure, section-by-section guidance, examples tailored to the tech stack, anti-patterns, and a quality checklist.
  1. Software Test Plan
  2. Test Case Specifications
  3. Validation & Verification Plan
  4. Validation Test Report
  5. Peer Review / Inspection Report
  6. Incident Report
  7. Test Completion Report
每个模板提供完整结构、分章节指导、适配技术栈的示例、反模式以及质量检查清单。
  1. 软件测试计划
  2. 测试用例规范
  3. 验证与确认计划
  4. 验证测试报告
  5. 同行评审/检查报告
  6. 事件报告
  7. 测试完成报告

References

参考资料

  • ../sdlc-lifecycle.md: Shared SDLC execution model and lifecycle gates.
Back to: Skills Repository Related: sdlc-planning | android-tdd | vibe-security-skill | ai-error-handling Last Updated: 2026-03-15 (upgraded to BS ISO/IEC/IEEE 29119-3:2013 per Winston, BS Standards; strengthened per Adjei 2023, Splunk Product is Docs)
  • ../sdlc-lifecycle.md：共享SDLC执行模型和生命周期门控。
返回： 技能仓库 相关技能： sdlc-planning | android-tdd | vibe-security-skill | ai-error-handling 最后更新： 2026-03-15（根据Winston的BS标准升级至BS ISO/IEC/IEEE 29119-3:2013；根据Adjei 2023的Splunk Product is Docs强化内容）