# 软件测试知识体系详解报告

> **这份报告解决什么问题**
> "软件测试有哪些方向"是一张地图;本报告把这张地图展开成可逐层理解的**知识体系**——每个领域解决什么问题、依赖哪些理论、需要什么知识、用什么方法、落到什么工具与方案、用什么指标衡量。
>
> **怎么读**
> - 第一部分建立**坐标系**,回答"测试到底在测什么"。
> - 第二部分是**公共地基**:质量模型、层次、左移、风险、覆盖率、用例设计方法。所有方向都建立在其上,建议必读。
> - 第三部分按**工程/职业方向**逐个展开,每个方向统一按"问题域 → 理论 → 知识 → 方法 → 方案 → 指标"六层说明,可按需跳读。
> - 第四部分是**组合与落地**:如何把上述能力拼成一套可执行的测试策略。
> - 附录是**速查表、术语表与学习路径**。

---

## 一、总纲:先建立坐标系

日常说"测试",其实混淆了四个互相独立的问题。把它们分开,杂乱的知识才会各归其位。

| 维度 | 回答的问题 | 典型取值 |
| --- | --- | --- |
| **层次(Level)** | "测到多深?" | 单元 → 集成 → 系统 → 验收 |
| **方法(Method)** | "怎么看被测对象?" | 黑盒 / 白盒 / 灰盒 |
| **类型(Type)** | "测什么质量属性?" | 功能、性能、安全、兼容、可靠性…… |
| **工程方向(Discipline)** | "谁来测、怎么组织成专业能力?" | 功能、自动化、测试开发、性能、安全、移动端…… |

**关键认知:工程方向 = 层次 × 方法 × 类型的专业组合。**

- **性能测试** ≈ 系统层次 + 黑盒方法 + 性能类型。
- **安全测试** ≈ 多层次 + 灰盒/白盒 + 安全类型。
- **测试开发** 不针对某个类型,而是把"测试"这件事本身工程化、平台化。

因此,第三部分展开的每个方向,本质上都是"某个质量属性 + 某套方法 + 某类工具"的纵向深化;而第二部分的理论,则对**所有**方向通用。

---

## 二、理论地基(所有方向共用)

### 2.1 质量模型:先定义"好"是什么

**ISO/IEC 25010** 给出软件产品质量的标准切分,是"测试类型"的理论来源:

- **功能适合性**——功能完整、正确、恰当。
- **性能效率**——时间行为、资源利用、容量。
- **兼容性**——共存、互操作。
- **交互能力/易用性**——可识别、易学、可操作、防错、有吸引力、可访问。
- **可靠性**——成熟度、可用性、容错、可恢复。
- **安全性**——保密性、完整性、不可否认、可追溯、真实性。
- **可维护性**——模块化、可复用、可分析、可修改、可测。
- **灵活性/可移植性**——适应性、可安装、可替换、可扩展。

**为什么先看它**:它把"测试什么"从经验变成了清单。每一条质量属性,都对应一类测试类型与一组验证手段。新版 25010(2023)还单列了 **Safety(安全性/功能安全)**,说明"不出事"和"不被黑"是两件事。

### 2.2 认识论:黑盒、白盒、灰盒

- **黑盒**:只依据输入与输出,不看内部实现。理论基础是"规格即契约"。代表方法:等价类、边界值、判定表、场景法。
- **白盒**:基于代码结构。理论基础是**控制流图**与**数据流图**。代表方法:语句/分支/路径覆盖、MC/DC。
- **灰盒**:知道内部结构,但按接口/协议验证。接口测试、流量回放、基于埋点的断言都属于灰盒。

**选择原则**:结构越清晰、可观测性越强,越可偏向白盒;反之依赖黑盒。真实项目中三者混用。

### 2.3 层次与测试金字塔:成本与反馈速度的权衡

经典**测试金字塔**:

- **单元测试**(最底层,数量最多):毫秒级、定位精准、成本最低。
- **集成测试**(中间):验证模块协作、协议、数据一致性。
- **端到端/UI 测试**(顶层,数量最少):最接近用户,但慢、脆、维护贵。

