瀑布模型、V 模型和 W 模型、迭代模型，以及敏捷开发
DevOps、微服务
概述
软件测试存在的意义是：通过一系列测试活动，“提前” 发现和定位软件产品质量的薄弱环节，并倒逼开发人员修正，从而保证交付的软件质量满足客户需求
越早发现软件中存在的问题，开发费用就越低，软件质量越高，软件发布后的维护费用越低。因此，提前发现和定位问题极为重要，而在软件开发的整个历程中，越是新兴的软件开发模型，越重视“提前测试”。提前测试可以使得在需求分析时期就可发现的错误，不必等到开发完成才被发现
软件开发模型的演进
测试活动随着软件开发模型的演进被不断前置，大型或专业软件的研发，通常会遵循一定的开发模型，从软件发展的历程来看，其中比较典型的有瀑布模型、V 模型和 W 模型、迭代模型，以及敏捷开发模型
各种开发模型并没有明显的适用范围，即使现在也有项目用瀑布模型开发，开发模型的选择并不是越新越好的，而是要根据项目而变化
瀑布模型
瀑布模型的主要特征在于项目完全按照阶段划分，只有前一阶段完成，才能开始下一阶段。具体到测试活动，则只能在全部编码完成后、发布之前执行，在这种开发模型中，测试活动被完全后置了，测试仅仅是编码后的一个活动阶段，测试的重要性没有被凸显出来
V模型
V 模型在整个开发过程中，不仅相对清晰地划分了测试活动的不同级别，还将其不同级别的测试活动与软件开发各阶段清晰地对应起来，强调了测试在整个开发过程中的重要性。但在 V 模型中，测试依旧是编码之后才开始的，测试介入时间还是太晚。比如，需求分析阶段出现的问题，要等到系统测试阶段才能发现
W模型
W 模型是把 V 模型左边的每一个活动都加了一个测试设计活动，体现了“尽早和不断地进行测试”的原则。但
W 模型和 V 模型都把软件的开发视为需求、设计、编码、测试等一系列串行的活动，无法支持迭代、自发性及变更调整
迭代模型
迭代模型(RUP)将大型项目分为多个迭代，每个迭代本质上是一个小项目，每个小项目都包括了需求分析、设计、编码与测试等一系列项目活动。需要注意的一点是，迭代模型是增量的，它要求先完成部分系统功能或业务逻辑，然后依据客户反馈来进一步明确需求，最后通过一次次的迭代来给用户交付达标的产品
每次迭代都有测试，所以迭代模型客观上实现了测试的更早介入
- 敏捷开发模型
作为一种以人为核心，强调迭代、循序渐进的开发方法，敏捷开发近几年非常流行。它有 Scrum、XP 等多种实现方式，当前 Scrum 模式采用较多
敏捷开发中的 Scrum 与迭代模型（RUP）看起来很像，但两者概念完全不同，区别如下：
- 敏捷开发一般不设置deadline，由project owner来决定何时发布；迭代模型则有明确的发布时间规划
- 敏捷开发没有预定项目范围，采用sprint的方式管理项目范围；迭代模型则会预先定义项目范围
- 敏捷开发推崇可运行的软件而不是详尽的文档，每个sprint发布出去都是一个可运行的软件；而迭代模型包含详尽的项目文档、正式的功能需求文件、系统架构文档、开发及测试计划等
- 敏捷开发常用在快速增强功能；而迭代模型更多应用在超大型、长期、企业级的复杂项目上
DevOps
在瀑布模型下，测试人员有大量时间去准备详尽的测试计划，step by step 的测试用例
但敏捷模式下每个 Sprint 的周期比过去的瀑布模式开发缩短了很多，这意味着相同时间内，你发布的次数增多了。而每一次发布都意味着，你需要回归所有重要的测试场景（一般是 P0 和 P1 级别的测试必须回归，P2 和 P3 级别则视实际情况而定要不要回归）。如果在敏捷模式下还采用相同的处理方式，测试的工作量会很大。就会导致工作流积压在测试一侧，无法及时向后进行，而持续集成也会因为测试迟迟不能结束而受到影响
在敏捷开发模型中，测试不能仅仅关注测试本身。向左，要在项目立项阶段就介入进去，去寻找需求中可能存在的问题；向右，介入到发布后的流程中去，通过生产环境监控得来的各种数据去分析各种潜在的缺陷(可进一步参考测试的左移右移)
在这样的背景下，DevOps就出现了，DevOps是开发、质量保证人员、技术运维三个角色的交集，它旨在通过自动化的“软件交付”和“架构变更”的流程，来解决不同角色之间合作的流畅度，以及把软件交付的构建、测试、发布变得更加快捷、频繁和可靠
DevOps 打破了部门墙，提升了研发效率。但这也给软件测试人员带来又一挑战：那就是如何在持续集成、持续部署的模式下保障质量？对于测试来说，如何把测试活动，特别是自动进行的测试活动无缝融合到公司的持续集成，持续部署的框架下，将是个很大的挑战
微服务
微服务是相对于单体应用来说的，它将应用拆分成数个更小的独立服务，并使它们可以单独构建和部署
微服务的采用，也让技术栈变得更繁多、复杂，比如：
- 解决微服务间复杂的通信和消息传递问题，引入了 RabbitMQ、RocketMQ、Kafka 各种消息中间件
- 多个微服务的独立部署导致的环境依赖问题，引入了容器化技术 Docker；
- 容器越来越多，要解决其管理和维护问题而引入了 Kubernetes；
- 为了简化故障定位问题，引入 ELK（Elasticsearch + Logstash + Kibana）
- 上线后，要对系统运行情况进行监控，因而引入了 Prometheus 与 Grafana 等
以上技术的引入，是为了不断应对软件开发演变中带来的各项需求和问题，解决了旧问题的同时，也带来了新挑战，例如：
- 微服务独立部署、独立发布，那么微服务下的测试还能保持一成不变吗？以数据库举例，分库分表怎么来的？要怎么测试？
- 由于某些特殊情况（比如双十一）而导致服务雪崩，微服务会引发熔断、降级、限流等一系列保护措施，要怎么保证这些措施被正确实施了？
- 持续集成，持续部署流水线建立了，以往的测试框架如何最小成本嵌入变成流水线的一环？
面对这些挑战，软件测试在快速演进的同时，也在裹挟前行，寻找破局之道。发布动作变得越来越频繁，以往靠大量手工功能测试 + 少量主流程自动化测试 + 部分回归测试来保障质量的做法，变得越来越不现实。自动化测试，特别是不同层次的自动化测试在整个测试活动中的占比，正逐渐成为影响软件发布质量的关键
敏捷开发测试流程
- 一个软件产品的立项是从软件产品规划开始的，一般会根据业务目标把规划的软件产品需求项，基于实际情况（业务目标、公司战略等）拆分为多个 Backlog 进行进一步细化，即 Backlog Grooming
- 细化之后的需求按照优先级和发布规划，会分为多个 Sprint 进行开发、测试、上线。在每一个 Sprint 内，需求会被拆分为一个个的开发和测试任务，开发人员完成 Task 开发后，就进行自测
- 自测没问题，开发会通过提交 Pull Request 并引起自动构建，自动构建会引导持续集成平台，把开发提交的最新代码打包成可用的测试版本。持续集成平台会触发预设的测试脚本进行自动化测试验证（一般是整个产品的主流程冒烟测试）
- 冒烟测试通过后，再进行功能、性能、安全等方面的测试验证。测试人员进行测试验证的依据来自测试计划的制定和细化，如果测试验证不通过，测试失败的结果会被反馈给开发，Pull Request 不会被 Approve，开发人员会修复问题，再次提交 Pull Request 流程；反之，如果测试验证通过，会通知开发人员测试已经通过（这相当于 Approve 之前开发提交的 Pull Request），然后开发就会合并代码到 Master 分支。合并会再次触发新一轮的持续集成流程，如此循环往复
- 合并进入 Master 分支的代码，通过自动测试验证后，就会被发布到指定测试环境，测试人员会将自动化脚本在此环境进行新一轮的测试验证，直至没问题后，最终被持续部署平台部署上线
功能测试
测试人员根据获取到的软件测试版本，针对开发提交的 Task 进行测试。主要针对新功能，手工执行的方式居多
初级测试开发
帮助功能测试人员编写测试工具及测试框架，进而来提升功能测试的效率，也就是通过开发手段让功能测试变得更简单、快捷。这一阶段的目的纯粹是助力功能测试，减少人工重复劳动，缩短测试周期。该阶段的测试开发仅仅聚焦在开发这个纯粹的事情上，如开发造数平台（Data Platform），让构造测试数据变得比以往更为简单。综上测试开发，即提升测试活动的效率，通过技术手段帮助功能测试工程师提升测试效率
资深测试开发
资深测试开发不再局限于开发本身，而是从流程出发，检测公司整个软件开发周期中，哪个部分耗时最长，哪个部分最复杂，哪个部分最容易出错；然后资深测试开发就要改造现有流程，通过详尽分析、仔细论证，把最复杂、最容易出错的部分流程自动化掉，纳入当前的持续集成流水线中去。综上资深测试开发，即重构测试活动，技术产出完全融入公司的技术体系
测试架构师/测试专家
测试架构师就要规划当前的测试框架需要何种裁剪才能保证本项目顺利发布，并且在项目最开始阶段，通过测试左移的手段，对需求、开发技术方案进行分析，在保证可测试性的前提下，把公司现有的测试手段完美嵌入整个开发生命周期中
在项目发布后，通过测试右移的手段，对生产系统进行监控，对系统本身或业务本身的各种线上情况进行分析，找出薄弱点，反查整个开发测试流程中的短板，然后补齐，从而保证产品的高质量和业务的高可用性
也就是说，测试架构师或者测试专家是在某个领域，全部或者部分重新定义测试活动、测试顺序
综上测试专家/测试架构师，即重新定义测试活动，输出普适的测试方法论