@umacloud/knowledge 1.0.1

package/testing/05-cases/case-testing-transformation.md

@@ -0,0 +1,300 @@
+---
+id: case-testing-transformation
+title: 测试转型案例：从无测试到 80% 覆盖率的团队转型实战
+domain: testing
+category: 05-cases
+difficulty: intermediate
+tags: [10-13, 14-16, agent, case, checklist, testing, transformation, 初始状态]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 测试转型案例：从无测试到 80% 覆盖率的团队转型实战
+
+## 概述
+
+本案例记录一个 15 人后端团队从零测试基础到稳定 80%+ 覆盖率的转型过程。项目是一个 SaaS 订单管理系统（Node.js + TypeScript + PostgreSQL），历时 16 周完成转型。转型前线上事故平均每月 3.2 次，转型后降至每月 0.4 次。
+
+---
+
+## 初始状态
+
+### 团队画像
+
+- 后端工程师 12 人，QA 3 人
+- 平均工作经验 3 年，仅 2 人有测试编写经验
+- 测试依赖 QA 手动回归，每次发布回归 2 天
+- 无 CI/CD pipeline，通过 SSH 手动部署
+
+### 代码状态
+
+- 代码仓库 180+ 文件，约 45,000 行 TypeScript
+- 单元测试：0 个
+- 集成测试：0 个
+- E2E 测试：0 个
+- 测试覆盖率：0%
+- 技术债务：无类型检查、无 lint 规则、全局变量滥用
+
+### 痛点
+
+1. 每次上线前 QA 手动回归 2 天，仍有遗漏
+2. 修 Bug A 引入 Bug B 的情况每月发生 2-3 次
+3. 重构恐惧症：没人敢动核心模块
+4. 新人上手慢：没有测试作为活文档，只能读代码猜行为
+
+---
+
+## 第一阶段：基础设施搭建（第 1-2 周）
+
+### 目标
+
+让团队能运行一条测试命令并看到结果。
+
+### 行动
+
+```
+1. 安装测试框架
+   - Jest + ts-jest（与 TypeScript 兼容）
+   - @types/jest 类型定义
+
+2. 配置 jest.config.ts
+   - 测试文件匹配：**/*.test.ts
+   - 覆盖率收集：开启
+   - 模块别名映射：与 tsconfig.paths 一致
+
+3. 创建第一个测试文件
+   - 选择最简单的工具函数 utils/format.ts
+   - 编写 5 个基础测试用例
+   - 在团队会议上演示运行过程
+
+4. 配置 CI（GitHub Actions）
+   - 每次 Push 自动运行 jest
+   - 覆盖率报告上传到 Codecov
+   - PR 评论自动显示覆盖率变化
+```
+
+### 成果
+
+- 团队所有人可以运行 `npm test`
+- 第一个测试文件通过
+- CI pipeline 就绪
+- 覆盖率：0.3%（5 个测试）
+
+### 关键决策
+
+不强制所有人立刻写测试。先让基础设施就绪，降低写测试的门槛。
+
+---
+
+## 第二阶段：种子测试 + 培训（第 3-5 周）
+
+### 目标
+
+培养 3 名测试先锋，产出可参考的测试模式。
+
+### 行动
+
+```
+1. 选拔 3 名测试先锋（自愿报名 + 技术能力评估）
+
+2. 内部培训（4 次 workshop，每次 2 小时）
+   - Workshop 1：测试基础（AAA 模式、断言、mock）
+   - Workshop 2：测试设计（边界条件、等价类划分）
+   - Workshop 3：集成测试（Testcontainers + 数据库测试）
+   - Workshop 4：代码可测试性改造（依赖注入、纯函数提取）
+
+3. 种子测试编写
+   - 每位先锋负责 1 个核心模块
+   - 订单服务（order-service）：15 个测试
+   - 支付服务（payment-service）：12 个测试
+   - 用户服务（user-service）：10 个测试
+
+4. 建立测试规范文档
+   - 测试命名规范
+   - 目录结构规范（与源码平行的 __tests__ 目录）
+   - Mock 使用指南
+   - 测试数据工厂模式
+```
+
+### 成果
+
+- 3 名先锋掌握测试技能
+- 37 个种子测试建立了可参考的模式
+- 测试规范文档完成
+- 覆盖率：8%
+
+### 关键教训
+
+Workshop 效果远好于文档自学。实际 pair programming 写测试的效果又好于 Workshop。
+
+---
+
+## 第三阶段：全员推广 + 增量要求（第 6-9 周）
+
+### 目标
+
+全员具备测试编写能力，新代码必须有测试。
+
+### 行动
+
+```
+1. CI 卡点设置
+   - 新增代码覆盖率 < 60% 则 PR 阻止合并
+   - 全量覆盖率只监控不卡点（避免历史债务阻塞日常开发）
+
+2. Pair Programming 推广
+   - 每位先锋带 3 名同事
+   - 每周 2 次 pair 写测试，每次 1 小时
+   - 第一周先锋主写，同事观摩
+   - 第二周同事主写，先锋指导
+   - 第三周独立编写，先锋 review
+
+3. 测试模板工具
+   - 编写 CLI 工具自动生成测试文件骨架
+   - 根据源文件的 export 自动生成测试用例模板
+   - 减少 "不知道从哪开始" 的阻力
+
+4. Code Review 加入测试审查
+   - PR 无测试文件则标记为 "needs-tests"
+   - 测试质量纳入 review 标准（不是有测试就行）
+
+5. 每周测试看板
+   - 展示各模块覆盖率
+   - 展示本周新增测试数量
+   - 展示测试发现的 bug 数量（正向激励）
+```
+
+### 成果
+
+- 12 人全部可独立编写单元测试
+- 新增 PR 测试覆盖率平均 72%
+- 累计测试 280+ 个
+- 覆盖率：32%
+
+### 最大阻力及应对
+
+"写测试太慢了，影响交付" -- 用数据反驳：测试发现的 bug 避免了线上修复的更大时间成本。统计显示写测试的 PR 返工率低 60%。
+
+---
+
+## 第四阶段：存量补测 + 集成测试（第 10-13 周）
+
+### 目标
+
+核心模块补充测试，集成测试覆盖关键路径。
+
+### 行动
+
+```
+1. 识别高风险模块（按以下标准排序）
+   - 线上事故次数
+   - 变更频率
+   - 业务重要程度
+   - 结果：确定 8 个高风险模块优先补测
+
+2. 补测策略
+   - 不追求 100% 覆盖，优先覆盖核心路径和历史 bug 场景
+   - 每个历史线上 bug 都补一个回归测试
+   - 使用 Characterization Test 锁定现有行为
+
+3. 集成测试建设
+   - Docker Compose 搭建测试环境（PostgreSQL + Redis）
+   - 使用 Testcontainers 管理测试容器生命周期
+   - API 集成测试覆盖 20 个核心端点
+   - 数据库事务测试覆盖 5 个关键事务场景
+
+4. 可测试性重构
+   - 提取纯函数（从 controller 中分离业务逻辑）
+   - 引入依赖注入（从 new 直接创建改为构造函数注入）
+   - 消除全局状态（单例模式改为工厂模式）
+```
+
+### 成果
+
+- 8 个高风险模块覆盖率从 15% 提升到 75%
+- 20 个 API 集成测试就绪
+- 补测过程中发现 6 个潜在 bug（未上线前修复）
+- 覆盖率：58%
+
+---
+
+## 第五阶段：E2E + 性能 + 稳定化（第 14-16 周）
+
+### 目标
+
+建立完整测试金字塔，覆盖率稳定在 80%+。
+
+### 行动
+
+```
+1. E2E 测试（Playwright）
+   - 5 个核心业务流程（注册→下单→支付→发货→退款）
+   - 在 CI 中每日定时运行（非每次 PR）
+   - 失败自动截图并通知 Slack
+
+2. 性能测试基线
+   - 使用 k6 建立 10 个关键 API 的性能基线
+   - P95 响应时间和最大 QPS 记录在案
+   - 每月运行一次，对比基线
+
+3. 覆盖率卡点升级
+   - 全量覆盖率 < 75% 则 CI 警告
+   - 新增代码覆盖率 < 80% 则 PR 阻止合并
+   - 核心模块覆盖率 < 85% 触发技术债务任务
+
+4. 测试文化固化
+   - Bug 修复必须附带回归测试（写入团队规范）
+   - 新功能 Definition of Done 包含测试
+   - 月度测试质量报告（覆盖率趋势、测试发现bug比例、不稳定测试列表）
+```
+
+### 最终成果
+
+| 指标 | 转型前 | 转型后 | 改善 |
+|------|--------|--------|------|
+| 单元测试数量 | 0 | 620+ | -- |
+| 集成测试数量 | 0 | 45 | -- |
+| E2E 测试数量 | 0 | 12 | -- |
+| 行覆盖率 | 0% | 82% | -- |
+| 分支覆盖率 | 0% | 71% | -- |
+| 月均线上事故 | 3.2 次 | 0.4 次 | -87.5% |
+| QA 回归时间 | 2 天 | 2 小时 | -87.5% |
+| 发布频率 | 2 周/次 | 每日 | +7x |
+| PR 返工率 | 35% | 12% | -66% |
+| 新人上手周期 | 4 周 | 1.5 周 | -62.5% |
+
+---
+
+## 转型经验总结
+
+### 成功要素
+
+1. **管理层支持** - CTO 明确要求测试纳入 DoD，给团队时间投入
+2. **先锋带动** - 3 名先锋的 Pair Programming 比培训文档有效 10 倍
+3. **渐进式推进** - 先增量后存量，先单元后集成，不要一步到位
+4. **数据驱动** - 用事故减少、返工降低的数据说服质疑者
+5. **工具降低门槛** - 测试模板生成器消除了 "不知道怎么开始" 的问题
+
+### 常见陷阱
+
+1. **追求覆盖率数字** - 80% 有意义的测试 > 95% 无意义的测试
+2. **一次性全量补测** - 团队疲劳且质量下降，不如分阶段推进
+3. **忽略可测试性** - 代码不可测则测试写不出来，需先重构
+4. **不维护测试** - 不稳定的测试（Flaky Test）会摧毁团队信心
+5. **测试与开发割裂** - 测试不是 QA 的事，是开发者的基本功
+
+---
+
+## Agent Checklist
+
+以下为 AI Agent 在推动测试转型时必须遵循的硬约束：
+
+- [ ] 确认测试框架已安装且 `test` 命令可运行
+- [ ] 确认 CI 中包含测试执行步骤和覆盖率上传
+- [ ] 确认 jest.config / pytest.ini / go test 配置正确
+- [ ] 为新写的每个模块同步创建测试文件
+- [ ] 测试遵循 AAA 模式（Arrange-Act-Assert）
+- [ ] 不使用 sleep/delay，使用 fake timer 或显式等待
+- [ ] 不调用真实外部服务，全部使用 mock
+- [ ] 测试命名描述被测行为而非实现细节
+- [ ] 确认覆盖率阈值已设置并在 CI 中生效
+- [ ] 生成测试覆盖率报告并标注低覆盖率模块

