1.6　测试流程体系

1．软件测试的作用

软件测试是软件质量保证流程中的关键环节。通过软件测试越早发现软件中存在的问题（Bug），修复软件中的问题的成本就越低，软件质量也就越高，软件发布后的维护费用越低。

为了能更好地保障软件质量，在软件测试的实践中，测试人员慢慢形成了一些流程用来达到保障软件质量的目标。下面介绍一下常见的测试流程。

2．常见的测试流程

常见的测试流程包含了如图1-21所示的步骤。

图1-21

下面分别介绍每一个流程的含义。

（1）单元测试

单元测试是对软件中的基本组成单位进行的软件测试。目的是检验软件基本组成单位的正确性。

1）测试阶段：编码完成后。

2）测试对象：最小模块。

3）测试人员：开发人员。

4）测试依据：代码、注释、详细的设计文档。

5）测试方法：白盒测试。

（2）集成测试

集成测试是在软件系统集成过程中进行的测试，目的是检查软件模块之间的接口是否正确。

1）测试阶段：单元测试完成后。

2）测试对象：模块间的接口。

3）测试人员：开发人员。

4）测试依据：单元测试模块、概要设计文档。

5）测试方法：黑盒与白盒结合。

（3）冒烟测试

冒烟测试是在软件开发过程中针对软件基本功能的一种快速验证，是对软件基本功能进行确认验证的手段。

1）测试阶段：提测后。

2）测试对象：整个系统。

3）测试人员：测试人员。

4）测试依据：冒烟测试用例。

5）测试方法：黑盒测试（手工或自动化测试方式）。

（4）系统测试

系统测试是对已经集成好的软件系统进行彻底的测试，验证软件系统的正确性和性能等是否满足其规约所指定的要求。

1）测试阶段：冒烟测试通过后。

2）测试对象：整个系统。

3）测试人员：测试人员。

4）测试依据：需求文档、测试方案、测试用例。

5）测试方法：黑盒测试。

一般系统的主要测试工作都集中在系统测试阶段。根据不同的系统，所进行的测试种类很多。在系统测试中，又包括如下测试种类。

1）功能测试：功能测试是对系统的各项功能进行验证，以检查这些功能是否满足需求。

2）性能测试：性能测试是通过自动化测试工具模拟多种正常、峰值及异常负载情况对系统的各项性能指标进行的测试。

3）安全测试：安全测试检查系统对非法入侵的防范能力。

4）兼容性测试：兼容性测试主要是测试系统在不同的软硬件环境下是否能够正常地运行。

（5）验收测试

验收测试是部署软件之前的最后一种测试。验收测试的目的是确保软件准备就绪，向软件购买方展示该软件满足其需求。

1）测试阶段：发布前。

2）测试对象：整个系统。

3）测试人员：用户/需求方。

4）测试依据：需求文档、验收标准。

5）测试方法：黑盒测试。

3．软件测试模型

软件测试模型用于定义软件测试的流程和方法。众所周知，软件开发的质量决定了软件的质量，同样地，测试的质量将直接影响测试结果的准确性和有效性。软件测试和软件开发一样，都遵循软件工程原理，遵循管理学原理。

随着测试管理的发展，软件测试专家通过实践总结出了很多很好的测试模型。这些模型是对测试活动的抽象、概括，并与开发活动有机地结合起来，是测试管理的重要参考依据。下面介绍几种常见的测试模型。

（1）V模型

V模型是开发模型中瀑布模型的一种改进。瀑布模型将软件生命周期划分为计划、分析、设计、编码、测试和维护这6个阶段。由于早期的系统错误可能要等到开发后期的测试阶段才能发现，所以使用瀑布模型进行开发很可能给系统造成严重的后果。

V模型改进了瀑布模型的缺点，在软件开发时期，开发活动和测试活动几乎同时开始，在开发活动进行的时候，测试活动开始进行相应的文档准备工作，从而提高软件开发的效率和效果，如图1-22所示。

图1-22

V模型的优点是明确地标注了测试过程中存在着哪些不同的测试类型，并且可以清楚地表达测试和开发各阶段的对应关系。

但是，它也有一些缺点，例如，容易使人误解，测试只是软件开发完成后的工作。而且由于它的顺序性，当编码完成之后，正式进入测试时，我们发现的一些Bug可能不容易找到其产生的根源，而且代码修改起来也很困难。在实际工作中，因为用户对系统的需求变更较快，所以使用V模型可能导致要重复变更需求、设计、编码、测试，返工量会比较大。

（2）W模型

W模型从V模型演化过来，相对于V模型，在软件各开发阶段中W模型增加了应同步进行的验证和确认环节。

W模型由两个V字型模型组成，分别代表测试与开发过程，图1-23中明确表示出了测试与开发的并行关系。测试与开发是同步进行的，有利于尽早、全面地发现系统中的问题。

图1-23