**理论依据**:缺陷发现越晚,修复成本越高(缺陷成本曲线呈指数上升);但越贴近用户的测试,单次执行成本越高。金字塔正是这两条曲线的平衡点。

**反模式**:冰淇淋筒(UI 测试一堆、单元测试没有)——慢、flaky、反馈延迟。
**前端变体**:**测试奖杯(Testing Trophy)**——强调集成测试价值最高,配合静态类型检查打基础,端到端只做关键路径。

### 2.4 测试左移与右移

- **左移(Shift-Left)**:把质量活动前移到需求与设计阶段。手段:需求可测性评审、TDD/BDD、契约测试、静态分析与 SAST、CI 门禁。
- **右移(Shift-Right)**:把验证延伸到生产环境。手段:灰度/金丝雀发布、特性开关、生产监控、埋点校验、混沌实验、A/B 实验。

**核心思想**:质量不是"测出来的阶段",而是贯穿全生命周期的持续活动。

### 2.5 基于风险的测试(RBT)

**理论**:测试资源有限,应优先投入"高概率发生 × 高影响"的风险点。

- 风险值 = 发生可能性 × 影响程度。
- 输出是**优先级排序**,决定"测多少、测多深、先测谁"。
- 常见打分法:风险矩阵、FMEA(失效模式与影响分析)。

这是所有测试策略真正起点:没有风险排序的"全覆盖"是无意义的。

### 2.6 覆盖率理论及其局限

白盒覆盖率由弱到强:**语句 → 分支/判定 → 条件 → 判定条件(MC/DC) → 路径 → 数据流**。

- **路径覆盖**在含循环的代码中组合爆炸,工程上不可行,故用 MC/DC 等近似。
- **覆盖率是"充分性"的必要而非充分条件**:100% 语句覆盖仍可能漏掉大量逻辑。
- 结论:**用覆盖率找"没测到的地方",而不是当 KPI 追数字。**

### 2.7 测试预言问题(Oracle Problem)

**理论**:判断"输出是否正确"本身就需要依据,这个依据就是测试预言(Test Oracle)。

- 显式预言:精确期望值。
- 隐式预言:不变量(总金额守恒)、元属性(排序幂等)、差分预言(新旧版本对比)、统计预言(性能分位数)。
- 大量测试难点其实是"没有可靠的预言",而非"不会执行"。

### 2.8 组合测试:用正交/成对降维

**理论**:缺陷多由**少数参数的相互作用**触发。

- **成对组合(Pairwise)**能覆盖任意两参数的所有取值组合,用例数远小于全组合。
- 工具:正交表、PICT、ACTS。
- 适用:配置矩阵、兼容性矩阵、多开关场景。

### 2.9 缺陷理论

- **故障-错误-失效链(Fault → Error → Failure)**:代码缺陷(故障)在特定输入下被激活(执行)、传播(感染)、最终显现(失效)。PIE 模型解释了"为什么有 bug 却没测出来"。
- **正交缺陷分类(ODC)**:按缺陷类型/触发条件分类,用于分析缺陷分布、预测薄弱环节。
- **缺陷收敛曲线**与**缺陷逃逸率(DER)**:衡量测试有效性与发布就绪度。

---
## 三、用例设计方法论(公共底座)

这是**唯一一门所有测试方向都必须掌握的通用技能**。以下每种方法都按"定义 → 原理 → 例子 → 适用"说明,输入统一取一个例子:**一个接受年龄(整数)并返回票价等级的接口,合法范围 0-120。**

### 3.1 等价类划分

- **定义**:把输入域切成若干"行为等价"的子集,每个子集只取一个代表值。
- **原理**:同一等价类内的输入应触发相同的处理逻辑,测一个等价于测全部。
- **例子**:有效类 `[0,120]`;无效类 `年龄<0`、`年龄>120`、`非整数`。
- **适用**:输入域大、取值连续的场景,是最基础的第一步。

