在掌握具体的测试技术之前，我们先来宏观了解下当前互联网大厂的软件研发与测试流程。

一、软件

软件是与计算机系统操作有关的计算机程序、可能有的文件、文档及数据。

程序、文档、数据这三个结合起来，就是完整的软件。

软件生命周期是软件的产生直到报废或停止使用的生命周期。

软件生命周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段。

为了使软件开发的工作效率系统化并且可控制，需要采用合适的软件开发模型和开发过程管理所有的活动。

二、软件开发流程

2.1 简介

软件开发流程即软件设计思路和方法的一般过程，包括对软件先进行需求分析，设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编码和调试、程序联调和测试以及编写、提交程序等一系列操作以满足客户的需求并且解决客户的问题，如果有更高需求，还需要对软件进行维护、升级处理，报废处理。

从事软件测试这个行业，每天面对的被测对象都是软件。想要更好的去完成我们测试的工作，首先需要对被测对象，也就是对软件要有基本的了解。最基本的就是需要了解软件开发的流程。了解软件开发的流程会帮助我们更了解测试的流程。

2.2 软件开发流程的演变

2.3 传统瀑布模型

瀑布模型是最早也是应用最广泛的软件过程模型。瀑布模型提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容，给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。

瀑布模型中软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，当前活动的工作结果需要进行验证。

瀑布模型的优点很明显，它有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究，提高了大型软件项目开发的质量和效率。

但是由于开发模型是线性的，所以增加了开发的风险，而且早期的错误可能要等到开发后期的阶段才能发现。这就是瀑布模型的缺点了。

瀑布模型适合使用在充分理解客户需求，并且在项目开发过程中，这些需求不能发生变更的场景中。

2.4 敏捷开发模型

敏捷开发模式是一种从 1990 年***始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，相对于传统软件开发方法的“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。

敏捷开发更适用于需求频繁变化和需要快速开发的场景。

常见的敏捷开发模型有 XP 和 Scrum，下面我们来分别介绍下这两种开发模型。

2.4.1 XP - 极限编程

XP（eXtreme Programming）的主要目标在于降低因需求变更而带来的成本。在传统系统开发方法中，系统需求是在项目开发的开始阶段就确定下来，并在之后的开发过程中保持不变的。这意味着项目开发进入到之后的阶段时出现的需求变更将导致开发成本急速增加，而这样的需求变更在一些发展极快的领域中是不可避免的。

XP 是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

2.4.2 Scrum

Scrum 是一个敏捷开发框架，是一个增量迭代的开发过程。创建 Scrum 的目的是为了提高软件开发的效率。

在 Scrum 中，使用产品 Backlog 来管理产品的需求，产品 Backlog 是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。

Scrum 团队从产品 Backlog 中挑选最高优先级的需求进行开发。挑选的需求在Sprint 计划会议讨论。

在 Sprint 上经过讨论、分析和估算得到相应的任务列表，我们称它为 Sprint Backlog。

在 Scrum 中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个 Sprint，每个 Sprint 的建议长度是二至四周。

在每个迭代周期中，Scrum 团队会举行每日站会。在每日站会上检验 Sprint 目标的进展，做出调整，从而优化次日的工作。

在每个迭代结束时，Scrum 团队将递交潜在可交付的产品增量。

在每个迭代周期最后，需要进行一次 Sprint 评审会议，让团队向产品负责人和利益相关者展示已完成的功能。

在 Sprint 评审会议结束之后，下一个 Sprint 计划会议之前，需要进行 Sprint 回顾会议。回顾会议是要找出 Sprint 过程中，哪些地方执行的很好，哪些地方执行的不好，团队可以做哪些改进。

2.5 DevOps 开发模型

DevOps 主要是为了扩展敏捷开发实践，进一步完善软件变更在构建、测试、部署、交付等阶段中的流动。通过软件应用程序的全面所有权，跨职能团队完成从设计到生产支持等各环节的工作。

DevOps（Development 和 Operations的组合词）是一种软件开发方法，涉及软件在整个开发生命周期中各个阶段。

它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”以及测试人员之间沟通合作的模型。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

它的出现是由于软件行业日益清晰地认识到为了按时交付软件产品和服务，开发、测试和运维工作必须紧密合作。

DevOps 更适合使用在需求频繁变化、开发、测试运维都需要敏捷的场景下。

2.5.1 DevOps 生命周期

持续开发

