3、测试驱动设计
站在整个项目的角度组织，读取预定的测试用例，通过程序控制调用被测模块完成对模块功能的测试，并组织输出结果。
驱动作为测试的大框架，要尽量模拟被测模块运行环境，比如被测模块是控制台下的，那么驱动就要按控制台的模式设计。
基于被测模块分两个层次（文件和函数），且具备扩展性，这里的驱动设计也需要分为两个层次，模型如下：
便于驱动维护、扩展及团队协作，测试驱动的命名及布局都很重要，下面以函数的方式说明：
第一层次文件命名要和被测项目相关，比如文件命名为：ipld_test。第一层次的测试驱动命名要以项目+模块的方式，主入口格局如下：
| void main() { Iniall（）； test_Xld_lb(); // test＋项目＋模块,实现链表模块测试 test_gm(); 。。。。。。。 扩充测试模块入口 Doallresult（）； } |
二级测试文件按项目+模块的方式命名，比如链表测试文件命名为：ipld_lb_test，第二层次的测试驱动名称应该以项目+模块+函数的方式命名，格局如下：
| void test_Xld_lb () { Inilball（）； test_lb_add();// test＋项目＋模块+函数,实现lb_add函数测试 test_lb_del(); 。。。。。。。 扩充测试函数入口 Dolbresult（）； } |
4、桩函数设计
满足被测模块正常运行的支撑，对一个项目来说，桩可以是多个被测模块公用的，或者是某个特定模块根据自身需求使用的，且称为公共桩和专用桩。
在团队协作的测试项目中，项目经理要负责公共桩的使用一致性，比如桩设计的格式，声明及实现的位置等，并且要公布给所有组内成员供大家重用。至于专用桩，则有某个被测模块具体的负责人自己安排即可。
5、测试结果处理
驱动通过调配测试用例控制被测模块运行后，其结果是可预期的，测试结果是预期结果和实际结果分析对比后的体现。
在测试项目中，一般设计为每个小的被测模块输出自己的结果文件，这样可以使负责各项测试任务的负责人在工作中不相互干扰，输出的结果文件命名也要有固定的规则，比如按被测模块+resule的方式命名，便于最终项目测试结果汇总分析和评审。
另外驱动要提供写结果文件的结果函数供项目组成员重用，以便于维护，提高测试效率。