### 3.2 边界值分析

- **定义**:专测等价类的**边界**(上点、内点、离点)。
- **原理**:绝大多数缺陷集中在边界,因为比较符(`<` vs `<=`)最易写错。
- **例子**:测 `-1, 0, 1, 119, 120, 121`。
- **适用**:几乎与等价类配对使用,是**性价比最高的方法**之一。

### 3.3 判定表

- **定义**:把"多个条件 → 多个动作"的复杂逻辑列成表格,每一列是一条规则。
- **原理**:把组合逻辑穷举出来可避免漏分支,天然对应 `if/else` 与业务规则表。
- **例子**:条件"是会员""年龄<18""余额充足",动作"是否打折""是否拦截"。
- **适用**:规则引擎、权限矩阵、资费计算等多条件组合场景。

### 3.4 因果图

- **定义**:把输入(因)与输出(果)的因果、约束关系画成图,再转判定表。
- **原理**:先建模约束(互斥、包含、唯一),再生成用例,减少遗漏。
- **适用**:输入之间存在逻辑约束的场景,是判定表的"前置建模"步骤。

### 3.5 正交实验 / 成对组合(Pairwise)

- **定义**:选取尽量少的组合,覆盖任意两因素的所有取值对。
- **原理**:缺陷多由两两交互触发,故成对覆盖性价比极高。
- **例子**:3 个开关各 2 种状态,全组合 8 条,成对只要 4 条。
- **适用**:配置组合、兼容性矩阵、大量开关的开关组合测试。

### 3.6 状态迁移测试

- **定义**:把系统建模为状态机,设计用例覆盖状态与迁移(0-switch / 1-switch 覆盖)。
- **原理**:大量缺陷来自非法迁移或"卡在某状态"。
- **例子**:订单"待支付 → 已支付 → 已发货 → 已完成",需覆盖非法跳转如"待支付 → 已发货"。
- **适用**:订单、支付、审批流、连接会话等有明确状态的系统。

### 3.7 场景法

- **定义**:以"用户完成某目标"的完整路径为一条用例,含基本流与备选流。
- **原理**:贴近真实业务闭环,能暴露跨步骤的集成问题。
- **例子**:登录 → 加购 → 下单 → 支付 → 退款。
- **适用**:端到端业务流程验证。

### 3.8 错误推测

- **定义**:基于经验、历史缺陷与"直觉"直接列出易错点。
- **原理**:形式化方法覆盖不到的地方,靠经验补位。
- **适用**:作为其他方法的**补充**,不是替代。

### 3.9 探索性测试(SBTM)

- **定义**:不以预写用例为主,而是"设计—执行—学习"同时进行,用**会话(Session)**组织,以时间盒约束。
- **原理**:在需求不全、时间紧、或需要发现"未知的未知"时效率最高。
- **适用**:新功能探索、上线前的突击验证、复杂交互。

### 3.10 用例的粒度与结构

一条合格用例至少包含:**前置条件 / 输入数据 / 操作步骤 / 预期结果**。
- 预期结果必须**可判定**(避免"界面正常"这类无法验证的描述)。
- 用例应与**需求/风险**建立追溯关系(需求-用例-缺陷三向矩阵)。

---

## 四、按工程/职业方向展开

> 每个方向按 **问题域 → 理论 → 知识 → 方法 → 方案 → 指标** 六层说明。

### 4.1 功能测试

- **问题域**:验证软件"做得对不对",是所有方向的公共底座。
- **理论**:需求可测性、用例设计方法论(见第三部分)、基于风险的测试。
- **知识**:业务流程建模、需求分析、缺陷生命周期、用例管理。
- **方法**:等价类/边界值/判定表/场景法;用例分层(冒烟 → 主流程 → 异常 → 边界);回归策略(全量/精准/影响面分析)。
- **方案**:用例管理工具(TestRail、Xray、禅道);三向追溯矩阵;FMEA 风险打分。
- **指标**:需求覆盖率、用例执行率、缺陷发现率、缺陷逃逸率。

