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测试技能

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

生成的证据

Category	Artifact	Format	Example
Correctness	Test plan compliant with BS ISO/IEC/IEEE 29119-3:2013	Markdown 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.

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/
```
目录下的模板。

为软件开发项目生成完整的测试与质量文档套件。本技能可生成5类文档，用于建立测试基准、定义测试用例、验证系统、报告结果以及标准化同行评审流程。

Load Order

加载顺序

Load
```
world-class-engineering
```
.
Load
```
advanced-testing-strategy
```
.
Load this skill to produce formal test documentation and release evidence.

加载
```
world-class-engineering
```
。
加载
```
advanced-testing-strategy
```
。
加载本技能以生成正式测试文档和发布证据。

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

文档清单


templates/software-test-plan.md
templates/test-case-specifications.md
templates/validation-verification-plan.md
templates/validation-test-report.md
templates/peer-review-report.md
templates/incident-report.md
templates/test-completion-report.md

#	Document	File	Purpose	Audience	Phase
1	Software Test Plan	`templates/software-test-plan.md`	Testing strategy, tools, environments, schedule, completion criteria	QA leads, PMs, devs	After SRS + SDD
2	Test Case Specifications	`templates/test-case-specifications.md`	Normative 29119-3 test cases: ID, objective, priority, traceability, preconditions, input, expected result	Test engineers, devs	During development
3	Validation & Verification Plan	`templates/validation-verification-plan.md`	V&V approach (built right + right product)	QA mgrs, PMs, compliance	After SRS + SDD
4	Validation Test Report	`templates/validation-test-report.md`	Test execution results and Go/No-Go release decision	PMs, stakeholders, QA	Before release
5	Peer Review Report	`templates/peer-review-report.md`	Code, design, and document review findings	Dev team, tech leads	Throughout SDLC
6	Incident Report	`templates/incident-report.md`	Anomaly record: ID, timing, context, description, impact, urgency, status	QA, dev leads	During execution
7	Test Completion Report	`templates/test-completion-report.md`	Test summary, deviations, completion criteria met, residual risks, lessons learned	PMs, stakeholders, compliance	End of test phase


templates/software-test-plan.md
templates/test-case-specifications.md
templates/validation-verification-plan.md
templates/validation-test-report.md
templates/peer-review-report.md
templates/incident-report.md
templates/test-completion-report.md

序号	文档名称	文件	用途	受众	阶段
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:

Activity	Traditional Phase	Shift-Left Phase
Unit testing	After coding	During coding (TDD)
Security testing	Pre-release	During design + development
Performance testing	Pre-release	During development (benchmarks)
Code review	After feature complete	Per-commit (PR-based)
Requirements review	After SRS finalized	During 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

前置条件

Input	Source	Required?
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

单元测试

Platform	Framework	Scope	Speed
Android	JUnit 5 + MockK + Turbine	ViewModels, UseCases, Repositories, Mappers	<1ms each
PHP	PHPUnit	Services, validators, business logic, helpers	<10ms each

平台	框架	范围	速度
Android	JUnit 5 + MockK + Turbine	ViewModels、UseCases、Repositories、Mappers	每个<1ms
PHP	PHPUnit	服务、验证器、业务逻辑、辅助工具	每个<10ms

Integration Testing

集成测试

Platform	Framework	Scope
Android	Room in-memory DB + MockWebServer	DAO queries, API contracts, auth flows
PHP	PHPUnit + real MySQL test DB	API endpoints, stored procedures, multi-table ops

平台	框架	范围
Android	Room内存数据库 + MockWebServer	DAO查询、API契约、认证流程
PHP	PHPUnit + 真实MySQL测试数据库	API端点、存储过程、多表操作

UI / E2E Testing

UI / E2E测试

Platform	Framework	Scope
Android	Compose Testing + Espresso	Screen rendering, navigation, user flows
Web	Browser testing (manual + automated)	CRUD workflows, form validation, responsive layout

平台	框架	范围
Android	Compose Testing + Espresso	屏幕渲染、导航、用户流程
Web	浏览器测试（手动+自动化）	CRUD工作流、表单验证、响应式布局

User Acceptance Testing (UAT)

用户验收测试（UAT）

Distinguish Alpha and Beta testing explicitly in the Test Plan:

Stage	Location	Testers	Focus
Alpha	Controlled environment (internal/QA lab)	Internal testers, stakeholders	Functional correctness, defect discovery
Beta	Real-world environment (staging/limited production)	Selected external users	Real-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.

Step	Owner	Action
1	Tester	Reproduce — determine exact minimal sequence; check for intermittence
2	Tester	Discriminate — test bug or system bug?
3	Tester	Isolate — identify external factors (config, data, workflows) affecting symptoms
4	Developer	Root cause — find cause in code, hardware, network, or environment
5	Developer	Repair — fix without introducing new problems
6	Developer	Verify fix — confirm the fix is clean before handoff
7	Tester	Confirm + 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）

Security Testing

安全测试

Area	Method	Reference
Tenant isolation	Automated + manual: cross-tenant access denied	`vibe-security-skill`
Auth bypass	Token manipulation, session hijacking attempts	`dual-auth-rbac`
Injection	SQL injection, XSS, CSRF payloads	OWASP Top 10
Data exposure	API 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

性能测试

Metric	Target	Tool
API response time	< 500ms (P95)	curl timing, load test tools
Web page load	< 2s (first contentful paint)	Browser DevTools, Lighthouse
Android cold start	< 3s	Android Profiler
Database query	< 100ms (P95)	MySQL slow query log, EXPLAIN

指标	目标	工具
API响应时间	< 500ms（P95）	curl计时、负载测试工具
网页加载时间	< 2s（首次内容绘制）	浏览器开发者工具、Lighthouse
Android冷启动时间	< 3s	Android Profiler
数据库查询时间	< 100ms（P95）	MySQL慢查询日志、EXPLAIN

Cross-References to Existing Skills

与现有技能的交叉引用

Upstream Skills (use BEFORE this skill)

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

Skill	Relationship
`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)

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

