软件测试存在的意义

身处软件行业的人都知道，“软件的质量不是测试出来的”，既然质量不能被测试出来，那么测试工程师，乃至软件测试存在的意义是什么呢？

我认为，软件测试存在的意义是：
通过一系列测试活动，“提前” 发现和定位软件产品质量的薄弱环节，并倒逼开发人员修正，从而保证交付的软件质量满足客户需求。

有研究表明，越早发现软件中存在的问题，开发费用就越低，软件质量越高，软件发布后的维护费用越低。因此，提前发现和定位问题极为重要，而在软件开发的整个历程中，越是新兴的软件开发模型，越重视“提前测试”。提前测试可以使得在需求分析时期就可发现的错误，不必等到开发完成才被发现。

那么，具体是如何一步步 “提前” 发现软件产品中存在的质量问题的呢？

那就不得不从软件开发模型的演变过程说起了。

开发模型

测试开发面临的第一个挑战就是：测试活动随着软件开发模型的演进被不断前置

大型或专业软件的研发，通常会遵循一定的开发模型，从软件发展的历程来看，其中比较典型的有瀑布模型、V 模型和 W 模型、迭代模型，以及敏捷开发模型。

这里值得说明的一点是，各种开发模型并没有明显的适用范围，即使现在也有项目用瀑布模型开发，开发模型的选择并不是越新越好的，而是要根据项目而变化。

1 、瀑布模型

我们知道，瀑布模型的主要特征在于项目完全按照阶段划分，只有前一阶段完成，才能开始下一阶段。具体到测试活动，则只能在全部编码完成后、发布之前执行，在这种开发模型中，测试活动被完全后置了，测试仅仅是编码后的一个活动阶段，测试的重要性没有被凸显出来。

2、V模型

基于此，V 模型出现了。V 模型在整个开发过程中，不仅相对清晰地划分了测试活动的不同级别，还将其不同级别的测试活动与软件开发各阶段清晰地对应起来，强调了测试在整个开发过程中的重要性。但在 V 模型中，测试依旧是编码之后才开始的，测试介入时间还是太晚。比如，需求分析阶段出现的问题，要等到系统测试阶段才能发现。

3、W 模型

为了弥补这一缺点，V 模型的进一步深化版，即W 模型出现了。

从 W 模型的示意图中，可以看到，W 模型是把 V 模型左边的每一个活动都加了一个测试设计活动，体现了“尽早和不断地进行测试”的原则。

但是说到底，W 模型和 V 模型都把软件的开发视为需求、设计、编码、测试等一系列串行的活动，无法支持迭代、自发性及变更调整。例如，需要根据市场及监管要求，快速调整项目需求时（比如，今年春节期间各大平台线上抢口罩的活动），使用 W 模型或 V 模型不仅无法快速响应，而且还会影响软件质量，甚至公司声誉。于是迭代模型应运而生，它正好可以弥补 W 模型和 V 模型的不足。

4、迭代模型

迭代模型，常用于需求不甚明确、开发难度比较大的项目，比如互联网行业流行的先出 MVP 版本，然后再根据用户反馈进行调整的项目。

迭代模型将大型项目分为多个迭代，每个迭代本质上是一个小项目，每个小项目都包括了需求分析、设计、编码与测试等一系列项目活动。需要注意的一点是，迭代模型是增量的，它要求先完成部分系统功能或业务逻辑，然后依据客户反馈来进一步明确需求，最后通过一次次的迭代来给用户交付达标的产品。

以双 11 大促时的优惠会场项目为例，在一次迭代中，开发者会先实现会场的部分需求，然后在下一次迭代中，再根据用户的反馈，修正主会场的需求及完成剩余需求。

由于每次迭代都有测试，所以迭代模型客观上实现了测试的更早介入。

此外，作为一种以人为核心，强调迭代、循序渐进的开发方法，敏捷开发近几年非常流行。它有 Scrum、XP 等多种实现方式，当前 Scrum 模式采用较多。

虽然敏捷开发中的 Scrum 与上文提及的迭代模型（RUP）看起来很像，但两者概念完全不同，区别如下：

因此，从业务类型出发，如果有明确交付日（通常有合同约束），或者和外部公司合作的项目，比较适宜迭代模型；如果没有明确交付日，公司内部的产品，则更适用于敏捷开发。

---

综上所述可以看出，以上几种模型是随着技术与业务的变化逐渐演化的，软件测试从初始的瀑布模型的最后一道工序，逐渐被提前到敏捷开发模型（以 Scrum 为例）中的每一个 Sprint 中，测试在软件开发过程中发挥着越来越重要的作用。

