软件质量保证与测试工程硕士.ppt

1、1,软件测试,内容,前言 第一章 软件质量保证 第二章 软件测试概述 第三章 测试人员的数学知识 第四章 软件测试技术 第五章 软件测试过程 第六章 软件测试管理体系,前言-内容,课程的由来 软件危机 软件工程 软件质量保证 软件测试 课程的介绍 目标 内容 形式和要求 参考书目,前言-课程由来,软件危机(1960s) 根源： 硬件越来越复杂，功能越来越强大（摩尔定律） 对软件在应用领域和规模上的期望越来越高 软件的发展速度落后于硬件的发展速度 真实世界与计算机世界的映射 靠人来生产 多人开发,前言-课程由来,软件危机(1960s) 表现：软件质量不高、超出预算、项目延迟 根源：软件系统复杂性

2、提高、多人合作 解决： 软件工程 与软件相关的人员 项目组 用户和股东 计算机系统 设计技术 控制复杂：人的思维极限 抽象/建模 分解 重用：质量和效率 语言与开发包 OO,前言-课程由来,软件工程 目标：解决沟通和集成问题 策略：控制错误 错误 缺陷/Bug/Defect/Error 狭义： 软件定义、设计、实现、打包/部署、使用过程中出现的与明确的需求不一致：不能正确完成任务、完成多余的任务 广义： 还包括：改善产品的建议；与用户隐含的需求不一致,前言-课程由来,软件工程 方法： 预防错误： 规范化 流程、职责、角色、模式：RUP (Rational Unified Process )、C

3、MM/CMMI、Pattern 表达方式：UML、Pattern 文档化 迭代与体系结构 纠正错误： 测试 调试 减少错误损失 培训,前言-课程由来,SQA：软件质量保证 过程改进：预防错误 规范化：流程 文档化 软件测试：发现错误 错误发现的越早，解决的代价越小,前言-课程由来,SQA涉及的工作岗位 过程改进工程师 过程改进 测试工程师 软件测试 开发工程师 软件测试 软件调试 测试经理 测试流程管理 测试度量,前言-内容,课程的由来 软件危机 软件工程 软件质量保证 软件测试 课程的介绍 目标 内容 形式和要求 参考书目,前言-课程介绍,目标 学习质量保证的基本概念和理论 学习软件测试的基

4、本概念和理论 掌握白盒测试/黑盒测试技术 掌握单元测试/集成测试/系统测试技术 掌握测试流程管理和测试度量技术 掌握测试工具和测试流程管理工具 了解测试相关工作的岗位要求和职业素质要求 了解测试行业的现状和技术发展趋势,前言-课程介绍,内容 软件质量保证方法和软件测试概念 开发工程师需要掌握的 静态测试/白盒测试/黑盒测试技术、单元测试/集成测试要求 测试度量方法 测试工具 职业素质要求,前言-课程介绍,内容 测试工程师需要掌握的 黑盒测试技术、集成测试/系统测试要求 攻击式软件测试 测试度量方法 测试工具 职业素质要求 测试经理需要掌握的 测试流程管理 测试团队组织和测试度量 测试流程管理工

5、具和缺陷跟踪工具 职业素质要求,前言-课程介绍,形式和要求 学习前的要求： 掌握软件工程基本概念 掌握软件开发方法、高级程序设计语言和数据库相关知识 了解Windows平台开发 学习方式： 课堂讲解 上机实践（浪潮通软ERP或者自己开发计算器程序） 课堂讨论或者课堂练习 成绩评定方法： 期末笔试占总成绩的60% 实践和课堂讨论（课堂练习）占总成绩的40%,前言-课程介绍,参考书目 软件测试基础 Paul Ammann, Jeff Offutt，2010,机械工业出版社 软件测试案例教程 吕云翔，王洋等 ，2011，机械工业出版社 实用软件测试指南 马良荔，2003，电子工业出版社,前言-其他事

6、宜,请班长留联系方式 请留班级公共邮箱,17,第一章 软件质量保证,第一章 内容,1.1 软件质量 1.2 软件质量保证：SQA 1.2.1 SQA目标 1.2.2 SQA模型 1.2.2.1 ISO9001 1.2.2.2 CMMI 1.3 SQA支持工具,1.1 软件质量,什么是软件质量 ANSI/IEEE Std 729-1983定义软件质量为“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”。 M.J. Fisher 定义软件质量为“所有描述计算机软件优秀程度的特性的组合”。,1.1 软件质量,高质量的软件,能够按照预期的时间和成本提交给用户，并能够按照预期要求正确工作的

7、软件 Scope Time Cost,1.1 软件质量,为什么提出软件质量 软件质量不高是导致软件危机的根本原因 进度延误、预算超支 项目失败、项目终止 软件质量高可以降低总成本 软件维护成本 高质量的软件可以降低维护成本，并延长软件的生命期，从而降低总成本 软件失效成本 高质量的软件可以降低软件失效导致的成本损失，从而降低总成本,怎样提高软件质量 目标 优化软件开发过程 减少软件中的bug 方法 防止在软件中引入错误 通过检测找出软件中的错误，并解决这种错误,1.1 软件质量,1.2 软件质量保证：SQA,什么是SQA Software Quality Assurance 是软件工程领域中的