### 4.2 自动化测试

- **问题域**:把重复、稳定、高价值的验证交给机器,换取速度与频率。
- **理论**:测试金字塔、**FIRST 原则**(Fast/Isolated/Repeatable/Self-validating/Timely)、隔离性与幂等性。
- **知识**:断言设计、测试数据管理、Mock/Stub/Spy/Fake 的差别、依赖注入、异步等待与同步。
- **方法**:
  - 模式:录制回放、关键字驱动、数据驱动、行为驱动(BDD, Given-When-Then)。
  - 结构:页面对象模型(POM)、Screenplay 模式。
  - 治理:失败重试、**flaky(不稳定)测试**识别与隔离。
- **方案**:单测 Jest / Vitest / JUnit / pytest;接口 RestAssured / Supertest / httpx;UI Playwright / Cypress / Selenium / Appium;CI 集成于 GitHub Actions / GitLab CI / Jenkins。
- **指标**:自动化率、执行时长、flaky 率、失败定位耗时。

**自动化测试的铁律**:不稳定比没有更糟——它会消耗团队对测试的信任。**宁可少,也要稳。**

### 4.3 测试开发 / TestOps

- **问题域**:测试本身也是软件工程,需要平台化、服务化。
- **理论**:测试左移/右移、持续测试、**DORA 指标**、可测试性设计。
- **知识**:CI/CD 流水线、容器与编排、测试环境治理、测试数据构造、质量门禁。
- **方法**:测试即服务(能力封装为 API/CLI)、环境一键拉起、用例智能选取(仅跑受影响用例)、质量看板与趋势分析。
- **方案**:Jenkins / GitLab CI / GitHub Actions;Docker Compose / **Testcontainers**(真实依赖一键起);K8s;自研测试平台。
- **指标**:流水线时长、环境就绪时长、回归反馈周期、DORA 四指标(部署频率、变更前置时间、变更失败率、MTTR)。

### 4.4 性能测试

- **问题域**:系统"扛不扛得住"以及"够不够快"。
- **理论**:吞吐量-响应时间-并发-资源利用率四者关系;**Little's Law**(L = λW);**Amdahl 定律**(可扩展性上限);排队论;性能拐点与容量模型。
- **知识**:TPS/QPS、**分位数(P95/P99)而非平均值**、思考时间、并发用户模型、瓶颈定位(CPU/IO/GC/锁/DB/网络)。
- **方法**:基准测试、负载测试、压力测试、稳定性/疲劳测试(长时间)、尖峰测试;**阶梯加压找拐点**;全链路压测;瓶颈分析用 **USE**(利用率/饱和度/错误)与 **RED**(速率/错误/时延)方法。
- **方案**:JMeter、**Locust**、**k6**、Gatling、wrk;APM(Pinpoint/SkyWalking)、Arthas、火焰图;全链路压测平台。
- **指标**:TPS、P95/P99 延迟、错误率、资源水位、最大并发承载、恢复时间。

**常见误区**:只看平均响应时间。平均值会掩盖 P99 的长尾劣化,而用户与 SLA 惩罚的正是长尾。

### 4.5 安全测试

- **问题域**:系统"会不会被打穿"以及"数据会不会泄露"。
- **理论**:**OWASP Top 10**、**STRIDE 威胁建模**、CIA 三要素(机密性/完整性/可用性)、攻击面分析、纵深防御。
- **知识**:注入类(SQL/命令/模板)、XSS/CSRF/SSRF、越权(IDOR)、认证鉴权、加密与密钥管理、依赖漏洞、序列化与反序列化。
- **方法**:SAST(静态)、DAST(动态)、IAST(交互)、SCA(依赖成分)、RASP(运行时);渗透测试、**模糊测试(Fuzzing)**、灰盒代码审计;把安全活动嵌入 SDL / DevSecOps 流程。
- **方案**:Burp Suite、OWASP ZAP、Semgrep、SonarQube、Trivy / Dependabot / Renovate;AFL++ / libFuzzer。合规可参照等保、ISO 27001、PCI-DSS。
- **指标**:漏洞数量与严重度分布、修复时长(MTTR)、高危遗留数、依赖漏洞覆盖率。

