如何衡量单元测试？
单元测试的质量直接决定了其对业务代码的保障能力，核心关注准确性、完整性、可维护性、高效性四个维度，具体如下：
1. 断言
精准性 ：断言要针对被测试函数 / 方法的核心逻辑和预期输出，而非无关细节。
全面性 ：不仅要断言正常场景，还要覆盖边界场景、异常场景。
避冗余：不要写无意义的断言（如 assert True），也不要重复断言同一逻辑，避免用例臃肿。
2. 覆盖率
高覆盖率不代表高测试质量，比如一行代码被执行过，不代表其逻辑被验证过，需结合业务场景、覆盖率类型、断言有效性一起评估，常用覆盖率类型有：
语句覆盖率：是否每一行可执行代码都被执行过。这是最基础的指标，目标通常建议 80% 以上。
分支覆盖率：是否每一个条件分支都被覆盖。
路径覆盖率：是否覆盖了函数内所有可能的执行路径。该覆盖率成本较高，一般针对核心模块。
3. 用例质量
独立性 ：测试用例间无依赖，可独立运行，不因某个用例失败或执行顺序影响其他用例。
原子性 ：一个测试用例只测试一个功能点。
可复现性：测试结果稳定，相同输入下每次运行的结果一致。避免依赖随机数、未隔离的外部资源（如数据库、网络接口）。
4. 对外部依赖的隔离程度
第一： 单元测试的对象是 "单元"，需要隔离外部依赖（如数据库、第三方接口、缓存），否则会导致测试不稳定、执行缓慢。
第二： 使用 Mock/Stub 替代外部依赖：比如测试一个调用数据库的函数，用 Mock 框架模拟数据库的返回值，而非真实连接数据库。
**第三：**避免测试环境耦合：不要让测试用例依赖测试环境的配置（如特定的文件路径、环境变量），确保在任何环境下都能运行。
5. 可维护性
可读性 ：测试用例的命名要清晰，逻辑一目了然，方便其他人理解和维护。
低维护成本 ：当被测试代码的逻辑发生小改动时，对应的测试用例不需要大规模修改。比如通过封装通用的测试数据、使用参数化测试，可以减少重复代码。
参数化测试：对同一逻辑的多组输入输出，可以用参数化（如 JUnit5 的 @ParameterizedTest、Python 的 @pytest.mark.parametrize），避免写大量重复的测试用例。
6. 执行效率
单元测试需要频繁运行（如代码提交前、CI/CD 流程中），执行效率很关键。
第一 ：执行速度快：单个测试用例的执行时间应在毫秒级，避免在测试中做耗时操作（如大量数据的循环、网络请求）。
第二：可批量执行：支持一键运行所有单元测试，且能快速反馈结果。
7. 异常处理
很多 Bug 出现在异常场景，因此单元测试必须覆盖异常处理逻辑。
验证预期异常：比如测试一个除法函数，当除数为 0 时，是否抛出 DivideByZeroException。
验证异常后的行为：比如函数抛出异常后，是否释放了占用的资源，是否返回了预期的错误码。
单元测试质量自查清单
本清单从断言、覆盖率、用例设计、依赖隔离、可维护性、异常测试、执行效率7 个核心维度设计，可直接用于日常开发的测试用例校验。
| 检查维度 | 具体检查项 | 达标标准 | 备注 / 实操建议 |
|---|---|---|---|
| 1. 断言有效性 | 1.1 断言是否针对核心业务逻辑 | ✅ 断言直接验证函数 / 方法的预期输出，而非无关中间变量 | 例如：测试登录接口，断言 "登录成功后返回 token"，而非断言 "调用了数据库查询方法" |
| 1.2 是否覆盖正常 / 边界 / 异常场景 | ✅ 三类场景均有对应断言，无遗漏 | 边界场景：如参数最大值 / 最小值、空集合；异常场景：如非法入参、权限不足 | |
| 1.3 是否存在冗余 / 无效断言 | ✅ 无 assert True 类无意义断言，无重复断言同一逻辑 |
重复断言会增加维护成本，需及时清理 | |
| 2. 测试覆盖率 | 2.1 语句覆盖率是否达标 | ✅ 核心模块≥80%，非核心模块≥60% | 避免为了覆盖率写 "无效测试"，覆盖率是参考而非目标 |
| 2.2 分支覆盖率是否覆盖全条件 | ✅ 所有 if/else/switch 分支均被执行 |
例如：if(a>0) 需覆盖 a>0 和 a≤0 两种情况 |
|
| 2.3 是否覆盖关键路径 | ✅ 核心业务流程的所有执行路径均有测试 | 路径覆盖率成本高，优先覆盖高风险路径 | |
| 3. 用例设计质量 | 3.1 用例是否独立无依赖 | ✅ 单个用例可独立运行，执行顺序不影响结果 | 禁止用例之间共享测试数据，避免 "前一个用例失败导致后续用例全部失败" |
| 3.2 用例是否满足原子性 | ✅ 一个用例只测试一个功能点 | 例如：不允许在一个用例中同时测试 "用户注册" 和 "用户信息修改" | |
| 3.3 用例是否可复现 | ✅ 相同输入多次运行结果一致 | 避免依赖随机数、未隔离的外部资源（如真实数据库） | |
| 3.4 用例命名是否清晰 | ✅ 命名格式统一，如 test_功能名_场景 |
例如：test_add_num_normal test_add_num_negative_param |
|
| 4. 外部依赖隔离 | 4.1 是否隔离数据库 / 第三方接口 | ✅ 使用 Mock/Stub 替代真实外部依赖 | 推荐工具：Java→Mockito，Python→unittest.mock |
| 4.2 是否依赖测试环境配置 | ✅ 不依赖特定文件路径、环境变量、网络地址 | 测试资源应内置或通过配置文件统一管理 | |
| 5. 可维护性 | 5.1 是否使用参数化测试 | ✅ 同一逻辑的多组输入输出用参数化实现，无重复代码 | 例如：JUnit5 @ParameterizedTest、pytest @parametrize |
| 5.2 测试代码是否简洁可读 | ✅ 无复杂嵌套，辅助逻辑（如数据构造）封装为工具方法 | 测试代码的可读性优先级高于性能 | |
| 5.3 被测试代码改动后，测试维护成本是否低 | ✅ 核心逻辑不变时，测试用例无需修改 | 避免断言 "实现细节"，只断言 "业务结果" | |
| 6. 异常处理测试 | 6.1 是否测试预期异常 | ✅ 非法入参、资源不足等场景会抛出预期异常 | 例如：测试除法函数，除数为 0 时断言抛出 DivideByZeroException |
| 6.2 是否测试异常后的资源释放 | ✅ 异常发生后，占用的连接 / 文件等资源被正常释放 | 例如：数据库查询失败后，连接是否关闭 | |
| 7. 执行效率 | 7.1 单个用例执行时间 | ✅ 毫秒级完成，无秒级以上耗时用例 | 禁止在单元测试中做大量数据循环、网络请求 |
| 7.2 批量执行是否快速 | ✅ 全量单元测试执行时间≤5 分钟 | 可通过拆分测试套件，支持按模块执行 |