8、一部分 为了确保软件开发过程和结果符合预期的要求，而建立的一系列规程和计划，以及依照规程和计划采取的一系列活动及其结果评价 软件开发过程是按照计划和规范实施的 软件开发结果包括完整的软件和文档，并且符合可预期的目标和检验标准,1.2.1 SQA目标,SQA总目标 减少并纠正实际的软件开发过程和软件开发结果与预期的软件开发过程和软件开发结果的不符合情况 SQA方法 通过在软件开发周期中尽可能早地预期或检测到不符合情况(错误) ，来防止错误的发生，并减少错误纠正的成本 错误发现得越早，造成的损失越小，修改的代价也越小,1.2.1 SQA目标,软件开发不同阶段： 需求分析：Requirements

9、Analysis 规格定义：Software Specifications 设计：Design 编码：Coding 测试：Testing 维护：Maintenance,1.2.1 SQA目标,需求分析：Requirements Analysis 确保客户提出的要求是可行的 确保客户了解自己提出的需求的含义，并且这个需求能够真正达到他们的目标 确保开发人员和客户对于需求没有误解或者误会 确保按照需求实现的软件系统能够满足客户提出的要求,1.2.1 SQA目标,规格定义：Software Specifications: 确保规格定义能够完全符合、支持和覆盖前面描述的系统需求 可以采用建立需求跟踪文

10、档和需求实现矩阵的方式 确保规格定义满足系统需求的性能、可维护性、灵活性的要求 确保规格定义是可以测试的，并且建立了测试策略 确保建立了可行的、包含评审活动的开发进度表 确保建立了正式的变更控制流程,1.2.1 SQA目标,设计：Design: 确保建立了设计的描述标准，并且按照该标准进行设计 确保设计变更被正确的跟踪、控制、文档化 确保按照计划进行设计评审 确保设计按照评审准则评审通过并被正式批准之前，没有开始正式编码,1.2.1 SQA目标,编码：Coding: 确保建立了编码规范、文档格式标准，并且按照该标准进行编码 确保代码被正确地测试和集成，代码的修改符合变更控制和版本控制流程 确保

11、按照计划的进度编写代码 确保按照进化的进度进行代码评审,1.2.1 SQA目标,测试：Testing: 确保建立了测试计划，并按照测试计划进行测试 确保测试计划覆盖了所有的系统规格定义和系统需求 确保经过测试和调试，软件仍旧符合系统规格和需求定义,1.2.1 SQA目标,维护：Maintenance: 确保代码和文档同步更新，保持一致 确保建立了变更控制流程和版本控制流程，并按照这些流程管理维护过程中的产品变化 确保代码的更改仍旧符合编码规范、通过代码评审，并且不会造成垃圾代码或冗余代码,1.2.2 SQA模型,质量管理历史 质量就是产品、过程、系统符合标准要求的能力 质量是生产出来的，不是检

12、测出来的 质量存在于全部直接/间接相关的环节中 Deming(美国质量管理专家戴明博士 )，日本的全面质量管理TQM 预防为主 第一次就把事情做好是最经济的 质量管理的灵魂在于持续改进 PDCA,1.2.2 SQA模型,软件质量管理相关标准和技术 标准 ISO9000族标准 国际标准，ISO/TC176制订，适用于所有行业，其中9000-3针对软件开发行业 SW-CMM/CMMI标准 CMM:行业标准，CMU-SEI制订和管理，针对软件开发行业 CMMI:集成的CMM ISO15504标准 国际标准，试图结合ISO9000、CMM与软件工程概念 项目管理技术 项目：目标、起止时间、相关活动 定

13、义、计划、实施,1.2.2.1 ISO9001,ISO9000族标准 一系列关于质量管理/质量保证/质量审核方面的国际标准，1983/1994/2000 9001/9002/9003/9004/9000-3 是管理思想的精华，管理工作的指导原则，也是做事方式 文档管理：写你要做的，做你所写的，记你所做的 过程控制：PDCA-计划性及持续改进 相关标准：QS9000等,1.2.2.1 ISO9001,原则 原则1：以顾客为中心 组织依存于顾客。因此，组织应理解顾客当前和未来的需求，满足顾客要求并争取超越顾客期望 原则2：领导作用 领导将本组织的宗旨、方向和内部环境统一起来，并创造使员工能够充分参

14、与实现组织目标的环境,1.2.2.1 ISO9001,原则 原则3：全员参与 各级人员是组织之本。只有他们的充分参与，才能使他们的才干为组织带来最大的收益 原则4：过程方法 将相关的资源和活动作为过程进行管理，重视输入和输出，可以更高效地得到期望的结果,1.2.2.1 ISO9001,原则 原则5：管理的系统方法 针对设定的目标，识别、理解并管理一个由相互关联的过程所组成的系统，有助于提高组织的有效性和效率 原则6：持续改进 持续改进是组织的一个永恒目标,1.2.2.1 ISO9001,原则 原则7：基于事实的决策方法 对数据和信息的逻辑分析或直觉判断是有效决策的基础 原则8：互利的供方关系

15、通过互利的关系，增强组织及其供方创造价值的能力,1.2.2.1 ISO9001,在软件企业的实施案例 原则： 运用项目管理技术 重视质量策划 重视培训和工具支持 框架： 质量手册、规程文件、作业指导书 开发管理、体系支持,1.2.2.1 ISO9001,在软件企业的实施案例 角色分工,1.2.2.1 ISO9001,在软件企业的实施案例 产品开发规程,1.2.2.1 ISO9001,在软件企业的实施案例 定制项目开发规程,1.2.2.1 ISO9001,在软件企业的实施案例,体系支持规程 管理评审规程 质量体系文件控制规程 内部质量体系审核规程 纠正措施规程 预防措施规程 配置管理规程 质量记

