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

传统测试、敏捷测试和持续测试有何不同？文章源自玩技e族-https://www.playezu.com/18493.html

 文章源自玩技e族-https://www.playezu.com/18493.html

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

 文章源自玩技e族-https://www.playezu.com/18493.html

文章源自玩技e族-https://www.playezu.com/18493.html

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

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

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

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

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

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

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

　　图 DevOps中的测试

1、用户需求分析

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

2、编码、构建阶段

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

3、验收阶段

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

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

   

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

4、部署阶段（持续监控）

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

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

5、持续集成（Continuous Integration）

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

6、协作

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

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

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