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

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

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

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

3、少错误损失培训,前言-课程由来,SQA：软件质量保证过程改进：预防错误规范化：流程文档化软件测试：发现错误错误发现的越早，解决的代价越小,前言-课程由来,SQA涉及的工作岗位过程改进工程师过程改进测试工程师软件测试开发工程师软件测试软件调试测试经理测试流程管理测试度量,前言-内容,课程的由来软件危机软件工程软件质量保证软件测试课程的介绍目标内容形式和要求参考书目,前言-课程介绍,目标学习质量保证的基本概念和理论学习软件测试的基本概念和理论掌握白盒测试/黑盒测试技术掌握单元测试/集成测试/系统测试技术掌握测试流程管理和测试度量技术掌握测试工具和测试流程管理工具了解测试相关工作的岗位要求和职业素质

4、要求了解测试行业的现状和技术发展趋势,前言-课程介绍,内容软件质量保证方法和软件测试概念开发工程师需要掌握的静态测试/白盒测试/黑盒测试技术、单元测试/集成测试要求测试度量方法测试工具职业素质要求,前言-课程介绍,内容测试工程师需要掌握的黑盒测试技术、集成测试/系统测试要求攻击式软件测试测试度量方法测试工具职业素质要求测试经理需要掌握的测试流程管理测试团队组织和测试度量测试流程管理工具和缺陷跟踪工具职业素质要求,前言-课程介绍,形式和要求学习前的要求：掌握软件工程基本概念掌握软件开发方法、高级程序设计语言和数据库相关知识了解Windows平台开发学习方式：课堂讲解上机实践（浪潮通软ERP或者自

5、己开发计算器程序）课堂讨论或者课堂练习 成绩评定方法：期末笔试占总成绩的60%实践和课堂讨论（课堂练习）占总成绩的40%,前言-课程介绍,参考书目软件测试基础Paul Ammann,Jeff Offutt，2010,机械工业出版社软件测试案例教程吕云翔，王洋等，2011，机械工业出版社实用软件测试指南马良荔，2003，电子工业出版社,前言-其他事宜,请班长留联系方式请留班级公共邮箱,17,第一章 软件质量保证,第一章 内容,1.1 软件质量1.2 软件质量保证：SQA1.2.1 SQA目标1.2.2 SQA模型1.2.2.1 ISO90011.2.2.2 CMMI1.3 SQA支持工具,1.1

6、 软件质量,什么是软件质量ANSI/IEEE Std 729-1983定义软件质量为“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”。M.J.Fisher 定义软件质量为“所有描述计算机软件优秀程度的特性的组合”。,1.1 软件质量,高质量的软件,能够按照预期的时间和成本提交给用户，并能够按照预期要求正确工作的软件ScopeTimeCost,1.1 软件质量,为什么提出软件质量软件质量不高是导致软件危机的根本原因进度延误、预算超支项目失败、项目终止软件质量高可以降低总成本软件维护成本高质量的软件可以降低维护成本，并延长软件的生命期，从而降低总成本软件失效成本高质量的软件可以降低

7、软件失效导致的成本损失，从而降低总成本,怎样提高软件质量目标优化软件开发过程减少软件中的bug方法防止在软件中引入错误 通过检测找出软件中的错误，并解决这种错误,1.1 软件质量,1.2 软件质量保证：SQA,什么是SQASoftware Quality Assurance是软件工程领域中的一部分为了确保软件开发过程和结果符合预期的要求，而建立的一系列规程和计划，以及依照规程和计划采取的一系列活动及其结果评价软件开发过程是按照计划和规范实施的软件开发结果包括完整的软件和文档，并且符合可预期的目标和检验标准,1.2.1 SQA目标,SQA总目标减少并纠正实际的软件开发过程和软件开发结果与预期的软

8、件开发过程和软件开发结果的不符合情况SQA方法通过在软件开发周期中尽可能早地预期或检测到不符合情况(错误)，来防止错误的发生，并减少错误纠正的成本错误发现得越早，造成的损失越小，修改的代价也越小,1.2.1 SQA目标,软件开发不同阶段：需求分析：Requirements Analysis 规格定义：Software Specifications设计：Design编码：Coding测试：Testing维护：Maintenance,1.2.1 SQA目标,需求分析：Requirements Analysis 确保客户提出的要求是可行的确保客户了解自己提出的需求的含义，并且这个需求能够真正达到他们

