【1+X】软件测试流程和过程模型

想看更多内容请移步专栏

转载：【1+X】软件测试技术 - 软件测试流程和过程模型 - 蓝桥云课 (lanqiao.cn)

软件测试流程和过程模型

知识点

• 软件测试流程
• V 模型
• W 模型
• H 模型

简介

软件工程由多个环节组成，每个环节都需要软件测试人员参与，有些环节虽然不是软件测试人员主要工作体现的地方，但却是不可或缺的重要组成部分。相应的，软件测试也由多个环节组成。本章将整体介绍软件测试的各流程环节，以及软件测试人员在这些环节中所需要执行的大体工作内容以及需要输出的工作成果。

为了读者能了解软件测试与软件开发在每个环节中的密切结合，本章还将介绍几个传统的软件测试过程模型。通过软件测试的流程和软件测试过程模型，可以很好的指导读者以后的软件测试工作。

软件测试流程

软件测试是伴随着项目的立项而开始的，也就是说，软件项目一旦确立，软件测试工作也就开始了，那么软件测试到底是如何贯穿到整个软件工程中的呢？

按照尽早进行测试的原则，应该在软件项目中尽早开展软件测试工作，就软件测试过程本身而言，应该包含以下几个阶段。

• 测试需求分析
• 测试计划制定
• 测试用例设计
• 测试环境搭建
• 测试数据准备
• 测试执行及缺陷处理
• 测试总结报告
• 测试文件归档

接下来就一起来看看测试人员在这几个阶段的主要工作内容。

软件需求分析

软件需求分析是软件测试流程中的基础一环，用来明确软件测试对象以及测试范围，并作为测试覆盖的基础。其目的是确保所有风险承担者尽早地对项目功能达成共识并对将来的产品有个相同而清晰的认识。

本阶段主要由需求人员统一收集需求，并整理成文档格式转发给 PM（Project Manager 项目经理或者 Product Manager 产品经理）、开发经理和测试经理。然后 PM 召集开发经理、测试经理和需求分析人员进行会议讨论，了解具体每个需求的实际含义，并明确各个需求的有效性、可用性和可测性；然后确定最终实现的需求和功能点，并整理出重点需求。接着 PM 会根据会议讨论结果编写需求说明，并且再次召集各职能小组人员参与开会讨论，对需求说明进行修复、完善、并最终确定《需求规格说明书》。《需求规格说明书》决定了项目以后所有工作的基调。

这个阶段的主要负责人是 PM，PM 有时候是指项目经理，有时候是指产品经理。这是因为每个公司的组织方式可能不同，有的公司采取项目式组织架构，那么负责人应该是项目经理；有些公司采取职能式组织架构，那么负责人应该是产品经理，正巧他们的英文都可以缩写为 PM。同学们要根据实际情况灵活地去理解它的含义。

软件测试人员在本环节中的主要作用是参与需求评审，通过提出评审意见的方式对需求进一步矫正，并为下一个环节（制定测试计划）中工作量的评估打下基础。

本阶段的输入文档主要是需求说明相关文档，输出文档是《需求规格说明书》。

软件测试计划制定

了解了软件的需求之后，软件测试人员会讨论开发这个版本的目的是什么、要包括什么功能、功能的范围是什么样的、有哪些可以参考的文档、用什么测试策略和工具来执行软件测试工作，然后快速地进行风险分析，并据此制定风险应对方案，还要确定测试资源，还需要确立几个里程碑事件……这看起来就是一个测试计划分析的过程，而最终形成的文档就是《软件测试计划》

软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试范围、测试配置、测试进度、测试资源、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是软件测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制软件测试进度，应对软件测试过程中的各种变更。

如何编写软件测试计划，这部分内容会在《软件测试计划》中详细讲解。

本阶段主要负责人是测试经理，但软件测试员会参与软件测试计划中与本人相关部分的内容制定。

本阶段输入文档是《需求规格说明书》和《项目开发计划》，输出文档是《软件测试计划》。

