第1章  软件测试引论

1.1  质量和质量认识论

质量的重要性是显而易见的，客户不可能去购买一个存在质量问题的产品，生产厂商如果生产出存在质量问题的产品就不可能卖出去。因此，有不少人说质量是决定产品存在的价值，质量是企业的生命。那么，什么叫质量呢？

质量这一概念有许多不同的定义，不同的立场，不同的观念，对质量的定义就会不同。抛开这些因素，举例说明。《辞海》和《辞源》中，把质量解释为“产品或工作的优劣程度”。世界著名质量管理专家Juran博士，在他的经典著作《质量控制手册》中，把质量定义为“产品在使用时能成功地适合用户目的的程度”。再如，国际标准化组织（ISO）把质量定义为：“反映实体（可单独描述和研究的事物，如活动、过程、产品、组织、体系或人，以及它们各项的任何组合）满足明确和隐含需要能力的特性总和”。那么，人们是如何认识质量的呢？

狭义的质量概念就是产品质量。所谓产品质量好，往往被人们认为生产出最佳产品，即在尽可能充分利用现代生产技术水平的条件下，制造出最好的产品。而且，所谓“好”，常常仅从产品性能着眼。这种概念不能反映质量的全部内容。

广义的质量概念包括产品质量和工作质量两个组成部分，即全面质量。它既要反映客观的要求，又要考虑到设计、制造、销售服务的水平和能力。

在这里，需要对产品作一解释，产品可分为4种类别，即硬件、流程性材料、软件和服务。硬件是不连续的具有特定形状的产品，如空调、洗衣机、电视机等；流程性材料是将原料转化为某一预定状态的有形产品，如流体、气体、粒状、块状、线状或板状，其典型的交付方式有桶装、袋装、罐装、瓶装或通过管道；软件是通过支持媒体表达的信息所构成的一种智力创作，软件的形式如概念、信息、程序、规划、记录、计算机程序等，可见此处的软件是泛指，不单指计算机软件；服务是为满足客户的需要，供方和顾客之间在接触时的活动，以及供方内部活动所产生的结果。因此，产品的提供和使用可构成服务提供的一部分。服务可以与产品的制造和提供相关联。当然，服务亦需投入资源和活动，也是一种价值的增值。

影响质量的因素是什么？其包括5大因素：人、材料、设备、方法和环境。显而易见，人的因素第一，有了人的主动性、对质量的深刻认识，就会非常重视质量的各个环节；材料也非常重要，半导体的收音机和集成电路的收音机取材不同，质量也就有天壤之别；设备的先进程度和工作状态的好坏也能够深刻影响产品质量；方法包含内容更广泛，它可以是生产方法、设计方法、管理方法、检验方法，这就是技术因素；环境也非常重要，集成电路的生产就与环境密切相关，如尘埃就能决定集成电路块是否报废。

任何一个机构，都必须确定质量目标，质量目标就是产品和工程质量在一定时间内可达到的水平，产品和工程质量目标的制订需做3个方面的调查。

（1）用户对开发新产品或改进老产品的意见和要求，包括产品性能、可靠性、安全性、价格、使用维修、外观包装和运输储存等。

（2）生产过程中老产品曾经出现过的问题及新产品开发中可能发生的问题。

（3）国内外有关的技术与经济情况。

制定质量目标还需考虑成本的增加。任何一个产品或者工程项目，其价格是由销售成本所决定的，销售成本包括生产成本、质量成本和利润。就质量成本而言，包括损失成本、检验成本和预防成本。损失成本是因产品未能达到质量要求而造成的各项损失费用，一般包括内部损失（如报废、返修、降级等）和外部损失（如拒收、索赔、声誉破坏等）；检验成本是用于检验产品质量所需的各项费用；预防成本是用于预防产生不良产品所需的各项费用，如员工培训、质量管理开销、检测设备购置等。

现在人们不仅从技术层面上去思考产品质量，也从质量管理的角度去思考产品的质量保证，ISO 9000、CMM等都可以看作质量管理所引发的对机构在质量保证方面的考核。所谓质量管理就是为保证和提高产品或工程质量所进行的调查、计划、组织、协调、控制、检查、处理及信息反馈等各项活动的总和。按照国际标准化组织的定义，则包括确定质量方针、目标和职责，并在质量体系中通过例如质量策划、质量控制、质量保证和质量改进，使其实施全部管理职能的所有活动。质量体系是为实施质量管理所需的组织结构、程序、过程和资源；质量策划是确定质量以及采用质量体系要素的目标和要求的活动，包括产品策划、管理和作业策划，以及质量计划的编制和质量改进的准备工作；质量控制是为达到质量要求所采取的作业技术和活动；质量保证是为了提供足够的信任表明实体能满足质量要求，而在质量体系中实施并根据需要进行证实的全部有计划有系统的活动；质量改进是为向本机构及其顾客提供更多的收益，在整个机构内所采取的旨在提高活动和过程的效益和效率的各种措施。有关这些概念的认识，读者可以参考清华大学出版社于1999年出版的《软件企业ISO 9000质量体系的建立和认证》一书。

