软件工程7_1(概论、白盒)

《软件工程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,有了“黑盒”测试为什么还要“白盒”测试,黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件 就是正确的。因为程序有可能用错误的运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测试才能发现真正的原