《软件测试工程 》PPT课件
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
设计说明书
设计员: 我要让软件
理解正确性 编码正确性
做什么?
测试原则
(2)应该尽早制定测试计划。 概要设计时应完成测试计划,
详细的测试用例定义可在设计模型 确定后开始,所有测试可在任何代 码被产生之前进行计划和设计。
测试原则
(3)应该由第三方进行测试工作。 一个软件项目的开发人员不应
该同时是该软件的测试人员,基于 心理因素,人们往往不愿意否定自 己的工作。
测试原则
(4)穷举测试是不可能的。 测试的最高目标是指发现错误
的可能性最高的测试,所以,测试 的关键技术是设计一组高产的测试 用例,好的测试方案是尽可能发现 至今为止仍未发现的错误。从某种 意义上说,测试是否成功,取决测 试用例的选择。
测试原则
(5)充分注意到错误的群集现象 经验表明,测试发现的错误
开发前期出现错误的扩展
测 编 设 需求 试 码 计 分析 计划
A B
软件生存期各阶段间需保持的正确性
用户要求 用户:
相符吗?
运行结果
计算机:
我要什么?
程序运行得
理解正确性
5 到的结果
表达正确性
1
运行正确性
需求说明书
分析员:
我可以提
供什么?
2
4 输入正确性
源程序
程序员:
我要让计算
3
机什么做?
理解正确性 设计正确性 表达正确性
第五章 软件测试工程
概述
软件开发过程必须伴有质量 保证活动。
软件测试是软件质量保证的 关键元素,代表了规约、设计 和编码的最终检查。
软件产品最大的成本是检测软 件错误、修正软件错误的成本。
在整个软件开发中,测试工作量 一般占30%~40%,甚至≥50%。 在人命关天的软件(如飞机控制、 核反应堆等)测试所花费的时间 往往是其它软件工程活动时间之 和的三到五倍
中有80%的错误很可能是由20%的 程序模块造成的,这是一种错误 群集性现象。也就是说,在程序 段中,发现错误数目多的地方, 则残存错误的数目也比较多,这 一现象已为许多程序测试实践所 证明。
测试原则
(6)测试应该从“小规模”到“大规 模” 通常,最初的测试重点往往是
放在单个的程序模块中,然后,进 一步的测试重点放在集成的模块族 ,最后是对整个系统进行测试。随 着测试的逐步深入展开,要集中测 试容易出错的地方。
测试的“成功”与“失败”:能 够发现错误的测试是成功的测试,否 则是失败的测试。
“测试的目的是说明程序正确地执
行它应有的功能” 这种说法正确吗?
例:程序Triangle,输入三个整数,表 示一个三角形的三个边长,该程序产生一 个结果,指出该三角形是等边三角形、等 腰三角形还是不等边三角形。
为说明其能正确执行它的功能,可使用 “测试用例”(3,4,5),(5,5,6),(6,6,6), 程序都能给出正确结果,是否就可认为程 序是正确的?
质量控制技术
避免错误
检错
调试 测试
容错
质量控制活动分类
开发方法学 配置管理 验证技术 评审
正确性验证 性能调试 组件测试 集成测试
系统测试 原子事务 模块冗余性
测试的目的与地位
G.J.Myers在《软件测试技巧》
中认为:
1.测试是为了寻找错误而运行程序的过 程。
2.一个好的测试用例是指很可能找到迄 今为止尚未发现的错误的测试。
软件测试是为了发现错误而执行程 序的过程,或者说,软件测试是根 据软件的规格说明(例如软件的功 能、性能、运行环境等要求)以及 程序内部结构而设计一批测试用例 ,并利用这些测试用例去运行程序 ,以发现软件错误的过程。
测试用例是为了测试软件而设计的 一组数据,它应该包括输入的数据 和预期输出的结果两部分。
测试用例={输入数据+预期结果}
软件测试背景
软件是人编的—所以不完美
实例:
• Intel的pentium处理器 • 1994年浮点除法缺陷 • 2000年8月28日,1.13MHZ处理器一个可能导致运行程 序被挂起的执行指令问题
• 1999年12月3日,美国航天局火星极地登陆飞船失 踪
• 1991年爱国者导弹防御系统系统时钟错误积累造 成跟踪系统失去精确度
• 千年虫:世界各地解决2000年错误超过数亿美元
质量管理领域权威人物J.M.Juran将质量 定义为“决定产品性能和‘满意程度’ 的特征”, 测试注重于产品的满意度。
测试应针对这样一种情况:软件产品在 一些特定的范围内不能满足客户的合理 要求。
通过测试过程可以评定质量风险(可能 的错误),了解被测试系统中存在的错 误模式(观察到的错误症状)。
测试原则
(1)所有的测试都应追溯到用户需求
最严重的错误(从用户角度)是那些导 致软件无法满足需求的错误。 程序中的问题根源可能出现在开发前 期的各阶段,纠正错误也必须追溯到 前期工作。
测 决定软件与系统的配合关系
试 与
需求分析
开
概要设计
发
详细设计
前
期
编码
工
单元测试
作 的
集成测试
关
确认测试
系
系统测试
(两边之和必须大于第三边)
难以现,那么 它算不算软件缺陷?”
见,古谁谚能:说它“发一出片了树声叶音飘?落”在森林中没有人听眼
由于不能报告没有看见的问题,因此, 没有看见就不能说存在软件缺陷。
见 为
只有看到了,才能断言软件缺陷,尚未 实
发现的软件缺陷只能说是未知软件缺陷。
3.一个成功的测试是揭示了迄今为止尚 未发现的错误的测试。
E.W.Dijkstra 指出: “程序测试能证明错误的存在,
但不能证明错误不存在。”
测试的目的是发现程序中的错 误,是为了证明程序有错,而不 是证明程序无错。
把证明程序无错当作测试目的不仅是 不正确的, 完全做不到的,而且对做 好测试没有任何益处,甚至是十分有 害的。 软件测试要设法使软件发生故障,暴 露软件错误。
软件测试是一个查找错误的过程,所以 软件测试只能证明错误的存在,而不是 证明程序无错,不能保证经过测试的程 序一定没有错误。 软件测试仅仅是一个手段,根本的目的 是为了纠错,即纠正软件中的错误,从 而提高软件的质量。 测试不可能发现所有错误,只能在有限 的时间和经济条件下,尽可能地发现错 误。
质量控制
软件测试流程
需求规格说明书 软件设计说明书
被测源程序
软件 配置
测试计划 测试用例 (测试数据) 测试驱动程序
测试 配置
测试
工具
改正
的软件
测试 错误 排错