9、的目标确保开发人员和客户对于需求没有误解或者误会确保按照需求实现的软件系统能够满足客户提出的要求,1.2.1 SQA目标,规格定义：Software Specifications:确保规格定义能够完全符合、支持和覆盖前面描述的系统需求可以采用建立需求跟踪文档和需求实现矩阵的方式确保规格定义满足系统需求的性能、可维护性、灵活性的要求确保规格定义是可以测试的，并且建立了测试策略确保建立了可行的、包含评审活动的开发进度表确保建立了正式的变更控制流程,1.2.1 SQA目标,设计：Design:确保建立了设计的描述标准，并且按照该标准进行设计确保设计变更被正确的跟踪、控制、文档化确保按照计划进行设计评

10、审确保设计按照评审准则评审通过并被正式批准之前，没有开始正式编码,1.2.1 SQA目标,编码：Coding:确保建立了编码规范、文档格式标准，并且按照该标准进行编码确保代码被正确地测试和集成，代码的修改符合变更控制和版本控制流程确保按照计划的进度编写代码确保按照进化的进度进行代码评审,1.2.1 SQA目标,测试：Testing:确保建立了测试计划，并按照测试计划进行测试确保测试计划覆盖了所有的系统规格定义和系统需求确保经过测试和调试，软件仍旧符合系统规格和需求定义,1.2.1 SQA目标,维护：Maintenance:确保代码和文档同步更新，保持一致确保建立了变更控制流程和版本控制流程，并

11、按照这些流程管理维护过程中的产品变化确保代码的更改仍旧符合编码规范、通过代码评审，并且不会造成垃圾代码或冗余代码,1.2.2 SQA模型,质量管理历史质量就是产品、过程、系统符合标准要求的能力质量是生产出来的，不是检测出来的质量存在于全部直接/间接相关的环节中Deming(美国质量管理专家戴明博士)，日本的全面质量管理TQM预防为主第一次就把事情做好是最经济的质量管理的灵魂在于持续改进PDCA,1.2.2 SQA模型,软件质量管理相关标准和技术标准ISO9000族标准国际标准，ISO/TC176制订，适用于所有行业，其中9000-3针对软件开发行业SW-CMM/CMMI标准CMM:行业标准，C

12、MU-SEI制订和管理，针对软件开发行业CMMI:集成的CMMISO15504标准国际标准，试图结合ISO9000、CMM与软件工程概念项目管理技术项目：目标、起止时间、相关活动定义、计划、实施,1.2.2.1 ISO9001,ISO9000族标准一系列关于质量管理/质量保证/质量审核方面的国际标准，1983/1994/20009001/9002/9003/9004/9000-3是管理思想的精华，管理工作的指导原则，也是做事方式文档管理：写你要做的，做你所写的，记你所做的过程控制：PDCA-计划性及持续改进相关标准：QS9000等,1.2.2.1 ISO9001,原则原则1：以顾客为中心组织依

13、存于顾客。因此，组织应理解顾客当前和未来的需求，满足顾客要求并争取超越顾客期望原则2：领导作用领导将本组织的宗旨、方向和内部环境统一起来，并创造使员工能够充分参与实现组织目标的环境,1.2.2.1 ISO9001,原则原则3：全员参与各级人员是组织之本。只有他们的充分参与，才能使他们的才干为组织带来最大的收益原则4：过程方法将相关的资源和活动作为过程进行管理，重视输入和输出，可以更高效地得到期望的结果,1.2.2.1 ISO9001,原则原则5：管理的系统方法针对设定的目标，识别、理解并管理一个由相互关联的过程所组成的系统，有助于提高组织的有效性和效率原则6：持续改进持续改进是组织的一个永恒目

14、标,1.2.2.1 ISO9001,原则原则7：基于事实的决策方法对数据和信息的逻辑分析或直觉判断是有效决策的基础原则8：互利的供方关系通过互利的关系，增强组织及其供方创造价值的能力,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,在软件企业的实施案例,体系