1.2  软件产品和其他产品的差异

1.1节中所讲的产品包括4种类别，其中的软件还不是单指计算机软件，其范围亦大得多。自从1968年提出软件工程这一概念以来，就希望能够借助传统的工程方法来研发出软件产品。因此，软件产品在某些方面的确相似于其他工程中的有形产品，但毕竟不相同，它们之间存在一些重要的差别。所以，在软件工程中，人们认识到不能够简单地把一般工程中的知识、方法和技术直接应用到软件工程上来。那么软件产品和其他产品有什么不同呢？

（1）软件是逻辑产品而不是实物产品。可以粗略地说软件不是有形产品，磁盘、集成电路块只是软件的载体。这一事实就意味着费用集中在研制开发上而不在生产上。当然，由于是逻辑产品，软件就不会用坏、磨损、老化，而且可以不断地改进、优化，其可靠性由逻辑确定。开发软件在许多方面更像进行数学证明，可是软件产品的评价却主要决定于它们在问题求解中是否有用，而不是决定于抽象的正确性判定标准。换句话说，开发软件产品时主要使用的是工程标准，而不是数学标准。

（2）由于软件是逻辑产品，使得它的功能只能依赖于硬件和软件的运行环境，以及人们对它的操作，才能得以体现。没有计算机相关硬件的支持，软件难有实用价值。同样，没有软件支持的计算机硬件，也只是毫无使用价值的机器。软件与硬件的密切相关的程度是一般工程所没有的。

（3）对软件产品的要求比一般有形产品要复杂。其一，软件产品要完成的多种多样功能，用户难以清晰、准确地表达。凭此一项，软件系统的复杂性可以比得上历史上任何一个工程项目：即使保守估计，一个100万条汇编语句的软件，至少有1万个分功能，其中每一个分功能至少可以用两种不同方式制定。所以，在功能上，软件设计者也得要从2¹⁰⁰⁰⁰（相当于10³⁰⁰⁰）种功能组合中进行挑选。其二，对软件产品的要求，如可靠性、易移植性、易使用性等是隐含的，也是难以表达的，而且也缺少度量的具体标准，和有形产品的质量检验的精度相距甚远。其三，软件设计不仅涉及到技术复杂性，也涉及到管理复杂性。     美国Hetgel曾讲过，当他负责一个软件研制小组时，认为关键的问题是方法学问题；当他负责50人的软件开发项目组时，逐渐理解到除方法学之外，程序文档变得越来越重要了；后来他又领导200人的软件开发项目组时，他的认识又有了变化，认识到最关键的问题是管理问题。这是很有代表性的认知过程。即使在今天软件工程已有很大进展的情况下，许多人都不愿意去领导一个庞大的项目组。能像其他工程项目那样进行规模化生产并非易事。

（4）在软件设计时发生的复杂性，引起的软件特征包括4方面。其一，功能的多样性。软件提供的功能比一般工程产品提供的功能更加多种多样，以致用户一时难以掌握。为此，使用软件产品，往往还会伴随一个培训任务，而且软件产品的用户手册还不一定能全面描述其功能。其二，实现的多样性。对软件产品的要求不仅仅包括功能和性能要求，还必须包括在符合功能和性能要求的各种实现中作出选择，更有实现算法上的优化带来的不同，所以实现上的差异会带来使用上的差异。其三，能见度低。要看到软件进度比看到有形产品的进度难得多，这里涉及到如何使用文档（document）表示的概念能见度，这又为软件管理复杂性增加难度。其四，软件结构的合理性差。结构不合理使软件管理复杂性随着软件规模增大而呈指数增长，换句话说，软件规模的增长所引起的管理复杂性成了设计的难题。总之，前两方面属于技术复杂性。后两方面属于管理复杂性。为了控制软件复杂性，人们进行了各种研究，这在一般工程中是前所未有的。

（5）任何一种工程，在其年轻时代总是人工密集的，而到其成熟时期却成为资金密集的。但是软件工程却也有它自己的特点，尽管今后可能有许多活动可以自动化，而软件的资金密集程度终究会比其他工程学科中的资金密集程度高，其中包含更多的人的成分，可以说软件工程是智力密集型。从而，它的知识产权保护就显得极为重要，软件本身会越来越值钱，逐步体现出它应有的价值。

1.3  软 件 质 量

1.2节讨论了软件产品与其他产品的差异，那么软件产品质量与其他产品的质量有没有区别呢？先来看软件质量的定义：反映软件系统或软件产品满足明确或隐含需求的能力有关的特性总和。其含义有四：其一，能满足给定需要的性质和特性的全体；其二，具有所期望的各种属性的组合程度；其三，顾客和用户觉得能满足其综合期望的程度；其四，确定软件在使用中将满足顾客预期要求的程度。简言之，软件质量是软件一些特性的组合，它依赖软件的本身。

