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

1,软件测试,内容,前言第一章软件质量保证第二章软件测试概述第三章测试人员的数学知识第四章软件测试技术第五章软件测试过程第六章软件测试管理体系,前言-内容,课程的由来软件危机软件工程软件质量保证软件测试课程的介绍目标内容形式和要求参考书目,前言-课程由来,软件危机(1960s)根源：硬件越来越复杂，功能越来越强大（摩尔定律）对软件在应用领域和规模上的期望越来越高软件的发展速度落后于硬件的发展速度真实世界与计算机世界的映射靠人来生产多人开发,前言-课程由来,软件危机(1960s)表现：软件质量不高、超出预算、项目延迟根源：软件系统复杂性提高、多人合作解决：软件工程与软件相关的人员项目组用户和股东计算机系统设计技术控制复杂：人的思维极限抽象/建模分解重用：质量和效率语言与开发包OO,前言-课程由来,软件工程目标：解决沟通和集成问题策略：控制错误错误缺陷/Bug/Defect/Error狭义：软件定义、设计、实现、打包/部署、使用过程中出现的与明确的需求不一致：不能正确完成任务、完成多余的任务广义：还包括：改善产品的建议；与用户隐含的需求不一致,前言-课程由来,软件工程方法：预防错误：规范化流程、职责、角色、模式：RUP(RationalUnifiedProcess)、CMM/CMMI、Pattern表达方式：UML、Pattern文档化迭代与体系结构纠正错误：测试调试减少错误损失培训,前言-课程由来,SQA：软件质量保证过程改进：预防错误规范化：流程文档化软件测试：发现错误错误发现的越早，解决的代价越小,前言-课程由来,SQA涉及的工作岗位过程改进工程师过程改进测试工程师软件测试开发工程师软件测试软件调试测试经理测试流程管理测试度量,前言-内容,课程的由来软件危机软件工程软件质量保证软件测试课程的介绍目标内容形式和要求参考书目,前言-课程介绍,目标学习质量保证的基本概念和理论学习软件测试的基本概念和理论掌握白盒测试/黑盒测试技术掌握单元测试/集成测试/系统测试技术掌握测试流程管理和测试度量技术掌握测试工具和测试流程管理工具了解测试相关工作的岗位要求和职业素质要求了解测试行业的现状和技术发展趋势,前言-课程介绍,内容软件质量保证方法和软件测试概念开发工程师需要掌握的静态测试/白盒测试/黑盒测试技术、单元测试/集成测试要求测试度量方法测试工具职业素质要求,前言-课程介绍,内容测试工程师需要掌握的黑盒测试技术、集成测试/系统测试要求攻击式软件测试测试度量方法测试工具职业素质要求测试经理需要掌握的测试流程管理测试团队组织和测试度量测试流程管理工具和缺陷跟踪工具职业素质要求,前言-课程介绍,形式和要求学习前的要求：掌握软件工程基本概念掌握软件开发方法、高级程序设计语言和数据库相关知识了解Windows平台开发学习方式：课堂讲解上机实践（浪潮通软ERP或者自己开发计算器程序）课堂讨论或者课堂练习成绩评定方法：期末笔试占总成绩的60%实践和课堂讨论（课堂练习）占总成绩的40%,前言-课程介绍,参考书目软件测试基础PaulAmmann,JeffOffutt，2010,机械工业出版社软件测试案例教程吕云翔，王洋等，2011，机械工业出版社实用软件测试指南马良荔，2003，电子工业出版社,前言-其他事宜,请班长留联系方式请留班级公共邮箱,17,第一章软件质量保证,第一章内容,1.1软件质量1.2软件质量保证：SQA1.2.1SQA目标1.2.2SQA模型1.2.2.1ISO90011.2.2.2CMMI1.3SQA支持工具,1.1软件质量,什么是软件质量ANSI/IEEEStd729-1983定义软件质量为“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”。M.J.Fisher定义软件质量为“所有描述计算机软件优秀程度的特性的组合”。,1.1软件质量,高质量的软件,能够按照预期的时间和成本提交给用户，并能够按照预期要求正确工作的软件ScopeTimeCost,1.1软件质量,为什么提出软件质量软件质量不高是导致软件危机的根本原因进度延误、预算超支项目失败、项目终止软件质量高可以降低总成本软件维护成本高质量的软件可以降低维护成本，并延长软件的生命期，从而降低总成本软件失效成本高质量的软件可以降低软件失效导致的成本损失，从而降低总成本,怎样提高软件质量目标优化软件开发过程减少软件中的bug方法防止在软件中引入错误通过检测找出软件中的错误，并解决这种错误,1.1软件质量,1.2软件质量保证：SQA,什么是SQASoftwareQualityAssurance是软件工程领域中的一部分为了确保软件开发过程和结果符合预期的要求，而建立的一系列规程和计划，以及依照规程和计划采取的一系列活动及其结果评价软件开发过程是按照计划和规范实施的软件开发结果包括完整的软件和文档，并且符合可预期的目标和检验标准,1.2.1SQA目标,SQA总目标减少并纠正实际的软件开发过程和软件开发结果与预期的软件开发过程和软件开发结果的不符合情况SQA方法通过在软件开发周期中尽可能早地预期或检测到不符合情况(错误)，来防止错误的发生，并减少错误纠正的成本错误发现得越早，造成的损失越小，修改的代价也越小,1.2.1SQA目标,软件开发不同阶段：需求分析：RequirementsAnalysis规格定义：SoftwareSpecifications设计：Design编码：Coding测试：Testing维护：Maintenance,1.2.1SQA目标,需求分析：RequirementsAnalysis确保客户提出的要求是可行的确保客户了解自己提出的需求的含义，并且这个需求能够真正达到他们的目标确保开发人员和客户对于需求没有误解或者误会确保按照需求实现的软件系统能够满足客户提出的要求,1.2.1SQA目标,规格定义：SoftwareSpecifications:确保规格定义能够完全符合、支持和覆盖前面描述的系统需求可以采用建立需求跟踪文档和需求实现矩阵的方式确保规格定义满足系统需求的性能、可维护性、灵活性的要求确保规格定义是可以测试的，并且建立了测试策略确保建立了可行的、包含评审活动的开发进度表确保建立了正式的变更控制流程,1.2.1SQA目标,设计：Design:确保建立了设计的描述标准，并且按照该标准进行设计确保设计变更被正确的跟踪、控制、文档化确保按照计划进行设计评审确保设计按照评审准则评审通过并被正式批准之前，没有开始正式编码,1.2.1SQA目标,编码：Coding:确保建立了编码规范、文档格式标准，并且按照该标准进行编码确保代码被正确地测试和集成，代码的修改符合变更控制和版本控制流程确保按照计划的进度编写代码确保按照进化的进度进行代码评审,1.2.1SQA目标,测试：Testing:确保建立了测试计划，并按照测试计划进行测试确保测试计划覆盖了所有的系统规格定义和系统需求确保经过测试和调试，软件仍旧符合系统规格和需求定义,1.2.1SQA目标,维护：Maintenance:确保代码和文档同步更新，保持一致确保建立了变更控制流程和版本控制流程，并按照这些流程管理维护过程中的产品变化确保代码的更改仍旧符合编码规范、通过代码评审，并且不会造成垃圾代码或冗余代码,1.2.2SQA模型,质量管理历史质量就是产品、过程、系统符合标准要求的能力质量是生产出来的，不是检测出来的质量存在于全部直接/间接相关的环节中Deming(美国质量管理专家戴明博士)，日本的全面质量管理TQM预防为主第一次就把事情做好是最经济的质量管理的灵魂在于持续改进PDCA,1.2.2SQA模型,软件质量管理相关标准和技术标准ISO9000族标准国际标准，ISO/TC176制订，适用于所有行业，其中9000-3针对软件开发行业SW-CMM/CMMI标准CMM:行业标准，CMU-SEI制订和管理，针对软件开发行业CMMI:集成的CMMISO15504标准国际标准，试图结合ISO9000、CMM与软件工程概念项目管理技术项目：目标、起止时间、相关活动定义、计划、实施,1.2.2.1ISO9001,ISO9000族标准一系列关于质量管理/质量保证/质量审核方面的国际标准，1983/1994/20009001/9002/9003/9004/9000-3是管理思想的精华，管理工作的指导原则，也是做事方式文档管理：写你要做的，做你所写的，记你所做的过程控制：PDCA-计划性及持续改进相关标准：QS9000等,1.2.2.1ISO9001,原则原则1：以顾客为中心组织依存于顾客。因此，组织应理解顾客当前和未来的需求，满足顾客要求并争取超越顾客期望原则2：领导作用领导将本组织的宗旨、方向和内部环境统一起来，并创造使员工能够充分参与实现组织目标的环境,1.2.2.1ISO9001,原则原则3：全员参与各级人员是组织之本。只有他们的充分参与，才能使他们的才干为组织带来最大的收益原则4：过程方法将相关的资源和活动作为过程进行管理，重视输入和输出，可以更高效地得到期望的结果,1.2.2.1ISO9001,原则原则5：管理的系统方法针对设定的目标，识别、理解并管理一个由相互关联的过程所组成的系统，有助于提高组织的有效性和效率原则6：持续改进持续改进是组织的一个永恒目标,1.2.2.1ISO9001,原则原则7：基于事实的决策方法对数据和信息的逻辑分析或直觉判断是有效决策的基础原则8：互利的供方关系通过互利的关系，增强组织及其供方创造价值的能力,1.2.2.1ISO9001,在软件企业的实施案例原则：运用项目管理技术重视质量策划重视培训和工具支持框架：质量手册、规程文件、作业指导书开发管理、体系支持,1.2.2.1ISO9001,在软件企业的实施案例角色分工,1.2.2.1ISO9001,在软件企业的实施案例产品开发规程,1.2.2.1ISO9001,在软件企业的实施案例定制项目开发规程,1.2.2.1ISO9001,在软件企业的实施案例,体系支持规程管理评审规程质量体系文件控制规程内部质量体系审核规程纠正措施规程预防措施规程配置管理规程质量记录控制规程,产品度量规程过程度量规程采购规程配套软件产品控制规程培训规程档案管理规定合同评审规程软件质量保证规程产品开发规程,1.2.2.1ISO9001,在软件企业的实施案例,ISO9001是品质保证标准，对过程管理提出最低要求质量保证体系根据软件工程原理自行设计和维持，满足ISO9001要求质量策划根据项目自身特点，对质量体系进行剪裁和补充,1.2.2.2CMMI,CMMI：CapabilityMaturityModelIntegration，即能力成熟度模型集成来源于：美国卡内基梅隆大学的软件工程研究所(SEI)创立的CMM(CapabilityMaturityModel软件能力成熟度模型),1.2.2.2CMMI,目标为提高组织过程和管理产品开发、发布和维护能力提供保障。帮助组织客观评价自身能力成熟度和过程域能力，为过程改进建立优先级以及执行过程改进。,1.3SQA支持工具,SQA实施要素规范规程、模板、指南文档、记录人员分工、接口、培训、检查技术知识管理、工具,1.3SQA支持工具,支持工具自行开发厂商提供IBMRational,49,第二章软件测试概述,内容,2.1软件测试定义及术语2.2错误与缺陷的分类2.3软件测试的目标2.4软件测试的特征2.5测试用例及管理工具,2.1什么是软件测试,软件测试是为了发现错误而执行一个程序或系统的过程,2.1软件测试的发展历史,20世纪50年代之前，没有系统的软件测试20世纪50年代-60年代，测试的重点是高级语言编写的系统，软件测试发展缓慢20世纪70年代以后，软件测试发展迅速，同时面临着危机现在，软件测试是一个基于软件开发整个生命周期的质量控制活动,2.1国内软件行业的现状,处于起步阶段软件评测中心的出现,2.1软件的生命周期,2.1相关术语,软件故障：软件中的静态缺陷软件错误：不正确的内部状态，该状态是某个故障的表现软件失败：与需求或者其他期望行为的描述有关的、外部的、不正确的行为,2.1相关术语,以看病为例解释上述术语：病人带着一些失败（症状）进入医生办公室，医生必须发现故障（症状的根源）。为了帮助诊断，医生制定一些测试来寻找异常的内部条件，比如高血压、心律不齐等，这些异常的内部条件相当于错误。,2.1相关术语,软件测试与医生诊疗有质的不同：软件中的故障是设计错误医疗问题与计算机硬件故障一样，经常是物理退化的结果,2.1相关术语,PublicstaticintnumZero(intx)/效果：统计x中0出现的次数intcount=0；for(inti=1;i=2000)/良好的版式If(year=2000)/不良的版式If(a=b)8else9if(1=iType)10 x=y+10;11else12x=y+20;1314,4.1.2第一步：画出控制流图,c/c+语句中的控制语句表示含义如下：图中的每一个圆称为流图的结点，代表一条或多条语句。流图中的箭头称为边或连接，代表控制流。,4.1.2白盒法,4.1.2白盒法,程序设计中遇到复合条件时，生成的流图变得更为复杂。当条件语句中用到一个或多个布尔运算符(逻辑OR，AND，NAND，NOR)时，就出现了复合条件。下图为语句IFaORb中的每一个a和b创建了一个独立的结点，包含条件的结点被称为判定结点，从每一个判定结点发出两条或多条边。例如：1ifaorb2x3else4y对应的逻辑为：,4.1.2第二步：计算圈复杂度,圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量，将该度量用于计算程序的基本的独立路径数目，为确保所有语句至少执行一次的测试数量的上界。独立路径必须包含一条在定义之前不曾用到的边。,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第三步：导出测试用例,根据上面的计算方法，可得出四个独立的路径：路径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第四步：准备测试用例,路径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白盒法循环测试,嵌套循环：如果将简单循环的测试方法用于嵌套循环，可能的测试数就会随嵌套层数成几何级增加，这会导致不实际的测试数目，下面是一种减少测试数的方法：从最内层循环开始，将其它循环设置为最小值；对最内层循环使用简单循环，而使外层循环的迭代参数（即循环计数）最小，并为范围外或排除的值增加其它测试；由内向外构造下以个循环的测试，但其它的外层循环为最小值，并使其它的嵌套循环为“典型”值；继续直到测试所有的循环。,4.1.2白盒法循环测试,串接循环：如果串接循环的循环都彼此独立，可是使用嵌套的策略测试。但是如果两个循环串接起来，而第一个循环是第二个循环的初始值，则这两个循环并不是独立的。如果循环不独立，则推荐使用的嵌套循环的方法进行测试。不规则循环：不能测试，尽量重新设计给结构化的程序结构后再进行测试。,4.1.3使用用例场景设计测试用例,用例场景是通过描述流经用例的路径来确定的过程，这个流经过程要从用例开始到结束遍历其中所有的基本流和备选流。,4.1.3使用用例场景设计测试用例,现在的软件都是由事件触发来控制流程的，事件触发时的情景便形成了场景。将软件设计中的思想引入到软件测试中最早由Rational公司提出,4.1.3使用用例场景设计测试用例,黑线：基本流彩色线：备选流,4.1.3可能的场景,场景一：基本流场景二：基本流备选流1场景三：基本流备选流1备选流2场景四：基本流备选流3场景五：基本流备选流3备选流1场景六：基本流备选流3备选流1备选流2场景七：基本流备选流4场景八：基本流备选流3备选流4,4.1.3ATM取款场景基本流,ATM处于就绪状态1准备提款：客户将银行卡插入ATM2验证卡：ATM读取卡信息3输入PIN：ATM要求的PIN4验证帐户和PIN：帐户和密码是否正确5ATM选项：ATM显示本机上所有的选项,4.1.3ATM取款场景基本流,6输入金额：要从ATM中提取的金额7授权：ATM将帐户、密码和金额提交银行系统进行验证8出钞：提供现金9返回银行卡：银行卡被返回10收据：打印凭单ATM就绪状态,4.1.3ATM取款场景备选流,备选流1：银行卡无效备选流2：ATM内没有现金备选流3：ATM内现金不足备选流4：PIN有误备选流5：帐户不存在,4.1.3ATM取款场景备选流,备选流6：帐面金额不足备选流7：达到每日最大提款额备选流8：记录错误备选流9：退出备选流10：暂停,4.1.3ATM取款场景,场景1：成功提款基本流场景2：没有现金基本流备选流2场景3：现金不足基本流备选流3场景4：密码有误基本流备选流4场景5：密码有误基本流备选流4场景6：帐户不存在基本流备选流5场景7：余额不足基本流备选流6场景8：达到每日最大题款数基本流备选流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=de=x21000100R=P=1N10=0N5=1N5=04N1=1N1=0,4.1.4边界值分析实例2,RR1,RR2,RR3表示应找的钱数R100R100P=50RR2=10RR3=5,4.1.4边界值分析实例2,输入输出条件组合出可能的情形:R100R1000R=100,PR0R=100,R=P=100,RR=500R=100,R=P=100,RR=490R=100,R=P=100,RR=10,4.1.4边界值分析实例2,0R=100,R=P=100,RR=90R=100,R=P=100,RR=50R=100,R=P=100,RR=40R=100,R=P=100,RR=10R=100,R=P=100,RR=0,4.1.4边界值分析实例2,1.货品价格=1012.货品价格=03.货品价格=-14.货品价格=100,付款金额=1015.货品价格=100,付款金额=996.货品价格=50,付款金额=1007.货品价格=51,付款金额=100,4.1.4边界值分析实例2,8.货品价格=90,付款金额=1009.货品价格=91,付款金额=10010.货品价格=95,付款金额=10011.货品价格=96,付款金额=10012.货品价格=99,付款金额=10013.货品价格=100,付款金额=100,4.1.4边界值分析实例2,见附件,4.1.4黑盒测试,NextDate函数是一个有三个变量的（年、月、日）的函数，函数返回输入日期后面的那个日期。Y:1812=年份=2012M：1=M=12D：1=D=31请用黑盒测试设计其测试用例,4.1.5因果图法,等价分类法和边界值分析法都没有考虑输入情况的各种组合，也没有考虑各个输入情况之间的相互制约关系因果图方法的思路：从用自然语言书写的需求规格说明书中找出因（输入条件）和果（输出或者程序状态的改变），通过因果图转换为判定表,4.1.5因果图法的几个步骤,分析需求规格说明书，找出原因和结果分析需求规格说明书中的语义内容，并将其表示成连接各个原因与各个结果的“因果图”对原因和结果的组合情况不可能出现的，在因果图上使用若干特殊符号表明约束条件,4.1.5因果图法的几个步骤（续）,把因果图转换成判定表把判定规则(每一列)转换成测试用例,4.1.5因果图的基本图形符号,在因果图中用Ci表示原因，Ei表示结果，各节点表示状态。,4.1.5因果图的基本图形符号说明,恒等：若原因出现，则结果出现；若原因不出现，则结果也不出现。非：若原因出现，则结果不出现；若原因不出现，则结果出现。或：若几个原因中有1个出现，则结果出现；若几个原因都不出现，则结果不出现。与：若几个原因都出现，结果才出现；若其中有1个原因不出现，则结果不出现。,4.1.5因果图的约束符号,4.1.5因果图的约束符号说明,异：表示几个原因不会同时成立，最多有一个成立或：多个原因中至少有一个必须成立唯一：表示各种原因中必须有一个，且仅有一个成立要求：表示当原因a出现时，b也必须出现。a出现时，不可能b不出现。强制：当a是1时，b必须是0；当a是0时，b必须是1,4.1.5因果图实例讲解,某软件规格说明中包含这样的要求：第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改。但如果第一列字符不正确，则给出信息L;如果第二列字符不是数字，则给出信息M。分开原因和结果原因：1-第一列字符是A;2-第一列字符是B;3-第二列字符是一数字。结果：21-修改文件;22-给出信息L;23-给出信息M。,4.1.5因果图实例讲解,4.1.5因果图实例讲解,有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下：若投入5角钱或1元钱的硬币，按下橙汁或啤酒的按钮，则相应的饮料就送出来.若售货机没有零钱找，则一个显示零钱找完的红灯亮，这时在投入1元硬币并按下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示零钱找完的红灯灭，在送出饮料的同时退还5角硬币。,4.1.5因果图实例讲解,(1)分析这一段说明，列出原因和结果原因:1.售货机有零钱找2.投入1元硬币3.投入5角硬币4.按下橙汁按钮5.按下啤酒按钮建立中间结点，表示处理中间状态11.投入1元硬币且按下饮料按钮12.按下橙汁或啤酒的按钮13.应当找5角零钱并且售货机有零钱找14.钱已付清,4.1.5因果图实例讲解,结果：21.售货机零钱找完灯亮22.退还1元硬币23.退还5角硬币24.送出橙汁饮料25.送出啤酒饮料(2)画出因果图。所有原因结点列在左边，所有结果结点列在右边。(3)由于2与3，4与5不能同时发生，分别加上约束条件E。(4)因果图,因果图,因果图,4.1.6侵入测试,出于测试的目的，侵入测试需要修改被测试系统及其行为这种修改均不能提交给最终用户谨慎使用,4.1.7错误猜测,有关被测试系统的知识，如设计方法和实现技术有关的早期测试阶段的结果的知识测试类似或相关系统的经验典型的实现错误的知识（被零除）通用的测试经验规则,4.2白盒测试的优缺点,优点：迫使测试人员考虑软件的实现可以检测代码中的每条分支和路径解释隐藏在代码中的错误对代码的测试比较彻底最优化,4.2白盒测试的优缺点,缺点：昂贵有遗漏的路径,4.2黑盒测试的优缺点,优点：效率高测试人员不需要了解细节测试人员和编程人员彼此独立从用户的角度进行测试需求完成后，马上可以设计测试用例,4.2黑盒测试的优缺点,缺点：只有少部分可能的输入被测到依赖于完整的需求文档丢失路径无法针对特定的程序,4.2测试用例设计方法选择的综合策略,在任何情况下必须使用边界值分析方法,经验表明,用这种方法设计出测试用例,发现程序错误的能力最强必要时用等价类划分方法补充测试用例用错误推测法追加测试用例如果程序的功能说明书中有输入条件的组合情况,考虑因果图法,4.3自动化功能测试,4.3自动化功能测试工具,Winrunner,4.3Winrunner,Winrunner是基于Windows平台的功能测试工具自动处理测试过程录制/回放,4.3Winrunner工作原理,当点击GUI时，WR将用类C的测试脚本语言（TSL）生成一个测试脚本测试人员可以修改脚本,4.3Winrunner测试过程,创建GUImap创建测试调试测试执行测试查看测试结果报告错误,4.3GUIMap,GUIMap用于保存GUI对象,4.3录制测试脚本,WR已录制的方式，快速建立自动测试脚本。,4.3撰写测试脚本,除了以录制的方式产生测试脚本之外，还可以使用函数产生器，在测试脚本中插入函数。,4.3建立数据驱动测试脚本,测试脚本建立完毕后，很有可能用多组不同的数据，去执行测试脚本。为了达到此目的，需要将测试脚本转换为数据驱动测试脚本。,4.3文字检查点,验证某个值是否在一定范围之内计算数值是否正确,4.4非功能测试,配置/安装测试安装/反安装测试的目的：避免“大风浪都挺过来了，却在阴沟里翻了船”目前市面上有非常流行的、专门制作安装/反安装程序的一些工具，如InstallShelled。制作安装/反安装程序不再是件难事，关键是不要麻痹大意。主要测试工作：（1）至少在标准配置和最低配置两种环境下测试；（2）如果有安装界面，应当尝试各种选项，如选择“全部”、“部分”、“升级”等。兼容性测试兼容性是指不同产品（或者新老产品）相互交换信息的能力。例如两个字处理软件的文件格式兼容，那么它们都可以操作对方的文件，这种能力对用户很有好处。兼容性的商业规则：弱者设法与强者兼容，否则无容身之地；强者应当避免被兼容，否则市场将被瓜分。文档和帮助测试这种测试是检查用户文档(如用户手册)的清晰性和精确性。,4.4非功能测试,健壮性测试健壮性是指在异常情况下，软件还能正常运行的能力。健壮性有两层含义：一是容错能力，二是恢复能力。容错性测试通常构造一些不合理的输入来引诱软件出错，例如：（1）输入错误的数据类型。如“猴”年“马”月。（2）输入定义域之外的数值。粗暴一些方式俗称“大猩猩”测试法。除了不能拳打脚踢嘴咬外，什么招术都可以使出来。例如在测试客户机服务器模式的软件时，把网络线拔掉，造成通信异常中断。恢复测试重点考察一下几项：（1）系统能否重新运行；（2）有无重要的数据丢失；（3）是否毁坏了其它相关的软件硬件。,4.4非功能测试,性能测试性能通常是指软件的“时间-空间”效率，而不仅是指软件的运行速度。人们总希望软件的运行速度高些，并且占用资源少些。既要马儿跑得快，又要马儿吃的少。有时人们关心测试的“绝对值”，如数据送输速率是每秒多少比特。有时人们关心测试的“相对值”，如某个软件比另一个软件快多少倍。在获取测试的“绝对值”时，我们要充分考虑并记录运行环境对测试的影响。例如网络环境、计算机主频，总线结构和外部设备都可能影响软件的运行速度。,4.4非功能测试,4.4非功能测试,性能测试性能优化的关键工作是找出限制性能的“瓶颈”，不要关注无关痛痒的地方。程序员可以通过优化数据结构、算法和代码(包括SQL)来提高软件的性能。算法复杂度分析是很好的方法，可以达到“未卜先知”的功效。,4.4非功能测试,性能测试性能优化就好像从海绵里挤水一样，你不挤，水就不出来，你越挤海绵越干。有些程序员认为现在的计算机不仅速度越来越高，而且内存越来越大，因此软件性能优化的必要性下降了。这种看法是不对的，殊不知随着机器的升级，软件系统也越来越庞大了和复杂了，性能优化仍然大有必要。,4.4非功能测试,性能测试的一些注意事项：不要试图让人拿着钟表去测时间，应当编写一段程序用于计算时间以及相关数据。应当测试软件在标准配置和最低配置下的性能。为了排除干扰，应当关闭那些消耗内存、占用CPU的其它应用软件（如杀毒软件）。不同的输入情况会得到不同的性能数据，应当分档记录。例如传输文件的容量从100K到1M可以分成若干等级。由于环境的波动，同一种输入情况在不同的时间可能得到不同的性能数据，可以取其平均值。,4.4非功能测试,可靠性测试可靠性是指在一定的环境下、在给定的时间内、系统不发生故障的概率。由于软件不像硬件那样可以“加速老化”，按此定义，软件可靠性测试可能会花费很长时间。比较实用的办法是，让用户使用该系统，记录每一次发生故障的时刻。计算出相邻故障的时间间隔，注意要去掉非工作时间。这样我们可以方便地统计出不发生故障的“最小时间间隔”、“最大时间间隔”和“平均时间间隔”。其中“平均时间间隔”会让人们大体了解到系统“可靠”的程度。,4.4非功能测试,安全性测试信息安全性（security）是指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。信息安全性测试有如下步骤：（1）为非法入侵设立目标，例如“盗窃某个文件”或“更改数据库记录”等。（2）邀请（或悬赏）一些人扮演黑客，让他们想尽办法入侵系统，实现“目标”。,4.4非功能测试,压力测试压力测试也叫负荷测试，即获取系统能正常运行的极限状态。了解“极限”是很有价值的，例如潜艇下潜极限深度。压力测试的主要任务是：构造正确的输入，使劲折腾系统却让它刚好不瘫痪。压力测试的一个变种是敏感测试。在某种情况下，微小的输入变动会导致系统的表现（如性能）发生急剧的变化。敏感测试目的是发现什么样的输入可能会引发不稳定现象。,4.4非功能测试,易用性测试易用性是指用户使用软件的容易程度。现代人的生活节奏快，干啥事都想图个方便。所以把易用性作为重要的质量属性对待无可非议。,4.5非功能自动化软件测试,LoadRunner,4.5LoadRunner,是一种预测系统行为和性能的工业标准负载测试工具通过模拟大量用户实时并发负载和实时性能监测的方式来确认和查找问题创建虚拟用户创建真实负载实施监测结果分析,4.5LoadRunner,4.5LoadRunner-虚拟用户,4.5创建运行场景,4.5LoadRunner-分析结果,4.6性能测试案例,三层结构的性能测试案例,4.7GUI测试,用户图形界面(GUI)开发环境有可复用构件，开发用户界面既省时又精确,4.7GUI测试,1.窗口窗口能否基于相关的输入或菜单命令适当的打开窗口能否改变大小、移动和滚动窗口中的数据能否用鼠标、功能键、方向箭头和键盘操作当被覆盖的窗口重新调用后，窗口能否正确再生,4.7GUI测试,1.窗口能否使用所有窗口的相关功能，所有相关功能是否可操作相关的下拉式菜单，工具条，滚动条，对话框，按钮，图标和其它控制有否？能否正常显示？完全可用？显示多窗口时，窗口名能否正确显示，活动窗口是否加亮,4.7GUI测试,1.窗口使用多用户时，所有窗口是否能实时更新多次或不正确按鼠标是否会产生无法预测的结果窗口的声音、颜色提示和窗口的操作顺序是否符合需求窗口能否正确关闭,4.7GUI测试,2.数据项字母、数据能否正确显示且输入系统图形方式数据项(如滚动条)是否正常工作数据输入、消失是否可以理解，能否识别非法数据,4.7GUI测试,3.下列式菜单和鼠标操作菜单条显示在合适语言环境中应用程序的菜单是否显示系统相关特性下拉式操作是否正确，功能是否正确菜单、调色板和工具条都是否能正常的工作能否列出所有菜单功能和下拉式功能,4.7GUI测试,3.下列式菜单和鼠标操作能否通过鼠标操作所有菜单的功能，通过文本命令激活每个菜单功能菜单功能随当前窗口操作加亮或变灰如果要求多次点击鼠标或鼠标有多个按钮时能否正确识别光标、处理指示器和识别指针能否随操作而适当改变,4.7优秀的用户界面具有的要素,符合标准和规范直观性一致性灵活性舒适性正确性实用性,4.7符合标准和规范,如果软件在windows等现有平台上运行，标准是已经确立的平台可能没有标准，也许测试的就是平台本身。在这种情况下，设计小组可能成为标准的创立者,4.7Windows界面标准中三种级别信息,4.7直观性,用户界面是否洁净、不唐突、不拥挤？UI不应该为用户制造障碍，所需功能或者期待的响应应该明显，并在预期出现的地方UI的组织和布局合理吗？是否允许用户轻松地从一个功能转到另一个功能？下一步作什么明显吗？任何时候都可以决定放弃或者回退、退出吗？输入得到承认了吗？菜单或者窗口是否深藏不露？有多余的功能吗？软件整体或者局部是否做得太多？是否有太多特性把工作复杂化了？是否感到信息太庞杂？如果其他所有努力失败，帮助信息真的能帮忙吗？,4.7一致性,快捷键和惨淡选项，在windows中，按“F1”键总是得到帮助信息术语和命令。整个软件使用同样的术语吗？特性命名一致吗？例如Find是否一直叫Find，而不是有时叫Search受众。软件是否一直面向同一受众级别？带有花哨的用户界面的贺卡程序不应该显示在泄露技术机密的错误提示信息中按钮位置和等价的按钮。对话框中有ok按钮和cancel按钮时，ok按钮总是在上方或左方，cancel按钮总是在右方或下方。cancel按钮的等价按钮是Esc,而OK按钮的等价按钮是Enter。,4.7Windows记事本和写字板,4.7灵活性,状态终止和跳过。当软件具有用户非常熟悉的超级用户模式时，应该能够跳过众多提示或者窗口，直接到达想取得地方。数据输入和输出。用户希望有多种输入数据和查看结果。为了在记事本中插入文字，可以用键盘输入、粘贴、作为对象插入或者用户鼠标从其他程序拖动。,4.7Windws计算器的两种选择,4.7舒适性,恰当。软件外观和感觉应该与所做的工作和使用者相符。金融商业应用不应该使用选丽的色彩和音效来表示狂放的风格。错误处理库。程序应该在用户执行严重错误的操作之前提出警告，并且允许用户恢复由于错误操作导致丢失的数据。性能。快不见得是好事。程序的错误提示信息不应该一闪而过。如果操作缓慢，至少应该像用户反馈操作持续时间，并显示它正在工作，没有停止。,4.7Windows的进度条,4.7正确性,市场定位偏差。有没有多余的或者遗漏的功能，或者某些功能执行了与市场宣传材料不符的操作。语言和拼写。不良媒体。媒体是软件UI包含的所有支持图标、图像、声音和视频。图标应该同样大，并且具有相同的调色板。声音应该都有相同的格式。正确的媒体从UI选择是应该显示出来。所见即所得。保证UI所说的就是实际所得的。单击保存按钮时，显示器上的文档与存入磁盘中的完全一样吗？从磁盘读出时，与原文档相同吗？,4.7实用性,软件的具体特性是否实用,4.7辅助选项测试,视力损伤听力损伤运动损伤认知和语言障碍,322,第五章测试过程,测试过程,5.1单元测试5.2集成测试5.3系统测试5.4系统集成测试5.5验收测试5.6回归测试5.7企业测试策略,5.1单元测试,目标：确保产生符合需求的可靠的程序单元由开发人员完成白盒测试活动,5.1单元测试覆盖的区域,单元执行的计算/操作的正确性低级性能问题低级可靠性问题窗口的内容及导航，包括窗口的外观的一致性、热键、功能键和快捷键,5.1单元测试覆盖的区域,报告的内容、布局和计算文件/记录的创建、更新及删除互操作单元间的通信,5.1单元的定义,单元的定义与被测试系统的设计方法，以及在开发过程中采用的实现技术有关：使用过程化程序语言开发的应用中的单元可以用一个函数或过程表示使用面向对象编程语言开发的应用中的单元可以用一个类表示,5.1单元的定义（续）,可视化编程环境下的单元可以是一个窗口，或者是这个窗口中相关元素的集合基于组件开发环境中的单元可以是一个预先定义的可重用的组件,5.1单元测试任务,任务1、模块接口测试检查进出模块的数据是否正确Checklist：模块的实际输入与定义的输入是否一致个数、类型、顺序模块中对于非内部/局部变量是否合理使用使用其他模块时，是否检查可用性和处理结果使用外部资源时，是否检查可用性并及时释放资源内存、文件、硬盘、端口等其他,5.1单元测试任务,任务2、模块局部数据结构测试检查局部数据结构能否保持完整性Checklist：变量从来没有被使用可能别的地方使用了错误的变量名变量没有初始化错误的类型转换数组越界非法指针变量或函数名称拼写错误使用了外部变量或函数其他,5.1单元测试任务,任务3、模块边界条件测试检查临界数据是否正确处理Checklist：普通合法数据是否正确处理普通非法数据是否正确处理边界内最接近边界的(合法)数据是否正确处理边界外最接近边界的(非法)数据是否正确处理其他,5.1单元测试任务,任务4、模块独立执行通路(路径)测试检查由于计算错误、判定错误、控制流错误导致的程序错误Checklist：死代码错误的计算优先级精度错误比较运算错误赋值错误表达式的不正确符号循环变量的使用错误错误赋值其他,5.1单元测试任务,任务5、模块内部错误处理测试检查内部错误处理设施是否有效Checklist：是否检查错误出现资源使用前后其他模块使用前后出现错误，是否进行错误处理抛出错误通知用户进行记录错误处理是否有效在系统干预前处理报告和记录的错误真实详细其他,5.1单元测试方法,确定如何调用某个给定单元以及每次调用该单元的响应确定单元的状态和状态间转换确定单元的每个状态的预期结果，以及确认这些结果所必须的内容,5.1单元测试方法（续）,考察被测试系统的需求规格说明文档以及被测试的单元，确认以前的步骤已识别出了所有可能的测试条件，如有必要可以增加附件条件确定测试该单元的先决条件使用上述信息生成一套测试该单元的测试用例,5.1单元测试的数据需求,不使用真实数据需要少量数据时，可以考虑可以使用边界分析或等价类划分方法，设计模拟数据需要大量数据时，可以使用真实数据的拷贝（对于敏感数据应适当处理），或者使用真实数据的有代表性的样本,5.1单元测试输入,被测试系统的需求规格文档被测试系统的设计文档补充材料（如用户手册）单元测试计划单元测试规范说明文档单元测试指南单元测试用例空白的测试记录表格,5.1单元测试测试技术,针对被测单元需求的功能测试静态测试白盒测试状态转换测试性能测试,5.1单元测试输出,完整的被测试过的单元单元测试证书修正的测试用例归档的测试数据完成的测试结果记录表格,5.1单元测试输出（续）,单元测试日志单元测试重用包简短的单元测试总结报告,5.1单元测试过程,5.1单元测试停止标准,单元测试用例设计已经通过评审按照单元测试计划完成了所有规定单元的测试达到了测试计划中关于单元测试所规定的覆盖率的要求被测试的单元每千行代码必须发现至少3个错误软件单元功能与设计一致在单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准,5.2集成测试-概述,进行系统测试之前证明组成被测试系统的各个模块以正确、稳定、一致的方式接口和交互。由开发组/测试组完成黑盒技术,5.2集成测试覆盖的区域,从其它互操作模块调用一个模块在互操作模块间正确传输数据兼容性性能问题,5.2执行集成测试遵循的方法,识别组成一个完整系统的模块间的关系评审模块间的交互和通信需求，识别出模块间的接口使用上述信息产生一套测试该模块的测试用例当依次将模块加入到扩充的系统中，并测试新合并的系统时，应采用增量测试,5.2集成测试-数据需求,不使用真实数据使用测试辅助程序模拟数据访问,5.2集成测试-输入,被测试系统的需求规格文档被测试系统的设计文档补充材料（如用户手册）集成测试计划单元测试规范说明文档集成测试指南集成测试用例空白的测试记录表格,5.2集成测试-技术,黑盒测试性能测试,5.2集成测试-输出,完整的被测试过和集成过的模块集成测试证明修正的测试用例归档的测试数据完成的测试结果记录表格集成测试日志集成测试报告,5.2集成测试过程,5.2集成测试停止标准,集成测试用例设计已经通过评审按照集成构建计划及增量集成策略完成了整个系统的集成测试达到了测试计划中关于集成测试所规定的覆盖率的要求被测试的集成工作版本每千行代码必须发现2个错误集成工作版本满足设计定义的各项功能、性能要求在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准,5.3系统测试-概述,测试系统的功能和结构的稳定性测试性能和可靠性等非功能性需求黑盒技术测试人员完成,5.3系统测试-方法,评审系统需求，找出以下内容：高级业务需求真实系统的数据处理和事务率需求系统性能需求备份和恢复需求保密性需求,5.3系统测试-方法（续）,识别被测试系统与其他系统通信的需求及通信手段考察将要运行真实系统的计算机环境，以便找出该系统与其它系统的互操作性或兼容性问题检查对测试系统过程、系统文档、帮助设施以及恢复、备份和归档的需求使用上述信息，生成测试用例,5.3系统测试-数据,使用真实数据,5.3系统测试-角色和职责,测试组组长：保证在质量控制和监督下，使用合适的测试技术执行充分的系统测试测试分析员：设计和实现用于被测试系统测试的测试用例测试员：执行测试用例独立测试观察员：监控测试过程,5.3系统测试计划和资源,一个合适的具体测试环境的可用性对真实环境的商业或安全要求的估计以及系统测试对它产生不利影响的可能性真实环境中商业或机密的敏感数据或保密性重要信息的出现,5.3系统测试输入,被测试系统的需求规格文档被测试系统的设计文档补充材料（如用户手册）系统测试计划系统测试规范说明文档系统测试指南系统测试用例空白的测试记录表格,5.3系统测试测试技术,针对高级系统需求的黑盒测试针对被测试系统的该机业务需求的线索测试非功能测试（容量、压力、性能）静态测试（评审系统文档）使用自动化测试工具,5.3系统测试输出,完整的被测试系统系统测试证明修正的测试用例归档的测试数据完成的测试结果记录表格系统测试日志系统测试报告,5.3系统测试过程,5.3系统测试停止标准,系统测试用例设计已经通过评审按照系统测试计划完成了系统测试达到了测试计划中关于系统测试所规定的覆盖率的要求被测试的系统每千行代码必须发现1个错误系统满足需求规格说明书的要求在系统测试中发现的错误已经得到修改，各级缺陷修复率达到标准,5.4系统集成测试概述,目标：确保被测试系统可以与其他制定的软件系统成功进行互操作（不对其他系统产生不利的影响，也不被其他系统影响）黑盒技术测试人员进行,5.4系统集成测试方法,审查系统的互操作性需求，并确认以下要求：1.被测试系统与其他系统通信的需求和通信的手段2.涉及与其他系统通信的