《第五章软件测试.ppt》由会员分享，可在线阅读，更多相关《第五章软件测试.ppt（75页珍藏版）》请在三一文库上搜索。
1、第五章 软件测试,文 档,5.1 基本概念,软件开发过程必须伴有质量保证活动。 软件测试是软件质量保证的关键元素，代表了规约、设计和编码的最终检查。 软件产品最大的成本是检测软件错误、修正软件错误的成本。 在整个软件开发中，测试工作量一般占30%40%，甚至50%。 在人命关天的软件(如飞机控制、核反应堆等）测试所花费的时间往往是其它软件工程活动时间之和的三到五倍,例:Windows95有1000万行代码 Windows2000有5000万行代码， 3000多个工程师，几百个小团队。 Exchange2000和 Windows2000开发人员结构,软件测试背景,软件是人编的所以不完美 实例:
2、1994-1995,迪斯尼的狮子王系统不支持问题 Intel的pentium处理器 1994年浮点除法缺陷 200年8月28日，1.13MHZ处理器一个可能导致运行程序被挂起的执行指令问题 1999年12月3日,美国航天局火星极地登陆飞船失踪 1991年爱国者导弹防御系统系统时钟错误积累造成跟踪系统失去精确度 千年虫,世界各地解决2000年错误超过数亿美元,软件测试的问题,软件缺陷是什么？ 谁执行测试？ 开发者？ 单独的测试人员？ 两方面人员？ 测试什么？ 每个部分都测试？ 测试软件中高风险部分？ 什么时候测试？ 怎样测试？ 测试应进行到什么程度？,软件缺陷是什么,描述软件失败的术语 缺点(d
3、efect) 谬误(fault) 问题(problt) 错误(error),异常(anomaly) 偏差(variance) 失败(failure) 缺陷(bug),难以说清的软件缺陷,古谚： “一片树叶飘落在森林中没有人听见， 谁能说它发出了声音？”,由于不能报告没有看见的问题，因此， 没有看见就不能说存在软件缺陷,“如果软件中的问题没有人发现，那么它算不算软件缺陷？”,只有看到了，才能断言软件缺陷，尚未发现的软件缺陷只能说是未知软件缺陷。,眼 见 为 实,三个盲人和一头大象：你能够为质量下定义吗？,质量管理领域权威人物J.M.Juran将质量定义为： “决定产品性能和满意程度的特征”, 测
4、试注重于产品的满意度。 测试应针对这样一种情况： 软件产品在一些特定的范围内不能满足客户的合理要求。 通过测试过程可以评定质量风险（可能的错误），了解被测试系统中存在的错误模式（观察到的错误症状）。,软件测试的目标,(1)预防错误: 几乎不可实现 (2)发现错误,5.1.1 测试的目的与地位 G.J.Myers在中认为: 1.测试是为了寻找错误而运行程序的过程。 2.一个好的测试用例是指很可能找到迄今为止尚未发现的错误的测试。 3.一个成功的测试是揭示了迄今为止尚未发现的错误的测试。,E.W.Dijkstra 指出: “程序测试能证明错误的存在,但不能证明错误不存在.” 测试的目的是发现程序中
5、的 错误，是为了证明程序有错, 而 不是证明程序无错.,把证明程序无错当作测试目的不仅是不正确的, 完全做不到的，而且对做好测试没有任何益处，甚至是十分有害的. 软件测试要设法使软件发生故障,暴露软件错误 测试的“成功”与“失败” 能够发现错误的测试是成功的 测试，否则是失败的测试。,“测试的目的是说明程序正确地执行它应有的功能” 这种说法正确吗？ 例：程序Triangle，输入三个整数，表示一个三角形的三个边长，该程序产生一个结果，指出该三角形是等边三角形、等腰三角形还是不等边三角形。 为说明其能正确执行它的功能，可使用“测试用例”(3,4,5),(5,5,6),(6,6,6), 程序都能给
6、出正确结果，是否就可认为程序是正确的？,测试设计中需要考虑的22种测试类型,黑盒测试 白盒测试 单元测试 累计综合测试 集成测试 功能测试 系统测试 端到端测试 健全测试 衰竭测试 接受测试,负载测试 强迫测试 性能测试 可用性测试 安装/卸载测试 恢复测试 兼容测试 安全测试 比较测试 Alpha测试 Beta测试,质量控制技术,质量控制活动分类,开发方法学,配置管理,验证技术,评 审,正确性验证,性能调试,组件测试,集成测试,系统测试,原子事务,模块冗余性,检 错,质量控制,避免错误,容 错,调 试,测 试,软件质量问题,以软件测试为中心的软件质量保障技术 软件 静态测试技术 质量 软件度
7、量技术 控制 动态测试技术 技术 配置管理技术 修改控制与管理技术 软件测试是保证软件质量,提高 软件可靠性的关键,5.1.2 测试原则 (1)所有的测试都应追溯到用户需求 最严重的错误(从用户角度)是那些导致软件无法满足需求的错误。 程序中的问题根源可能在开发前 期的各阶段解决、纠正错误也必须追 溯到前期工作。,测试与开发前期工作的关系,决定软件与系统的配合关系,需求分析,概要设计,详细设计,编 码,单元测试,集成测试,确认测试,系统测试,测试活动和相关工作产品,项目协议,对象设计,客户,开发人员,用户,集成策略,系统分解,功能性需求,非功能性需求,单元测试,集成测试,结构测试,功能测试,性
8、能测试,来自ODD,来自TP,来自SDD,来自RAD,来自RAD,用户手册,验收测试,安装测试,现场测试,日常操作,开发前期出现错误的扩展,计划,需求 分析,设 计,编 码,测 试,A,B,软件生存期各阶段间需保持的正确性,用户要求,用户: 我要什么?,运行结果,计算机: 程序运行得 到的结果,源程序,程序员: 我要让计算 机什么做?,设计说明书,设计员: 我要让软件 做什么?,需求说明书,分析员: 我可以提 供什么?,1,2,3,4,5,理解正确性 表达正确性,理解正确性 设计正确性 表达正确性,理解正确性 编码正确性,运行正确性 输入正确性,相符吗?,软件开发面临的实际问题,项目开发前 分
9、析员的理 解、设想,软件开发面临的实际问题,分析员 的描述,完成的设计,软件开发面临的实际问题,程序员做出的产品,软件开发面临的实际问题,现场的安装,软件开发面临的实际问题,用户原来的设想,软件开发面临的实际问题,测试原则 (2)概要设计时应完成测试计划， 详细的测试用例定义可在设计 模型确定后开始，所有测试可 在任何代码被产生之前进行计 划和设计。,软件测试不等于程序测试 软件测试应贯穿于软件定义与开发的整个期间； 据美国一家公司统计，查出的软件错误中，属于需求分析和软件设计的错误约占 64%，属于程序编写的错误仅占 36%。程序编写的许多错误是“先天的”。,测试阶段工作步骤 单元测试:检验
10、每个模块能否单独工作 集成测试:检验概要设计中模块接口设计问题 确认测试:以需求规格说明书为检验尺度 系统测试:综合检验 测试可视为分析、设计、编码三个阶 段的最终复审,以保证软件质量.,测试原则 (3)pareto原则：测试发现的错误中80%很 可能起源于20%的模块中。 应孤立这些疑点模块重点 测试。 (4)穷举测试是不可能的,测试原则,例:测试计算器程序 加法测试 1+0= 1+99999999999999999999999999999999= 2+0= 2+99999999999999999999999999999999= 9999999999999999999999999999999
11、9+99999999999999999999999999999999= 1.0+0.1= 1.0+0.2= 减法测试 乘法测试 除法测试 求平方根 百分数 倒数,测试原则 (5)应由独立的底三方来构造测试。 （开发和测试队伍分别建立） (6)测试用例应由输入数据和预期的输 出结果两部分组成. (7)兼顾合理的输入和不合理的输入数据 (8)程序修改后要回归测试 (9)应长期保留测试用例，直至系统废弃。,测试原则：软件测试是有风险的行为,数 量,遗漏软件 缺陷数目,测试费用,测试中,测试后,软件,测试工作量,每一个软件项目都有一个最优的测量量,最优测量量,5.1.3 可测试性 可测试软件的特征：
12、可操作性 可观察性 可控制性 可分解性 简单性 稳定性 易理解性,“好”测试的属性： 发现错误的可能性高 不冗余 在目的相似的测试中，应使用最可能找到错误的测试 每一个测试应独立执行,测试 (test) 调试 (debug),以已知条件开始, 使用预先定义的程序, 有预知的结果,以不可知内部条件开始,结果一般不可预见,有计划,被动的,由独立的测试组，在 不了解软件设计的条 件下完成,由程序作者进行,发现错误,找出错误位置，排除,测试与调试(排错),软件错误分类 功能错(需求分析错误) 软件结构错 数据错 编码错 软件集成错 测试定义与测试执行错误,5.1.4 测试用例设计 测试用的一组输入数据
13、。 选择测试用例是软件测试员最重要 的一项工作。,测试用例的属性: 属性 描述 name 测试用例的名称 location 可执行的完全路径名 input 输入数据或命令 oracle 期待测试结果 log 测试产生的输出,程序测试举例 例：程序 Triangle， 输入三个整数，表示一个 三角形的三个边长，该程序产生一个结果， 指出该三角形是等边三角形、等腰三角形还 是不等边三角形。,判断三角型的测试用例设计: 输入数据 预期结果 (1) 6;6;6 等边 (2) 8;8;4 等腰 (3) 4;5;6 一般 还应输入非法数据： 0; 7; 9 -7; 3; 5 a; 2; 7 等,5.1.5
14、 软件测试信息流,软件 配置,测试,测试 配置,测试 工具,结果 分析,排错,可靠性 分析,测试 结果,错误,预期 结果,出错率,改正 的软件,预测 的可 靠性,需求规格说明书 软件设计说明书 被测源程序,测试计划 测试用例 (测试数据) 测试驱动程序,测试活动和相关工作产品,项目协议,对象设计,客户,开发人员,用户,集成策略,系统分解,功能性需求,非功能性需求,单元测试,集成测试,结构测试,功能测试,性能测试,来自ODD,来自TP,来自SDD,来自RAD,来自RAD,用户手册,验收测试,安装测试,现场测试,日常操作,测试设计中需要考虑的22种测试类型,黑盒测试 白盒测试 单元测试 累计综合测
15、试 集成测试 功能测试 系统测试 端到端测试 健全测试 衰竭测试 接受测试,负载测试 强迫测试 性能测试 可用性测试 安装/卸载测试 恢复测试 兼容测试 安全测试 比较测试 Alpha测试 Beta测试,5.1.6 测试的方法与技术,软件测试的 策略和方法,静态 测试方法,动态 测试方法,人工测试方法,计算机辅助静 态分析方法,白盒测试方法,黑盒测试方法,静态测试：基本特征是在对软件进行 分析、检查和审阅，不实 际运行被测试的软件。 静态测试约可找出3070%的逻辑设计错误. 对需求规格说明书、软件设计说明书、源程序做检查和审阅，包括： 是否符合标准和规范； 通过结构分析、流图分析、符号执行指
16、出软件 缺陷；,动态测试：通过运行软件来检验软件 的动态行为和运行结果的 正确性 动态测试的两个基本要素： 被测试程序 测试数据（测试用例）,动态测试方法 (1)选取定义域有效值,或定义域外无效值. (2)对已选取值决定预期的结果 (3)用选取值执行程序 (4)执行结果与预期的结果相比,不吻和程序 有错.,动态黑盒测试 闭着眼睛测试软件,软件,输入,不深入代码细节的测试方法称为动态黑盒测试。 软件测试员充当客户来使用它。,输出,动态白盒测试 带上X光眼镜测试软件,?,3581322.293419985680302829734315,250*(1+0.015)*(1+0.015)360-1)/0
17、.015,250*(1+0.015)*(1+0.015)360-1)/0.015,假如知道一个盒子包含一台计算机,而另一个 盒子是人用纸笔计算,就会选择不同的测试用例,了解软件的运作方式会影响测试手段,5.2 两种类型的测试 5.2.1 黑盒测试 又称:功能测试 数据驱动测试 基于规格说明书的测试,5.2.2 白盒测试 又称:开盒测试 结构测试 玻璃盒测试 基于覆盖的测试. 根据被测程序的逻辑结构设计测试用例; 力求提高测试覆盖率;,黑盒测试与白盒测试比较 黑盒测试是从用户观点，按 规格说明书要求的输入数据与输 出数据的对应关系设计测试用例, 是根据程序外部特征进行测试。 白盒测试是根据程序内
18、部逻辑结构 进行测试。,黑盒测试与白盒测试能发现的错误,C,B,A,D,-只能用黑盒测试发现的错误,A,-只能用白盒测试发现的错误,-两种方法都能发现的错误,-两种方法都不能发现的错误,B,C,D,黑盒测试与白盒测试优缺点比较,黑盒测试 白盒测试,优 点,缺 点,性 质,适用于各阶段测试 从产品功能角度测试 容易入手生成测试数 据,可构成测试数据使特定程 序部分得到测试 有一定的充分性度量手段 可或较多工具支持,某些代码得不到测试 如果规格说明有误， 则无法发现 不易进行充分性测试,不易生成测试数据(通常) 无法对未实现规格说明的 部分进行测试 工作量大，通常只用于单 元测试，有应用局限,是一
19、种确认技术，回答 “我们在构造一个正确 的系统吗？”,是一种验证技术，回答 “我们在正确地构造一个系 统吗？”,5.2.3 穷举测试 例:输入 三条边长 可采用的测试用例数 (设字长16位) 执行时间: 设测试一次需1ms 共需一万年.,黑盒测试,穷举测试实例: 白盒测试 设程序含4个分支,循环次数 20,从A到B的可能路径 执行时间: 设测试一次需2ms 穷举测试需5亿年.,A,B,不论黑盒还是白盒测试都不能进行穷尽测试, 所以软件测试不可能发现程序中存在的所有错误, 因此需精心设计测试方案, 力争尽可能少的次数，测出尽可能多的错误.,5.3白盒测试的测试用例设计 5.3.1 逻辑覆盖法 (
20、1)语句覆盖 (2)判定覆盖 (3)条件覆盖 (4)判定/条件覆盖 (5)条件组合覆盖 (6)路径覆盖 (7)点覆盖 (8)边覆盖,例: PROCEDURE SAMPAL (A,B:REAL; VAR X:REAL); BEGIN IF (A1) AND (B=0) THEN X:=X/A IF (A=2) OR (X1) THEN X:=X+1 END;,开始,(A1) AND (B=0),(A=2) OR (X1),返回,X=X/A,X=X+1,F,F,T,T,a,b,d,c,e,(1)语句覆盖 使程序中每个语句至少执行一次,开始,(A1) AND (B=0),(A=2) OR (X1),
21、返回,X=X/A,X=X+1,F,F,T,T,a,b,d,c,e,只需设计一个测试用例: 输入数据：A=2， B=0， X=4 即达到了语句覆盖;,语句覆盖是 最弱的逻辑覆盖,开始,(A1) AND (B=0),(A=2) OR (X1),返回,X=X/A,X=X+1,F,F,T,T,a,b,d,c,e,只需设计一个测试用例: 输入数据：A=2，B=0，X=4 即达到了语句覆盖;,(2)判定覆盖(分支覆盖) 使每个判定的真假分支都至少执行一次,开始,(A1) AND (B=0),(A=2) OR (X1),返回,X=X/A,X=X+1,F,F,T,T,a,b,d,c,e,例:可设计两组测试用例
22、: A=3，B=0 ，X=3 可覆盖c、d分支 A=2，B=1 ，X=1 可覆盖b、e分支 两组测试用例可覆盖所有判定的真假分支 判定覆盖仍是弱的逻辑覆盖,(3)条件覆盖 使每个判定的每个条件的可能取值至少执行一次。,开始,(A1) AND (B=0),(A=2) OR (X1),返回,X=X/A,X=X+1,F,F,T,T,a,b,d,c,e,满足条件:T1,T1, T2,T2 T3,T3 T4,T4,第一判定表达式: 设条件 A1 取真 记为T1 假 T1 条件 B=1 取真 记为T2 假 T2 第二判定表达式: 设条件 A=2 取真 记为T3 假 T3 条件 X1 取真 记为T4 假 T
23、4,测试用例 通过 满足的 覆盖 A B X 路径 条件 分支 1 0 3 abe T1,T2,T3,T4 b,e 2 1 1 abe T1,T2,T3,T4 b,e 两个测试用例覆盖了四个条件八种可能取值。 未覆盖c、d分支，不满足判定覆盖的要求. 条件覆盖不一定包含判定覆盖 判定覆盖也不一定包含条件覆盖,(4)判定/条件覆盖 选取足够多的 测试用例，使判断 中的每个条件的所 有可能取值至少执 行一次，同时每个 判断本身的所有可 能判断结果至少执 行一次.,开始,(A1) AND (B=0),(A=2) OR (X1),返回,X=X/A,X=X+1,F,F,T,T,a,b,d,c,e,满足条
24、件:T1,T1, T2,T2 T3,T3 T4,T4,测试用例 通过 满足的条件 覆盖 A B X 路径 分支 2 0 4 ace T1,T2,T3,T4 c,e 2 1 1 abd T1,T2,T3,T4 b,d 能同时满足判定、条件两种覆盖标准的取值,测试用例 通过 满足的 覆盖 A B X 路径 条件 分支 2 0 3 ace T1,T2,T3,T4 c,e 2 1 1 abe T1,T2,T3,T4 b,e 1 0 3 abe T1,T2,T3,T4 b,e 1 1 1 abd T1,T2,T3,T4 b,d,(5)条件组合覆盖 所有可能的条件取值组合至少执行一次 A1, B=0 A1
25、, B0 A1, B=0 A1, B0 A=2, X1 A=2, X1 A2, X1 A2, X1,测试用例 通过 满足的 覆盖 A B X 路径 条件 分支 2 0 4 ace T1,T2,T3,T4 c,e 2 1 1 abe T1,T2,T3,T4 b,e 1 0 2 abd T1,T2,T3,T4 b,d 1 1 1 abd T1,T2,T3,T4 b,d,(6)路径覆盖 覆盖每一个可能的路径 测试用例 通过 满足的 覆盖 A B X 路径 条件 分支 1 1 1 abd T1,T2,T3,T4 b,d 1 1 2 abe T1,T2,T3,T4 b,e 3 0 1 acd T1,T2
26、,T3,T4 c,d 2 0 4 ace T1,T2,T3,T4 c,e,基本路径测试法 通过分析由控制构造的环路的复杂性，导出基本路径集合，从而设计测试用例，保证这些路径至少通过一次。 基本路径测试步骤： 导出程序流程图的拓扑结构-流图(控制流程图) 计算流图G的环路复杂性V(G) 确定只包含独立路径的基本路径集 设计测试用例,导出程序流程图的拓扑结构-流图,1,2,3,6,4,5,7,10,11,a,节点,边,R4,区域,1,2,3,4,5,8,7,6,9,11,8,9,R1,R2,R3,10,计算流图G的环路复杂度CC的不同方法 (1)CC=区域个数 = 4 (2)CC=边的条数-节点个数+2 = 11-2+2=4 (3)CC=判定节点个数+1 = 3+1=4 确定只包含独立路径的基本路径集 path1:1-11 path1:1-2-3-4-5-10-1-11 path1:1-2-3-6-8-9-10-1-11 path1:1-2-3-6-7-9-10-1-11 环路复杂度4是构成这个基本路径集的独立路径数 的上界，也是设计测试用例的数目 设计测试用例,保证基本路径集中每条路径的执行,一条新路径 必须包含一 条新边,