软件测试技术学习课件

软件测试课程内容第1章

软件工程与软件测试1.1软件工程1.2软件质量1.3软件测试1.4软件测试人员的根本素质严格地说，软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程。通俗地说，软件工程是实现一个大型程序的一套原那么方法，即按工程化的原那么和方法组织软件开发工作。软件测试是软件工程的一个重要环节，相当于工程领域中的质量检验局部，是确保软件工程质量的重要手段。1.1软件工程软件工程的目标及其一般开发过程一个软件产品从形成概念开始，经过开发、使用和维护，直到最后退出使用的全过程称为软件生存周期。软件生存周期根据软件所处的状态，以及软件开发活动的目的和任务，可划分为假设干个阶段。一般软件生存周期包括软件定义、软件开发以及软件使用与维护3个局部。2．软件开发软件开发是按照需求规格说明的要求，由抽象到具体，逐步生成软件的过程。软件开发一般由设计、实现和测试等阶段组成。3．软件使用和维护软件的使用是在软件通过测试后，将软件安装在用户确定的运行环境中移交给用户使用。软件的维护是对软件系统进行修改或对软件需求变化做出反响的过程。1.1.2软件过程模型软件开发过程中存在各种复杂因素，为了解决由此而带来的种种问题，软件开发者们经过多年的摸索，给出了多种实现软件工程的方式——软件过程模型，如瀑布过程模型、螺旋过程模型和增量过程模型等。1．瀑布过程模型瀑布过程模型反映了人们早期对软件工程的认识水平，是人们所熟悉的一种线性思维的表达。瀑布过程模型强调阶段的划分及其顺序性、各阶段工作及其文档的完备性，是一种严格线性的、按阶段顺序的、逐步细化的开发模式，如图1-1所示。图1-1瀑布过程模型2．螺旋过程模型螺旋过程模型的根本思路是，依据前一个版本的结果构造新的版本，这个不断重复迭代的过程形成了一个螺旋上升的路径，如图1-2所示。图1-2螺旋过程模型3．增量过程模型有些时候可能会用一种几乎连续的过程小幅度地推进工程，这就是增量过程模型，如图1-3所示。图1-3增量过程模型1.2软件质量软件质量是软件的生命，它直接影响软件的使用与维护。通常软件质量由以下几方面进行评价。①软件需求是衡量软件质量的根底，不符合需求的软件就不具备质量。设计的软件应在功能、性能等方面都符合要求，并能可靠地运行。②软件结构良好，易读、易于理解，并易于修改、维护。③软件系统具有友好的用户界面，便于用户使用。④软件生存周期中各阶段文档齐全、标准，便于配置、管理。1.2.1质量与质量模型软件的质量因素很多，如正确性、精确性、可靠性、容错性、性能、效率、易用性、可理解性、简洁性、可复用性、可扩充性、兼容性等。软件质量因素也称为软件质量特性，反映了质量的本质。讨论一个软件的质量，问题最终要归结到定义软件的质量特性。面对众多的质量因素如何取折衷，这实际上就是区分质量因素对软件质量影响程度轻重的问题，这个问题已经有了解决方案，即软件质量模型。图1-4所示为ISO/IEC9126－1991标准规定的软件质量度量模型。它由3层组成，其中第1层称为质量特性，第2层称为质量子特性，第3层称为度量。图1-4ISO软件质量度量模型软件质量评价的目的是为了直接支持开发并获得能满足用户要求的软件。最终目标是保证产品能提供所要求的质量，即满足用户明确的和隐含的要求。软件产品的一般评价过程是，确定评价需求，然后规定、设计和执行评价，如图1-5所示。图1-5软件评价过程1.2.2软件质量保证为了在软件开发过程中保证软件的质量，软件的质量保证活动应贯穿整个软件生存周期的每一个阶段。软件的质量保证的措施主要有检查、评审和测试。如图1-6所示，软件质量保证的工作从工程一开始就应介入。图1-6质量保证活动1.3软件测试