15、支持规程管理评审规程 质量体系文件控制规程 内部质量体系审核规程 纠正措施规程 预防措施规程配置管理规程 质量记录控制规程,产品度量规程过程度量规程采购规程配套软件产品控制规程 培训规程档案管理规定合同评审规程软件质量保证规程产品开发规程,1.2.2.1 ISO9001,在软件企业的实施案例,ISO9001是品质保证标准，对过程管理提出最低要求质量保证体系根据软件工程原理自行设计和维持，满足ISO9001要求质量策划根据项目自身特点，对质量体系进行剪裁和补充,1.2.2.2 CMMI,CMMI：Capability Maturity Model Integration，即能力成熟度模型集成 来

16、源于：美国卡内基梅隆大学的软件工程研究所(SEI)创立的CMM(Capability Maturity Model 软件能力成熟度模型),1.2.2.2 CMMI,目标为提高组织过程和管理产品开发、发布和维护能力提供保障。帮助组织客观评价自身能力成熟度和过程域能力，为过程改进建立优先级以及执行过程改进。,1.3 SQA支持工具,SQA实施要素规范规程、模板、指南文档、记录人员分工、接口、培训、检查技术知识管理、工具,1.3 SQA支持工具,支持工具自行开发厂商提供IBM Rational,49,第二章 软件测试概述,内容,2.1 软件测试定义及术语2.2 错误与缺陷的分类2.3 软件测试的目标

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

18、的、外部的、不正确的行为,2.1相关术语,以看病为例解释上述术语：病人带着一些失败（症状）进入医生办公室，医生必须发现故障（症状的根源）。为了帮助诊断，医生制定一些测试来寻找异常的内部条件，比如高血压、心律不齐等，这些异常的内部条件相当于错误。,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 co

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

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

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

22、易传染 扩展到其他系统停机,2.4 软件测试的特征,软件测试具有一定的风险软件缺陷的寄生虫性软件测试的杀虫剂现象软件测试的不修复原则Pareto原则,2.4完全测试程序是不可能的,输入量太大输出结果太多软件实现途径太多软件说明书没有客观标准,2.4软件测试是有风险的行为,2.4软件缺陷的寄生虫性,找到的缺陷越多，说明软件存在的缺陷越多原因：程序员的疲倦 程序员往往犯同样的错误 某些软件缺陷可能是大灾难的征兆,2.4软件测试的杀虫剂现象,软件测试越多，其免疫力越强方案：编写新的测试用例 对程序的不同部分进行测试,2.4软件测试的不修复原则,并非所有的软件缺陷都需要修复原因：没有足够的时间，项目进

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

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

25、们不可能进行穷举测试，为了节省时间和资源、提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。,2.5测试用例设计人员,测试用例应由测试设计员或专职测试工程师来制定，而不是普通的测试执行人员；应该让最有能力的人员来完成用例的设计,2.5测试用例要素,编号：唯一编号前置条件：说明测试路径重要级别：对后期的测试用例执行的考核提供一个标准输入：输入的条件期望输出：期望输出的结果实际输出：实际输出的结果是否正确：是/否执行人：测试用例执行人标志执行时间：测试用例执行的时间备注：其他说明文字,2.5 练习一,有两个有故障的程序，每个包含了一个以失败为结果的测试

26、用例，确定程序中的故障。练习一,2.5测试用例编写,1、Word2、Excel3、系统管理（TestDirector、Bugzilla）,2.5 TestDirector,Mercury Interactive公司（2006年被HP以45亿美元收购）的测试管理工具,2.5 TestDirector-测试管理过程,需求定义（Specify Requirements）：分析应用程序并确定测试需求。测试计划（Plan Tests）：基于测试需求，建立测试计划。测试执行（Execute Tests）：创建测试集（Test Set）并执行测试。缺陷跟踪（Track Defects）：报告程序中产生的缺陷