这是DevOps生命周期中软件不断开发的阶段。与瀑布模型不同的是，软件可交付成果被分解为短开发周期的多个任务节点，在很短的时间内开发并交付。

这个阶段包括计划、编码和构建阶段，并使用 Git 和 SVN 等工具来维护不同版本的代码，以及 Ant、Maven、Gradle 等工具来构建、打包代码到可执行文件中，这些文件可以转发给自动化测试系统进行测试。

• 计划：Jira
• 编码：Git、SVN
• 打包：Ant、Maven、Gradle

持续测试

在这个阶段，开发的软件将被持续地测试 Bug。对于持续测试，使用自动化测试工具，如 Selenium、Appium、TestNG、JUnit、pytest 等。这些工具允许质量管理系统完全并行地测试多个代码库，以确保功能中没有缺陷。在这个阶段，使用 Docker 容器实时模拟“测试环境”也是首选。一旦代码测试通过，它就会不断地与现有代码集成。

持续集成（CI）

持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。

这是支持新功能的代码与现有代码集成的阶段。由于软件在不断地开发，更新后的代码需要不断地集成，并顺利地与系统集成，以反映对最终用户的需求更改。更改后的代码，还应该确保运行时环境中没有错误，允许我们测试更改并检查它如何与其他更改发生反应。

Jenkins 是一个非常流行的用于持续集成的工具。使用 Jenkins，可以从 Git 存储库提取最新的代码修订，并生成一个构建，最终可以部署到测试或生产服务器。可以将其设置为在 Git 存储库中发生更改时自动触发新构建，也可以在单击按钮时手动触发。

持续部署

它是将代码部署到生产环境的阶段。在这里，我们确保在所有服务器上正确部署代码。如果添加了任何功能或引入了新功能，那么应该准备好迎接更多的网站流量。因此，系统运维人员还有责任扩展服务器以容纳更多用户。由于新代码是连续部署的，因此配置管理工具可以快速，频繁地执行任务。

容器化工具在部署阶段也发挥着重要作用。 Docker 是流行的工具，有助于在开发，测试，登台和生产环境中实现一致性。 除此之外，它们还有助于轻松扩展和缩小实例。

持续监控

这是 DevOps 生命周期中非常关键的阶段，旨在通过监控软件的性能来提高软件的质量。这种做法涉及运营团队的参与，他们将监视用户活动中的错误/系统的任何不正当行为。这也可以通过使用专用监控工具来实现，该工具将持续监控应用程序性能并突出问题。

使用的一些流行工具是 ELK Stack。这些工具可帮助密切监视应用程序和服务器，以主动检查系统的运行状况。它们还可以提高生产率并提高系统的可靠性，从而降低 IT 支持成本。发现的任何重大问题都可以向开发团队报告，以便可以在持续开发阶段进行修复。

2.5.2 DevOps 对应用程序发布的影响

在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备 DevOps 能力的组织中，应用程序发布的风险很低。

1. 减少变更范围
   与传统的瀑布模式模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。
2. 加强发布协调
   需要靠强有力的发布协调人来调和开发与运营之间的技能鸿沟和沟通鸿沟；采用协作工具来确保所有相关人员理解变更的内容并全力合作。
3. 自动化
   强大的部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。与传统开发方法那种大规模的、不频繁的发布（通常以“季度”或“年”为单位）相比，敏捷方法大大提升了发布频率（通常以“天”或“周”为单位）。

3. 测试流程体系

3.1 简介

软件测试是软件质量保证的关键步骤。越早发现软件中存在的问题，修复问题的成本就越低，在编码后修改软件缺陷的成本是编码前的10倍，在产品交付后修改软件缺陷的成本是交付前的10倍。软件质量越高，软件发布后的维护费用越低。

为了能更好的保障软件质量，在软件测试的实践中，慢慢形成了一些流程用来达到这一目标。

3.2 传统测试流程

单元测试

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

• 测试阶段：编码后
• 测试对象：最小模块
• 测试人员：开发
• 测试依据：代码、注释、详细设计文档
• 测试方法：白盒测试

集成测试

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

• 测试阶段：单元测试完成后
• 测试对象：模块间的接口
• 测试人员：开发
• 测试依据：单元测试模块、概要设计文档
• 测试方法：黑盒与白盒结合

冒烟测试

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

• 测试阶段：提测后
• 测试对象：整个系统
• 测试人员：测试
• 测试依据：冒烟测试用例
• 测试方法：黑盒测试（手工或自动化手段）

