软件测试流程

• 软件测试需求分析（Software testing demand analysis）

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

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

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

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

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

• 软件测试计划制定（Software testing plan development）

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

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

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

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

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

• 软件测试用例设计（Software testing case design）

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

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

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

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

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

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

• 软件测试环境搭建（Software testing environment setup）

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

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

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

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

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

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

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

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

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

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

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

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

• 测试数据准备（Testing data preparation）

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

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

手动创建测试数据:

• 手动模拟用户的实际操作来创建重要业务流程的测试数据；
• 通过 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 的功能与性能测试。

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

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

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

• 测试执行及缺陷处理（Testing execution and defect handling）

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

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

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

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

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

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

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

• 测试总结报告和测试文件归档（Testing summary report and file archiving ）

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

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

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

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

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

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

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

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

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

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

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

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