16、录控制规程,产品度量规程 过程度量规程 采购规程 配套软件产品控制规程 培训规程 档案管理规定 合同评审规程 软件质量保证规程 产品开发规程,1.2.2.1 ISO9001,在软件企业的实施案例,ISO9001是品质保证标准，对过程管理提出最低要求 质量保证体系根据软件工程原理自行设计和维持，满足ISO9001要求 质量策划根据项目自身特点，对质量体系进行剪裁和补充,1.2.2.2 CMMI,CMMI：Capability Maturity Model Integration，即能力成熟度模型集成 来源于：美国卡内基梅隆大学的软件工程研究所(SEI)创立的CMM(Capability Matu

17、rity Model 软件能力成熟度模型),1.2.2.2 CMMI,目标 为提高组织过程和管理产品开发、发布和维护能力提供保障。 帮助组织客观评价自身能力成熟度和过程域能力，为过程改进建立优先级以及执行过程改进。,1.3 SQA支持工具,SQA实施要素 规范 规程、模板、指南 文档、记录 人员 分工、接口、培训、检查 技术 知识管理、工具,1.3 SQA支持工具,支持工具 自行开发 厂商提供 IBM Rational,49,第二章 软件测试概述,内容,2.1 软件测试定义及术语 2.2 错误与缺陷的分类 2.3 软件测试的目标 2.4 软件测试的特征 2.5测试用例及管理工具,2.1 什么是

18、软件测试,软件测试是为了发现错误而执行一个程序或系统的过程,2.1 软件测试的发展历史,20世纪50年代之前，没有系统的软件测试 20世纪50年代-60年代，测试的重点是高级语言编写的系统，软件测试发展缓慢 20世纪70年代以后，软件测试发展迅速，同时面临着危机 现在，软件测试是一个基于软件开发整个生命周期的质量控制活动,2.1 国内软件行业的现状,处于起步阶段 软件评测中心的出现,2.1 软件的生命周期,2.1 相关术语,软件故障：软件中的静态缺陷 软件错误：不正确的内部状态，该状态是某个故障的表现 软件失败：与需求或者其他期望行为的描述有关的、外部的、不正确的行为,2.1相关术语,以看病为

19、例解释上述术语：病人带着一些失败（症状）进入医生办公室，医生必须发现故障（症状的根源）。为了帮助诊断，医生制定一些测试来寻找异常的内部条件，比如高血压、心律不齐等，这些异常的内部条件相当于错误。,2.1相关术语,软件测试与医生诊疗有质的不同： 软件中的故障是设计错误 医疗问题与计算机硬件故障一样，经常是物理退化的结果,2.1相关术语,Public static int numZero(int x) /效果：统计x中0出现的次数 int count = 0； for (int i = 1;i x.length;i+) if (xi = 0) count+; return count; ,考虑输入

20、为2.7.0和0.7.2时，上述程序的表现,虽然有软件故障，但是第一个输入，软件并没有失败,2.1相关术语,上一页的例子说明，对于一个给定的故障，不是所有的输入都会“触发”故障来创建不正确的输出（失败）。要发现一个失败需要考虑下面3个条件： 程序中包含故障的位置必须找到 执行该位置后，程序的状态必须是不正确的 受到影响的状态必须传播出来，引起改程序的某个输出是不正确的,2.1软件故障产生的原因,2.2 软件测试的目的,2.2软件测试的目的,软件测试是一个为了寻找缺陷而运行程序的过程 一个好的测试用例是很可能找到至今为止尚未发现的缺陷的测试用例 一个成功的测试是揭示了至今为止尚未发现缺陷的测试

21、软件测试的目标是设计这样的测试：既能系统的揭示不同类型的缺陷而且耗费最少的时间和最少的工作量,2.2软件测试的原则,测试能提高软件的质量，但是提高质量不能依赖测试 确定预定的输出 避免测试自己的程序 彻底检查每一个测试结果 对非法、非预期性输入的测试 检查程序是否做了它不该做的事 程序中存在错误的概率与已发现的错误数成正比 保留测试用例,2.2软件测试中的误区,调试和测试是一样的 测试组应该为保证质量负责 过分依赖Beta测试 把测试作为新员工的一个过渡工作 把不合格的开发人员安排作测试 关注测试的执行，忽略测试的设计,2.2软件测试中的误区（续）,测试自动化是万能的 测试时可以穷尽的 测试是

22、为了证明软件的正确性 测试是枯燥乏味，缺乏创造力的工作,2.2软件测试人员应具备的素质,探索精神 故障排除能力 不懈努力 创造性 追求完美 判断准确 老练稳重 说服力,2.3 软件缺陷,软件未达到产品描述标明的功能/非功能要求 软件出现了产品描述指明不会出现的错误 软件功能超出了产品描述指明的功能 软件未达到产品描述虽未指明但应达到的目标 测试人员或者最终用户认为软件难以理解、不易使用、运行速度缓慢,2.3 缺陷分类,轻微 词语拼写错误 中等 误导或重复信息 使人不悦 被截断的名称 影响使用 有些交易没有处理 严重 丢失交易,2.3 缺陷分类（续）,非常严重 不正确的交易处理 极为严重 经常出