**注意**:安全测试需要**明确授权**。未授权的渗透测试在多数司法辖区是违法行为。

### 4.6 移动端测试

- **问题域**:客户端碎片化 + 端上资源受限 + 移动网络不可靠。
- **理论**:客户端测试金字塔(大量单测 + 少量 UI 自动化);兼容性矩阵理论;端上资源模型(内存/电量/流量/CPU)。
- **知识**:Android/iOS 差异、机型与系统碎片化、权限与隐私、前后台与生命周期、热更新/动态化、推送。
- **方法**:真机云测(规模覆盖)、**Monkey** 稳定性测试、弱网模拟、埋点校验、灰度发布验证、性能基线对比。
- **方案**:Appium、Espresso / XCUITest、Airtest;云真机(WeTest、Firebase Test Lab);Charles / Fiddler 抓包改包。
- **指标**:机型覆盖率、崩溃率、ANR 率、启动耗时、内存峰值、流量与耗电。

### 4.7 服务端 / 接口与契约测试

- **问题域**:服务边界的正确性、稳定性和上下游兼容性。
- **理论**:契约先行;**幂等与最终一致性**;CAP 与分布式事务;协议语义。
- **知识**:REST / gRPC / GraphQL / WebSocket、鉴权(OAuth/JWT)、限流熔断、缓存与数据库一致性、消息中间件。
- **方法**:接口用例分层(参数/鉴权/边界/异常/并发);**流量回放**;新旧版本 **Diff 对比**;Mock 挡板;**消费者驱动契约(CDC)**验证。
- **方案**:Postman / Newman、RestAssured、Supertest、Karate;**Pact** / Spring Cloud Contract、Schemathesis(基于 OpenAPI);WireMock / Hoverfly;GoReplay。
- **指标**:接口覆盖率、契约通过率、联调阻塞时长、线上接口错误率。

**契约测试的价值**:用"消费者声明期望 + 提供者验证"取代大量脆弱的端到端联调,把集成问题左移到 CI。

### 4.8 大数据与数据质量测试

- **问题域**:数据管道与数仓的正确性、口径一致性与及时性。
- **理论**:**数据质量六维度**——完整性、准确性、一致性、及时性、唯一性、有效性;数据血缘。
- **知识**:数仓分层(ODS/DWD/DWS/ADS)、ETL/ELT、批处理与流处理差异、指标口径定义、分区与数据倾斜。
- **方法**:源-目标**对账**、指标公式校验、T+1 比对、分区与空洞检查、**幂等重跑**验证、波动与异常检测。
- **方案**:Great Expectations、dbt tests、Soda;数据对账平台;DolphinScheduler / Airflow 挂载校验任务;Debezium 校验 CDC。
- **指标**:对账一致率、口径偏差、任务成功率、数据时效(SLA)、脏数据占比。

---
### 4.9 专项测试(非功能聚焦点)

- **问题域**:针对单一非功能属性的深度验证,通常与移动端/客户端强相关。
- **理论**:非功能质量模型(ISO 25010)、场景化验收、基线对比法。
- **知识**:弱网/丢包/抖动、电量与流量、**内存泄漏与 OOM**、启动耗时、卡顿/掉帧、ANR。
- **方法**:断点续传与降级验证、长稳测试(72h+)、Monkey、**基线对比**(版本间回归)、场景复现。
- **方案**:Network Link Conditioner、tc/netem、Charles 弱网预设;Perfetto / Systrace / Instruments;LeakCanary、MAT。
- **指标**:崩溃率、ANR 率、P90 启动耗时、内存峰值与增长斜率、耗电 mAh/h。

### 4.10 AI / 算法与 LLM 评测