1.3.1软件测试的定义及目的简单地说，软件测试就是为了发现错误而执行程序的过程。软件测试是一个找错的过程。软件测试的过程亦是程序运行的过程。程序运行需要数据，为测试设计的数据称为测试用例。测试用例的设计原那么是尽可能暴露程序中的错误。软件是由人来完成的，所有由人做的工作都不会是完美无缺的。软件开发是个很复杂的过程，期间很容易产生错误。无论是软件从业人员、专家和学者做了多大的努力，软件错误仍然存在。因而大家也得到了一种共识：软件中残存着错误，这是软件的一种属性，是无法改变的。所以通常说软件测试的目的就是为了发现尽可能多的缺陷，并期望通过改错来把缺陷统统消灭，以期提高软件的质量。一个成功的测试用例在于发现了至今尚未发现的缺陷。软件测试的目的是以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。1.3.2软件测试信息流为进一步说明软件测试的过程，这里给出软件测试的信息流示意图，如图1-8所示。图1-8软件测试信息流1.3.3软件测试与软件开发过程的关系对于软件测试与软件开发过程之间的关系，套用固定的模型不是聪明之举。比方“程序设计〞与“测试〞之间的关系，习惯上总以为程序设计在先，测试在后，如图1-9〔a〕所示。而对于一些复杂的程序，将测试分为同步测试与总测试更有效，如图1-9〔b〕所示。图1-9程序设计与测试的关系现在还有一种全新的软件开发模式——以测试驱动软件开发，总的思想是：软件测试是贯穿于软件开发过程的。软件生存周期的各个阶段中都少不了相应的测试，软件生存周期各个阶段的测试分别对应于软件测试过程中的单元测试、集成测试、系统测试和确认测试，如图1-10所示。这种对应关系有利于软件开发过程的管理和软件质量的控制。图1-10软件测试与软件开发的关系1.3.4软件测试与质量保证的区别1．质量保证质量保证〔QA〕工作通过预防、检查与改进来保证软件质量。QA采用“全面质量管理〞和“过程改进〞的原理开展质量保证工作。2．软件测试测试虽然也与开发过程紧密相关，但关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。测试人员要“执行〞软件，对过程中的产物——开发文档和源代码进行走查，运行软件，以找出问题，报告质量。测试人员必须假设软件存在潜在的问题，测试中所做的操作是为了找出更多的问题，而不仅仅是为了验证每一件事是正确的。对测试中发现的问题的分析、追踪与回归测试也是软件测试中的重要工作，因此软件测试是保证软件质量的一个重要环节。软件质量保证活动与软件测试的关系可用图1-11说明。图1-11软件质量保证活动与测试的关系1.3.5软件测试的开展历程及趋势软件测试是伴随着软件的产生而产生的，有了软件的生成和运行就必然有软件测试。在早期的软件开发过程中，测试的含义比较窄，将测试等同于“调试〞，目的是纠正软件中已经知道的故障，常常由软件开发人员自己完成这局部工作。对测试的投入极少，测试介入得也晚，常常是等到形成代码，产品已经根本完成时才进行测试。直到1957年，软件测试才开始与调试区别开来，成为一种发现软件缺陷的活动。直到20世纪80年代早期，“质量〞的号角才开始吹响。软件测试的定义发生了改变，测试不单纯是一个发现错误的过程，而且包含软件质量评价的内容。软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题。制定了各类标准，包括IEEE标准、美国ANSI标准和ISO国际标准。20世纪90年代，测试工具终于盛行起来。到了2002年，Rich和Stefan在?系统的软件测试?一书中对软件测试做了进一步定义：“测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程〞。这些经典论著对软件测试研究的理论化和体系化产生了巨大的影响。根据国内外软件测试的开展现状，可以看到软件测试有以下的开展趋势。①测试工作将进一步前移。②软件架构师、开发工程师、QA人员、测试工程师将进行更好的融合。③测试职业将得到充分的尊重。④设置独立的软件测试部门将成为越来越多的软件公司的共识。软件测试部门将和开发部、质量保证部一样作为一个重要的独立部门存在。⑤测试外包效劳将快速增长。和软件开发外包一样，软件测试外包将成为全球化的一种趋势。可以利用职业测试专家队伍与机构为自己的产品进行测试，而且可以节省测试费用。1.4软件测试人员的根本素质软件测试人员应具备以下根本素质。1．具有良好的计算机编程根底2．具有创新精神和超前意识3．不懈努力，追求完美4．具有整体观念，对细节敏感5．团队合作精神第2章软件测试的根本知识2.1软件测试贯穿于整个的软件开发生命周期2.2测试模型2.3软件测试的分类2.4软件测试的原那么2.5软件测试策略2.6软件测试流程2.7测试的成功经验2.1软件测试贯穿于整个的软件开发生命周期2.1.2软件测试贯穿于整个的软件开发生命周期20世纪70年代中期以来，形成了软件开发生命周期的概念。测试工作应该着眼于整个软件开发生命周期，特别是着眼于编码以前各开发阶段的工作来保证软件的质量。也就是说，测试应该从软件开发生命周期的第一个阶段开始，并贯穿于整个的软件开发生命周期。谈到测试，首先是为什么要进行测试的问题。所有的测试都是为了发现和消除软件的缺陷。明确为什么要进行软件测试的问题之后，就需要明确测试什么的问题。软件的开发有其自己的生命周期，在整个软件生命周期中，软件都有各自的相对于各生命周期的阶段性的输出结果，其中也包括需求分析、概要设计、详细设计及程序编码等各阶段所产生的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，而所有这些输出结果都应成为被测试的对象。随着人们对软件工程化的重视以及软件规模的日益扩大，软件分析、设计的作用越来越突出，而且有资料说明，60%以上的软件错误并不是程序错误，而是分析和设计错误。因此，做好软件需求和设计阶段的测试工作就显得非常重要。这就是传统的测试概念的扩大化，从而提出了软件全生命周期测试的概念。测试过程包括了软件开发生命周期的每个阶段。在需求阶段，重点要确认需求定义是否符合用户的需要；在设计和编程阶段，重点要确定设计和编程是否符合需求定义；在测试和安装阶段，重点是审查系统执行是否符合系统规格说明；在维护阶段，要重新测试系统，以确定更改的局部和没有更改的局部是否都正常工作。2.1.3软件测试的手段1．验证和确认通常在测试中，使用验证来检查中间可交付的结果，使用确认来评估可执行代码的性能。一般来说，验证答复这样的问题：“是否建立了正确的系统？〞，而确认答复的问题是：“建立的系统是否正确？〞。所谓验证，是指如何决定软件开发的每个阶段、每个步骤的产品是否正确无误，并与其前面的开发阶段和开发步骤的产品相一致。验证工作意味着在软件开发过程中开展一系列活动，旨在确保软件能够正确无误地实现软件的需求。所谓确认，是指如何决定最后的软件产品是否正确无误。2.2测试模型就像软件开发有过程模型一样，测试也有测试模型。描述以上测试过程的就是测试模型。最具有代表意义的测试模型称为V模型。V模型如图2-1所示。图2-1V模型示意图在开发过程中，从需求阶段到编码阶段，主要是采用验证手段进行测试，如需求评审、设计评审、代码走查以及代码审查等，从而完成对开发的中间结果的正确性的评估。编码完成并经过代码审查等测试之后，此时的测试主要在软件的可执行模式下进行，即利用确认手段进行测试，确认测试包括单元测试、集成测试、系统测试以及用户验收测试等，其相应的关系如图2-2所示。图2-2V模型中的测试2.3软件测试的分类按照不同的分类方法，软件测试可分为以下几种类型。1．按照开发阶段划分按照开发阶段划分，软件测试可分为单元测试、集成测试、系统测试和验收测试。2．按照测试实施组织划分按照测试实施组织划分，软件测试可分为开发方测试、用户测试〔β测试〕和第三方测试。2.4软件测试的原那么软件测试的原那么尚没有标准的说法，大多是经验之谈，一般有下面几条可作为测试的根本原那么。〔1〕所有的测试都应追溯到用户需求。〔2〕应当把“尽早地和不断地进行软件测试〞作为软件测试者的座右铭。〔3〕设计时应完成测试方案，详细的测试用例定义可在设计模型确定后开始，测试可在代码产生之前进行方案和设计。〔4〕pareto原那么：测试发现的错误中80%很可能起源于20%的模块中。应孤立这些疑点模块，进行重点测试。〔5〕完全测试是不可能的，测试需要终止。〔6〕应由独立的第三方来构造测试。〔7〕充分注意测试中的群集现象。〔8〕要尽量防止测试的随意性。〔9〕兼顾合理的输入和不合理的输入数据。〔10〕程序修改后要回归测试〔11〕应长期保存测试用例，直至系统废弃。2.5软件测试策略通常，制定软件测试策略要考虑如下的内容。〔1〕要使用的测试方法。〔2〕确定质量风险。〔3〕测试完成和测试成功所采用的评价标准。〔4〕有关资源要求或涉及进度的特殊考虑。〔5〕测试类型、评估标准以及测试方法。〔6〕确定资源。在软件测试策略所包含的内容中最主要的局部有两个，一是要进行的测试过程，另外一个就是要执行的测试类型。1．测试过程共分为以下4个过程。①单元测试②集成测试③系统测试④验收测试2．测试类型对于测试类型的说法多种多样，最多的能有30多种测试类型。而实际工作中很多测试是互相包含的。按照企业中实际工作需要，测试主要包含下面的类型。①功能测试②健壮性测试③接口测试④强度测试⑤压力测试⑥性能测试⑦用户界面测试⑧平安测试⑨可靠性测试⑩安装/反安装测试11.文档测试12.恢复测试13.兼容性测试14.α测试15.β测试2.6软件测试流程软件测试工作必须要通过制定测试方案、设计测试、实施测试、执行测试、评估测试几个阶段来完成。其流程如图2-4所示。图2-4软件测试流程2.6.1制定测试方案测试方案是对每个产品，或是对各个开发阶段的产品开展测试的策略。方案的目的是用来识别任务、分析风险、规划资源和确定进度。方案并不是一张时间进度表，而是一个动态的过程，最终以系列文档的形式确定下来。拟定软件测试方案需要测试工程管理人员的积极参与，这是因为主工程方案已经确定了整体工程的一个时间框架，软件测试作为阶段工作必须服从方案和资源上的约定。一般来说，一个完整的测试方案应该包含以下几个方面。〔1〕对测试范围〔即测试活动需要覆盖的范围〕的界定〔2〕风险确实定〔3〕资源的规划〔4〕时间表的制定2.6.2设计测试设计测试阶段要设计测试用例和测试过程，要保证测试用例完全覆盖测试需求。设计测试阶段最重要的是如何将测试需求分解，如何设计测试用例。1．如何对测试需求进行分解对测试需求进行分解需要反复检查并理解各种信息，和用户交流，理解他们的要求。可以按照以下步骤执行。〔1〕确定软件提供的主要任务。〔2〕对每个任务，确定完成该任务所要进行的工作。〔3〕确定从数据库信息引出的计算结果。〔4〕对于对时间有要求的交易，确定所要的时间和条件。〔5〕确定会产生重大意外的压力测试，包括内存、硬盘空间、高的交易率。〔6〕确定应用需要处理的数据量。〔7〕确定需要的软件和硬件配置。〔8〕确定其他与应用软件没有直接关系的商业交易。〔9〕确定安装过程。〔10〕确定没有隐含在功能测试中的用户界面要求。设计测试用例即设计针对特定功能或组合功能的测试方案，并编写成文档。测试用例应该表达软件工程的思想和原那么。传统的测试用例文档编写有两种方式。一种是填写操作步骤列表：将在软件上进行的操作步骤一步一步详细记录下来，包括所有被操作的工程和相应的值。另一种是填写测试矩阵：将被操作项作为矩阵中的一个字段，而矩阵中的一条条记录，那么是这些字段的值。评价测试用例的好坏有以下两个标准。①是否可以发现尚未发现的软件缺陷？②是否可以覆盖全部的测试需求？2．获得测试数据需要测试的常见情形如下。〔1〕正常事务的测试〔2〕使用无效数据的测试创立测试数据时主要考虑如下步骤。①识别测试资源②识别测试情形③排序测试情形④确定正确的处理结果⑤创立测试事务确定实际的测试数据时，必须说明处理测试数据的以下4个属性。〔1〕深度〔2〕宽度〔3〕范围〔4〕结构3．测试脚本概要所谓脚本，是完整的一系列相关终端的活动。一般测试脚本有5个级别，分别是：单元脚本，用于测试特定单元/模块的脚本；并发脚本，用于当两个或多个用户同时访问同一文件时测试的脚本；集成脚本，用于确定各模块是否可以前当连接；回归脚本，用于确定系统未改变的局部在系统改变时是否改变；强度/性能脚本，用于验证系统在被施加大量事务时的性能。〔3〕数据驱动的测试许多测试过程包括在给定的数据输入屏幕内输入几组字段数据，检查字段确认功能、错误处理等。〔4〕测试脚本同步和时间安排当进行重点测试时，通常需要同步测试脚本以便它们在预先确定的时间启动。〔5〕测试和调试测试脚本在记录测试脚本的同一测试软件上执行这些最近记录的测试脚本时，不应该发生任何错误。4．辅助测试工具为了实施高效的测试工作，还需要有高效、好用的辅助工具，做软件测试通常需要以下一些根本工具。①优秀的办公处理软件②秒表③错误跟踪系统④自动测试工具⑤软件分析工具⑥好的操作系统⑦多样化平台2.6.4执行测试执行测试是执行所有的或选定的一些测试用例，并观察其测试结果的过程。尽管为执行测试所做的准备和方案工作会贯穿于软件开发生命周期之中，但是执行测试往往都会在软件开发生命周期的末期，或者接近末期进行，即在编码完成之后进行。由于测试过程一般分成代码审查、单元测试、集成测试、系统测试和验收测试几个阶段，尽管这些阶段在实现细节方面都不相同，但其工作流程方面却是一致的。执行测试的过程由以下4个局部组成。①输入。要完成工作所必须的入口标准或可交付的结果。②执行过程。从输入到输出的过程或工作任务。③检查过程。确定输出是否满足标准的处理过程。④输出。推出标准或工作流程产生的可交付的结果。执行测试过程如图2-5所示。图2-5执行测试过程2.6.5评估测试软件测试的主要评测方法包括测试覆盖和质量评测。测试覆盖是对测试完全程度的评测，它是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。质量评测是对测试对象〔系统或测试的应用程序〕的可靠性、稳定性以及性能的评测，它建立在对测试结果的评估和对测试过程中确定的变更请求〔缺陷〕分析的根底上。1．覆盖评测覆盖指标提供了“测试的完全程度如何〞这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求〔基于需求的〕或代码的设计/实施标准〔基于代码的〕而言的完全程度的任意评测，如用例的核实〔基于需求的〕或所有代码行的执行〔基于代码的〕。2．质量评测测试覆盖的评估提供对测试完全程度的评测，在测试过程中已发现缺陷的评估提供了最正确的软件质量指标。3．性能评测评估测试对象的性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作可靠性和限制。2.7测试的成功经验在软件开发生命周期中，软件是通过迭代来不断加以完善的。在这种环境中，对于每个作为测试目标的工作版本，测试的生命周期还都必须具有一种迭代方法。对于针对每个工作版本执行的测试，都做出了增补和改进，并累积为一个测试体，用于后续阶段的回归测试。通过迭代是软件开发把原来的整个软件开发生命周期分成多个迭代周期，在每个迭代周期都进行测试，这样在很大程度上提前了软件系统测试发生的时间，这可以在很大程度上降低工程风险和工程开发本钱。3.1软件测试方法概述3.2白盒测试3.3黑盒测试3.4测试用例设计3.1软件测试方法概述软件测试的种类大致可分为人工测试和基于计算机的测试。而基于计算机的测试又可分为黑盒测试和白盒测试。1．黑盒测试黑盒测试是根据软件产品的功能设计规格，在计算机上进行测试，以证实每个已经实现的功能是否符合要求。黑盒测试意味着测试要在软件的接口处进行。2．白盒测试白盒测试是根据软件产品的内部工作过程，在计算机上进行测试，以证实每种内部操作是否符合设计规格要求，所有内部成分是否已经过检查。白盒测试把测试对象看做一个翻开的盒子，允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。3.2白盒测试白盒测试也称为结构测试或逻辑驱动测试，前提是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都能够按预定要求正确工作，而不管产品的功能，主要用于软件验证。白盒测试的动态测试要根据程序的控制结构设计测试用例，其原那么是：〔1〕保证一个模块中的所有独立路径至少被使用一次；〔2〕对所有逻辑值均需测试true和false；〔3〕在上下边界及可操作范围内运行所有循环；〔4〕检查内部数据结构以确保其有效性。下面将介绍几种实用的白盒测试用例设计方法，包括程序插桩、逻辑覆盖、根本路径测试等。3.2.1程序插桩在软件动态测试中，程序插桩是一种根本的测试手段，有着广泛的应用。1．方法简介程序插桩方法是借助往被测程序中插入操作，来实现测试目的的方法。图3-3插桩后求最大公约数程序的流程图设计插桩程序时需要考虑的问题包括：①探测哪些信息；②在程序的什么部位设置探测点；③需要设置多少个探测点。2．断言语句在程序中特定部位插入某些用以判断变量特性的语句，使得程序执行中这些语句得以证实，从而使程序的运行特性得到证实。我们把插入的这些语句称为断言。这一做法是程序正确性证明的根本步骤，尽管算不上严格的证明，但方法本身仍然是很实用的。请看下面的程序清单badptr.c：

