软件测试的分类：深入探讨

软件测试有着各式各样的说法，关于软件测试的分类框架，普渡大学的Aditya P.Mathur教授在文献[2]中分别从测试设计的依据、测试所在的生命周期、测试活动的目标、被测软件制品特点以及测试过程模型5个方面对软件测试的类型进行了归纳与分类。

2.1.1.1　测试设计的依据

根据测试设计的依据，软件测试的类型有黑盒测试、白盒测试、基于模型或规范的测试、接口测试。

（1）黑盒测试（Black-Box Testing）[3]把程序看作一个不能打开的黑盒子，不考虑程序内部逻辑结构和内部特性的情况下，测试程序的功能。测试要在软件的接口处进行，它只检查程序功能是否按照规格说明书的规定正常使用，程序是否能接收输入数据而产生正确的输出信息，以及性能是否满足用户的需求，并且保持数据库或外部信息的完整性。通过测试来检测每个功能是否都能正常运行，因此黑盒测试又可称为从用户观点和需求出发的测试。

（2）白盒测试（White-Box Testing）[3]是指在测试活动中基于源代码进行测试的用例设计和评价。一般包含静态测试和动态测试，其中静态测试通过人工的模拟技术对软件进行分析和测试，不要求程序实际执行；动态测试是指输入一组预先按照一定测试准则设计的实例数据驱动运行程序，检查程序功能是否符合设计要求，发现程序中错误的过程。

（3）基于模型或规范的测试[2]是指对软件行为进行建模以及根据软件的形式化模型设计测试的活动，在测试过程中需要首先对需求进行形式化定义。

（4）接口测试（Interface-Testing）[3]的目的是测试系统相关联的外部接口，测试的重点是要检查数据的交换以及传递和控制管理过程。

2.1.1.2　测试所在的生命周期

根据测试所在的生命周期，软件测试的类型有单元测试、集成测试、系统测试、回归测试以及非正式验收测试，本书主要介绍非正式验收测试。

非正式验收测试过程分为Alpha测试和Beta测试[3]。其中Alpha测试是用户在开发环境下所进行的测试，或者是内部开发的人员在模拟实际环境下进行的测试。Alpha测试没有正式验收测试那样严格，在Alpha测试中，主要是对用户使用的功能和用户运行任务进行确认，测试的内容由用户需求说明书决定。进行Beta测试时，各测试员应负责创建自己的测试环境，选择数据，决定要研究的功能、特性和任务，并负责确定自己对于系统当前状态的接受标准。

2.1.1.3　测试活动的目标

针对特定的目标，软件测试可以分为：功能测试、性能测试、压力测试、安全保密测试、可靠性测试、容错性测试、鲁棒性测试、GUI测试、操作测试、入侵测试、验收测试、兼容性测试、一致性测试、外设配置测试、外国语言测试等。

（1）功能测试用于考察软件对功能需求完成的情况，应该设计测试用例使需求规定的每一个软件功能得到执行和确认。

（2）性能测试检验软件用于考察是否达到需求规格说明中规定的各类性能指标，并满足一些与性能相关的约束和限制条件。

（3）压力测试[3]即强度测试，是指模拟巨大的工作负荷来测试应用程序在峰值情况下如何执行操作。在实际的软硬件环境下，压力测试主要是以软件响应速度为测试目标，尤其针对在较短时间内大量并发用户访问时软件的抗压能力。

（4）容错性测试包括两个方面：一方面是输入异常数据或进行异常操作，以检验系统的保护性，如果系统的容错性好，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃；另一方面是灾难恢复性测试，通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复。

2.1.1.4　被测软件制品特点

针对不同被测软件制品而进行的特定软件测试分类，例如：针对应用程序组件的组件测试；针对客户/服务器的C/S测试；针对编译器的编译器测试；针对设计的设计测试；针对编码的编码测试；针对数据库系统的事务流测试；针对面向对象软件的OO测试；针对操作系统的OO测试；针对实时软件的实时测试；针对需求的需求测试；针对Web的Web服务测试。

2.1.1.5　测试过程模型(www.xing528.com)

1.常用测试过程模型

目前存在着各种测试模型，所谓测试模型是软件开发全部过程、活动和任务的结构框架，是把多种测试方式集成到软件的生命周期中的一个完整过程。常用的测试过程模型有：瀑布测试模型、V测试模型、快速原型模型、螺旋测试以及敏捷测试等。

（1）瀑布测试模型（Waterfall Model）。1970年由W·Royce提出，该模型给出了固定的顺序：对需求规格说明、设计、编码与单元测试、集成与子系统测试、系统测试、验收测试、培训和交付、维护等生存期活动，从上一个阶段向下一个阶段逐级过渡，如同流水下泻，最终得到所开发的软件产品，投入使用。在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。

图2-1　V测试模型

（2）V测试模型（V Model）。该测试模型是软件开发瀑布测试模型的变种，它反映了测试活动与分析和设计的关系，如图2-1所示，从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系，左边依次下降的是开发过程各阶段，与此相对应的是右边依次上升的部分，即各测试过程的各个阶段。

V测试模型是在快速应用开发（Rapid Application Development，RAD）模型基础上演变而来，由于将整个开发过程构造成一个V字形而得名。V测试模型强调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软件质量情况下缩短开发周期。

（3）快速原型模型（Rapid Prototype Model）。快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求。第二步则在第一步的基础上开发客户满意的软件产品。

（4）螺旋测试模型（Spiral Model）。1988年，Barry Boehm正式发表了软件系统开发的螺旋测试模型，将瀑布测试模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，螺旋测试模型采用一种周期性的方法来进行系统开发，以进化的开发方式为中心，在每个项目阶段使用瀑布模型法，这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次。在最后阶段测试，人员关注的是系统测试和验收测试。

（5）敏捷测试（Agile testing）。敏捷测试强调从客户的角度来测试系统，重点关注持续迭代的测试新开发的功能，而不再强调传统测试过程中严格的测试阶段，尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。

2.常用测试模型的特点

以上几种常用测试模型的主要特点如下：

（1）瀑布测试模型由于开发的模型为线性，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险，早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

（2）V测试模型使用户能清楚地看到质量保证活动和项目同时展开，项目一启动，软件测试的工作也就启动了，避免了瀑布模型所带来的误区——软件测试是在代码完成之后进行。V测试模型具有面向客户、效率高、质量预防意识等特点，能帮助我们建立一套更有效的、更具有可操作性的软件开发过程。

（3）快速原型模型可以克服瀑布测试模型的缺点，减少由于软件需求不明确带来的开发风险。快速原型模型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，比起原型系统的内部结构，更重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。

（4）采用螺旋测试模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失，另外，过多的迭代次数会增加开发成本，延迟提交时间。

（5）敏捷测试是一个持续的质量反馈过程，测试中发现的问题要及时反馈给产品经理和开发人员，测试人员不仅要全程参与需求、产品功能设计等讨论，而且要面对面地、充分地讨论并参与代码复审。

瀑布测试模型由于其滞后的测试响应，一般不太常用，快速原型模型、螺旋测试模型。敏捷测试可以将测试反映的问题或者用户的需求迅速地反映到软件开发中，目前在软件开发中比较常用，一般在软件开发商的内部质量控制中使用。V测试模型由于其质量保证活动和项目开发活动同时展开，不仅可以应用到软件开发商的内部质量控制，同时也可以提供给软件使用者实现外部质量控制，因此非常适合配电自动化系统这样的大型软件系统的质量保证过程。