在W模型中测试伴随着整个软件开发周期，而且测试的对象不仅是程序，需求、设计等也需要测试。

系统使用W模型有利于尽早、全面地发现系统中的问题，例如，需求分析完成后，测试人员就立即参与到对需求的验证和确认工作中，以便尽早地找出需求中的缺陷所在。

对需求的测试也有利于及时了解项目的测试难度和测试风险，尽早制定应对措施，这将显著减少总体测试时间，加快项目进度。

使用W模型的优点很明显。首先测试与软件开发同步进行，而且测试的对象不仅仅是程序，还包括需求和设计。这样可以尽早发现软件缺陷，降低软件开发的成本。

但是W模型还是有一些缺点，例如，开发和测试依然是线性的关系，项目的需求变更和调整依然不方便。而且如果前期工作流程中没有产生文档，根本无法执行W模型。

（3）H模型

相对于V模型和W模型，H模型将测试完全独立出来，形成一个完全独立的工作，将测试准备工作和测试执行工作清晰地体现出来，如图1-24所示。

图1-24

图1-24仅仅演示了在软件整个生产周期中某个层次上的一次测试——“微循环”。图1-24中标注的其他流程可以是任意的开发流程，例如，设计流程或编码流程。测试流程是灵活的，只要满足测试条件，并且完成测试准备活动，测试就可以进行了。

H模型中包含了如下概念。

1）测试准备：所有测试活动的准备，判断是否达到测试就绪点。

2）测试就绪点：测试准入准则，开始执行测试的条件。

3）测试执行：具体的执行测试的程序。

4）其他流程：设计流程或编码流程。

H模型揭示了软件测试中除测试执行外，还有很多其他工作。它让测试活动完全独立贯穿于整个软件生命周期，并与其他流程并发进行。在H模型中，软件测试活动可以尽早准备、尽早执行，具有很强的灵活性。而且软件测试可以根据被测对象的不同而分层次、分阶段、分次序执行，同时也是可以被迭代的。

但是H模型对于项目管理要求很高，需要定义清晰的规则和管理制度，否则测试过程将很难管理和控制。而且对于测试人员的技能要求也很高，因为H模型要求测试人员对迭代规模有控制能力，迭代的规模不能太大也不能太小。在H模型中，测试就绪点的分析也比较困难，在测试过程中，测试人员并不知道测试准备到什么程度是合适的？就绪点在哪？就绪点标准是什么？这会给后续的测试执行带来很大的困难。

（4）3种测试模型对比

上面介绍的3种测试模型使用场景会有一些不同。

● V模型适用于中小企业。

● W模型适用于中大型企业。

● H模型对测试人员的技能要求非常高，使用比较少。

4．系统测试工作流程

系统测试工作流程如图1-25所示。

图1-25

下面分别解释一下图1-25所示的每一步的具体含义。

（1）项目计划

这是描述软件测试目的、范围、方法和重点等内容的文档。

（2）需求分析

测试工程师参与需求分析，可以增加对需求的了解，减少后期与产品和开发人员的沟通成本，节省时间。早期确定测试用例的编写思路可以为测试打好基础。在需求分析的过程中测试人员可以获取一些测试数据，有助于测试用例的设计。而且在需求分析过程中可以发现需求不合理的地方，降低后期的测试成本。

（3）测试设计

测试设计是指把概括的测试目标转化为具体的测试用例的一系列活动。测试设计时要结合需求、系统架构、设计和接口说明等文档评审测试依据。通过对测试项、规格说明、测试对象行为和结构的分析，识别测试条件并确定测试优先级；根据分析的内容设计测试用例，同时确定测试条件和测试用例所需的必要的测试数据。

（4）用例评审

测试用例评审一般进行两轮。一轮是组内评审，组内人员会评审测试用例是否完全覆盖了需求，并提出一些修改意见。二轮评审需要和产品经理、研发人员一起进行，产品经理和研发人员会从不同角度对测试用例进行一些补充。测试用例评审并且把评审中的建议补充完毕之后，测试用例才最终被设计完毕，进入等待执行的状态。

（5）测试执行

开发人员完成需求的开发之后会提测，也就是把可以测试的产品交付给测试人员进行测试。提测后需要先执行冒烟测试，冒烟测试通过之后正式进入测试执行阶段。

开始执行测试之前要确认已经正确搭建了测试环境。测试环境没有问题后，就根据计划执行，如通过手工或使用测试工具来执行测试用例。执行测试过程中需要记录测试执行的结果，以及被测软件、测试工具的标识和版本，将测试得到的实际结果和预期结果进行比较，得出实际结果和预期结果之间的差异，作为Bug上报，并对Bug进行分析以确定引起差异的原因。Bug修正后，重新对系统进行测试。

（6）Bug管理

软件缺陷（Bug）是一种泛称，它可以指功能的错误，也可以指性能低下、易用性差等。

（7）发布维护