#include<stdio.h>

#include<assert.h>

#include<stdlib.h>

intmain(void)

{

FILE*fp;

fp=fopen("test.txt","w");//以可写的方式翻开一个文件，如果不存在就创立一个同名文件

assert(fp);//所以这里不会出错

fclose(fp);

fp=fopen("noexitfile.txt","r");//以只读的方式翻开一个文件，如果不存在就翻开文件失败

assert(fp);//所以这里出错

fclose(fp);//程序永远都执行不到这里来

return0;

}

assert宏的原型定义在<assert.h>中，其作用是如果它的条件返回错误，那么终止程序执行从覆盖源程序语句的详细程度分析，逻辑覆盖标准有语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖和修正条件判定覆盖。为便于理解，使用如下所示的程序，图3-7所示的是其流程图。图3-7参考例子流程图intfunction1〔boola，boolb，boolc〕{intx;x=0;if(a&&(b||c))x=1;returnx;}1．语句覆盖SC〔StatementCoverage〕为了暴露程序中的错误，程序中的每条语句至少应该执行一次。所以，语句覆盖的含义是：选择足够多的测试数据，使被测程序中每条语句至少执行一次。2．判定覆盖DC〔Decisioncoverage〕比语句覆盖稍强的覆盖标准是判定覆盖。按判定覆盖准那么进行测试是指，设计假设干测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断的真假值均曾被满足。判定覆盖又称为分支覆盖。3．条件覆盖CC〔ConditionCoverage〕在设计程序中，一个判定语句是由多个条件组合而成的复合判定。条件覆盖的含义是：构造一组测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次。4．条件判定组合覆盖CDC〔Condition/DecisionCoverage〕条件判定组合覆盖的含义是：设计足够的测试用例，使得判定中每个条件的所有可能〔真/假〕至少出现一次，并且每个判定本身的判定结果〔真/假〕也至少出现一次。5．多条件覆盖MCC〔MultipleConditionCoverage〕多条件覆盖也称为条件组合覆盖，它的含义是：设计足够的测试用例，使得每个判定中条件的各种可能组合都至少出现一次。显然满足多条件覆盖的测试用例是一定满足判定覆盖、条件覆盖和条件判定组合覆盖的。6．修正条件判定覆盖MCDC〔MultipleConditionDecisionCoverage〕它要求满足两个条件：首先，每一个程序模块的入口和出口点都要考虑至少被调用一次，每个程序的判定到所有可能的结果值要至少转换一次；其次，程序的判定被分解为通过逻辑操作符〔and、or〕连接的bool条件，每个条件对于判定的结果值是独立的。7．测试覆盖准那么〔1〕Foster的ESTCA覆盖准那么前面所介绍的逻辑覆盖其出发点似乎是合理的。所谓“覆盖〞，就是想要做到全面而无遗漏。但是，事实说明，它并不能真的做到无遗漏。从测试工作实践的教训出发，吸收了计算机硬件的测试原理，提出了一种经验型的测试覆盖准那么：在容易发生问题的地方设计测试用例，即重视程序中谓词〔条件判断〕的取值。具体规那么：[规那么1]对于ArelB型(rel可以是<、=或>)的分支谓词，应适当的选择A与B的值，使得测试执行到该分支语句时，A<B、A=B、A>B的情况分别出现一次。——这是为了检测逻辑符号写错的情况，如将“A<B〞错写为“A>B〞。[规那么2]对于ArelC型(rel可以是>或<,A是变量，C是常量)的分支谓词：当rel为<时，应适当的选择A的值，使A=C-M〔M是距C最小的机器容许正数，假设A和C都为正整数时，M=1〕；当rel为>时，应适当的选择A的值，使A=C+M。——这是为了检测“差1〞之类的错误，如“A>1〞错写成“A>0〞。[规那么3]对外部输入变量赋值，使其在每一个测试用例中均有不同的值与符号，并与同一组测试用例中其他变量的值与符号不同。——这是为了检测程序语句中的错误，如应该引用某一变量而错成引用另一个常量。〔2〕Woodward等人的层次LCSAJ覆盖准那么Woodward等人曾经指出结构覆盖的一些准那么，如分支覆盖或路径覆盖，都缺乏以保证测试数据的有效性。为此，他们提出了一种层次LCSAJ覆盖准那么。LCSAJ覆盖准那么是一个分层的覆盖准那么，可以概括的描述为：第一层—语句覆盖。第二层—分支覆盖。第三层—LCSAJ覆盖，即程序中的每一个LCSAJ都至少在测试中经历过一次。第四层—两两LCSAJ覆盖，即程序中的每两个相连的LCSAJ组合起来在测试中都要经历一次。第n+2层—每n个首尾相连的LCSAJ组合在测试中都要经历一次。在实施测试时，假设要实现上述的层次LCSAJ覆盖，需要产生被测程序的所有LCSAJ。3.2.3根本路径测试上节的例子是个比较简单的程序段，只有两条路径。但在实际问题中，即使一个不太复杂的程序，其路径的组合都是一个庞大的数字。如果把覆盖的路径数压缩到一定限度内，例如，程序中的循环体只执行零次和一次，就成为根本路径测试。设计出的测试用例要保证在测试中程序的每一条可执行语句至少执行一次。1．程序的控制流图控制流图是描述程序控制流的一种图示方式。其中根本的控制结构对应的图形符号如图3-8所示。在图3-8所示的图形符号中，圆圈称为控制流图的一个结点，它表示一个或多个无分支的语句或源程序语句。图3-8控制流图的图形符号图3-9〔a〕所示的是一个程序的流程图，它可以映射成图〔b〕所示的控制流图。图3-9程序流程图和对应的控制流图2．计算程序环路复杂性进行程序的根本路径测试时，程序的环路复杂性给出了程序根本路径集合中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。所谓独立路径，是指包括假设干未曾处理的语句或条件的一条路径。根本路径集不是惟一的，对于给定的控制流图，可以得到不同的根本路径集。通常环路复杂性可用以下3种方法求得。①将环路复杂性定义为控制流图中的区域数。②设E为控制流图的边数，N为图的结点数，那么定义环路的复杂性为V(G)=E−N+2。③假设设P为控制流图中的判定结点数，那么有V(G)=P+1。3．根本路径测试法步骤根本路径测试法适用于模块的详细设计及源程序，其主要步骤如下。①以详细设计或源代码作为根底，导出程序的控制流图。②计算得到的控制流图G的环路复杂性V〔G〕。③确定线性无关的路径的根本集。④生成测试用例，确保根本路径集中每条路径的执行。3.2.4程序的静态测试1．源程序静态分析在静态结构分析中，测试者通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口、内部控制逻辑等内部结构，生成函数调用关系图、模块控制流图、内部文件调用关系图、子程序表、宏和函数参数表等各类图形图表，可以清晰地标识整个软件系统的组成结构，使其便于阅读与理解，然后可以通过分析这些图表，检查软件有没有存在缺陷或错误。通常采用以下一些方法进行源程序的静态分析。〔1〕生成各种引用表①标号交叉引用表②变量交叉引用表③子程序〔宏、函数〕引用表④等价表⑤常数表〔2〕错误静态分析错误静态分析主要用于确定在源程序中是否有某类错误或“危险〞结构。①类型和单位分析②引用分析③表达式分析④接口分析2．人工测试静态分析中进行人工测试的主要方法有桌前检查、代码审查和走查。经验说明，使用这种方法能够有效地发现30%～70%的逻辑设计和编码错误。〔1〕桌前检查由程序员自己检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析、检验，并补充相关的文档，目的是发现程序中的错误。〔2〕代码审查代码审查是由假设干程序员和测试员组成一个审查小组，通过阅读、讨论和争议，对程序进行静态分析的过程。代码审查分两步。第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、标准等分发给小组成员，作为审查的依据。小组成员在充分阅读这些材料后，进入审查的第二步，召开程序审查会。〔3〕走查走查与代码审查根本相同，其过程分为两步。第一步也把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。开会的程序与代码审查不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当〞计算机，即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论用。3.2.5其他白盒测试方法简介1．域测试域测试是一种基于程序结构的测试方法。域测试正是在分析输入域的根底上，选择适当的测试点以后进行测试的。2．符号测试符号测试的根本思想是允许程序的输入不仅仅是具体的数值数据，而且包括符号值，这一方法也因此而得名。3．Z路径覆盖分析程序中的路径是指检验程序从入口开始，执行过程中经历的各个语句，直到出口。4．程序变异程序变异方法是一种错误驱动测试。所谓错误驱动测试方法，是指该方法是针对某类特定程序错误的。经过多年的测试理论研究和软件测试的实践，人们逐渐发现要想找出程序中所有的错误几乎是不可能的。比较现实的解决方法是将错误的搜索范围尽可能地缩小，以利于专门测试某类错误是否存在。错误驱动测试主要有两种，即程序强变异和程序弱变异。最后，归纳一下白盒测试中各种测试方法的应用策略。在白盒测试中，可以使用各种测试方法的综合策略如下。〔1〕在测试中，应尽量先使用工具进行静态结构分析。〔2〕测试中可采取先静态后动态的组合方式：先进行静态结构分析、代码检查，再进行覆盖率测试。〔3〕利用静态分析的结果作为导引，通过代码检查和动态测试的方式对静态发现结果进行进一步确实认，使测试工作更为有效。〔4〕覆盖率测试是白盒测试的重点，一般可使用根本路径测试法到达语句覆盖标准；对于软件的重点模块，应使用多种覆盖率标准衡量代码的覆盖率。〔5〕在不同的测试节点，测试的侧重点不同：在单元测试阶段，以代码检查、逻辑覆盖为主；在集成测试阶段，需要增加静态结构分析等；在系统测试阶段，应根据黑盒测试的结果，采取相应的白盒测试。3.3黑盒测试黑盒测试也称功能测试或数据驱动测试，前提是产品所具有的功能，通过测试来检测每个功能是否都正常使用。黑盒测试方法主要有等价类划分、边界值分析、因果图、错误推测、功能图法等，主要用于软件确认测试。3.3.1等价类划分法等价类划分是一种典型的黑盒测试方法。使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。由于不可能用所有可以输入的数据来测试程序，而只能从全部可供输入的数据中选择一个自己进行测试。如何选择适当的子集，使其尽可能多地发现错误，解决的方法之一就是等价类划分。首先，把数目极多的输入数据，包括有效的和无效的，划分为假设干等价类，而所谓等价类，是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等价于对这一类其他值的测试。因此，可以把全部输入数据合理划分为假设干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可用少量代表性测试数据，取得较好的测试结果。等价类的划分有以下两种不同的情况。①有效等价类②无效等价类划分等价类的原那么如下。①按区间划分②按数值划分③按数值集合划分④按限制条件或规那么划分在确立了等价类之后，建立等价类表，列出所有划分出的等价类，如表3-6所示。再从划分出的等价类中按以下原那么选择测试用例。①为每一个等价类规定一个惟一的编号。②设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类；重复这一步骤，直到所有的有效等价类都被覆盖为止。③设计一个新的测试用例，使其仅覆盖一个无效等价类，重复这一步骤，直到所有的无效等价类都被覆盖为止。3.3.2边界值分析法人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。选择测试用例的原那么如下。①如果输入条件规定了值的范围，那么应该取刚到达这个范围的边界值，以及刚刚超过这个范围边界的值作为测试输入数据。②如果输入条件规定了值的个数，那么用最大个数、最小个数、比最大个数多1个、比最小个数少1个的数作为测试数据。③根据规格说明的每一个输出条件，使用规那么1。④根据规格说明的每一个输出条件，使用规那么2。⑤如果程序的规格说明给出的输入域或输出域是有序集合〔如有序表、顺序文件等〕，那么应选取集合的第一个和最后一个元素作为测试用例。⑥如果程序用了一个内部结构，应该选取这个内部数据结构的边界值作为测试用例。⑦分析规格说明，找出其他可能的边界条件。3.3.3错误推测法人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。这就是错误推测法。错误推测法的根本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。3.3.4因果图法因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。利用因果图生成测试用例的根本步骤如下。①分析软件规格说明的描述中哪些是原因，哪些是结果。原因是输入条件或输入条件的等价类，结果是输出条件。②分析软件规格说明描述中的语义，找出原因与结果之间、原因与原因之间对应的关系，根据这些关系，画出因果图。③标明约束条件。由于语法或环境的限制，有些原因和结果的组合情况是不可能出现的。为说明这些特定的情况，在因果图上使用假设干标准的符号标明约束条件。④把因果图转换成判定表。⑤为判定表中的每一列设计测试用例。通常在因果图中，用Ci表示原因，Ei表示结果，其根本符号如图3-12所示。图3-12因果图的根本符号对于黑盒测试方法来说，以上4种方法是根本的测试方法，除此之外还有判定表驱动法、正交试验法、功能图法和场景法等。在实际测试中，往往是综合使用各种方法才能有效地提高测试效率和测试覆盖率，这就需要认真掌握这些方法的原理，积累更多的测试经验，以有效地提高测试水平。以下是各种测试方法选择的综合策略，可供读者在实际应用过程中参考。①首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效的方法。②在任何情况下都必须使用边界值分析方法。经验说明，用这种方法设计出的测试用例发现程序错误的能力最强。③可以用错误推测法追加一些测试用例，这需要依靠测试工程师的智慧和经验。④对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有到达要求的覆盖标准，应当再补充足够的测试用例。⑤如果程序的功能说明中含有输入条件的组合情况，那么一开始就可选用因果图法和判定表驱动法。⑥对于参数配置类的软件，要用正交试验法选择较少的组合方式到达最正确效果。⑦功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据。⑧对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。3.3.5场景法现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有根本流和备选流。1．根本流和备选流如图3-14所示，图中经过用例的每条路径都用根本流和备选流来表示，直黑线表示根本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从根本流开始，在某个特定条件下执行，然后重新参加根本流中〔如备选流1和3〕；也可能起源于另一个备选流〔如备选流2〕，或者终止用例而不再重新参加到某个流〔如备选流2和4〕。图3-14根本流和备选流2．ATM例子〔1〕例子描述图3-15所示是ATM例子的流程示意图。图3-15ATM流程示意图〔2〕场景设计表3-8所示是生成的场景。〔3〕用例设计对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列那么代表测试用例的信息。本例如中，对于每个测试用例，存在一个测试用例ID、条件〔或说明〕、测试用例中涉及的所有数据元素〔作为输入或已经存在于数据库中〕以及预期结果。〔4〕数据设计一旦确定了所有的测试用例，那么应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。测试用例一经认可，就可以确定实际数据值〔在测试用例实施矩阵中〕并且设定测试数据，如表3-10所示。3.4测试用例设计