package/testing/06-glossary/testing-glossary.md

@@ -0,0 +1,110 @@
+---
+id: testing-glossary
+title: 测试术语表 (Testing Glossary)
+domain: testing
+category: 06-glossary
+difficulty: intermediate
+tags: [agent, checklist, glossary, testing, 测试度量, 测试方法论, 测试替身与隔离, 测试环境与基础设施]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 测试术语表 (Testing Glossary)
+
+> 适用场景：测试策略制定、测试方案评审、QA 团队 Onboarding、开发团队测试培训。
+> 涵盖范围：测试方法论、测试类型、测试工具概念、测试度量指标等核心术语。
+
+---
+
+## 测试方法论
+
+| 术语 | 英文 | 定义 |
+|------|------|------|
+| 测试驱动开发 | Test-Driven Development (TDD) | 先写测试再写实现的开发方法。循环：Red（写失败测试）→ Green（写最小实现使测试通过）→ Refactor（重构代码保持测试通过）。 |
+| 行为驱动开发 | Behavior-Driven Development (BDD) | 基于业务行为描述编写测试的方法，使用 Given-When-Then 格式，促进开发、测试和业务的沟通。工具：Cucumber / Behave / Jest-Cucumber。 |
+| 验收测试驱动开发 | Acceptance Test-Driven Development (ATDD) | 在开发前由产品、开发和测试共同定义验收标准和验收测试，确保交付符合业务需求。 |
+| 契约测试 | Contract Testing | 验证服务提供者和消费者之间接口契约一致性的测试方法，防止接口变更导致集成失败。工具：Pact。 |
+| 基于属性的测试 | Property-Based Testing | 定义输入数据的属性和输出应满足的不变量，框架自动生成大量随机输入进行验证。工具：Hypothesis (Python) / fast-check (JS)。 |
+
+---
+
+## 测试类型
+
+| 术语 | 英文 | 定义 |
+|------|------|------|
+| 单元测试 | Unit Test | 测试最小可测试单元（函数/方法/类）的独立行为，不依赖外部系统。执行速度快（毫秒级），数量最多。 |
+| 集成测试 | Integration Test | 验证多个模块或服务之间的交互是否正确，通常涉及数据库、消息队列等真实或模拟的外部依赖。 |
+| 端到端测试 | End-to-End Test (E2E) | 模拟真实用户操作，验证完整业务流程从前端到后端到数据库的全链路功能。工具：Playwright / Cypress / Selenium。 |
+| 回归测试 | Regression Test | 在代码变更后重新执行已有测试，确保新变更没有破坏已有功能。通常自动化执行。 |
+| 冒烟测试 | Smoke Test | 部署后快速验证系统核心功能是否可用的最小测试集，通常在 CI/CD 部署后自动执行。 |
+| 金丝雀测试 | Canary Test | 在生产环境中针对小比例流量运行的测试，验证新版本在真实条件下是否正常，异常则自动回滚。 |
+| 压力测试 | Stress Test | 在超出正常负载的条件下测试系统行为，找到系统的极限和断裂点。 |
+| 负载测试 | Load Test | 在预期负载条件下验证系统性能指标（响应时间、吞吐量）是否满足要求。工具：k6 / Locust / JMeter。 |
+| 性能测试 | Performance Test | 测试系统在不同条件下的响应速度、吞吐量、资源利用率等性能指标的总称。 |
+| 安全测试 | Security Test | 识别系统安全漏洞的测试，包括渗透测试、SAST、DAST、依赖扫描等。 |
+| 可访问性测试 | Accessibility Test (a11y) | 验证应用是否对残障用户友好，符合 WCAG 标准。工具：axe / Lighthouse / Pa11y。 |
+| 视觉回归测试 | Visual Regression Test | 通过截图对比检测 UI 的非预期视觉变化。工具：Percy / Chromatic / BackstopJS。 |
+| 混沌测试 | Chaos Test | 主动向系统注入故障（网络延迟、服务宕机、磁盘满）验证系统的容错和恢复能力。工具：Chaos Monkey / Litmus。 |
+
+---
+
+## 测试替身与隔离
+
+| 术语 | 英文 | 定义 |
+|------|------|------|
+| 测试替身 | Test Double | 替代真实依赖的测试用对象的总称，包括 Dummy、Stub、Spy、Mock、Fake 五种类型。 |
+| Mock | Mock | 预设期望行为并验证交互的测试替身。可以断言被调用的次数、参数等。工具：unittest.mock / Jest mock / Mockito。 |
+| Stub | Stub | 返回预设固定值的测试替身，不验证交互。用于隔离被测代码的外部依赖。 |
+| Spy | Spy | 包装真实对象的测试替身，记录调用信息但仍执行真实逻辑。用于验证交互同时保留真实行为。 |
+| Fake | Fake | 具有简化但可工作实现的测试替身。如内存数据库替代 PostgreSQL、本地文件系统替代 S3。 |
+| Fixture | Fixture | 测试运行前的预设环境和数据，包括数据库记录、配置文件、临时目录等。通过 `setUp` / `@pytest.fixture` 管理。 |
+| Test Factory | Test Factory | 创建测试数据的工厂函数或类，提供合理的默认值并允许按需覆盖。工具：Factory Boy (Python) / Fishery (JS)。 |
+
+---
+
+## 测试度量
+
+| 术语 | 英文 | 定义 |
+|------|------|------|
+| 代码覆盖率 | Code Coverage | 测试执行时覆盖的代码比例，包括行覆盖率、分支覆盖率、函数覆盖率等。工具：coverage.py / Istanbul / JaCoCo。 |
+| 分支覆盖率 | Branch Coverage | 测试覆盖的条件分支比例（if/else、switch/case），比行覆盖率更严格。 |
+| 变异测试 | Mutation Testing | 自动修改源代码（如将 `>` 改为 `>=`），验证测试是否能检测到变异。存活的变异体说明测试不够充分。工具：mutmut / Stryker。 |
+| Flaky Test | Flaky Test | 不稳定测试，在相同代码上时而通过时而失败。常见原因：时间依赖、竞态条件、外部服务、测试顺序依赖。 |
+| 测试金字塔 | Test Pyramid | 测试分布的理想模型：底部大量快速的单元测试，中间适量集成测试，顶部少量 E2E 测试。由 Mike Cohn 提出。 |
+| 测试冰淇淋锥 | Test Ice Cream Cone | 测试金字塔的反模式：大量 E2E/手动测试在顶部，少量单元测试在底部。导致测试慢、脆弱、维护成本高。 |
+
+---
+
+## 高级测试技术
+
+| 术语 | 英文 | 定义 |
+|------|------|------|
+| 模糊测试 | Fuzzing | 向程序输入大量随机或半随机数据，检测崩溃、内存泄漏和安全漏洞。工具：AFL / libFuzzer / Atheris。 |
+| 快照测试 | Snapshot Testing | 将组件输出序列化为快照文件，后续测试对比输出是否发生变化。适用于 UI 组件和 API 响应。工具：Jest Snapshot。 |
+| 影子测试 | Shadow Testing | 将生产流量复制到新版本服务，对比新旧版本的输出差异，不影响用户。 |
+| 数据驱动测试 | Data-Driven Testing | 测试逻辑与测试数据分离，通过外部数据源（CSV/JSON/数据库）驱动测试执行，同一测试逻辑覆盖大量场景。 |
+| 参数化测试 | Parameterized Test | 同一测试函数使用不同参数多次执行，避免重复编写结构相同的测试。`@pytest.mark.parametrize` / `@ParameterizedTest`。 |
+| 测试左移 | Shift-Left Testing | 将测试活动提前到开发生命周期的更早阶段（需求、设计），而非等到编码完成后才开始测试。 |
+| 测试右移 | Shift-Right Testing | 在生产环境中进行测试（如 Canary 测试、A/B 测试、混沌工程），验证系统在真实条件下的行为。 |
+| 契约测试 | Contract Testing | 验证服务间接口契约一致性的测试方法。消费者定义期望，提供者验证满足。工具：Pact / Spring Cloud Contract。 |
+
+---
+
+## 测试环境与基础设施
+
+| 术语 | 英文 | 定义 |
+|------|------|------|
+| 测试环境 | Test Environment | 用于运行测试的独立环境，与生产环境隔离。包括本地环境、CI 环境、Staging 环境等。 |
+| 测试容器 | Testcontainers | 使用 Docker 容器为集成测试提供真实依赖（数据库、消息队列等）的库，测试后自动清理。 |
+| 测试数据管理 | Test Data Management | 创建、维护和清理测试所需数据的策略和工具。包括 Fixture、Factory、Seed Data、数据脱敏等。 |
+| 持续测试 | Continuous Testing | 在 CI/CD 流水线中自动化执行测试的实践，每次代码提交都触发测试，快速反馈质量状态。 |
+| 服务虚拟化 | Service Virtualization | 模拟外部依赖服务（第三方 API、后端服务）行为的技术，使测试不依赖真实外部系统。工具：WireMock / MockServer。 |
+| 测试隔离 | Test Isolation | 确保每个测试独立运行，不受其他测试的影响。通过独立数据、事务回滚、容器隔离等方式实现。 |
+
+---
+
+## Agent Checklist
+
+- [ ] 项目测试方案中使用的术语与本表定义一致
+- [ ] QA 和开发团队对核心术语的理解已对齐
+- [ ] 新引入的测试方法/工具已补充到本术语表
+- [ ] 测试评审时使用本表作为沟通基准