软件测试用例设计

软件测试用例是指导软件测试工作的一种文档，它是通过使用在软件测试计划中确定的测试技术，对于已确定的软件测试需求进行逐步推敲而设计出来的。

软件测试用例设计完成，要进行综合评审，通过评审可以弥补软件需求中遗漏的一些因果关系和异常案例，可以改善测试分析和设计的过程。类似地，软件测试工作的其它产出文档，如软件测试计划、软件风险分析应该进行评审。

关于软件测试用例的介绍，比如定义、作用、设计过程等，会在《软件测试用例概述》中详细讲解。

而软件测试用例的黑盒设计方法，会在《高效设计测试用例》中详细讲解。

本阶段的主要负责人是测试经理和测试工程师，但需要注意的是，在很多公司测试经理不光要做管理和任务分配工作，也会负担重要功能部分的实际设计和评审工作。

本阶段的输入文档是《软件需求规格说明书》、《软件测试计划》、《软件设计文档》（包括《软件概要设计文档》和《软件详细设计文档》），输出文档是《软件测试用例》。

软件测试环境搭建

要顺利执行测试，首先要确定正确地搭建了软件测试环境。

软件测试环境是指为了完成软件测试工作所必须的计算机硬件、软件、网络设备、历史数据的总称。

测试环境的搭建是一项非常重要的工作，同时也可能是一项很耗时的工作。有些软件的测试环境要求比较复杂，需要在测试执行之前做好充分的准备。如果正在测试的是第一个版本，搭建测试环境就尤为重要了，需要从头做起。

有些项目也曾尝试在开发环境下做测试，但效果并不好。开发环境主要是方便程序员调试程序存在的，而测试环境则比较接近于生产环境，如果在测试环境上测试结果不能通过，那么是肯定不能部署到生产环境给用户或客户使用的。

就像程序员有用于他们调试的环境一样，测试人员也需要有对测试环境的独立访问和控制权，以保证一些私有的测试数据不会被其他人用到，这样可以提高他们的工作效率。测试环境适合与否会严重影响测试结果的真实性和正确性。

通常在搭建测试环境的时候，开发人员会提供安装指导书，否则也可以在搭建测试环境遇到问题的时候要求开发人员协助。通常，测试环境会有专人来负责。

在大数据系统的测试过程中，测试环境和数据的准备是测试过程中的重点。

大数据系统由于其自身的特点（数据规模大、数据多样、计算复杂度高、分布式结构等）使得对它的测试与传统软件测试有所不同，包括需要使用大数据测试工具、测试环境和数据的准备等，对测试人员提出了更高的专业要求。

大数据系统通常是分布式架构，测试环境复杂。接下来我们重点讲述大数据测试环境搭建时需要考虑的问题。搭建大数据测试，需要我们考虑以下几点：

• 环境是否具有分布式节点和分布式数据存储的集群；
• 环境是否有足够的空间来存储和处理大规模数据；
• 另外如果是做大数据系统的性能测试的话，还要考虑影响大数据系统性能的一些因素----网络环境、应用、虚拟化、数据质量等，所以还应考虑部署合适的监控系统，监控整个集群机器、服务、计算、存储、任务等层面的指标。

而根据对大数据所测场景不同，所需要的测试环境也有所不同，但测试环境的软硬件配置、软件模块的版本应与生产环境一致。

• 如果是在大数据新业务上线前对系统功能做验证测试，通常需要构造单独的类生产的迷你测试环境；
• 如果是测试实时数据处理业务或是做系统组件的升级测试，则可以按照系统生产环境进行等比例缩放；
• 如果是测试重要业务功能或是做系统的性能测试，则需要直接在生产环境上进行测试。

测试数据准备

目前很多互联网软件应用，后台都会有数据库做支撑，那就需要在测试的时候准备相应的测试数据，准备测试数据是软件测试工作的一项必备工作。如何快速地创建测试数据，也是测试工程师的重要能力之一。

