《软件工程7_1(概论、白盒)》由会员分享,可在线阅读,更多相关《软件工程7_1(概论、白盒)(62页珍藏版)》请在金锄头文库上搜索。
1、第七章,软件测试,概论,在本章中,我们将研究: 1、错误类型和如何分类错误 2、 测试的目的 3、单元测试 4、 集成测试策略 5、测试计划 6、 何时停止测试 有许多种测试方法,这里将为你介绍几种测试方法,它们能够使你为用户发布一个高质量的系统。 在开发过程中怎样在需求和设计的复查中帮助我们探索错误。 但是测试是以发现错误为核心,有许多种方法使我们在测试上下的功夫更有效率更有效果。,概论,Jones广泛地研究了程序员的生产力,包括错误的查找和修正的本性。查阅了历史上一千万行的代码,他发现代码检查纠除了85%多的错误。 实际上,没有一个能够除去一半以上的错误。Jones调查了建议典型的准备时间
2、和会议时间。 表 典型的准备时间和会议时间(1991) 开发产品 准备时间 会议时间 需求文档 每小时25页 每小时12页 功能描述 每小时45页 每小时15页 逻辑描述 每小时50页 每小时20页 源代码 每小时150行代码 每小时75行代码 用户手册 每小时35页 每小时20页,概论,韦勒( 1993) 在公牛信息系统3 年检查数据。 来自几乎7,000 个检查会议的尺度包括大约11557 个错误信息和14677 页的设计文献。他发现小组的有效性和效率取决于他们对产品的熟悉: 越熟悉,越好。 另一方面,韦勒发现在一项12000 行C语言的工程上,需求和设计没被复查; 检查从代码开始。 比较
3、代码检查数据和测试数据,韦勒发现代码检查主要鉴定编码或者低水平设计错误。 测试 还要发现需求和结构的错误。因此,代码检查的结果没代表真实的系统质量。 表 发现活动中发现的错误(Jones 1991) 发现活动 每千行代码发现的错误 需求复查 2.5 设计复查 5.0 代码检查 10.0 集成测试 3.0 接受性测试 2.0,概论,Grady在惠普解释到,为代码检查做计划一般需要2个小时,接着30分钟的小组会议。然后个人准备2个小时发现错误和90分钟汇报错误。小组花费30分钟集体讨论错误的发现并推荐采取的措施。当错误修正后,代码检查会议的主持人再花费半个小时书写和发布摘要文档。 Jones总结了
4、他的工程信息的数据,画了一个不同的图,比较复查,检查和其他发现方法的不同。 代码检查善于发现代码错误,但是原型系统更容易鉴别需求的错误。 Fagan在IBM发布检查代码的方针后,许多其它的组织机构,包括惠普,ITT和AT&T都采纳了代码检测作为推荐或标准实施。,概论,假想你已经编完你的组件,自己检查完毕,小组复查完毕。下一步测试是,以更加结构化的方式详细审查确保它的正确性。 一个程序是正确的,当它正确实现设计中说明的功能和数据和它与其它组件正确接口。 一种研究程序的正确性方式是把代码看成语句的逻辑流。如果我们能够用正式的逻辑系统复写程序,就能测试语句的正确性。 公式证明技巧。按照一系列步骤转换
5、代码为逻辑副本,表达遵循数学逻辑的规则。,7.1 基本概念,软件产品最大的开发成本是检测软件错误、修正软件错误的成本。 在整个软件开发中: 测试工作量50%,软件质量问题,以软件测试为中心的软件质量保障技术 软件 静态测试技术 质量 动态测试技术 控制 配置管理技术 技术 修改控制与管理技术 软件测试是保证软件质量,提高 软件可靠性的关键,软件测试的目标,(1)预防错误: 几乎不可实现 (2)发现错误: 软件测试目的,找错,7.1.1 测试的目的与地位,G.J.Myers在中认为: “程序测试是为了发现错误而执行程序的过程.”,E.W.Dijkstra 指出: “程序测试能证明错误的存在,但不
6、能证明错误不存在.” 测试的目的是发现程序中的错误,是为了证明程序有错,而不是证明程序无错。 成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员的职责是设计这样的测试用例,它能有效地揭示潜伏在软件里的缺陷。 千万不要将“测试”与“演示”混为一谈。,把证明程序无错当作测试目的不仅是不正确的, 完全做不到的,而且对做好测试没有任何益处,甚至是十分有害的. 软件测试要设法使软件发生故障,暴露软件错误 测试的“成功”与“失败” 能够发现错误的测试是成功的测试, 否则是失败的测试。,“测试的目的是说明程序正确地执行它应有的功能”也是错误的. 例:程序Triangle,输入三个整数,表示一个三角形的三个
7、边长,该程序产生一个结果,指出该三角形是等边三角形、等腰三角形还是不等边三角形。 为说明其能正确执行它的功能,可使用“测试用例” (3,4,5),(5,5,6),(6,6,6), 程序都能给出正确结果,是否就可认为程序是正确的?,测试 (test) 调试 (debug),以已知条件开始, 使用预先定义的程序, 有预知的结果,以不可知内部条件开始,结果一般不可预见,有计划,被动的,由独立的测试组,在 不了解软件设计的条 件下完成,由程序作者进行,发现错误,找出错误位置,排除,测试与调试(排错),程序中的问题根源可能在开发前期的各阶段,解决、纠正错误也必须追溯到前期工作。,测试与开发前期工作的关系
8、,决定软件与系统的配合关系,需求分析,概要设计,详细设计,编 码,单元测试,集成测试,确认测试,系统测试,测试阶段工作步骤 单元测试: 检验每个模块能否单独 工作. 集成测试: 检验概要设计中模块接 口设计问题 系统测试: 结合系统硬软件综合检验 确认测试: 以需求规格说明书为检 验尺度 测试可视为分析、设计、编码三个阶段的最终复审,以保证软件质量.,开发前期出现错误的扩展,计划,需求 分析,设 计,编 码,测 试,A,A,B,软件生存期各阶段间需保持的正确性,用户要求,用户: 我要什么?,运行结果,计算机: 程序运行得 到的结果,源程序,程序员: 我要让计算 机什么做?,设计说明书,设计员:
9、 我要让软件 做什么?,需求说明书,分析员: 我可以提 供什么?,1,2,3,4,5,理解正确性 表达正确性,理解正确性 设计正确性 表达正确性,理解正确性 编码正确性,运行正确性 输入正确性,相符吗?,软件测试的对象 软件测试不等于程序测试 软件测试应贯穿于软件定义与开发的整个期间; 据美国一家公司统计,查出的软件错误中,属于需求分析和软件设计的错误约占 64%,属于程序编写的错误仅占 36%。程序编写的许多错误是“先天的”。,7.1.2 测试的基本原则 “测试用例”要求 测试用的一组输入数据、环境平台和运行条件。,测试的基本原则 (1)开发和测试队伍分别建立 (2)测试用例应由输入数据和预
10、期的输出结果两部分组成 (3)兼顾合理的输入和不合理的输入数据 (4)应检查程序是否作了不该做的事 (5)程序修改后要回归测试 (6)应长期保留测试用例,直至系统废弃。,程序测试举例 例:程序 Triangle, 输入三个整 数,表示一个三角形的三个边 长,该程序产生一个结果,指 出该三角形是等边三角形、等 腰三角形还是不等边三角形。,判断三角型的测试用例设计: 输入数据 预期结果 (1) 6;6;6 等边 (2) 8;8;4 等腰 (3) 4;5;6 一般 还应输入非法数据: 0; 7; 9 -7;3; 5 a; 2; 7 等,软件错误分类 功能错(需求分析错误) 软件结构错 数据错 编码错
11、 软件集成错 测试定义与测试执行错误,7.1.3 软件测试信息流,测试过程需要三类输入: 软件配置:需求规格说明书 软件设计说明书 被测源程序 测试配置:测试计划 测试用例(测试数据) 测试驱动程序 测试工具,7.1.3 软件测试信息流,软件 配置,测试,测试 配置,测试 工具,结果 分析,排错,可靠性 分析,测试 结果,错误,预期 结果,出错率,改正 的软件,预测 的可 靠性,7.1.4 测试的方法与技术,软件测试的 策略和方法,静态测 试方法,动态测 试方法,人工测试方法,计算机辅助静 态分析方法,白盒测试方法,黑盒测试方法,穷举测试方法,静态测试:基本特征是在对软件进行 分析、检查和测试
12、,不实 际运行被测试的软件。 静态测试约可找出3070%的逻辑设计错误. 对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错.,动态测试: 通过运行软件来检验软件的动态行为和运行结果的正确性 动态测试的两个基本要素: 被测试程序 测试数据(测试用例),动态测试方法 (1)选取定义域有效值,或定义域外无效值. (2)对已选取值决定预期的结果 (3)用选取值执行程序 (4)执行结果 与(2)结果相比, 不吻合程序有错.,每个开发人员应当测试自己的程序(份内之事),但是不能作为该程序已经通过测试的依据(所以项目需要独立测试人员)。 测试应当循序渐进,不要企图一次性干完,注
13、意“欲速则不达”。,测试的分类与比较,测试方式 白盒测试:关心软件内部设计和程序实现,主要测试依据是设计文档 黑盒测试:不关心软件内部,只关心输入输出,主要测试依据是需求文档,测试阶段,单元测试、集成测试、系统测试、验收测试。是“从小到大”、“由内至外”、“循序渐进”的测试过程,体现了“分而治之”的思想。 单元测试的粒度最小,一般由开发小组采用白盒方式来测试,主要测试单元是否符合“设计”。 集成测试界于单元测试和系统测试之间,起到“桥梁作用”,一般由开发小组采用白盒加黑盒的方式来测试,既要验证“设计”又要验证“需求”。 系统测试的粒度最大,一般由独立测试小组采用黑盒方式来测试,主要测试系统是否
14、符合“需求规格说明书”。 验收测试与系统测试非常相似,主要区别是测试人员不同,验收测试由用户执行。,7.2 两种类型的测试 “彻底地测试”难以成为现实,要考虑时间、费用等限制,不允许无休止地测试。 7.2.1 黑盒测试 又称:功能测试 数据驱动测试 基于规格说明书的测试,7.2.2 白盒测试 又称:结构测试 玻璃盒测试 基于覆盖的测试 根据被测程序的逻辑结构设计测试用例 力求提高测试覆盖率,黑盒测试与白盒测试比较 黑盒测试是从用户观点,按 规格说明书要求的输入数据与输 出数据的对应关系设计测试用例, 是根据程序外部特征进行测试。 白盒测试是根据程序内部逻辑结构进行测试。,7.2.3 穷举测试
15、例:输入 三条边长 黑盒测试 可采用的测试用例数 (设字长16位) 执行时间: 设测试一次需1ms 共需一千年。,=2 X2 X2 3X10,16,16,16,14,7.2.3 穷举测试 白盒测试 例: 含4个分支,循环次数 20,从A到B的可能 路径 执行时间: 设测试一次需3ms 穷举测试需1千年.,=5+5 +5 +5 10,20,1,2,19,14,A,B,不论黑盒还是白盒测试都不能 进行穷尽测试, 所以软件测试不可能发现程序中存在的所有错误 因此需精心设计测试方案, 力争尽可能少的次数,测出尽可能多的错误.,黑盒测试与白盒测试能发现的错误,C,B,A,D,-只能用黑盒测试发现的错误,A,-只能用白盒测试发现的错误,-两种方法都能发现的错误,-两种方法都不能发现的错误,B,C,D,有了“黑盒”测试为什么还要“白盒”测试,黑盒测试只能观察软件的外部表现,即使软件的输入输出都是正确的,却并不能说明软件 就是正确的。因为程序有可能用错误的运算方式得出正确的结果,例如“负负得正,错错得对”,只有白盒测试才能发现真正的原