3.4.1测试用例的根本概念简单地说，测试用例就是设计一个情况，软件程序在这种情况下，必须能够正常运行并且到达程序所设计的执行结果。如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示已经测出软件有缺陷，这时候就必须将这个问题标示出来，并且输入到问题跟踪系统内，通知软件开发人员。软件开发人员接到通知后，将问题修改完成于下一个测试版本内，测试工程师取得新的测试版本后，必须利用同一个测试用例来测试这个问题，确保该问题已修改完成。在测试时，不可能进行穷举测试，为了节省时间和资源，提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。使用测试用例的好处主要表达在以下几个方面。①在开始实施测试之前设计好测试用例，可以防止盲目测试并提高测试效率。②测试用例的使用令软件测试的实施重点突出、目的明确。③在软件版本更新后只需修正少局部的测试用例便可开展测试工作，降低工作强度，缩短工程周期。④功能模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化那么会使软件测试易于开展，并随着测试用例的不断精化其效率也不断提高。测试用例主要有如下几种。①功能测试用例。包含功能测试、健壮性测试、可靠性测试。②性能测试用例。包含性能测试、压力测试、强度测试。③集成测试用例。包含接口测试、健壮性测试、可靠性测试。④平安测试用例。平安测试用例。⑤用户界面测试用例。用户界面测试用例、少量功能测试用例。⑥安装/反安装测试用例。安装/反安装测试用例。测试种类、阶段和用例的关系如表3-11所示。测试工作和开发通常一同进行，所以在完成测试方案编写后，就可以进行用例的编写工作了。测试和开发的对应关系如表3-12所示。3.4.2测试用例的设计步骤测试按照阶段分为单元测试、集成测试以及系统测试。而各阶段都有相应的测试用例。这里，以单元测试的用例设计为依据来说明测试用例的设计步骤。单元测试说明实际上由一系列单元测试用例组成，每个测试用例应该包含以下4个关键元素。①被测单元模块初始状态声明，即测试用例的开始状态〔仅适用于被测单元维持了调用间状态的情况〕。②被测单元的输入，包含由被测单元读入的任何外部数据值。③该测试用例实际测试的代码，用被测单元的功能和测试用例设计中使用的分析来说明，如单元中哪一个决策条件被测试。④测试用例的期望输出结果。测试用例的期望输出结果总是应该在测试进行之前在测试说明中定义。最后，总结一下用例设计的一般原那么。通常应该防止依赖先前测试用例的输出，测试用例的执行序列早期发现的错误可能导致其他的错误而减少测试执行时实际测试的代码量。测试用例设计过程中，包括作为试验执行这些测试用例时，常常可以在软件构建前就发现BUG。还有可能在测试设计阶段比测试执行阶段发现更多的BUG。

