步骤(2)
测试单元E，在调用E 单元的D 单元处使用一个测试驱动，再加上已测试过的单元H、I 和J。
步骤(3)
测试单元D，在调用D 单元的A 单元处使用一个测试驱动，再加上已测试过的单元E、F、G
、H、I 和J。(如图3.1 所示)
步骤(4)
测试单元A，使用已测试过的单元B、C、D、E、F、G、H、I 和J。
2. 优点
和自上而下法一样，自下而上单元测试法提供了一种比软件集成阶段更早的单元集成。自下
而上单元测试同样也是真正意义上的单元测试和软件集成策略的结合。因为不需要测试桩，
所以所有的测试用例都由测试驱动控制。这样就使得低层次单元附近的单元测试相对简单些
。(但是，高层次单元的测试可能会变得很复杂。)在使用自下而上法测试时，测试用例的
编写可能只需要功能性的设计信息，不需要结构化的设计信息(尽管结构化设计信息可能有
利于实现测试的全覆盖)。所以当详细的设计文档缺乏结构化的细节时，自下而上的单元测
试就变得十分有用处。自下而上单元测试法提供了一种低层次功能性的集成，而较高层次的
功能随着单元测试过程的进行按照单元层次关系逐层增加。这就使得自下而上单元测试很容
易地与测试对象相兼容。
3. 缺点
随着测试逐层推进，自下而上单元测试变得越来越复杂，随之而来的是开发和维护的成本越
来越高昂，同样要实现好的结构覆盖也变得越来越困难。低层单元的变化经常影响其上层单
元的测试。例如：想象一下H 单元发生变化的情况。很明显，对H 单元的测试不得不发生变
化和重新进行。另外，对于A、D 和E 单元的测试来说，因为它们共同使用了已测试过的H
单元，所以它们的测试也不得不重做。作为H 单元发生变化的后果，这些测试本身可能也要
进行改变，即使单元A、D 和E 实际上并没有发生变化。这就导致了当变化发生时，产生了
文章来源于领测软件测试网 https://www.ltesting.net/
