1、1,1,软件测试综述,2,2,软件测试综述,软件测试是一个必不可少的活动，是对软件需求分析、设计规约和编码的最终复审；是软件质量保证的关键步骤。软件测试是根据软件开发各阶段的规约和软件的内部结构，精心设计一批测试用例（包括输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现软件中不符合质量特性要求（即缺陷或错误）的过程。,3,3,软件测试综述,软件测试的背景软件测试概述软件测试的模型,4,4,软件测试的背景,软件错误和软件失效的案例软件缺陷是什么软件缺陷分类软件缺陷的产生软件缺陷修复的代价软件可靠性问题软件错误数估算,5,5,软件错误和软件失效的案例,火星登陆事故 1999年12
2、月3日，缺少集成测试爱国者导弹防御系统, 1991，多哈，死亡28人，缺少稳定性测试英特尔奔腾芯片缺陷，1994，对待缺陷的态度（41958353145727）31457274195835美迪斯尼公司的狮子王游戏软件bug 1994年圣诞节前，缺少兼容性测试记事本 联通,软件错误概述,软件错误和软件失效,“错误”术语“错误”这一术语。在没有特别加以说明的情况下，这是一个泛用的、模糊的概念。它指的可能是bug(差错)、 fault(故障)、error(错误)、failure(失效)、crash(重大事故)、problem(疑问)等。在汉译中，这些术语的使用更加混乱。,7,7,软件缺陷是什么？,软
3、件出错机理可描述为:软件错误，软件缺陷，软件故障，软件失效。 软件错误(error) ：是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。软件缺陷(bug) ：是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。软件故障(fault) ：是指软件运行过程中出现的一种不希望或不可接受的内部状态。此时若无适当措施（容错）加以及时处理，便产生软件失效。软件失效(failure) ：是指软件运行时产生的一种不希望或不可接受的外部行为结果。,软件错误概述,8,8,软件缺陷激活条件,符合下列五种情况
4、之一就可认为是软件缺陷（出错）：1）软件未达到软件产品需求说明书指明的要求。 2）软件出现了软件产品需求说明书指明不会出现的错误。 3）软件功能超出软件产品需求说明书指明的范围。 4）软件未达到软件产品需求说明书虽未指明但应达到的要求。5）软件测试人员认为难以理解、不易使用、运行速度缓慢、或者最终用户认为不好的问题。 软件缺陷的特征“看不到” 软件的特殊性决定了缺陷不易看到“看到但是抓不到” 发现了缺陷，但不易找到问题发生的原因所在,软件错误概述,9,9,软件缺陷分类,可从不同角度对软件缺陷进行分类： 按错误的影响和后果分类 按错误的性质和范围分类 按软件生存期阶段分类,软件错误概述,10,1
5、0,软件错误分类-按错误的影响和后果分类,按错误的影响和后果分类 较小错误：只对系统输出有一些非实质性影响。如，输出的数据格式不合要求等。中等错误：对系统的运行有局部影响。如输出的某些数据有错误或出现冗余。较严重错误：系统的行为因错误的干扰而出现明显不合情理的现象。如开出了0.00元的支票，系统的输出完全不可信赖。严重错误：系统运行不可跟踪，一时不能掌握其规律，时好时坏。非常严重的错误：系统运行中突然停机，其原因不明，无法软启动。最严重的错误：系统运行导致环境破坏，或是造成事故，引起生命、财产的损失。,软件错误概述,11,11,软件错误分类-按错误的性质和范围分类,按错误的性质和范围分类 B.
6、Beizer从软件测试观点出发，把软件错误分为5类。1.功能错误1）规格说明错：规格说明可能不完全，有二义性或自身矛盾。2）功能错误：程序实现的功能与用户要求的不一致。这常常是由于规格说明中包含错误的功能、多余的功能或遗漏的功能所致。3）测试错误：测试的设计与实施发生错误。软件测试自身也可能发生错误。4）测试标准引起的错误：对软件测试的标准要选择适当，若测试标准太复杂，则导致测试过程出错的可能就大。,软件错误概述,12,12,软件错误分类-按错误的性质和范围分类,2.系统错误1）外部接口错误：外部接口指如终端、打印机、通信线路等系统与外部环境通信的手段。2）内部接口错误：内部接口指程序之间的联
7、系。3）硬件结构错误 ：不能正确理解硬件如何工作而导致的出错。4）操作系统错误：主要是由于不了解操作系统的工作机制而导致出错。当然，操作系统本身也有错误。5）软件结构错误：由于软件结构不合理或不清晰引起的错误。6）控制与顺序错误：如存在不正确的处理步骤等。7）资源管理错误：由于不正确使用资源而产生的。,软件错误概述,13,13,软件错误分类-按错误的性质和范围分类,3.加工错误1）算术与操作错误：指在算术运算、函数求值和一般操作过程中发生的错误。2）初始化错误：如，忘记初始化工作区、寄存器和数据区；对循环控制变量赋错初值；用不正确的格式，数据或类型进行初始化等。3）控制和次序错误：与系统级同名
8、错误类似，但它是局部错误。如遗漏路径；不可达到的代码等；4）静态逻辑错误：主要包括：不正确地使用CASE语句；在表达式中使用不正确的条件（例如用“”代替“”的否定）；对情况不适当地分解与组合；混淆“或”与“异或”等。,软件错误概述,14,14,软件错误分类-按错误的性质和范围分类,4.数据错误1）动态数据错误 ：动态数据是在程序执行过程中暂存的数据。2）静态数据错误：静态数据直接或间接地出现在程序或数据库中，在内容和格式上都固定。一般由预处理出错造成。3）数据内容错误：由内容被破坏或被错误地解释而造成的错。4）数据结构错误：数据结构错误主要包括结构说明错误及把一个数据结构误当做另一类数据结构使
9、用的错误。5）数据属性错误：如错把整数当实数，允许不同类型数据混合运算而导致的错误等。,软件错误概述,15,15,软件错误分类-按错误的性质和范围分类,5.代码错误主要包括：语法错误；打字错误；对语句或指令不正确理解所产生的错误。,软件错误概述,16,16,软件错误分类-按软件生存期阶段分类,把软件的逻辑错误按生存期不同阶段分为4类。1.问题定义（需求分析）错误在软件定义阶段，分析员研究用户的要求后所编写文档中出现的错误。换句话说，这类错误是由于问题定义不满足用户的要求而导致的错误。,软件错误概述,17,17,软件错误分类-按软件生存期阶段分类,2.规格说明错误这类错误是指规格说明与问题定义不
10、一致所产生的错误。它们又可以细分成：1）不一致性错误：规格说明中功能说明与问题定义发生矛盾。2）冗余性错误：规格说明中某些功能说明与问题定义相比是多余的。3）不完整性错误：规格说明中缺少某些必要的功能说明。4）不可行错误：规格说明中有些功能要求是不可行的。5）不可测试错误：有些功能的测试要求是不现实的。,软件错误概述,18,18,软件错误分类-按软件生存期阶段分类,3.设计错误设计阶段产生的错误，它使系统的设计与需求规格说明中的功能说明不相符。它们又可以细分为：1）设计不完全错误：某些功能没有被设计，或设计得不完全。2） 算法错误：算法选择不合适。主要表现为算法的基本功能不满足功能要求、算法不
11、可行或者算法的效率不符合要求。3） 模块接口错误 ：模块结构不合理 ；模块与外部数据库的界面不一致，模块之间的界面不一致。4） 控制逻辑错误 ：控制流程与规格说明不一致 ；控制结构不合理。5） 数据结构错误：数据设计不合理；与算法不匹配；数据结构不满足规格说明要求。,软件错误概述,19,19,软件错误分类-按软件生存期阶段分类,4.编码错误多种多样 ，大体归为以下几种 ：数据说明错、数据使用错、计算错、比较错、控制流错、界面错、输入输出错，及其它的错误。在不同的开发阶段，错误的类型和表现形式不同，故应采用不同的方法和策略来进行检测。,软件错误概述,20,20,软件缺陷的产生,软件缺陷的产生比较
12、容易造成软件缺陷的主要因素,归纳如下:技术问题算法错误、语法错误、计算和精度问题、系统结构不合理、接口参数不匹配。团队工作需求不清、开发人员相互理解不一致、设计或编程上的假定或依赖性没得到充分沟通。软件本身文档错误、大数据量错误、边界错误、时序错误、数据恢复能力没有或不够、软硬件上的错误、软件开发标准或过程上的错误。,软件错误概述,21,21,软件缺陷的构成,软件错误产生的原因分布,软件错误概述,22,22,软件缺陷的产生,软件需求说明书为什么是软件缺陷存在最多的地方，主要原因有：用户的计算机知识较少要开发产品的特性不够清晰需求变化的不一致对需求说明书不重视项目组成员间缺少沟通,软件错误概述,
13、23,23,软件缺陷的产生,软件缺陷的状态为便于跟踪和管理某产品的缺陷，可以定义不同的软件缺陷状态:激活状态(Active或Open)：问题还没解决，测试员报的bug、或验证后bug仍然存在。已修正状态(Fixed或Resolved)：开发人员针对缺陷，修改程序，认为已解决问题，或通过单元测试。关闭或非激活状态(Close或Inactiv)：测试员验证Fixed bug后，确认bug已改的状态。Hold状态：第三方产品引起的、或是无法解决的bug。Differed状态：不需解决或准备在下版中解决的bug。,软件错误概述,24,24,软件错误修复的代价,软件在从计划、编制、测试、一直到交付用户公
14、开使用的过程中，都有可能产生和发现错误。随着整个开发过程的时间推移，修复软件的费用呈几何级数的增长。下图是软件错误在不同阶段发现时修改的费用示意图,软件错误概述,25,25,软件可靠性问题,软件可靠性定义IEEE将软件可靠性定义为：在给定时间间隔内和特定的环境下，软件按规格说明成功运行的概率。给定的时间间隔：在定义中，一般采用“运行时间” t 作为时间的尺度。环境条件：指的是软件的使用环境。无论是什么软件，如果不对它的使用环境加以限制，都会失效。这种失效的数据，不能用来度量软件的可靠性。成功地运行：指不仅程序能正确运行，满足用户对它的功能要求， 而且当程序一旦受到意外的伤害，或系统故障时，能尽
15、快恢复，仍能正常地运行。,软件错误概述,软件可靠性问题,软件可靠性的主要指标借用硬件可靠性的定量度量方法来度量软件的可靠性： MTBF:平均故障间隔时间 MTTF:平均故障时间,26,MTTF,n,i=1,n,1,t,i,t1，t2, ., tn:失效时间,27,27,软件可靠性问题,因软件设计故障与因计算机硬件设计故障而引发的系统 失效的比例大约是：10:1 运行软件的驻留故障密度（每千行代码的故障数目）： 要求很高的关键财务或财产软件为：每千行代码 110个故障 关键的生命软件为：每千行代码0.011个故障 软件可靠性是对软件在设计、开发以及所预定的环境下具有能力的置信度的一个度量，是衡量
16、软件质量的主要参数之一。软件测试则是保证软件质量、提高软件可靠性的最重要手段。,软件错误概述,软件错误数估算,植入故障法估算（ 捕获再捕获抽样法）利用植入故障法估算程序中原有故障总数ET设Ns 是在测试前人为地向程序中植入的故障数(称播种故障)，ns 是经过一段时间测试后发现的播种故障的数目，n 是在测试中又发现的程序原有故障数。设测试用例发现植入故障和原有故障的能力相同，则程序中原有故障总数 N ( =ET )估算值为,28,软件错误数估算,Hyman分别测试法由两个测试员同时互相独立测试同一程序的两个副本，用 t 表示测试时间，记 t0时，程序中原有故障总数是 B0；tt1 时，测试员甲发
17、现的故障总数是 B1；测试员乙发现的故障总数是 B2；其中两人发现的相同故障数目是 bc；两人发现的不同故障数目是 bi。在大程序测试时，开始两个测试员测试的结果应当比较接近，bi 不是很大。这时有,29,软件错误数估算,Hyman分别测试法（续）如果bi很大，应当每隔一段时间，由两个测试员再分别测试，分析测试结果，估算B0。如果bi减小，或几次估算值的结果相差不多，则B0作为原有错误总数的估算值。,30,31,31,软件测试概述,软件测试的发展软件测试的定义软件测试的重要性 软件测试的分类软件测试的目的和原则软件测试活动软件测试技术概要软件测试误区测试员应有的素质,32,32,软件测试的发展
18、,软件测试发展史上的几个重要事件1972年6月，首次软件测试会议1972年6月，Bill Hetzel（代表论著The Complete Guide to Software Testing）在美国的北卡罗来纳（North Carolina）大学组织了首次以软件测试为主题的会议。1973年， Bill Hetzel定义软件测试概念就是建立一种信心，认为程序能够按预期的设想运行。1983年，Bill Hetzel将定义修订为：评价一个程序和系统的特性或能力，并确定它是否达到预期的结果。软件测试就是以此为目的的任何行为。他还把软件的质量定义为“符合要求”。,软件测试的发展,33,33,软件测试的发展
19、,软件测试发展史上的几个重要事件（续）1979年，Glenford Myers：The Art of Software Testing出版。这本书是软件测试方面的圣经。Myers定义及诠释的测试方法论已成为软件测试的基本模块。提出测试的目的是证伪。1983、1990年，IEEE/ANSI标准定义软件测试概念1990年的IEEE/ANSI标准将软件测试进行了这样的定义：在既定的状况条件下，运行一个系统或组建，观察记录结果，并对其某些方面进行评价的过程。这里所谓“既定的状况”可理解为需求或设计。,软件测试的发展,34,34,软件测试的发展,软件测试发展史上的几个重要事件（续）1996年提出：测试能
20、力成熟度TCMM（Testing Capability Maturity Model）、测试支持度TSM（Testing Support Model）、测试成熟度（Testing Maturity Model）。,软件测试的发展,35,35,软件测试的发展,软件测试发展趋势测试与质量保证体系的融合测试方法越来越细分测试方法的细分，如网站测试、安全性测试等；测试技术不断发展软件验证技术方面软件静态测试方面测试用例的选择方面自动化测试方面测试走向专业化道路,软件测试的发展,36,36,软件测试的定义,一般定义IEEE的定义Myers的定义广义定义相关术语,软件测试的定义,37,37,一般软件测试的
21、定义,定义1：1983年，IEEE提出的软件工程标准术语中给软件测试下的定义：软件测试是使用人工的或自动的手段来运行或检测某个系统的过程, 其目的在于检验它是否满足约定的需求或是比较预期结果与实际结果之间的差别。1990年的IEEE/ANSI标准将软件测试进行了这样的定义： (IEEE/ANSI, 1990 Std 610.12-1990)就是在既定的状况条件下，运行一个系统或组建，观察记录结果，并对其某些方面进行评价的过程。(这里所谓“既定的状况”也可理解为需求或设计)这一定义非常明确地提出了软件测试以检验是否满足需求为目标。,软件测试的定义,38,38,一般软件测试的定义,定义2：Glen
22、ford J.Myers在其1979年软件测试技巧（“The Art of Software Testing”）一书中对软件测试的定义是：软件测试是为了发现错误而运行程序的过程。这一定义明确指出软件测试的目的是“发现错误”。,软件测试的定义,39,39,广义软件测试的定义,广义的软件测试是由确认、验证、测试3方面组成。确认：评估将要开发的软件产品是否“正确无误”、可行和有价值的。确认意味着确保一个开发软件是“正确无误的”，是对软件开发构想的检测。验证：检测软件开发的每个阶段、每个步骤的结果是否“正确无误”，是否与软件开发各阶段的要求或期望的结果相一致。验证意味着确保软件会“正确无误”地实现软件
23、的需求，开发过程是沿着正确的方向进行的。测试：与狭隘的测试概念统一。,软件测试的定义,40,40,软件测试的定义 -相关术语,测试用例所谓测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果；测试用例是执行测试的最小实体。测试步骤测试步骤详细规定了如何设置、执行、评估特定的测试用例。精确和准确准确是指得到的测试结果与真实值之间的接近程度。精确是指同样环境下重复测测试所得到的结果之间的重现性。确认和验证确认是保证软件符合产品说明书的过程。验证是保证软件满足用户要求的过程。,软件测试的定义,41,41,软件测试的对象,软件测试的对象软件测试并不等于程序测试。软件测试应该贯穿整个软件定义
24、与开发整个期间。因此需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应该是软件测试的对象。,软件测试的定义,42,42,软件测试的对象,软件测试的定义,43,43,软件测试的对象,上图中，在对需求理解与表达的正确性、设计与表达的正确性、实现的正确性以及运行的正确性的验证中，任何一个环节发生了问题都可能在软件测试中表现出来。,软件测试的定义,44,44,软件测试的重要性,软件错误不可避免由于人的思维局限性，再加上开发的系统具有的复杂性，因此决定了在开发过程中出现软件错误是不可避免的。软件错误并不一定是由编码所引起的，
25、很可能是详细设计，概要设计阶段，甚至于是需求分析阶段的问题引起的。 若能及早排除开发中的错误，就可排除给后期工作带来的麻烦，降低出错代价。 软件测试应无处不在,45,45,软件测试的分类,按测试过程 （开发阶段）单元测试：又称模块测试，是针对软件设计的最小单位程序模块进行正确性检验的测试工作。集成测试：又称组装测试，是将模块按照设计要求组装起来进行测试，主要目标是发现与接口有关的问题。确认测试：验证软件的功能和性能及其它特性是否与用户的要求一致。系统测试：是在集成测试通过后进行，目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求。 验收测试：用户为主，开发人员参与，以规格说明书为
26、蓝本的测试。,46,46,软件测试的分类,47,47,软件测试的分类,按测试用例设计方法白盒测试也称结构测试或逻辑驱动测试。它是从程序的控制结构出发进行的测试，测试程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。黑盒测试又称功能测试、数据驱动测试或基于规格说明书的测试，是一种从用户观点出发的测试，在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。灰盒测试是介于白盒测试与黑盒测试之间的测试，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。,48,48,软件测试的分类,按
27、实施对象：Alpha测试（企业内部测试）：是由用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试。 Beta测试（最终用户测试）：是软件的多个用户在实际使用环境下进行的测试。 第三方测试（独立测试）,49,49,软件测试的分类,按执行方式人工测试：手工执行的测试；自动化测试：希望能够通过自动化测试工具或其他手段,按照测试工程师的预定计划进行自动的测试。如：负载测试、性能测试、可靠性测试等。,50,软件测试的分类,按测试方式划分静态测试静态测试方法的主要特征是在用计算机测试源程序时，计算机并不真正运行被测试的程序，只对被测程序进行特性分析。静态测试常称为“分析”
28、，静态分析是对被测程序进行特性分析的一些方法的总称。动态测试动态测试方法的主要特征是计算机必须真正运行被测试的程序，通过输入测试用例，对其运行情况(输入/输出的对应关系)进行分析。,50,51,51,软件测试的分类,按测试形态(Testing Types)(台湾许育诚的一种分法)：建构性测试(Construction Testing)：当程序还是处于建设阶段时所进行的测试；是属于前置性的测试,它主要是偏重于程序端的功能测试,以确保程序执行运行正常。系统测试(System Testing) :是针对系统的行为来做测试；是属于中后期的整合测试,所进行的测试是以使用者的观点为主,也就是模拟外界世界的
29、使用者会如何的使用产品。 特殊测试(Special Testing) :根据产品的本质特性来安排或剔除特殊测试,52,52,软件测试的分类,建构性测试包括：单步测试、尝试性测试、单元测试、组件测试、集成测试等系统测试包括：集成测试、前哨测试、功能测试、设置测试、发行测试、验收测试等特殊测试包括：回归测试、压力测试、兼容性测试、性能测试、Alpha和Beta测试,53,53,软件测试的目的,软件测试的目的决定了如何去组织测试。如果测试的目的是为了尽可能多地找出错误，那么测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置。如果测试目的是为了给最终用户提供具有一定可信度的质量评价，那么测试
30、就应该直接针对在实际应用中会经常用到的商业假设。,软件测试的目的和原则,54,54,软件测试的目的,Grenford J. Myers在The Art of Software Testing一书中的观点： 软件测试是程序的执行过程，目的在于发现错误； 测试是为了证明程序有错，而不是证明程序无错误。 一个好的测试用例是在于它能发现至今未发现的错误； 一个成功的测试是发现了至今未发现的错误的测试。,软件测试的目的和原则,55,55,软件测试的目的,对 Myers 观点的解释测试要以查找错误为中心，而不是为了演示软件的正确功能。但发现错误并不是软件测试的唯一目的。没有发现错误的测试也是有价值的，完整
31、的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。例如 Bev Littlewood发现一个经过测试而正常运行了n小时的系统有继续正常运行n小时的概率。,软件测试的目的和原则,56,56,软件测试的原则,软件开发者的座右铭：“尽早地和不断地进行软件测试” 。测试用例应由测试输入和与之对应的预期输出结果两部分组成。程序员应避免检查自己的程序。（注意不是指对程序的调试）在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。不合理的输入条件是指异常的，临界的，可能引起问题异变的输入条件。妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。测试无法显示潜在
32、的软件缺陷和故障通过测试只能报告已被发现的缺陷和故障，无法报告隐藏的软件故障。,软件测试的目的和原则,57,软件测试的原则,完全测试是不可能的，测试需要终止。（1）测试所需要的输入量太大（2）测试的输出结果太多（3）软件实现的途径太多（4）软件规格说明没有一个客观标准软件测试是有风险的行为，要针对风险做出抉择。就是如何将无边无际的可能性减小到一个可控的范围，以及如何针对软件风险做出恰当选择，去粗存精，找到最佳的测试量，使得测试工作量不多也不少，既能达到测试的目的，又能较为经济。,57,58,58,软件测试的原则,59,59,软件测试的原则,充分注意测试中的群集现象。经验表明，测试后程序残存的错
33、误数目与该程序中以发现的错误数目或检错率成正比。应该对错误群集的程序段进行重点测试。其中的原因是：编写该段程序时，程序员情绪不佳、心情不好；程序员往往犯同样的错误；某些软件缺陷实乃冰山一角。,软件测试的目的和原则,60,60,软件测试的原则,严格执行测试计划，排除测试的随意性。测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方法和过程，系统的组装方式，跟踪规则，调试规则，以及回归测试的规定等等以及评价标准。应当对每一个测试结果做全面的检查。对测试结果要有一个确认过程。A测出的错误由B确认。严重的错误可召开评审会进
34、行讨论和分析。,软件测试的目的和原则,61,61,软件测试的原则,所有测试的标准都应建立在用户的需求上软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间服从质量。并非所有软件缺陷都要修复原因：没有足够的时间进行修复；修复的风险较大； 不值得修复；可不算做故障的一些缺陷；“杀虫剂现象”。结论：关键是要进行正确判断、合理取舍，根据风险分析决定哪些故障必须修复，哪些故障可以不修复。,软件测试的目的和原则,62,62,软件测试过程,对于各种测试，需要有一系列的测试活动来完成。,软件测试活动,63,63,软件测试活动,1 测试条件取决于被测试验证的项目或事件。测试条件是被测环境的
35、描述，可以用多种方式描述：如简单的语言，表格项形式或类似于流图的图表形式；标识测试条件的活动最好与开发活动（即V模型左边的活动）并行开展。2 设计测试用例（test case） ，确定“怎样测试”。测试是从大量的测试用例中选择有限的测试用例发现软件中的大部分缺陷的一种技术。测试用例是按一定顺序执行的与测试目标（测试理由或目的）相关的一系列测试。测试用例设计将产生许多测试所包括的输入、期望结果及其他任何运行测试的有关信息，如环境要求。,软件测试活动,64,64,软件测试活动,2 设计测试用例，确定“怎样测试”。（续）期望输出包括应输出或建立的内容，应修改或更新或应删除的内容。期望输出集可以是一个
36、很大的集合。好的测试用例的4个特性：检测软件质量的有效性，是否能发现缺陷，或至少可能发现缺陷；可仿效的测试用例可以测试很多内容，因而减少测试用例的数量；经济性，测试用例的执行、分析和调试是否经济；测试用例的可修改性，每次软件修改后对测试用例的维护成本。,软件测试活动,65,65,软件测试活动,3 开发测试用例，包括准备测试脚本、测试输入、测试数据以及期望输出。测试脚本（test script）是具有正规语法的数据和指令的集合，在测试执行自动工具使用中，通常以文件形式保存；必须先完成测试用例的先决条件，然后再执行测试。测试用例可能要求专门的硬件或软件，如网络环境或打印机等；期望输出可以组成成文件
37、形式用于自动工具。对于手动测试，期望输出仅仅只是简单地记录在手工测试过程或脚本中。设置用于自动比较的期望输出比设置用于手工测试的期望输出复杂得多。在自动工具中要求每项内容都要拼写正确，而在手工测试中要求没这么严格。测试开发的任何工作可以提前进行（相对V模型左边的活动进行），以后可以节省时间。,软件测试活动,66,66,软件测试活动,4 执行测试用例对于手动测试来讲，测试者按事先准备好的手工过程进行测试，测试者输入数据、观察输出、记录发现的问题。对于自动测试，可能只需要启动测试工具，并告诉工具执行哪些测试用例；,软件测试活动,67,67,软件测试活动,5 将测试结果与期望输出进行比较应该对每次测
38、试的实际输出进行分析研究，判断软件功能是否正确。验证可以是非正式的测试者主观判断，也可以是将实际输出与期望输出进行严格准确的比较。一些信息比较，如可以在执行测试时进行显示屏幕上的信息，另一些输出比较，如修改数据库记录，只能在测试执行结束后进行。自动测试一般结合了这两种方法。,软件测试活动,68,68,测试信息流程,测试信息流程如图所示。测试过程中需要三类输入：软件配置、测试配置和测试工具。,图 测试信息流程,软件测试活动,69,69,软件测试的周期性,软件测试的周期性是“测试-改错-再测试-再改错”这样一个循环过程，如下图所示。,图 软件测试的周期性,软件测试活动,70,70,软件测试技术概要
39、,软件测试的策略：就是测试将按照什么样的思路和方式进行。通常，软件测试要经过单元测试、集成测试、确认测试、系统测试以及验收测试。软件测试技术： （1）白盒测试和黑盒测试 （2）静态测试和动态测试 （3）传统测试方法和面向对象测试的方法 （4）特定环境及应用的测试,71,71,软件测试误区,如果发布的软件有质量问题，那是软件测试人员的错。软件测试技术要求不高，至少比编程容易多了。有时间就多测试一些，来不及就少测试一些。软件测试是测试人员的事，与开发人员无关。根据瀑布模型，测试是开发后期的一个阶段。,软件测试误区,72,72,软件测试人员应具备的素质,软件测试员在开发团队中“讨人厌”软件测试员的目
40、标 发现潜在的软件缺陷保持团队和谐的建议尽可能早的找出缺陷控制情绪不要总是报告坏消息,软件测试人员应具备的素质,73,73,软件测试人员应具备的素质,软件测试员应具备的素质：(1)探索精神(2)故障排除能力(3)不懈努力(4)创造性(5)追求完美(6)判断准确(7)老练稳重(8)说服力,软件测试人员应具备的素质,74,74,软件测试的模型,软件测试模型则是软件测试的工作框架,用于指导软件测试过程.V模型W模型H模型X模型前置模型测试模型的使用,软件测试的模型,75,75,软件测试的模型 - V模型,软件测试的模型,76,76,软件测试的模型 - V模型,V模型描述了不同的测试级别V模型描述了一
41、些不同的测试级别,并说明了这些级别所对应的生命周期中不同的阶段。如模型图中所示,左边下降的是开发过程各阶段,与此相对应的是右边上升的部分，即各测试过程的各个阶段。 在模型图中的开发阶段一侧，先从定义业务需求开始，然后要把这些需求不断地转换到概要设计和详细设计中去，最后开发为程序代码。在测试执行阶段一侧，执行先从单元测试开始，然后是集成测试、系统测试和验收测试。 成功应用V模型的关键因素是设计测试案例的时机,77,77,软件测试的模型 - V模型,V模型的价值它非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系：单元测试的主要目的是针对编码过程中
42、可能存在的各种错误，例如用户输入验证过程中的边界值的错误。集成测试主要目的是针对详细设计中可能存在的问题尤其是检查各单元与其它程序部分之间的接口上可能存在的错误。 系统测试主要针对概要设计，检查了系统作为一个整体是否有效地得到运行，例如在产品设置中是否达到了预期的高性能。 验收测试通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需要。,78,78,软件测试的模型 - V模型,V模型问题测试是开发之后的一个阶段测试的对象是程序本身易导致需求阶段的错误一直到最后系统测试阶段才被发现如果问题不能及时被发现，这些隐含的问题也被带到下一个工序，正确的设计被编码，错误的设计也同时被编码。,79,
43、79,软件测试的模型 - W模型,V模型测试的改进，在概要设计、详细设计和编码每个步骤都要进行检测。尽量把问题及时发现、及时消灭。 W模型是基于IEEE std 1012-1998软件验证和确认（V&V）原则提出。此原则主要思想是“尽早地和不断地进行软件测试”。,80,80,软件测试的模型 - W模型,81,81,82,82,软件测试的模型 - W模型,测试伴随整个开发周期。相应开发活动完成，即可对相应开发活动进行测试测试对象不仅是程序，还包括需求和设计优点强调了测试计划等工作的先行和对系统需求和设计的测试。缺点没有对软件测试流程予以说明,83,83,软件测试的模型 - H模型,V模型和W模型
44、的局限软件开发被视为一系列串行活动。实际上，大部分时间可并发。软件开发中，严格的阶段划分只是一种理想状态。实际，只要测试条件满足，就可进行测试。不同层次测试之间除了先后关系外，还有触发、反复、迭代和增量关系。没有很好地表示测试流程的完整性。测试流程大致可分为测试准备活动（包括测试需求分析、测试计划、测试设计、测试编码和测试验证）和测试执行活动（包括测试运行、测试分析和测试报告）,84,84,软件测试的模型 - H模型,H模型将测试作为一个独立流程，贯穿整个开发周期，与其他流程并行，同时测试准备和测试执行分离。,85,85,软件测试的模型 - H模型,H模型特性测试不仅仅指测试的执行，还包括许多
45、其他活动;测试是一个独立流程，贯穿产品整个生命周期；与其它流程并发进行测试要尽早准备，尽早执行测试是根据被测对象的不同而分层进行。意义测试准备和测试执行分离，有利于资源调配，降低成本，提高效率充分体现测试过程（不是技术）的复杂性有组织、有结构化的独立流程，有助于跟踪测试投入的流向,86,86,软件测试的模型 - X模型,X模型X模型基本思想由Brian Marick（软件子系统测试的作者） 提出，Robin F.Goldsmith（Go项目管理咨询公司的总裁 ）命名。Brian Marick对V模型的质疑主要有：V模型无法引导项目的全过程。他认为一个模型应能处理开发的所有方面，包括交接，频繁重
46、复的集成，以及需求文档的缺乏等。 V模型基于一套必须按照一定顺序严格排列的开发步骤，而这很可能并没有反映实际的实践过程。 质疑了单元测试和集成测试的区别，因为在某些场合人们可能会跳过单元测试而热衷于直接进行集成测试。按照V模型所指导的步骤进行工作，某些做法并不切合实用。,87,87,88,88,软件测试的模型 - X模型,X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试此后将进行频繁的交接,通过集成最终合成为可执行的程序。(右上半部分）,这些可执行程序还需要进行测试。已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以
47、在各个部分发生。,89,89,软件测试的模型 - X模型,X模型还定位了探索性测试（右下方）。 这是不进行事先计划的特殊类型的测试， 诸如“我这么测一下结果会怎么样？” ，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误.X模型及其探索性测试的提倡也是为了避免把大量时间花费在测试文档编写上面，那样的话，真正用于测试的时间就减少了。,90,90,软件测试的模型 - X模型,V模型的一个强项是它明确的需求角色的确认，而X模型没有这么做，这是X模型的一个不足之处。 X模型并不要求在进行作为创建可执行程序（图中右上方）的一个组成部分的集成测试之前， 对每一个程序片段都进行单元测试（图
48、中左侧的行为）。但X模型没能提供是否要跳过单元测试的判断准则。,91,91,软件测试的模型 - 前置测试模型,前置测试模型由Robin F. Goldsmith ，Dorothy Graham提出，是一个将测试和开发紧密结合的模型，该模型提供了轻松的方式，可以使你的项目加快速度。V模型和X模型是当前被测试专家所推崇的主要的测试模型。前置测试从V模型和X模型中汲取其中精华，并设法弥补了它们的不足之处。虽然前置测试也不是完美的，但它可以带来明显的益处。,92,92,93,93,软件测试的模型 - 前置测试模型,开发和测试相结合前置测试模型将开发和测试的生命周期整合在一起，标识了项目生命周期从开始到结束之间的关键行为。并且表示了这些行为在项目周期中的价值所在。如果其中有些行为没有得到很好的执行，那么项目成功的可能性就会因此而有所降低。 如果有业务需求，则系统开发过程将更有效率。业务需求最好在设计和开发之前就被正确定义。,
