DevOps时代，测试应该如何应对？

DevOps的概念最早起源于2009年的欧洲，但由于当时配套技术和工具的匮乏，导致DevOps并没有迅速兴起。近几年随着云计算和大数据等新技术的高速发展以及微服务架构理念的深入实践，提倡持续高效的交付使DevOps成为了一种趋势，容器技术又使得DevOps的实施变得相对容易，所以DevOps在各行业各种规模的组织中开始逐步落地实施。

DevOps是Development和Operations的组合词，它是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障(Quality Assurance)部门之间的沟通、协作与整合，旨在以高质量持续发布的产品应对瞬息万变的市场需求。DevOps中质量保障贯穿了整个产品的交付周期，是连接开发和运维之间的桥梁。如果没有全面的质量保障和测试策略，就无法实现持续开发和交付。

图 DevOps

QA等同于测试么？回答肯定是否定的。QA包含QC(Quality Control)和测试两部分，其主要目标是规划和建立质量评估体系，以确保产品的预期质量；测试是用来验证产品并找到可能缺陷的过程。QA和测试二者相互关联，不可互换与替代。

持续测试作为DevOps的一个关键环节，是产品质量保证最重要的方法，那么传统的测试人员应该如何转型去适应DevOps呢？

传统测试以手工测试为主，对代码级别的测试投入较少，整体呈倒三角模式, 侧重于发现缺陷并修复；敏捷的出现增大了自动化测试的比例，以底层运行速度快、消耗小的单元测试为主，整体呈正三角模式，相比传统测试反馈更及时，修复缺陷的成本低；持续测试在敏捷测试的基础上，强调测试持续进行，通过各部门的协同工作，持续发现缺陷并迅速修复。

图 传统测试、敏捷测试和DevOps测试

从传统的瀑布型测试到敏捷测试再到DevOps，三者之间具体有什么区别？这一系列的转型对测试提出了什么样的挑战？DevOps中的测试人员需要掌握哪些技能才能做到全面的质量保障？

传统测试

传统瀑布式软件开发模式中，开发、测试和运维团队之间无协作关系。开发团队负责代码编写和对应的单元测试；测试团队编写手动测试用例并执行，以业务场景测试和系统集成测试为主；QA团队编写自动化测试用例，往往在产品发布前才进行大规模的产品质量验证。

由此可见，传统测试遵循自上而下的顺序方法，产品的质量在测试阶段确定，对产品进行任何更改都非常困难。自动化测试执行效率低，测试用例执行成本高。各部门之间的独立必然导致重复性测试，无法保证全面的产品质量。

敏捷测试

随着市场需求的加快，传统的瀑布式软件开发模式已经不能够满足频繁的软件交付，敏捷开发模式应运而生。在敏捷测试中，测试不再是一个单独的阶段，它属于迭代计划的一个组成部分，测试人员始终与开发人员保持同步，共同负责产品的质量保障。敏捷提倡频繁且更快地进行测试，因此自动化测试在敏捷测试中至关重要。

从开发到运营的整体流程来看，敏捷模型仅仅融合了开发和测试两个部分，加快了软件开发的频率。但是实际部署到生产环境仍然是由运维团队独立完成，开发和运维之间依然隔着厚厚的一堵墙，繁琐的发布周期使敏捷工作重新回到了瀑布模式。DevOps的出现成功打破了开发和运维之间的隔阂，解决了从开发到部署的这一难题。

持续测试

持续测试可以看作敏捷测试的进阶版，意味着持续不断的测试，贯穿了整个软件交付周期，包括从需求分析到产品部署的各种测试阶段。持续测试提倡尽早测试、频繁测试和自动化测试。测试与代码开发同时进行，开发人员和测试人员共同分析测试需求，共同编写和维护测试用例，每开发完一项任务就立即运行自动化测试集对交付质量进行验证，从而形成持续验证。代码一旦成功通过了自动化测试集就会立刻部署到生产环境中，进行生产阶段的持续监控。

Laurent曾经从测试左移、右移的角度描述了当软件开发模式从瀑布到敏捷、再到DevOps转型时，测试应该如何相应变化。

测试左移，是指测试人员更早地参与到软件项目前期的各项活动中，在功能开发之前定义好相关的测试用例，提前发现质量问题。早期引入测试过程有助于防止缺陷，并为开发人员提供了在整个开发阶段应用动态变更的灵活性。

测试右移，就是直接在生产环境中监控，并且实时获取用户反馈。在这种方法中，从用户侧收集反馈，根据用户反馈持续改进产品的用户体验满意度，提高产品质量。测试右移有助于更好的响应意外情况。

传统测试主要集中在软件开发周期的最后，产品发布之前。为了迎合不断加快的交付频率，越来越多团队的测试活动开始向左右两侧移动。一般问题修复成本较高和面向企业收费的软件，一旦生产环境中出现了问题会造成比较大的损失，通常采取测试左移的方式；对于具有展示功能的软件产品，更容易在生产环境中发现问题，通常采取测试右移的方式。面对测试左右摇摆的问题，小编从以下几个阶段阐述了DevOps中的测试具体应该如何实现。