23、现“非常严重”错误 无法忍受 数据库破坏 灾难性 系统停机 容易传染 扩展到其他系统停机,2.4 软件测试的特征,软件测试具有一定的风险 软件缺陷的寄生虫性 软件测试的杀虫剂现象 软件测试的不修复原则 Pareto原则,2.4完全测试程序是不可能的,输入量太大 输出结果太多 软件实现途径太多 软件说明书没有客观标准,2.4软件测试是有风险的行为,2.4软件缺陷的寄生虫性,找到的缺陷越多，说明软件存在的缺陷越多 原因：程序员的疲倦 程序员往往犯同样的错误 某些软件缺陷可能是大灾难的征兆,2.4软件测试的杀虫剂现象,软件测试越多，其免疫力越强 方案：编写新的测试用例 对程序的不同部分进行测试,2.

24、4软件测试的不修复原则,并非所有的软件缺陷都需要修复 原因： 没有足够的时间，项目进度决定 不算真正的缺陷，是一项功能 修复风险太大 ，可能导致其它bug 不值得修复，不常用的功能，不常出现的bug，可以躲过的,2.4 Pareto原则,2.5 什么是测试用例？,测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。,2.5系统测试用例的好处（一）,要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。,2.5系统测试用例的好处（二）,对测试过程可

25、以进行进行有效的监督，可以准确、有效的评估测试的工作量,2.5系统测试用例的好处（三）,可以对测试结果进行评估，并且对测试是否完成产生一个量化的结果,2.5系统测试用例的好处（四）,可以在回归测试的过程中准确、快速的进行正确的回归,2.5系统测试用例的好处（五）,测试用例的使用令软件测试的实施重点突出、目的明确,2.5系统测试用例的好处（六）,在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。,2.5系统测试用例的好处（七）,在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期,2.5系统测试用例的范围,用户的需求，包括用户提出的功能性需求、非功

26、能性需求等 系统测试用例需要考虑的问题：功能、易用性、性能、安全等,2.5测试用例的局限性,我们不可能进行穷举测试， 为了节省时间和资源、提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。,2.5测试用例设计人员,测试用例应由测试设计员或专职测试工程师来制定，而不是普通的测试执行人员；应该让最有能力的人员来完成用例的设计,2.5测试用例要素,编号：唯一编号 前置条件：说明测试路径 重要级别：对后期的测试用例执行的考核提供一个标准 输入：输入的条件 期望输出：期望输出的结果 实际输出：实际输出的结果 是否正确：是/否 执行人：测试用例执行人标志 执行

27、时间：测试用例执行的时间 备注：其他说明文字,2.5 练习一,有两个有故障的程序，每个包含了一个以失败为结果的测试用例，确定程序中的故障。练习一,2.5测试用例编写,1、Word 2、Excel 3、系统管理（TestDirector、Bugzilla）,2.5 TestDirector,Mercury Interactive公司（2006年被HP以45亿美元收购 ）的测试管理工具,2.5 TestDirector-测试管理过程,需求定义（Specify Requirements）： 分析应用程序并确定测试需求。 测试计划（Plan Tests）： 基于测试需求，建立测试计划。 测试执行（Ex

28、ecute Tests）： 创建测试集（Test Set）并执行测试。 缺陷跟踪（Track Defects）： 报告程序中产生的缺陷并跟踪缺陷修复的全过程。 贯穿测试的每一个阶段，你能够通过产生详细的报告和图标对数据进行分析。,2.5 TestDirector-需求定义,定义测试范围（Define Testing Scope）： 检查应用程序文档，并确定测试范围测试目的、目标和策略。 创建需求（Create Requirements）： 创建需求树（Requirements Tree），并确定它涵盖所有的测试需求。 描述需求（Detail Requirements）： 为“需求树”中的每一个

29、需求主题建立了一个详细的目录，并描述每一个需求，给它分配一个优先级，如有必要的话还可以加上附件。 分析需求（Analyze Requirements）： 产生报告和图表来帮助你分析测试需求，并检查需求以确保它们在你的测试范围内。,TestDirector-需求定义,2.5 TestDirector-需求描述,优先级：Low, Medium, High, Very High, Urgent 覆盖状态：no covered, passed, no completed, no run, failed,TestDirector-需求描述,2.5 TestDirector-测试计划,定义测试策略（Def

30、ine Testing Strategy）： 检查应用程序、系统环境和测试资源，并确认测试目标。 定义测试主题（Define Test Subject）： 将应用程序基于模块和功能进行划分，并对应到各个测试单元或主题，构建测试计划树（Test Plan Tree）。 定义测试（Define Tests）： 定义每个模块的测试类型，并为每一个测试添加基本的说明。 创建需求覆盖（Create Requirements Coverage）： 将每一个测试与测试需求进行连接。,2.5 TestDirector-测试计划,设计测试步骤（Design Test Steps）： 对于每一个测试，先决定其要进

