测试基础知识：软件测试分类、黑盒与白盒、测试用例设计原则、测试生命周期
做 SDK 测试之前，得先把基本功打牢。很多新人一上来就写脚本，结果漏了边界条件，跑完发现覆盖率惨不忍睹。我个人习惯，先理清测试的“地图”再动手。这一节就把测试的那些核心概念串一遍。
软件测试分类
测试可以从不同角度切分。最常见的三种分法：按是否执行代码、按测试阶段、按测试方法。
- 静态 vs 动态 – 静态就是不跑代码，光看文档、走查代码。动态就是真正运行被测对象。
- 阶段分类 – 单元测试、集成测试、系统测试、验收测试。SDK 验证里，单元和集成是重头戏。
- 方法分类 – 黑盒、白盒、灰盒。下面重点讲。
教训： 我在项目里见过有人把冒烟测试当成系统测试来写，结果 bug 全堆积到后期。分类不是纸上谈兵，选对类型才能命中要害。
黑盒测试与白盒测试
黑盒和白盒，说白了就是“看不看代码”的区别。
| 维度 | 黑盒测试 | 白盒测试 |
|---|---|---|
| 关注点 | 功能、输入输出、用户场景 | 代码逻辑、分支、路径覆盖 |
| 用例设计依据 | 需求文档、接口规范 | 程序结构、流程图 |
| 常见技术 | 等价类划分、边界值分析 | 语句覆盖、分支覆盖、条件组合 |
| 适用阶段 | 系统测试、验收测试 | 单元测试、集成测试 |
| 优点 | 不依赖代码实现，验证外部行为 | 能发现隐藏的逻辑缺陷 |
| 缺点 | 可能漏掉内部逻辑路径 | 成本高，需要维护代码知识 |
个人经验： 我在做 SDK 验证时，接口多、文档不全，经常先用黑盒把主流程跑通，再用白盒补分支。两套结合，覆盖率能从 40% 飙到 80% 以上。
测试用例设计原则
不管你用什么方法，设计用例都得守住几条铁律。
- 有效性 – 每个用例都要有明确目的。别写“随便点一下”。
- 可重复性 – 同样的输入、环境、步骤，每次结果一致。
- 独立性 – 用例之间不依赖顺序。我踩过坑：用例 A 创建了数据，用例 B 没清干净，导致 C 反复失败。后来加了 setUp/tearDown 才稳住。
- 可追溯性 – 每条用例都能对应到需求或接口定义。
- 覆盖率优先 – 先覆盖所有正常路径和边界，再搞异常、压力。
避坑指南： 我曾经在一个 SDK 项目里，测试用例全是“快乐路径”，结果上线后用户在特定参数组合下崩了。从那以后，我强制要求每个模块至少写 2 个边界用例和 1 个非法参数用例。
测试生命周期
测试不是一锤子买卖。正规流程一般分这几个阶段：
- 计划与控制 – 定范围、选工具、评估风险。
- 分析与设计 – 评审需求、设计用例。
- 实现与执行 – 写脚本、跑测试、记录结果。
- 评估与报告 – 分析失败原因、出报告、确认是否发布。
- 收尾与复盘 – 归档用例、总结教训、优化流程。
下面这张图把上面提到的核心概念串在一起，方便你快速建立起知识结构。
实用建议： 对 SDK 验证来说，我最常用的是黑盒 + 集成测试的组合。接口文档写清楚，边界值填进去，再配上自动化脚本，几轮下来就能把大部分风险锁死。