- **问题域**:输出是**概率性**的,不能再用"精确等值"来判定。
- **理论**:模型评测理论(精确率/召回率/F1/AUC)、过拟合与泛化、公平性与鲁棒性、**数据分布漂移**;**LLM 特有**:幻觉、有害性、指令遵循、上下文一致性。
- **知识**:数据集质量与标注一致性、离线指标 vs 在线指标、A/B 实验与显著性检验、评测集构建、奖励/偏好数据。
- **方法**:留出集与交叉验证、对抗样本、分布漂移监控、**LLM-as-Judge** 自动评测、人工评分量表(如 Likert)、红队测试、提示词回归套件。
- **方案**:scikit-learn / PyTorch 指标库、MLflow、Evidently;**RAGAS**(RAG 评测)、Promptfoo / OpenAI Evals;A/B 实验平台。
- **指标**:准确率/召回/F1、幻觉率、拒答率、人工偏好胜率、离线-在线一致性。

**核心差异**:传统测试问"等于不等于",AI 评测问"**多大概率算好,阈值是多少,分布变了没有**"。

### 4.11 云原生与混沌工程

- **问题域**:分布式系统"部分失效是常态",需要验证容错能力。
- **理论**:**稳态假设(Steady State Hypothesis)**、爆炸半径控制、可观测性三支柱(日志/指标/链路)、**SLO/SLI/错误预算**。
- **知识**:K8s 编排、服务网格、声明式配置、弹性与自愈、依赖降级。
- **方法**:故障注入(节点/网络/依赖/延迟)、金丝雀与蓝绿验证、混沌实验闭环(假设 → 注入 → 观测 → 修复)。
- **方案**:**Chaos Mesh**、Litmus、Gremlin;**Prometheus + Grafana + OpenTelemetry**;K6 + K8s 做弹性验证。
- **指标**:SLO 达成率、错误预算消耗、故障恢复时长、MTTD/MTTR。

### 4.12 游戏测试

- **问题域**:实时交互、海量状态组合、经济系统与数值平衡。
- **理论**:状态机与场景覆盖、数值平衡与期望验证、概率正确性。
- **知识**:帧率与延迟、客户端预测与回滚、多端一致性、活动与充值经济、弱网下的同步。
- **方法**:玩法路径穷举、**机器人压测**(模拟真实玩家)、数值回归、兼容性云测、内存与性能剖析。
- **方案**:自研机器人框架、Unity Test Framework / Unreal Automation、云真机、抓包与内存分析工具。
- **指标**:Crash 率、帧率分布、登录/匹配成功率、数值偏差、单局内存峰值。

### 4.13 车载 / IoT / 嵌入式

- **问题域**:实时性、安全性、硬件耦合与长周期验证。
- **理论**:实时系统约束(确定性时延)、**功能安全(ISO 26262 / IEC 61508)**、失效模式分析(FMEA/FTA)。
- **知识**:总线协议(CAN/LIN/以太网)、**HIL/SIL/MIL**、OTA 升级、低功耗与长稳、信息安全(ISO 21434)。
- **方法**:硬件在环(HIL)测试、台架测试、故障注入、实车/实地路测、长期稳定性(震动/高低温)。
- **方案**:Vector CANoe / CANalyzer、dSPACE、LabVIEW;硬件夹具 + 自动化脚本;仿真环境(SIL)。
- **指标**:时延确定性与抖动、故障覆盖率、安全完整性等级(ASIL)达成、OTA 成功率。

---

## 五、如何组合成一套可落地的测试策略

### 5.1 分阶段演进路径

不要一次全上,按"先能跑通,再逐层加固"的顺序推进:

1. **打地基**:需求可测性评审 + 用例设计方法论 + 基于风险的优先级。**先让功能测试可靠。**
2. **提效率**:建立自动化分层(单测 → 接口 → UI 冒烟),接入 CI。**接口/服务端自动化投入产出比最高。**
3. **建平台**:环境一键化、测试数据构造、质量门禁、测试报告看板(TestOps)。
4. **补专项**:按业务风险补 性能 / 安全 / 兼容性 / 契约。
5. **右移**:灰度发布、生产监控、混沌实验、A/B 与线上验证。