31、行的测试类型（手动测试和自动测试），若准备进行手动测试，需要为其在测试计划树上添加相应的测试步骤（Test Steps）。测试步骤描述测试的详细操作、检查点和每个测试的预期结果。 自动测试（Automate Tests）： 对于要进行自动测试的部分，应该利用Mercury Interactive 、自己或第三方的测试工具来创建测试脚本。 分析测试计划（Analyze Test Plan）： 产生报告和图表来帮助你分析测试计划数据，并检查所有测试以确保它们满足你的测试目标。,TestDirector-测试计划,TestDirector-建立测试覆盖,TestDirector-测试步骤,2.5 T

32、estDirector-测试执行,创建测试集（Create Test Sets）： 在你的工程中定义不同的测试组来达到各种不同的测试目标，他们可能包括，举个例子，在一个应用程序中测试一个新的应用版本或是一个特殊的功能。并确定每个测试集都包括了哪些测试。 确定进度表（Schedule Runs）： 为测试执行制定时间表，并为测试员分配任务。 运行测试（Run Tests）： 自动或手动执行每一个测试集。 分析测试结果（Analyze Test Results）： 查看测试结果并确保应用程序缺陷已经被发现。生成的报告和图表可以帮助你分析这些结果。,TestDirector-建立测试集,TestDi

33、rector-加入测试集,2.5 TestDirector-缺陷跟踪,添加缺陷（Add Defects）： 报告程序测试中发现的新的缺陷。在测试过程中的任何阶段，质量保证人员、开发者、项目经理和最终用户都能添加缺陷。 检查新缺陷（Review New Defects）： 检查新的缺陷，并确定哪些缺陷应该被修复。 修复打开的缺陷（Repair Open Defects）： 修复那些你决定要修复的缺陷。 测试新构建（Test New Build）： 测试应用程序的新构建，重复上面的过程，直到缺陷被修复。 分析缺陷数据（Analyze Defect Data）： 产生报告和图表来帮助你分析缺陷修复过

34、程，并帮助你决定什么时候发布该产品。,TestDirector-缺陷跟踪,TestDirector-添加缺陷,2.5 TestDirector-缺陷状态,New ： 测试人员新发现的缺陷 open ：经开发负责人检查后，确认是缺陷，将其状态设置为open Fixed：开发人员对于缺陷修复完毕后，将其状态置为fixed Rejected：如果发现不是缺陷或者是重复缺陷，开发负责人将缺陷的状态置为rejected Closed：对于状态是fixed或者是rejected的缺陷，可以关闭，closed是缺陷的最终状态 Reopen：对于状态是fixed的缺陷，如果测试人员经过验证后，发现没有完全修复

35、，将其状态置为reopen,TestDirector主页面,TestDirector创建项目,TestDirector-创建用户,TestDirector-登陆,2.5编写测试用例需要考虑的问题,1、测试用例的执行结果可以作为测试报告的一个附件提交，从而提高测试报告的能够更准确的反映测试的进展 2、通过对测试用例的执行情况的汇总、统计，可以得出系统目前所进行的测试工作是否充分、必要，是否已经达到了预期的效果，测试是否已经按计划完成等,115,第三章 测试人员的数学知识,3.1 集合论,集合定义：一组明确的、互不相同的事物组成的整体，称为一个集合。 集合与成员：组成集合的各个事物称为该集合的元素

36、。,3.1集合定义方式,全部列举：写出集合的所有元素 部分列举：列举部分元素，其它元素用省略号代替 规定集合的元素所满足的条件： A=x|x具有的性质P,3.1空集,空集是不包含任何元素的集合 空集表示： 和 是不同的 年|2012年1812,3.1维恩图,维恩图是由两个或者两个以上重叠的圆组成的，用于表示集合之间的相互关系。 集合的关系 A 是 B 的 子集 A B A 是 B 的 真子集 A B A 和 B 是 相等集合A=B,3.1集合划分,集合的划分 A1,A2,An是集合A的子集 A1,A2,An是集合A的一个划分 A1A2An=A 且 Ai Aj= (i != j),3.1集合划分

37、在测试中的应用,测试（1） 完备性 （2） 无冗余性 比如： 三角形和非三角形 等边、等腰、不等边和非三角形 等边、等腰、不等边、直角和非三角形,3.2函数,任何程序都可以看成将其输出与输入关联起来的函数，因此函数是开发测试的核心概念。 1对1函数/多对1函数 程序实现的功能大多数是多对一的函数，这对测试很重要（多对一测试可选代表等价类1对1 功能相似也可分等价类）,3.3概率论,测试中研究语句执行特定路径的概率 事件的概率P(E)=E/S s是有限样本空间，E是事件,3.4图论,有向图 无向图 定义：图G=(V, E)由结点的有限非空集V和结点无序对偶集E组成 图通过关联矩阵表示 图G=(V

38、, E)的关联矩阵是mn矩阵,3.4图论,相邻矩阵 n1 n2 n3 n4 n5 n6 n7 N1 0 1 0 1 0 0 0 N2 1 0 0 0 1 0 0 N3 0 0 0 1 0 0 0 N4 1 0 1 0 0 1 0 N5 0 1 0 0 0 0 0 N6 0 0 0 1 0 0 0 N7 0 0 0 0 0 0 0,3.4图论,路径 结构化测试中用例 路径是一系列的边或一系列的节点,3.4图论,有向图（框图）D=(V,E) 一个节点有限集合V 一个边的集合E 有向图即可表示程序框图 有向图相邻矩阵：有m个节点的有向图D=(V, E)的相邻矩阵是一个mm矩阵 有向图的路径：有向图的