创建测试数据的过程，往往需要很长的时间，传统的创建测试数据的方法分为手动创建和自动化创建两种方法。

手动创建测试数据:

• 手动模拟用户的实际操作来创建重要业务流程的测试数据；
• 通过 SQL 语句中 where 查询条件和 update 方法来创建符合条件的测试数据；
• 导入本地机器上存储的一些符合条件的测试数据；
• 导入并加工线上数据变成测试数据。

自动化创建测试数据：

• 使用自动化工具创建：Data Generator、Databene Benerator、Testgen、Datatect、Turbo Data；
• 这几个工具可以为所有类型带的输入域和边界条件生成测试数据，可以生成普通文件或直接向数据库表插入不同类型的数据，比如名字、地址等；
• 使用自建脚本创建：Ruby、Python、Fit、FitNesse、Shell。

实际工作中，可以结合手工方式和自动化方式，灵活运用多种方法去创建不同测试阶段需要的测试数据。另外，也可以在平时就保存一些常用的测试数据。但随着时间的推移，测试数据也会过时。就算是从实际的生产过程中得到的数据，如果时间太久，也不再能精确的代表当前的生产数据了。一个使用了无效数据而“测试通过”的测试场景是没有说服力的。所以测试数据也需要经常更新。

大数据系统所处理的数据具有大规模（Volume）、类型多样（Variety）、产生速度快（Velocity）、商业价值高（Value）、数据准确和可信赖（Veracity）等特点，所以数据获取方式也与传统项目的数据获取方式有所不同。

常见的大数据测试数据获取方式：

• 通过网络爬虫来“爬取”免费的网络数据；
• 向一些数据机构购买有价值的数据；
• 共享合作公司提供的数据；
• 使用自己公司的自有数据。

获取自有数据当然更好，因为数据准确、实时、高效。根据使用场景的不同，测试数据可以直接使用真实数据，也可以按照某种算法构造。

• 真实数据引流。

  就是直接把生产环境下的流量直接分流到测试系统。这种场景一般用于“强业务”场景测试，比如实时推荐这样的场景，考虑到数据的多样性和数据的非随机性，“强业务”场景一般不采用构造数据，通常采用生产引流的方法。

• 生产环境数据复制。

  生产环境数据引流可能会影响到线上的业务系统，因此可以采取一个折中的方法，就是在业务使用流量比较少的时候，通过旁路从线上生产环境复制部分或全部数据流量。这样对生产环境的影响比较小。

• 构造数据。

  就是以实际业务场景的数据作为基础，基于历史数据的特征，通过算法来生成和模拟数据。构造数据通常使用基准数据集或人工构造的方法。大数据系统中的组件测试通常采用构造的数据。例如 Hive 或 Spark SQL 功能与性能的测试，或者 Spark Streaming 和 Flink 的功能与性能测试。

拿到数据之后，我们要对数据进行预处理。数据预处理是一种数据挖掘技术，本质就是为了把原始数据转换为可以理解的格式或者符合我们挖掘的格式。为什么要进行预处理呢？因为直接获取的数据通常质量比较低，主要表现为这些现象：

• 数据可能是不完整的，缺少某些属性值；
• 高维度，所谓的高维度是指数据的属性或字段太多；
• 数据可能存在重复；
• 数据可能会由于包含代码或者名称的差异导致跟实际需要的数据不一致；
• 可能含噪声，所谓的含噪声就是指数据中存在着错误或异常数据。

数据预处理就是解决上面所提到的数据问题的可靠方法。首先要进行数据清洗，数据清洗完成之后接着进行或者同时进行数据集成、转换、归一化等一系列处理，这个过程就是数据预处理。一方面是提高数据的质量，另一方面可以让数据更好的适应特定的项目环境。

测试执行及缺陷处理

提交了测试对象并且测试对象满足了测试执行的进入准则后（测试的进入准则会在《软件测试计划》中详细讲述，就是满足了一定的条件，才能开始执行测试），可以开始测试执行。