系统测试

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

• 测试阶段：冒烟测试通过后
• 测试对象：整个系统
• 测试人员：测试
• 测试依据：需求文档、测试方案、测试用例
• 测试方法：黑盒测试

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

功能测试：功能测试是对产品的各功能进行验证，以检查是否满足需求的要求。

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

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

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

验收测试

验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，向软件购买都展示该软件系统满足其用户的需求。

• 测试阶段：发布前
• 测试对象：整个系统
• 测试人员：用户/需求方
• 测试依据：需求、验收标准
• 测试方法：黑盒测试

案例

比如一个 App 的新功能迭代项目，研发在编码完成后，会首先进行单元测试，单元测试可以选择 Junit 框架来写单元测试脚本。

单元测试通过之后，研发之间会进行模块之间的集成测试。集成测试需要在测试环境中进行联调，重点关注模块之间的数据传递是否正确。集成测试通过之后会集成代码，生成包含新功能的包。

生成的包需要先进行冒烟测试，可以使用自动化的手段，用 Java 或者 Python 语言，结合 TestNG 或者 pytest 框架，写出正向功能验证的自动化测试用例来进行冒烟测试。可以把冒烟测试直接集成到 Jenkins 当中，冒烟失败则打包失败。

冒烟测试通过后测试人员接手下一步任务，开始执行系统测试。系统测试会对新包的各个方面进行测试，包含手工的新功能验证，使用 Appium 写自动化测试用例来进行功能方面的回归测试和兼容性测试，使用 python 脚本实现 app 的专项性能测试和安全性测试等等。

测试通过后，交由需求方进行验收测试；验收测试通过后，才会交给最终用户使用。这就是一个完整的传统测试流程。

3.3 软件测试模型

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

随着测试过程管理的发展，软件测试专家通过实践总结出了很多很好的测试过程模型。这些模型将测试活动进行了抽象，并与开发活动有机的进行了结合，是测试过程管理的重要参考依据。

V 模型

V 模型是瀑布模型的一种改进，瀑布模型将软件生命周期划分为计划、分析、设计、编码、测试和维护六个阶段，由于早期的错误可能要等到开发后期的测试阶段才能发现，所以可能带来严重的后果。

优点

• 明确的标注了测试过程中存在着那些不同的测试类型
• 清楚的表达了测试阶段和开发过程各阶段的对应关系

缺点

• 容易让人误解为测试是在开发完成之后的一个阶段。
• 由于它的顺序性，当编码完成之后，正式进入测试时，这时发现的一些bug可能不容易找到其根源，并且代码修改起来很困难。
• 实际中，由于需求变更较大，导致要重复变更需求、设计、编码、测试。返工量大。

W 模型

W 模型从 V 模型演化过来，增加了软件个开发阶段中应同步进行的验证和确认活动，W 模型明确表示出了测试与开发的并行关系。测试与开发是同步进行的，有利于尽早的全面发现问题。

相对于 V 模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W 模型由两个 V 字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

W 模型认为测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。

W 模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。

优点

• 测试的活动与软件开发同步进行
• 测试的对象不仅仅是程序，还包括需求和设计
• 尽早发现软件缺陷可降低软件开发的成本

缺点

• 开发和测试依然是线性的关系，需求的变更和调整，依然不方便
• 如果没有文档，根本无法执行 W 模型
• 对于项目组成员的技术要求更高

H 模型

相对于 V 模型和 W 模型，H 模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

这个示意图仅仅演示了在整个生产周期中某个层次上的一次测试“微循环”。图中标注的其他流程可以是任意的开发流程。例如，设计流程或编码流程。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以（或者说需要）进行了。

测试准备：所有测试活动的准备判断是否到测试就绪点

测试就绪点：测试准入准则，即是否可以开始执行测试的条件

测试执行：具体的执行测试的程序

优点

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

缺点

• 管理型要求高：要定义清晰的规则和管理制度，否则测试过程将很难管理和控制
• 技能要求高：H 模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；
• 测试就绪点分析困难：测试很多时候，你并不知道测试准备到什么时候是合适的，就绪点在哪，就绪点标准是什么，对后续的测试执行启动带来很大的困难
• 对整个项目组的人员要求非常高

三种模型对比

• V模型适用于中小企业
• W模型适用于中大型企业
• H模型人员要求非常高，现阶段使用比较少