package/testing/risk-based-test-matrix.md

@@ -0,0 +1,36 @@
+---
+id: risk-based-test-matrix
+title: risk-based-test-matrix
+domain: testing
+category: risk-based-test-matrix.md
+difficulty: intermediate
+tags: [based, matrix, risk, test, testing, 风险驱动测试矩阵]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 开发：Excellent（11964948@qq.com）
+
+## 风险驱动测试矩阵
+
+### 目标
+- 把测试资源聚焦到高风险高影响场景，提升回归效率与事故预防能力。
+
+### 风险评分模型
+- 业务影响：低/中/高
+- 变更复杂度：低/中/高
+- 历史缺陷密度：低/中/高
+- 依赖外部系统数量：低/中/高
+
+### 测试等级映射
+- R1（低风险）：单元测试 + 冒烟验证。
+- R2（中风险）：单元 + 集成 + 契约测试。
+- R3（高风险）：单元 + 集成 + E2E + 性能 + 安全专项。
+
+### 执行清单
+- 每次发布前更新模块风险评分。
+- 高风险模块回归失败时禁止发布。
+- 高风险缺陷必须沉淀为长期回归用例。
+
+### 常见失败模式
+- 所有模块“一刀切”同等测试深度。
+- 风险评估不更新，矩阵失去参考价值。