对于软件质量有多种不同的视面。用户主要感兴趣的是如何使用软件、软件性能和使用软件的效用，特别是在指定的使用环境（context）下获得与有效性、生产率、安全性和满意度有关的规定目标的能力，即使用质量。开发者负责生产出满足质量要求的软件，所以他们对中间制品和最终产品的质量都感兴趣，当然开发者视面也要体现软件维护者所需要的质量特性。对于管理者也许更注重总的质量而不是某一特性，必须从管理准则，如在进度拖延或成本超支与质量提高之间进行权衡，以达到用有限的人力、成本和时间使软件质量达到优化的目的。

保证软件质量基本上可用两种途径来实现，一种是保证生存周期过程，另一种是评价软件最终产品的质量。这两种途径都很重要，且都要求有一系统来管理质量，该系统应确定管理对质量的保证，指明其策略以及恰当的详细执行步骤。前者是采用ISO 9001质量体系——设计、开发、生产、安装和服务的质量保证模式，或者CMM——能力成熟度模型，或者ISO 15504软件过程评估（也称为SPICE，即软件过程改进和能力确定）等方法来取得满足质量要求的软件。后者是把软件产品评价看作软件生存周期的一个过程，目标就是让软件产品在指定的使用环境下具有所需的效用，可以通过测量内部属性，也可以通过测量外部属性，或者通过测量使用质量属性来评价。

软件质量管理  经济地实现符合用户要求的软件质量或服务的方法体系及其一系列活动，具体包括确定质量方针和目标、确定岗位职责和权限、建立质量体系（如质量策划、质量控制、质量保证和质量改进）并使之有效运行等所有活动。任何一个机构，要想使自己提供给用户的产品达到并保持一定的质量水平，都必须进行严格的质量管理。对于一个软件机构来说，也必须建立质量管理体系。目前能被大家接受和公认的是基于软件生存周期过程的质量管理，包括ISO 9001、CMM、ISO 15504等都是属于这种类型，如能力成熟度模型（CMM）较全面地描述和分析软件机构的软件过程能力的发展程度，建立了一个描述软件机构的软件过程成熟度的分级标准和框架。软件过程能力是描述遵循一个软件过程而得到期望结果的程度，软件过程成熟度是指一个具体的软件过程被明确定义、管理、控制其实效的程度。利用能力成熟度模型，软件机构可以评估自己当前的过程成熟度，并通过提出更严格的软件质量标准和过程改进，来选择自己的改进策略，以达到更高一级的成熟程度。软件产品评价需要策划和管理，从而也是管理职能中的一个部分。

软件质量模型  一个框架，它规定了内部和外部质量的质量模型与使用质量的质量模型，以及它们在软件生存周期中的关系。内部和外部质量的质量模型将软件质量属性分类为6个特性，即功能性、可靠性、易用性、效率、易维护性和易移植性，并进一步细分为27个子特性，从而构成一个有层次的树状结构，结构的最高层由质量特性组成，最低层则由软件质量属性组成。使用质量的质量模型将软件质量属性分类为4个特性，即有效性、生产率、安全性和满意度。获得软件的使用质量依赖于所取得的外部质量，而取得的外部质量依赖于获得必要的内部质量，所取得的内部质量又依赖于生存周期中所规定的过程的质量。同样，为了获得所需的使用质量，就有助于确定外部质量需求，从而有助于确定内部质量需求，进而有助于确定过程的质量。

软件质量特性

功能性：在指定条件下使用时，软件产品提供满足明确和隐含需求功能的能力；

可靠性：在指定条件下使用时，软件产品维持规定的性能级别的能力；

易用性：在指定条件下使用时，软件产品被理解、学习、使用及其吸引用户的能力；

效率：在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力；

易维护性：软件产品可被修改的能力，修改可能包括修正、改进或者适应环境、需求和功能规约的变化；

易移植性：软件产品从一种环境迁移到另一种环境的能力；

有效性：软件产品在指定使用环境下，使用户准确、完整地获得规定目标的能力；

生产率：软件产品在指定使用环境下，使用户花费合适的与有效性相关的资源数量的能力；

安全性：软件产品在指定使用环境下，获得可接受的损害人类、商务、软件、财产或环境风险级别的能力；

满意度：软件产品在指定使用环境下，使用户满意的能力。

