Cunit是一种针对于C语言代码的单元测试框架，具有以下优点：

　　–提供很多实用的接口函数（比如：各种断言、信息汇总、打印等）

　　–简单、安全、方便

　　–可添加任意多个测试单元

　　–逐步添加，汇总成套，全面回归测试

　　–完全免费

　　测试框架选定以后，在组内进行了相应的培训，使得每个人的认识达到相同的水平，尽可能保证以后测试风格的一致。

　　1.3.2 测试方案和测试规程

　　单元测试是一个系统的工作，在进行之前需要一个总体的规划。这个工作在单元测试方案中得到体现；测试规程是对测试方案的细化，是单元测试的指导。测试规程可以在notes的测试管理平台中录入。

　　1.3.3 自动化测试的考虑

　　一个单元测试是由许多测试用例构成的，要实现可回归，自动化的测试，每个测试用例都应该可以按照一定的顺序连续的执行。要达到这个目标，就要求对整个单元测试做一个很好的规划。以数据库模块为例，我们做了如下的规划：

　　● 数据环境的建立

　　数据库的测试依赖于一套数据表。单元测试一开始就需要在表中插入数据，以建立后续测试用例依赖的数据环境

　　● 测试粒度合理的划分

　　我们把被测对象分为表方法、查询接口和修改接口。

　　注：测试用例套（TestSuite）是Cunit的一个概念，用于封装测试用例套或者测试用例（TestCase）

　　● 在某种粒度上面保证数据环境的松耦合

　　所有的测试用例基于数据环境编写，数据环境对于数据库的单元测试是及其重要的。每个测试用例从前一个用例继承数据环境，又将本测试用例修改后的数据环境移交给下一个测试用例。从这个过程可以看出，数据环境在测试用例间是紧耦合的。如果测试用例一多，数据环境就会变得难以控制，用例的编写将变得非常麻烦。尤其是多人分工合作的情况下，简直变成了不可能的任务。

　　幸好我们有测试套！

　　以表方法的测试套为例，在第二级粒度上，一个套就是一张表所有表方法测试用例的集合。这个套包含的测试用例大致在4、5个左右。我们的策略是：二级粒度测试套内部的测试用例紧耦合数据环境，而二级粒度套之间的数据环境为松耦合。这通过在每个二级粒度套内加入一个数据环境恢复用例来实现。

　　这样一来，我们可以按照二级粒度的测试套来分工编写测试代码。