软件测试技术教程[课件] (1)[25页]
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
• 什么是缺陷
▫ 所谓软件缺陷,即为计算机软件或程序中存在的某 种破坏正常运行能力的问题、错误,或者隐藏的功 能缺陷。缺陷的存在会导致软件产品在某种程度上 不能满足用户的需要。IEEE729-1983对缺陷有一 个标准的定义:从产品内部看,缺陷是软件产品开 发或维护过程中存在的错误、毛病等各种问题;从 产品外部看,缺陷是系统所需要实现的某种功能的 失效或违背。
• 软件测试与软件质量的区别
▫ 软件测试和软件质量是分不开的。测试是手段,质 量是目的。如果软件质量仅仅依赖于测试,是不可 能真正解决软件的质量问题。软件测试不是解决软 件质量的 ▫ 实现软件质量保证主要有两种途径,一种是通过贯 彻软件工程各种有效的技术方法和措施使得尽量在 软件开发期间减少错误;另一种是通过分析软件和 测试软件来发现和纠正错误。 ▫ 根本举措,只是一种辅助的,必须的手段。
• 什么是软件质量
▫ 所有描述计算机软件优秀程度的特性的组合
• 通常,软件质量由以下几个方面进行评价。
▫ 软件需求是衡量软件质量的基础,不符合需求的软 件就不具备质量。设计的软件应在功能、性能等方 面都符合要求,并能可靠地运行。 ▫ 软件结构良好,易读、易于理解,并易于修改、维 护。 ▫ 软件系统具有友好的用户界面,便于用户使用。 ▫ 软件生存周期中各阶段的文档齐全、规范。
• 软件测试属于软件控制,作为软件质量的重要保 证,其和软件质量保证的区别如下:
1.3 软件测试的目的
• 证明、检测和预防已经成为测试的重要目标。 • 证明 ▫ 获取软件系统在可接受风险范围内可用的信心; ▫ 尝试在非正常情况和条件下的功能和特性是可接受的; ▫ 保证一个软件系统是完整的并且可用或者可被集成的。 • 检测 ▫ 发现缺陷、错误和系统的不足; ▫ 定义软件系统的能力和局限性; ▫ 提供组件、工作产品和软件系统的质量信息。 • 预防 ▫ 确定系统的规格中不一致和不清晰的地方; ▫ 提供预防和减少可能制造错误的信息; ▫ 在过程中尽早检测错误; ▫ 确认问题的风险,并且提前确认解决这些问题和风险的途径。
1.1 行业背景
• 软件测试是伴随着软件的产生而产生的,有了软件生产和运行就必然有软件测试。早 期的软件开发过程中,测试的含义比较狭窄,将测试等同于“调试”,目的是纠正软 件中已经知道的故障,常常由开发人员自己完成这部分的工作。 • 直到1957年,软件测试才开始与调试区别开来,成为一种发现软件缺陷的活动。 • 直到20世纪80年代早期,“质量”的号角才开始吹响。软件测试定义发生了改变,测 试不单纯是一个发现错误的过程,而且包含软件质量评价的内容。软件开发人员和测 试人员开始坐在一起探讨软件工程和测试问题。 • 20世纪90年代,测试工具终于盛行起来。人们普遍意识到工具不仅是有用的,而且要 对今天的软件系统进行充分的测试,工具是必不可少的。 • 到了2002年,Rick和Stefan在《系统的软件测试》(Systematic Software Testing)一 书中对软件测试做了进一步定义:“测试是为了度量和提高被测软件的质量,对测试 软件进行工程设计、实施和维护的整个生命周期过程”。这些经典论著对软件测试研 究的理论化和体系化产生了巨大的影响。
• 缺陷的表现形式不仅体现在功能的失效方面,还 体现在其他方面。主要类型有:
▫ ▫ ▫ ▫ 软件没有实现产品规格说明所要求的功能模块; 软件中出现了产品规格说明指明不应该出现的错误; 软件实现了产品规格说明没有提到的功能模块; 软件没有实现虽然产品规格说明没有明确提及但应 该实现的目标; ▫ 软件难以理解,不容易使用,运行缓慢,或从测试 员的角度看,最终用户会认为不好。
软件测试教程
第1章 软件测试概述
第1章软件项目的功能测试
1.1 行业背景 1.2 软件测试与软件质量 1.3 软件测试的目的
1.4 测试用例
1.5 软件测试的原则 1.6 软件缺陷的修复成本 1.7 软件测试的对象 1.8 软件测试的分类 1.9 软件测试人员的基本素质 本章小结 习题
本章导读
• 本章讲解了软件测试行业的产生与发展,软件测 试在软件生命周期的地位和意义。以及软件测试 的概念(定义、对象、目的、原则),软件测试 的方法和分类。
▫ ▫ ▫ ▫ ▫ ▫ 有效性 经济性 可仿效性 可修改性 独立性 可跟踪性
• 测试用例设计的基本原则
▫ 测试用例的代表性 ▫ 测试结果的可判定性 ▫ 测试结果的可再现性
1.5 软件测试的原则
• • • • • • • • • • • 原则1:测试显示缺陷的存在 原则2: 穷尽测试是不可能的 原则3: 测试的尽早介入 原则4:缺陷的集群性 原则5: 杀虫剂悖论 原则6:测试活动依赖于测试内容 原则7:没有失效不代表系统是可用的 原则8:测试的标准是用户的需求 原则9: 尽早定义产品的质量标准 原则10: 测试贯穿于整个生命周期 原则11: 第三方或独立的测试团队
测试原则: • 应当尽早和不断地进行软件测试。 • 程序员应当避免检查自己的程序,测试工作应该交由独立的专业的软件测试 机构来完成。 • 设计测试用例时应该同时考虑合法和不合法的输入以及各种边界条件,特殊 情况下可以制造极端状态和意外状态,比如网络异常中断、电源断电等情况。 • 一定要注意测试中BUG集中发生的现象 • 对测试错误结果一定要有一个确认的过程,一般由A测试出来的错误,一定 要由B来确认,严重的错误可以召开评审会进行讨论和分析。 • 制定严格的测试计划,并把测试时间安排得尽量宽松,不要希望在极短的时 间内完成一个高水平的测试。 • 回归测试的关联性一定要引起充分的注意,修改一个错误而引起更多的错误 出现的情况并不少。 • 妥善保存一切测试过程文档,意义是不言而喻的。1.2 软件测 Nhomakorabea与软件质量
• 什么是测试
▫ 1983年IEEE提出的软件工程标准术语中给软件测 试下的定义是:“使用人工或自动手段来运行或测 定某个系统的过程,其目的在于检验它是否满足规 定的需求或是弄清预期结果与实际结果之间的差 别。” ▫ G.J.Myers认为“程序测试是为了发现错误而执行 程序的过程。”
1.4 测试用例
• 定义
▫ 测试用例(Test Case)是为某个特殊目标而编制的 一组测试输入、执行条件以及预期结果,以便测试 某个程序路径或核实是否满足某个特定需求。
• 测试用例的重要性
▫ ▫ ▫ ▫ 指导测试的实施 规划测试数据的准备 编写测试脚本的“设计规格说明书” 降低工作强度
• 测试用例的评价标准