为关联的函数/方法打桩
当你想控制在测试过程中关联函数/方法的返回值时，你就需要为关联函数/方法建立替代值，打桩是集成和单元测试中非常重要的部分，因为它允许你从应用程序的其它部分中隔离出被测代码，更容易触发你所感兴趣的单元或子系统的执行。
许多工具都需要手动生成测试代码，才能使得桩（stub）不仅仅只是返回一个静态的标量值（return 0;）。
要点
> 桩是自动生成的，还是你为它们写的代码？
> 是否自动支持复杂的输出（结构体，类）？
> 每次调用桩能返回不同的值吗？
> 桩会记录它被调用的次数吗？
> 桩会记录多个调用的输入参数吗？
> 你可以对标准C的库函数比如malloc打桩吗？
测试数据
“半自动化”和“自动化”工具生成测试用例的基本方法有两种。一种是“数据驱动”架构，另一种是“单一测试”架构。
对于数据驱动架构，所有被测单元都创建了测试框架，并支持在这些单元中定义的所有函数/方法。当要运行测试时，工具只是简单地通过一个数据流，如文件句柄或像一个通用异步收发器(UART)一样的物理接口，提供执行所需的测试数据。
对于“单一测试”架构，在每次运行测试时，工具都将建立该测试的测试驱动程序，编译并链接成一个可执行文件。这里有两点需要注意：首先，单一测试方法所需要的额外的代码的生成、编译和链接在测试执行的时候都将花费更多的时间；其次，你最后要为每个测试用例建立一个单独的测试框架。
这意味着候选工具可能看上去在运行一些有名无实的测试用例，但可能在更复杂的测试中却无法正确地工作。
要点
> 测试框架是数据驱动的吗？
> 执行测试用例（包括所有代码生成和编译时间）要多久？
> 可以在测试工具IDE之外编辑测试用例吗？
> 如果不能，我是否已经用复杂的示例代码充分地玩转该工具以了解工具的所有限制了？
测试数据的自动化生成
一些“自动化”工具提供了测试用例在一定程度上的自动化创建。这可以用不同的方法来完成。以下段落描述了其中的一些方法：
|
MMM 极小-中间-极大值测试用例 |
MMM的测试将重点函数/方法的输入类型的边界值。 C和C ++代码通常不会控制超出边界范围的输入值。工程师已在他们头脑中已经清楚函数/方法的值域范围，他们却往往没有控制超出边界范围的输入。 |
|
EC等价类 |
等价类测试为每个数据类型创建了“分区”，并从每个分区选取了一个样本值。设定相同分区中的值将以同样的方式触发应用程序。 |
|
RV随机值 |
随机值测试会为每个函数/方法的参数设置随机值组合。 |
|
BP基本路径测试 |
基本路径测试使用基础路径分析来测试贯穿被测程序的各条可能的执行路径。基本路径测试可以自动达到一个高水平的分支覆盖率。 |
在考虑构建自动化测试用例时，要记住的关键一点是它们使用的目的。自动化测试可以很好地用于测试应用程序代码的健壮性，而不是正确性（即使它们提供了很高的代码覆盖率）。对于正确性，你创建的测试用例必须是基于应用程序应该要做什么（测试需求），而不是基于它做了什么（代码）。