软件质量度量  能被用来确定软件系统或软件产品某属性值的一种测量方法或测量尺度。测量尺度可以根据满足不同程度的需求细分为多个级别，如划分为两级，不能令人满意的和令人满意的；如划分为4级，包括超出需求、达到目标、可接受的最低级别和不可接受的。软件质量度量有内部度量、外部度量和使用质量的度量3种。内部度量可应用于在设计和编码期间的非执行软件产品（如设计规约或源代码），能提供给用户、评价者、测试员和开发者评价软件质量，并尽早地发布质量问题。外部度量是通过测试、操作和观察可执行软件，能提供给用户、评价者、测试员和开发者评价软件质量。使用质量的度量是在指定使用环境下，测量有效性、生产率、安全性和满意度达到所规定的目标的程度。

最初由Rubey和Hartwick于1968年提出了一些属性的测量方法，但未建立质量度量体系。Boehm等人于1976年提出了定量地评价软件质量的概念，并提出了60个质量度量公式，并首次提出了软件质量度量的层次模型。1978年Walters和McCall提出了从软件质量要素、准则到度量的3层次软件质量模型，将质量要素降到11个。上海计算机软件中心于1988年提出了软件质量评价体系，由6个质量特性和22个评价准则，以及众多的度量和度量元构成了一个4层次树状模型，并提出了评价准则与质量特性的关系和应用策略。国际标准化组织于1991年制定了ISO/IEC 9126-1991标准，给出了6个特性和21个子特性，又于1994年开始对ISO/IEC 9126修订，直到2001年才完成修订工作，现已被两个系列标准 “ISO/IEC 14598 软件工程  产品评价”和“ISO/IEC 9126 软件工程  产品质量”所    取代。

软件质量评价过程  由于评价的出发点不同，可分为3种评价过程：其一，开发者用的过程，计划开发新产品或增强现有产品时为了预测最终产品质量指标；其二，需求方用的过程，计划获取或复用某个已有产品时，为了决定接受产品或者从众多可选产品选择某个产品；其三，评价者用的过程，应开发者、需方或其他机构的请求，对产品进行独立评估，它们通常是第三方机构。不论哪一种评价过程，都是首先要确立评价需求，然后是规定评价、设计评价和执行评价等活动。确立评价需求应确立评价目的，确定产品类型（中间制品、最终产品），规定质量模型；规定评价包括选择度量、建立度量评定等级、确立评估准则；设计评价包括制定评价计划；执行评价包括进行度量、与评估准则相比较，评价结果。

早在20世纪60年代末，已经有人讨论大型软件开发项目的组织管理问题。随着软件工程在实践过程中发生的问题，人们认识到软件产品和软件项目的开发，不完全取决于软件开发方法。与程序的复杂性和系统的复杂性相比，前者已得到较大的缓解，更重要的是后者。如进度推迟、经费超支、质量差、软件人员不称职，均与管理有关。自20世纪80年代初，软件界就关注“软件过程”。1984年10月在美国召开的第一届国际软件过程讨论会，正式提出了“软件过程”的概念。1991年9月美国电气和电子工程师学会（IEEE）的标准化委员会制定了“软件生存周期过程开展”标准。1994年国际标准化组织和国际电工委员会（ISO/IEC）制定了“软件生存周期过程”标准草案，1995年正式公布了“ISO/IEC 12207-1995 信息技术 软件生存周期过程”国际标准。同时，在国际标准化组织中质量管理和质量保证技术委员会（ISO/TC176）制定了ISO 9000簇标准，共有27个标准。其中有一个“ISO 9000-3 质量管理和质量保证——第3部分”，主要针对软件开发、供应、安装和维护中的使用指南，其1997版替代了1993版，内容已大多数和ISO/IEC 12207-1995相吻合，读者可以参考清华大学出版社于1999年出版的《软件企业ISO 9000质量体系的建立和认证》一书。

20世纪80年代中期，IBM在Watts S.Humphrey的指导下，Ron Radice等人将成熟度框架首次应用于软件过程，并由Humphrey于1986年将此成熟度框架带到卡内基·梅隆大学的软件工程研究所（CMU/SEI）。

应美国联邦政府要求，为其提供一个评价软件开发商能力的方法，1986年11月，CMU/SEI在MITRE公司的帮助下开始设计过程成熟度框架，以此帮助软件机构改进他们的软件过程。1987年9月，CMU/SEI发表了一个简短的软件过程成熟度框架。其后在Humphrey的《管理软件过程》一书中进行扩充。书中提出了软件过程评估和软件能力评估，和成熟度问卷，用于评估软件过程成熟度。基于这些设想，由Jim Withey，Mark Paulk和Cynthia Wise在1990年推出了最早的草案。1991年8月Mary Beth Chrissis和Bill Curtis帮助Mark Paulk校订，推出了CMM（成熟度模型）1.1版。

CMU/SEI原先计划在1997年下半年推出2.0版，1998年推出2.1版。但由于种种原因，未能按计划推出2.0版。

由于美国联邦政府的大力推行，CMM模型得到了广泛应用，CMU/SEI于2001年公布了通过CMM评估的软件机构共有964家，并对其作了统计分析。目前CMM本身还在向纵深发展，CMM家族有：