图 DevOps中的测试

DevOps模式下，与产品相关的所有角色都要参与到用户需求的分析与拆分中，包括开发、测试、运维、产品经理、市场等角色，需全部角色共同确定需求的质量标准和验收条件，并采取BDD（Behavior Driven Development）的方式定义，从而使产品交付流水线上的所有相关人员都能对需求达成一致的理解。

测试与开发采用TDD（Test-Driven Development,）的方式工作，共同分析用户故事、制定验收条件。测试用例与产品开发同步进行和完成，代码一旦开发完会立即通过这些测试套件。这一阶段的测试多以自动化的代码级测试为主，比如单元测试、组件测试、接口/服务级测试等。通常这类的测试不需要启动整个应用程序，运行时间短，从而获得更快的反馈，因此这些测试位于测试套件的前端。

验收测试用来验证用户需求是否得到了满足，产品是否可以进入部署阶段。制定全面的用户/业务级的验收测试，既验证了软件产品是否交付了用户期望的业务价值，又可以防止回归问题或者缺陷破坏了软件原有的功能。验收测试分为功能验收测试和非功能验收测试。

功能验收测试

功能验收测试运行在类生产环境中，通过模拟用户在真实环境中的操作来验证用户故事是否完成。手工验收测试将代码部署到UAT（User Acceptance Test）环境中，手动模拟用户的操作进行验证；自动化验收测试采用自动化测试工具和应用交付的方式来模拟用户的使用。常见的功能验收测试包括UI（User Interface）测试、集成测试和服务测试等。

非功能验收测试

这一类测试通常运行在特定的环境中，使用的工具类型取决于被测的产品，一般需要花费较长时间和较复杂的环境来运行，所以这类测试一般位于测试套件的后端。常见的非功能验收测试包括容量测试、易用性测试、安全性测试和兼容性测试等满足其交叉功能特性的测试。

Jez Humble曾指出：“如果真的想获得持续交付的好处，应该尽早将软件产品部署到生产环境中”。代码通过了开发过程中自动化测试套件后，就直接部署到生产环境中，从而获取更直接的反馈。

部署阶段的测试，更准确的说应该叫做生产环境中的监控，从基础监控、应用监控到业务监控，既覆盖了对新功能的可用性测试，也囊括了对已有功能的实时监控，并通过不断的收集用户意见，及时整理、分析并反馈给研发部门，最终实现产品价值的不断提升。常见的监控有两种：一是直接在生产环境上自动运行测试用例；二是通过向生产环境中引入问题来发现产品在生产环境中的潜在问题。

理想的DevOps周期，是从代码开发到生产环境运行的一键部署。显然DevOps非常重视构建、测试和部署的自动化，使用持续集成成为了持续测试的基础。实现持续测试的重要一步，是创建全面的自动化测试套件以在持续集成构建中使用，代码提交后会立刻经过这套自动化测试套件得以验证。常见的自动化测试套件由单元测试、组件检测和验收测试组成，其中每种测试的代码或功能覆盖率至少要达到80%以上才能保证不引入回归问题。

持续测试的成功实施离不开团队内、团队间及跨团队的协作。新项目从开始就要保证所有成员的共同参与，在协作开发中，开发人员和测试人员在各自的用户故事上并行工作，如开发人员开始编译代码，测试驱动也需跟着启动。代码开发完成就能迅速获取反馈，大大缩短了反馈周期，协同工作也帮助开发人员更好的理解用户故事的真正实现。测试人员同时要积极的参与到持续部署的流程中，在将产品部署到生产环境的过程中跟运维人员做好无缝衔接，尽早制定在生产环境中的监测计划，并根据运维人员的反馈及时调整测试方案。

DevOps中质量保证（QA）不再是测试人员的专属责任，而是全体人员都要为之努力的方向。测试人员提前介入到开发工作中，与开发人员一起制定测试计划；开发人员可以参与配置部署；运维人员可以向自动化测试用例库填写测试用例；测试人员随时将自动化测试用例配置到持续交付链中，所有成员的共同目的都是交付高效、高质量的产品。

持续测试要求测试人员具有一定的编码能力。测试人员不但要掌握常用的测试工具、版本控制工具和集成工具的使用，还要能读懂代码，检查构建日志，不断的优化整个测试策略和测试用例。测试人员还必须参与到整个持续交付过程中，以最高效的方式保证产品的质量。

测试人员应该专注于测试策略的不断优化。自动化测试固然是实现持续集成最重要的方式，但并不是所有的测试都适合自动化，比如易用性测试和界面一致性测试等。测试人员需要集中在不断的测试策略优化上，通过调整各种测试用例的比例、增加测试覆盖度、提高测试用例的质量以及快速的反馈来提高测试效率，实现全面的质量保障。