27、并跟踪缺陷修复的全过程。贯穿测试的每一个阶段，你能够通过产生详细的报告和图标对数据进行分析。,2.5 TestDirector-需求定义,定义测试范围（Define Testing Scope）：检查应用程序文档，并确定测试范围测试目的、目标和策略。创建需求（Create Requirements）：创建需求树（Requirements Tree），并确定它涵盖所有的测试需求。描述需求（Detail Requirements）：为“需求树”中的每一个需求主题建立了一个详细的目录，并描述每一个需求，给它分配一个优先级，如有必要的话还可以加上附件。分析需求（Analyze Requirements

28、）：产生报告和图表来帮助你分析测试需求，并检查需求以确保它们在你的测试范围内。,TestDirector-需求定义,2.5 TestDirector-需求描述,优先级：Low,Medium,High,Very High,Urgent覆盖状态：no covered,passed,no completed,no run,failed,TestDirector-需求描述,2.5 TestDirector-测试计划,定义测试策略（Define Testing Strategy）：检查应用程序、系统环境和测试资源，并确认测试目标。定义测试主题（Define Test Subject）：将应用程序基于模块

29、和功能进行划分，并对应到各个测试单元或主题，构建测试计划树（Test Plan Tree）。定义测试（Define Tests）：定义每个模块的测试类型，并为每一个测试添加基本的说明。创建需求覆盖（Create Requirements Coverage）：将每一个测试与测试需求进行连接。,2.5 TestDirector-测试计划,设计测试步骤（Design Test Steps）：对于每一个测试，先决定其要进行的测试类型（手动测试和自动测试），若准备进行手动测试，需要为其在测试计划树上添加相应的测试步骤（Test Steps）。测试步骤描述测试的详细操作、检查点和每个测试的预期结果。自动测

30、试（Automate Tests）：对于要进行自动测试的部分，应该利用Mercury Interactive、自己或第三方的测试工具来创建测试脚本。分析测试计划（Analyze Test Plan）：产生报告和图表来帮助你分析测试计划数据，并检查所有测试以确保它们满足你的测试目标。,TestDirector-测试计划,TestDirector-建立测试覆盖,TestDirector-测试步骤,2.5 TestDirector-测试执行,创建测试集（Create Test Sets）：在你的工程中定义不同的测试组来达到各种不同的测试目标，他们可能包括，举个例子，在一个应用程序中测试一个新的应用版

31、本或是一个特殊的功能。并确定每个测试集都包括了哪些测试。确定进度表（Schedule Runs）：为测试执行制定时间表，并为测试员分配任务。运行测试（Run Tests）：自动或手动执行每一个测试集。分析测试结果（Analyze Test Results）：查看测试结果并确保应用程序缺陷已经被发现。生成的报告和图表可以帮助你分析这些结果。,TestDirector-建立测试集,TestDirector-加入测试集,2.5 TestDirector-缺陷跟踪,添加缺陷（Add Defects）：报告程序测试中发现的新的缺陷。在测试过程中的任何阶段，质量保证人员、开发者、项目经理和最终用户都能添加

32、缺陷。检查新缺陷（Review New Defects）：检查新的缺陷，并确定哪些缺陷应该被修复。修复打开的缺陷（Repair Open Defects）：修复那些你决定要修复的缺陷。测试新构建（Test New Build）：测试应用程序的新构建，重复上面的过程，直到缺陷被修复。分析缺陷数据（Analyze Defect Data）：产生报告和图表来帮助你分析缺陷修复过程，并帮助你决定什么时候发布该产品。,TestDirector-缺陷跟踪,TestDirector-添加缺陷,2.5 TestDirector-缺陷状态,New：测试人员新发现的缺陷open：经开发负责人检查后，确认是缺陷，将

33、其状态设置为openFixed：开发人员对于缺陷修复完毕后，将其状态置为fixedRejected：如果发现不是缺陷或者是重复缺陷，开发负责人将缺陷的状态置为rejectedClosed：对于状态是fixed或者是rejected的缺陷，可以关闭，closed是缺陷的最终状态Reopen：对于状态是fixed的缺陷，如果测试人员经过验证后，发现没有完全修复，将其状态置为reopen,TestDirector主页面,TestDirector创建项目,TestDirector-创建用户,TestDirector-登陆,2.5编写测试用例需要考虑的问题,1、测试用例的执行结果可以作为测试报告的一个附