在整个单元测试设计中，主要的输入应该是被测单元的设计文档。在某些情况下，需要将试验实际代码作为测试设计过程的输入，测试设计者必须意识到不是在测试代码本身。3.4.3测试用例的编写1．测试用例方案的编写2．测试设计说明3．测试用例说明测试用例的编写请参考表3-13。表3-13 测试用例

4．测试程序说明图3-16所示是“Windows计算器〞的测试程序说明的例子片断。图3-16测试程序说明片断3.4.4测试用例设计实例1．软件设计说明导出的测试2．根本路径测试3．等价类划分4．因果图法5．边界值分析3.4.5测试用例的管理可以把测试用例看成程序——测试工程师编写的程序，这个程序也要经过“设计〞、“开发〞、“测试〞、“版本管理〞、“发布〞、“维护〞等一系列操作。1．用例评审有效的用例评审通常由下面两种形式组成。①测试部门外部评审②测试部门内部评审通常情况下先执行内部评审，然后执行外部评审。很多时候，内部评审会被忽略，建议要进行内部评审。2．用例管理版本管理是用例管理的核心局部，建议采用工具〔例如VisualSourceSafe〕对用例进行控制。建议用例参照图3-19进行管理。图3-19用例管理示意图第4章

软件测试过程4.1软件测试过程概述4.2单元测试4.3集成测试4.4系统测试4.5验收测试4.6回归测试4.7系统排错4.1软件测试过程概述软件测试过程与软件工程的开发过程是相对的。第2章图2-1采用V形图表示软件开发与软件测试的对应关系，也可以采用图4-1所示的螺旋形图来表示这种关系。图4-1测试过程4.2单元测试单元测试是对软件设计的最小单元——模块进行正确性检验的测试工作，主要测试模块在语法、格式和逻辑上的错误。单元测试应对模块内所有重要的控制路径进行测试，以便发现模块内部的错误。单元测试是检查软件源程序的第一次时机，通过孤立地测试每个单元，确保每个单元工作正常，这样比单元作为一个更大系统的一个局部更容易发现问题。在单元测试中，每个程序模块可以并行、独立地进行测试工作。4.2.1单元测试的主要任务单元测试是针对每个程序模块进行测试，单元测试的主要任务是解决以下5个方面的测试问题。1．模块接口测试针对模块接口测试应进行的检查，主要涉及以下几方面的内容。①模块接受输入的实际参数个数与模块的形式参数个数是否一致。②输入的实际参数与模块的形式参数的类型是否匹配。③输入的实际参数与模块的形式参数所使用单位是否一致。④调用其他模块时，所传送的实际参数个数与被调用模块的形式参数的个数是否相同。⑤调用其他模块时，所传送的实际参数与被调用模块的形式参数的类型是否匹配。⑥调用其他模块时，所传送的实际参数与被调用模块的形式参数的单位一致。⑦调用内部函数时，参数的个数、属性和次序是否正确。⑧在模块有多个入口的情况下，是否有引用与当前入口无关的参数。⑨是否会修改了只读型参数。⑩出现全局变量时，这些变量是否在所有引用它们的模块中都有相同的定义。11.有没有把某些约束当做参数来传送。2．模块局部数据结构测试3．模块中所有独立执行路径测试4．各种错误处理测试5．模块边界条件测试4.2.2单元测试的执行过程一般情况下，在完成了程序编写、复查和语法正确性验证后，就应进行单元测试。测试用例设计应与复审工作相结合，根据设计信息选取数据，将增大发现上述各类错误的可能性。在进行单元测试时，需设置假设干辅助测试模块。辅助模块有两种，一种是驱动模块〔Driver〕，用以模拟被测试模块的上级模块。另一种是被调用模拟子模块〔Sub〕，用以模拟被测模块工作过程中所调用的模块。图4-2显示了一般的单元测试环境。图4-2一般单元测试环境单元测试中使用的数据，通常不使用真实数据。当被测试单元的功能不涉及操纵或使用大量数据时，测试中可以使用有代表性的一小局部手工制作的测试数据。在创立测试数据时，应确保数据充分地测试单元的边界条件。当被测试单元要操纵大量数据，并且有很多单元都有这种需求时，可以考虑使用真实数据的一个较小的有代表性的样本。测试时还要考虑往样本数据中引入一些手工制作的数据，以便测试单元的某个具体特性，例如对错误条件的响应等。当测试一个单元要从远程数据源接收数据时〔例如，从一个客户端/效劳器系统中接收数据〕，有必要在单元测试中使用测试辅助程序，来模拟对这些数据的访问。但在考虑这种选择时，必须首先对开发的测试辅助程序进行测试，以保证模拟的真实性。4.3集成测试将经过单元测试的模块按设计要求连接起来，组成所规定的软件系统的过程称为“集成〞。①将各模块连接起来，检查模块相互调用时，数据经过接口是否丧失。②将各个子功能组合起来，检查能否到达预期要求的各项功能。③一个模块的功能是否会对另一个模块的功能产生不利的影响。④全局数据结构是否有问题，会不会被异常修改。⑤单个模块的误差积累起来，是否被放大，从而到达不可接受的程度。4.3.2集成测试方法集成测试包括两种不同方法：非增量式集成和增量式集成。1．非增量式测试方法概括来说，非增量式测试方法是采用一步到位的方法来进行测试，即对所有模块进行个别的单元测试后，按程序结构图将各模块连接起来，把连接后的程序当做一个整体进行测试。图4-3给出的是采用这种非增量式的集成测试方法的一个经典例子。2．增量式测试方法〔1〕自顶向下增量式测试自顶向下增量式测试表示逐步集成和逐步测试是按结构图自上而下进行的。即模块集成的顺序是首先集成主控模块〔主程序〕，然后按照软件控制层次结构向下进行集成。图4-4自顶向下集成集成测试的整个过程由以下3个步骤完成。①主控模块作为测试驱动器，把对主控模块进行单元测试时引入的被调用模拟子模块用实际模块替代。②依照所选用的模块集成策略〔深度优先和广度优先〕，下层的被调用模拟子模块一次一个地被替换为真正的模块。③在每个模块被集成时，都必须立即进行测试一遍。回到第2步重复进行，直到整个系统结构被集成完成。图4-5给出了一个按广度优先策略进行集成测试的典型例子。图4-5自顶向下增量式测试〔广度优先策略〕〔2〕自底向上增量式测试自底向上增量式测试是从最底层的模块开始，按结构图自下而上逐步进行集成和测试。图4-6表示了采用自底向上增量式测试实现同一实例的过程。图4-6自底向上增量式测试执行集成测试应遵循下面的方法。①确认组成一个完整系统的模块之间的关系。②评审模块之间的交互和通信需求，确认出模块间的接口。③使用上述信息产生一套测试用例。④采用增量式测试，依次将模块参加到〔扩充〕系统，并测试新合并后的系统，这个过程以一个逻辑/功能顺序重复进行，直至所有模块被功能集成进来形成完整的系统为止。此外，在测试过程中尤其要注意关键模块，所谓关键模块一般都具有下述一个或多个特征。①对应几条需求。②具有高层控制功能。③复杂，易出错。④有特殊的性能要求。因为集成测试的主要目的是验证组成软件系统的各模块的接口和交互作用，因此集成测试对数据的要求无论从难度和内容来说一般不是很高。集成测试一般也不使用真实数据，测试人员可以使用手工制作一局部代表性的测试数据。在创立测试数据时，应保证数据充分测试软件系统的边界条件。在单元测试时，根据需要生成了一些测试数据，在集成测试时可适当地重用这些数据，这样可节省时间和人力。4.3.4集成测试遵循的原那么集成测试很不好把握，应针对总体设计尽早开始筹划。为了做好集成测试，需要遵循以下原那么。①所有公共接口都要被测试到。②关键模块必须进行充分的测试。③集成测试应当按一定的层次进行。④集成测试的策略选择应当综合考虑质量、本钱和进度之间的关系。⑤集成测试应当尽早开始，并以总体设计为根底。⑥在模块与接口的划分上，测试人员应当和开发人员进行充分的沟通。⑦当接口发生修改时，涉及的相关接口必须进行再测试。⑧测试执行结果应当如实记录。在集成测试过程中，测试过程由一个独立测试观察员来监控测试工作。集成测试过程中应考虑邀请一个用户代表非正式地观看集成测试。4.4系统测试集成测试通过以后，软件已经组装成一个完整的软件包，这时就要进行系统测试。4.4.1系统测试的任务系统测试一般要完成以下几种测试。1．功能测试2．性能测试3．恢复测试4．平安测试5．强度测试6．其他限制条件的测试4.5验收测试系统测试完成后，并使系统试运行了预定的时间，应进行验收测试。4.5.1验收测试的主要任务软件验收测试应完成的主要测试工作包括以下几方面。1．文档资料的审查验收2．功能测试3．性能测试4．强化测试5．性能降级执行方式测试6．检查系统的余量要求7．安装测试8．用户操作测试只要有可能，在验收测试中就应该使用真实数据。当真实数据中包含机密性或平安性信息，并且这些数据在局部或整个验收测试中可见时，就必须采取以下措施来保证。①用户代表被允许使用这些数据，或者合理地组织测试使测试组长不必看到这些数据也可进行测试。②测试观察员被允许使用这些数据，或者能够在看不到这些数据的情况下确认并记录测试用例的成功或失败。4.5.4α、β测试软件开发设计人员在软件开发设计时，不可能完全预见用户实际使用软件系统的情况。另外，一个软件产品可能拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以发现那些似乎只有最终用户才能发现的问题。α测试是在软件开发公司内模拟软件系统的运行环境下的一种验收测试，即软件开发公司组织内部人员，模拟各类用户行为对即将面市的软件产品〔称为α版本〕进行测试，试图发现并修改错误。经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况，提出批评意见。然后软件开发公司再对β版本进行改错和完善。所以，一些软件开发公司把α测试看成是对一个早期的、不稳定的软件版本所进行的验收测试，而把β测试看成是对一个晚期的、更加稳定的软件版本所进行的验收测试。4.6回归测试回归测试是指软件系统被修改或扩充〔如系统功能增强或升级〕后重新进行的测试，是为了保证对软件所做的修改没有引入新的错误而重复进行的测试。每当软件增加了新的功能，或者软件中的缺陷被修正，这些变更都有可能影响软件原有的功能和结构。为了防止软件的变更产生无法预料的副作用，不仅要对内容进行测试，还要重复进行过去已经进行过的测试，以证明修改没有引起未曾预料的后果，或证明修改后的软件仍能满足具体的需求。在理想的测试环境中，程序每改变一次，测试人员都重新执行回归测试，一方面来验证新增加或修改功能的正确性，另一方面测试人员还要从以前的测试中选取大量的测试以确定是否在实现新功能的过程中引入了缺陷。图4-7说明了回归测试和V模型之间的关系。图4-7回归测试和V模型回归测试特别适用于较高阶段的测试过程，回归测试一般多在系统测试和验收测试环境下进行，以确保整个软件系统新的构造或新的版本仍然运行正确，或者确保软件系统的现有业务功能完好无损。④典型的产生错误的知识，如被零除错误；⑤通用的测试经验规那么。设计和引入回归测试数据的重要原那么是，应保证数据中可能影响测试的因素与未经修改扩充的原软件上进行测试时的哪些因素尽可能一致，否那么要想确定观测到的测试结果是由于数据变化还是很困难的。4.6.2回归测试的范围在回归测试范围的选择上，一个最简单的方法是每次回归执行所有在前期测试阶段建立的测试，来确认问题修改的正确性，以及没有造成对其他功能的不利影响。常用的用例选择方法可以分为以下3种。〔1〕局限在修改范围内的测试〔2〕在受影响功能范围内回归〔3〕根据一定的覆盖率指标选择回归测试在回归测试过程中，测试过程由一个测试观察员来监控测试工作。在回归测试完成时测试组组长负责整理并归档大量的回归测试结果，包括测试结果记录、回归测试日志和简短的回归测试总结报告。4.7系统排错系统测试的目的是为了发现尽可能多的错误，系统排错的任务就是根据测试时所发现的错误，找出原因和具体的位置，并进行改正。排错工作主要由程序开发人员进行，也就是说，谁开发的程序由谁来排错。1．排错过程2．排错方法下面简要介绍常用的3种排错方法。①原始类排错方法是最常用也是最低效的方法，只有在万般无奈的情况下才使用它，主要思想是“通过计算机找错〞。②回溯法能成功地用于程序的排错。③归纳和演绎法采用“分治〞的概念，首先基于错误出现有关的所有数据，假想一个错误原因，用这些数据证明或反驳它；或者一次列出所有可能的原因，通过测试一一排除。只要某次测试结果说明某种假设已呈现倪端，那么立即精化数据，进一步进行深入的测试。前面屡次提到，修改一处老问题可能引入几处新问题，有时程序越改越乱，但假设能做到每次纠错前都细心注意以下3个问题，情况将大为改观。①导致这个错误的原因在程序其他局部还可能存在吗？②本次修改可能对程序中相关的逻辑和数据造成什么影响？引起什么问题？③上次遇到的类似问题是如何排除的？第5章软件测试报告与测试评价5.1软件缺陷的概念和种类5.2正确面对软件缺陷5.3软件缺陷的生命周期5.4软件缺陷的严重性和优先级5.5报告软件缺陷5.6别离和再现软件缺陷5.7测试总结报告5.8测试的评测软件测试是在软件开发的过程中，对软件产品进行质量控制，目的是保证软件产品的最终质量。一般来说软件测试应严格按照软件测试流程，制定测试方案、测试方案、测试标准，实施测试，对测试数据进行记录，并根据测试情况撰写测试报告。测试报告主要是报揭发现的软件缺陷。测试评价主要包括覆盖评价以及质量和性能评价。覆盖评价是对测试完全程度的评测；质量和性能评价是对测试的软件对象的性能、稳定性以及可靠性的评测。5.1软件缺陷的概念和种类软件缺陷简单说就是存在于软件〔文档、数据、程序〕之中的那些不希望，或不可接受的偏差，而导致软件产生的质量问题。按照一般的定义，只要符合下面5个规那么中的一个，就叫做软件缺陷。软件未到达软件规格说明书中规定的功能；软件超出软件规格说明书中指明的范围；软件未到达软件规格说明书中指出的应到达的目标；软件运行出现错误；软件测试人员认为软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。在软件测试过程中如何判断软件缺陷，软件缺陷都有哪些种类？〔1〕功能不正常〔2〕软件在使用上不方便〔3〕软件的结构未做良好规划〔4〕功能不充分〔5〕与软件操作者的互动不良〔6〕使用性能不佳〔7〕未做好错误处理〔8〕边界错误〔9〕计算错误〔10〕使用一段时间所产生的错误〔11〕控制流程的错误〔12〕在大数据量压力之下所产生的错误〔13〕在不同硬件环境下产生的错误〔14〕版本控制不良所产生的错误〔15〕软件文档的错误5.2正确面对软件缺陷在软件测试过程中，软件测试人员必须确保测试过程发现的软件缺陷得以关闭。测试是为了证明程序有错，而不是证明程序没错。不管测试方案多么完善和执行测试多么努力，也不能保证所有软件缺陷发现了就能修复。有些软件缺陷可能会完全被忽略，还有一些可能推迟到软件后续版本中修复。有些软件缺陷不被修复的原因如下。〔1〕没有足够的时间〔2〕不算真正的软件缺陷〔3〕修复的风险太大〔4〕不值得修复虽然软件测试人员需要对自己找出的软件缺陷保持一种平常心态，但同时又必须坚持有始有终的原