Skill	Relationship
`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)

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

Skill	Relationship
`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的技能

Skill	Phase	Status
`sdlc-planning`	Planning & Management	Available
`sdlc-design`	Design & Architecture	Available
`sdlc-testing`	Testing & Quality	This Skill
`sdlc-user-deploy`	Delivery & Deployment	Available

技能	阶段	状态
`sdlc-planning`	规划与管理	可用
`sdlc-design`	设计与架构	可用
`sdlc-testing`	测试与质量	本技能
`sdlc-user-deploy`	交付与部署	可用

Adaptation Rules

适配规则

SaaS vs Standalone

SaaS vs 独立应用

Aspect	Multi-Tenant SaaS	Standalone App
Tenant isolation tests	Required (franchise_id in every query)	Not applicable
RBAC test cases	Full matrix (super_admin, owner, staff)	Simple role tests
Cross-tenant security	Dedicated test suite	Omit
Test data setup	Per-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

Aspect	Android + Web	Web-Only
Test frameworks	JUnit 5, MockK, Compose Testing + PHPUnit	PHPUnit only
UI testing	Compose tests + browser tests	Browser tests only
Offline testing	Room caching, network error scenarios	N/A
Device matrix	API levels 26-35, multiple screen sizes	Browser matrix

方面	Android + Web	仅Web
测试框架	JUnit 5、MockK、Compose Testing + PHPUnit	仅PHPUnit
UI测试	Compose测试 + 浏览器测试	仅浏览器测试
离线测试	Room缓存、网络错误场景	不适用
设备矩阵	API级别26-35、多种屏幕尺寸	浏览器矩阵

CI/CD Integration

CI/CD集成

Stage	Trigger	Tests Run
Pre-commit	Local commit	Unit tests (fast)
PR validation	PR created/updated	Unit + integration tests
Merge to develop	PR merged	Full test suite + coverage
Release candidate	Tag created	Full suite + security + performance
Post-deploy	Production deploy	Smoke 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-Pattern	Why It Fails	Do This Instead
No formal test plan	Ad-hoc testing misses critical paths	Write STP before testing begins
Test cases without expected results	Can't determine pass/fail	Every TC has explicit expected results (test oracle)
Vague expected results ("response looks OK")	Not a test oracle; tester must interpret	State exact output: value, format, timing, error code
No traceability to requirements	Can't prove coverage	Map every TC to FR-xxx or NFR-xxx
Testing only happy paths	Edge cases cause production failures	Include negative, boundary, and error cases
No test data strategy	Inconsistent, flaky tests	Define fixtures, factories, seed data with tenant isolation
Skipping security testing	Vulnerabilities ship to production	Include security test suite in every release
No peer review process	Bugs caught late, inconsistent code	Standardize reviews with checklists
Rubber-stamp reviews	Reviews provide no value	Require findings documented, metrics tracked
Testing in production only	Users find bugs, not testers	Test in staging first, smoke test prod
No regression suite	Passing tests break silently between releases	Define regression suite, trigger on every RC
No incident tracking	Anomalies lose context	Open an Incident Report for every anomaly during execution
No Test Completion Report	Phase never formally closes	Produce 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.

Software Test Plan
Test Case Specifications
Validation & Verification Plan
Validation Test Report
Peer Review / Inspection Report
Incident Report
Test Completion Report

每个模板提供完整结构、分章节指导、适配技术栈的示例、反模式以及质量检查清单。

软件测试计划
测试用例规范
验证与确认计划
验证测试报告
同行评审/检查报告
事件报告
测试完成报告

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强化内容）