单元测试过程
定义：单元测试是对软件基础组成单元进行的测试
时机：一般在代码完成后由开发人员完成，QA人员辅助
对象：类、模块、组件、单元
单元测试
- 单元测试的依据是软件的详细设计描述、源程序清单、编码标准等。
- 单元测试一般应该由编程人员完成，有时测试人员也加入进来，但编程人员扔会起到主要作用。
- 多个被测试模块之间的单元测试可同时进行，以提高单元测试效率。
- 单元测试是对软件组成的基本单元测试。
- 在传统的结构化编程语言如c语言中，单元一般是模块，也就是函数或子过程。
- 在象c++中，单元是类和类的方法
- 在Ada语言中，单元可为独立的过程、函数或Ada包
- 在第四代语言（4GL）中，单元对应为一个菜单或显示界面。
单元测试的目的
- 验证代码是否达到详细设计的预期要求（概要设计->集成测试）
- 发现代码中不符合编码规范的地方
- 准确定位发现的错误，以便排除错误
单元测试的优点
- 单元测试在编码过程中（在所有测试前），若发现一个错误，不论是从做回归测试的角度，还是对错误原因理解的深刻性的角度，修复错误的成本远小于集成测试阶段，更小于系统测试阶段（效益更优）
- 在编码过程中考虑单元测试的问题，有助于编程人员养成更良好的编程习惯（规范），提高源代码质量
单元测试的步骤
实施应遵循一定的步骤。
- 计划单元测试
- 设计单元测试
- 实现单元测试
- 执行单元测试
- 结果分析并提交测试报告
单元测试环境构成
单元测试中，单元测试一般为编码步骤的附属部分，模块不是独立的程序，自己不能运行，要靠其他部分来驱动，要为每个单元模块开发来两个软件：
- 驱动模块（Driver）:调用模块的运行
- 桩模块（Stub）:测试接口
驱动一般少于桩，尽量避免开发桩
若采用自底向上的方式开发，底层的单元先开发并测试，则避免了底层桩模块的开发。
如何构建单元测试的环境
- 构造最小运行调度系统，即构造被测单元的驱动模块
- 模拟被测单元的接口，即构造桩模块
- 模拟相应测试集中的测试数据
单元测试的内容
- 模块接口
- 局部数据结构测试
- 路径测试
- 错误处理测试
- 边界测试
模块接口测试
- 调用所测试模块的输入参数与模块的形式参数在个数、属性、顺序上是否匹配
- 所测试模块调用子模块时，它输入子模块的参数和子模块的形式参数在个数、属性、顺序上是否匹配
- 是否修改了只做输入用的形式参数
- 输出给标准函数的参数在个数上、属性上、顺序上是否匹配
- 全局变量的定义在各模块中是否一致
- 限制是否通过形式参数来传送
局部数据结构测试
- 检查不正确或不一致的数据类型说明；
- 使用尚未赋值或尚未初始化的变量；
- 错误的初始值或错误的默认值；
- 变量名拼写错误或书写错误；
- 不一致的数据类型。
路径测试
1. 常见的不正确的计算有：
- 运算的优先次序不正确或误解了运算的优先次序；
- 运算的方式错误（运算的对象彼此在类型上不相容）；
- 算法错误；
- 初始化不正确；
- 运算精度不够；
- 表达式的符号表示不正确等。
2. 常见的比较和控制流错误有：
- 不同数据类型的比较；
- 不正确的逻辑运算符或优先次序；
- 因浮点运算精度问题而造成的两值比较不等；
- 关系表达式中不正确的变量和比较符；
- “差1错”，即不正确地多循环或少循环一次；
- 错误的或不可能的循环终止条件；
- 当遇到发散的迭代时不能终止循环；
- 不适当地修改了循环变量等。
错误处理测试（容错）
- 出错的描述难以理解；
- 出错的描述不足以对错误定位和确定出错的原因；显示的错误与实际的错误不符；
- 对错误条件的处理不正确；在对错误进行处理之前，错误条件已经引起系统的干预；
- 如果出错情况不予考虑，那么检查恢复正常后模块可否正常工作。
边界测试
- 在n次循环的第0次、1次、n次是否有错误；
- 运算或判断中取最大最小值时是否有错误；
- 数据流、控制流中刚好等于、大于、小于确定的比较值时是否出现错误。
单元测试类型
- 逻辑单元测试；
- 集成单元测试；
- 功能单元测试。
单元测试应试应从各个层次来对单元内部算法、外部功能实现等进行检验，包括对程序代码的评审和通过运行单元程序来验证其功能特性等内容。一般单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。
进行单元测试时，常用的方法是采用白盒测试，辅之以黑盒测试。
根据测试对象的其内部结构的逻辑关系、测试的方法，按照由小到大、由单一到组合、又简单到复杂，单元测试可以逻辑单元测试、集成单元测试和功能单元测试。
断言
定义：
简单的方法调用，判断一个语句、一个函数或对象的一个方法所产生的结果是否符合你期望的那个结集（为真）。
时机：
- 用错误处理代码来处理预期会发生的状况，用断言来处理绝不应该发生的状
- 用断言注解并验前（置），条件和后（置）条件赶链的花构，应该先使用断管再处理错要
应用场景：
- 在在功能代码开发阶段，可以逐步添加断言测试是否获取自己想要的数据结果
- 写单元测试时，可用到断言，主要目的：测试这个功能片段的代码能否返回预期的结果
- 自己提供接口供他人使用时，可先断言使用者传递过来的参数是否符合要求，如果不符合要求，将以AssertionError 的方式告知使用者。
- assertion（断言）是软件开发中一种常用的调试方式，很多开发语言中都支持这种机制。
- assertion 就是在程序中的一条语句，它对一个布尔表达式进行检查，必须保证这个表达式的值为true；如果为false，则说明程序已经处于不正确的状态，系统将给出警告或退出。
- assertion 用于保证程序最基本、关键的正确性。
- assertion 通常在开发和测试时开启。为了提高性能，在软件发布后，assertion通常是关闭的。
-![在这里插入图片描述]()
单元测试的目的
- 验证代码能否达到详细设计的预期要求。
- 发现代码中不符合编码规范的地方。口准确定位发现的错误，以便排除错误。
单元测试的作用
- 编写单元测试可以帮助开发人员书写高质量的代码。
- 编写单元测试可以使开发人员更有信心重构应用程序，去拥抱变化。