系统单元测试规范-4：JAVA单元测试指引

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