测试执行是指按照之前设计好的测试用例，按照里面的步骤一步一步的执行，查看预期结果与实际结果是否一致的过程。

测试的执行只能有 2 种结果：Pass 或者 Fail。测试不通过的话，测试人员就应该把发现的问题及时记录下来，报告给开发人员做出相应的修改。缺陷记录是测试人员工作的具体表现形式，是测试人员与开发人员沟通的基础。因此，如何录入一个高质量的缺陷报告，是每个测试人员都要重视的问题。

测试工程师对于那些已经被开发人员修复的缺陷，需要做回归测试以验证其是否得到正确修复，确认已经被修复的，就将缺陷关闭，否则重新提交给开发人员进行修复。对于缺陷的处理可以使用缺陷管理工具。

关于缺陷以及缺陷的处理，会在《软件测试用例》中详细讲解。

本阶段的负责人是测试经理。测试经理需要跟踪每个项目的实际测试情况，并对难以处理的情况做出决定。本阶段，测试工程师的工作是执行具体的测试工作、提交缺陷、回归缺陷。

本环节输入文档是《需求规格说明书》《测试计划》《软件设计文档》《测试用例文档》以及《测试数据》。输出文档是《软件缺陷报告》。

测试总结和报告

软件测试进行到一定程度就要进行测试评估了。测试评估可以在软件测试过程中阶段性进行，也可以是测试整体结束后进行。通过测试评估生成的软件测试报告（又叫测试评估报告）来确定测试是否达到了出口准则。

测试报告是一个展示测试人员工作过程的机会。软件缺陷列表和软件测试用例都太细了，而且篇幅比较大，专业性又强，很多人对其不感兴趣，但是测试报告却是很多人都会看的一份文档。所以，学会写软件测试报告会帮助你更好的在工作中找到自己的价值。

测试报告要介绍项目的基本信息，展示软件的遗留问题，回顾整个测试过程，同时得出测试结论，并在最后提出自己建设性的意见，然后用 PDCA 循环来进行过程改进。完成软件测试报告之后要进行评审，以确定软件测试是否确定要结束。

如何进行测试评估以及如何编写一份完整的软件测试报告，这部分内容会在《软件测试报告》中详细讲解。

本阶段的主要负责人是测试经理，测试报告一般由他来完成。但测试执行人员会提供自己所负责模块的测试情况给测试经理以帮助完成这份文档。

本阶段的输入文档是《需求规格说明书》《测试计划》《设计文档》《测试用例》《软件缺陷报告》。输出文档是《软件测试总结报告》。

测试文件归档

软件测试到此是否就结束了呢？还有最后一个环节，那就是测试文件的归档。测试文件归档是在测试验收结束，宣布测试有效及结束测试后，对整个过程中涉及到的各种标准文档进行归档、存档。可以使用文档管理工具来完成此项工作。如 Ftp、SVN、Git、VSS、Wiki 等。

软件测试的过程，其实是一个完整的 PDCA 循环。测试不应该在执行完软件测试后就戛然而止，应该使用这次测试总结出来的经验和教训指导下一次测试的设计和执行。软件测试中到处都体现着 PDCA 循环的精神。

• 大的测试流程中，制定好测试计划、执行测试、通过测试结果来检查测试计划制定的合理性，然后分析计划偏离的原因，再把总结出来的经验用于指导下一次测试的计划，这样就形成了一个 PDCA 循环过程。

• 提交一个缺陷也可以应用 PDCA 循环，先写下来，再检查，然后提交审核，对提出的意见进行分析，总结写的不好的地方，把总结的经验用于指导下一次报告的编写，这样的过程同样是一个 PDCA。

• 编写测试用例也是一个 PDCA，选择好测试用例的编写方法，开始设计测试用例，然后通过评审来发现更多问题，或者通过执行测试用例来发现 bug，再根据执行的情况和 bug 的情况来分析测试用例的有效性，把这些总结出来的经验用于指导下一次的测试用例设计。这也是一个 PDCA 循环。