39、路径是一系列的边，使得该序列中所有相邻对偶ei，ej第一条边的终止节点是第二条边的起始节点,128,第四章 测试技术,内容,4.1功能测试技术 4.1.1白盒静态测试 4.1.2白盒动态测试 4.1.3基于场景测试 4.1.4黑盒测试 4.1.5因果图测试 4.1.6侵入测试 4.1.7错误猜测法 4.2功能测试总结 4.3自动化功能测试 4.4非功能测试技术 4.5自动化非功能测试 4.6非功能测试案例 4.7GUI测试,4.1静态与动态测试,4.1功能测试,功能测试的基本方法是构造一些合理或者不合理的输入，检查输出是否与期望的相同。如果两者不一致，即表明功能有误。也有例外的情况，如需求规格

40、说明书中的某个功能写错了，而实际上软件的功能却是正确的，这时要更改的是需求规格说明书。 功能测试看起来比较简单，只要看得懂需求规格说明书，谁都会做。难点在于如何构造有效的输入。由于输入空间通常是无限的，穷举测试显然行不通。随便输入一些东西，碰运气也是行不通的,4.1功能测试,肯定测试：验证系统和它陈述的需求一致 否定测试：证明一个系统不会作不需要它做的事情,4.1录音机需求,状态：备用、打开、播放、停止 在备用模式时，按打开按钮打开录音机 当录音机打开时，按备用按钮回到备用模式 当录音机打开时，按播放按钮开始播放当前磁带，按停止按钮停止播放,4.1肯定测试的用例,在备用模式时，按打开按钮打开录

41、音机 当录音机打开时，按备用按钮回到备用模式 当录音机打开时，按播放按钮开始播放当前磁带，按停止按钮停止播放,4.1否定测试的用例,当录音机正在播放磁带时，按下备用按钮会怎样？ 按下打开按钮会怎样？ 当录音机打开并且没有磁带时，按下播放按钮会怎样？按下停止按钮会怎样？ 当录音机正在播放磁带时，断电。,4.1功能测试技术,白盒测试 黑盒测试,4.1白盒测试和黑盒测试,白盒测试：对于测试对象的内部内容是透明的、可见的，可以设计数据覆盖测试对象的每一条路经。 黑盒测试：黑盒法不关心程序内部的逻辑，而只是根据程序的功能说明来设计测试用例,4.1.1白盒测试,4.1.1白盒测试,代码检查 静态结构分析

42、代码质量度量 功能确认与接口分析 逻辑覆盖率分析 性能与效率分析 内存分析,4.1.1白盒法-静态测试,代码检查 静态结构分析,4.1.1白盒法代码检查,目的 确保代码编程规范被有效执行 检查代码是否存在逻辑上的错误,4.1.1白盒法代码检查,变量命名和类型检查 变量初始值检查 变量作用范围检查 程序逻辑审查 程序语法检查 程序结构检查,4.1.1白盒法代码检查,排除违背程序编写标准的问题 排除违背程序编程风格的问题 确保代码和设计的一致性 确保代码的逻辑表达的正确性 确保代码结构的合理性 找出程序中不可移植的部分 发现程序中不安全、不明确、模糊的部分 实践表明，程序走查平均能查出被测程序的3

43、0%-70%的逻辑设计和代码缺陷，IBM代码走查能够检查出80%的错误,4.1.1白盒法代码检查,需求描述文档 程序设计文档 程序的源代码清单 代码编码标准 代码缺陷检查表,4.1.1 C/C+代码检查表,文件结构 程序的版式 命名规则 表达式与基本语句 常量 函数设计 内存管理 C+函数的高级特性 类的构造函数、析构函数 类的高级特性 其他特性,4.1.1文件结构,头文件和定义文件的名称是否合理 头文件和定义文件的目录结构是否合理 版权和版本声明是否完整,4.1.1程序的版式,空行是否得体? 代码行内的空格是否得体? 长行拆分是否得体? “”和“”是否是否各占一行并且对齐于同一列 一行代码是

44、否只做一件事情?如只写一条语句 If,for,while,do等语句各占一行，不论执行多少语句都写,4.1.1命名规则,命名规则是否与采用的操作系统或者开发工具的风格保持一致 标示符是否直观并且可以拼读,4.1.1程序的版式,If (year = 2000) /良好的版式 If (year=2000) /不良的版式 If (a = b) if(x3) /语句块3 ,4.1.2流程图,4.1.2白盒法,语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 条件组合覆盖 路径测试,4.1.2白盒法语句覆盖,语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次；,4.1

45、.2白盒法语句覆盖,为了说明简略，分别对各个判断的取真、取假分支编号为a、b、c、d、e。 为了测试语句覆盖率只要设计一个测试用例就可以把三个执行语句块中的语句覆盖了。 测试用例输入为： x=4、y=5、z=5 程序执行的路径是：abd,该测试用例虽然覆盖了可执行语句，但并不能检查判断逻辑 是否有问题，例如在第一个判断中把 3 int y=0; 4 while (iRecordNum- 0) 5 6 if(0= =iType) 7x=y+2; 8 else 9 if(1= =iType) 10 x=y+10; 11 else 12 x=y+20; 13 14 ,4.1.2第一步：画出控制流图,