软件能力成熟度模型（SW-CMM）

软件获取能力成熟度模型（SA-CMM）

人员能力成熟度模型（People-CMM）

系统工程能力成熟度模型（SE-CMM）

集成产品开发能力成熟度模型（IPD-CMM）

个体软件过程（PSP）

群组软件过程（TSP）

另外，国际标准化组织为组织软件过程评价标准的制订，成立了“软件过程改进和能力确定（Software Process Improvement and Capability Determine，SPICD）”项目，ISO/IEC JTCI的SC 7分技术委员会于1996年9月正式公布了工作草案，代号为15504，即ISO/IEC TR 15504 Information Technology—Software Process Assessment。

CMM的广泛采纳和成功推广，推动了软件及其他学科的类似模型的开发，从而模型繁衍，导致了过程改善目标和技术的冲突。要求的培训工作有了相当大的增长，部分实践人员在应用各种不同的模型来实现特定的需要时产生了混淆。针对这种情况，美国联邦政府、产业界和CMU/SEI于1998年启动了“能力成熟度模型集成（Capability Maturity Model Integration，CMMI）”项目，于2000年第四季度发布了第一个正式的CMMI，最近的修改是2002年6月10日。CMMI包括了大量的工程改善和过程改善的信息，提供了单一的集成化框架来改善跨越几个学科的机构的工程过程，从而提高机构过程改善的质量和有效性。相信CMMI将会逐步替代CMM。

另外我国也非常重视CMM的研究和应用，目前已经参照CMM1.1版制定国家军标“军用软件成熟度模型”，以及参照CMMI制定行业标准“ST/T11234 软件过程能力评估模型” 和“ST/T 11235软件能力成熟度模型”。

1.4  软 件 测 试

1.4.1  软件测试的重要性

计算机和程序是一对孪生兄弟，自从计算机诞生之日就必须要有程序在其上运行。为了使所编制的程序能在计算机上运行，从而得到问题的正确解，必须对程序的功能性进行测试。所以，软件测试工作是在软件工程诞生之前就客观存在了，一直延用至今，且其测试的内容和技术也有了较大的发展。

无论是ISO 9000的质量体系认证，还是CMU/SEI的CMM认证，其中均涉及到测试，如ISO 9000中共有19个要素，其中一个要素就是“检验和试验”，对于软件来说就是测试；再如CMU/SEI的CMM中共有18个过程关键域，其中有一个质量保证过程关键域，就是对过程的监视和测量。

因此，无论从何种角度讲，软件测试是一个必不可少的活动，是对软件需求分析、设计规约和编码的最终复审；是软件质量保证的关键步骤。软件测试是根据软件开发各阶段的规约和软件的内部结构，精心设计一批测试用例（包括输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现软件中不符合质量特性要求（即缺陷或错误）的过程。目前，许多软件开发机构将研制力量的40%以上投入到软件测试之中，体现了充分重视软件质量要求。众所周知，软件中存在的缺陷甚至是错误，如果遗留到软件交付投入运行之时，终将会暴露出来。但到那时，不仅改正这些缺陷所花的代价更高，而且往往造成恶劣的后果。由此可知软件测试的重要性。

软件测试不等同于程序测试。软件测试应当贯穿软件生存周期全过程。因此，需求描述、需求规约、设计规约、模块设计书以及程序等都应成为软件测试的对象。换句话说，软件测试包括程序测试和各类文档的评审，这就是对软件测试的广义理解。相对的狭义理解就是程序测试，但也不等于程序编好了才进行测试。

在进行软件产品或软件系统开发时，主要有3类人员必须参与，他们是项目经理、开发人员和测试人员。一般来说，大家都会十分重视开发工作，因此在一个项目组中，会有很多的开发人员，而测试人员都比较少。经过多次实践后，才会增加测试人员，如微软公司就是这种情况。目前软件测试人员就比较多了，如Exchange 2000，项目经理23人，开发人员140人，测试人员350人；再如Windows 2000，项目经理250人，开发人员1700人，测试人员3200人，可以看出测试人员和开发人员之比，竟达5∶3。对于我国当前的软件企业来说，软件测试的力度远远不够，随着市场的成熟和企业的发展，必将会极大地投入到测试工作中去，那时测试人员将会十分走俏。

1.4.2  软件测试的目的和原则

基于不同的立场，存在着不同的测试目的。从用户的角度看，一般希望通过软件测试暴露软件中隐藏的缺陷，以此来决定是否可以接受该软件产品和软件系统。从软件开发者的角度看，总是希望通过测试说明软件中不存在缺陷，表明该软件已正确地实现了用户的要求，从而确立用户对该软件的质量信任。由软件管理者角度看，普遍希望花费有限的资源达到该软件用户的质量要求，经费和进度是其首要考虑的焦点。因此，Grenford.J.Myers就软件测试目的提出如下的观点：