测试工作就像进行一场战争，敌人不是开发人员，而是可恶的、狡猾的、隐蔽的 bug。测试人员应该与开发人员成为亲密的战友，共同对万恶的 bug 展开一场轰轰烈烈的歼灭战，并且最好能把它们消灭在产生的源头。

软件测试过程模型

软件开发过程模型:

也叫软件开发生命周期模型,是指软件开发全部过程、活动和任务的结构框架。是无数前辈们通过无数项目总结出来的软件开发的全过程，从而沉淀下来的固有模型，是前人的智慧结晶。

在软件开发几十年的实践过程中，人们总结了很多的开发模型，比如大爆炸模型、边写边改模型、瀑布模型、原型模型、增量模型、渐进模型、RAD 模型以及近些年互联网很流行的敏捷开发模型 Scrum 等。这些模型对于软件开发过程具有很好的指导作用。但是，遗憾的是，这些过程模型中并没有对测试的作用予以重视，所以无法利用这些模型更好的指导软件测试的实际工作。

软件测试贯穿软件工程的始终，是与软件开发紧密相关的一系列有计划的系统性的活动，显然软件测试也需要模型去指导实践，非常可喜的是软件测试专家通过测试实践总结出了很多很好的测试模型。例如 V 模型、W 模型、H 模型。由于测试和开发的结合非常紧密，在这些测试模型中也都把开发过程进行了很好的总结，体现了测试与开发的融合，下面对这几种模型做一些简单的介绍。

V 模型

V 模型是最具有代表意义的测试模型。V 模型在英国国家计算机中心文献中发布，旨在改进软件开发的效率和效果。V 模型最早由 Paul Rook 在 20 世纪 80 年代后期提出。

V 模型是软件开发瀑布模型的变种，在瀑布模型中，人们通常把测试过程作为在需求分析、概要设计、详细设计和编码之后的一个阶段，尽管有时测试工作会占用整个项目周期一半的时间，但是有人仍然认为测试只是一个收尾的工作，而不是主要的过程。V 模型的推出就是对此认识的改进。

V 模型的优点： 反映了测试活动与分析、设计、开发的关系，从左到右，描述了基本的开发过程和测试行为，非常明确地表明了测试过程中存在不同的测试级别，并且清楚地描述了这些测试阶段和开发过程各阶段的对应关系。

典型的 V 模型一般都有四种测试级别，分别与四种开发级别相对应。实际上，V 模型的测试级别可能会比上面提到的 4 种多，也可能少，或者有不同的测试级别，这取决于不同的项目和软件产品。比如，在组件测试后，可能有组件集成测试，在系统测试后有系统集成测试。在上图，这四种测试级别是：

• 单元测试（component/unit testing）
• 集成测试（integration testing ）
• 系统测试（system testing ）
• 验收测试（acceptance testing ）

这四种测试级别在《软件测试概述》中也有详细介绍。V 模型的软件测试策略既包括底层测试又包括了高层测试，底层测试是为了保证源代码的正确性，高层测试是为了使整个系统满足用户的需求。

V 模型的局限性： 它把测试过程作为需求分析、概要设计、详细设计及编码之后的一个阶段，容易使人认为测试是软件开发过程的最后一个阶段，以及软件测试的对象仅限于程序，有可能需求分析阶段隐藏的问题会一直拖到后期的验收测试才被发现。

W 模型

V 模型的局限性在于没有明确地说明早期的测试，不能体现“尽早地和不断地进行软件测试”的原则。在 V 模型中增加软件开发各阶段应同步进行的测试，就演化成了 W 模型，W 模型又叫双 v 模型，因为实际上开发是“V”，测试也是与此并行的“V”。W 模型是由 Evolutif 公司提出的，如下图所示。

相对于 V 模型，W 模型更科学。

W 模型的优点： 它强调软件测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，还包括需求、设计以及开发输出的文档。