46、c/c+语句中的控制语句表示含义如下： 图中的每一个圆称为流图的结点，代表一条或多条语句。流图中的箭头称为边或连接，代表控制流。,4.1.2白盒法,4.1.2白盒法,程序设计中遇到复合条件时，生成的流图变得更为复杂。当条件语句中用到一个或多个布尔运算符(逻辑OR，AND，NAND，NOR)时，就出现了复合条件。下图为语句IF a OR b中的每一个a和b创建了一个独立的结点，包含条件的结点被称为判定结点，从每一个判定结点发出两条或多条边。例如： 1 if a or b 2 x 3 else 4 y 对应的逻辑为：,4.1.2第二步：计算圈复杂度,圈复杂度是一种为程序逻辑复杂性提供定量测度的软件

47、度量，将该度量用于计算程序的基本的独立路径数目，为确保所有语句至少执行一次的测试数量的上界。独立路径必须包含一条在定义之前不曾用到的边。,4.1.2第二步：计算圈复杂度,有以下两种方法计算圈复杂度： 给定流图G的圈复杂度：V(G)，定义为V(G)=E-N+2，E是流图中边的数量，N是流图中结点的数量； 给定流图G的圈复杂度：V(G)，定义为V(G)=P+1，P是流图G中判定结点的数量。,4.1.2第二步：计算圈复杂度,对应上面图中的圈复杂度，计算如下： V(G)=10条边-8结点+2=4; V(G)=3个判定结点+1=4。,4.1.2第三步：导出测试用例,根据上面的计算方法，可得出四个独立的路

48、径： 路径1：4-14 路径2：4-6-7-14 路径3：4-6-8-10-13-4-14 路径4：4-6-8-11-13-4-14 根据上面的独立路径，去设计输入数据，使程序分别执行到上面四条路径。,4.1.2第四步：准备测试用例,为了确保基本路径集中的每一条路径的执行，根据判断结点给出的条件，选择适当的数据以保证某一条路径可以被测试到，满足上面例子基本路径集的测试用例是： 路径1：4-14 输入数据：iRecordNum0，或者取iRecordNum0的某一个值 预期结果：x0 路径2：4-6-7-14 输入数据：iRecordNum1,iType0 预期结果：x2,4.1.2第四步：准备

49、测试用例,路径3：4-6-8-10-13-4-14 输入数据：iRecordNum1,iType1 预期结果：x10 路径4：4-6-8-11-13-4-14 输入数据：iRecordNum1,iType2 预期结果：x20,4.1.2白盒法循环测试,循环测试是一种白盒测试技术，注重于循环构造的有效性。 有四种循环：简单循环,串接循环，嵌套循环和不规则循环。,4.1.2白盒法循环测试,简单循环： 下列测试集用于简单循环，其中n是允许通过循环的最大次数。 整个跳过循环； 只有一次通过循环； 两次通过循环； m次通过循环，其中mn； n-1，n,n+1次通过循环。,4.1.2白盒法循环测试,嵌套循

50、环： 如果将简单循环的测试方法用于嵌套循环，可能的测试数就会随嵌套层数成几何级增加，这会导致不实际的测试数目，下面是一种减少测试数的方法： 从最内层循环开始，将其它循环设置为最小值； 对最内层循环使用简单循环，而使外层循环的迭代参数（即循环计数）最小，并为范围外或排除的值增加其它测试； 由内向外构造下以个循环的测试，但其它的外层循环为最小值，并使其它的嵌套循环为“典型”值； 继续直到测试所有的循环。,4.1.2白盒法循环测试,串接循环： 如果串接循环的循环都彼此独立，可是使用嵌套的策略测试。但是如果两个循环串接起来，而第一个循环是第二个循环的初始值，则这两个循环并不是独立的。如果循环不独立，则

51、推荐使用的嵌套循环的方法进行测试。 不规则循环： 不能测试，尽量重新设计给结构化的程序结构后再进行测试。,4.1.3使用用例场景设计测试用例,用例场景是通过描述流经用例的路径来确定的过程，这个流经过程要从用例开始到结束遍历其中所有的基本流和备选流。,4.1.3使用用例场景设计测试用例,现在的软件都是由事件触发来控制流程的，事件触发时的情景便形成了场景。 将软件设计中的思想引入到软件测试中 最早由Rational公司提出,4.1.3使用用例场景设计测试用例,黑线：基本流 彩色线：备选流,4.1.3可能的场景,场景一：基本流 场景二：基本流 备选流1 场景三：基本流 备选流1 备选流2 场景四：基

52、本流 备选流3 场景五：基本流 备选流3 备选流1 场景六：基本流 备选流3 备选流1 备选流2 场景七：基本流 备选流4 场景八：基本流 备选流3 备选流4,4.1.3 ATM取款场景基本流,ATM处于就绪状态 1准备提款：客户将银行卡插入ATM 2验证卡： ATM读取卡信息 3输入PIN： ATM要求的PIN 4验证帐户和PIN：帐户和密码是否正确 5ATM选项： ATM显示本机上所有的选项,4.1.3 ATM取款场景基本流,6输入金额：要从ATM中提取的金额 7授权： ATM将帐户、密码和金额提交银行系统进行验证 8出钞：提供现金 9返回银行卡：银行卡被返回 10收据：打印凭单 ATM就