监控上线后的产品，若发现产品有问题应及时修复。

5．Bug管理流程

Bug的管理也需要遵循一定的流程，基本流程如图1-26所示。

图1-26

（1）提交Bug

在提交一个Bug的时候，测试人员先尽量描述这个Bug的属性：重现环境、类型、等级、优先级，以及详细的重现步骤、结果与期望等。在提交一个问题（Bug）之前首先应该保证，这个Bug是没有被提交过的，以免造成重复提交Bug。

（2）指派Bug

有些公司的测试部门与开发部门相互独立，那么测试人员就不好确定自己测试的系统模块是由哪位开发人员负责的，在这种情况下，测试人员统一把测出的问题指派给项目组长或经理，由项目组长（或经理）对问题进行确认后再次分配给相应的开发人员去解决。有些测试人员是和研发团队在一起工作的，这时，测试人员会对某开发人员负责的模块非常清楚，就可以将测出的问题直接指派给相应的开发人员。

（3）确认Bug

开发人员接到测试人员提交的一个Bug，首先对其进行分析与重现，如果对其进行分析后发现不是Bug（可能由于测试人员不了解需求）或无法对此Bug进行重现，那么就需要将此问题返回给测试人员再次进行回归测试，并注明返回Bug的原因；如果确认为是Bug，则需要对其进行处理。

（4）判断是否推迟处理

在处理问题（Bug）之后，开发人员还需要对Bug进行一次判断，决定是否需要推迟处理此Bug。有些Bug已经被确认了是需要解决的问题，由于其可能在极端情况下才会出现，或处理此Bug需要对系统架构进行改动，或其优先级非常低，所以暂时不需要对此Bug进行处理或到下个系统版本再修复此Bug。

（5）遗留Bug

对于推迟处理的Bug可以暂时进行遗留。一般遗留的Bug需要经过项目经理与测试经理协商后才可以决定接下来要做的工作。

（6）处理Bug

开发人员在确认完一个Bug需要处理时，就对其进行处理。

（7）回归Bug

确认不是一个Bug：对于测试人员提交的一个Bug，开发人员处理后确认不是Bug或无法重现此Bug，就直接把此Bug转交给测试人员回归测试。测试人员再次确认此Bug，如果真如开发人员所说，则将此Bug取消；如果非开发人员所说，是由于对Bug描述模糊或其他原因造成未重现Bug，则再次注明Bug出现的原因并转给开发人员。

确认修复Bug：测试人员对开发人员修复的Bug再次进行确认，确认此Bug已处理，则取消此Bug；确认此Bug还存在，将Bug再次转给开发人员进行处理。

确认遗留Bug：有计划地对遗留的Bug进行确认，有些遗留Bug随着时间的推移、版本的更新或已经不存在了，对这类Bug应该及时取消。有些遗留Bug被取消后依然存在且需要紧急处理，对于这类Bug应该及时交给开发人员处理。

（8）关闭Bug

对于已经修复的Bug进行关闭，这也是一个Bug的最后一个状态。

6．测试左移和测试右移

传统的测试流程就是测试人员接到项目后参与需求评审，然后根据需求文档写测试用例和准备测试脚本，等开发人员提测之后正式开始测试、提交Bug、回归测试，测试通过后项目开发工作就结束了，运维人员把项目上线运行。

这样的流程看似没什么问题，但缺点是测试过程是在一定时间间隔内发生的，测试人员必须等待产品完全构建后才能开始找错误和软件故障。“等待代码”成为测试人员加快测试进度的瓶颈。

而测试左移以及测试右移能够让测试人员拥有更多的主动权，有更充足的时间进行测试，同时不会像之前因为测试质量差使系统延期上线，并且系统质量也得到保证。

不管是测试左移还是测试右移都是为保证产品质量服务的。不要把提测认为是测试活动的开始，上线是测试活动的结束，更不要认为质量只是测试人员需要关注的。

（1）测试左移

测试左移是系统测试工作向测试之前的开发阶段移动。

测试左移的原则是支持测试团队在软件开发周期早期和所有干系人合作。这样是为了使测试人员在清晰地理解需求后，高效地设计出测试用例，用这些测试用例让软件“快速失败”，进一步促使开发团队更早地修改系统中所有的Bug。

测试左移聚焦于使测试人员在项目的全部或最重要的实施阶段参与进来，让测试人员把工作焦点从发现Bug转移到预防Bug上。

测试左移为测试人员提供了早于开发人员设计测试用例的机会，也促使开发人员根据这些测试用例去开发软件，以充分保证系统功能满足用户需求。

（2）测试右移

测试右移是系统测试工作向产品发布之后的阶段移动。是产品上线之后进行的一些测试活动。测试右移是测试人员在生产环境中做测试监控，监控线上产品的性能和可用率，一旦线上产品发生任何问题，测试人员可尽快反映问题，提前解决问题，保证产品给用户良好的体验。