动态测试方法，通过实际执行代码去发现潜在代码错误的测试方法。
人工动态方法，可以真正检测代码的业务逻辑功能，其关注点是“什么样的输入，执行了什么代码，产生了什么样的输出”，主要用于发现算法错误和部分算法错误，是最主要的代码级测试手段。代码级测试的人工动态测试方法，其实就是单元测试所采用的方法。
单元测试，用驱动代码去调用被测函数，并根据代码的功能逻辑选择必要的输入数据的组合，然后验证执行被测函数后得到的结果是否符合预期。
单元测试中三个最主要的难点：
单元测试用例“输入参数”的复杂性；
单元测试用例“预期输出”的复杂性；
关联依赖的代码不可用。
单元测试用例“输入参数”的复杂性，表现在“输入参数”不是简单的函数输入参数。本质上讲，任何能够影响代码执行路径的参数，都是被测函数的输入参数。
第一，被测试函数的输入
参数 如示例的输入参数a和b
int someFunc(int a, int b)
{
…
}第二，被测试函数内部需要读取的全局静态变量。
如果被测函数内部使用了该函数作用域以外的变量，那么这个变量也是被测函数的输入参数。
bool someGlobalVariable = true；
void Func_SUT(int a)
{
...
if(someGlobalVariable == true)
{
FuncA();
}
else
{
FuncB();
}
...
}示例中 全局变量 someGlobalVariable，需要设计为true和false的情况，导致这个全局变量也成为了输入。
第三，被测试函数内部需要读取的类成员变量
class someClass{
...
bool someClassVariable = true；
...
void Func_SUT(int a)
{
...
if(someClassVariable == true)
{
FuncA();
}
else
{
FuncB();
}
...
}
...
}根据 someClassVariable 的取值不同，会执行两个不同的代码分支。同样地，单元测试想要覆盖这两个分支，就必须提供 someClassVariable 的不同取值，所以 someClassVariable 对于被测函数 Func_SUT 来说也是输入参数。
第四，函数内部调用子函数获得的数据
void Func_SUT(int a)
{
bool toggle = FuncX(a);
if(toggle == true)
{
FuncA();
}
else
{
FuncB();
}
}这里toggle 也成为一个被测函数的输入参数。
第五，函数内部调用子函数改写的数据
第六，嵌入式系统中，在中断调用中改写的数据
单元测试用例“预期输出”的复杂性，主要表现在“预期输出”应该包括被测函数执行完成后所改写的所有数据。
第一，被测函数的返回值
第二，被测函数的输出参数
第三，被测函数所改写的成员变量和全局变量
第四，被测函数中进行的文件更新、数据库更新、消息队列更新等
假设被测函数中调用了其他的函数，那么这些被调用的其他函数就是被测函数的关联依赖代码。
为了不影响被测函数的测试，我们往往会采用桩代码来模拟不可用的代码，并通过打桩补齐未定义部分
具体来讲，假定函数 A 调用了函数 B，而函数 B 由其他开发团队编写，且未实现，那么我们就可以用桩函数来代替函数 B，使函数 A 能够编译链接，并运行测试。
桩函数要具有与原函数完全相同的原形，仅仅是内部实现不同，这样测试代码才能正确链接到桩函数。一般来讲桩函数主要有两个作用，一个是隔离和补齐，另一个是实现被测函数的逻辑控制。
用于实现隔离和补齐的桩函数实现比较简单，只需拷贝原函数的声明，加一个空的实现，可以通过编译链接就可以了。用于实现控制功能的桩函数是最常用的，实现起来也比较复杂，需要根据测试用例的需要，输出合适的数据作为被测函数的内部输入。
自动动态方法是，基于代码自动生成边界测试用例并执行来捕捉潜在的异常、崩溃和超时的测试方法。
自动动态方法的重点是：如何实现边界测试用例的自动生成。
解决这个问题最简单直接的方法是，根据被测函数的输入参数生成可能的边界值
任何数据类型都有自己的典型值和边界值，我们可以预先为它们设定好典型值和边界值，然后组合就可以生成了。
比如，函数 int func(int a, char *s)，就可以按下面的三步来生成测试用例集。
定义各种数据类型的典型值和边界值。 比如，int 类型可以定义一些值，如 int 的最小值、int 的最大值、0、1、-1 等；char* 类型也可以定义一些值，比如“”、“abcde”、“非英文字符串”等。
根据被测函数的原形，生成测试用例代码模板，比如下面这段伪代码：
将参数 @a@和 @s@的各种取值循环组合，分别替换模板中的相应内容，即可生成用例集。由于该方法不可能自动了解代码所要实现的功能逻辑，所以不会验证“预期输出”，而是通过 try…catch 来观察是否会引发代码的异常、崩溃和超时等具有边界特征的错误。