34、件提交，从而提高测试报告的能够更准确的反映测试的进展2、通过对测试用例的执行情况的汇总、统计，可以得出系统目前所进行的测试工作是否充分、必要，是否已经达到了预期的效果，测试是否已经按计划完成等,115,第三章 测试人员的数学知识,3.1 集合论,集合定义：一组明确的、互不相同的事物组成的整体，称为一个集合。集合与成员：组成集合的各个事物称为该集合的元素。,3.1集合定义方式,全部列举：写出集合的所有元素部分列举：列举部分元素，其它元素用省略号代替规定集合的元素所满足的条件：A=x|x具有的性质P,3.1空集,空集是不包含任何元素的集合空集表示：和 是不同的 年|2012年1812,3.1维恩图

35、,维恩图是由两个或者两个以上重叠的圆组成的，用于表示集合之间的相互关系。集合的关系 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集合划分在测试中的应用,测试（1）完备性（2）无冗余性比如：三角形和非三角形 等边、等腰、不等边和非三角形 等边、等腰、不等边、直角和非三角形,3.2函数,任何程序都可以看成将其输出与输入关联起来的函数，因此函数是开发测试的核心概念。1对1函数/多对1函数程序实现的功能大

36、多数是多对一的函数，这对测试很重要（多对一测试可选代表等价类1对1 功能相似也可分等价类）,3.3概率论,测试中研究语句执行特定路径的概率事件的概率P(E)=E/Ss是有限样本空间，E是事件,3.4图论,有向图无向图定义：图G=(V,E)由结点的有限非空集V和结点无序对偶集E组成图通过关联矩阵表示图G=(V,E)的关联矩阵是mn矩阵,3.4图论,相邻矩阵 n1 n2 n3 n4 n5 n6 n7N1 0 1 0 1 0 0 0N2 1 0 0 0 1 0 0N3 0 0 0 1 0 0 0N4 1 0 1 0 0 1 0N5 0 1 0 0 0 0 0N6 0 0 0 1 0 0 0N7 0

37、0 0 0 0 0 0,3.4图论,路径结构化测试中用例路径是一系列的边或一系列的节点,3.4图论,有向图（框图）D=(V,E)一个节点有限集合V一个边的集合E有向图即可表示程序框图有向图相邻矩阵：有m个节点的有向图D=(V,E)的相邻矩阵是一个mm矩阵有向图的路径：有向图的路径是一系列的边，使得该序列中所有相邻对偶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

38、.4非功能测试技术4.5自动化非功能测试4.6非功能测试案例4.7GUI测试,4.1静态与动态测试,4.1功能测试,功能测试的基本方法是构造一些合理或者不合理的输入，检查输出是否与期望的相同。如果两者不一致，即表明功能有误。也有例外的情况，如需求规格说明书中的某个功能写错了，而实际上软件的功能却是正确的，这时要更改的是需求规格说明书。功能测试看起来比较简单，只要看得懂需求规格说明书，谁都会做。难点在于如何构造有效的输入。由于输入空间通常是无限的，穷举测试显然行不通。随便输入一些东西，碰运气也是行不通的,4.1功能测试,肯定测试：验证系统和它陈述的需求一致否定测试：证明一个系统不会作不需要它做的

39、事情,4.1录音机需求,状态：备用、打开、播放、停止在备用模式时，按打开按钮打开录音机当录音机打开时，按备用按钮回到备用模式当录音机打开时，按播放按钮开始播放当前磁带，按停止按钮停止播放,4.1肯定测试的用例,在备用模式时，按打开按钮打开录音机当录音机打开时，按备用按钮回到备用模式当录音机打开时，按播放按钮开始播放当前磁带，按停止按钮停止播放,4.1否定测试的用例,当录音机正在播放磁带时，按下备用按钮会怎样？按下打开按钮会怎样？当录音机打开并且没有磁带时，按下播放按钮会怎样？按下停止按钮会怎样？当录音机正在播放磁带时，断电。,4.1功能测试技术,白盒测试黑盒测试,4.1白盒测试和黑盒测试,白盒