q        测试是程序的执行过程，目的在于发现缺陷；

q        一个好的测试用例在于能发现至今未发现的缺陷；

q        一个成功的测试是发现了至今未发现的多个缺陷的测试。

所以，测试的目标是以最少的资源和时间，找出软件中隐藏的各种缺陷甚至错误。测试的成功与否就是以发现软件中潜在的缺陷多少来衡量。

根据这些测试目的和目标，软件测试应该注意些什么呢？郑人杰等人编著的《实用软件工程》^［5］第2版（清华大学出版社，1999年）中有一段描述对此问题进行了回答，现摘录如下：

① 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。

由于原始问题的复杂性，软件的复杂性和抽象性，软件开发各个阶段工作的多样性，以及参加开发各种层次人员之间工作的配合关系等因素，使得开发的每个环节都可能产生错误。所以不应把软件测试仅仅看作是软件开发的一个独立阶段，而应当把它贯穿到软件开发的各个阶段中。坚持在软件开发的各个阶段的技术评审，这样才能在开发过程中尽早发现和预防错误，把出现的错误克服在早期，杜绝某些隐患，提高软件质量。

② 测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。

在做测试以前，应当根据测试的要求选择在测试过程中使用的测试用例。测试用例主要用来检验程序员编制的程序，因此不但需要测试的输入数据，而且需要针对这些输入数据的预期输出结果。如果对测试输入数据没有给出预期的程序输出结果，那么就缺少了检验实测结果的基准，就有可能把一个似是而非的错误结果当成正确结果。

③ 程序员应避免检查自己的程序。

测试工作需要严格的作风，客观的态度和冷静的情绪。人们常常由于各种原因，具有一种不愿否定自己工作的心理，认为揭露自己程序中的问题总不是一件愉快的事，这一心理状态就成为测试自己程序的障碍。另外，程序员对规约理解错误而引入的错误更难发现。如果由别人来测试程序员编写的程序，可能会更客观，更有效，并更容易取得成功。要注意的是，这点不能与程序的排错（debugging，亦译成调试）相混淆。排错由程序员自己来做可能更有效。

④ 在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

合理的输入条件是指能验证程序正确的输入条件，而不合理的输入条件是指异常的、临界的及可能引起问题异变的输入条件。在测试程序时，人们常常倾向于过多地考虑合法的和期望的输入条件，以检查程序是否做了它应该做的事情，而忽视了不合法的和预想不到的输入条件。事实上，软件在投入运行以后，用户的使用往往不遵循事先的约定，使用了一些意外的输入，如用户在键盘上按错了键或输入了非法的命令。如果开发的软件遇到这种情况时不能做出适当的反应，给出相应的信息，那么就容易产生故障，轻则给出错误的结果，重则导致软件失效。因此，软件系统处理非法命令的能力也必须在测试时受到检验。用不合理的输入条件测试程序时，往往比用合理的输入条件进行测试能发现更多的错误。

⑤ 充分注意测试中的群集现象。

测试时不要以为找到了几个错误问题就已解决，不需继续测试了。经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目或检错率成正比。根据这个规律，应当对错误群集的程序段进行重点测试，以提高测试投资的效益。

在所测程序段中，若发现错误数目多，则残存错误数目也比较多。这种错误群集性现象，已为许多程序的测试实践所证实。例如美国IBM公司的OS/370操作系统，47%的错误仅与该系统的4%的程序模块有关。这种现象对测试很有用。如果发现某一程序模块似乎比其他程序模块有更多的错误倾向时，则应当花费较多的时间和代价测试这个程序模块。

⑥ 严格执行测试计划，排除测试的随意性。

测试计划应包括：所测试软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方式和过程，系统组装方式，跟踪规程，排错规程，回归测试的规定以及评价标准等（下面还会作介绍）。

对于测试计划，要明确规定，不要随意解释。

⑦ 应当对每一个测试结果做全面检查。

这是一条最明显的原则，但常常被忽视。有些错误的征兆在输出实测结果时已经明显地出现了，但是如果不仔细全面地检查测试结果，就会使这些缺陷或错误被遗漏掉。所以必须对预期的输出结果明确定义，对实测的结果仔细分析检查，抓住症候，暴露错误。

⑧ 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

1.4.3  软件测试过程

软件测试过程可以在两个不同的层次上分析，在低层次上，软件测试过程是一个不断地运行一个程序段，不断地输入数据，观察和记录程序的运行行为和输出的结果，并判断其行为和输出结果的正确性，直到能够由这些结果有效地分析该程序段的特性的过程。

