测试类型
§1摘要与结论
测试类型是与特定质量特性相关的一组测试活动，如功能测试与非功能测试，也可按是否依赖内部结构分为黑盒、白盒与经验型；大多数测试类型可应用于每一个测试层次，层次与类型是两个正交的坐标。
别名：test type、test types、测试类型、功能与非功能测试、黑盒白盒 | 英文：Test Types | 类型：方法 / process
§2局部关系图
§3原理 · 为什么
测试类型回答的是「测什么性质」，而测试层次回答的是「在什么范围测」，二者正交。按质量特性划分，功能测试验证系统是否完成了规定的功能，非功能测试验证性能、可靠性、安全、可用性等质量特性在不同条件下的表现。按对内部结构的依赖划分，黑盒测试仅依据外部规格设计用例，白盒测试依据代码或结构信息设计用例，经验型测试则依赖测试者的经验、知识与直觉。类型正交于层次意味着：同一个质量特性可以在不同层次被验证，同一个层次也可以执行多种类型的测试。把类型与层次分开，能避免把某一类测试错误地绑定到某个层次，也能帮助团队检查质量维度的覆盖是否完整——只做功能测试会遗漏非功能风险，只做黑盒测试会遗漏结构性的实现缺陷。类型的选择应由要降低的风险决定，而非由习惯或工具便利决定。
§4机制 · 如何运作
测试设计技术是把测试类型落为具体用例的手段。规格型（黑盒）技术依据需求与接口设计用例，如等价类划分、边界值分析、决策表、状态迁移与用例场景；结构型（白盒）技术依据代码结构，如语句覆盖、分支覆盖与路径覆盖；经验型技术依赖测试者判断，如错误推测、探索性测试与清单式检查。不同类型技术对缺陷的揭示能力不同：黑盒更易发现规格与需求层面的偏差，白盒更易发现实现层面的结构性缺陷，经验型则擅长发现规格未言明、难以形式化的风险。非功能测试通常需要专门的负载、故障注入或安全探测手段来构造其触发条件。因此有效的测试方案会依据目标缺陷类型混合使用多种技术，并为每类技术设定相应的覆盖度量，用以判断抽样是否触及了预期的区域，而不是把某一种技术当作普遍适用的答案。
§5工程 · 怎么落地
实践中先明确要被降低的风险，再选择测试类型与技术。为功能维度，用规格型技术覆盖正常路径、边界与异常路径；为结构维度，用覆盖度量驱动白盒技术补充实现层面的用例；为经验维度，安排探索性测试与基于缺陷历史的错误推测。为质量特性维度，把性能、可靠性、安全、兼容性等非功能目标转写为可度量的场景，并设计能构造相应条件的测试。类型选择应覆盖不同层次：单元级多用白盒与经验型，集成级侧重接口与契约，系统级侧重端到端功能与非功能，验收级侧重业务价值。应用时应避免重复与遗漏：用用例来源矩阵检查每个需求与质量特性在哪些层次、由哪类测试覆盖，识别空档。最后应让测试类型随风险变化调整，在缺陷分布或业务重点改变时重新平衡投入，而不是固定一套技术长期不变。对关键质量特性应明确其验收场景与判定依据，使非功能测试同样具备可比较、可复现的结论，而非停留在主观感受。
§6权衡卡
反例之一是把测试类型等同于工具类别，用「用了某类工具」代替「覆盖了某类风险」，导致类型齐全而风险空档仍在。
反例之二是只追求功能测试的通过率，忽略非功能特性，直到上线后在高负载或攻击下才暴露问题。
- 技术越多、用例越多，测试套件的维护负担越重，且不同类型测试可能彼此重复，消耗资源却不增加有效覆盖。
- 类型与层次的组合应在覆盖矩阵中被显式登记与复核。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7学习路径条
§8案例带
插件 DAG RC5→RC7 升级
一次知识库随上游源码版本升级的级联维护：以三层差异分析把 219 个包收敛为 26 个实质变更包，经编译、运行时、组合三类依赖判定更新 DAG 数据后全量重生成页面，并以静态门控加渲染验证收口。
§9信源与核验
核验结论：测试类型与测试层次是两个正交坐标，大多数测试类型可应用于每一个测试层次；不同类型技术对缺陷的揭示能力不同，应依据目标风险混合选用 [OFF-018]
§10原始关系清单
展开：本节点的全部原始关系边（3 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 依据推导 | → ESS-I-02 | 可测试性本质 E-486 | 测试类型设计以可测试性为结构前提 |
| 实现 | ← TEC-I-02 | 关键字驱动测试框架 E-820 | 关键字驱动测试作为规格化黑盒测试类型的实现 |
| 前置依赖 | ← MTH-I-01 | 测试层次 E-490 | 测试层次是应用测试类型的结构前提 |