● 桩函数的考虑

　　单元测试是不依赖其他模块的测试。但是实际代码中存在对其他模块函数的调用。为了消除这种依赖关系，就需要编写桩函数来替代对外部模块函数的调用。

　　为了清晰起见，我们的桩函数集中在一个文件中。

　　桩函数只是一个实现，至于原形定义，还是要引用其他模块的头文件，这样可以跟踪其他模块函数接口最新的改动。

　　● 单元测试工程的规划

　　一个清晰合理的单元测试工程规划是必要的，这样有利于对象的查找和维护。

　　以DBS模块的单元测试为例，我们的工程结构如下图所示。

　　1.3.4 测试效果的可验证

　　如何来量化单元测试的效果？

　　覆盖率是一个最直观的指标。我们采用了Rational公司的Pure Coverage工具来获取覆盖率。这也是公司推荐的一个简单易上手的工具。我们要求测试覆盖率达到90%以上。

　　2、自动测试

　　2.1 每日构造

　　每日构造是公司推行的一个最佳实践。它有一下一些功能：

　　● 开发人员及时把最新代码放入代码库，及时check out和check in，避免积累大量代码

　　● 及时进行模块间的整合，及时发现问题

　　● 对部分功能进行测试，无需等待

　　● 使用测试用例工具，对功能进行完整和重复的检验

　　● 记录所有程序问题

　　● 实现解决Bug的自动流程

　　● 提高正式版本提交的质量和速度

　　● XXXX在软件上开始推行每日构造。

　　2.2 冒烟测试

　　如果在每日构造的同时进行“冒烟测试”，能最早发现版本的问题。“冒烟测试”是微软提出的名词。其

　　对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。“冒烟测试“的执行者是版本编译人员。

　　ZXWR-RNS网管项目已有用Robot在网管产品进行冒烟测试的实践。但是对于前台软件，公司内部尚未有这方面的尝试。

　　2.3 自动测试

　　基于前期模块的单元测试工作，一个自然的想法就是在每日构造的框架上运行模块的单元测试代码，实现前台软件的每日自动化测试。这是比“冒烟测试”更全面，更彻底的一个测试。

　　2.3.1 单板软件

　　模块1

　　模块2

　　模块n

　　模拟测试工具

　　XXXX软件的架构