3.4 系统测试工作流程

项目计划

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

需求分析

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

测试设计

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

用例评审

一般进行两轮。一轮是组内评审，组内人员会评审测试用例是否完全覆盖了需求，会提出一些修改意见。二轮评审需要和产品、研发一起进行，产品和研发会从不同角度对用例进行一些补充。

测试执行

提测后通过冒烟测试即可进入测试执行阶段。需要根据测试规程创建测试套件，以提高测试执行的效率，并且确认已经正确搭建了测试环境。

环境没有问题后，就根据计划的执行顺序，通过手工或使用测试工具来执行测试规程。记录测试执行的结果，以及被测软件、测试工具的标识和版本。将实际结果和预期结果进行比较。对实际结果和预期结果之间的差异，作为bug上报，并且进行分析以确定引起差异的原因。缺陷修正后，重新进行测试活动。

Bug 管理

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

发布维护

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

3.5 Bug 管理流程

提交 Bug

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

指派 Bug

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

确认 Bug

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

判断是否推迟处理

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

遗留 Bug

对于推迟处理的问题可以暂时进行遗留。一般遗留的问题需要经过项目经理与测试经理协商后才可以。

处理 Bug

开发人员在确认完一个问题需要处理时，那么就对其进行处理工作。

回归 Bug

确认非 Bug 问题：对于提交的一个 Bug，开人员处理为非 Bug 或无法重现，然后直接转交给测试人员回归。测试人员再次确认，如果真如开发人员所说，则将问题关闭。如果非开发人员所说，是由于问题描述模糊或其它原因未重现问题，则再次注明原因转给开发人员。

确认修复问题：对开发人员修复的问题再次进行确认，确认能过，则关闭问题。确认不通过，将问题再次打开并转给开发人员。

确认遗留问题：有计划的对遗留的问题进行确认，有些遗留问题随着时间的推移，版本的更新或已经不存在了，对这类问题应该及时关闭。有些遗留问题依然存在且变得紧急，对于这类问题应该及时打开交给开发人员处理。

关闭 Bug

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

3.6 测试左移和测试右移

传统的流程就是接到项目后参与需求评审，然后根据需求文档写写用例和准备脚本，等开发提测之后正式开始测试、提 Bug、回归，测试通过后就结束了，项目交给运维上线，之后投入下一个项目继续重复这样的流程。

这样的流程看似没什么问题，但缺点是：测试过程是在一定时间间隔内发生的，测试人员必须等待产品完全构建才能找到错误和故障。不可否认，花费的时间超过了可以商定的时间，等待代码成为测试人员的瓶颈。

而测试左移以及测试右移，能够让测试拥有更多的主动权，有更充足的时间进行测试，同时不会像之前因为质量差风险高每次都延期上线，并且产品的线上质量也能有保证。

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

3.6.1 测试左移

测试左移是向测试之前的开发阶段移动。

测试左移的原则支持测试团队在软件开发周期早期和所有干系人合作。因此他们能清晰地理解需求以及设计测试用例去帮助软件“快速失败”，促使团队更早的修改所有的 Bug。

参与和理解会使测试人员获取产品完整的知识，彻底想清楚各种场景，根据软件行为设计实时的场景，这些都会帮助团队在编码完成之前识别出一些缺陷

左移聚焦在使测试人员在全部和最重要的项目阶段参与进来。这就是测试人员把焦点从发现 Bug 转移到 Bug 的预防上，同时也驱动项目的商业目标。

随着测试团队的责任的提高，团队不在仅仅聚焦在“测试软件去发现 Bug”，而是积极团队合作，参与项目初始阶段的计划和建立强壮有效的测试策略，而测试策略又为团队提供好的测试领导力和指导，使团队聚焦在产品的长远的视角，而不仅仅是测试工作。

左移首先为测试人员提供了设计测试的机会，无论这些测试是被聚焦在客户的体验还是期望，也促使开发人员根据这些测试去开发软件以满足客户需求。

3.6.2 测试右移

测试右移是测试活动向产品发布之后的步骤移动。

是产品上线了之后也可以进行一些测试活动。可以在生产环境做监控，监控线上性能和可用率，一旦线上发生任何问题，尽快反应，提前反应，给用户良好的体验。

小结

以上，我们对互联⽹⼤⼚软件研发与测试流程有初步的全⾯了解，接下来就技术体系作深⼊学
习。