4. 测试覆盖
4.1. 代码覆盖度
单元测试中对每个被测逻辑体内的代码覆盖有以下几种方法，其覆盖的程度按照顺序递增。
这里借助一个示例对覆盖方法做一个简单的说明，供各位进行参考。 假定被测逻辑入下图（长方形内为代码语句）：
4.1.1. 语句覆盖
语句覆盖是最起码的结构覆盖要求，语句覆盖要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。
对应的用例如下：
6
4.1.2. 分支（判定）覆盖
它要求设计足够多的测试用例，使得程序中每个判定至少有一次为真值，有一次为假值，即：程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。
对应的用例如下：
4.1.3. 条件覆盖
条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。
对应的测试用例如下：
4.1.4. 分支（判定）-条件覆盖
判定-条件覆盖就是设计足够的测试用例，得使判断中每个条件的所有可能取值至少执行一次，同时每个判断本身所有可能结果也至少执行一次。
对应的测试用例如下：
7
4.1.5. 条件组合覆盖
要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。满足“条件组合覆盖”的测试用例是一定满足“判定覆盖”、“条件覆盖”和“判定/条件覆盖”的。
对应的测试用例如下：
4.1.6. 路径覆盖
路径覆盖的含义是，选取足够多的测试数据，使程序的每条可能路径都至少执行一次（如果程序图中有环，则要求每个环至少经过一次）。
对应的测试用例如下：
8
4.2. 原则
由于根据程序的逻辑复杂程度以及程序设计上的差异性，某些代码想要完成特定的测试覆盖几乎是无法完成的，所以原则上不要求所有测试用例都能完成最高的代码覆盖度。
因此在条件允许的情况，尽量完成更高的测试覆盖度，最低要求是语句覆盖。
5. 建议执行规范
考虑到规范的的复杂度与实施效果不成正比的关系，在单元测试方案的规范中只取最核心的几项进行规范化以便降低实施的难度的同时提高交付的系统的质量。
5.1. 提交test测试包
Maven项目在main目录同级下默认了一个test包用于存放测试代码以及测试用配置文件，maven项目所编写的所有测试用代码和配置文件必须提交到SVN。
5.2. 每个模块或类提交对应的测试类
每个模块或服务类有对应同名的测试类。测试类中每个方法只进行一项最简单的单元测试，并且测试的方法必须有含义且与测试的逻辑相符合。
5.3. 测试用例至少达到语句覆盖
编写测试代码的研发人员需要使用Cobertura或其他工具自检提交的单元测试代码，最低要求测试的覆盖率达到语句覆盖级别。
5.4. 系统编译时需要执行所有测试类
编译机进行系统编译打包的时候需要执行test包底下的所有测试用例，必须所有测试用例都通过才允许打包部署。
9
6. 实施
6.1. 新项目
新项目采用maven构建，并且系统在生命周期内按照规范持续交付产出。
6.2. 旧项目 6.2.1. Maven项目
逐步补充提交模块和服务类的单元测试用例，新增功能同时产出测试用例代码。
6.2.2. 非maven项目
添加test测试包，逐步补充提交模块和服务类的单元测试用例，新增功能同时产出测试用例代码。Ant编译打包时需要将test包下的所有单元测试执行一次，全部通过方可
打包部署。
10