【白盒测试】单元测试的理论基础及用例设计技术（6种）详解

🌞前言

[🏞️1. 单元测试的理论基础](#🏞️1. 单元测试的理论基础)

[🌊1.1 单元测试是什么](#🌊1.1 单元测试是什么)

[🌊1.2 单元测试的好处](#🌊1.2 单元测试的好处)

[🌊1.3 单元测试的要求](#🌊1.3 单元测试的要求)

[🌊1.4 测试框架-Junit4的介绍](#🌊1.4 测试框架-Junit4的介绍)

[🌊1.5 单元测试为什么要mock](#🌊1.5 单元测试为什么要mock)

[🏞️2. 单元测试用例设计技术（6种）](#🏞️2. 单元测试用例设计技术（6种）)

[🌊2.1 语句覆盖](#🌊2.1 语句覆盖)

[🌊2.2 判定覆盖【也称分支覆盖】](#🌊2.2 判定覆盖【也称分支覆盖】)

[🌊2.3 条件覆盖](#🌊2.3 条件覆盖)

[🌊2.4 判定条件覆盖](#🌊2.4 判定条件覆盖)

[🌊2.5 组合覆盖](#🌊2.5 组合覆盖)

[🌊2.6 路径覆盖](#🌊2.6 路径覆盖)

🌞前言

白盒测试【 也称透明盒测试、结构测试或逻辑驱动测试**】**：

定义： 白盒测试是把测试对象看作一个透明白色的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。

目的： 白盒测试旨在验证程序的内部逻辑是否正确，检查代码覆盖率，并找出可能存在的编程错误、逻辑错误和性能问题。

测试对象： 白盒测试通常由开发人员或专业的测试工程师执行，他们具有编程和软件设计方面的专业知识。

测试方法： 白盒测试通常使用技术性的测试方法，如语句覆盖、分支覆盖、路径覆盖等，以确保对代码的各个部分进行了充分的测试。

黑盒测试【 也称功能测试或规格驱动测试**】**：

定义： 黑盒测试是把测试对象看作一个黑色不透明的盒子，在不考虑程序内部结构和实现细节的情况下设计和执行测试用例的过程。测试者只关注输入和输出之间的关系，而不考虑内部工作原理。

目的： 黑盒测试旨在验证软件的功能是否符合规格说明和用户需求，检查系统的功能完整性和正确性。

测试对象： 黑盒测试通常由测试人员执行，不用了解系统的内部实现细节，只根据需求文档和功能规格进行测试。

测试方法： 黑盒测试通常使用功能性测试方法，如等价类划分、边界值分析、场景测试等，以验证系统的功能是否符合预期。

综上，白盒测试和黑盒测试的主要区别在于测试者对系统内部结构的了解程度。白盒测试关注程序内部逻辑和代码覆盖率，而黑盒测试则关注系统的功能和用户体验。

🏞️1. 单元测试的理论基础

🌊1.1 单元测试是什么

单元测试 是软件开发中的一种测试方法（由开发者编写 ），对程序中的最小可测试单元 （通常是函数、方法或类）进行检查和验证。通常一个单元测试是由于判断每个特定条件（或场景）下某个特定函数的行为。

🌊1.2 单元测试的好处

测试更充分：单元测试属于白盒测试

bug修复代价最少

代码自review

代码功能更具易用性

回归测试

快速定位bug

🌊1.3 单元测试的要求

全自动执行
独立
可重复执行
需要维护

🌊1.4 测试框架-Junit4的介绍

JUnit 4 中常用的注解包括：

@Test: 用于标识测试方法。

@Before: 标识在每个测试方法之前需要执行的方法。

@After: 标识在每个测试方法之后需要执行的方法。

@BeforeClass: 标识在测试类加载时需要执行的方法。

@AfterClass: 标识在测试类销毁时需要执行的方法。

@Ignore 或 @Ignore("reason"): 标识忽略测试方法，可以附带原因说明。

@RunWith: 指定测试运行器，如 @RunWith(Parameterized.class) 用于参数化测试。

@Rule: 用于创建测试规则，如 @Rule public ExpectedException exception = ExpectedException.none() 用于测试异常。

Junit4的单元测试用例的执行顺序

@BeforeClass->@Before->@Test->@After->@AfterClass

每个测试方法的调用顺序

@Before->@Test->@After

🌊1.5 单元测试为什么要mock

单元测试中使用 Mock 的主要目的是解决测试环境的依赖性和复杂性。

提高测试用例的速度: 在单元测试中，有时无法直接访问外部依赖，或者外部依赖的操作会耗费较长时间。通过 Mocking，可以避免真实的外部调用，从而提高测试的速度。
**解除外部依赖：**从而将测试的焦点放在被测试组件本身，而不受外部依赖的影响。比如数据库、第三方接口等，使测试用例可以独立运行。
**减少工作量：**减少编写测试用例的工作量，提高效率。

综上，使用 Mock 是为了更好地隔离测试目标、消除测试环境的不确定性、提高测试速度、模拟异常情况以及降低测试成本，从而使单元测试更加简单、可靠和高效。

🏞️2. 单元测试用例设计技术（6种）

单元测试用例设计技术可分成大致6种，由弱至强，工作量由低到高：

语句覆盖：程序中每条语句至少被执行一次。

判定覆盖【也称分支覆盖 】：确保每个分支的两个可能的结果都被至少一次执行。即每个判断的取真、取假至少执行一次。

条件覆盖：每一个判断中的每个子句的不同true false都要取一次。

判定条件覆盖：确保每个分支的两个可能的结果以及每个条件的每个可能的结果都被至少一次执行（即满足条件覆盖+判定覆盖）。

组合覆盖【也称条件组合覆盖】：确保每个条件的每个可能的组合结果都被至少一次执行（比如x>=80 and y>=80,这个判断可拆分成如x>=80、y>=80,那么测试用例需要让其分别满足 T T、T F、F T、F F）。

路径覆盖：覆盖程序的所有可能的路径。

🌊2.1 语句覆盖

**语句覆盖：**程序中每条语句至少被执行一次。

【案例】语句覆盖

语句覆盖的测试用例

用例序号	X	Y	路径
1	50	50	OBDE
2	100	40	OBCE
3	90	90	OAE

说明：上述示例覆盖了所有语句【1 ->T、2 ->T、3 ->T】。

x=50 y=50：覆盖了语句【3 ->T】

x=100 y=40：覆盖了语句【2 ->T】

x=90 y=90：覆盖了语句【1 ->T】

🌊2.2 判定覆盖【也称分支覆盖】

**判定覆盖：**确保每个分支的两个可能的结果都被至少一次执行。即每个判断的取真、取假至少执行一次。

【案例】评定覆盖（也称分支覆盖）

判定覆盖的测试用例

用例序号	X	Y	路径
1	50	50	OBDE
2	100	40	OBCE
3	90	90	OAE

说明：上述示例覆盖了所有分支。

x=50 y=50：覆盖了分支【No-No】

x=100 y=40：覆盖了分支【No-Yes】

x=90 y=90：覆盖了分支【Yes】

🌊2.3 条件覆盖

**条件覆盖：**每一个判断中的每个子句的不同true false都要取一次。

【案例】条件覆盖

条件覆盖的测试用例

这里其实有四个判断子句，分别是：x>=80、y>=80、x+y=140、(x>90 or y>90).

可以这样设计条件覆盖的测试用例：

x取值	y取值	x>=80	y>=80	x+y=140	(x>90 or y>90)
60	85	F	T	F	F
100	40	T	F	T	T

说明：上述示例覆盖了所有判断子句。

x=60 y=85 与 x=100 y=40 覆盖了四个判断子句为 true 和 false 的情况。

🌊2.4 判定条件覆盖

**判定条件覆盖：**确保每个分支的两个可能的结果以及每个条件的每个可能的结果都被至少一次执行（即满足条件覆盖+判定覆盖）。

【案例】判定条件覆盖

判定条件覆盖的测试用例

X	Y	路径	x>=80	y>=80	x+y=140	(x>90 or y>90)	覆盖分支
90	90	OAE	T	T	F	F	Yes
50	50	OBDE	F	F	F	F	No-No
100	40	OBCE	T	F	T	T	No-Yes

说明：上述示例覆盖了所有判断子句+分支。

🌊2.5 组合覆盖

组合覆盖【也称条件组合覆盖】：确保每个条件的每个可能的组合结果都被至少一次执行（比如x>=80 and y>=80,这个判断可拆分成如x>=80、y>=80,那么测试用例需要让其分别满足 T T、T F、F T、F F）。

【案例】组合覆盖

组合覆盖的测试用例

组合覆盖需要拆分判断子句

对于第一个判断 x>=80 and y>=80 ，由于不是原子的可进一步拆分成 x>=80 和 y>=80 。

那么测试用例需要让第一个判断分别满足下面的条件：

对于第二个判断x+y=140 and (x>90 or y >90) ，由于不是原子的可进一步拆分成x+y=140 、x>90 和y >90。那么测试用例需要让第二个判断分别满足下面的条件：

说明：测试示例需要覆盖上面所有的条件。

🌊2.6 路径覆盖

路径覆盖：覆盖程序的所有可能的路径。

【案例】路径覆盖

路径覆盖的测试用例

用例序号	X	Y	路径
1	50	50	OBDE
2	100	40	OBCE
3	90	90	OAE

说明：上述示例覆盖了所有路径。

x=50 y=50：覆盖了路径【OBDE】

x=100 y=40：覆盖了路径【OBCE】

x=90 y=90：覆盖了路径【OAE】