01 软件开发模型

1.瀑布模型

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

为了弥补这一缺点，V 模型的进一步深化版，即W 模型出现了。从 W 模型的示意图中，可以看到，W 模型是把 V 模型左边的每一个活动都加了一个测试设计活动，体现了“尽早和不断地进行测试”的原则。

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

敏捷、DevOps、微服务等开发模型给测试带来的挑战

那前面我们说到了各自不同的软件开发模型，对于测试人员来说，在不同的开发模型下，保障质量所采用的方式也不尽相同。

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

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

1.敏捷开发

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

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

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

2.DevOps

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

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

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

因为我解决微服务间复杂的通信和消息传递问题，引入了 RabbitMQ、RocketMQ、Kafka 各种消息中间件；

因为多个微服务的独立部署导致的环境依赖问题，引入了容器化技术 Docker；

容器越来越多，要解决其管理和维护问题而引入了 Kubernetes；

为简化故障定位问题，引入 ELK（Elasticsearch + Logstash + Kibana）；

上线后，要对系统运行情况进行监控，因而引入了 Prometheus 与 Grafana 等。

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

微服务独立部署、独立发布，那么微服务下的测试还能保持一成不变吗数据库举例，分库分表怎么来的怎么测试/p>

由于某些特殊情况（比如双十一）而导致服务雪崩，微服务会引发熔断、降级、限流等一系列保护措施，要怎么保证这些措施被正确实施了/p>

持续集成，持续部署流水线建立了，以往的测试框架如何最小成本嵌入变成流水线的一环/p>

面对这些挑战，软件测试在快速演进的同时，也在裹挟前行，寻找破局之道。

破局之道：测试开发

发布动作变得越来越频繁，以往靠大量手工功能测试 + 少量主流程自动化测试 + 部分回归测试来保障质量的做法，变得越来越不现实。自动化测试，特别是不同层次的自动化测试在整个测试活动中的占比，正逐渐成为影响软件发布质量的关键。这也就是测试开发在近年来越来越受追捧的原因。

这么多的自动化测试用例，需不需要维护何维护何将自动化测试融入公司的持续集成流程中并自动触发运行些都是测试开发首要关注的问题，可以预料的是，随着交付频率的加快，测试开发会变成软件测试人员的基本技能。

好了，今天的笔记就到这里。