### 5.2 一个最小可用测试策略模板

```
目标:在 N 周内,以可控成本支撑 M 次/周的发布,风险可控。
范围:被测系统边界 + 明确不测的范围(防范围蔓延)。
风险:Top 5 高风险模块 → 对应测试强度(深度/频率)。
分层:单元 X% | 接口 Y% | UI 冒烟 Z 条关键路径。
非功能:性能基线、安全扫描、兼容性机型矩阵。
门禁:合并前必须通过单测+lint;发布前必须通过冒烟+性能基线。
指标:缺陷逃逸率、回归反馈时长、flaky 率、SLO 达成率。
```

### 5.3 质量门禁与指标(不要只追一个数)

- **过程**:需求覆盖率、自动化率、回归周期、环境就绪时长。
- **结果**:缺陷逃逸率、线上故障数、MTTR、SLO 达成率。
- **健康度**:flaky 率、用例维护成本、覆盖率(仅作参考,不作 KPI)。

---

## 六、附录

### 6.1 工具速查表

| 用途 | 代表工具 |
| --- | --- |
| 单元测试 | Jest、Vitest、JUnit、pytest、Go testing |
| 接口测试 | Postman/Newman、RestAssured、Supertest、Karate、httpx |
| UI 自动化 | Playwright、Cypress、Selenium、Appium |
| 契约测试 | Pact、Spring Cloud Contract、Schemathesis |
| Mock/挡板 | WireMock、Hoverfly、MSW |
| 性能测试 | JMeter、Locust、k6、Gatling、wrk |
| 安全测试 | Burp、ZAP、Semgrep、SonarQube、Trivy |
| 模糊测试 | AFL++、libFuzzer、Jazzer |
| 数据质量 | Great Expectations、dbt tests、Soda |
| 混沌工程 | Chaos Mesh、Litmus、Gremlin |
| 可观测性 | Prometheus、Grafana、OpenTelemetry、SkyWalking |
| 云真机/兼容 | Firebase Test Lab、WeTest、BrowserStack |
| LLM 评测 | RAGAS、Promptfoo、OpenAI Evals |
| CI/CD | GitHub Actions、GitLab CI、Jenkins |

### 6.2 术语表

- **Oracle(预言)**:判断输出是否正确的依据。
- **Flaky 测试**:同一代码多次运行结果不一致的测试。
- **MC/DC**:修正条件/判定覆盖,航电等高安全领域的强制覆盖标准。
- **CDC**:消费者驱动契约。
- **Little's Law**:并发数 = 到达率 × 停留时间。
- **SLO/SLI/错误预算**:服务目标/指标/可消耗的失败额度。
- **P95/P99**:分位数延迟,反映长尾。
- **DER**:缺陷逃逸率。
- **HIL/SIL/MIL**:硬件/软件/模型在环测试。

### 6.3 学习路径

- **入门(0-3 月)**:功能测试 + 用例设计方法论(第三部分全部) + 缺陷管理。
- **进阶(3-12 月)**:自动化分层、接口测试、CI 集成;选一个方向深耕(性能或安全最通用)。
- **深化(1-3 年)**:TestOps 平台化、可观测性、契约测试、混沌工程;补 DORA 与 SLO 体系。
- **专精(3 年+)**:按业务选纵深——AI 评测 / 大数据 / 车载安全 / 云原生架构级质量。

---

## 结语

三句话概括整份报告:

1. **理论是地心引力**:层次、方法、类型、质量模型、风险与覆盖率,决定了"该测什么、测多深"。
2. **方法是通用语言**:用例设计方法论是所有方向共享的技能,不会过时。
3. **方向是纵深**:每个工程方向都是"某质量属性 + 某套方法 + 某类工具"的长期积累;**选方向时,业务知识往往比测试技术更稀缺。**

> 若需要,我可以把本报告转成 Word/PDF 版本,或针对某个方向(如性能测试或自动化分层)再展开成一份可直接执行的落地方案。