学习单元测试,你必须要懂得的基础理论

1.定义

• 1.1 单元测试是编写测试代码，用来检测特定的、明确的、细颗粒的功能
• 1.2 单元测试并不一定保证程序功能正确性，更不保证整体业务正确性

2.编写目的

• 2.1 为了达到 尽早发现问题 和 尽量小的影响范围 以及 暴露错误
• 2.2 提升代码质量，督促开发人员写出更加易于测试和维护的代码
• 2.3 减少维护成本保证功能实现的长期稳定
• 2.4 降低重构难度
• 2.5 提升代码信心
• 2.6 提升bug修复速度
• 2.7 减少集成测试和回归测试成本
• 2.8 通过单元测试快速熟悉代码，提升开发团队内部的协作效率

3.单元测试度量

• 3.1 执行的测试用例数量

完善的测试用例往往能提高单元测试的效果，但并不能以此作为单元测试好坏的依据。相应的复杂臃肿的测试用例并不能证明此次测试效果优秀，简陋的测试用例却能直接表明测试工作的欠缺

• 3.2 单元测试bug数

并不建议以此作为度量单元测试效果，纯粹的bug数纬度会引起团队内部的过度竞争和信息封锁。因为测试模块本身的难易和不稳定性，导致测试不同模块产生的bug也不同，难以甄别其有效性

• 3.3 百分比通过率

测试人员可能会专注于执行更容易通过的测试，从而提高通过率，亦或者团队可以将一个长时间的测试分解成许多小的测试，人为地提高百分比的通过率，百分比通过率的测试效果易于操纵

• 3.4 代码覆盖率

代码覆盖是另一个常用的度量指标，代码覆盖率 ＝ 代码的覆盖程度,测试覆盖率仅仅能够告诉团队什么没有被测试，根本就回答不了软件是否经过了有效测试

• 3.5 语句覆盖

语句覆盖(StatementCoverage)：又称行覆盖(LineCoverage)，段覆盖(SegmentCoverage)，基本块覆盖(BasicBlockCoverage)，这是最常用也是最常见的一种覆盖方式，就是度量被测代码中每个可执行语句是否被执行到

• 3.6 判定覆盖

判定覆盖(DecisionCoverage)：又称分支覆盖(BranchCoverage)，所有边界覆盖(All-EdgesCoverage)，基本路径覆盖(BasicPathCoverage)，判定路径覆盖(Decision-Decision-Path)。它度量程序中每一个判定的分支是否都被测试到了

• 3.7 条件覆盖
• 3.8 路径覆盖

路径覆盖(PathCoverage)：又称断言覆盖(PredicateCoverage)。它度量了是否函数的每一个分支都被执行了，测试路径随着分支的数量指数级别增加.对于比较简单的小程序来说，实现路径覆盖是可能的，但是如果程序中出现了多个判断和多个循环，可能的路径数目将会急剧增长，以致实现路径覆盖是几乎不可能的

• 3.9 循环覆盖

它度量是否对循环体执行了零次，一次和多余一次循环

4.测试要求

• 4.1 【强制】在开发中，自己开发的新模块，只有在通过单元测试之后才能提交Git 库，防止未经测试的代码更改流入到生产环节中（代码审核）
• 4.2 【强制】单元测试结果必须自动化，必须使用assert，杜绝System.out来进行人肉验证
• 4.3 【强制】项目启动或者maven编译时必须处理测试断言中未通过案例
• 4.4 【强制】对于模块类或者方法的修改必须同步修改单元测试
• 4.5 【强制】单元测试单测粒度至多是类级别，一般是方法级别ui service util等
• 4.6 【强制】核心业务、核心应用、核心模块的增量代码确保单元测试覆盖并通过
• 4.7 【强制】单元测试代码必须写在如下工程目录：src/java/test，不允许写在业务代码目录下
• 4.8 【强制】单元测试作为一种质量保障手段，不建议项目发布后补充单元测试用例，建议在项目提测前完成单元测试
• 4.9 【强制】安全接口测试：校验安全性的功能 100%
• 4.10 【强制】控制层接口测试：保证对外接口的访问连通性 100%

5.代码覆盖率

• 5.1 【强制】语句覆盖率：> 80% （核心模块100%）

计算标准：方法覆盖行/方法行

• 5.2 【推荐】参数值覆盖率：>50%

计算标准：方法传参 a，b 对a或者b其中一个参数做边界值测试等，则异常值测试率为50% 覆盖参数/总参数

• 5.3 【强制】判定覆盖：>50%

计算标准： if switch 的判定条件true false case等是否都测试到，对方法中出现的if-else做统计 覆盖的if-else代码块/总if-else代码块 覆盖的if-else数/总if-else数

• 5.4 【强制】条件覆盖：>50%

计算标准： if(a|b) a、b条件是否都测试到 ，如果a b只测试了一个则为50%，三目运算等计算同理 覆盖的表达书/总表达式

• 5.5 【强制】循环覆盖：while、递归等循环覆盖100%

计算标准： 代码中出现while、递归的方法，则该while 递归的代码必须做到 行覆盖、判定覆盖、条件覆盖 100%

• 5.6 路径覆盖: >40%

计算标准： 覆盖的执行路径/总执行路径 路径的覆盖计算过于复杂，暂时不强制要求

6.基本原则

• 6.1 AIR原则
  • A: Automatic 自动化
  • I: Independent 相互独立
  • R: Repeatable 可重复执行
• 6.2 BCDE原则
  • B: Border
    • 边界值测试：包括循环、 特殊取
    • 特殊取特殊时间点、数据顺序
    • 初始值：是否存在初始值（null）
    • 变量是否溢出（期望异常或拒绝服务）：最小值-1，最大值+1
    • 参数边界：最小值，最大值，无穷大
    • 字符串：字符串长度等
    • 集合：大小边界
    • 查询接口返回列表：查询返回结果集长度判定100%
  • C: Correct
    • 正确的输入，并得到预期结果
  • D: Design
    • 设计文档相结合，来编写单元测试
  • E: Error
    • 强制错误信息输入（如：非法数据、异常流程业务允许等），强制错误信息输入（如：非法数据、异常 流程业务允许等），并得到预期结果
• 6.3 推荐
  • 数据库相关的查询，更新，删除等操作，不能假设数据库里的数据是存在的，或者直接操作数据库把数据插入进去，请使用程序插入或者导入数据的方式来准备数据
  • 对于不可测的代码建议做必要的重构，使代码变得可测，避免为了达到测试要求而书写不规范测试代码
  • 在解决方案评审阶段，开发人员需要和测试人员一起确定单元测试范围，单元测试最好覆盖所有测试用例
  • 多层条件语句建议使用卫语句、策略模式、状态模式重构

7.使用涉及范围

ctl  service util等，不需要测试dao层

8.提交测试报告

测试报告只能导出需要测试的文件并打包上传到需求单补丁单中（不允许打全量）

压缩包名：实际表单标题