为了高效地执行这一过程，往往需要书写一段程序来调用被测试的程序段，向被测试程序段输送测试数据，打印、显示或记录该程序段运行的行为。这样一段程序被称之为该测试的驱动程序。同样亦往往需要编写另一段程序来为被测试的程序段提供数据（在正式交付用户运行时，这些数据可能是由其他程序段被调用后运行的结果，也可能是由其他程序段直接提供）。这样一段程序称之为该测试的桩基模块（stub）。对程序动态运行行为的观察和记录，只限于该程序段测试的输出结果是不够的，有时需要对程序段的执行路径以及在路径上的一些关键点的中间结果进行记录和分析。为了有效地记录该测试的动态行为，需要在该程序段中插入一些程序代码，这样的代码称为软件测试监视代码。

软件测试过程还可以在一个更高的层次上来进行分析。软件测试过程可以看成不断地进行测试、排错、修改程序和文档，然后再进行测试（回归测试），直到软件达到用户质量特性要求的一个循环往复的过程。

一个成功的测试包括两个主要方面：其一是被测试的程序段在足够多的测试数据上是正确的。注意，并不是指被测试的程序段是正确的，它可能发现存在隐含的缺陷，也可能在某些测试数据上未发现缺陷，只说明在这种情况下，被测试的程序段是正确的。其二是测试数据是充分的，即该程序段在测试数据上的动态行为能够充分反映质量特性的总体  表现。

1.4.4  软件测试与相关的几个概念

软件测试不仅仅是软件质量保证体系中的重要一环，而且也是保证质量的重要技术手段，在前面已讨论了它们之间的关系。除此之外，还有几个概念需要进一步说明。

（1）排错（debugging）是查找、分析和纠正错误的过程。而测试（testing）是由人工或自动方法来执行或评价软件系统或软件子系统的过程，以验证是否满足规定的需求，或识别出期望的结果和实际结果之间有无差别。因此，测试的任务是尽可能多地发现软件中的缺陷和错误，而排错的任务是进一步诊断和改正程序中潜在的缺陷和错误。一般来说，排错有两类活动：其一是确定程序中可疑缺陷或错误的确切性质和位置；其二，是对程序（设计、编码）进行修改，从而排除这个潜在的缺陷或错误。

（2）验证（verification）有3个含义：

其一，确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的需求的过程；

其二，程序正确性的形式证明，即采用形式理论证明程序符合设计规约规定的过程；

其三，评审、审查、测试、检查、审计等各类活动，或对某些项处理、服务或文件等是否和规定的需求相一致进行判断和提出报告。

（3）确认（validation）是在软件开发过程结束时，对软件进行评价，以确认它和软件需求是否相一致的过程，其目的是想证实在一个给定的外部环境中软件的正确性。确认一般包括需求规约的确认和程序的确认，而程序的确认又分静态确认和动态确认。静态确认不在计算机上实际执行程序，通过人工分析或者程序正确性证明来证实程序的正确性。动态确认主要通过动态执行程序作分析，或者测试程序来检查其动态行为，以证实程序是否存在问题，这通常就叫确认测试。

由此，可以把验证与确认看成是软件测试的一部分工作。

1.5  软件测试方法分类

软件测试无论技术还是应用都处在发展中，所以软件测试的内容、工具，甚至关于软件测试的名词术语也都在不断扩大中。而这些软件测试的内容、工具和名词术语，都代表着软件测试的某个方面，有其特定的含义。为了比较正确地理解其含义和比较正确地将其定位，应该从宏观角度对软件测试加以分类。

软件测试有各种分类方法，按照不同的分类原则有不同的分类结果。软件测试的分类原则可以有以下几种：

q        按照软件测试的动、静态分类；

q        按照软件层面分类；

q        按照软件开发过程的内、外分类；

q        按照测试用例所依据的信息来源分类；

q        按照判断测试的充分性分类；

q        按照软件测试的完整性分类。

（1）按照软件测试的动、静态来分，有静态测试和动态测试。

在软件开发过程中，每产生一个文档，或每一个活动结束时产生的文档，都必须对文档进行测试，静态测试通过了，则该过程或活动才算结束，开发工作取得了进展，可以进入下一个阶段或活动，对这种静态测试亦叫做评审。

动态测试就是通过运行程序来检验程序的动态行为和运行结果的正确性。运行程序并非动态测试的目的，通过运行来检验程序是否正确才是动态测试的目的。动态测试必须具备测试用例，有时还需要具备驱动程序、桩模块和测试监视代码。

（2）按照软件层面来分，美国国家宇航局建议将软件评审的内容分两个层面来进行，即技术评审和管理评审。

① 技术评审的任务

q        建立软件配置管理基线；

q        提出并解决技术问题，审查技术工作；

q        评价项目的状态，判明有关技术问题的近期、长期风险，并加以讨论；

q        在技术代表的权限内，达成已判明风险的转移策略；

q        标识呈交给管理人员讨论的风险要素和有关问题；