在瀑布模型下，测试人员有大量时间去准备详尽的测试计划，step by step 的测试用例，但如果在敏捷、DevOps、微服务的模式下还采用相同的处理方式，就会导致工作流积压在测试一侧，无法及时向后进行，而持续集成也会因为测试迟迟不能结束而受到影响。

“兵无常势、水无常形”， 面对敏捷、DevOps、微服务这些开发模型时，我们要保障质量，就必须知道，它们各有什么特点？以及相比较传统开发模型，给我们带来了哪些挑战？

开发模型特点

1.敏捷开发

由于敏捷开发模型每一个 Sprint 都是完整的，并且每一个 Sprint 结束时都会发布一个可工作的软件，所以在每一个 Sprint 内，测试工程师都要进行完备的测试，以确保发布出去的软件产品质量没问题。

而每个 Sprint 的周期比过去的瀑布模式开发缩短了很多，这意味着相同时间内，你发布的次数增多了。而每一次发布都意味着，你需要回归所有重要的测试场景（一般是 P0 和 P1 级别的测试必须回归，P2 和 P3 级别则视实际情况而定要不要回归）。那么可以想象一下，这里面的工作量有多大、多枯燥

在敏捷开发模型中，测试不能仅仅关注测试本身，而且还要走出去。向左，要在项目立项阶段就介入进去，去寻找需求中可能存在的问题；向右，介入到发布后的流程中去，通过生产环境监控得来的各种数据去分析各种潜在的缺陷。在这过程当中“牵一发而动全身”，团队的每个角色（开发、质量保证人员、技术运维）都要对质量负责。

2.DevOps

这个时候，DevOps 和微服务便出现了。DevOps是开发、质量保证人员、技术运维三个角色的交集，它旨在通过自动化的“软件交付”和“架构变更”的流程，来解决不同角色之间合作的流畅度，以及把软件交付的构建、测试、发布变得更加快捷、频繁和可靠。

如果你所在公司采用了持续集成、持续部署流水线，它们一般都是 DevOps 的工作成果，DevOps 打破了部门墙，提升了研发效率。但这也给软件测试人员带来又一挑战：那就是如何在持续集成、持续部署的模式下保障质量？对于测试来说，如何把测试活动，特别是自动进行的测试活动无缝融合到公司的持续集成，持续部署的框架下，将是个很大的挑战，也是你在测试职业生涯上再走远些，将面对的问题。

3.微服务

关于微服务，你只需知道微服务是相对于单体应用来说的，它将应用拆分成数个更小的独立服务，并使它们可以单独构建和部署。

微服务的引进提升了开发效率，降低了发布时间，但也带来了新的挑战：由于各个微服务常由不同的团队负责，并且各个服务之间普遍依赖 API 完成通信和调用，那么这些 API 之间的“契约”就变得非常重要，“契约测试”也就相应产生了。

还有，相较于传统单体应用，微服务的测试也更加复杂。仅从代码打包部署这件事儿来说，在单体应用里，不太出现使用错测试包的情况，但是在微服务里，这个情况可能会发生。单体应用，一个版本就对应一个代码分支；而使用微服务，每个微服务通常对应不同的代码分支。这就意味着在测试微服务时，测试不仅要关注你测试的微服务是否版本部署正确，还要检查其依赖的其他微服务的部署分支，查看其他微服务的分支是不是也部署正确。

而且，微服务的采用，也让我们的技术栈更为繁多、复杂，比如：

• 因为我解决微服务间复杂的通信和消息传递问题，引入了 RabbitMQ、RocketMQ、Kafka 各种消息中间件；
• 因为多个微服务的独立部署导致的环境依赖问题，引入了容器化技术 Docker；
• 容器越来越多，要解决其管理和维护问题而引入了 Kubernetes；
• 为简化故障定位问题，引入 ELK（Elasticsearch + Logstash + Kibana）；
• 上线后，要对系统运行情况进行监控，因而引入了 Prometheus 与 Grafana 等。

• ---

  以上“新”技术的引入，是为了不断应对软件开发演变中带来的各项需求和问题，解决了旧问题的同时，也带来了新挑战，例如：

• 微服务独立部署、独立发布，那么微服务下的测试还能保持一成不变吗？以数据库举例，分库分表怎么来的？要怎么测试？
• 由于某些特殊情况（比如双十一）而导致服务雪崩，微服务会引发熔断、降级、限流等一系列保护措施，要怎么保证这些措施被正确实施了
• 持续集成，持续部署流水线建立了，以往的测试框架如何最小成本嵌入变成流水线的一环？

•