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

《软件质量保证与测试工程硕士.ppt》由会员分享，可在线阅读，更多相关《软件质量保证与测试工程硕士.ppt（462页珍藏版）》请在三一文库上搜索。

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) & (c =b&c=d) /不良的版式,4.1.1表达式与基本语句,如果代码行中的运算符比较多,是否已用括号清楚地确定表达式的运算顺序 是否编写太复杂或者多用途的复合表达式,4.1.2白盒法动态测试,void DoWork(int x,int y,int z)

45、 int k=0,j=0; if(x3) /语句块3 ,4.1.2流程图,4.1.2白盒法,语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 条件组合覆盖 路径测试,4.1.2白盒法语句覆盖,语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次；,4.1.2白盒法语句覆盖,为了说明简略，分别对各个判断的取真、取假分支编号为a、b、c、d、e。 为了测试语句覆盖率只要设计一个测试用例就可以把三个执行语句块中的语句覆盖了。 测试用例输入为： x=4、y=5、z=5 程序执行的路径是：abd,该测试用例虽然覆盖了可执行语句，但并不能检查判断逻辑 是否有问题，例如在第

46、一个判断中把&错误的写成了|， 则上面的测试用例仍可以覆盖所有的执行语句。 可以说语句覆盖率是最弱的逻辑覆盖准则。,4.1.2白盒法判定覆盖,执行足够的测试用例，使得程序中每个判定至少都获得一次“真”值和“假”值，或者说使得程序中的每一个分支至少都通过一次。,4.1.2白盒法判定覆盖,对于上面的程序，如果设计两个测试用例则可以满足条件覆盖的要求。 测试用例的输入为： x=4、y=5、z=5 x=2、y=5、z=5,上面的两个测试用例虽然能够满足条件覆盖的要求， 但是也不能对判断条件进行检查，例如把第二个条件 y5错误的写成y5,、上面的测试用例同样满足了 分支覆盖。,4.1.2白盒法条件覆盖,

47、执行足够的测试用例，使得判定中的每个条件获得各种可能的结果。,4.1.2白盒法条件覆盖,对例子中的所有条件取值加以标记。例如： 对于第一个判断： 条件x3 取真值为T1，取假值为-T1 条件z5 取真值为T4，取假值为-T4,4.1.2白盒法条件覆盖,上面的测试用例不但覆盖了所有分支的真假两个分支，而且覆盖了判断中的所有条件的可能值。,4.1.2白盒法条件覆盖,但是如果设计了下面的测试用例，则虽然满足了条件覆盖，但只覆盖了第一个条件的取假分支和第二个条件的取真分支，不满足分支覆盖的要求。,4.1.2白盒法条件判定覆盖,执行足够的测试用例，使得判定中每个条件取到各种可能的值，并使每个判定得到各种

48、可能的结果。,4.1.2白盒法条件判定覆盖,根据定义只需设计以下两个测试用例便可以覆盖8个条件值以及4个判断分支。,4.1.2白盒法条件判定覆盖,分支条件覆盖从表面来看，它测试了所有条件的取值，但是实际上某些条件掩盖了另一些条件。例如对于条件表达式(x3)&(z3）为假则一般的编译器不在判断是否z5）来说，若x=4测试结果为真，就认为表达式的结果为真，这时不再检查（y5）条件了。因此，采用分支条件覆盖，逻辑表达式中的错误不一定能够查出来了。,4.1.2白盒法条件组合覆盖,执行足够的例子，使得每个判定中条件的各种可能组合都至少出现一次,4.1.2白盒法条件组合覆盖,x3,z3,z=10 记做T1 -T2， 第一个判断的取假分支 x=10 记做-T1 -T2，第一个判断的取假分支 x=4,y5 记做T3 T4， 第二个判断的取真分支 x=4,y5 记做-T3 T4， 第二个判断的取真分支 x!=4,y=5 记做-T3 -T4，第二个判断的取假分支,4.1.2白盒法条件组合覆盖,根据定义取4个测试用例，就可以覆盖上面8种条件取值的组合。测试用例如下表：,4.1.2白盒法条件组合覆盖,上面的测试用例覆盖了所有条件的可能取值的组合，覆盖了所有判断的可取分支，但是却丢失了一条路径