1、1JAVA 单元测试指引21.背景系统的规模及复杂度与时间及业务的拓展成正比。随着系统的规模不断变大，各子系统内的业务逻辑的新增，系统的代码总数也在不断的增加。部分业务在时间的推移上会发生变化引起系统在代码层面上的重构，系统代码在软件工程的生命周期中不断的迭代和变化。代码的新增以及重构都需要通过严格测试才能部署上线，公司目前对于上线功能采取的多数是黑盒测试，并未使用白盒测试对研发人员编写的代码进行更高的覆盖测试。而研发人员平时在功能开发完成后进行自测的时候使用的方式也因为个人喜好或各种原因没有形成统一。因此，系统若能在编译、部署、上线的时候能够对所有功能都进行尽可能全面的白盒测试将会有助于降低
2、系统在升级过程中的故障率，提高系统升级的速度。若能够通过更全面的测试发现代码中的隐藏缺陷，便能提升代码的健壮性，使系统在长期运行中发生更少的问题。2.需求研发人员在功能开发结束之后应当同时提交该功能的单元测试用例代码，并且该单元测试用例代码需要满足以下几点需求：2.1. 功能覆盖1) 每个单元测试代码中需要覆盖该功能的所有输入和输出，并对输出进行校验。2) 最终目标每个系统的所有测试用例代码需要覆盖系统的所有功能。 （存量系统在后续分阶段补充）32.2. 测试颗粒化1) 单元测试用例只测试小颗粒的功能。2) 一个单元测试用例只涉及到一个被测模块，避免牵扯到太多的模块。2.3. 测试自动化1)
3、单元测试的输入，输出以及校验全部自动化，不需要人工干预。2) 系统编译的时候需要自动将所有单元测试执行一次，任意单元测试不通过不允予通过发布。2.4. 持续维护1) 新添加的功能和模块需要添加相对应的单元测试用例。2) 重构或业务逻辑变更涉及到的功能和模块代码变化需要更新相对应的单元测试用例。3.方案基于公司在 JAVA 语言方面多数系统是采用 Maven 进行构建的现状以及 Maven 在系统构建的优势，故采用 Maven 进行系统构建+Junit 进行用例测试的方案实现。研发人员可以借助 Cobertura 对自己编写的测试用例进行代码覆盖分析，以便对测试代码进行调整和优化。3.1. Ma
4、ven1) Maven 不仅仅能构建项目，同时还是一个依赖管理工具，一个项目管理工具，提供中央仓库帮助我们自动下载构件，也允许我们上传自己开发的 jar 包供各系统使用，这4些都是自动化的非常方便。2) Maven 提供的免费中央仓库涵盖了非常非常多的开源库，能满足绝大多数系统的使用需求。3) Maven 对于目录结构有要求，约定优于配置，项目间切换就省去了学习成本。4) Maven 项目对单元测试支持很友好，约定的 test 目录用来编写单元测试代码， maven在进行系统编译的时候自动执行 test 目录里测试用例，一旦出现用例不通过 maven 自动打包发布。5) Maven 构建的系统
5、默认集成了 Junit 单元测试工具。3.2. Junit1) 简单易用的单元测试工具，通过断言校验期望值与实际值的差异。2) 支持图形交互，测试结果简洁明了。3) 提供异常堆栈方便跟踪错误代码。3.3. JaCoCo1) 简介JaCoCo 是一个开源的覆盖率工具( 官网地址： http:/www.eclemma.org/JaCoCo/ )，它针对的开发语言是 java，其使用方法很灵活，可以嵌入到 Ant、Maven 中；可以作为Eclipse 插件，可以使用其 JavaAgent 技术监控 Java 程序等等。2) 覆盖率概况5标示绿色的为行覆盖充分，标红色的为未覆盖的行，黄色菱形的为分支
6、部分覆盖，绿色菱形为分支完全覆盖。3) JaCoCo 的使用方式： Apache Ant 方式Task coverage、 Task agent、Task dump、Task merge、Task report、Task instrument 命令行方式使用方式说明：主要放在 JAVA_OPTS 中，比如：由 AgentOptions 的 getVMArgument 方法加载，各参数入 AgentOptions 的对应参数，为后续操作做为输入。系统在 jvm 停止的时候会 dump 覆盖率信息。 Apache Maven 方式（1 ）项目已 jar 包方式打包，引入 junit 和 jacoc
7、o。（2 ） Build 时执行 instrument、report、check。（3 ）覆盖率生成到 target/jacoco.exec64.测试覆盖4.1. 代码覆盖度单元测试中对每个被测逻辑体内的代码覆盖有以下几种方法，其覆盖的程度按照顺序递增。这里借助一个示例对覆盖方法做一个简单的说明，供各位进行参考。假定被测逻辑入下图（长方形内为代码语句）：4.1.1. 语句覆盖语句覆盖是最起码的结构覆盖要求，语句覆盖要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。对应的用例如下：74.1.2. 分支（判定）覆盖它要求设计足够多的测试用例，使得程序中每个判定至少有一次为真值，有一次为假
8、值，即：程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。对应的用例如下：4.1.3. 条件覆盖条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。对应的测试用例如下：4.1.4. 分支（判定）-条件覆盖判定-条件覆盖就是设计足够的测试用例，得使判断中每个条件的所有可能取值至少执行一次，同时每个判断本身所有可能结果也至少执行一次。对应的测试用例如下：84.1.5. 条件组合覆盖要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。满足“ 条件组合覆盖”的测试用例是一定满足“判定覆盖” 、 “条件
9、覆盖”和“判定/条件覆盖”的。对应的测试用例如下：4.1.6. 路径覆盖路径覆盖的含义是，选取足够多的测试数据，使程序的每条可能路径都至少执行一次（如果程序图中有环，则要求每个环至少经过一次） 。对应的测试用例如下：94.2. 原则由于根据程序的逻辑复杂程度以及程序设计上的差异性，某些代码想要完成特定的测试覆盖几乎是无法完成的，所以原则上不要求所有测试用例都能完成最高的代码覆盖度。因此在条件允许的情况，尽量完成更高的测试覆盖度，最低要求是语句覆盖。5.建议执行规范考虑到规范的的复杂度与实施效果不成正比的关系，在单元测试方案的规范中只取最核心的几项进行规范化以便降低实施的难度的同时提高交付的系统
10、的质量。5.1. 提交 test 测试包Maven 项目在 main 目录同级下默认了一个 test 包用于存放测试代码以及测试用配置文件，maven 项目所编写的所有测试用代码和配置文件必须提交到 SVN。5.2. 每个模块或类提交对应的测试类每个模块或服务类有对应同名的测试类。测试类中每个方法只进行一项最简单的单元测试，并且测试的方法必须有含义且与测试的逻辑相符合。5.3. 测试用例至少达到语句覆盖编写测试代码的研发人员需要使用 Cobertura 或其他工具自检提交的单元测试代码，最低要求测试的覆盖率达到语句覆盖级别。5.4. 系统编译时需要执行所有测试类编译机进行系统编译打包的时候需要执行 test 包底下的所有测试用例，必须所有测试用例都通过才允许打包部署。106.实施6.1. 新项目新项目采用 maven 构建，并且系统在生命周期内按照规范持续交付产出。6.2. 旧项目6.2.1. Maven 项目逐步补充提交模块和服务类的单元测试用例，新增功能同时产出测试用例代码。6.2.2. 非 maven 项目添加 test 测试包，逐步补充提交模块和服务类的单元测试用例，新增功能同时产出测试用例代码。Ant 编译打包时需要将 test 包下的所有单元测试执行一次，全部通过方可打包部署。
