DevOps自动化测试的原则和实践
DevOps是为了在保证高质量的前提下缩短系统变更从提交到部署至生产环境的时间。在对系统进行变更时，质量很重要。高质量才能让业务价值传递到系统干系人。『自动化测试既是提高质量的一种重要手段，也是实施持续测试必需的能力，因此它是DevOps持续交付流水线中必不可少的环节』。本文简单阐述一下在DevOps持续交付流水线中自动化测试的原则和实践。
1、自动化测试的原则
DevOps实施自动化测试主要有以下原则：全员参与、更早的介入、指标量化和收益至上。
全员参与
在DevOps团队中一般不会有专职的测试人员。DevOps参与的人是系统的干系人，运维、客户、产品经理是首要受众群体，其实是设计师、架构师，最后才是技术团队。
更早的介入
DevOps测试工作贯穿整个软件交付生命周期，在需求阶段即进行业务级的测试设计，在需求特性开发、交付整个过程中同步进行并完成测试任务。
指标量化
所有的测试指标应该量化，且是全团队共同的职责。所有的指标要有阀值，比如代码复杂度要小于<多少，单元测试率要>多少，技术债务中验证类问题不能高于多少。只有通过量化的指标才能进行流水的下一个节点
收益至上
DevOps尤重收益。在自动化技术选型上优先收益率最高是单元测试，其次接口服务测试、最后才界面测试。
2、自动化测试的实践
自动化测试实践除了依赖自动化的测试服务外，还有其他三个要素即人、过程和方法。
对平台的自动化的测试服务要求
测试服务对象包含一切，“软件定义一切”。『一切即可测试』，包括文档、配置、环境、发布包、脚本、基础设施。
测试服务功能涵盖多种类型，包括代码扫描、功能测试、性能测试、安全测试、兼容性测试、乃至验收测试和用户体验性测试。
测试服务自动触发，通过持续交付流水线节点触发自动化测试服务。DevOps持续交付流水线原则上要求5分钟内结束。这不仅需要分布式的测试执行技术，还要求应用架构能够定义测试优先级以及相配套的快速部署技术。
测试服务基础资源即开即用，借助容器、弹性扩缩等技术让自动化测试能力服务化。
自动化测试服务能力进行分层，自动化测试平台提供基础测试服务和组件接入能力。项目个性化的技术要求和跨系统公用组件由项目组自行建设，测试平台负责接入。
人
团队技能要求提升，即是全栈开发团队也是全栈测试团队，要求具备各层级测试的能力。团队不再需求基础手工测试人员。但在团队中需要有测试架构师进行整体测试方案设计，负责和平台进行对接事宜。需要有测试领域技术专家按照测试场景进行技术分析和选型，并提供业务和技术组件。需要测试专家能够指导开发工程师进行测试组件和用例的开发。
过程
要实现测试工作前移，必然要修改原来需求、开发、测试、运维串联的过程，采用协同并行工作模式。团队要采用敏捷的开发模式，团队成员数量尽量少、支撑的的业务系统尽量的集中，这样确保每个团队的成员对用户场景有统一认识。
在开发迭代中，做故事澄清、原型设计、数据模型设计时，可以并行进行测试对象分析、测试点分析、测试数据、测试组件等设计。越早的发现问题，修复的成本越低。
同一个故事的开发任务和测试任务安排给同一个人，测试驱动开发的另外一个好处是通过用例，让开发从用户的角度去审视自己的设计从而提升质量。
实施方法
用例管理要坚持“三易”， 用例执行要支持“三更”
用例管理的「三易」
1.易管理：
“比遗留代码更可怕的是遗留的测试代码”，测试代码管理复杂度远高于代码本身。一定要建立统一的管理规范。团队的测试规范包括用例规范、组件规范、过程规范、环境管理规范必须事前先建立。要建立用例的评估把控机制，做到事前评审事后抽查。
2.易维护：
采用分层设计，用例和组件分离，用例本身只关注业务逻辑。区分变化与不变、资源文件、环境信息与用例代码分离。
3.易定位：
测试用例不相互依赖，要求明确的断言信息。
用例执行的「三更」
1.更多：
采用各种各样的自动化测试方式来解决业务测试的问题，而不是单一技术手段。
2.更早：
尽早测试，尤其是已知的风险因素，确保在交付生命周期的后期发现的问题更少。
3.更频繁：
不断的重复进行测试，向开发团队提供代码质量的迭代式反馈。
3、总结
实施自动化测试也要重视收益。测试工作应该贯穿整个软件交付生命周期，越早的发现问题，修复的成本越低。在实施自动化测试的过程中，不一定减少测试人员的个数，但能逐步提升测试人员素质。
好的自化测试实践，不仅仅是依赖自动化测试服务。还依赖与团队、任务的协作方式，以及自动化测试建设过程中的一些小技巧。
绵薄之力
最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走
这些资料，对于想进阶【自动化测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助....
DevOps自动化测试的原则和实践相关推荐
- 技术沙龙|京东云DevOps自动化运维技术实践
自动化测试体系不完善.缺少自助式的持续交付平台.系统间耦合度高服务拆分难度大.成熟的DevOps工程师稀缺,缺少敏捷文化--这些都是DevOps 在落地过程中,或多或少会碰到的问题,DevOps发展任 ...
- 普元eos使用svn_普元DevOps给DevOps打上企业级最佳实践标签
作者:顾伟 卷首语:2017年初,我们DevOps团队给自己定了个小目标,将自己的研发 过程以软文方式分享出来,于是就有了"无数春笋满林生"的画面,写什 么的都有:转型过程.项目管 ...
- 演讲实录 | DevOps五大理念及其落地实践
5月29日,我在全球软件质量&效能大会QECon2021深圳站上进行了一场名为"DevOps五大理念及其落地实践"的演讲. 相信很多朋友已经看过了我参与翻译的新书<独 ...
- ML：MLOps系列讲解之《MLOps原则之监控/“机器学习成绩”系统/可再现性/松散耦合架构(模块化)/基于ML的软件交付指标/MLOps原则和实践的总结》解读
ML:MLOps系列讲解之<MLOps原则之监控/"机器学习成绩"系统/可再现性/松散耦合架构(模块化)/基于ML的软件交付指标/MLOps原则和实践的总结>解读 目录
- 走向.NET架构设计—第五章—业务层模式，原则，实践（中篇）
走向.NET架构设计-第五章-业务层模式,原则,实践(中篇) 前言:设计模式并不是什么很高深的东西,至少不是那么"神乎其神".说到底,设计模式就是一些设计思想.下面我们就走进项目, ...
- 领域驱动设计学习之路—DDD的原则与实践
本文是我学习Scott Millett & Nick Tune编著的<领域驱动设计模式.原理与实践>一书的学习笔记,一共会分为4个部分如下,此文为第1部分: 领域驱动设计的原则与实 ...
- 《软件需求分析（第二版）》第 14 章——需求管理的原则和实践 重点部分总结
文章目录 前言 一.讨论 二.简答题 三.名词解释 总结 前言 软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化,分析各种可能的解法,并且分配给各个软件元素.需求分析是软件定义阶段中的最后 ...
- 走向.NET架构设计—第五章—业务层模式，原则，实践（后篇）
走向.NET架构设计-第五章-业务层模式,原则,实践(后篇) 前言:在上一篇文章中,讲述了一些设计模式的使用,本篇首先接着介绍还没有讲完的一些设计模式,然后再讲述一些架构模式中的超类模式,作为本篇的结 ...
- 软件过程的价值观、原则以及实践——从敏捷说起
[写在最前:文章的很多观点是S老师讲授并且我觉得能引发我许久不动的大脑的一点零星火花的内容.在S老师上课之前,R老师曾就敏捷开发提出了诸多质疑,敏捷真的是拥抱变化的么?开发人员真的欢迎变化么?敏捷的方 ...
最新文章
- 如何最好一个管理者？
- 新计算推动信息技术产业新发展？
- leetcode算法题--Letter Case Permutation
- 纳米技术系列：物联网的下一个大事件竟来自极小之处
- 移植YAFFS2文件系统到linux3.18.4内核(原)
- presto-server-0.198集群安装
- c++ map 获取key列表_一日一技：举例说明python中的map()方法
- 计算机网络考试难吗,网络教育统考中的计算机考试难不难,
- 南大首届AI本科课程曝光：周志华为第一批00后，准备了大剂量烧脑数学
- C# string.Format json格式字符串报错”输入字符串的格式不正确“
- allegro使用经验
- vue 函数（二）：callback回调函数
- 海康 安全码 修改密码_「海康威视客户服务」“通道被锁定”“网络不可达”“未认证的设备”……NVR4.0 Lite通道专题来袭！...
- jQuery中关于jQuery.fn.init.prototype = jQuery.fn的解读
- 1024_scsdn_徽章获取日_日常工作记录_百度图片爬取小程序
- 延迟满足 —— 达到目标需要忍住重重诱惑
- 【sourcetree】sourcetree连接云效项目，带密码（每个平台可能不一样）
- 电脑升级Win11后不流畅卡顿怎么解决
- 激光打印机工作原理（网上摘录）
- 在window系统安装虚拟linux系统以及搭建web环境教程