q        确保用户和软件开发技术人员之间的交流通畅。

② 管理评审的任务

q        报告上级管理部门该项目的状态、所采取的方针、所达成的技术协议，以及软件产品进展的总体情况；

q        解决技术评审不能解决的问题；

q        就技术评审不能解决的近期、长期风险可达成的转移战略；

q        鉴别并解决管理方面的问题以及技术评审没有提出的风险；

q        征得用户的同意和各方认可以便及时完成。

（3）按照软件开发过程的内、外进行分类。

① 软件开发过程中的测试。按软件开发过程中所处的阶段（或活动）及其作用来    分，有

q        单元测试

q        集成测试

q        系统测试

q        验收测试

软件开发过程中的测试，大部分是开发单位自行完成的。当然，也可交第三方软件测试机构执行，但往往是系统测试和验收测试。有时，这种测试，因为不是由用户进行的，又称α测试。

出现在软件开发过程中各个阶段（或活动）的还有“回归测试”。只要对软件的代码有修改，不论是修改错误还是增加功能或提高性能，原则上都要进行回归测试，以保证对代码修改的正确性，并不会对其他部分带来负面影响。

② 软件产品测试。其测试对象是产品化或正在产品化的软件。这种测试的内容包含范围很广，通常由第三方软件测试机构执行。

A．通常的软件产品测试：

q        功能测试

q        性能测试

q        β测试（用户测试）

q        Benchmark测试

B．专门的软件产品测试：

q        可靠性测试

q        标准符合性测试

q        互操作性测试

q        安全性测试

q        强度测试

（4）按照测试用例所依据的信息来源，测试方法可以分为如下几种。

① 以程序为基础的测试。通过对程序的分析形成测试用例，并以程序被执行的程度来判断测试是否充分，这就是“白盒法”。

② 以需求规约和需求描述为基础的测试。通过分析软件的需求描述和需求规约形成测试用例，并根据需求描述和需求规约所规定的功能和性能是否得到了充分的检验来判断测试是否充分。这就是“黑盒法”。

③ 程序和需求相结合的测试。综合考虑需求和实现形成测试用例。

④ 以接口为基础的测试，仅仅依靠软件与其运行环境之间的接口形成测试用例，随机测试就是一种以接口为基础的测试方法。

（5）按照判断测试的充分性，测试方法可以分为如下几种。

① 结构性测试，旨在充分覆盖程序结构，并以程序中的某类成分是否都已得到测试为依据，来判断测试的充分性，如语句覆盖是一种结构性测试。

② 排错性测试，旨在排除程序中潜在缺陷的可能性，并根据测试用例集成排除软件潜在缺陷可能性的能力判断测试的充分性。

③ 分域测试，通过对软件的需求和实现进行分析，将软件的输入空间划分成一系列子空间，然后在每一个子空间内选择一个或多个测试数据。

④ 功能测试，根据软件所需的功能和所实现的功能，形成测试用例，分析测试的充   分性。

（6）按照软件测试的完整性，Shooman 从程序结构和测试覆盖程度分为如下几种。

① 完全性和连续性测试

要求程序中的所有指令至少执行一次（100%的语句覆盖）

② 图路径测试

所有图路径至少执行一次（100%的图路径覆盖）

③ 程序路径测试

所有程序路径至少执行一次（100%的程序路径覆盖）

④ 穷举测试

对输入参数的所有值执行所有程序路径，或对输入参数的所有值和所有输入序列，以及初始条件的所有组合，执行所有程序路径。

以上这6种软件测试的分类方法，从不同的技术角度对软件测试进行分类。实际上，它们之间有很多交互和相关之处。例如，同一测试技术可以融在不同类的相关测试阶段之中。在本书中，主要依据软件开发过程的内、外分类方法安排章节目录。

1.6  软件错误的分级

在软件产品开发中，不论哪一阶段产生的缺陷和错误，其最后的表现就是：软件产品达不到用户的要求，由于存在软件错误，使之不能有效地完成规定的任务。

软件测试的任务，就在于找出或发现软件中存在的错误（假如错误存在的话）。由于错误的性质不同，危害性也不同。软件测试如果能发现软件中危害性大的错误（如果存在的话），那么该软件测试的价值就越高。一般将软件错误分为5级。

q        第1级错误

不能完全满足软件需求，基本功能未完全实现，危及人员或设备安全的错误。

q        第2级错误

不利于完全满足软件需求或基本功能的实现，并且不存在可以变通的解决办法（重新装入或重新启动该软件不属于变通解决办法）。

q        第3级错误

不利于完全满足软件需求或基本功能的实现，但却存在合理的、可以变通的解决办法（重新装入或重新启动该软件不属于变通解决办法）。

q        第4级错误

不影响完全满足软件需求或基本功能的实现，但有不便于操作员操作的错误。

q        第5级错误

不属于第1~4级错误的其他错误。