第一章 软件测试概述课件.pptx

软件测试技术软件测试技术 第第1 1章章 软件测试概述软件测试概述1/88前言前言软件测试是保障软件质量的关键手段。本章介绍了软件测试的行业需求、现状和发展历程，给出了软件测试的基本概念、目的、分类和原则，说明了软件测试过程、常见测试模型和测试用例。2/881.11.1软件测试行业需求与现状软件测试行业需求与现状国际上公认的软件测试和开发工程师人员配置比例标准是1:1，国外一些开发大型、复杂软件系统的成熟企业（如微软），软件测试人员和开发人员的比例约为2:1，下表是微软公司两个大型软件产品开发过程中开发和测试人员的比例。3/88国外软件测试行业现状国外软件测试行业现状Exchange2000Windows2000项目经理项目经理25250开发人员开发人员1401700测试人员测试人员3503200测试与开发人员比例测试与开发人员比例2.5:11.9:1表表1-1 1-1 微软公司微软公司Exchange2000Exchange2000和和Windows2000Windows2000测试和开发人员比例测试和开发人员比例4/88国内软件测试行业现状国内软件测试行业现状20%18%14%14%12%9%7%6%1:31:7以上1:41:51:21:61:11:7图图1-1软件测试和开发工程师人员比例软件测试和开发工程师人员比例如图1-1所示，能够达到上述合理比例的国内企业数量仅占7%，1:7以上配置比例的企业数量仍然高达18%，这从一个侧面反映了我国软件测试行业的成熟度与国外相比还有很大的差距，同时也说明其增长空间是巨大的。5/88软件测试的职业优势（1）职业门槛不高（2）职业生命周期长（3）无性别偏好（4）多元化发展，职业空间广阔6/88软件测试的应用领域软件测试的应用领域41%20%14%7%6%4% 3%3%2%通信及互联网应用软件金融行业其它基础软件及PC消费类电子及IC教育军工、政府工业控制图图1-2软件测试人员所属行业分布软件测试人员所属行业分布7/88软件测试职业发展方向软件测试职业发展方向从软件测试职业发展方向来看，大体可以分为技术和管理两个方向。根据测试能力和经验的不同，技术方向又可分为初级、中级和高级3个阶段。（1）初级技术）初级技术阶段阶段：处于这一阶段的测试人员的工作内容主要是接受测试主管分配的任务，根据已有测试计划、流程和方案编写和执行测试用例、提交软件缺陷报告、完成阶段性测试报告以及参与部分阶段性评审工作。（2）中级技术）中级技术阶段阶段：处于此阶段的软件测试从业人员已经能够胜任自动化测试工程师、白盒测试工程师、性能测试工程师职位。8/88软件测试职业发展方向软件测试职业发展方向（3）高级技术）高级技术阶段阶段：高级技术阶段的自动化测试工程师不仅需要能够完成自动化测试脚本的设计和开发，还需要能够设计数据驱动，开发测试框架以及自主开发测试特定业务所需要的一些企业内部小型测试工具。 对于白盒测试来讲，需要结合不同软件架构和多种开发技术，寻找最为有效的代码测试方法，并且具有对代码进行优化的能力。 对于性能测试来讲，需要具备设计整体性能测试方案的能力，这就要求对主流的软件开发模式和应用系统具备丰富的知识和经验。9/88软件测试人员职位分布软件测试人员职位分布历史平均 18.0%48.0%8.9%13.0%6.3%0.9%0.4%0.4%1.1%1.8%2.8%2016年16.0%49.0%10.0%5.0%13.0%1.0%0.4%0.3%1.0%2.0%3.0%初级测试工程师测试工程师高级测试工程师测试主管或测试项目经理测试部门经理测试/质量总监测试分析师测试架构师性能测试工程师自动化测试工程师其它0.0%10.0%20.0%30.0%40.0%50.0%60.0%10/88软件测试的职业发展阶段（1）测试主管一般由具备35年软件测试经验的人员担任，要熟练掌握各种测试方法，具备过硬的测试技术。（2）测试经理一般由管理和技术能力都比较成熟的资深测试人员担任，完成企业级或大型项目级软件总体测试工作的策划和实施。为测试团队成员提供业务指导。（3）测试总监测试总监负责企业级全部测试及产品质量保障工作，全面管理企业的相关测试资源。11/88 1.2 软件软件中的中的Bugl 什么是什么是BugBug？Bug是英语“虫子”的意思，现在人们将计算机系统或程序中隐藏的问题、缺陷或漏洞统称为Bug。在软件测试领域，我们一般使用更为正规的名词：软件缺陷（Software Defect）。12/88软件缺陷的定义软件缺陷的定义国内软件可靠性工程领域广泛使用的定义为：软件缺陷就软件缺陷就是存在于软件（程序、数据和文档）中的那些不希望或不是存在于软件（程序、数据和文档）中的那些不希望或不可接受的偏差，会导致软件产生质量问题可接受的偏差，会导致软件产生质量问题。IEEE国际标准729-1983中给出的软件缺陷标准定义是：从从软件产品内部看，软件缺陷是软件产品内部看，软件缺陷是软件软件开发或维护过程中存在开发或维护过程中存在的错误、毛病等各种问题；从软件产品外部看，软件缺陷的错误、毛病等各种问题；从软件产品外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。是系统所需要实现的某种功能的失效或违背。13/88软件缺陷的定义软件缺陷的定义通常认为，只要符合下面5个规则中的任意一条，就是软件缺陷：（1）软件未达到软件规格说明书中规定的功能；（2）软件超出软件规格说明书中指明的范围；（3）软件未达到软件规格说明书中指出的应达到的目标；（4）软件运行出现错误；（5）软件难以理解，不易使用，运行速度慢，或者最终用户认为使用效果不好。14/88BugBug的由来的由来图图1-4第一个第一个Bug记录手稿记录手稿1945年9月9日，美国海军的Grace Hopper中尉作为程序员正在研制一个被称为“MARK ”的计算机。那时的计算机还不是一个完全的电子计算机，需要使用大量的继电器完成工作。因为正值炎热的夏天，机房又位于一个没有空调的老建筑内，因此为了散热，所有窗户都敞开着。突然，“MARK ”死机了。Grace Hopper经过排查，在计算机的继电器里，找到了一只被继电器打死的小飞蛾，这只小虫子卡住了计算机的运行。Grace Hopper顺手将飞蛾夹在工作笔记里，并诙谐地把程序故障称为“Bug”。这一称呼后来演变成表达缺陷漏洞的计算机专业术语，人们习惯地把排除程序故障叫做“Debug”（除虫）。这一事件记录和那只飞蛾可以被称作是第一个Bug记录手稿（如图1-4所示），现在陈列在美国历史博物馆中。这就是我们今天所说的“Bug”的由来，它最初竟然真的就是“一只虫子”。15Grace Hopper简介图图1-5GraceHopperGrace Hopper后来成为美国海军少将，她是第一个程序语言编译器的开发者，第一个使用词语的计算机语言开发者，第一个商用编程语言COBOL的开发者，是与阿兰图灵、史蒂夫乔布斯、比尔盖茨等一同入选“IT界十大最有远见的人才”的唯一一位女性。2016年，Hopper被奥巴马追授总统自由勋章，这是美国平民所能获得的最高荣誉。16/88据统计，每年因软件问题会让美国经济损失近600亿美元。软件Bug的普遍存在影响的不仅仅是我们的日常生活，历史上很多灾难性事件的发生都是由软件Bug引起的。1979年11月28日，新西兰航空901号班机坠毁。1982年夏天，苏联西伯利亚天然气管线发生特大爆炸。1987年10月19日，道琼斯指数一天之内暴跌，引发金融市场恐慌。1991年2月25号，海湾战争期间，美国拦截导弹失败。1996年6月4日，阿丽亚娜5号火箭发射失败。2016年10月19日，火星登陆器“斯基亚帕雷利”坠毁。17/881.2.3 软件软件缺陷产生的原因缺陷产生的原因图图1-6软件缺陷产生的原因软件缺陷产生的原因18/881.3 什么是软件测试什么是软件测试测试事实上包含了硬件测试和软件测试两个方面，在本书中特指软件测试，即Software Testing。软件测试在其发展历程中有过不同的定义和不同的观点，了解它们有助于建立正确的软件测试思想。19/881.3.1 1.3.1 软件测试的发展历程软件测试的发展历程1、1957年之前，调试为主（Debugging Oriented）由于由于当时的软件当时的软件规模小、复杂度低、开发过程无序规模小、复杂度低、开发过程无序，测试被测试被等同等同于软件于软件调试调试，真正意义上的软件测试还未形成，真正意义上的软件测试还未形成。2、1957年1978年，证明为主（Demonstration Oriented）19571957年，年，Charles BakerCharles Baker对调试和测试进行了对调试和测试进行了区分区分，是软件是软件测试史上的一个重要里程碑，它标志了测试首次具有了独立测试史上的一个重要里程碑，它标志了测试首次具有了独立性。性。20/88软件测试的发展历程软件测试的发展历程 19721972年，在美国的北卡罗莱纳大学举办了历史上首届正式年，在美国的北卡罗莱纳大学举办了历史上首届正式的软件测试会议，标志着软件测试作为一个学科正式诞生的软件测试会议，标志着软件测试作为一个学科正式诞生了了。 19681968年北大西洋公约组织在联邦德国召开国际会议，会议年北大西洋公约组织在联邦德国召开国际会议，会议上正式提出了上正式提出了“软件工程软件工程”这一名词，标志了软件工程学这一名词，标志了软件工程学科的诞生科的诞生。 19731973年，年，William C. HetzelWilliam C. Hetzel整理出版了软件测试的第一本整理出版了软件测试的第一本著作著作Program Test MethodsProgram Test Methods，对测试方法和测试工具，对测试方法和测试工具进行了论述进行了论述。 19751975年，年，GoodenoughGoodenough和和GerhartGerhart首次提出了软件测试的理论，首次提出了软件测试的理论，使得软件测试成为具有理论指导的实践性学科。使得软件测试成为具有理论指导的实践性学科。21/88软件测试软件测试的发展历程的发展历程3、1979年1982年，破坏为主（Destruction Oriented）19791979年，年，Glenford J. MyersGlenford J. Myers出版了对软件测试行业影响深出版了对软件测试行业影响深远的著作远的著作The Art of The Art of Software TestingSoftware Testing，在书中，在书中给出了一个开创性的软件测试给出了一个开创性的软件测试定义：定义：“测试是为了发现错误测试是为了发现错误而而执行执行一个程序或者系统的过一个程序或者系统的过程程”。GlenfordJ.Myers22/88软件测试的发展历程软件测试的发展历程4、1983年1987年，评估为主（Evaluation Oriented）这一阶段的测试内涵也发生了转变，测试不再是一个单纯发现这一阶段的测试内涵也发生了转变，测试不再是一个单纯发现错误的过程，它包含了软件质量评价的内容。这一时期，出现错误的过程，它包含了软件质量评价的内容。这一时期，出现了测试领域著名的两个名词了测试领域著名的两个名词验证（验证（VerificetionVerificetion）和和确认确认（ValidationValidation）。人们提出了在软件生命周期中通过分析、评。人们提出了在软件生命周期中通过分析、评审和测试来评估软件产品的理论审和测试来评估软件产品的理论。5、1988年至今，预防为主（Prevention Oriented）STEPSTEP（Systematic Test and Evaluation ProcessSystematic Test and Evaluation Process）是最早的）是最早的一个以预防为主的测试生命周期模型，该模型体现了一个以预防为主的测试生命周期模型，该模型体现了测试测试与开与开发的并行性，强调了整个测试的生命周期也是由计划、分析、发的并行性，强调了整个测试的生命周期也是由计划、分析、设计、开发、执行和维护组成，也就是说，设计、开发、执行和维护组成，也就是说，测试测试不是在编码完不是在编码完成后才开始介入，而是成后才开始介入，而是贯穿于整个软件生命周期贯穿于整个软件生命周期。23/88 1983年，IEEE给出了一个比较完善的软件测试标准定义：“使用人工或自动手段来运行或测定某个系统的过程，其使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果和实目的在于检验它是否满足规定的需求或弄清预期结果和实际结果之间的差别际结果之间的差别”。 软件测试也可定义为：软件测试是由验证（软件测试是由验证（VerificationVerification）和有效性确认（和有效性确认（ValidationValidation）活动构成的整体，也就是软）活动构成的整体，也就是软件测试件测试=V&V=V&V。24/88验证&有效性确认n验证验证：是指检验软件生命周期的每个阶段和步骤的产品是否符合产品规格说明中定义的功能和特性要求，并且与前面的阶段和步骤所产生的产品保持一致性。验证通过数据和证据表明每一个软件生命周期活动是否已正确完成，判断是否在正确地开发软件产品，是否可以开始另外的生命周期活动，强调的是过程的正确性。n有效性有效性确认：确认：是保证所开发的软件是否真正满足用户实际需求，用数据和证据表明是不是制造了正确的产品，强调的是结果的正确性。25/88验证&有效性确认1981年，Boehm给出了有关验证和有效性确认的一个简洁解释，说明了两者之间的区别：验证验证：Are we building the product right? 也就是，我们是否正在正确地构造软件？检验软件开发过程中阶段性产品与软件规格说明书的一致性。有效性有效性确认确认：Are we building the right product? 也就是，我们是否构造了正确的产品？即是否构造了用户需要的产品。26/88软件测试认识误区软件测试认识误区p 误区一：如果已发布的软件有质量问题，都是测试人员的责任。p 误区二：软件测试技术要求不高，至少比编程容易多了。p 误区三：软件测试是开发后期的一个阶段。p 误区四：有时间就多测试一些，来不及就少测试一些。p 误区五：软件测试是测试人员的工作，与开发人员无关。p 误区六：有太多的问题无法测试。p 误区七：测试自动化将取代手工测试。p 误区八：软件测试工作不如软件开发工作有前途。27/88 1.4 软件测试软件测试的目的与原则的目的与原则软件测试的目的保证软件产品的最终质量。检验一个软件系统是否满足规定的需求，衡量出预期结果和实际结果之间的偏差，识别出软件阶段或最终产品的正确度和完全度。但是需要注意的是，发现错误是软件测试的手段而不是软件测试的唯一目的，未发现错误的测试依然是有价值的，软件测试的最终目的是检验软件产品是否满足用户的需求。28/881.4.1 软件测试的目的 关于软件测试的目的Glenford J. Myers曾经给出过如下观点：n（1）软件测试是一个程序的执行过程，其目）软件测试是一个程序的执行过程，其目的在于发现错误；的在于发现错误；n（2）一个好的测试用例很可能会发现至今尚）一个好的测试用例很可能会发现至今尚未发现的错误；未发现的错误；n（3）一个成功的测试是发现了至今尚未发现）一个成功的测试是发现了至今尚未发现的错误的测试。的错误的测试。29/881.4.1 软件测试的目的软件测试的目的一般包含以下内容：（1）验证软件是否满足开发合同、开发计划、需求规格说明和设计说明等规定的软件质量要求。（2）由于难以消除软件中的所有错误，所以通常来说软件测试的目的就是为了发现尽可能多的软件缺陷，消除它们，提高软件质量。（3）测试不仅是为了发现软件缺陷，还是对软件质量进行度量和评估的过程。测试结果数据可以为软件产品的质量测量和评价提供依据。（4）通过分析软件缺陷产生的原因，可以针对性地进行软件过程改进。30/88（1）软件测试不能证明程序无错。（2）所有测试都应当追溯软件缺陷的起源。（3）尽早和不断地进行软件测试。（4）软件测试应尽可能具有独立性。（5）Pareto原则。（6）重视无效数据和非预期的功能。（7）完全测试不可行，测试需要适时终止。（8）重视回归测试的关联性。（9）软件缺陷的免疫性。（10）测试过程文档需要妥善保存。31/881.5 软件测试过程与分类软件测试过程与分类软件测试过程软件测试过程一般包括四项活动，按顺序分别是：测试策划、测试设计、测试执行、测试总结。这就构成了软件测试的生命周期。（1）测试策划。主要是进行测试需求分析并制定测试计划。（2）测试设计。根据测试需求与计划，选择已有的或设计新的测试用例，准备测试数据，获取测试资源，开发测试软件，建立测试环境，进行测试就绪评审。（3）测试执行。执行测试用例，获取和分析测试结果。（4）测试总结。整理和分析测试数据，评价测试效果和被测软件项，描述测试状态。32/88软件测试过程在实际工作中，我们一般将测试过程分为制定测试计划、测试设计、测试准备、执行测试、测试评估和测试总结等几个阶段33/88软件测试过程（1）制定测试计划。在需求评审和设计评审的基础上制定测试计划。以测试计划指导整个测试工作，内容主要包括确定测试范围、识别和分解测试任务、识别风险并给出应对措施、规划测试资源、确定测试策略和确定测试进度等。（2）测试设计。设计测试用例和测试执行过程，保证测试用例完全覆盖测试需求。（3）测试准备。为执行测试进行前期准备，包括配置测试环境、准备测试数据、开发测试用例或测试脚本、选择测试工具等。34/88软件测试过程（4）执行测试。执行测试用例，发现和修正软件缺陷，主要包括单元测试、集成测试、系统测试和验收测试四个阶段。修改缺陷后往往需要进行回归测试。（5）测试评估。分析测试结果，对测试对象的可靠性、稳定性以及性能进行评测，为测试总结记录量化评测数据。（6）整体项目测试总结。总结整体项目测试工作，为今后不断改进测试质量和效率做准备。35/88软件测试分类软件测试分类36/88按照软件测试执行阶段的不同，一般将软件测试分为单元测试、集成测试、系统测试和验收测试。 单元测试是对软件的最小可测试单元进行检查和验证。 集成测试，有时也称为组装测试，是把经过单元测试的模块按照软件设计不断进行组装而进行的测试，重点是测试模块间的接口部分。 系统测试是将软件作为整个计算机系统的一部分，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，对计算机系统进行的一系列全面测试。 验收测试是软件交付给用户使用前的最后一项测试工作，其目的是向用户证明软件系统在功能、性能以及其它特性方面与用户的要求相一致。（1）按照测试执行阶段划分37/88按照测试技术，软件测试分为白盒测试与黑盒测试。白盒测试又称为结构测试或逻辑驱动测试。盒子在这里是指被测试的软件，白盒是指盒子里的东西及其运作是看得见的。白盒测试是在已知产品内部工作流程的情况下，研究程序的源代码和程序结构，按照程序的内部结构测试程序。（2）按测试技术划分38/88黑盒测试又称为数据驱动测试。黑盒测试不关心程序内部结构，将程序看做是不能打开的黑盒，用于检查程序所应具有的功能是否都已实现，每个功能是否都能正常使用，是否满足用户的需求。黑盒测试主要针对程序接口和用户界面进行测试，检查程序是否能够适当地接收输入数据并产生正确的输出结果。39/88（3 3）按测试执行状态）按测试执行状态划分划分按照测试执行状态，或者说按照是否运行程序，软件测试分为静态测试和动态测试。静态测试不实际运行被测程序，只是静态地检查程序代码、文档或软件界面是否存在错误。对于程序代码，主要检查其是否符合标准和规范，并对程序的数据流和控制流进行分析；对于文档测试，主要是检查需求、设计、用户手册等文档是否完整、正确、内容一致、易于理解等；对于软件界面，主要是检查界面与需求40/88和设计中的说明是否一致。需要注意的是，静态测试，尤其是对代码进行的静态测试可以借助很多测试工具进行，静态测试和人工测试是不同的两个概念。 动态测试需要实际运行被测程序，输入测试数据，对比程序输出结果与预期结果是否一致，分析对比结果，发现软件中潜在的缺陷。区分一个测试是动态测试还是静态测试的唯一标准就是看是否运行程序。41/88（4）按用户需求划分）按用户需求划分按用户需求，分为功能测试和非功能测试。功能测试比较容易理解，主要是根据软件需求规格说明书，检验软件是否满足各方面功能的使用要求。通常是测试人员直接运行软件，针对程序接口或软件界面进行测试。针对不同系统的功能测试内容差别很大，但是都可以归结为界面、数据、操作、逻辑、接口等几个方面，常见的功能测试包括逻辑功能测试、界面测试、可用性测试、接口测试等。42/88非功能测试是相对于功能测试而言，软件系统能否正常运行不仅依赖于其功能是否正确实现，而且依赖于其非功能性属性能否满足使用要求，尤其是软件性能是否满足要求。常见的非功能测试包括性能测试、安全性测试、可靠性测试、恢复测试等，而性能测试又包括一般性能测试、稳定性测试、负载测试、压力测试、容量测试等。43/88（5）其它）其它 软件测试中还有一些不易归类的测试概念，例如回归测试、冒烟测试和随机测试等。 回归测试一般是指在修改代码之后，为了保证修改没有引起新的错误而进行的重新测试过程。严格的来讲，回归测试不是一个测试阶段，它是一种可以在单元测试、集成测试、系统测试和验收测试等任何测试阶段进行的测试活动。既有黑盒测试的回归，也有白盒测试的回归。软件测试中，回归测试的工作量极大，尤其是在软件版本频繁升级和发布的软件项目中。44/88冒烟测试是对每一个新编译的需要正式测试的软件版本，在大规模测试之前，先检查软件基本功能是否正常，是否具有可测试性。冒烟测试严格来说就是一个对软件基本功能点进行初步测试的过程。当开发出一个新版本的软件后，首先要进行冒烟测试，测试通过后，再进行回归测试。但是，回归测试并不是都在新版本冒烟测试之后进行，在软件开发和测试的各个阶段都会进行很多次的回归测试。45/88随机测试是根据测试人员的经验，对软件进行功能和性能抽查，是对根据测试说明书和测试用例进行测试之外的补充测试手段，可以更好地保证测试覆盖的完整性。随机测试的输入数据都是随机生成的。随机测试存在着一些明显的缺点，例如测试方法不系统，无法统计覆盖率指标，很难回归测试等。随机测试称为猴子测试。46/881.6 软件测试过程模型软件测试过程模型软件测试与软件开发紧密相关，与软件开发具有过程模型一样，软件测试也有其测试过程模型。软件测试过程模型是对测试过程的一种抽象，用于定义软件测试的流程和方法，并与开发方法进行了有机的结合。掌握软件测试过程模型可以帮助我们正确理解测试与开发的关系，根据不同的软件开发过程选择合适的测试过程。47/881.6.1 V模型48/88V模型是软件开发瀑布模型的变形，突出了测试过程的独立性，反映了软件测试活动和软件开发活动的关系，明确地标明了测试过程中存在的不同级别的测试阶段，并且清楚地描述了这些测试阶段和开发过程各阶段之间的对应关系。V模型中的测试是在软件编码之后进行，箭头代表了时间进度，其左侧是开发阶段，右侧是测试阶段。V模型在测试中的地位就如同瀑布模型在开发中的地位一样，都是最基础的模型，大部分测试模型都是从这个模型演化而来。49/88 V模型的测试策略包含低层和高层测试，低层测试是为了保证源代码和设计的正确性，高层测试是为了使系统满足用户需求。单元测试和集成测试主要验证软件是否满足设计要求，系统测试是为了验证系统功能和性能是否达到了质量要求的指标，验收测试是确定最终的软件产品是否真正满足用户需求。50/88V模型存在着明显的局限性，它只是将测试看做是编码之后的一个阶段，主要是针对程序寻找错误的活动，从而忽视了测试活动对需求分析和系统设计等前期开发活动的验证和确认功能。 V模型的缺点51/881.6.2 W1.6.2 W模型模型52/88W模型的优点是有利于尽早地和全面地发现软件缺陷。在软件需求分析完成后，就应当及时地对需求分析结果进行验证和确认，尽早地发现隐藏在需求分析结果中的错误。同时，对需求进行测试可以使测试人员及时了解软件项目的功能和性能要求、项目的难度和复杂度以及测试工作的风险，便于针对性的制定测试计划，提高测试工作的准确度和效率，保障软件的质量满足用户需求。同理，对软件设计的及时测试可以保障设计结果的合理性和正确性。W模型的优点53W模型的缺点模型的缺点W模型将需求、设计和编码等开发活动都看做是串行活动。同时，测试和开发活动也保持着一种线性的前后关系，前面的一个阶段完成后，才可以开始下面一个阶段的工作。因此，W模型无法支持迭代的软件开发过程，也难以适应需求变更调整。541.6.3 H1.6.3 H模型模型H模型是针对V模型和W模型的局限性而提出的，上图只是展示了整个软件开发周期中某个层次上的一次测试“微循环”，图中的其它流程可以是设计流程或编码流程等任意的开发流程55/88H H模型模型H模型适合于迭代特征比较明显的软件开发过程，例如面向对象的软件开发过程，这类开发过程在各个开发阶段之间或一个阶段内的各个开发步骤之间经常会多次反复迭代。H模型所表达的主要原理是：软件测试是一个独立的流程，以“微循环”的方式参与软件开发生命周期的各个阶段，与其它流程并发地进行。软件测试要尽早准备，尽早执行。56/881.6.4 X模型模型57/88X模型的说明模型的说明X模型的右上方表示对已通过集成测试的程序成品形成某一版本的软件并提交给用户，也可以是将已集成好的阶段产品用于更大规模的集成活动。多根并行的曲线表示变更可以在各个部分发生。X模型的右下方给出了一种探索性测试方式做为传统测试过程的补充，这是一种不进行事先计划的特殊类型的测试，强调的是测试设计和测试执行的同时性，区别于传统测试过程中“先设计后执行”的方式。探索性测试在对测试对象进行测试的同时学习测试对象并设计测试，在测试过程中运用获得的关于测试对象的信息设计新的更好的测试。58/88X X模型的特点模型的特点X模型弥补了V模型欠缺测试设计环节和不能够进行测试回溯的缺陷，并且增加了探索性测试这种新的测试思维方式。X模型能够很好地处理软件开发和测试的交接过程。能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但由于缺乏计划性，可能造成测试资源的浪费，对测试人员的经验性要求很高。59/881.6.5 1.6.5 前前置测试模型置测试模型60/88前置测试前置测试模型的特点模型的特点前置测试模型是一种将测试和开发紧密结合的模型，它将V模型和X模型相结合，沿用它们的长处，同时又弥补了它们的不足。运用前置测试模型可以加快项目开发的速度。具有以下特点：（1）开发与测试相结合：前置测试模型将开发和测试的生命周期整合在一起，标识了项目生命周期从开始到结束之间的关键行为，关键行为的缺失将会降低软件项目成功的可能性。前置测试在开发阶段可以通过编码和测试交替的方式进行，也就是说，程序片段一旦编写完成，就会立即进行测试。61/88（2）对每一个交付内容进行测试：每一个交付的开发结果都必须通过一定的方式进行测试，源程序代码并不是唯一需要测试的内容。（3）在设计阶段进行测试计划与设计：设计阶段是做测试计划与设计的最好时机。前置模型认为测试主要包括验收测试和技术测试两种类型，它们都需要测试计划。验收测试计划的制定不仅依赖于系统分析的结果，而且依赖于系统设计的结果，需要根据系统设计所决定的一些具体系统操作来判断验收标准是否达成，以及基于需求的测试是否成功完成。62/88（4）验收测试和技术测试相互保持独立：提倡验收测试应该独立于技术测试，这样可以提供双重的保险，以保证设计及程序编码能够符合最终用户的需求。（5）反复交替的开发与测试：软件项目经常会在各个开发阶段发生变更，例如新增功能并同步修改技术文档，开发和测试需要一起反复交替地执行。（6）模型内在价值：通过对风险优先级的划分，用较低的成本来及早发现错误，并且充分强调了测试对确保软件质量的重要意义。63/88测试模型的特点测试模型的特点 模型模型模型主要特点模型主要特点V模模型型明确说明了软件测试在整个软件开发周期中需要经历的阶段，每个测试阶段都与一个开发阶段对应。但是测试只在编码之后进行，没有明确说明应对需求和设计进行测试，不支持迭代开发。W模模型型 强调了测试和开发的并行性，明确了需要对需求和设计进行测试，有利于尽早发现软件缺陷。将开发和测试都看做是串行活动，无法支持软件迭代开发。 表表1-2 1-2 测试模型的主要测试模型的主要特点特点64/88 模型模型模型主要特点模型主要特点H H模模型型 表明了测试是一个独立的流程，贯穿产品整个生命周期，与其它流程并发地进行。强调了软件测试要尽早准备和尽早执行，只要具备了测试条件就可以开始测试，支持迭代开发。但模型意义仅在于应用其思想指导工作，模型本身没有太多的可执行意义。X X模模型型 体现了测试设计和测试回溯的过程，能很好的处理开发和测试的交接过程，探索性测试有利于有经验的测试人员发现测试计划之外的软件缺陷。表1-2 测试模型的主要特点（续表1）65/88 模型模型模型主要特点模型主要特点前置前置模型模型 将开发和测试紧密结合，明确了除程序之外的测试对象，强调了验收测试和技术测试的独立性，支持反复交替的测试过程，可以加速开发进度。表1-2 测试模型的主要特点（续表2）66/88 1.7软件测试软件测试信息流信息流软件测试信息流，反映了软件测试过程中一些主要的处理活动以及与这些处理活动相关的输入与输出信息。67/88 软件测试在实施前应当给出如下三类信息：（1）软件配置。这里的软件配置特指软件测试的对象，包括被测试的目标执行程序、软件数据结构、需求规格说明书和设计规格说明书等软件开发文档。（2）测试配置。包括测试计划、测试用例或测试数据、测试驱动程序等。实际上，从软件工程整体角度来看，测试配置只是软件配置的一个子集。（3）测试工具。为提高软件测试效率所使用的测试工具，例如，程序静态和动态分析工具、负载测试工具、测试度量报告工具、测试管理工具等。68/88 评估测试结果是对实施测试后得到的测试结果进行分析，分析过程中需要将实际获得的测试结果和预期的结果进行对比。如果发现对比结果不一致，意味着软件中存在错误，需求进行错误排查，定位错误并确定错误性质。修改错误后，需要修改相关的技术文档，并且对修改后的程序进行重新测试，直到测试通过为止。 排查与修正错误所需花费的时间往往难以预估，这种排错所固有的时间不确定性很可能造成测试进度的延后，需要在测试项目管理中引起高度重视。 通过评估测试结果，可以获得软件的出错率。建立软件可靠性模型能够定量化地给出软件的可靠性，以此判断软件质量是否达到了可以接受的程度，软件可以发布。69/881.8 1.8 软件测试用例软件测试用例测试用例构成了设计和制定测试过程的基础，是软件测试中最重要的工作。l 什么是测试用例？测试用例是测试执行之前已设计好的一套详细的测试方案，也是测试执行时的最小实体。概况的来讲，测试用例是为了某个特殊目标而编制的一组测试输入、执行条件以及预期结果，其目的是确定应用程序的某个特性是否能够正常工作，并且满足了特定用户需求和软件设计结果。70/88表表1-3 Word形式的软件卸载形式的软件卸载测试用例测试用例序号序号XZ01XZ01功能描述功能描述通过安装程序进行卸载用例目的用例目的测试是否能通过安装程序自带的卸载程序进行正确卸载，并卸载干净。测试类型测试类型卸载测试前提条件前提条件已经安装好程序，并且安装程序自带了卸载程序。71/88表表1-3 Word形式的软件卸载形式的软件卸载测试用例测试用例（续表）（续表）序号序号XZ01XZ01测试方法测试方法与步骤与步骤输入点击自带的卸载程序，根据卸载提示信息卸载程序。期望输出卸载后，系统能恢复到软件安装前的状态（包含目录结构、动态库、注册表、系统配置文件、驱动程序、关联情况等）。测试结果测试结果功能完成功能完成是 否72/88针对软件卸载功能的测试包含一组相关测试用例，我们称之为测试套件（Test Suite），测试套件是根据特定的测试目标和任务而构造的某个测试用例的集合。Excel形式的测试用例每个用例占用一行，因此能够比较方便地对针对某一软件功能的测试用例进行呈现、管理和维护，而Word形式的测试用例一般每个独占一页，用例信息丰富，但管理和维护起来比较分散。上面两个测试用例是完整的测试用例吗？73/88序号序号测试项测试项测试结果测试结果XZ01XZ01通过安装程序进行卸载 XZ02XZ02通过控制面板进行卸载 XZ03XZ03通过第三方卸载工具卸载 XZ04XZ04程序正在使用时卸载 XZ05XZ05卸载过程中取消卸载 XZ06XZ06突然中断卸载过程（关闭程序、关机、断电、断网等） 表表1-4Excel形式的软件卸载形式的软件卸载测试用例测试用例74/88一个测试套件或者一个测试用例一般包括如下内容：1.用例版本历史信息用例版本历史信息（1）项目名称。（2）项目代号。项目研发代号，部分项目没有代号可空缺。（3）创建日期。测试用例文件创建的日期（4）版本。测试用例文件的版本号。（5）作者。创建或修改新用例版本的测试人员。（6）类型。新用例版本所作的操作选项：C创建，A添加，M修改，D删除。（7）备注。创建或修改用例的一些特殊说明或提醒。1.8.2 测试用例编写规范75/88（8）参考文件名称。项目文档或技术文档的文件名。（9）参考文件路径/附件。项目文档的公共提取地址，此条目为用例编写依据。2.用例模板信息用例模板信息（1）CaseID（用例编号）。（2）CheckPoint（检查点）。统一使用“功能分支功能点”命名方式，每个CheckPoint不允许出现相同的描述，必须做到可区分，例如“网上订货-订购”。（3）Preset Conditions（预置条件）。实施此项测试用例的前提条件。76/88（4）Test Environment（测试环境）。测试所需硬件、软件和网络等测试平台的描述。（5）Input Data（输入数据）。可能包括数据、文件，以及必要时的数据库信息。（6）Test Steps（测试步骤）。n测试步骤的编号统一使用“1.XX”的编号方式；n步骤的提示指引符号使用“-”，例如“打开文件-关闭对话框”；n测试步骤如果与当前条目用例检查点无关，尽可能合并步骤，不要每步操作对应一个步骤编号，例如将“打开文件”和“关闭对话框”合并为 “打开文件-关闭对话框”）。77/88 （7）Expect Results（期望结果）。n预期结果编号需与步骤编号完全一致，编号命名与步骤一致；n如果测试结果中有特殊情况需加括号注明，例如“测试网上订购接口（不确定接口参数）”。（8）Actual Results（实际结果）。当测试用例执行失败时的执行结果描述（注意：该条目对NA用例不适用）。（9）Pass/Fail/Blocked/NA（测试结论）。记录用例的通过和失败，Blocked为Bug无法测试，NA为当前用例不适用当前测试。78/88（10）Priority（用例优先级）。使用率高且对项目有重大影响的功能点为P1，使用率不高但同属于功能性的为P2，其他文字性和界面美观性为P3或P4。（11）Created By（用例编写者）。（12）Creation Date（用例编写日期）。（13）Executed By（执行用例测试人员）。（14）Execution Date（用例执行日期）。（15）Execution Version（执行该条用例使用的软件版本号）。（16）Comments（说明）。测试该条用例时如果出现失败或被阻碍，描述简要现象和其它问题。79/88编写测试的注