单元测试介绍
单元测试(Unit Test, UT)/模块测试,是针对程序模块(软件设计的最小单位)来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中,一个单元就是单个程序、函数、过程等;对于面向对象编程,最小单元就是方法,包括基类(超类)、抽象类、或者派生类(子类)中的方法。
单元测试可以看作是编码工作的一部分,是由程序员自己来完成,最终受益者是程序员自己。程序员有责任编写功能代码,同时也有责任为自己的代码编写单元测试。执行单元测试,就是为了证明这段代码的行为和我们期望的一致。
单元测试能帮助开发人员更高效的发现问题,保证代码健壮,打算能源测试在集成测试之前做,并且每次修改代码后也需要跑单元测试,保证修改代码对其他逻辑无影响。
单元测试的重要性:
- 高效、低成本
- 保证质量
- 促进代码优化
单元测试原则-FIRST原则
- fast快速:测试的运行速度将直接决定自动化的反馈速度,速度越快,越能提早发现问题;省去不必要浪费的时间,提高工作效率。
- isolated独立:每一个测试用例需要保证完全独立运行,互不依赖,这样才能保证测试运行不被干扰,从而能够并行运行甚至分布式运行,使得测试运行更加fast。
- repeatable可重复:每一个测试用例在运行条件不变的情况下,无论重复运行多少次,运行结果必须完全一致。
- self-validating自验证:测试用例必须能够自动告知(断言)运行结果,而不依赖人工判断结果正确还是错误。
- timely及时:编写自动化测试是一种好的习惯,为了保证能够及时得到反馈,必须及时编写自动化测试而不拖延,一旦拖延,就很难补回来。
软件测试基础
什么是测试
测试是通过实验方法,获得产品知识,以进行产品评估的过程。实验方法包括一定程度的:提问、学习、建模、观察和推论。
测试是一个包含计划、准备、和测量活动的过程。其目的时确认被测系统的特性,并指出需求和实现之间的差异。
测试的目标是减少风险差距。差距越大,测试越困难。
软件测试的目标(ISTQB):
- 预防缺陷
- 发现缺陷
- 为决策者提供信息
- 消减风险
- 评估产品质量
- 验证需求实现
- 确认达成客户期望
- 建立质量信心
软件测试的目标(ISO29119):
- 提供风险信息
- 提供质量信息
- 评估缺陷修复
- 评估实现变更
- 评估需求实现
- 评估客户期望
华为测试的目标:
- 需求验证:发现缺陷、评估缺陷修复、评估实现变更、验证需求实现
- 评估质量:消减风险、确认达成客户期望、评估产品质量
- 提升质量:预防缺陷、建立质量信心
- 提供信心:为决策者提供信息
测试原则
ISTQB(国际测试资质认证委员会)提出,所有测试的指导仿真,测试的7条基本原则:
- 测试可以显示缺陷defect的存在,但不能证明系统不存在缺陷
- 穷尽测试是不可能的
- 测试尽早介入
- 缺陷具有集群性
- 杀虫剂悖论
- 测试活动依赖于测试背景,测试背景决定测试活动
- “Absence of errors”谬误,系统发布取决于是否满足客户需求,而不是是否还有缺陷
测试模型
测试的基本模型为T-IBO。
测试的依据包括业务需求、合同标准、法律标准和行业标准。
在计算、软件工程和软件测试中,test oracle是一种决定一项测试是否通过的判断机制。test oracle的使用会要求将被测试系统的实际输出与我们所期望的输出进行比较,从而判断是否有差异。如果有差异,可能就存在缺陷。
测试不仅仅局限于软件程序的测试,测试活动贯穿于软件开发过程的整个周期中。因此,需求分析、概要设计、详细设计以及编码各阶段所得到的交付件,包括设计文档、源代码、应用程序乃至随软件版本发布的资料、license、证书,都是测试的对象。
测试是研发团队所有人的职责,不只是测试人员的事。
测试越早开始,代价越低越好。在开发过程中越晚修正缺陷,代价就会越高。
何时停止测试,需要从多个维度进行综合评估:
- 当达到了必要的信心级别,风险可以接受的时候
- 当发现缺陷的代价高于缺陷发生引起的代价时
- 当达到测试完成标准(退出/成功标准)时
测试可以发生在产品生命周期的各个环节/活动的环境上:
- 在需求分析、系统设计评审/交流的时候
- 在开发人员本地的仿真环境
- 在分支/主干持续集成环境
- 在研发测试实验室
- 在用户beta环境
- 在正式的生产环境
测试的基本过程为:
- 计划:识别测试的任务;定义测试的目标;为实现测试目标和任务定义规格说明。
- 控制:通过对测试进展和测试计划之间的比较,报告测试的状态,包括与计划之间存在的误差,包括在必要的时候采取必要的措施来满足测试的任务和目标。
- 分析和设计:分析测试目标和形成测试设计;将测试条件转化为测试用例、测试件;测试环境的搭建。
- 执行和评估:将测试的执行结果和已经定义的测试目标进行比较,在各个测试级别上都需要进行评估。
- 结束:从完成的测试活动中收集资料,巩固测试经验、测试件、影响测试的因素和其他数据。
测试术语
bug:是指组件或系统中的缺陷,可能导致组件或系统无法执行其所需功能,而造成功能不正常、司机、数据丢失、非正常中断等现象。
error错误:人为错误,不仅指代码逻辑错误,包括产品生命周期中任何人可能的错误。
fault内部缺陷/故障:期望结果与实际结果的差异。
failure外部失效:是缺陷导致的后果,通常系统不能完成最初的功能、性能等。
verification验证:评估产品、服务或系统是否正确实现既定的需求、规格。
validation确认:保证产品、服务或系统满足客户和其他利益相关者的需求。
软件质量:反应实体满足明确和隐含的需求的能力的特征的总和。软件质量是产品、组织和体系或过程的一组固有特性,反映它们满足顾客和其他相关方面要求的程度。
人们通常把影响软件质量的特性称为软件质量属性,用质量模型来描述,并定义为分层模型,最基本的叫做基本质量特性,它可以由一些子质量特性定义和度量。
ISO25010产品质量属性:
- 功能适应性:完整性、正确性、适合性
- 性能效率:时间行为、资源利用、容量/规格
- 兼容性:共存、互操作
- 易用性:可识别性、易学性、易操作性、误操作保护、ui美观度、可接入性
- 可靠性:成熟度、可使用性、容错性、可恢复性
- 安全:保密性、完整性、不可抵赖性、可追溯性、真实性
- 可维护性:模块化、重用度、可分析性、可修改性、可测试性
- 可移植性:适应性、可安装性、可替换性
测试分类
围绕测试的目标,人们开发了多种的测试活动与技术:
- 按是否运行程序划分
- 静态测试
- 动态测试
- 按阶段划分
- 单元测试
- 集成测试
- 系统测试
- 验收测试
- 按测试用例的测试设计方法划分
- 白盒测试
- 黑盒测试
- 按测试针对的质量目标划分
- 功能测试
- 适用性测试
- 性能测试
- 安全测试
- 可靠性测试
测试流程
阶段测试活动:
- 开发者测试:UT->IT/MST->BBIT
- 系统集成与验证:SDV->SIT->SVT
- 客户化测试:比拼测试->准入测试->客户验收测试
关键测试交付:
- 测试策略
- 测试分析:测试需求
- 测试设计:测试方案、测试用例
- 测试实现:测试用例、测试脚本、测试工具
- 测试执行:用例手工执行、用例自动化执行
- 测试评估:测试评估、测试报告、产品缺陷
测试设计技术
黑盒测试
等价类EP(Equivalence Partitioning)
等价类划分法是一种最基础的黑盒测试用例设计方法。它不考虑程序内部结构,唯一依据是软件需求规格说明书。等价类是输入条件的一个子集,该子集种的数据对于揭示程序种的错误是等价的。从每一个子集种选取具有代表性的数据生成测试用例。
有效等价类:指对于系统的规格来说是合理的,有效输入数据构成的集合。
无效等价类:指对于系统的规格来说是不合理或无意义的输入(即不正确的输入值)。
简单等价类划分的一般规则如下:
- 输入条件是布尔量
- 按照数值集合划分
- 按照区间划分
- 按照数值划分
边界值BVA(Boundary Value Analysis)
边界值分析是一种常用的软件测试技术,旨在通过对输入参数边界值的测试,来发现程序边界条件下可能存在的错误。
黑盒测试仅仅关注程序的输入,不考虑软件内部实现细节。
数据组合Combinatorial Test
数据组合将被测系统输入参数的取值进行组合,来生成测试用例。它可以覆盖任意n个因素所有取值组合,理论上可以发现由n个因素共同作用引发的缺陷。
数据组合测试设计技术针对系统的需求进行分析,识别出测试因子及其可能取值,采用数据组合覆盖技术生成测试数据组合,最后生成测试用例。
EC(Each Choice)组合:所有参数(因子)的可能取值至少被一个测试用例覆盖。
BC(Base Choice)组合:以测试因子的基本组合为基础,每次修改一个因子的取值,直到该因子的所有取值被覆盖。
N-wise组合:从多个测试因子中取n个因子进行组合,不考虑组合的顺序,当n=2时是pairwise组合,n为测试因子个数时为全组合。
- Pairwise组合:只考虑两个因子之间的组合,可以有效地发现因子的交互作用。
- 全组合:考虑所有因子之间的所有组合,测试覆盖率最高,但测试用例数量也最多。
- n-wise组合:介于pairwise和全组合之间,可以通过调整n值来平衡测试覆盖率和测试用例数量。
数据组合优化策略:
- 无效值:针对选择因子中的无效值,一般不进行组合。
- 约束条件:明确定义约束关系,并利用组合测试用具生成有效的测试用例集。
- 复合组合策略:为了降低测试用例数量,提高测试效率。
判定表DTT
判定表是一种充分考虑被测系统输入因子组合、约束,以及输入和输出之间因果关系的测试用例设计方法,特别适用于输入条件与输出结果之间存在明确因果关系的系统。
判定表可以与因果图结合,分析所有输入组合和它们对应的输出。对于简单的系统也可以直接适用判定表进行设计。分析步骤如下:
- 分析需求
- 定义条件与动作
- 列出条件项
- 生成判定表
- 简化判定表
判定点DPT
判定点逻辑覆盖通过对系统内部逻辑结构的深入分析,确保每个判定点及其所有可能条件都被测试覆盖。它与其他黑盒测试方法相比,更关注实现细节和业务逻辑,是一种偏白盒的测试分析方法。
- 判定decision:在程序执行过程中,根据条件判断结果选择不同的执行路径的分支点。
- 条件condition:判定点中包含一个或多个逻辑表达式,这些表达式通过逻辑运算(与、或、非)组合而成,最终结果为真或假。
- 逻辑覆盖:通过设计测试用例,使得流程中的每个判定点的所有可能结果都被执行到,以及每个条件的所有可能取值都被覆盖到。
处理周期PCT
路径覆盖:软件系统功能的业务逻辑可以适用流程图进行描述,系统的业务逻辑流程图往往包含一条或多条业务路径,路径覆盖的对象就是这些路径的组合。
处理周期测试设计技术:是一种针对系统业务进行测试的方法,它利用系统的业务逻辑流程图,并结合路径组合技术来生成测试用例。步骤如下:
- 针对被测对象分析,采用结构化的流程图描述其系统功能流程。
- 适用路径覆盖技术识别测试条件(即路径组合)。
- 创建测试用例。
状态转换测试STT
N-switch覆盖是指对被状态图中的所有n+1次连续状态转换的序列的覆盖。 通过对进行被测系统分析,得到系统业务逻辑的状态迁移图,n-switch覆盖的对象就是状态迁移图中的状态转换序列。
白盒测试
白盒测试是根据被测对象的结构设计测试用例的一种方法。这里的结构包括:
- 代码的结构(控制流图)
- 数据的结构
- 模块间相互调用的结构
- 业务流程的结构
语句覆盖:要求每条可执行语句至少执行一次。
判定覆盖:也叫分支覆盖,每个判断的真值和假值至少执行一次。
条件覆盖:要求程序中的每个条件的真值和假值至少执行一次。
判定-条件覆盖:要求每个判定的真值和假值至少执行一次,并且每个条件的真值和假值也至少执行一次。
条件组合覆盖:也叫多重条件覆盖,每个判定的条件取值组合至少执行一次。
MC/DC(Modified Condition/Decision Coverage)修正条件/判定覆盖,是一种严格的逻辑覆盖准则。它要求:
- 每个条件在判定中至少被赋值为真和假一次
- 每个判定的每个结果至少被触发一次
- 每个条件必须能够独立影响判定的输出
路径覆盖:覆盖程序中所有可能的路径。路径是指程序从入口到所有出口的执行路径。