软件测试 第6章 单元测试

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

6.1 单元测试的目标与内容
单元测试的内容
单元测试的内容是对单元的功能、性能、接口、 局部数据结构、独立路径、错误处理、边界条件 和内存使用情况进行测试。 对软件单元接口的测试通常是先于其他内容 的测试进行的。
6.1 单元测试的目标与内容
(1)接口测试 对接口的测试通常包括以下内容 ● 调用、被调用的实形参 ● 全局变量的使用 ● 输入/输出语句和文件的使用 ● 缓存区的使用
6.3 单元测试的策略
4.路径覆盖 路径覆盖是指测试用例中执行到的路径数量占被测试模块 所有可能的执行路径的比率。在路径覆盖中,我们只考虑 所有可能的执行路径,对于不可能执行的路径,我们是不 需要考虑的。而且对于一些大型程序,其包含的路径总量 是非常庞大的,如果要把所有路径都找出来去覆盖也是不 现实的。因此我们可借助以下一些方法来寻找程序中的路 径。
6.3 单元测试的策略
6.3.3 单元测试的自动化意义 单元测试要求设置实际而有效的测试套件,借助自动化 测试工具来帮助开发者自动搭建测试框架,自动生成桩函 数和测试用例,这能在一定程度上减轻开发者的工作。 单元测试通常将静态分析与动态测试相结合,首先利 用自动化测试工具或人脑来完成代码的静态分析或代码审 查,然后再采用动态测试方法进行补充性测试。
6.2 单元测试环境
桩模块的使用条件如下。 (1)被测试模块必须要调用桩模块; (2)必须能够正确接收来自被测试模块传递的各 项参数; (3)桩模块要能够对接收到的参数的正确性进行 判断; (4)桩模块对外的接口定义必须要符合被测试模 块调用的说明; (5)桩模块必须要向被测试模块返回一个结果。
6.2 单元测试环境
6.3 单元测试的策略
6.3.2 单元测试的覆盖率 1.语句覆盖 语句覆盖指的是代码中所有的语句都至少执行一遍,用 于检查测试用例是否有遗漏。原则上讲,单元测试中的语 句覆盖率必须达到100%,尤其是对一些对质量要求较高 的软件,如电信设备软件、航天软件、医用设备软件等, 就要求软件中的所有语句都必须执行到;对质量要求不高 的软件,根据实际项目情况,语句覆盖率也应达到90%以 上,否则单元测试的效果会大打折扣。
6.1 单元测试的目标与内容
(5)错误处理测试 主要检查软件单元对执行过程中发生的错误是否进行了有 效的处理。如果出现以下情况,说明错误处理存在缺陷。
● ● ● ● ● ● ● ●
对执行中发生的意外情况没有进行处理或处理不当; 对错误条件的判定不当; 对错误发生的描述难以理解; 对联机条件处理不正确; 错误提示与实际错误不匹配; 对错误的处理意见对用户没有帮助; 对错误的描述信息不足以确定产生错误的位置或原因; 在对错误进行处理前,系统已经对错误进行了干预。
• 例:找出程序流图中所有LCSAJ和LCSAJ路径 LCSAJ(5个): (1)int k=0,j=0; if ((x>3)&&(z<10)) (2)k=x*y-1; j=sqrt(k); if ((x==4)||(y>5)) (3)if ((x==4)||(y>5)) (4)j=x*y+10; j=j%3; (5)j=j%3; LCSAJ路径(4条): (1)-(2)-(4) (1)-(2)-(5) (1)-(3)-(4) (1)-(3)-(5)
5.函数覆盖
函数覆盖主要是评估在进行测试时函数的执行比 率,防止遗漏对某些单元的测试。
6.Z路径覆盖
Z路径覆盖是路径覆盖的一个变种,对路径进行了 简化,主要是针对循环而言的,按Z路径覆盖的观 点,一个循环被看成最多只有两条路径。
6.3 单元测试的策略
7.ESTCA覆盖 ESTCA覆盖是K.A.Foster受硬件领域测试方法的启发而 提出的一种经验测试覆盖准则,其最核心的部分是一套错 误敏感测试用例分析规则ESTCA(Error Sensitive Test Cases Analysis)。 规则1:对于A rel B(rel可以是<、= 或 >)型的分支谓 词,应适当选择A与B的值,使测试执行到该分支语句时, A < B、A = B、A > B的情况分别出现一次。 这条规则可以有效地检测逻辑符号是否写错,比如将大于 号“>”错写成小于号“<”.
6.1 单元测试的目标与内容
(6)功能测试 功能测试要求对设计文档中罗列的软件单元的功能进行逐 项测试。 (7)性能测试 按照设计文档的要求对软件单元的性能(如精度、时间、 容量等)进行测试。 (8)内存使用测试
主要检查内存的使用情况,重点检查动态申请内存是否 存在错误(包括指针使用越界,对空指针赋值,内存泄漏 等)。
本章内容提要?单元测试的目标与内容?单元测试的环境?单元测试的策略?单元测试的过程61单元测试的目标与内容单元测试的目标是检查每个模块是否正确地实现了设计说明中的功能性能接口和其他设计约束要求单元测试的目标是检查每个模块是否正确地实现了设计说明中的功能性能接口和其他设计约束要求确保每个单元都被正确地编码确保每个单元都被正确地编码
6.3 单元测试的策略
2.判断覆盖 判断覆盖是指对被测试模块中的每一个判断要分别取真和 假各一次进行测试。判断覆盖是单元测试中很常用的一类 覆盖,利用判断覆盖可以检查测试用例的设计是否完整, 判断覆盖的标准一般都要达到。
3.条件覆盖
条件覆盖是指程序中每个判断中的每个条件的所有可能的 取值的全部组合情况至少都执行一次,是一种比判断覆盖 更严格的覆盖。
6.3 单元测试的策略
(1)单个判断语句的路径计算:路径有两条,一条 是判断条件为真,另一条是判断条件为假。 (2)单个循环语句中的路径计算:简化循环 ① 当循环中条件一定会满足 ② 当循环条件不一定满足 ③ 当循环过程中有可能中断时的情况
(3)有嵌套判断或循环时的路径计算
6.3 单元测试的策略
6.3 单元测试的策略
8.线形代码序列与跳转(LCSAJ)覆盖 LCSAJ覆盖(Linear Code Sequence and Jump Coverage)是Woodward等人提出来的一套覆盖率准则, 实际上可看做是路径覆盖的一个变型。 一个LCSAJ其实是一组顺序执行的代码,它以控制流 跳转作为其结束点。它的起点是由程序本身决定。起点可 以是程序第一行(入口)或转移语句的入口点,也可以是 控制流可跳转的点。一个LCSAJ可能结束于程序的出口, 也可能结束于一个导致控制流跳转的点。
6.2 单元测试环境
6.2.1 驱动模块和桩模块的定义
Test
A
运行BLeabharlann CD驱动程序
调用
E
F
G
被测模块B
测试结果
桩程序 桩程序
6.2 单元测试环境
6.2.2 驱动模块和桩模块的使用条件 驱动模块的使用条件如下。 (1)必须要驱动被测试模块执行; (2)能正确接收要传递给被测试模块的各项参数; (3)能够对接收到的参数的正确性进行判断; (4)能够将接收到的数据传递给被测模块; (5)必须接收到被测试模块的执行结果,并对结果 的正确性进行判断; (6)能将判断结果作为用例执行结果输出测试报告
6.3 单元测试的策略
规则2:对于A rell C(rell可以是<或>,A是变量,C是 常量)型的分支谓词,当rell为“<”时,应适当地选取A的 值,使得A = C - M。 同理当rell为“>”时,应适当地 选择A,使A = C + M。 这条规则主要用于检查程序中的差1型的错误。 规则3:对外部输入的变量赋值,使其在每一个测试用例 中均有不同的值与符号,并与同一组测试用例中其他变量 的值与符号不一致。 这条规则主要用于检测变量赋值错误的情况,比如将一个 变量的值错误地赋给另外一个变量,能有效地发现软件变 量初始化时的错误。
6.3 单元测试的策略
如果有几个LCSAJ首尾相接,且第一个LCSAJ起点 为程序起点,最后一个LCSAJ终点为程序终点,这 些LCSAJ串就组成了程序的一条路径(LCSAJ路 径)。一条LCSAJ路径可能是由2个、3个或多个 LCSAJ组成。
6.3 单元测试的策略
LCSAJ覆盖准则是一个分层的覆盖准则,具体介绍如下: 第一层:语句覆盖。 第二层:分支覆盖。 第三层:LCSAJ覆盖。即程序中的每一个LCSAJ至少都 在测试中经历过一次。 第四层:两两LCSAJ覆盖。程序中每两个首尾相连的 LCSAJ组合起来在测试中都要经历一次。 ...... 第n层:每n个首尾相连的LCSAJ组合在测试中都经历一 次
单元测试工具列表
JUnit介绍
• JUnit()是开源测 试框架体系xUnit的一个实例,可以方便 地组织和运行Java程序的单元测试
微软VSTS的单元测试
• Visual Studio Team System(VSTS)是一套工 具集,全面整合了软件设计、开发、测试、部署和 人员协作工具,其开发版提供了静态分析、代码剖 析、代码涵盖以及其它单元测试所需的功能特性。
• •
程序段如下: void DoWork(int x,int y,int z) { int k=0,j=0; if((x>3)&&(z<10)) { k=x*y-1; //语句块1 j=sqrt(k); } if((x= =4)||(y>5)) { j=x*y+10; //语句块2 } j=j%3; //语句块3 }
6.2.3 驱动模块和桩模块的设计
图6-1 模块实例结构图
图6-2 驱动模块与桩模块示例图
决定测试顺序的基本原则有: (1)尽早测试关键的模块。
(2)尽早测试包含输入/输出操作的模块。
6.3 单元测试的策略
6.3.1 静态与动态结合的测试
单元测试是一种静态测试与动态测试相 互配合的白盒测试其中用到了代码规则检查、 代码人工审查、静态分析与动态测试等技术 手段。
6.1 单元测试的目标与内容
(2)局部数据结构测试 测试单元内部数据内容、格式及相互关系以及 它们的完整性。设计测试用例以检查以下错误: ● 数据类型说明不正确或不一致; ● 检测是否存在变量名拼写错误的情况; ● 是否存在未赋值的默认值; ● 是否存在指针越界访问; ● 是否存在上溢、下溢或地址访问错误; ● 检查全局数据对软件单元的影响。
第六章 单元测试
单元测试的对象是软件设计中的最 小单位—模块。
从传统制造业得到什么启发?
本章内容提要
• • • •
单元测试的目标与内容 单元测试的环境 单元测试的策略 单元测试的过程
6.1 单元测试的目标与内容
单元测试的目标是检查每个模块是否正确地实现了设计说 明中的功能、性能、接口和其他设计约束要求,确保每个 单元都被正确地编码。 单元测试需要达到以下一些具体目标: ●信息能否正确地流入和流出单元; ●单元工作过程中,其内部数据能否保持完整性,包括内 部数据的形式、内容及相互关系不发生错误,全局变量在 单元中的处理和影响; ●控制数据处理的边界能否正确工作; ●单元的运行能否做到满足特定的逻辑覆盖; ●对于单元中发生的错误,其出错处理措施是否有效。

创建单元测试项目。 设置项目引用。 添加适当的测试类(一个或多个)。 生成主干的单元测试框架(Unit Test Framework)类和属性
创建单个测试方法。
创建适合特定接口的逻辑
商业单元测试工具
• C/C++语言的单元测试工具以商业工具为主,例 如Parasoft C++、PR QA•C/C++、 CompuWare DevPartner for Visual C++ BoundsChecker Suite、Panorama C++等 • 内存资源泄漏检查工具,如CompuWare BounceChecker, IBM Rational PurifyPlus 等 • 代码覆盖率检查工具,如CompuWare TrueCoverage, IBM Rational PureCoverage,TeleLogic Logiscope等。 • 代码性能检查工具,如Logiscope和 Macabe等
6.1 单元测试的目标与内容
(3)独立路径测试
至少包括一条新的处理语句或一个新的条件的程序 路径叫独立路径。在程序流图中,独立路径至少包含 一条其他独立路径中没有的边。基本路径是通过对程 序流图中的环路复杂度进行分析而导出的基本的、可 执行的独立路径集合。应该设定适当的测试用例对软 件单元中的独立路径进行测试,尤其是对独立路径中 的基本路径进行测试。
6.1 单元测试的目标与内容
(4)边界条件测试 边界条件测试检查软件单元在边界处的工作是否正 常,主要检查以下情况。 ● 检查n重循环的第0次。第1次和第n次是否有错; ● 检查n维数组的第1个和第n个元素是否有错; ● 在运算或判断中的最大取值与最小取值是否有错; ● 数据流、控制流或判断条件中刚好小于、等于、大 于比较值时是否有错。
相关文档
最新文档