这样，只要相应的开发活动完成，我们就可以开始执行测试，可以说，测试和开发是同步进行的，测试人员尽早参与项目，才有利于尽早地发现问题。以需求为例，需求分析一完成，我们就可以对需求进行测试，而不是等到最后才开始针对需求进行验收测试。

根据 W 模型的要求，一旦有文档提供，就要及时确定测试条件，以及编写测试用例。当需求被提交后，就需要确定高级别的测试用例来测试这些需求。当概要设计编写完成后，就需要确定测试条件来查找该阶段的设计缺陷。W 模型中所有的测试产出文档都需要评审，而且开发各个阶段中所产生的文档评审的时候，测试人员也都需要参与。比如：概要设计文档、详细设计文档。

如果测试文档能尽早提交，那么就有了更多的测试时间。另外还有一个很大的益处是，测试者可以在项目中尽可能早地找出缺陷所在，从而帮助改进项目内部的质量。参与前期工作的测试者可以预先估计问题和难度，这可以显著地减少总体测试时间，加快项目进度。

W 模型的局限性： 最大的局限性就是无法支持迭代。W 模型和 V 模型都把软件的开发视为需求、设计、编码等一系列串行的活动。同样的，软件开发和测试也是保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代。

H 模型

W 模型和 V 模型都把软件的开发视为需求、设计、编码等一系列串行的活动，而事实上，虽然这些活动之间存在互相牵制的关系，但在大部分时间内，它们是可以交叉进行的。虽然软件开发期望有清晰的需求、设计和编码阶段，但实践告诉我们，严格的阶段划分只是一种理想状况。试问，有几个软件项目是在有了明确的需求之后才开始设计的呢？如果需求全都明确才开始设计，就不会有那么多的需求变更了。所以，相应的测试活动也不存在严格的次序关系。同时，V 模型和 W 模型都没有很好地体现测试流程的完整性。

为了解决以上问题，有专家提出了 H 模型。它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。H 模型是配合敏捷开发模式产生的。

在 H 模型中，软件测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发地进行。当某个测试条件就绪时，软件测试即从测试准备阶段进入执行阶段。H 模型的简单示意图如下图所示。

图中的其他流程可以是任意流程，例如，开发流程、设计流程、编码流程、SQA 流程，甚至是测试流程自身。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以（或者需要）进行了。概括地说，H 模型揭示了：

• 软件测试不仅仅指测试的执行，还包括测试准备工作。
• 软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。
• 软件测试要尽早准备，尽早执行。
• 软件测试是根据被测物的不同而分层次进行的，支持被测物的多次迭代。

上面介绍了三种典型的测试过程模型，在这些模型中，V 模型强调了在整个软件项目开发中需要经历的若干个测试级别，而且每一个级别都与一个开发级别相对应，但它忽略了测试对象不应该仅仅包括程序，而这一点在 W 模型中得到了补充。W 模型强调了测试计划等工作的先行和对系统需求和系统设计的测试，但 W 模型中不能很好的支持各个流程的迭代。

事实上，随着人们对软件质量的要求越来越高，软件测试也逐步发展成为一个独立于软件开发的知识体系，就每一个软件测试的细节而言，它都有一个独立的流程。比如，现在的第三方测试，就包含了从测试计划和测试案例编写，到测试实施以及测试报告编写的全过程，这个过程在 H 模型中得到了相应的体现，表现为测试是独立的。也就是说，只要测试的前提具备了，就可以开始进行测试了。

这三种模型对指导测试工作的进行都具有重要的意义，但在实际工作中，不能为了使用模型而使用模型，要灵活运用各种模型的优点，取其精华，去其糟粕。例如可以在 W 模型的框架下，运用 H 模型的思想进行独立测试，并同时将测试和开发紧密结合，寻找恰当的就绪点开始测试并反复迭代测试，最终保证按期完成预定目标。

小结

本章需要掌握的内容重点：

• 软件测试的流程
• 测试环境的注意事项
• 测试数据的准备
• V 模型各环节和优缺点
• W 模型各环节和优缺点
• H 模型的思想