软件测试与软件质量朱蔚恒.ppt

软件测试与软件质量,朱蔚恒 09.秋,第一章：测试概述,第一章：测试概述,1.1 软件测试1.2 测试用例1.3 文氏图理解测试1.4 功能性测试与结构性测试1.5 测试级别与过程,1.1.1一些著名的软件错误,迪斯尼狮子王 9495Intel 奔腾浮点除法缺陷 1994美国航天局火星极地登陆者 1999爱国者导弹防御系统 1991千年虫 1974危险的预见 19942004,近年的比较出名的软件错误,In February of 2009 users of a major search engine site were prevented from clicking through to sites listed in search results for part of a day A large health insurance company was reportedly banned by regulators from selling certain types of insurance policies in January of 2009 due to ongoing computer system problems that resulted in denial of coverage for needed medications and mistaken overcharging or cancelation of benefits A news report in January 2009 indicated that a major IT and management consulting company was still battling years of problems in implementing its own internal accounting systems,including a 2005 implementation that reportedly was attempted without adequate testing.In August of 2008 it was reported that more than 600 U.S.airline flights were significantly delayed due to a software glitch in the U.S.FAA air traffic control system.The problem was claimed to be a packet switch that failed due to a database mismatch,and occurred in the part of the system that handles required flight plans.,1.1.2软件缺陷是什么,软件未实现产品说明书要求的功能软件出现了产品说明书指明不应该出现的错误软件出现了产品说明书未提到的功能软件未实现产品说明书虽未明确提及但应该实现的目标软件难以理解、不易使用、运行缓慢或者从测试人员的角度看最终用户会认为不好,为什么会出现软件缺陷,沟通软件的复杂性编程错误需求变更时间压力Egos(自私的,自我的)没有文档软件工具自身的错误,软件缺陷的产生原因,软件缺陷的积累和放大效应,软件缺陷的积累和放大效应,软件缺陷的修复费用,Financial Implications of Improved Testing,NIST estimates that billions of dollars could be saved each year if improvements were made to the testing process.*NIST Report:The Economic Impact of Inadequate Infrastructure for Software Testing,2002.,Estimated Cost of Inadequate Testing,*NIST Report:The Economic Impact of Inadequate Infrastructure for Software Testing,2002.,软件测试的意义,软件错误可以避免吗?在软件开发的一系列阶段和步骤中,出现错误的时机很多:软件需求的描述可能有错和不完善；软件的设计可能有错；软件的编码可能有错；为了发现软件缺陷,软件测试必不可少。,软件测试的意义（续）,其开销在软件开发过程总成本中占很大比例。据Boehm的统计，这个数值可达30%50%。是保障软件质量和可靠性的重要手段。是软件质量度量的重要依据。,1.1.3基本定义,错误(error)，缺陷(fault)，bug，defect失效(failure)事故(incident)测试(test)测试用例(test case),FailureA failure is said to occur whenever the external behavior does not conform to system spec.ErrorAn error is a state of the system which,in the absence of any corrective action,could lead to a failure.FaultAn adjudged cause of an error.,Fault,Error,Failure,It is there in the program,Program state,Observed,fault,bug,error,defect,error/fault/bug:something wrong in softwarefailure:manifestation of an error(observable in software behaviour)something wrong in software behaviour(deviates from requirements),错误与缺陷分类,缺陷分类的方法：以出现相应错误的开发阶段来划分；以相应失效产生的后果来划分；以解决难度来划分；以不解决会产生的风险来划分；,根据严重程度分类的缺陷,1.轻微 词语拼写错误2.中等 误导或重复信息3.使人不悦 被截断的名称4.影响使用 有些交易没有处理5.严重 丢失交易6.非常严重 不正确的交易处理7.极为严重 经常出现“非常严重”的错误8.无法忍受 数据库破坏9.灾难性 系统停机10.容易传染 扩展到其它系统的系统停机,软件测试定义（I）,“The process of devising a set of inputs to a given piece of software that will cause the software to exercise some portion of its code.The developer of the software can then check that the results produced by the software are in accord with his or her expectations.”,软件测试定义（II）,“Software testing is a process used to identify the correctness,completeness and quality of developed computer software.Actually,testing can never establish the correctness of computer software,as this can only be done by formal verification(and only when there is no mistake in the formal verification process).It can only find defects,not prove that there are none.”,软件测试定义（III）,*是为了发现错误而执行程序的过程。GJMyers 广义上讲，在软件开发过程中的所有评审、确认、检验等活动都是软件测试。*是使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。(IEEE),Beizer:1st law:(Pesticide paradox)Every method you use to prevent or find bugs leaves a residue of subtler bugs,for which other methods are needed2nd law:Software complexity grows to the limits of our ability to manage it,1.1.4 软件生命周期,需求分析设计(System and Object)实施测试Testing phase集成Integration phase维护Maintenance phaseRetirement,Software Lifecycle Activities,SystemDesign,ObjectDesign,Implemen-tation,Testing,RequirementsElicitation,Analysis,.and their models,A Testing Cycle,Although testing varies between organizations,there is a cycle to testing:Requirements Analysis:Testing should begin in the requirements phase of the software life cycle(SDLC).Design Analysis:During the design phase,testers work with developers in determining what aspects of a design are testable and under what parameter those testers work.Test Planning:Test Strategy,Test Plan(s),Test Bed creation.Test Development:Test Procedures,Test Scenarios,Test Cases,Test Scripts to use in testing software.Test Execution:Testers execute the software based on the plans and tests and report any errors found to the development team.Test Reporting:Once testing is completed,testers generate metrics and make final reports on their test effort and whether or not the software tested is ready for release.Retesting the Defects,Concept map of the testing process,一个测试生命周期,设计,编码,缺陷隔离,缺陷分类,测试,需求规格说明,缺陷解决,错误,错误,错误,错误,修复,缺陷,缺陷,缺陷,事故,一些测试的目标,尽可能多的找出软件的缺陷尽早找出重要的错误对潜在的质量风险评估.对潜在的项目风险建议.对潜在的质量建议.验证是否符合某一指定的标准.评估各阶段产品的一致性(requirements,design,or product claims).,软件测试的对象,需求分析概要设计详细设计编码上述各个阶段的文档的测试，而不仅仅是源程序的测试。,测试调试,发现错误,测 试,调 试,确定错误性质、位置并修改,测试与调试是一个交叉循环的过程,测试调试（续）,测试是一种检验；调试是推理过程。测试的结果常常表明一个程序员的失败；调试则是程序员证明其正确。测试经常由非程序设计者完成；调试必须有程序员完成。大多数测试在不了解设计细节的条件下完成；而调试必须了解程序的细节。测试可以并应该计划、设计和制定工作日程表；调试的规程和持续的时间不受约束。在能做什么和不能做什么方面，测试有一套完整的理论；而调试没有。很多测试的设计和执行能够自动化；而调试则不行。,软件测试的特征,软件测试的风险性软件测试的不修复原则软件测试的群集现象(Pareto原则)软件缺陷的寄生虫性,软件测试是有风险的行为,原因:输入量太大输出结果太多软件运行的路径太多软件说明书没有客观标准 如果决定不去测试所有的情况，那就是选择了风险。,彻底测试程序是不可能的,软件测试的不修复原则,并非所有软件缺陷都需要修复,原因：没有足够的时间不算真正的软件缺陷修复的风险太大不值得修复,软件测试的群集现象(Pareto原则),测试发现的错误中的80%很可能起源于程序模块中的20%。,例如:IBM OS/370操作系统中，47%的错误仅与该系统中的4%的程序模块有关。软件缺陷的寄生虫性：找到的软件缺陷越多，就表明残存的软件缺陷越多原因：程序员的疲倦；程序员往往犯同样的错误,第一章：测试概述,1.1 软件测试1.2 测试用例1.3 文氏图理解测试1.4 功能性测试与结构性测试1.5 测试级别与过程,1.2 测试用例,如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。,软件测试是有组织性、步骤性和计划性的，而设计软件测试用例的目的，就是为了能将软件测试的行为转换为可管理的模式。软件测试是软件质量管理中最实际的行动，同时也是耗时最多的一项。基于时间因素的考虑，软件测试行为必须能够加以量化，才能进一步让管理阶层掌握所需要的测试过程，而测试用例就是将测试行为具体量化的方法之一。,1.2 测试用例,测试用例ID：目的：前提：输入：预期输出：后果执行历史日期 结果 版本 执行人,测试用例设计生成的基本准则,测试用例的代表性：能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等;测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果；测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。,测试用例的特征,最有可能抓住错误的；不是重复的、多余的；一组相似测试用例中最有效的；不要太简单，也不要太复杂。,测试用例的组织和跟踪,在执行测试过程中，会遇到如下问题：计划执行哪些测试用例？执行需要多少时间？一轮测试需要多少测试人员？能否挑出测试套装（相关测试用例子集）来测试某些特性或软件部分？在执行测试用例时，能否记录哪些通过？哪些失败；当前测试是否按计划进行？上次执行测试用例时通过的百分比是多少？测试用例跟踪管理方式：测试用例追踪表,测试用例的意义,使用测试用例的好处主要体现在以下几个方面：在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。测试用例的使用令软件测试的实施重点突出、目的明确。,测试用例的意义,在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。,测试用例的意义,组织性有利于测试的组织；功能覆盖确保功能不被遗漏；重复性有利于测试的重复；跟踪有利于测试的跟踪；测试确认在少数高风险的测试中，必须证明确实执行了计划执行的测试；,第一章：测试概述,1.1 软件测试1.2 测试用例1.3 文氏图理解测试1.4 功能性测试与结构性测试1.5 测试级别与过程,1.3 文氏图所描述的行为和所实现的程序行为,s,p,已描述已实现和经过测试的行为,S,P,T,5,7,4,1,3,2,6,8,测试技术,不实际运行程序，而是通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术。也称为静态分析技术。,实际运行程序，并通过观察程序运行的实际结果来发现错误的软件测试技术。,在不知道程序内部结构，只知道程序规格的情况下采用的测试技术或策略。,在知道程序内部结构的情况下采用的测试技术或策略。,开发组内部进行的，采用讲解、讨论和模拟运行的方式进行的查找错误的活动。,开发组内部进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告。,开发组、测试组和相关人员(QA、产品经理等)联合进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告。,测试技术,针对要求的程序功能，按照规范的流程进行的测试。,针对要求的程序功能以外的其他要求，包括性能、安全、配置、负载等指标，按照规范的流程进行的测试。,针对要求的程序功能、性能、安全、配置、负载等指标，基于破坏目的、按照经验进行的随机测试。,程序修改或者版本更新以后，为了确保以前正确的功能和其他指标仍旧正确，而重新进行的测试。,在测试过程中，选择足够的测试用例，使得每一个可执行语句至少被执行一次。,在测试过程中，选择足够的测试用例，使得程序中的每一个分支判断的每一种可能结果都至少被执行一次。,在测试过程中，选择足够的测试用例，使得程序中的每一条可能执行的路径都至少执行一次。,第一章：测试概述,1.1 软件测试1.2 测试用例1.3 文氏图理解测试1.4 功能性测试与结构性测试1.5 测试级别与过程,1.4 功能性测试与结构性测试,功能性测试将系统看成黑盒优点：（1）与软件实现无关，即使实现发生修改测试用例仍然有用（2）测试用例开发可以与实现并行进行，压缩开发时间结构性测试将系统看成白盒 测试人员能根据功能实际实现的方式来标识测试用例,黑盒测试,黑盒测试方法是在程序接口上进行测试，主要是为了发现以下错误:1.是否有不正确或遗漏了的功能?2.在接口上，输入能否正确地接受?能否输出正确的结果?3.是否有数据结构错误或外部信息(例如数据文件)访问错误?4.性能上是否能够满足要求?5.是否有初始化或终止性错误?,黑盒测试,用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出。但这是不可能的。,黑盒测试举例,假设一个程序P有输入量X和Y及输出量Z。在字长为32位的计算机上运行。若X、Y取整数，按黑盒方法进行穷举测试：可能采用的 测试数据组：232232264 如果测试一组数据需要1毫秒，一年工作36524小时，完成所有测试需5亿年。,白盒测试,软件人员使用白盒测试方法，主要想对程序模块进行如下的检查：对程序模块的所有独立的执行路径至少测试一次；对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次；在循环的边界和运行界限内执行循环体；测试内部数据结构的有效性。对一个具有多重选择和循环嵌套的程序，不同的路径数目可能是天文数字。,功能性测试用例标识方法比较,结构性测试用例标识方法比较,功能性测试与结构性测试比较,这种工具自20世纪70年代以来一直浪费测试人员的时间他不支持好的测试实践，应该从测试人员的工具包中剔除poston 1991如果达到85%或者更好的水平，分支覆盖率找出缺陷，一般是靠“直觉”测试找出缺陷的两倍Miller 1991,功能性测试与结构性测试比较(二),两种方法都不完善 如果所有的描述行为都未实现，那么结构性测试不能检测，反过来如果程序中实现了没被描述的行为，如恶意的代码，功能性测试不能发现,功能性（黑盒）确定置信度,结构性（白盒）查找缺陷,第一章：测试概述,1.1 软件测试1.2 测试用例1.3 文氏图理解测试1.4 功能性测试与结构性测试1.5 测试级别与过程,1.5 测试级别与过程,概要设计,详细设计,编码,系统测试,集成测试,单元测试,用户需求,回归测试,配置管理,缺陷跟踪,软件测试的级别,单元测试,验收测试,系统测试,集成测试,单元测试,单元测试,被测模块,被测模块,被测模块,已集成的软件,已确认的软件,可交付的软件,概要设计信息,系统其它元素,软件需求,详细设计信息,已经测试过的模块,用户参与,单元测试,单元测试时对软件基本组成单元进行的测试，这里的基本单元不一定是指一个具体的函数或一个类的方法。单元具有一些基本属性，如：明确的功能、规格定义，与其他部分明确的接口定义等，可以清晰地与同一程序的其他部分单元划分开来。,Unit:component(module,function,class,objects,),单元测试的目的,验证代码是与设计相符合的；跟踪需求和设计的实现；发现设计和需求中存在的错误；发现在编码过程中引入的错误。,单元测试,Objective:Find differences between specified units and their imps.,Unit:component(module,function,class,objects,),Unit test environment:,Unit undertest,Stub,Stub,Driver,Test cases,Test result,Dummy modules,Effectiveness?PartitioningCode coverage,对单元测试的错误认识,单元测试浪费了太多的时间；单元测试仅仅是证明这些代码做了什么；很棒的编程人员的工作不需要单元测试；不管怎样，集成测试将会抓住所有的bug；单元测试的成本效率不高。,集成测试,目标:发现集成中出现的问题To quickly obtain a working solution from components.问题区间内部:控件之间调用:call/message passing/参数:type,number,order,value调用返回:identity(who?),type,sequence外部:中断(wrong handler?)I/O timing交互,集成测试,集成的类别结构化大爆炸 no error localization自底向上:terminal,driver/module,(driver module)自顶向下:top,stubs,(stub module),early demo行为(next slide),集成测试(行为:基于路径),A,B,C,MM-路径:Interleaved sequence of module exec path and messages,Module exec path:entry-exit path in the same module,Atomic System Function:port input,MM-paths,port output,Test cases:exercise ASFs,系统测试,Concerns with the apps externalsMuch more than functionalLoad/stress testingUsability testingPerformance testingResource testing,系统测试,功能测试目标:评估系统是否能完成它应该完成的工作Basis:Behavioral/functional specificationTest case:A sequence of ASFs(thread),系统测试,功能测试覆盖率基于事件的覆盖率PI1:each port input event occursPI2:common sequences of port input event occursPI3:each port input in every relevant data contextPI4:for a given context,all possible input eventsPO1:each port output eventPO2:each port output event occurs for each cause基于数据的覆盖率DM1:Exercise cardinality of every relationshipDM2:Exercise(functional)dependencies among relationships,系统测试,压力测试:push it to its limit+beyond,Application(System),:,Users,rate,Volume,Resources:phy.+logical,response,性能测试Performance seen byusers:delay,throughputSystem owner:memory,CPU,commPerformanceExplicitly specified or expected to do wellUnspecified find the limit可用性测试Human element in system operationGUI,messages,reports,系统测试,小结,1.1 软件测试1.2 测试用例1.3 文氏图理解测试1.4 功能性测试与结构性测试1.5 测试级别与过程,