文章目录

• 软件测试存在的意义
• 开发模型
• • 1 、瀑布模型
  • 2、V模型
  • 3、W 模型
  • 4、迭代模型
• 开发模型特点
• • 1.敏捷开发
  • 2.DevOps
  • 3.微服务

软件测试存在的意义

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

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

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

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

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

开发模型

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

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

2、V模型

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

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

4、迭代模型

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

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

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

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

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

开发模型特点

1.敏捷开发

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

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

2.DevOps

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

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

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

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