790 likes | 882 Views
8. 第 八 章. 软件测试. 8.1 软件测试的基本概念. 一、软件测试的目的和重要性 因为开发工作的前期不可避免地会引入错误,测试的 目的是为了发现和改正错误 ,这对于某些涉及人的生命安全或重要的军事、经济目标的项目显得尤其重要。. 1963年美国飞往火星的火箭爆炸,原因是 FORTRAN 程序: DO 5 I=1,3 误写为: DO 5 I=1. 3 损失1000万美元。 1967 年苏联“联盟一号”宇宙飞船返回时因忽略一个小数点,在进入大气层时打不开降落伞而烧毁。. 二、软件测试的 特点. 2、不能进行“穷举”测试
E N D
8 第 八章 软件测试
8.1软件测试的基本概念 • 一、软件测试的目的和重要性 • 因为开发工作的前期不可避免地会引入错误,测试的目的是为了发现和改正错误,这对于某些涉及人的生命安全或重要的军事、经济目标的项目显得尤其重要。 1963年美国飞往火星的火箭爆炸,原因是FORTRAN程序:DO 5 I=1,3 误写为:DO 5 I=1. 3 损失1000万美元。 1967年苏联“联盟一号”宇宙飞船返回时因忽略一个小数点,在进入大气层时打不开降落伞而烧毁。
二、软件测试的特点 2、不能进行“穷举”测试 只有将所有可能的情况都测试到,才有可能检查出所有的错误。但这是不可能的: 例:程序P有两个整型输入量 X、Y,输出量为Z,在32位机上运行。所有的测试数据组(Xi,Yi)的数目为: 22 = 2 1毫秒执行1次,共需5亿年。 32 32 64 X P Z Y • 1、软件测试的开销大 • 按照Boehm的统计,软件测试的开销大约占总成本的30%-50%。例如:APPOLLO登月计划,80%的经费用于软件测试。
二、软件测试的特点 — 结论 • 3、软件测试难度大 • 根据上述分析,既然不能进行“穷举”测试,又要查出尽可能多的错误,软件测试工作的难度大。只有选择 — “高效的测试用例” 什么是“高效的测试用例”? 如何选择“高效的测试用例”? 这就是本章讨论的主要问题!!!
三、软件测试的基本原则 • 3、充分注意测试中的群集现象。 1、尽量不由程序设计者进行测试。 2、关键是注重测试用例的选择。 输入数据的组成(输入数据、预期的输出结果) 既有合理输入数据,也有不合理的输入数据。 用例既能检查应完成的任务,也能够检查不应该完成的任务。 长期保存测试用例。
四、测试的基本步骤 模块测试 (单元测试) (组装测试) 整体测试 概要设计审查 功能测试 (有效性测试) 详细设计审查 { (确认测试) 系统测试 代码审查 验收测试 { 安装测试 预测试 测试
8.2 软件测试方法 • 软件测试方法分为两类:静态分析、动态测试 • 一、静态分析方法 指以人工的、非形式化的方法对程序进行分析和测试。 • 桌前检查 代码会审 步行检查 步行检查时,还常使用以下分析方法: ①调用图 从语义的角度考察程序的控制路线。 ② 数据流分析图 检查分析变量的定义和引用情况。
① 调用图 • 无论Y 为何值,都不能够调用子程序。 READY A N Y>0 B Y C X:=Y 即执行ABC后,是不可能执行路径CDE的。 Y X<0 D E N 调用子程序
② 数据流分析图 • 节点 —表示单个语句。 • 有向边 —表示控制结构。 • d — 定义 • r — 引用 • u — 未引用 1 2 3 4 5 6 R=0.5 W=1/S Y=A**W Y=E*W R:duuuuu S :uruuur Y:uuddru 只定义不用 未定义引用 连续定义 Z=X+Y C=Z*S
二、动态测试方法(1) • 通过选择适当的测试用例,执行程序。 • 常用的方法: • 1、白盒法 • 分析程序的内部逻辑结构,注意选择适当的覆盖标准,设计测试用例,对主要路径进行尽可能多的测试。 • 2、黑盒法 • 不考虑程序的内部结构与特性,只根据程序功能或程序的外部特性设计测试用例。
白盒法 • 白盒法又称为逻辑覆盖法,其测试用例选择,是按照不同覆盖标准确定的。 强 弱 语 句 覆 盖 判 定 覆 盖 条 件 覆 盖 判 定 条 件 覆 盖 条 件 组 合 覆 盖
白盒法常用的覆盖标准 • ① 语句覆盖: 选择足够的测试用例,使得程序中每个语句至少都能被执行一次。 • ② 判定覆盖: 执行足够的测试用例,使得程序中每个判定至少都获得一次“真”值和“假”值。 • ③ 条件覆盖:执行足够的测试用例,使得判定中的每个条件获得各种可能的结果。 • ④ 判定/条件覆盖: 执行足够的测试用例,使得判定中每个条件取到各种可能的值,并使每个判定取到各种可能的结果。 • ⑤ 条件组合覆盖: 执行足够的例子,使得每个判定中条件的各种可能组合都至少出现一次。
白盒法步骤: 逻辑结构 1)选择逻辑覆盖标准。 2)按照覆盖标准列出所有情况。 3)选择确定测试用例。 4)验证分析运行结果与预期结果。 • 例:用白盒法测试以下程序段: • Procedure(VAR A,B,X:REAL); • BEGIN • IF (A>1) AND (B=0) • THEN X:=X/A ; • IF (A=2) OR (X>1) • THEN X:=X+1 • END;
白盒法举例 Y A>1 AND B=0 N X:=X/A A=2 OR X>1 Y X:=X+1 N • Procedure (VAR A,B,X:REAL); • BEGIN • IF(A>1) AND (B=0) • THEN X:=X/A ; • IF (A=2) OR (X>1) • THEN X:=X+1 • END; 逻辑结构
1、语句覆盖 a • 使得程序中每个语句至少都能被执行一次。 c A>1 AND B=0 Y 满足语句覆盖的情况: 执行路径:ace N X:=X/A b 用例格式: [输入(A,B,X),输出(A,B,X)] Y e A=2 OR X>1 X:=X+1 d N 选择用例: [(2,0,4),(2,0,3)]
2、判定覆盖 a • 使得程序中每个判定至少为TRUE 或FALSE各一次。 c A>1 AND B=0 覆盖情况:应执行路径 ace ∧ abd 或: acd ∧ abe Y N X:=X/A b 选择用例(其一): ⑴ [(2,0,4),(2,0,3)] ace [(1,1,1),(1,1,1)] abd ⑵ [(2,1,1),(2,1,2)] abe [(3,0,3),(3,1,1)] acd e A=2 OR X>1 Y X:=X+1 N d
3、条件覆盖 • 使得判定中的每个条件获得各种可能的结果。 a 应满足以下覆盖情况: 判定一: A>1, A≤1, B=0, B≠0 判定二: A=2, A≠2, X>1, X≤1 c A>1 AND B=0 A>1 A≤1 B=0 B≠0 A≠2 Y X≤1 A=2 X>1 N X:=X/A b 选择用例: [(2,0,4),(2,0,3)] [(1,1,1),(1,1,1)] 2 0 4 e A=2 OR X>1 1 1 1 Y X:=X+1 N 注意:[(1,0,3),(1,0,4)] [(2,1,1),(2,1,2)] 满足条件覆盖,但不满足判断覆盖。 d
4、判定/条件覆盖 a • 同时满足判断覆盖和条件覆盖。 应满足以下覆盖情况: 条件: A>1, A≤1, B=0, B≠0 A=2, A≠2, X>1, X≤1 应执行路径 ace ∧ abd 或: acd ∧ abe c A>1 AND B=0 Y N X:=X/A b e A=2 OR X>1 Y 选择用例: [(2,0,4),(2,0,3)](ace) [(1,1,1),(1,1,1)] (abd) X:=X+1 N d
5、条件组合覆盖 • 使得每个判定中条件的各种可能组合都至少出现一次。 a Y Y c 满足以下覆盖情况: ① A>1, B =0 ② A>1, B≠0 ③ A≤1, B =0 ④ A≤1, B≠0 ⑤ A=2, X>1⑥ A=2, X≤1 ⑦ A≠2, X>1⑧ A≠2, X≤1 B=0 A>1 N N b X:=X/A Y A=2 e N Y X>1 选择用例: [(2,0,4),(2,0,3)] ① ⑤ [(2,1,1),(2,1,2)] ② ⑥ [(1,0,3),(1,0,4)] ③ ⑦ [(1,1,1),(1,1,1)] ④ ⑧ X:=X+1 N d 编译系统下的执行情况: 部分路径未被执行。
二、动态测试方法(2) • (2)黑盒法 • 不考虑程序的内部结构与特性,只根据程序功能或程序的外部特性设计测试用例。 等 价 分 类 法 边 值 分 析 法 错 误 推 测 法 因 果 图 法
1. 等价分类法 • 基本思想:根据程序的I/O特性,将程序的定义域划分为有限个等价区段 —“等价类”,从等价类中选择出的用例,具有“代表性”。 等价类分为: 有效等价类 — 对于程序的规格说明,是合理的、有意义的输入数据构成的集合。 无效等价类 —对于程序的规格说明,是不合理的、没有意义的输入数据构成的集合。
等价分类法步骤 等价分类法步骤 显然,关键是 如何划分等价类 ① 划分“等价类” • 应按照输入条件(如输入值的范围,值的个数,值的集合,输入条件必须如何)划分为有效等价类和无效等价类。 • 例如:每个学生可选修1-3门课程 • 可以划分一个有效等价类:选修1-3门课程。 • 可以划分两个无效等价类:未选修课,选修课超过3门。 • ② 选择测试用例 • A 为每个等价类编号; • B 使一个测试用例尽可能覆盖多个有效等价类 • C 特别要注意:一个测试用例只能覆盖一个无效等价类。
2. 边值分析法 • 基本思想: 选择等价类的边缘值作为测试用例,让每个等价类的边界都得到测试,选择测试用例既考虑输入亦考虑输出。 分析步骤: A 先划分等价类。 B 选择测试用例,测试等价类边界。 边界选择原则: A 按照输入值范围的边界。 B 按照输入/输出值个数的边界。 C 输出值域的边界。 D 输入/输出有序集的边界。
边值分析法举例 A 按照输入值范围的边界。 例如:输入值的范围是-1.0至1.0,则可选择用例: –1.0、1.0、-1.001、1.001。 B 按照输入/输出值个数的边界。 例如:输入文件可有1-255个记录,则 设计用例:文件的记录数为 0个、1个、255个、256个。 C 输出值域的边界。 例如:检索文献摘要,最多4篇。设计用例:可检索0篇、1篇、4篇,和5篇(错误)。 D 输入/输出有序集(如顺序文件、线性表)的边界。 应选择第一个元素和最后一个元素。
黑盒法应用实例 对FORTRAN编译系统中的DIMENSION语句进行测试。 语句格式为:DIMENSION ad[,ad] … ad为数组描述符, 形式为 n(d[,] …其中:n-数组名,字母打头的字母数字串,长6。 D为界偶(1-7个):[ld:]nd ld 和 nd 的值为1-65535, ld缺省为1。 40 个等价类
3.错误推测法 • 凭经验或直觉推测可能的错误,列出程序中可能有的错误和容易发生错误的特殊情况,选择测试用例。 4.因果图法 • 把输入条件视为“因”,把输出条件视为“果”,将黑盒看成是从因到果的网络图,采用逻辑图的形式来表达功能说明书中输入条件的各种组合与输出的关系。根据这种关系可选择高效的测试用例。 • 因果图是一种形式化语言,是一种组合逻辑 • 网络图。
4.因果图法(cause effcet graphicei) a b a b a d ∨ b a d ∧ b • ⑴ 因果图的基本符号 • 0 - 表示“不出现” 1 - 表示“出现” 恒等 若a为1,则b为1,否则b为0。 “非”函数 若a为1,则b为0,否则b为1。 “或”函数 若a或b为1,则d为1,否则d为0。 “与”函数 若a与b同为1,则d为1,否则d为0。
4.因果图法(cause effcet graphicei) • 对“与”、“或”函数的限制符号 a E E约束(异)— 排斥 即a、b不能同时为1。 I约束(或)— 包容 a、b、c不能同时为0。 O约束(唯一)—选一 a、b中仅有一个为1。 R约束(要求)—需要 a为1时,b必须为1 M约束(强制)—屏蔽 若a为1时,则b强制为1。 b a I b c a O b a R b a M b
⑵ 因果图法的步骤 • 分析规范,即将问题分为若干可工作的步骤。 • 标识出规范中的原因与结果。 • 原因—输入条件 • 结果—输出或系统变换 分析规范语义、内容,转换为因果图。 将因果图转换为有限项判断表。 将判断表的每一列,转换为一个测试用例。
⑶ 因果图法应用举例 • 规范:文件名第一列字符必须为A或B,第二列字 • 符必须为数字。满足则修改文件。第一字符不正 • 确发出信息X12,第二个字符不正确发出信息X13。 1.分析规范 原 因 结 果 1 — 第一列字符为A 50—修改文件 2 — 第一列字符为B 51—发信息X12 3 — 第二列字符为数字 52—发信息X13
2.画出因果图 1 51 发 X 12 E ∨ 11 2 ∧ 50 修改文件 3 52 发 X 13 • 中间结点 是导出结果的进一步原因。 11 考虑到原因1、2不可能同时为1,加上E约束。
3.将因果图转换为判断表 11 51 50 52
8.3 软件测试的步骤 单元 测试 设计信息 软件需求 系统其他元素 被测模块 单元 测试 集成 测试 确认 测试 系统 测试 已测试的模块 已确认的软件 可交付的软件 已集成的模块 被测模块 单元 测试 • 测试步骤及策略 • 所有测试过程都应采用综合测试策略;即先 • 作静态分析,再作动态测试。并事先制订测试计 • 划。测试过程通常可分4步进行:
一、模块测试(Module Testing) 也称单元测试(unit testing ) • 1.测试内容 模块接口测试 重要路径测试 I/O 参数值的个数、类型、次序、格式是否正确,I/O文件属性、操作是否正确等。 重要路径通常是指完成模块功能的主要路径,一般是控制结构。 模块 局部数据结构测试 边界条件测试 错误处理测试 数据说明是否正确、一致,变量及其初值定义是否正确等。 边界条件常包括循环边界,最大最小值、控制流中等于、大于、小于的比较值等。 检查“错误处理程序”本身的错误。
2.模块测试步骤 • 考虑到被测模块与其它模块的联系,因此测试时需要使用两类辅助模块来模拟其他模块。 • 驱动模块(driver)—模拟主程序功能,用于向被测模块传递数据,接收、打印从被测模块返回的数据。 驱动模块 • 桩模块(stub)—又称为假模块,用于模拟那些由被测模块所调用的下属模块功能。 被测模块 桩模块 桩模块 桩模块 • 一般,驱动模块比桩模块容易设计。但都是额外开销。测试方法以白盒法为主。
二、组装测试(Integration Testing) • 也称为联合测试或集成测试,重点测试模块的接口部分,需设计测试过程使用的驱动模块或桩模块。 • 1.组装测试的任务 • ①确定模块组装方案,将经过测试的模块组装为一个完整的系统。组装方案分为渐增式及非渐增式。 • ②测试方法以黑盒法为主,按照组装方案进行 • 测试。 问题:渐增式与非渐增式各有何优、缺点?为什么通常采用渐增式?
2.渐增式组装测试 • 渐增式是先进行模块测试,然后将这些模块逐步组装成较大的系统,每连接一个模块进行一次测试。两种方案: 自顶而下增值 自底而上增值 • 设计驱动模块或桩模块,对每一个新组装的子 • 系统进行测试,对发现问题较多的子系统或模 • 块应该用白盒法作回归测试。
自顶而下增值 M1 M1 程序模块示意图 M2 S1 S1 S1 M3 S2 S2 S2 M4 S3 S3 S3 M2 M3 M4 S4 M5 S4 S4 S5 S5 M6 S5 M5 M6 第一步,测试主控模块M1设计桩模块S1、S2、S3,模拟被M1调用的M2、M3、M4。 第二步,依次用M2、M3、M4替代桩模块S1、S2、S3,每替代一次进行一次测试。 第三步,对由主控模块M1和模块M2、M3、M4构成的子系统进行测试,设计桩模块S4、S5。 第四步,依次用模块M5和M6替代桩模块S4、S5,并同时进行新的测试。组装测试完毕。
自底而上增值 D6 D4 D4 D4 D2 D2 M1 D2 D5 D5 D5 M1 程序模块示意图 M2 D1 D1 D1 M3 M4 D3 D3 D3 M2 M3 M4 M5 M6 M5 M6 第一步,对最底层的模块M3、M5、M6进行测试,设计驱动模块D1、D2、D3来模拟调用。 第二步,用实际模块M2、M1和M4替换驱动模块D1、D2、D3。 第四步,把已测试的子系统按程序结构连接起来完成程序整体的组装测试。 第三步,设计驱动模块D4、D5 和D6模拟调用,分别对新子系统进行测试。
深度优先与宽度优先 • 无论是自顶而下增值还是自底而上增值,还可选择 • 深度优先或者宽度优先增值。 • 举例:按自顶而下增值法,写出下图中分别按照深度优先或者宽度优先增值的模块组装次序。 A C D B E G F I H J K L N M
问 题 (1)自顶而下增值与自底而上增值各有何优、缺点? (2)为什么在实际的组装测试中,都应该采用混合增值的方法? (3)请自己设计 2-3个混合增值的测试方法。
确定集成过程的原则 自顶而下增值 优点:能够尽早发现系统主控方面的问题。 缺点:无法验证桩模块是否完全模拟了下属模块的功能。 自底而上增值 优点:驱动模块较容易编写桩模块,能够尽早查出底层涉及较复杂的算法和实际的I/O模块中的错误。 缺点:最后才能发现系统主控方面的问题。 集成过程的原则 ① 尽早测试关键模块。 ② 尽早测试包含I/O的模块。
3.混合增值 • 常见的混合增值方案: • 衍变的自顶而下 • 先自底而上集成子系统,再自顶而下集成总系统。 • 自底而上—自顶而下增值 • 对含有读操作的子系统采用自底而上。 • 对含有写操作的子系统采用自顶而下。 • 回归测试 • 在回归测试中自底而上,对其余部分(引起是对修改过的子系统)采用自顶而下。
三、确认测试(validation testing) • 1.任务 • 又称为有效性测试或功能测试。其任务是验证系统的功能、性能等特性是否符合需求规格说明。 选择测试人员 有效性 测试 测试报告 选择测试用例 实际运行测试 专家 鉴定会 管理 机构 裁决 交用户 软件计划 运行维护 软件 配置 审查 用户文档 开发文档 软件配置 源程序文本 支持环境
2.确认测试步骤 • (1)有效性测试 • 制定测试计划,运用黑盒法,验证软件特性是否与需求符合。 • (2)软件配置复查 • 软件配置—指软件工程过程中所产生的所有信 • 息项:文档、报告、程序、表格、数据。随着软 • 件工程过程的进展软件配置项(SCI software • Configuration Item)快速增加和变化。应复查 • SCI是否齐全。
(3)测试和测试 • 测试 是在开发机构的监督下,由个别用户在确认测试阶段后期对软件进行测试,目的是评价软件的FLURPS(功能、局域化、可使用性、可靠性、性能和支持),注重界面和特色。 • 测试 由支持软件预发行的客户对FLURPS进行测试,主要目的是测试系统的可支持性。 • Function Testing 功能测试 • Local Area Testing 局域化测试 • Usability Testing 可使用性测试 • Regression Testing 回归测试 • Performance Testing 性能测试 • Supportability Testing 可支持性测试
四、系统测试(system testing ) • 将经过确认测试的软件,与计算机硬件、外设、 • 支持软件等一起,在实际运行环境下测试。 五、验收测试(acceptance testing) • 验收测试是以用户为主的测试。软件工程课程设计的验收测试,18周进行。 • 1.步骤: • (1)由课题组根据测试用例,自己演示系统所有功能。 • (2)由教师进行测试。
8.3.6 综合测试策略 软件测试是保证软件可靠性的主要手段,也是软件开发过程中最艰巨、最繁杂的任务。 软件测试方案是测试阶段的关键技术问题,基本目标是选择最少量的高效测试用例,从而尽可能多地发现软件中的问题。因此,无论哪一个测试阶段,都应该采用综合测试策略,才能够实现测试的目标。 一般都应该先进行静态测试,再考虑动态测试。 • 最后进行验收测试(Acceptance Testing),是以用户为主的测试,测试过程、方法和测试内容与系统测试基本相同。 • 有时也将验收测试与系统测试合二为一,此时,参加测试的人员最好包括:有经验的系统测试专家,用户代表,软件开发人员及QA(质量保证)人员也应参加。
8.4 面向对象的测试 强调需求或设计的测试,通常以两种方式进行: 在没有代码的情况下进行测试; 在有代码的情况下进行测试。 面向对象的测试,既要使用许多传统的成熟的软件测试方法和技术,也有其不同的特点;主要反映在测试对象和内容的不同。 传统的观点认为测试要在编码之后才进行,主要测试的对象是程序代码。 而面向对象的测试贯穿软件开发的全过程,是与开发过程密切相关,而又分离出来的过程。
8.4.1 面向对象测试的特点 1.强调需求或设计的测试,通常以两种方式进行: 在没有代码的情况下进行测试; 在有代码的情况下进行测试。 2.在传统测试方法的基础上,根据面向对象的主要特性,需要改变测试策略和方法。 例如: 封装—对数据的隐蔽,减少了对数据非法操作,可简化该类测试。 继承—提高了代码复用性,但错误也会以同样方式被复用。 多态性—提供强大的处理能力,但也增加测试的复杂性。