package/testing/testing-strategy-deep-dive.md

@@ -0,0 +1,37 @@
+---
+id: testing-strategy-deep-dive
+title: testing-strategy-deep-dive
+domain: testing
+category: testing-strategy-deep-dive.md
+difficulty: intermediate
+tags: [deep, dive, strategy, testing, 测试环节深度知识库]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 开发：Excellent（11964948@qq.com）
+
+## 测试环节深度知识库
+
+### 目标
+- 建立“快速反馈 + 高风险覆盖”的测试体系。
+
+### 测试分层
+- 单元测试：验证业务规则与边界条件。
+- 集成测试：验证模块协作、数据库与外部依赖交互。
+- 端到端测试：验证核心用户链路与关键业务闭环。
+- 非功能测试：性能、可靠性、安全、兼容性。
+
+### 质量门禁
+- 核心路径测试必须通过。
+- 高风险模块覆盖率必须达标。
+- 变更涉及权限、支付、数据写入时必须触发增强测试集。
+- 线上故障必须沉淀为回归用例。
+
+### 测试数据策略
+- 数据可重复构建、可快速清理。
+- 敏感数据脱敏，禁止使用真实用户隐私数据。
+- 测试环境配置与生产关键开关保持一致。
+
+### 常见失败模式
+- 只测 happy path，不测异常流与并发冲突。
+- 测试不稳定，无法作为发布阻断依据。