40、测试：对于测试对象的内部内容是透明的、可见的，可以设计数据覆盖测试对象的每一条路经。黑盒测试：黑盒法不关心程序内部的逻辑，而只是根据程序的功能说明来设计测试用例,4.1.1白盒测试,4.1.1白盒测试,代码检查静态结构分析代码质量度量功能确认与接口分析逻辑覆盖率分析性能与效率分析内存分析,4.1.1白盒法-静态测试,代码检查静态结构分析,4.1.1白盒法代码检查,目的确保代码编程规范被有效执行检查代码是否存在逻辑上的错误,4.1.1白盒法代码检查,变量命名和类型检查变量初始值检查变量作用范围检查程序逻辑审查程序语法检查程序结构检查,4.1.1白盒法代码检查,排除违背程序编写标准的问题排除违背程

41、序编程风格的问题确保代码和设计的一致性确保代码的逻辑表达的正确性确保代码结构的合理性找出程序中不可移植的部分发现程序中不安全、不明确、模糊的部分实践表明，程序走查平均能查出被测程序的30%-70%的逻辑设计和代码缺陷，IBM代码走查能够检查出80%的错误,4.1.1白盒法代码检查,需求描述文档程序设计文档程序的源代码清单代码编码标准代码缺陷检查表,4.1.1 C/C+代码检查表,文件结构程序的版式命名规则表达式与基本语句常量函数设计内存管理C+函数的高级特性类的构造函数、析构函数类的高级特性其他特性,4.1.1文件结构,头文件和定义文件的名称是否合理头文件和定义文件的目录结构是否合理版权和版本

42、声明是否完整,4.1.1程序的版式,空行是否得体?代码行内的空格是否得体?长行拆分是否得体?“”和“”是否是否各占一行并且对齐于同一列一行代码是否只做一件事情?如只写一条语句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表达式与基本语句,如果代码行中的运算符比较多,是否已用括号清楚地确定表达式的运算顺序是否编写太复杂或

43、者多用途的复合表达式,4.1.2白盒法动态测试,void DoWork(int x,int y,int z)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程序执行的路径是

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

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

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

47、,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白盒法条件组合覆盖,上面的测试用例覆盖了所有条件的可能取值的组合，覆盖了所有判断的可取分支，但是却丢失了一条路径abe。,4.1.2白盒法路径测试,路径测试就是设计足够多的测试用例，覆盖

48、被测试对象中的所有可能路径。,4.1.2白盒法路径测试,上面的例子是一个很简单的程序函数，只有四条路径。但在实践中，一个不太复杂的程序，其路径都是一个庞大的数字，要在测试中覆盖所有的路径是不现实的。为了解决这一难题，只得把覆盖的路径数压缩到一定限度内，例如，程序中的循环体只执行一次。下面介绍的基本路径测试就是这样一种测试方法，它在程序控制图的基础上，通过分析控制构造的环行复杂性，导出基本可执行路径集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每一个可执行语句至少执行一次。,4.1.2白盒法路径测试,在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合

49、，从而设计测试用例。包括以下4个步骤,4.1.2白盒法路径测试,程序的控制流图：描述程序控制流的一种图示方法。程序圈复杂度：McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。导出测试用例：根据圈复杂度和程序结构设计用例数据输入和预期结果。准备测试用例：确保基本路径集中的每一条路径的执行。,4.1.2白盒法-控制流图的符号,在介绍基本路径方法之前，必须先介绍一种简单的控制流表示方法，即流图。流图使用下面的符号描述逻辑控制流，每一种结构化构成元素有一个相应的流图符号。,4.1.2白盒法,void S

50、ort(int iRecordNum,int iType)1 2 int x=0;3 int y=0;4 while(iRecordNum-0)5 6 if(0=iType)7x=y+2;8 else9 if(1=iType)10 x=y+10;11 else12 x=y+20;13 14,4.1.2第一步：画出控制流图,c/c+语句中的控制语句表示含义如下：图中的每一个圆称为流图的结点，代表一条或多条语句。流图中的箭头称为边或连接，代表控制流。,4.1.2白盒法,4.1.2白盒法,程序设计中遇到复合条件时，生成的流图变得更为复杂。当条件语句中用到一个或多个布尔运算符(逻辑OR，AND，NAN