53、绪状态,4.1.3 ATM取款场景备选流,备选流1：银行卡无效 备选流2：ATM内没有现金 备选流3：ATM内现金不足 备选流4：PIN有误 备选流5：帐户不存在,4.1.3 ATM取款场景备选流,备选流6：帐面金额不足 备选流7：达到每日最大提款额 备选流8：记录错误 备选流9：退出 备选流10：暂停,4.1.3 ATM取款场景,场景1：成功提款 基本流 场景2：没有现金 基本流 备选流2 场景3：现金不足 基本流 备选流3 场景4：密码有误 基本流 备选流4 场景5：密码有误 基本流 备选流4 场景6：帐户不存在 基本流 备选流5 场景7：余额不足 基本流 备选流6 场景8：达到每日最大题

54、款数 基本流 备选流7,4.1.3测试用例,V:valid 有效; I:invalid无效; n/a: 不适用,4.1.3测试用例,4.1.4黑盒测试,等价分类法 边缘值分析法 因果图法 错误推测法,4.1.4黑盒测试,4.1.4等价类划分,被测试系统的输入和输出可以被分组或划分为相关的组或类 步骤：1.划分等价类 2.选择测试用例,4.1.4等价类划分实例,a=X1=d e=x2=g,4.1.4等价类划分-弱一般等价类,弱一般等价类测试通过使用一个测试用例中的每个等价类的一个变量实现 基于单缺陷假设 单缺陷假设：失效极少有两个（或多个）缺陷的同时发生引起的。,4.1.4等价类划分-弱一般等价

55、类,4.1.4等价类划分-强一般等价类,强一般等价类测试基于多缺陷假设，因此需要等价笛卡儿积的每个元素对应的测试用例 笛卡儿积可以保证两种意义上的完备性： 1、覆盖所有的等价类 2、可能的输入组合,4.1.4等价类划分-强一般等价类,4.1.4等价类划分-弱健壮等价类,健壮：考虑了无效值 弱：基于单缺陷假设,4.1.4等价类划分-弱健壮等价类,4.1.4等价类划分-强健壮等价类,健壮：考虑了无效值 强：基于多缺陷假设,4.1.4等价类划分-强健壮等价类,4.1.4测试用例实例,程序TRANLE输入三个整数，它们表示一个三角形的三条边长，该程序产生一个结果指出三角形是等腰三角形、等边三角形还是不

56、等边三角形,请利用15分钟进行测试用例设计,4.1.4测试用例实例（续）,合理的不等边三角形（输入数据为1、2、3或2、5、10等不能算这一类） 合理的等边三角形（输入数据为0、0、0不算） 合理的等腰三角形（输入数据为2、2、4等不能算这一类） 等腰三角形的三种排列次序(3，3，4;3，4，3;4，3，3),4.1.4测试用例实例（续）,三个正数，其中两个之和等于第三个 上一种情况的三种排列次序 三个正数，其中两个之和小于第三个 上一种情况的三种排列次序 输入数据含有零值 输入数据含有负数,4.1.4测试用例实例（续）,输入数据含有非整数值 三个数均为零 输入数据不是三个数 输入数据中有字符

57、,4.1.4功能测试等价类划分,划分等价类在很大程度上是试探性的，下面几点可供参考: 1）如果某个输入条件说明了输入值的范围，如“数据值”是从1到999，则可划分一个合理等价类：大于等于1而小于等于999的数和两个不合理等价类：小于1的数，以及大于999的数。,4.1.4功能测试等价类划分,2)如果某个输入条件说明了输入数据的个数,如每个学生可以选修1至3门课程，则可划分一个合理等价类：选修13门课程和两个不合理等价类：没选修课程，以及超过3门课程。,4.1.4功能测试等价类划分,3）如果一个输入条件说明了一个“必须成立”的情况，如标识符的第一个字符必须是字母，则可划分一个合理等价类：第一字符

58、是字母和一个不合理等价类第一字符不是字母。,4.1.4功能测试等价类划分,4）如果某个输入条件说明了输入数据的一组可能的值，而且认为程序是用不同的方式处理每一种值的，如职称的输入值可以是助教、讲师、副教授和教授4种，则可为每一种值划分一个合理等价类：助教、讲师、副教授和教授，并划分一个不合理等价类：上述4种职称之外的任意值。,4.1.4功能测试等价类划分,5）如果认为程序将按不同的方式来处理某个等价类中的各种测试用例，则应将这个等价类再分成几个更小的等价类。如上面第4）就是将一个合理等价类又分成助教、讲师等4个等价类。,4.1.4等价类实例三角形问题,R1=:等边三角形 R2=:等腰三角形 R

59、3=:不等边三角形 R4=:不构成三角形,4.1.4等价类划分实例,4.1.4功能测试等价类划分,1）为每个等价类编号。 2）设计一个新的测试用例，使它能包括尽可能多的尚未被包括的合理等价类;重复做这一步，直至这些测试用例已包含所有的合理等价类。 3）设计一个新的测试用例，使它包括一个(而且仅仅一个)尚未被包括的不合理等价类，重复做这一步，直至测试用例己包括所有的不合理等价类。,4.1.4功能测试等价类划分,考察一个把数字串转变成整数的函数。用二进制补码表示整数，机器字长16位，即整数范围最小为- 32768，最大为32767。函数及参数的说明如下： function StrToInt (dstr : shortstr) : integer; type shortstr = array 1.6 of char; 要求被