软件测试技术学习课件PPT 605页

'软件测试 课程内容第1章软件工程与软件测试第2章软件测试的基本知识第3章软件测试的方法和技术第4章软件测试过程第5章软件测试报告与测试评价第6章软件测试项目管理第7章软件测试自动化与软件测试工具第8章软件测试实例 第1章软件工程与软件测试1.1软件工程1.2软件质量1.3软件测试1.4软件测试人员的基本素质 严格地说，软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程。通俗地说，软件工程是实现一个大型程序的一套原则方法，即按工程化的原则和方法组织软件开发工作。软件测试是软件工程的一个重要环节，相当于工程领域中的质量检验部分，是确保软件工程质量的重要手段。 1.1软件工程1.1.1软件工程的目标及其一般开发过程一个软件产品从形成概念开始，经过开发、使用和维护，直到最后退出使用的全过程称为软件生存周期。软件生存周期根据软件所处的状态，以及软件开发活动的目的和任务，可划分为若干个阶段。一般软件生存周期包括软件定义、软件开发以及软件使用与维护3个部分。 1．软件定义可行性分析的任务是了解用户的要求及实现环境，从技术、经济和社会等几个方面研究并论证软件系统的可行性。需求分析的任务是确定所要开发软件的功能需求、性能需求和运行环境约束，编制软件需求规格说明、软件系统的确认测试准则。软件的性能需求包括软件的适应性、安全性、可靠性、可维护性错误处理等。 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软件测试的定义及目的简单地说，软件测试就是为了发现错误而执行程序的过程。 在IEEE提出的软件工程标准术语中，软件测试被定义为：“使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清楚预期结果与实际结果之间的差别。”软件测试是与软件质量密切联系在一起的，归根结底，软件测试是为了保证软件质量。 软件测试是一个找错的过程。软件测试的过程亦是程序运行的过程。程序运行需要数据，为测试设计的数据称为测试用例。测试用例的设计原则是尽可能暴露程序中的错误。 软件是由人来完成的，所有由人做的工作都不会是完美无缺的。软件开发是个很复杂的过程，期间很容易产生错误。无论是软件从业人员、专家和学者做了多大的努力，软件错误仍然存在。因而大家也得到了一种共识：软件中残存着错误，这是软件的一种属性，是无法改变的。所以通常说软件测试的目的就是为了发现尽可能多的缺陷，并期望通过改错来把缺陷统统消灭，以期提高软件的质量。一个成功的测试用例在于发现了至今尚未发现的缺陷。 软件测试的目的是以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险。 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在《系统的软件测试》一书中对软件测试做了进一步定义：“测试是为了度量和提高被测软件的质量，对测试软件进行工程设计、实施和维护的整个生命周期过程”。这些经典论著对软件测试研究的理论化和体系化产生了巨大的影响。 近20年来，随着计算机和软件技术的飞速发展，软件测试技术的研究也取得了很大的突破，测试专家总结了很好的测试模型，如著名的V模型，在单元测试、自动化测试等方面涌现了大量优秀的软件测试工具。 虽然软件测试技术的发展很快，但是其发展速度仍落后于软件开发技术的发展速度，使得软件测试在今天面临着很大的挑战，主要体现在以下几个方面。①软件在国防现代化、社会信息化和国民经济信息化领域中的作用越来越重要，由此产生的测试任务越来越繁重。②软件规模越来越大，功能越来越复杂，如何进行充分而有效的测试成为难题。 ③面向对象的开发技术越来越普及，但是面向对象的测试技术却刚刚起步。④对分布式系统的整体性能还不能进行很好的测试。⑤对实时系统缺乏有效的测试手段。⑥随着安全问题的日益突出，对信息系统的安全性如何进行有效的测试与评估，成为世界性难题。 根据国内外软件测试的发展现状，可以看到软件测试有以下的发展趋势。①测试工作将进一步前移。②软件架构师、开发工程师、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.1软件测试中使用的各种术语①软件错误②软件缺陷③软件故障④软件失效 2.1.2软件测试贯穿于整个的软件开发生命周期20世纪70年代中期以来，形成了软件开发生命周期的概念。测试工作应该着眼于整个软件开发生命周期，特别是着眼于编码以前各开发阶段的工作来保证软件的质量。也就是说，测试应该从软件开发生命周期的第一个阶段开始，并贯穿于整个的软件开发生命周期。 谈到测试，首先是为什么要进行测试的问题。所有的测试都是为了发现和消除软件的缺陷。明确为什么要进行软件测试的问题之后，就需要明确测试什么的问题。 软件的开发有其自己的生命周期，在整个软件生命周期中，软件都有各自的相对于各生命周期的阶段性的输出结果，其中也包括需求分析、概要设计、详细设计及程序编码等各阶段所产生的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，而所有这些输出结果都应成为被测试的对象。 随着人们对软件工程化的重视以及软件规模的日益扩大，软件分析、设计的作用越来越突出，而且有资料表明，60%以上的软件错误并不是程序错误，而是分析和设计错误。因此，做好软件需求和设计阶段的测试工作就显得非常重要。这就是传统的测试概念的扩大化，从而提出了软件全生命周期测试的概念。 测试过程包括了软件开发生命周期的每个阶段。在需求阶段，重点要确认需求定义是否符合用户的需要；在设计和编程阶段，重点要确定设计和编程是否符合需求定义；在测试和安装阶段，重点是审查系统执行是否符合系统规格说明；在维护阶段，要重新测试系统，以确定更改的部分和没有更改的部分是否都正常工作。 2.1.3软件测试的手段1．验证和确认通常在测试中，使用验证来检查中间可交付的结果，使用确认来评估可执行代码的性能。一般来说，验证回答这样的问题：“是否建立了正确的系统？”，而确认回答的问题是：“建立的系统是否正确？”。 所谓验证，是指如何决定软件开发的每个阶段、每个步骤的产品是否正确无误，并与其前面的开发阶段和开发步骤的产品相一致。验证工作意味着在软件开发过程中开展一系列活动，旨在确保软件能够正确无误地实现软件的需求。所谓确认，是指如何决定最后的软件产品是否正确无误。 2．功能和结构测试当测试人员测试项目小组的解决方案时，将利用验证和确认技术完成功能和结构测试。功能测试通常也被称为黑盒测试，因为测试案例中都不涉及系统的内部逻辑。 相反，结构测试通常被称为白盒测试，因为系统的内部逻辑常被用于假想的测试案例。结构测试主要使用验证技术。如上所述，测试人员用验证技术，通过评审系统的结构和逻辑来确认系统的合理性。而确认要严格应用于物理测试，来确定是否产生了预期的结果。执行结构测试将主要使用验证技术，而执行功能测试则主要使用确认技术。 2.2测试模型就像软件开发有过程模型一样，测试也有测试模型。描述以上测试过程的就是测试模型。最具有代表意义的测试模型称为V模型。V模型如图2-1所示。 图2-1V模型示意图 在开发过程中，从需求阶段到编码阶段，主要是采用验证手段进行测试，如需求评审、设计评审、代码走查以及代码审查等，从而完成对开发的中间结果的正确性的评估。编码完成并经过代码审查等测试之后，此时的测试主要在软件的可执行模式下进行，即利用确认手段进行测试，确认测试包括单元测试、集成测试、系统测试以及用户验收测试等，其相应的关系如图2-2所示。 图2-2V模型中的测试 2.3软件测试的分类按照不同的分类方法，软件测试可分为以下几种类型。1．按照开发阶段划分按照开发阶段划分，软件测试可分为单元测试、集成测试、系统测试和验收测试。 2．按照测试实施组织划分按照测试实施组织划分，软件测试可分为开发方测试、用户测试（β测试）和第三方测试。 3．按照测试技术划分按照测试技术划分，软件测试可分为白盒测试和黑盒测试，也可分为静态测试和动态测试。 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．如何设计测试用例测试用例一般指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。值得提出的是，测试数据都是从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的。测试用例是软件测试系统化、工程化的产物，而测试用例的设计一直是软件测试工作的重点和难点。 设计测试用例即设计针对特定功能或组合功能的测试方案，并编写成文档。测试用例应该体现软件工程的思想和原则。 传统的测试用例文档编写有两种方式。一种是填写操作步骤列表：将在软件上进行的操作步骤一步一步详细记录下来，包括所有被操作的项目和相应的值。另一种是填写测试矩阵：将被操作项作为矩阵中的一个字段，而矩阵中的一条条记录，则是这些字段的值。 评价测试用例的好坏有以下两个标准。①是否可以发现尚未发现的软件缺陷？②是否可以覆盖全部的测试需求？ 2.6.3实施测试实施测试是指准备测试环境、获得测试数据、开发测试规程，以及为该过程挑选和准备辅助测试工具的过程。1．准备测试环境（1）测试技术准备（2）配置软件、硬件环境（3）人员 2．获得测试数据需要测试的常见情形如下。（1）正常事务的测试（2）使用无效数据的测试 创建测试数据时主要考虑如下步骤。①识别测试资源②识别测试情形③排序测试情形④确定正确的处理结果⑤创建测试事务 确定实际的测试数据时，必须说明处理测试数据的以下4个属性。（1）深度（2）宽度（3）范围（4）结构 3．测试脚本概要所谓脚本，是完整的一系列相关终端的活动。一般测试脚本有5个级别，分别是：单元脚本，用于测试特定单元/模块的脚本；并发脚本，用于当两个或多个用户同时访问同一文件时测试的脚本；集成脚本，用于确定各模块是否可以前当连接；回归脚本，用于确定系统未改变的部分在系统改变时是否改变；强度/性能脚本，用于验证系统在被施加大量事务时的性能。 （1）测试脚本的结构为了提高测试脚本的可维护性和可复用性，必须在执行测试脚本之前对它们进行构建。（2）记录技术为使测试脚本获得更高的可维护性，应该以最不易受测试对象变化影响的方式来记录测试脚本。 （3）数据驱动的测试许多测试过程包括在给定的数据输入屏幕内输入几组字段数据，检查字段确认功能、错误处理等。（4）测试脚本同步和时间安排当进行重点测试时，通常需要同步测试脚本以便它们在预先确定的时间启动。 （5）测试和调试测试脚本在记录测试脚本的同一测试软件上执行这些最近记录的测试脚本时，不应该发生任何错误。 4．辅助测试工具为了实施高效的测试工作，还需要有高效、好用的辅助工具，做软件测试通常需要以下一些基本工具。 ①优秀的办公处理软件②秒表③错误跟踪系统④自动测试工具⑤软件分析工具⑥好的操作系统⑦多样化平台 2.6.4执行测试执行测试是执行所有的或选定的一些测试用例，并观察其测试结果的过程。尽管为执行测试所做的准备和计划工作会贯穿于软件开发生命周期之中，但是执行测试往往都会在软件开发生命周期的末期，或者接近末期进行，即在编码完成之后进行。由于测试过程一般分成代码审查、单元测试、集成测试、系统测试和验收测试几个阶段，尽管这些阶段在实现细节方面都不相同，但其工作流程方面却是一致的。 执行测试的过程由以下4个部分组成。①输入。要完成工作所必须的入口标准或可交付的结果。②执行过程。从输入到输出的过程或工作任务。③检查过程。确定输出是否满足标准的处理过程。④输出。推出标准或工作流程产生的可交付的结果。执行测试过程如图2-5所示。 图2-5执行测试过程 2.6.5评估测试软件测试的主要评测方法包括测试覆盖和质量评测。测试覆盖是对测试完全程度的评测，它是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。质量评测是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测，它建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）分析的基础上。 1．覆盖评测覆盖指标提供了“测试的完全程度如何”这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。 2．质量评测测试覆盖的评估提供对测试完全程度的评测，在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。3．性能评测评估测试对象的性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作可靠性和限制。 2.7测试的成功经验为了减少系统的开发费用，越早测试越好，这是多年来软件行业的一个成功经验，即在整个软件开发生命周期中通过各种软件工程技术尽量早地完成各种软件测试任务。首先，软件的整个测试生命周期是与软件的开发生命周期基本平齐的过程 在软件开发生命周期中，软件是通过迭代来不断加以完善的。在这种环境中，对于每个作为测试目标的工作版本，测试的生命周期还都必须具有一种迭代方法。对于针对每个工作版本执行的测试，都做出了增补和改进，并累积为一个测试体，用于后续阶段的回归测试。 通过迭代是软件开发把原来的整个软件开发生命周期分成多个迭代周期，在每个迭代周期都进行测试，这样在很大程度上提前了软件系统测试发生的时间，这可以在很大程度上降低项目风险和项目开发成本。 第3章软件测试的方法和技术3.1软件测试方法概述3.2白盒测试3.3黑盒测试3.4测试用例设计 3.1软件测试方法概述软件测试的种类大致可分为人工测试和基于计算机的测试。而基于计算机的测试又可分为黑盒测试和白盒测试。1．黑盒测试黑盒测试是根据软件产品的功能设计规格，在计算机上进行测试，以证实每个已经实现的功能是否符合要求。黑盒测试意味着测试要在软件的接口处进行。 2．白盒测试白盒测试是根据软件产品的内部工作过程，在计算机上进行测试，以证实每种内部操作是否符合设计规格要求，所有内部成分是否已经过检查。白盒测试把测试对象看做一个打开的盒子，允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。 3.2白盒测试白盒测试也称为结构测试或逻辑驱动测试，前提是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都能够按预定要求正确工作，而不管产品的功能，主要用于软件验证。 白盒测试方法又可分为静态测试和动态测试。静态测试是一种不通过执行程序而进行测试的技术，其关键功能是检查软件的表示和描述是否一致，没有冲突或者没有歧义。它瞄准的是纠正软件系统在描述、表示和规格上的错误，是任何进一步测试的前提。而动态测试需要软件的执行，当软件系统在模拟的或真实的环境中执行之前、之中和之后，对软件系统行为的分析是动态测试的主要特点。它显示了一个系统在检查状态下是正确还是不正确。 白盒测试的动态测试要根据程序的控制结构设计测试用例，其原则是：（1）保证一个模块中的所有独立路径至少被使用一次；（2）对所有逻辑值均需测试true和false；（3）在上下边界及可操作范围内运行所有循环；（4）检查内部数据结构以确保其有效性。 下面将介绍几种实用的白盒测试用例设计方法，包括程序插桩、逻辑覆盖、基本路径测试等。3.2.1程序插桩在软件动态测试中，程序插桩是一种基本的测试手段，有着广泛的应用。1．方法简介程序插桩方法是借助往被测程序中插入操作，来实现测试目的的方法。 如果我们想要了解一个程序在某次运行中所有可执行语句被覆盖的情况，或是每个语句的实际执行次数，最好的办法是利用插桩技术。这里仅以计算整数X和整数Y的最大公约数程序为例，说明插桩方法的要点。图3-3给出了这一程序的流程图。 图3-3插桩后求最大公约数程序的流程图 设计插桩程序时需要考虑的问题包括：①探测哪些信息；②在程序的什么部位设置探测点；③需要设置多少个探测点。 2．断言语句在程序中特定部位插入某些用以判断变量特性的语句，使得程序执行中这些语句得以证实，从而使程序的运行特性得到证实。我们把插入的这些语句称为断言。这一做法是程序正确性证明的基本步骤，尽管算不上严格的证明，但方法本身仍然是很实用的。 请看下面的程序清单badptr.c：#include#include#includeintmain(void){FILE*fp;fp=fopen("test.txt","w");//以可写的方式打开一个文件，如果不存在就创建一个同名文件assert(fp);//所以这里不会出错fclose(fp);fp=fopen("noexitfile.txt","r");//以只读的方式打开一个文件，如果不存在就打开文件失败assert(fp);//所以这里出错fclose(fp);//程序永远都执行不到这里来return0;}assert宏的原型定义在中，其作用是如果它的条件返回错误，则终止程序执行 3.2.2逻辑覆盖逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术，是通过对程序逻辑结构的遍历实现程序的覆盖，它是一系列测试过程的总称，这组测试过程逐渐进行越来越完整的通路测试。这一方法要求测试人员对程序的逻辑结构有清楚的了解，甚至要能掌握源程序的所有细节。它属于动态测试。 从覆盖源程序语句的详细程度分析，逻辑覆盖标准有语句覆盖、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖和修正条件判定覆盖。为便于理解，使用如下所示的程序，图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覆盖准则前面所介绍的逻辑覆盖其出发点似乎是合理的。所谓“覆盖”，就是想要做到全面而无遗漏。但是，事实表明，它并不能真的做到无遗漏。K.A.Foster从测试工作实践的教训出发，吸收了计算机硬件的测试原理，提出了一种经验型的测试覆盖准则：在容易发生问题的地方设计测试用例，即重视程序中谓词（条件判断）的取值。 具体规则：[规则1]对于ArelB型(rel可以是<、=或>)的分支谓词，应适当的选择A与B的值，使得测试执行到该分支语句时，AB的情况分别出现一次。——这是为了检测逻辑符号写错的情况，如将“AB”。[规则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个关键元素。①被测单元模块初始状态声明，即测试用例的开始状态（仅适用于被测单元维持了调用间状态的情况）。②被测单元的输入，包含由被测单元读入的任何外部数据值。 ③该测试用例实际测试的代码，用被测单元的功能和测试用例设计中使用的分析来说明，如单元中哪一个决策条件被测试。④测试用例的期望输出结果。测试用例的期望输出结果总是应该在测试进行之前在测试说明中定义。 下面说明测试用例的设计步骤。（1）步骤1：使被测单元运行这个阶段适合的技术有：①模块设计导出的测试；②对等区间划分。 （2）步骤2：正面测试（PositiveTesting）这个阶段适合的技术有：①设计说明导出的测试；②等价类分析；③状态转换测试。 （3）步骤3：负面测试（NegativeTesting）这个阶段适合的技术有：①错误猜测；②边界值分析；③内部边界值测试；④状态转换测试。 （4）步骤4：需求中其他测试特性用例设计这个阶段适合的技术有：设计说明导出的测试。 （5）步骤5：覆盖率测试用例设计这个阶段适合的技术有：①分支测试；②条件测试；③数据定义——使用测试；④状态转换测试。其中①和②均属于逻辑覆盖范畴。 （6）步骤6：测试执行（7）步骤7：完善代码覆盖这个阶段适合的技术有：①分支测试；②条件测试；③设计定义——试验测试；④状态转换测试。 最后，总结一下用例设计的一般原则。通常应该避免依赖先前测试用例的输出，测试用例的执行序列早期发现的错误可能导致其他的错误而减少测试执行时实际测试的代码量。测试用例设计过程中，包括作为试验执行这些测试用例时，常常可以在软件构建前就发现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.2.3单元测试技术和测试数据用于单元测试的主要技术如下。1．静态测试2．白盒测试3．状态转换测试4．功能测试和非功能测试 单元测试中使用的数据，通常不使用真实数据。当被测试单元的功能不涉及操纵或使用大量数据时，测试中可以使用有代表性的一小部分手工制作的测试数据。在创建测试数据时，应确保数据充分地测试单元的边界条件。当被测试单元要操纵大量数据，并且有很多单元都有这种需求时，可以考虑使用真实数据的一个较小的有代表性的样本。测试时还要考虑往样本数据中引入一些手工制作的数据，以便测试单元的某个具体特性，例如对错误条件的响应等。 当测试一个单元要从远程数据源接收数据时（例如，从一个客户端/服务器系统中接收数据），有必要在单元测试中使用测试辅助程序，来模拟对这些数据的访问。但在考虑这种选择时，必须首先对开发的测试辅助程序进行测试，以保证模拟的真实性。 4.2.4单元测试人员单元测试一般由开发设计人员本身完成，一般由开发组在组长的监督下进行，由编写该单元的开发设计者设计所需的测试用例和测试数据，来测试该单元并修改缺陷。开发组组长负责保证使用合适的测试技术，在合理的质量控制和监督下执行充分的测试。 4.3集成测试将经过单元测试的模块按设计要求连接起来，组成所规定的软件系统的过程称为“集成”。 4.3.1集成测试的主要任务集成测试是组装软件的系统测试技术之一，按设计要求把通过单元测试的各个模块组装在一起之后，进行集成测试的主要任务是要求软件系统符合实际软件结构，发现与接口有关的各种错误。单元测试的主要任务是解决以下5个方面的测试问题。 ①将各模块连接起来，检查模块相互调用时，数据经过接口是否丢失。②将各个子功能组合起来，检查能否达到预期要求的各项功能。③一个模块的功能是否会对另一个模块的功能产生不利的影响。④全局数据结构是否有问题，会不会被异常修改。⑤单个模块的误差积累起来，是否被放大，从而达到不可接受的程度。 4.3.2集成测试方法集成测试包括两种不同方法：非增量式集成和增量式集成。 1．非增量式测试方法概括来说，非增量式测试方法是采用一步到位的方法来进行测试，即对所有模块进行个别的单元测试后，按程序结构图将各模块连接起来，把连接后的程序当做一个整体进行测试。图4-3给出的是采用这种非增量式的集成测试方法的一个经典例子。 2．增量式测试方法（1）自顶向下增量式测试自顶向下增量式测试表示逐步集成和逐步测试是按结构图自上而下进行的。即模块集成的顺序是首先集成主控模块（主程序），然后按照软件控制层次结构向下进行集成。 图4-4自顶向下集成 集成测试的整个过程由下列3个步骤完成。①主控模块作为测试驱动器，把对主控模块进行单元测试时引入的被调用模拟子模块用实际模块替代。②依照所选用的模块集成策略（深度优先和广度优先），下层的被调用模拟子模块一次一个地被替换为真正的模块。③在每个模块被集成时，都必须立即进行测试一遍。 回到第2步重复进行，直到整个系统结构被集成完成。图4-5给出了一个按广度优先策略进行集成测试的典型例子。 图4-5自顶向下增量式测试（广度优先策略） （2）自底向上增量式测试自底向上增量式测试是从最底层的模块开始，按结构图自下而上逐步进行集成和测试。图4-6表示了采用自底向上增量式测试实现同一实例的过程。 图4-6自底向上增量式测试 4.3.3集成测试技术和测试数据集成测试主要测试软件的结构问题，因为测试建立在模块的接口上，所以多为黑盒测试，适当辅以白盒测试。 执行集成测试应遵循下面的方法。①确认组成一个完整系统的模块之间的关系。②评审模块之间的交互和通信需求，确认出模块间的接口。③使用上述信息产生一套测试用例。④采用增量式测试，依次将模块加入到（扩充）系统，并测试新合并后的系统，这个过程以一个逻辑/功能顺序重复进行，直至所有模块被功能集成进来形成完整的系统为止。 此外，在测试过程中尤其要注意关键模块，所谓关键模块一般都具有下述一个或多个特征。①对应几条需求。②具有高层控制功能。③复杂，易出错。④有特殊的性能要求。 因为集成测试的主要目的是验证组成软件系统的各模块的接口和交互作用，因此集成测试对数据的要求无论从难度和内容来说一般不是很高。集成测试一般也不使用真实数据，测试人员可以使用手工制作一部分代表性的测试数据。在创建测试数据时，应保证数据充分测试软件系统的边界条件。在单元测试时，根据需要生成了一些测试数据，在集成测试时可适当地重用这些数据，这样可节省时间和人力。 4.3.4集成测试遵循的原则集成测试很不好把握，应针对总体设计尽早开始筹划。为了做好集成测试，需要遵循以下原则。①所有公共接口都要被测试到。②关键模块必须进行充分的测试。③集成测试应当按一定的层次进行。 ④集成测试的策略选择应当综合考虑质量、成本和进度之间的关系。⑤集成测试应当尽早开始，并以总体设计为基础。⑥在模块与接口的划分上，测试人员应当和开发人员进行充分的沟通。⑦当接口发生修改时，涉及的相关接口必须进行再测试。⑧测试执行结果应当如实记录。 4.3.5集成测试人员由于集成测试不是在真实环境下进行，而是在开发环境，或是一个独立的测试环境下进行的，所以集成测试所需人员一般从开发组中选出，在开发组长的监督下进行，开发组长负责保证在合理的质量控制和监督下使用合适的测试技术执行充分的集成测试。 在集成测试过程中，测试过程由一个独立测试观察员来监控测试工作。集成测试过程中应考虑邀请一个用户代表非正式地观看集成测试。 4.4系统测试集成测试通过以后，软件已经组装成一个完整的软件包，这时就要进行系统测试。 4.4.1系统测试的任务系统测试一般要完成以下几种测试。1．功能测试2．性能测试3．恢复测试4．安全测试5．强度测试6．其他限制条件的测试 4.4.2系统测试技术和测试数据系统测试完全采用黑盒测试技术，因为这时已不需要考虑组件模块的实现细节，而主要是根据需求分析时确定的标准检验软件是否满足功能、行为、性能和系统协调性等方面的要求。系统测试所用的数据必须尽可能地像真实数据一样精确和有代表性，也必须和真实数据的大小和复杂性相当。满足上述测试数据需求的一个方法是使用真实数据。 在不使用真实数据的情况下应该考虑使用真实数据的一个拷贝。拷贝数据的质量、精度和数据量必须尽可能地代表真实的数据。当使用真实数据或使用真实数据的拷贝时，仍然有必要引入一些手工数据。在创建手工数据时，测试人员必须采用正规的设计技术，使得提供的数据真正有代表性，确保软件系统能充分地测试。 4.4.3系统测试人员系统测试由独立的测试小组在测试组长的监督下进行，测试组长负责保证在合理的质量控制和监督下使用合适的测试技术执行充分的系统测试。在系统测试过程中，测试过程由一个独立测试观察员来监控测试工作。系统测试过程也应考虑邀请一个用户代表非正式地观看测试，同时得到用户反馈意见并在正式验收测试之前尽量满足用户的要求。 4.5验收测试系统测试完成后，并使系统试运行了预定的时间，应进行验收测试。4.5.1验收测试的主要任务软件验收测试应完成的主要测试工作包括以下几方面。 1．文档资料的审查验收2．功能测试3．性能测试4．强化测试5．性能降级执行方式测试6．检查系统的余量要求7．安装测试8．用户操作测试 4.5.2验收测试技术和测试数据验收测试完全采用黑盒测试技术，主要是用户代表通过执行其在平常使用系统时的典型任务来测试软件系统，根据业务需求分析，检验软件是否满足功能、行为、性能和系统协调性等方面的要求。 只要有可能，在验收测试中就应该使用真实数据。当真实数据中包含机密性或安全性信息，并且这些数据在局部或整个验收测试中可见时，就必须采取以下措施来保证。①用户代表被允许使用这些数据，或者合理地组织测试使测试组长不必看到这些数据也可进行测试。②测试观察员被允许使用这些数据，或者能够在看不到这些数据的情况下确认并记录测试用例的成功或失败。 在不使用真实数据的情况下，应该考虑使用真实数据的一个拷贝。拷贝数据的质量、精度和数据量必须尽可能地代表真实的数据。当使用真实数据或使用真实数据的拷贝时，仍然有必要引入一些手工数据，例如，测试边界条件或错误条件时，可创建一些手工数据。在创建手工数据时，测试人员必须采用正规的设计技术，使得提供的数据真正有代表性，确保软件系统能充分地测试。 4.5.3验收测试人员验收测试一般在测试组的协助下，由用户代表执行。测试组长负责保证在合理的质量控制和监督下使用合适的测试技术执行充分测试。测试人员在验收测试工作中将协助用户代表执行测试，并和测试观察员一起向用户解释测试用例的结果。 4.5.4α、β测试软件开发设计人员在软件开发设计时，不可能完全预见用户实际使用软件系统的情况。另外，一个软件产品可能拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以发现那些似乎只有最终用户才能发现的问题。 α测试是在软件开发公司内模拟软件系统的运行环境下的一种验收测试，即软件开发公司组织内部人员，模拟各类用户行为对即将面市的软件产品（称为α版本）进行测试，试图发现并修改错误。 经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况，提出批评意见。然后软件开发公司再对β版本进行改错和完善。所以，一些软件开发公司把α测试看成是对一个早期的、不稳定的软件版本所进行的验收测试，而把β测试看成是对一个晚期的、更加稳定的软件版本所进行的验收测试。 4.6回归测试回归测试是指软件系统被修改或扩充（如系统功能增强或升级）后重新进行的测试，是为了保证对软件所做的修改没有引入新的错误而重复进行的测试。每当软件增加了新的功能，或者软件中的缺陷被修正，这些变更都有可能影响软件原有的功能和结构。 为了防止软件的变更产生无法预料的副作用，不仅要对内容进行测试，还要重复进行过去已经进行过的测试，以证明修改没有引起未曾预料的后果，或证明修改后的软件仍能满足具体的需求。 在理想的测试环境中，程序每改变一次，测试人员都重新执行回归测试，一方面来验证新增加或修改功能的正确性，另一方面测试人员还要从以前的测试中选取大量的测试以确定是否在实现新功能的过程中引入了缺陷。 图4-7说明了回归测试和V模型之间的关系。图4-7回归测试和V模型 回归测试特别适用于较高阶段的测试过程，回归测试一般多在系统测试和验收测试环境下进行，以确保整个软件系统新的构造或新的版本仍然运行正确，或者确保软件系统的现有业务功能完好无损。 4.6.1回归测试技术和测试数据回归测试一般采用黑盒测试技术来测试软件的高级需求，而无须考虑软件的实现细节，也可能采用一些非功能测试来检查系统的增强或扩展是否影响了系统的性能特性，以及与其他系统间的互操作性和兼容性问题。 错误猜测在回归测试中是很重要的。错误看起来像是通过直觉发现软件中的错误或缺陷，实际上错误猜测主要来自于经验，测试者是使用了一系列技术来确定测试所要达到的范围和程度，这些技术主要有：①有关软件设计方法和实现技术；②有关前期测试阶段结果的知识；③测试类似或相关系统的经验，了解在以前的这些系统中曾在哪些地方出现缺陷； ④典型的产生错误的知识，如被零除错误；⑤通用的测试经验规则。设计和引入回归测试数据的重要原则是，应保证数据中可能影响测试的因素与未经修改扩充的原软件上进行测试时的哪些因素尽可能一致，否则要想确定观测到的测试结果是由于数据变化还是很困难的。 4.6.2回归测试的范围在回归测试范围的选择上，一个最简单的方法是每次回归执行所有在前期测试阶段建立的测试，来确认问题修改的正确性，以及没有造成对其他功能的不利影响。 常用的用例选择方法可以分为以下3种。（1）局限在修改范围内的测试（2）在受影响功能范围内回归（3）根据一定的覆盖率指标选择回归测试 4.6.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）不值得修复 虽然软件测试人员需要对自己找出的软件缺陷保持一种平常心态，但同时又必须坚持有始有终的原则，跟踪每一个软件缺陷的处理结果，确保软件缺陷得以关闭。而缺陷是否需要修复的最终决定权在软件的项目负责人，但使得缺陷得以关闭的责任在测试人员。 5.3软件缺陷的生命周期软件缺陷从被测试人员发现一直到被修复，也经历了一个特有的生命周期的阶段。下面是一个最简单的软件缺陷生命周期的例子，系统地表示软件缺陷从被发现起经历的各个阶段： （1）测试人员找到并登记软件缺陷，软件缺陷被移交到程序修复人员。（2）程序修复人员修复软件中的软件缺陷，然后移交到测试人员。（3）测试人员确认软件缺陷被修复，关闭软件缺陷。 当软件缺陷首先被软件测试人员发现时。在许多情况下，软件缺陷生命周期的复杂程度仅为软件缺陷被打开、解决和关闭。然而，在有些情况下，生命周期变得更复杂一些，如图5-1所示。 图5-1复杂的软件缺陷生命周期 5.4软件缺陷的严重性和优先级测试人员要对软件缺陷分类，以简明扼要的方式指出其影响。经常使用的方法是给软件缺陷划分严重性和优先级。严重性表示软件缺陷的恶劣程度，反映其对产品和用户的影响；优先级表示修复缺陷的重要程度和应该何时修复。下面给出严重性和优先级的常用划分方法，将有助于测试人员更好地理解两者之间的差异。 严重性级别：①致命错误，例如，导致系统崩溃、数据丢失、数据毁坏等；②一般性错误，例如，操作性错误、错误结果、遗漏功能等；③次要错误，例如，错别字、用户接口布局、罕见故障等。 缺陷优先级：①最高优先级，指的是一些关键性错误，必须立即修复；②高优先级，在产品发布之前必须修复；③中优先级，如果时间允许应该修复；④低优先级，可能会修复，但是也能发布软件。 5.5报告软件缺陷5.5.1报告软件缺陷的基本原则在软件测试过程中，对于发现的大多数软件缺陷，要求测试人员简捷、清晰地把发现的问题报告给判断是否进行修复的小组，使其得到所需要的全部信息，然后才能决定怎么做。 报告软件缺陷的基本原则如下。1．尽快报告软件缺陷2．有效地描述软件缺陷 有效的软件缺陷描述要求如下。（1）简单与短小（2）明确指明错误类型（3）单一（4）使用IT业界惯用的表达术语和表达方法 3．在报告软件缺陷时不做任何评价4．补充和完善软件缺陷报告 以上概括了报告测试错误的规范要求，测试人员应该牢记上面这些关于报告软件缺陷的原则。这些原则几乎可以运用到任何交流活动中，尽管有时难以做到，然而，如果希望有效地报告软件缺陷，并使其得以修复，这些是测试人员要遵循的基本原则。 随着软件的测试要求不同，测试者积累了相应的测试经验会，将会逐渐养成良好的专业习惯，不断补充新的规范书写要求。此外，经常阅读、学习高级测试工程师的测试错误报告，结合自己以前的测试错误报告进行对比和思考，可以不断提高技巧。 5.5.2IEEE软件缺陷报告模板ANS/IEEE829—1998标准定义了一个称为软件缺陷报告的文档，用于报告“在测试期间发生的任何异常事件”。简言之，就是用于登记软件缺陷。模板标准如图5-3所示。 图5-3IEEE软件缺陷报告模板 5.5.3软件缺陷数据库跟踪系统至此，我们了解到软件缺陷报告过程是很复杂的，需要大量信息、详尽的细节和很好的组织工作，才能有所成效。在实际软件测试工作中，为了更高效地记录发现的软件缺陷，并在软件缺陷的整个生命周期中对其进行监控，常常运用软件缺陷跟踪系统。图5-4所示的是一个软件缺陷数据库跟踪系统。 图5-4软件缺陷数据库跟踪系统 软件缺陷跟踪数据库最常用的功能，除了输入软件缺陷之外，就是通过执行查询来获得需要的软件缺陷清单。 通过使用软件缺陷跟踪数据库，不但可以进行查询，还可以找出发现的软件缺陷类型，发现软件缺陷的速度，以及多少软件缺陷已经得到了修复，能够提取各种实用和关心的数据，可以显示测试工作的成效和项目的进展情况。测试人员或者项目管理员可以看出数据中是否有趋势显示需要增加测试的区域，或者测试工作是否符合预先所制定的测试计划的进程等。 5.5.4手工报告和跟踪软件缺陷显然，在软件测试工作中，每个测试用例的结果都必须进行记录。如果使用软件缺陷数据库跟踪系统，那么测试工具将自动记录软件缺陷的相关信息。如果测试是采用手工记录和跟踪软件缺陷，那么有关软件缺陷的信息可以直接记录在相应的文档中。图5-5所示的是根据ANS/IEEE829—1998标准设计的软件缺陷报告文档。 图5-5软件缺陷报告文档 5.6分离和再现软件缺陷测试人员要想有效报告软件缺陷，就要对软件缺陷以明显、通用和再现的形式进行描述。分离和再现软件缺陷是考验软件测试人员专业技能的地方，测试人员应该设法找出缩小问题范围的具体步骤。对测试人员有利的情况是，若建立起绝对相同的输入条件时，软件缺陷就会再次出现，不存在随机的软件缺陷。 如果找到的软件缺陷要采取繁杂的步骤才能再现，或者根本无法再现，碰到这种情况，可采取如下的方法来分离和再现软件缺陷。实践证明这些方法对测试人员是有所帮助的。（1）不要想当然地接受任何假设（2）注意时间和运行条件上的因素 （3）注意软件的边界条件、内存容量和数据溢出的问题（4）注意事件发生次序导致的软件缺陷（5）考虑资源依赖性和内存、网络、硬件共享的相互作用（6）不要忽视硬件 5.7测试总结报告测试总结报告的目的是总结测试活动的结果，并根据这些结果对测试进行评价。这种报告是测试人员对测试工作进行总结，并识别出软件的局限性和发生失效的可能性。在测试执行阶段的末期，应该为每个测试计划准备一份相应的测试总结报告。本质上讲，测试总结报告是测试计划的扩展，起着对测试计划“封闭回路”的作用。 图5-6所示的是符合IEEE标准829—1998软件测试文档编制标准的测试总结报告模板。 图5-6测试总结报告模板 5.8测试的评测测试的评测主要方法包括覆盖评测和质量评测。测试覆盖评测是对测试完全程度的评测，它建立在测试覆盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。质量评测是对测试对象的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的缺陷及缺陷修复的分析基础上。 5.8.1覆盖评测覆盖评测指标是用来度量软件测试的完全程度的，所以可以将覆盖用做测试有效性的一个度量。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖，它们分别是指针对需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度评测。 1．基于需求的测试覆盖基于需求的测试覆盖在测试过程中要评测多次，并在测试过程中，每一个测试阶段结束时给出测试覆盖的度量。例如，计划的测试覆盖、已实施的测试覆盖、已执行成功的测试覆盖等。基于需求的测试覆盖率通过以下公式计算：测试覆盖率=T(p,i,x,s)/RfT% 在制定测试计划活动中，将计算计划的测试覆盖，其计算方法如下：计划的测试覆盖率=Tp/RfT%其中：Tp是用测试过程或测试用例表示的计划测试需求数。RfT是测试需求的总数。 在实施测试过程中，计算测试覆盖时使用以下公式：已执行的测试覆盖率=Ti/RfT%其中：Ti是用测试过程或测试用例表示的已执行的测试需求数。RfT是测试需求的总数。 在执行测试活动中，确定成功的测试覆盖率（即执行时未出现失败的测试，如没有出现缺陷或意外结果的测试）评测通过以下公式计算：成功的测试覆盖率=Ts/RfT%其中：Ts是用完全成功、没有缺陷的测试过程或测试用例表示的已执行测试需求数。RfT是测试需求的总数。 在执行测试过程中，经常使用两个测试覆盖度量指标，一个是确定已执行的测试覆盖率，另一个是确定成功的测试覆盖率，即执行时未出现失败的测试覆盖率。 2．基于代码的测试覆盖基于代码的测试覆盖评测是测试过程中已经执行的代码的多少，与之相对应的是将要执行测试的剩余代码的多少。 许多测试专家认为，一个测试小组在测试工作中所要做的最为重要的事情之一就是度量代码的覆盖情况。基于代码的测试覆盖率通过以下公式计算：基于代码的测试覆盖率=Ie/TIic%其中：Ie是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行代码数。TIic是代码的总数。 很明显，在软件测试工作中，进行基于代码的测试覆盖评测这项工作极有意义，因为任何未经测试的代码都是一个潜在的不利因素。在一般情况下，代码覆盖运用于较低的测试等级（例如单元和集成级）时最为有效。 但是，仅仅凭借执行了所有的代码，并不能为软件质量提供保证。也就是说，即使所有的代码都在测试中得到执行，并不能担保代码是按照客户需求和设计的要求去做了。 5.8.2质量评测测试覆盖的评测提供了对测试完全程度的评价，而在测试过程中对已发现缺陷的评测提供了最佳的软件质量指标。 常用的测试有效性度量是围绕缺陷分析来构造的。缺陷分析就是分析缺陷在与缺陷相关联的一个或者多个参数值上的分布。缺陷分析提供了一个软件可靠性指标，这些分析为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。 对于缺陷分析，常用的主要缺陷参数有以下4个。状态：缺陷的当前状态（打开的、正在修复的或关闭的等）。优先级：表示修复缺陷的重要程度和应该何时修复。严重性：表示软件缺陷的恶劣程度，反映其对产品和用户的影响等。起源：导致缺陷的原因及其位置，或排除该缺陷需要修复的构件。 缺陷分析通常用以下3类形式的度量提供缺陷评测：缺陷发现率；缺陷潜伏期；缺陷密度。 1．缺陷发现率缺陷发现率是将发现的缺陷数量作为时间的函数来评测，即创建缺陷趋势图，如图5-7所示。 图5-7缺陷发现率 2．缺陷潜伏期测试有效性的另外一个有用的度量是缺陷潜伏期，通常也称为阶段潜伏期。缺陷潜伏期是一种特殊类型的缺陷分布度量。在实际测试工作中，发现缺陷的时间越晚，这个缺陷所带来的损害就越大，修复这个缺陷所耗费的成本就越多。表5-1显示了一个项目的缺陷潜伏期的度量。 表5-2显示了一个项目的缺陷分布情况（按缺陷造成阶段和缺陷发现阶段）。 按照缺陷产生阶段和缺陷发现阶段统计了一个项目的缺陷分布情况后，根据软件开发生命周期的各个阶段缺陷潜伏期度量的加权值，可以对缺陷的发现过程有效性和修复软件缺陷所耗费的成本等进行评测。这里采用了一个缺陷损耗的概念，缺陷损耗是使用阶段潜伏期和缺陷分布来度量缺陷消除活动的有效性的一种度量。 缺陷消耗可使用下面公式计算：表5-3显示了一个项目的各个缺陷损耗值，它们依据的是经过缺陷潜伏期加权的已发现的缺陷数。这样，在验收测试期间发现的需求缺陷的加权数值为42（即6×7=42）。 一般而言，缺陷损耗的数值越低，说明缺陷的发现过程越有效（最理想的数值应该为1）。作为一个绝对值，缺陷损耗几乎没有任何意义，但是当用缺陷损耗来度量测试有效性的长期趋势时，它就会显示出自己的价值。 3．缺陷密度软件缺陷密度是一种以平均值估算法来计算出软件缺陷分布的密度值。程序代码通常是以千行为单位的，软件缺陷密度是用下面公式计算的： 图5-8显示了一个项目的各个模块中每千行代码的缺陷密度。图5-8各个模块中每千行代码的缺陷密度 但是，在实际评测中，缺陷密度这种度量方法是极不完善的，度量本身是不充分的。这里边存在的主要问题是：所有的缺陷并不都是均等构造的。各个软件缺陷的恶劣程度，及其对产品和用户的影响的严重程度，以及修复缺陷的重要程度有很大差别，有必要对缺陷进行“分级、加权”处理，给出软件缺陷在各严重性级别或优先级上的分布作为补充度量，这样将使这种评测更加充分，更有实际应用价值。 因为在测试工作中，大多数的缺陷都记录了它的严重程度的等级和优先级，所以这个问题通常都能够很好解决。例如，图5-9所示的缺陷分布图表示软件缺陷在各优先级上所应体现的分布方式。 图5-9各优先级上软件缺陷分布图 5.8.3性能评测主要的性能评测包括以下几点。动态监测：在测试执行过程中，实时获取并显示正在执行的各测试用例的状态。响应时间和吞吐量：测试对象针对特定测试用例的响应时间或吞吐量的评测。 百分比报告：数据已收集值的百分比计算与评测。比较报告：代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势。追踪和配置文件报告：测试用例和测试对象之间的消息和会话详细信息。 1．动态监测动态监测通常以柱状图或曲线图的形式提供实时显示/报告。该报告用于在测试执行过程中，通过显示当前的情况、状态以及测试用例正在执行的进度来监测或评估性能测试执行情况。例如，在图5-10所示柱状图中。 图5-10动态监测柱状图 2．响应时间和吞吐量响应时间和吞吐量是评测并计算与时间和吞吐量相关的性能行为。这些报告通常用曲线图显示，如图5-11所示。响应时间和吞吐量在“y”轴上，而事件数在“x”轴上。 图5-11响应时间曲线 3．百分比报告百分比报告通过显示已收集数据类型的各种百分比值，提供了另一种性能统计计算方法，如图5-12所示。 图5-12数据类型的各种百分比值 4．比较报告比较不同性能测试的结果，以评估测试执行过程中所作的变更对性能行为的影响，这种做法是非常必要的。比较报告应该用于显示两个数据集（分别代表不同的测试执行）之间的差异或多个测试执行之间的趋势。 5．追踪和配置文件报告当性能行为可以接受时，或性能监测表明存在可能的瓶颈时（如当测试用例保持给定状态的时间过长），追踪报告可能是最有价值的报告。追踪和配置文件报告显示低级信息。该信息包括主角与测试对象之间的消息、执行流、数据访问以及函数和系统调用。 第6章软件测试项目管理6.1测试项目管理概述6.2测试文档6.3软件测试计划6.4测试的组织与人员管理6.5软件测试过程管理 6.1测试项目管理概述6.1.1测试项目与测试项目管理1．测试项目测试项目是在一定的组织机构内，利用有限的人力和财力等资源，在指定的环境和要求下，对特定软件完成特定测试目标的阶段性任务。该任务应满足一定质量、数量和技术指标等要求。 测试项目一般具有如下一些基本特性。（1）项目的独特性（2）项目的组织性（3）测试项目的生命期（4）测试项目的资源消耗特性（5）测试项目目标冲突性（6）测试项目结果的不确定因素 2．测试项目管理测试项目管理就是以测试项目为管理对象，通过一个临时性的专门的测试组织，运用专门的软件测试知识、技能、工具和方法，对测试项目进行计划、组织、执行和控制，并在时间成本、软件测试质量等方面进行分析和管理活动。（一种高级管理方法）测试项目管理贯穿整个测试项目的生命周期，是对测试项目的全过程进行管理。 测试项目管理有以下基本特征。（1）系统工程的思想贯穿测试项目管理的全过程。（2）测试项目管理的组织有一定的特殊性。 （3）测试项目管理的要点是创造和保持一个使测试工作顺利进行的环境，使置身于这个环境中的人员能在集体中协调工作以完成预定的目标。（4）测试项目管理的方法、工具和技术手段具有先进性。 6.1.2测试项目的范围管理测试项目范围管理就是界定项目所必须包含且只需包含的全部工作，并对其他的测试项目管理工作起指导作用，以确保测试工作顺利完成。 项目目标确定后，下一步过程就是确定需要执行哪些工作，或者活动来完成项目的目标，这就是要确定一个包含项目所有活动在内的一览表。准备这样的一览表通常有两种方法：一种是让测试小组利用“头脑风暴法”根据经验，集思广益来形成。这种方法比较适合小型测试项目。 另一种是对更大更复杂的项目建立一个工作分解结构WBS和任务的一览表。工作分解结构是将一个软件测试项目分解成易于管理的更多部分或细目，所有这些细目构成了整个软件测试项目的工作范围。工作分解结构是进行范围规划时所使用的重要工具和技术之一，它是测试项目团队在项目期间要完成或生产出的最终细目的等级树，它组织并定义了整个测试项目的范围，未列入工作分解结构的工作将排除在项目范围之外。 进行工作分解是非常重要的工作，它在很大程度上决定项目能否成功。对于细分的所有项目要素需要统一编码，并按规范化进行要求。这样，WBS的应用将给所有的项目管理人员提供一个一致的基准，即使项目人员变动时，也有一个互相可以理解和交流沟通的平台。 6.2测试文档测试文档是对要执行的软件测试及测试的结果进行描述、定义、规定和报告的任何书面或图示信息。由于软件测试是一个很复杂的过程，同时也涉及到软件开发中其他一些阶段的工作，因此，必须把对软件测试的要求、规划、测试过程等有关信息和测试的结果，以及对测试结果的分析、评价，以正式的文档形式给出。 测试文档对于测试阶段工作的指导与评价作用更是非常明显的。需要特别指出的是，在已开发的软件投入运行的维护阶段，常常还要进行再测试或回归测试，这时还会用到测试文档。测试文档的编写是测试管理的一个重要组成部分。 6.2.1测试文档的作用测试文档的重要作用可从以下几个方面看出。1．促进项目组成员之间的交流沟通2．便于对测试项目的管理 3．决定测试的有效性4．检验测试资源5．明确任务的风险6．评价测试结果7．方便再测试8．验证需求的正确性 6.2.2测试文档的类型根据测试文档所起的不同作用，通常把它分成两类，即前置作业文档和后置作业文档。测试计划及测试用例的文档属于前置作业文档。后置作业文档是在测试完成后提交的，主要包括软件缺陷报告和分析总结报告。 6.2.3主要软件测试文档1．软件测试文档给出了软件测试主要文档的类型。 2．软件测试计划主要对软件测试项目、所需要进行的测试工作、测试人员所应该负责的测试工作、测试过程、测试所需的时间和资源，以及测试风险等做出预先的计划和安排。 3．测试设计规格说明用于每个测试等级，以指定测试集的体系结构和覆盖跟踪。 4．软件测试用例规格说明文档用于描述测试用例。 5．测试规程用于指定执行一个测试用例集的步骤。6．测试日志由于记录测试的执行情况不同，可根据需要选用。 7．软件缺陷报告用来描述出现在测试过程或软件中的异常情况，这些异常情况可能存在于需求、设计、代码、文档或测试用例中。8．测试总结报告用于报告某个测试完成情况。 6.3软件测试计划测试计划就是描述所有要完成的测试工作，包括被测试项目的背景、目标、范围、方式、资源、进度安排、测试组织，以及与测试有关的风险等方面。 6.3.1制定测试计划的目的一个计划一定是为了某种目的而产生的，对于软件质量管理而言，制定测试计划的目的主要有3个。1．使软件测试工作进行更顺利2．促进项目参加人员彼此的沟通3．使软件测试工作更易于管理 6.3.2制定测试计划的原则制定测试计划是软件测试中最有挑战性的一个工作。以下原则将有助于制定测试计划工作。1．制定测试计划应尽早开始2．保持测试计划的灵活性3．保持测试计划简洁和易读4．尽量争取多渠道评审测试计划5．计算测试计划的投入 6.3.3制定测试计划时面对的问题制定测试计划时，测试人员可能面对以下问题，必须认真对待，并妥善予以处理。1．与开发者意见不一致2．缺乏测试工具3．培训不够 4．管理部门缺乏对测试工作的理解和支持5．缺乏用户的参与6．测试时间不足7．过分依赖测试人员8．测试人员处于进退两难的状态9．不得不说“不” 6.3.4制定测试计划制定测试计划时，由于各软件公司的背景不同，测试计划文档也略有差异。实践表明，制定测试计划时，使用正规化文档通常比较好。为了使用方便，在这里给出IEEE软件测试计划文档模板。 根据IEEE829－1998软件测试文档编制标准的建议，测试计划包含了16个大纲要项，简要说明如下。1．测试计划标识符一个测试计划标识符是一个由公司生成的惟一值，它用于标识测试计划的版本、等级，以及与该测试计划相关的软件版本。 2．介绍在测试计划的介绍部分主要是测试软件基本情况的介绍和测试范围的概括性描述。 3．测试项测试项部分主要是纲领性描述在测试范围内对哪些具体内容进行测试，确定一个包含所有测试项在内的一览表。具体要点如下。功能的测试设计的测试整体测试 IEEE标准中指出，可以参考下面的文档来完成测试项：需求规格说明用户指南操作指南安装指南与测试项相关的事件报告 4．需要测试的功能测试计划中这一部分列出了待测的功能。5．方法（策略）这部分内容是测试计划的核心所在，所以有些软件公司更愿意将其标记为“策略”，而不是“方法”。 测试策略描述测试小组用于测试整体和每个阶段的方法。要描述如何公正、客观地开展测试，要考虑模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响，要尽可能地考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备。测试记录具体说明如下。 公正性声明测试用例特殊考虑经验判断设想 6．不需要测试的功能测试计划中这一部分列出了不需要测试的功能。7．测试项通过/失败的标准测试计划中这一部分给出了“测试项”中描述的每一个测试项通过/失败的标准。正如每个测试用例都需要一个预期的结果一样，每个测试项同样都需要一个预期的结果。 下面是通过/失败的标准的一些例子：通过测试用例所占的百分比；缺陷的数量、严重程度和分布情况；测试用例覆盖；用户测试的成功结论；文档的完整性；性能标准。 8．测试中断和恢复的规定测试计划中这一部分给出了测试中断和恢复的标准。常用的测试中断标准如下：关键路径上的未完成任务大量的缺陷严重的缺陷不完整的测试环境资源短缺 9．测试完成所提交的材料测试完成所提交的材料包含了测试工作开发设计的所有文档、工具等。例如，测试计划、测试设计规格说明、测试用例、测试日志、测试数据、自定义工具、测试缺陷报告和测试总结报告等。 10．测试任务测试计划中这一部分给出了测试工作所需完成的一系列任务。在这里还列举了所有任务之间的依赖关系和可能需要的特殊技能。 11．环境需求环境需求是确定实现测试策略必备条件的过程。例如：人员——人数、经验和专长。他们是全职、兼职、业余还是学生？设备——计算机、测试硬件、打印机、测试工具等。 办公室和实验室空间——在哪里？空间有多大？怎样排列？软件——字处理程序、数据库程序和自定义工具等。其他资源——软盘、电话、参考书、培训资料等。 12．测试人员的工作职责测试人员的工作职责是明确指出了测试任务和测试人员的工作责任。有时测试需要定义的任务类型不容易分清，不像程序员所编写的程序那样明确。复杂的任务可能有多个执行者，或者由多人共同负责。 13．人员安排与培训需求前面讨论的测试人员的工作职责是指哪类人员（管理、测试和程序员等）负责哪些任务。人员安排与培训需求是指明确测试人员具体负责软件测试的哪些部分、哪些可测试性能，以及他们需要掌握的技能等。实际责任表会更加详细，确保软件的每一部分都有人进行测试。每一个测试员都会清楚地知道自己应该负责什么，而且有足够的信息开始设计测试用例。 培训需求通常包括学习如何使用某个工具、测试方法、缺陷跟踪系统、配置管理，或者与被测试系统相关的业务基础知识。培训需求各个测试项目会各不相同，它取决于具体项目的情况。 14．进度表测试进度是围绕着包含在项目计划中的主要事件（如文档、模块的交付日期，接口的可用性等）来构造的。作为测试计划的一部分，完成测试进度计划安排，可以为项目管理员提供信息，以便更好地安排整个项目的进度。 表6-4给出了一个例子。 进度安排会使测试过程容易管理。通常，项目管理员或者测试管理员最终负责进度安排，而测试人员参与安排自己的具体任务。 15．潜在的问题和风险软件测试人员要明确地指出计划过程中的风险，并与测试管理员和项目管理员交换意见。这些风险应该在测试计划中明确指出，在进度中予以考虑。有些风险是真正存在的，而有些最终证实是无所谓的，重要的是尽早明确指出，以免在项目晚期发现时感到惊慌。 一般而言，大多数测试小组都会发现自己的资源有限，不可能穷尽测试软件所有方面。如果能勾画出风险的轮廓，将有助于测试人员排定待测试项的优先顺序，并且有助于集中精力去关注那些极有可能发生失效的领域。下面是一些潜在的问题和风险的例子： 不现实的交付日期与其他系统的接口处理巨额现金的特征极其复杂的软件有过缺陷历史的模块发生过许多或者复杂变更的模块安全性、性能和可靠性问题难于变更或测试的特征 风险分析是一项十分艰巨的工作，尤其是第一次尝试进行时更是如此，但是以后会好起来，而且也值得这样做。 16．审批审批人应该是有权宣布已经为转入下一个阶段做好准备的某个人或某几个人。测试计划审批部分一个重要的部件是签名页。审批人除了在适当的位置签署自己的名字和日期外，还应该签署表明他们是否建议通过评审的意见。 6.4测试的组织与人员管理6.4.1测试的组织与人员管理概述测试项目成功完成的关键因素之一就是要有高素质的软件测试人员，并将他们有效地组织起来，分工合作，形成一支精干的队伍，使他们发挥出最大的工作效率。 测试的组织与人员管理就是对测试项目相关人员在组织形式、人员组成与职责方面所做的规划和安排。测试的组织与人员管理的任务是：（1）为测试项目选择合适的组织结构模式；（2）确定项目组内部的组织形式；（3）合理配备人员，明确分工和责任；（4）对项目成员的思想、心理和行为进行有效地管理，充分发挥他们的主观能动性，密切配合实现项目的目标。 测试的组织与人员管理应注意的原则是：（1）尽快落实责任从软件的生存周期看，测试往往指对程序的测试，但是，由于测试的依据是规格说明书、设计文档和使用说明书，如果设计有错误，测试的质量就难以保证。实际上，测试的准备工作在分析和设计阶段就开始了，在软件项目的开始就要尽早指定专人负责，让他有权去落实与测试有关的各项事宜。 （2）减少接口要尽可能地减少项目组内人与人之间的层次关系，缩短通信的路径，方便人员之间的沟通，提高工作效率。（3）责任明确、均衡项目组成员都必须明确自己在项目组中的地位、角色和职责，各成员所负的责任不应比委任的权力大，反之亦然。 6.4.2测试人员的组织结构组织结构是指用一定的模式对责任、权威和关系进行安排，直至通过这种结构发挥功能。测试组织结构设计时主要考虑以下因素。垂直还是平缓集中还是分散分级还是分散专业人员还是工作人员功能还是项目 选择合理高效的测试组织结构方案的准则是：（1）提供软件测试的快速决策能力；（2）利于合作，尤其是产品开发与测试开发之间的合作；（3）能够独立、规范、不带偏见地运作并具有精干的人员配置； （4）有利于满足软件测试与质量管理的关系；（5）有利于满足软件测试过程管理要求；（6）有利于为测试技术提供专有技术；（7）充分利用现有测试资源，特别是人；（8）对测试者的职业道德和事业产生积极的影响。 进行软件测试的测试组织结构形式很多，目前常见的测试组织结构有独立的测试小组和集成的测试小组两种形式。 1．独立测试小组独立的测试小组，即主要工作是进行测试的小组，他们专门从事软件的测试工作。测试组设组长一名，负责整个测试的计划、组织工作。测试组的其他成员由具有一定的分析、设计和测试经验的专业人员组成，人数根据具体情况可多可少，一般3～5人为宜。测试组长与开发组长在项目中的地位是同级、平等的关系。 2．集成测试小组集成测试小组是将测试与基本设计因素组合起来，构成的测试组织结构。这是与独立测试有关的一种集成测试组织形式，即集成测试小组是由需要向同一个项目经理汇报工作的测试人员和开发人员组成。 6.4.3测试人员测试人员的能力应包括以下几项。（1）一般能力：包括表达、交流、协调、管理、质量意识、过程方法、软件工程等；（2）测试技能及方法：包括测试基本概念及方法、测试工具及环境、专业测试标准、工作成绩评估等； （3）测试规划能力：包括风险分析及防范、软件放行/接收准则制定、测试目标及计划、测试计划和设计的评审方法等；（4）测试执行能力：包括测试数据/脚本/用例、测试比较及分析、缺陷记录及处理、自动化工具；（5）测试分析、报告和改进能力：包括测试度量、统计技术、测试报告、过程监测及持续改进。 测试组织管理者的工作能力在很大程度上决定测试工作的成功与否，测试管理是很困难的，测试组织的管理者必须具备：（1）了解与评价软件测试政策、标准、过程、工具、培训和度量的能力；（2）领导一个测试组织的能力，该组织必须坚强有力、独立自主、办事规范且没有偏见； （3）吸引并留住杰出测试专业人才的能力；（4）领导、沟通、支持和控制的能力；（5）有提出解决问题方案的能力；（6）测试时间、质量和成本控制的能力。 6.4.4人员的通信方式人员的沟通、交流方式主要有：（1）正式非个人方式，如正式会议等；（2）正式个人之间交流，如成员之间的正式讨论等（一般不形成决议）；（3）非正式个人之间交流，如个人之间的自由交流等； （4）电子通信，如E-mail（电子邮件）、BBS（电子公告板系统）等；（5）成员网络，如成员与小组之外或公司之外有经验的相关人员进行交流；在实践中发现，（5）的通信效率最高，其次是（1）。 6.4.5测试人员管理的激励机制激励，简单地说就是调动人的工作积极性，把潜力充分发挥出来。在管理学中，激励是指管理者促进、诱导下属形成动机，并引导其行为指向特定目标的活动过程。激励机制在测试组织建设中十分重要，测试组织的管理者不仅把测试人员组织在一起，团结在一起工作，更重要的是要善于调动测试人员的工作热情，激励每个成员都努力工作，实现项目的目标。测试人员管理的激励机制的关键点是： 管理者习惯用对自己有效的因素激励测试人员，很可能发现无效；过多行使权力、资金或处罚手段很可能导致项目失败；注意采取卓有成效的非货币形式的激励措施；在项目进行过程中，而不仅是在项目结果时实施激励措施； 奖励应该在工作获得认同后尽快兑现；对项目成员的工作表现出真诚的兴趣，是对他们最好的奖励；已经满足的需要很可能不再成为激励因素。激励因素是影响个人行为的东西，是因人而异、因时而异的。因此，管理者必须明确各种激励的方式，并合理使用。 作为测试人员，测试工件的7条效率原则是：主动思考，积极行动；一开始就牢记目标，不迷失方向；重要的事情放在首位（但常常把紧急的事情放在首位）；先理解人，后被人理解；寻求双赢；互相合作，追求1+1>2；终生学习，自我更新，不断进步。 6.4.6测试人员的培训如今，计算机软、硬件技术发展十分迅速，测试人员必须有足够的能力来适应这些变化。而另一方面，测试工作本身是一门需要技术的学问，它包含了众多的理论和实践。缺乏这些知识和经验，测试的深度和广度就不够，测试的质量就无法保证。从测试管理的角度来说，为了高效地实现测试工作的目标，需要不断地帮助他们进行知识的更新和技术能力的提升，这些就需要通过培训来达到。 1．软件测试培训内容2．制定测试人员培训计划 6.4.7测试的组织与人员管理中的风险管理在进行测试的组织与人员管理时，我们往往重视招聘、培训、考评、薪资等各个具体内容的操作，而忽视了其中的风险管理问题。 其实，每个公司在人事管理中都可能遇到风险，如招聘失败、新政策引起员工不满、技术骨干突然离职等等，这些事件会影响公司的正常运转，甚至会对公司造成致命的打击。如何防范这些风险的发生，是我们应该研究的问题。特别是高新技术企业，由于对人的依赖更大，所以更需要重视测试的组织与人员管理中的风险管理。 6.5软件测试过程管理6.5.1测试项目的跟踪与监控软件测试和软件开发一样，都遵循软件工程的原理，有它自己的生命周期。软件的测试过程管理基于广泛采用的“V”模型。“V”模型支持系统测试周期的任何阶段。 基于“V”模型，在开发周期中的每个阶段都有相关的测试阶段相对应，测试可以在需求分析阶段就及早开始，创建测试的准则。每个阶段都存在质量控制点，对每个阶段的任务、输入和输出都有明确的规定，以便对整个测试过程进行质量控制和配置管理。 根据质量管理中PDCA质量环的思想，需要对软件测试过程进行跟踪、检查，并与测试计划进行对比。测试计划中描述了如何实施和管理软件的测试过程，测试计划经批准生效后，将被用来作为对测试过程跟踪与监控的依据。测试项目的跟踪与监控的基础是软件测试计划。 在具体的测试项目的跟踪与监控过程中，可以采用周报、日报、例会，以及里程碑评审会等方式来了解测试项目的进展情况，建立、收集和分析项目的实际状态数据，对项目进行跟踪与监控，达到项目管理的目的。基于可靠的信息，明智的和有意义的决策可以很好地管理测试过程，在测试过程的每个阶段，测试项目管理人员应特别注意需要弄清楚以下问题： 系统现在是否做好测试准备？如果系统开始测试会有什么样的风险？当前测试所达到的覆盖率是怎样的？到目前为止取得了哪些成功？还要哪些测试要做？怎么证明系统已经经过了有效的测试？有哪些变更，哪些必须重新测试？ 6.5.2测试的配置管理配置管理的目的是建立和维护在软件生命周期中软件产品的完整性和一致性。一般来说，软件测试配置管理包括4个最基本的活动：（1）配置标识；（2）变更控制；（3）配置状态报告；（4）配置审计。 1．配置标识配置标识是配置管理的基础。所有配置项的操作权限都应当严格管理，其基本原则是：所有基线配置项向测试人员开放读取权限；而非基线配置项向测试组长、项目经理及相关人员开放。 配置标识主要是标识测试样品、测试标准、测试工具、测试文档（包括测试用例）、测试报告等配置项的名称和类型。所有配置项都应按照相关规定统一编号，按照相应的模板生成，并在文档中的规定部分记录对象的标识信息，标识各配置项的所有者及储存位置，指出何时基准化配置项（置于基线控制之下），这样使得测试相关人员能方便地知道每个配置项的内容和状态。 2．变更控制变更控制的目的并不是控制和限制变更的发生，而是对变更进行有效的管理，确保变更有序地进行。 变更控制主要包括以下内容。（1）规定测试基线，对每个基线必须描述下列内容：每个基线的项（包括文档、样品和工具等）；与每个基线有关的评审、批准事项以及验收标准。 （2）规定何时何人创立新的基线，如何创立；（3）确定变更请求的处理程序和终止条件；（4）确定变更请求的处理过程中各测试人员执行变更的职能；（5）确定变更请求和所产生结果的对应机制；（6）确定配置项提取和存入的控制机制与方式。 3．配置状态报告配置状态报告就是根据配置项操作数据库中的记录，来向管理者报告软件测试工作的进展情况。配置状态报告应该包括以下主要内容：（1）定义配置状态报告形式、内容和提交方式；（2）确认过程记录和跟踪问题报告，更改请求，更改次序等；（3）确定测试报告提交的时间与方式。 4．配置审计配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实地执行和实现。配置审计包括以下主要内容：（1）确定审计执行人员和执行时机；（2）确定审计的内容与方式；（3）确定发现问题的处理方法。 6.5.3软件测试风险管理1．风险的基本概念风险可定义为“伤害、损坏或损失的可能性；一种危险的可能或一种冒险事件。”风险涉及到一个事件发生的可能性，涉及到该事件产生的不良后果或影响。软件风险是指开发不成功引起损失的可能性，这种不成功事件会导致公司商业上的失败。风险分析是对软件中潜在的问题进行识别、估计和评价的过程。软件测试中的风险分析是根据测试软件将出现的风险，制定软件测试计划，并排列优先等级。 软件风险分析的目的是确定测试对象、测试优先级，以及测试的深度。有时还包括确定可以忽略的测试对象。通过风险分析，测试人员识别软件中高风险的部分，并进行严格彻底地测试；确定潜在的隐患软件构件，对其进行重点测试。在制定测试计划的过程中，可以将风险分析的结果用来确定软件测试的优先级与测试深度。 2．软件测试与商业风险软件测试是一种用来尽可能降低软件风险的控制措施。软件测试是检测软件开发是否符合计划，是否达到预期的结果的测试。如果检测表明软件的实现没有按照计划执行，或与预期目标不符，就要采取必要的改进行动。因此，公司的管理者应该依靠软件测试之类的措施来帮助自己实现商业目标。 3．软件风险分析风险分析是一个对潜在问题识别和评估的过程，即对测试的对象进行优先级划分。风险分析包括以下两个部分。发生的可能性：发生问题的可能性有多大。影响的严重性：如果问题发生了会有什么后果。 通常风险分析采用两种方法：表格分析法和矩阵分析法。通用的风险分析表包括以下几项内容。（1）风险标识：表示风险事件的惟一标识；（2）风险问题：风险问题发生现象的简单描述；（3）发生可能性：风险发生可能性的级别（1～10）； （4）影响的严重性：风险影响的严重性的级别（1～10）；（5）风险预测值：风险发生可能性与风险影响的严重性的乘积；（6）风险优先级：风险预测值从高向低的排序。 综上所述，软件风险分析的目的是：确定测试对象、确定优先级，以及测试深度。在测试计划阶段，可以用风险分析的结果来确定软件测试的优先级。对每个测试项和测试用例赋予优先代码，将测试分为高、中和低的优先级类型，这样可以在有限的资源和时间条件下，合理安排测试的覆盖度与深度。 4．软件测试风险软件测试的风险是指软件测试过程出现的或潜在的问题，造成的原因主要是测试计划的不充分、测试方法有误或测试过程的偏离，造成测试的补充以及结果不准确。测试的不成功导致软件交付潜藏着问题，一旦在运行时爆发，会带来很大的商业风险。 主要是对测试计划执行的风险分析与制定要采取的应急措施，降低软件测试产生的风险造成的危害。测试计划的风险一般指测试进度滞后或出现非计划事件，就是针对计划好的测试工作造成消极影响的所有因素，对于计划风险分析的工作是制定计划风险发生时应采取的应急措施。 其中，交付日期的风险是主要风险之一。测试未按计划完成，发布日期推迟，影响对客户提交产品的承诺，管理的可信度和公司的信誉都要受到考验，同时也受到竞争对手的威胁。交付日期的滞后，也可能是已经耗尽了所有的资源。计划风险分析所做的工作重点不在于分析风险产生的原因，重点应放在提前制定应急措施来应对风险发生。当测试计划风险发生时，可能采用的应急措施有：缩小范围、增加资源、减少过程等措施。 将采用的应急措施如下。应急措施1：增加资源。请求用户团队为测试工作提供更多的用户支持。应急措施2：缩小范围。决定在后续的发布中，实现较低优先级的特性。应急措施3：减少质量过程。在风险分析过程中，确定某些风险级别低的特征测试，或少测试。 上述列举的应急措施要涉及到有关方面的妥协，如果没有测试计划风险分析和应急措施处理风险，开发者和测试人员采取的措施就比较匆忙，将不利于将风险的损失控制到最小。因此，软件风险分析和测试计划风险分析与应急措施是相辅相成的。 由上面分析可以看出，计划风险、软件风险、重点测试、不测试，甚至整个软件的测试与应急措施都是围绕“用风险来确定测试工作优先级”这样的原则来构造的。软件测试存在着风险，如果提前重视风险，并且有所防范，就可以最大限度减少风险的发生。在项目过程中，风险管理的成功取决于如何计划、执行与检验每一个步骤。遗漏任何一点，风险管理都不会成功。 6.5.4软件测试的成本管理对于一般项目，项目的成本主要由项目直接成本、管理费用和期间费用等构成。 当一个测试项目开始后，就会发生一些不确定的事件。测试项目的管理者一般都在一种不能够完全确定的环境下管理项目，项目的成本费用可能出现难以预料的情况，因此，必须有一些可行的措施和办法，来帮助测试项目的管理者进行项目成本管理，即依据实际预算制定项目计划，实施整个项目生命周期内的成本度量和控制。 1．测试费用有效性风险承受的确定，从经济学的角度考虑就是确定需要完成多少测试，以及进行什么类型的测试。经济学所做的判断，确定了软件存在的缺陷是否可以接受，如果可以，能承受多少。测试的策略不再主要由软件人员和测试人员来确定，而是由商业的经济利益来决定的。 “太少的测试是犯罪，而太多的测试是浪费。”对风险测试得过少，会造成软件的缺陷和系统的瘫痪；而对风险测试得过多，就会使本来没有缺陷的系统进行没有必要的测试，或者是对轻微缺陷的系统所花费的测试费用远远大于它们给系统造成的损失。 测试费用的有效性，可以用测试费用的质量曲线来表示，如图6-1所示。随着测试费用的增加，发现的缺陷也会越多，两线相交的地方是过多测试开始的地方，这时，排除缺陷的测试费用超过了缺陷给系统造成的损失费用。 图6-1测试费用的质量曲线 2．测试成本控制测试成本控制也称为项目费用控制，就是在整个测试项目的实施过程中，定期收集项目的实际成本数据，与成本的计划值进行对比分析，并进行成本预测，及时发现并纠正偏差，使项目的成本目标尽可能好地实现。 测试工作的主要目标是使测试产能最大化，也就是，要使通过测试找出错误的能力最大化，而检测次数最小化。测试的成本控制目标是使测试开发成本、测试实施成本和测试维护成本最小化。在软件产品测试过程中，测试实施成本主要包括：测试准备成本、测试执行成本和测试结束成本。 （1）测试准备成本控制（2）测试执行成本控制 对部分重新测试进行合理的选择，将风险降至最低，而成本同样会很高，必须将其与测试执行成本进行比较，权衡利弊。利用测试自动化，进行重新测试，其成本效益是较好的。部分重新测试选择方法有两种：①对由于程序变化而受到影响的每一部分进行重新测试；②对与变化有密切和直接关系的部分进行重新测试。 （3）测试结束成本控制（4）降低测试实施成本（5）降低测试维护成本降低测试维护成本，与软件开发过程一样，加强软件测试的配置管理，所有测试的软件样品、测试文档（测试计划、测试说明、测试用例、测试记录、测试报告）都应置于配置管理系统控制之下。降低测试维护工作成本主要考虑： 对于测试中出现的偏差要增加测试；采用渐进式测试，以适应新变化的测试；定期检查维护所有测试用例，以获得测试效果的连续性。 保持测试用例效果的连续性是重要的措施，有以下几个方面：每一个测试用例都是可执行的，即被测产品功能上不应有任何变化；基于需求和功能的测试都应是适合的，若产品需求和功能发生小的变化，不应使测试用例无效；每一个测试用例不断增加使用价值，即每一个测试用例不应是完全冗余的，连续使用，应是成本效益高的。 3．质量成本测试是一种带有风险性的管理活动，可以使企业减少因为软件产品质量低劣，而花费不必要的成本。 （1）质量成本要素质量成本要素主要包括一致性成本和非一致性成本。一致性成本是指用于保证软件质量的支出，包括预防成本和测试预算，如测试计划、测试开发、测试实施费用。 非一致性成本是由出现的软件错误和测试过程故障（如延期、劣质的发布）引起的。这些问题会导致返工、补测、延迟。追加测试时间和资金就是一种由于内部故障引起的非一致性成本。非一致性成本还包括外部故障（软件遗留错误影响客户）引起部分。一般情况下，外部故障非一致性成本要大于一致性成本与内部故障非一致性成本之和。 （2）质量成本计算质量成本一般按下式计算：质量成本=一致性成本+非一致性成本 4．缺陷探测率缺陷探测率是另一个衡量测试工作效率的软件质量成本的指标。缺陷探测率=测试发现的软件缺陷数/(测试发现的软件缺陷数+客户发现并反馈技术支持人员进行修复的软件缺陷数) 测试投资回报率可按下式计算：投资回报率=(节约的成本−利润)/测试投资×100% 第7章软件测试自动化与软件测试工具7.1软件自动化测试基础7.2自动化测试的作用和优势7.3软件测试工具分类7.4几种常用软件测试工具 7.1软件自动化测试基础1．软件自动化测试的产生随着计算机日益广泛的应用，计算机软件越来越庞大和复杂，软件测试的工作量也越来越大。 随着人们对软件测试工作的重视，大量的软件测试自动化工具不断涌现出来，自动化测试能够满足软件公司想在最短的进度内充分测试其软件的需求，一些软件公司在这方面的投入，会对整个开发工作的质量、成本和周期带来非常明显的效果。 2．软件自动化测试的概念软件测试自动化就是通过测试工具或其他手段，按照测试工程师的预定计划对软件产品进行自动的测试，它是软件测试的一个重要组成部分，能够完成许多手工无法完成或者难以实现的一些测试工作。正确、合理地实施自动化测试，能够快速、全面地对软件进行测试，从而提高软件质量、节省经费、缩短产品发布周期。 自动化测试能够替代大量手工测试工作，避免重复测试，同时，它还能够完成大量手工无法完成的测试工作，如并发用户测试、大数据量测试、长时间运行可靠性测试等。 7.2自动化测试的作用和优势使用测试工具的目的就是要提高软件测试的效率和软件测试的质量。通常，自动化测试的好处有：产生可靠的系统；改进测试工作质量；减少测试工作量并加快测试进度。 1．产生可靠的系统测试工作的主要目标一是找出缺陷，从而减少应用中的错误；另一个是确保系统的性能满足用户的期望。为了有效地支持这些目标，在开发生存周期的需求定义阶段，当开发和细化需求时则应着手测试工作。 使用自动化测试可改进所有的测试领域，包括测试程序开发、测试执行，测试结果分析、故障状况和报告生成。它还支持所有的测试阶段，其中包括单元测试、集成测试、系统测试、验收测试与回归测试等。 通过使用自动化测试可获得的效果可归纳如下。（1）需求定义的改进（2）性能测试的改进（3）负载/压力测试的改进（4）高质量测量与测试最佳化（5）改进与开发组人员之间的关系（6）改进系统开发生存周期 2．改进测试工作质量通过使用自动化测试工具，可增加测试的深度与广度，改进测试工作质量。其具体好处可归纳如下。 （1）改进多平台兼容性测试（2）改进软件兼容性测试（3）改进普通测试执行（4）使测试集中于高级测试问题（5）执行手工测试无法完成的测试（6）重现软件缺陷的能力（7）测试无需用户干预 3．减少测试工作量并加快测试进度善于使用测试工具来进行测试，其节省时间并加快测试工作进度是毋庸置疑的，这也是自动化测试的主要优点。 表7-1列出了采用手工和自动化测试方式完成各测试步骤所需工作量的基准对比结果。该测试涉及1750个测试程序和700个错误。表7-1中的数字反映出通过测试自动化，测试工作总量减少75%。 软件自动化测试是软件测试技术的一个重要的组成部分，引入自动化测试可以提高软件质量，节省经费，缩短产品发布周期。然而，测试工具本身的优势并不意味着使用测试工具就能成功，关键还是在于使用工具的人。很多刚拥有测试工具的人，经常过分夸大工具的功效，并投入太高的期望。 但是，工具只是提供了解决问题的一种手段而已。成功的测试自动化需有以下两个关键的因素。①一个被很好理解的并且稳定的应用行为②一个专注的、有着丰富技能的测试组，并且被分配了足够的时间和资源 7.3软件测试工具分类软件测试工具的种类不少，有些以用途来分类，有些以价位来分类，有些则以使用特性来分类。基本上，分类只是一种归纳的方式，这里按照测试工具的主要用途和应用领域将测试软件做了一个整理归纳，将自动化测试工具分为以下几类： 捕获错误用途；一般用途；GUI自动化用途；专项用途；软件产品功能、性能测试用途；测试管理工具；测试辅助工具。 1．捕获错误用途顾名思义就是用于捕获软件错误或程序调试。2．一般用途这里所说的一般用途，是指这个测试工具在进行测试时，可以适用于大部分的软件。 3．GUI自动化用途目前许多以测试用软件为主要产品的软件公司，大多提供这类的自动化测试软件。这类软件除了提供在窗口界面中使用外，也有不少是针对浏览器接口开发的自动化测试工具。 4．专项用途以专项用途为主的测试工具，就是某种专项测试的软件。（1）专用代码测试工具（2）白盒测试工具（3）网络测试工具 5．软件产品功能、性能测试用途这类测试工具通过自动录制、检测和回放用户的应用操作，将被测系统的输出记录同预先给定的标准结果进行比较。 6．测试管理工具测试管理工具用于对测试进行管理。7．测试辅助工具这些工具本身并不执行测试，例如它们可以生成测试数据，为测试提供数据准备等。 7.4几种常用软件测试工具1．QACenterQACenter自动化测试系列工具是Compuware公司的产品，它能够帮助测试人员创建快速、可重用的测试过程。这些测试工具可以帮助管理测试过程，快速分析和调试程序，包括针对回归、强度、单元、并发、集成、移植、容量、负载测试、自动执行测试和产生测试结果文档。 QACenter主要包括QARun、QALoad、QADirector、EcoTools和TESTBytes等模块。 2．WinRunnerWinRunner是MercuryInteractive公司提供的一个企业级的功能检测工具。WinRunner使功能测试得以自动化，从而保证了应用程序按照预定方式运行。它以测试脚本形式将业务的过程记录下来，并随着相应的应用程序的开发或更新来支持对脚本的改进。执行脚本及报告结果在整个的应用周期中可对脚本重复使用。 3．LoadRunnerLoadRunner是MercuryInteractive公司开发的一种预测系统行为和性能的负载测试工具，它可以通过模拟成千上万个用户和实施实时监测来确认和查找问题。对于有实力的大公司而言，这款软件可能比较适合，它的功能和QALoad相比不相上下。通过使用LoadRunner，企业能够最大限度地缩短测试时间、优化性能和加速应用系统的发布周期。 LoadRunner是一种具有较高规模适应性的自动负载测试工具，它能预测系统行为，优化性能，强调的是整个企业的系统。通过模拟实际用户的操作行为和实行实时性能监测，来查找和确认存在的问题。 LoadRunner是一种具有较高规模适应性的自动负载测试工具，它能预测系统行为，优化性能，强调的是整个企业的系统。通过模拟实际用户的操作行为和实行实时性能监测，来查找和确认存在的问题。 4．GUI接口自动化测试工具目前市场上有关GUI形式的自动化测试软件种类相当多，而且所支持的操作平台也越来越多。基本上GUI自动测试的原理就是以录制和播放（RecordandReplay）为主要的操作方式。由于每一家开发公司所采用的开发技术不同，因此使用者所要学习的指令编写方式也大不相同。 虽然学习这些指令并不困难，但是要将这些测试软件的功能发挥好，就必须非常熟悉软件所提供的API及函数，所以如果要学会所有的GUI自动测试软件指令，也不是一件容易的事。由于GUI自动化测试软件有相当多的种类，在这里只介绍两种GUI自动化测试软件。它们分别是Rational公司发行的VisualTest与Seapine公司发行的QAWizardforWeb版本。 （1）VisualTest使用VisualTest并不困难，而且熟悉MicrosoftVisualStudio的使用者会发现它与VisualStudio的使用界面几乎相同。它使用类似VisualBasic的语言，编程进行起来简单直接，同时它也具备使用指针处理复杂数据结构的高级功能，这让用VisualTest更容易调用WindowsAPI。 它使用类似VisualBasic的语言，编程进行起来简单直接，同时它也具备使用指针处理复杂数据结构的高级功能，这让用VisualTest更容易调用WindowsAPI。 （2）QAWizardQAWizard是由Seapine软件公司开发的。基本上QAWizard也是一个录制和播放的自动化测试。 目前的版本只支持Microsoft的IE浏览器，而未来将推出支持Netscape浏览器的版本。QAWizard最大的好处是它已经不需要再去对所产生的Script进行修改，当然如果有必要的话，使用者也可以很容易地进行修改。在资料存储上它采用微软的AccessMDB。 在使用QAWizard录制使用者的操作行为时，在浏览器的上端会嵌入QAWizard的功能栏，这个功能栏提供了Record、Run、Pause、Stop、Checkpoint及Properties6种功能键。这6种功能可以让使用者自由地操作录制的过程。 5．BoundsCheckerBoundsChecker是用于VisualC++开发环境所开发的程序代码的一个很优秀的自动捕捉错误及调试工具。它最主要的功能是协助程序开发人员快速找出与内存及资源有关的错误，并且指出是哪一行程序代码所导致的。 6．CodeReviewCodeReview是针对VisualBasic开发环境所开发的程序代码分析工具。这套工具可以检测出VisualBasic程序代码内可能出现错误的环节，一旦问题被捕捉出来，CodeReview会将出错的内容及导致出错的原因一一呈现给开发人员。 7．SmartCheckSmartCheck也是针对VisualBasic开发环境的分析工具。8．JCheckJCheck是用来分析Java执行过程与事件的工具，它可实时监控程序执行的状态。JCheck的最大特点是能将Java语言的执行过程以图形化的方式表现出来。 9．TrueTimeTrueTime是分析程序执行性能的工具，它能够自动锁定延缓程序执行速度的程序代码，并产生分析报表。10．TrueCoverageTrueCoverage与TrueTime一样同时支持VisualC++、VisualBasic及Java程序语言。 11．FailSafeFailSafe可以让开发人员在程序代码中加入错误处理程序代码，在程序发生错误时产生报告以方便错误的追查，同时也可以避免程序因错误而造成不正常的结束。FailSafe可以提高编写VisualBasic程序的稳定度，同时也方便日后的产品维护。 第8章软件测试实例8.1被测试软件项目介绍8.2HIS测试过程概述8.3测试计划8.4测试用例8.5缺陷报告8.6测试结果总结分析8.7应用测试工具8.8文档测试 本章介绍的被测试软件项目是医院信息管理系统（HIS，HospitalInformationSystem）。HIS是一个集成度很高的项目，因为行业的关系其中有一些词汇可能不被大家所了解，但这并不妨碍说清楚它的测试过程。 本章要重点描述的测试过程是HIS的集成测试，该阶段的测试重点在功能测试上，也有必要的性能测试。后面依次给出了HIS集成测试阶段的测试计划、测试用例、缺陷（错误）报告、测试结果总结与分析等内容。测试用例将针对HIS的一个子系统——门诊挂号管理子系统来设计。该子系统不但包含了对数据库的应用，对系统的并发性、安全性、准确性、高效性都有很高的要求，可谓麻雀虽小，五脏俱全，适合将其进行剖析。 8.1被测试软件项目介绍8.1.1软件背景医院信息管理系统（HIS）包含门诊挂号、门诊收费、诊间医令、病房管理、病案管理、药房药库管理等二十余个子系统，用于管理医院日常运作的整个过程。各子系统所处理的业务前后衔接，数据共享。医院信息管理系统的系统结构如图8-1所示。 图8-1HIS1.0系统结构图 8.2HIS测试过程概述HIS的测试按照一般测试过程，将其分为单元测试、集成测试、系统测试和验收测试4个阶段。 8.2.1单元测试单元测试常常是动态测试和静态测试两种方式并举的。动态测试可由开发人员去运行局部功能或模块以发现系统潜藏的错误，也可以借助测试工具去测试。静态测试即是代码审查。审查的内容包括代码规则和风格，程序设计和结构，业务逻辑等。 HIS系统中涉及到许多的费用计算问题，逻辑性很强，需要程序结构也很复杂。面对复杂的业务流程，面对管理各异的用户需求，没有白盒测试是不可想像的。最简单的例子：HIS中要处理很多类的患者，普通患者、医保患者、内部职工、公费患者等，每类患者的费用处理流程和计算方法都不相同，开发人员就要严格地依照系统设计去检查代码的逻辑结构，选取有代表性的测试用例去测试相关的模块。 又如医嘱分解，药房摆药等，必须知道系统的详细设计和程序的逻辑结构才能设计好测试用例。 8.2.2集成测试集成测试（有时被分为集成测试和确认测试两个阶段）是指将各模块组装起来进行测试，以检查与设计相关的软件体系结构的有关问题，并确认软件是否满足需求规格说明书中确定的各种需求。HIS系统的集成测试是指开发人员完成了所有系统模块的开发并通过了单元测试后，将编译好的软件交付给测试部门进行测试的过程。 这个阶段的测试需要一个完备的测试管理过程。集成测试过程可以分为测试准备、测试计划、测试设计、测试执行和测试总结5个阶段。测试准备阶段是指测试人员准备测试资源，熟悉系统的过程。 测试计划阶段包含制定测试策略、资源分配、风险预警和进度安排等内容，此项工作由测试负责人来做。8.3节中给出了HIS集成测试的测试计划。测试计划的模板各不相同，这个取决于软件的特殊性和管理的规范性。 测试设计阶段包括设计测试用例及相关管理工具的设计。8.4节将给出HIS集成测试过程中挂号管理子系统部分的主要测试用例，侧重于系统的功能和性能测试。测试用例设计之前一般要有一个测试用例的设计大纲。完成测试设计工作后，就开始执行实际的测试工作了。 测试时另外一项非常重要的工作就是做好系统缺陷记录。本章8.5节将给出系统生成缺陷报告的注意事项以及缺陷报告的实例，另外还设计了一个问题记录数据库表。用数据库记录缺陷的好处是测试人员和开发人员能够通过动态的信息发布和获取进行更好的交互，提高测试和修改的工作效率。经过修改后的系统再次经过测试即是回归测试。 测试结束后要及时总结分析测试结果。测试结果的总结与分析一方面是提供一个系统功能、性能和稳定性等方面的完整的分析和结论，另外要对测试过程本身做出总结，总结成功的经验和失败的教训，以使日后的工作开展得更顺利。具体的测试总结详见8.6节。 8.2.3系统测试系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接，并满足用户需求。 系统测试也应该经过测试准备、测试计划、测试设计、测试执行和测试总结5个阶段，每个阶段所做工作内容与集成测试很相似，只是关注点有所不同。在HIS系统的系统测试中，要搭建更真实的运行环境，另外还要在不同的操作系统下进行测试，如数据库服务器分别搭建在UNIX环境和WINNT环境下长时间多客户端并发运行系统的各项功能，并观测服务器的承受能力（系统的反应时间，服务器的资源占用情况等）。 8.2.4验收测试验收测试是指在用户对软件系统验收之前组织的系统测试。测试人员都是真正的用户，在尽可能真实的环境下进行操作，并将测试结果进行汇总，由相关管理人员对软件做出评价以及是否验收的决定。 HIS系统一般在用户验收之前都需要对系统进行一段时间的试运行，因此可以说HIS的验收测试就是实际的使用（但用户一般要参与软件的系统测试，即所谓的测试，不然用户是不会放心让系统试运行的）。因为验收测试由用户完成，不同软件实际应用的差异性又很大，这里就不对其详加论述了。 8.3测试计划测试计划工作的提交成果是一份完整的测试计划报告。下面给出医院信息管理系统1.0版集成测试的测试计划报告。 8.3.1概述本测试项目拟对医院信息管理系统（HIS）1.0进行测试。医院信息管理系统包含门诊挂号、门诊收费、诊间医令、病房管理、病案管理、药房药库管理等二十余个子系统，用于管理医院日常运作的整个过程，各子系统所处理的业务前后衔接，数据共享。 测试的目标是要找出影响医院信息管理系统正常运行的错误，分别在功能、性能、安全性等方面检验系统是否达到相关要求。本次集成测试采用黑盒和白盒测试技术（重点在黑盒测试）。测试手段为手工与自动测试相结合（主要依靠手工进行功能测试，依靠自动测试工具进行性能测试）。本测试计划面向相关项目管理人员、测试人员和开发人员。 8.3.2定义质量风险：被测试系统不能实现描述的产品需求或系统不能达到用户的期望的行为，即系统可能存在的错误。测试用例：为了查找被测试软件中的错误而设计的一系列的操作数据和执行步骤，即一系列测试条件的组合。 测试工具：应用于测试用例的硬件/软件系统，用于安装或撤销测试环境、创造测试条件，执行测试，或者度量测试结果等工作。测试工具独立于测试用例本身。进入标准：一套决策的指导方针，用于决定项目是否准备好进入特定的测试阶段。在集成测试和系统测试阶段，进入标准会很苛刻。 退出标准：一套标准，用于决定项目是否可以退出当前的测试阶段，或者进入下一个测试阶段或者结束项目。同进入标准，测试过程的后几个阶段退出标准一般很苛刻。功能测试：集中于功能正确性方面的测试。功能测试必须和其他测试方法一起处理潜在的重要的质量风险，比如性能、负荷、容积和容量等。 8.3.3质量风险摘要危险性：表示故障对系统影响的大小。5—致命；4—严重；3—一般；2—轻微；1—无。影响：5—一定影响所有用户；4—可能影响一些用户；3—对有些用户可能的影响；2—对少数用户有限的影响；1—在实际使用中难以觉察的影响。 优先级：表示风险可以被接受的程度。5—很紧急，必须马上纠正；4—不影响进一步测试，但必须修复；3—系统发布前必须修复；2—如果时间允许应该修复；1—最好修复。 8.3.4测试进度计划8.3.5进入标准（1）“测试小组”配置好软硬件环境，并且可以正确访问这些环境。（2）“开发小组”已完成所有特性和错误修复并完成修复后的单元测试。（3）“测试小组”完成“冒烟测试”，程序包能打开，随机的测试操作正确完成。 8.3.6退出标准（1）“开发小组”完成了所有必须修复的错误。（2）“测试小组”完成了所有计划的测试。没有优先级为3以上的错误。优先级为2以下的错误少于5个。（3）“项目管理小组”认为产品实现稳定性和可靠性。 8.3.7测试配置和环境服务器1台：HPPentiumⅢ550，1GB内存，8.4GB硬盘；软件环境：WindowsNT，Oracle。客户机10台：PentiumMMX166，1.2GB硬盘，32MB内存；软件环境：Oracle客户端。打印机1台：PanasonicKX-P1131。地点：58号楼101室。 8.3.8测试开发设计测试用例以进行手工测试。准备使用MILoadRunner，以检测系统对并发性的控制和系统的强壮性。设计开发问题记录及交互工具，包括问题存取控制系统及所对应的数据库，以对测试结果做很好的记录并提供相关测试和开发人员的交互平台。 8.3.9关键参与者测试经理：宋欣欣（制定测试计划及部署、监督相关工作）。测试人员：蔡亮，邱实，崔进，赫北松，洪怡，武刚，沙盼盼，王军妹（负责相关子系统测试）。开发人员：王铁全，李云帆，夏淼，张铁（及时解决影响测试进行的系统问题）。项目管理人员：王斌（跟踪项目进展）。 8.3.10预算8.3.11参考文档 8.4测试用例测试用例应由测试人员在充分了解系统的基础上在测试之前设计好，测试用例的设计是测试系统开发中一项非常重要的内容。集成测试阶段测试用例的设计依据为系统需求分析、系统用户手册和系统设计报告等相关资料的内容，而且测试人员要与开发人员充分交互。另外有一些内容由测试人员的相关背景知识、经验、直觉等产生。 测试用例的设计需要考虑很周全。在测试系统功能的同时，还要检查系统对输入数据（合法值、非法值和边界值）的反应，要检查合法的操作和非法的操作，检查系统对条件组合的反应等。好的测试用例让其他人能够很好地执行测试，能够快速地遍历所测试的功能，能够发现至今没有发现的错误。所以测试用例应该由经验丰富的系统测试人员来编写，对于新手来说，应该多阅读一些好的测试用例，并且在测试实践中用心去体会。 在编写测试用例之前，应该给出测试大纲，大纲基本上是测试思路的整理，以保证测试用例的设计能够清晰、完整而不是顾此失彼。测试大纲可以按照模块、功能点、菜单和业务流程这样的思路来策划。本节给出“医院信息管理系统1.0”的“门诊挂号管理子系统”的测试大纲和测试用例的主体部分。 8.4.1挂号管理子系统测试大纲8.4.2其他可用性测试检查标准软件产品的可用性是指软件产品能否让用户更快更容易地完成工作，即软件是否易学、易用，并使用户感到满意。软件产品的可用性主要反映在软件产品的用户界面及操作过程上减少错误出现，提高用户工作效率，增加用户满意度。 对于开发商而言可以缩减服务和培训费用，提高用户满意度。软件可用性已经越来越引起用户和开发商的关注。可用性测试对所有功能模块来说，检测标准是相同的，而这些检测在功能测试的同时即可检验，所以不再设计单独的测试用例。 8.4.3功能测试用例1．普通挂号，要病历本的测试用例2．预约挂号，老患者，不要病历本的测试用例3．预约挂号，不要病历本，无挂号费有诊察费的测试用例 4．有挂号费无诊察费，要病历本的测试用例5．退号，不退病历本的测试用例6．退号测试用例，包括病历本的测试用例7．挂号员结算的测试用例8．挂号员结算补打的测试用例 8.4.4性能测试用例 8.5缺陷报告这里给出一个利用数据作缺陷记录报告的实例。错误跟踪数据库可以自己开发，也可以购买现成的产品。 8.5.1建立缺陷报告数据库缺陷报告数据库应该在测试工作的准备配置阶段就建立起来，测试执行阶段，测试人员、开发人员和项目管理评估人员可以采用各种方式通过缺陷报告数据库进行交互，而可以自行开发一个小系统，使得数据库能够记录下人们访问数据库的一切活动。先设计一个缺陷记录的数据表结构。 8.5.2编写缺陷报告关于测试人员、系统开发人员和相关问题评审人员打开、读取和写入缺陷报告数据库，以何种形式并不重要，重要的是对于问题的描述应该是完整的、严谨的、简洁的、清晰的和准确的。 下面列出编写好的错误报告的几个要点（也是测试执行应该遵循的一些原则）。（1）再现：尽量三次再现故障。如果问题是间断的，那要报告问题发生频率。（2）隔离：确定可能影响再现的变量，例如配置变化、工作流、数据集，这些都可能改变错误的特征。 （3）推广：确定系统其他部分是否可能出现这种错误，特别是那些可能存在更加严重特征的部分。（4）压缩：精简任何不必要的信息，特别是冗余的测试步骤。（5）去除歧义：使用清晰的语言，尤其要避免使用那些有多个不同或相反含义的词汇。 （6）中立：公正表达自己的意思，对错误及其特征的事实进行陈述，避免夸张、幽默或讽刺。（7）评审：至少有一个同行，最好是一个有丰富经验的测试工程师或测试经理，在你递交错误报告之前先读一遍。为了说明一个基本的测试缺陷报告应该具有的内容，截取了本章所介绍案例HIS1.0中挂号管理子系统集成测试缺陷报告中的一页，如图8-5所示。 图8-5测试缺陷报告示例 8.6测试结果总结分析8.6.1测试总结报告图8-6所示的是测试总结报告的一个模板，各行业、各阶段的软件测试会有具体不同的总结报告，但基本上应该有本模板所展示的项目。 图8-6测试总结报告的一个模板 8.6.2测试用例分析对工作的及时总结，会及时调整方向，大大提高工作效率。测试工作的效果要直接依赖测试用例的编写和执行状况，所以在测试过程中和测试结束后都要对关于测试用例的一些重要值进行度量。 关于测试用例的分析，通常包括以下的内容：计划了多少个测试用例，实际运行了多少？有多少测试用例失败了？在这些失败的测试用例中，有多少个在错误得到修改后最终运行成功了？这些测试平均占用的运行时间比预期的长还是短？ 有没有跳过一些测试？如果有，为什么？测试覆盖了所有影响系统性能的重要事件吗？等等。这些问题都可以从相关的测试用例的设计和测试问题记录中找到相应的答案。当然，如果使用了数据库，这些问题就更能轻松地被解答了。测试用例的分析报告可以以多种形式体现出来：文字描述、表、图等。 8.6.3软件测试结果统计分析软件问题统计与分析，在对软件产品测试过程中发现的问题进行充分分析、归纳和总结的基础上，由全体参与测试的人员完成“软件问题倾向分析表”，对该软件或该类型系统软件产品在模块、功能及操作等方面出错倾向及其主要原因进行分析。软件问题倾向分析表将为以后开发工作提供一个参考，使开发人员根据软件问题倾向分析表明确在开发过程中应注意和回避的问题。该表也可为以后的测试工作明确测试重点提供依据。 图8-7表达的是软件的不同版本在测试时检测出的缺陷(Bug)数的对应关系。这里的版本指的是同一软件经过不同的测试阶段并修复Bug及作必要的调整后所产生的软件产品。显然，该图所表达的测试结果的变化是非常理想的。 图8-7按版本统计结果示例 图8-8表达的是在一个测试阶段所发现的缺陷数与测试日期之间的对应关系。测试过程中所发现的缺陷是随着时间的推移而增多的，但一段时间后，测试所发现的缺陷增加会渐缓，甚至没有增加，如果测试还在进行，那么表明，在现有测试用例、软硬件环境及相关条件下已经很难再发现新的缺陷了（虽然可以肯定系统中仍然存在缺陷），那么这个测试阶段应该考虑停止了。 图8-8按日期统计结果示例 图8-9表达的是测试中所发现的不同等级的缺陷的数目。关于A、B、C、D等级（或者还有E、F、G、…）所表达的不同含义由相关测试和开发人员来制定，而这种按等级的统计结果可以清楚地反映开发工作中的薄弱之处。 图8-9按等级统计结果示例 图8-10表达的是测试所发现的缺陷数目与究其原因缺陷所属的软件工程的不同阶段之间的关系。这个图表会又一次验证软件工程的任何阶段都会有导致程序中产生错误的因素，只是程度和数目不同而已。通过该图表的分析，可以清楚地看到，软件工程中的哪个阶段更应该加强控制。 图8-10按原因统计结果示例 图8-11表达的是程序的不同模块与在其中所发现的缺陷数目之间的关系。缺陷的产生有多方面的原因，但也可以从该图中反映出哪些程序员所开发的模块中Bug很多，而另一些程序员的则很少，那么在相同的系统设计和工作条件下，这也反映了程序员的工作能力或者责任感的不同。 图8-11按模块统计结果示例 图8-12表达的是在测试过程中每日发现的错误报告公开、关闭的对应关系图。公开是指错误被发现并被公告，关闭则指错误已被处理完毕的状况。图中中间两条粗线反映的是错误累计公开和累计关闭的实际状况。随着时间的推移，累计公开和累计关闭的错误数目都是渐增的，但到某个时间点，两条曲线会会合，即累计公开的数目等于累计关闭的数目，那就是说所有发现的错误都得到了处理。 图8-12按公开/关闭日期统计图表 图8-13表达的是错误原因分析，其中纵轴表达的是每类测试发现错误占所有错误的百分比。可以看出，只有每个错误都被明确细致地归类后才能得到这样的分析图表，也才能知道该从哪里去控制以减少错误的产生。 图8-13错误原因分析 图8-14表达的是对系统性能测试所产生的分析数据、图和简单的结论。这种分析是在系统经过性能测试后所必不可少的。性能测试的分析一般从并发用户数、系统响应时间以及CPU的利用率几方面来表述。 图8-14系统响应时间与用户数对比分析（性能测试结果分析） 8.7应用测试工具实际测试需要投入大量的时间和精力，测试工作同样也可以采用其他领域和行业中运用多年的办法——开发和使用工具，即自动化测试使工作更加轻松和高效。采用测试工具不但能提高效率，节约成本，还可以模拟许多手工无法模拟的真实场景。 当建立一个新的测试项目时，测试工具会自动生成测试代码，用户可以根据需要进行修改，自动测试工具再执行这些代码。图8-15显示的是测试工具在建立一个新的测试项目时产生的原始代码和测试执行记录，只是截取了其中的片断。这些代码很冗长，可不用担心，一切都是自动测试工具为你生成的。 图8-15自动测试工具所生成的代码 为了测试挂号管理子系统的并发性控制，按照前面的测试用例，选择10用户并发执行，每用户连续执行200次停止。如图8-16所示的是增加用户进程控制界面。10用户可以一起加入，而模拟3000用户时，可以批量加入用户，如每5分钟加入600用户，这样可能更接近于实际场景。 图8-16增加用户进程的界面 脚本开始运行后，LoadRunner会跟踪被测试系统的运行状况以及监控被测试设备的资源使用情况，如图8-17所示。 图8-17自动测试监控场景 8.8文档测试广义地说，文档测试也是软件测试的一项内容。文档测试包括对系统需求分析说明书、系统设计报告、用户手册以及与系统相关的一切文档、管理文件的审阅、评测。 系统需求分析和系统设计说明书中的错误将直接带来程序的错误；而用户手册将随着软件产品交付用户使用，是产品的一部分，也将直接影响用户对系统的使用效果，所以任何文档的表述都应该清楚、准确，含糊不得。 文档测试时应该慢慢仔细阅读文字。特别是用户手册，应完全根据提示操作，将执行结果与文档描述进行比较。不要任何假设。耐心补充遗漏的内容，耐心更正错误的内容和表述不清楚的内容。'