DevOps实战笔记
石雪峰
京东商城工程效率专家
立即订阅
3436 人已学习
课程目录
已更新 30 讲 / 共 35 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从默默无闻到风靡全球,DevOps究竟有什么魔力?
免费
基础理论篇 (4讲)
01 | DevOps的“定义”:DevOps究竟要解决什么问题?
02 | DevOps的价值:数字化转型时代,DevOps是必选项?
03 | DevOps的实施:到底是工具先行还是文化先行?
04 | DevOps的衡量:你是否找到了DevOps的实施路线图?
落地实践篇 (16讲)
05 | 价值流分析:关于DevOps转型,我们应该从何处入手?
06 | 转型之路:企业实施DevOps的常见路径和问题
07 | 业务敏捷:帮助DevOps快速落地的源动力
08 | 精益看板(上):精益驱动的敏捷开发方法
09 | 精益看板(下):精益驱动的敏捷开发方法
10 | 配置管理:最容易被忽视的DevOps工程实践基础
11 | 分支策略:让研发高效协作的关键要素
12 | 持续集成:你说的CI和我说的CI是一回事吗?
13 | 自动化测试:DevOps的阿克琉斯之踵
14 | 内建质量:丰田和亚马逊给我们的启示
15 | 技术债务:那些不可忽视的潜在问题
16 | 环境管理:一切皆代码是一种什么样的体验?
17 | 部署管理:低风险的部署发布策略
18 | 混沌工程:软件领域的反脆弱
19 | 正向度量:如何建立完整的DevOps度量体系?
20 | 持续改进:PDCA体系和持续改进的意义
平台工具篇 (4讲)
21 | 开源还是自研:企业DevOps平台建设的三个阶段
22 | 产品设计之道:DevOps产品设计的五个层次
23 | 持续交付平台:现代流水线必备的十大特征(上)
24 | 持续交付平台:现代流水线必备的十大特征(下)
特别放送 (4讲)
特别放送:成为DevOps工程师的必备技能(上)
特别放送:成为DevOps工程师的必备技能(下)
特别放送:学习DevOps不得不了解的经典资料
特别放送:Jenkins产品经理是如何设计产品的?
总结答疑 (1讲)
期中总结:3个典型问题答疑及如何高效学习
DevOps实战笔记
登录|注册

13 | 自动化测试:DevOps的阿克琉斯之踵

石雪峰 2019-11-09
你好,我是石雪峰。
在古希腊神话中,战神阿克琉斯英勇无比,浑身刀枪不入,唯独脚后跟是他的致命弱点。在特洛伊战争中,他的脚后跟被一箭射中,倒地身亡,从此,阿克琉斯之踵就被用来形容致命的缺陷。我今天要跟你聊的自动化测试,就是 DevOps 的阿克琉斯之踵。
我之前走访过很多公司,我发现,在工程实践领域,比如配置管理、持续集成等,他们实践得还不错,但是却有两大通病,一个是研发度量,另一个就是自动化测试
没有人会否认自动化测试的价值,而且很多公司也都或多或少地在实践自动化测试。但从整体来看,自动化测试的实施普遍不成体系,大多都在关注单点工具。另外,团队对自动化测试的真实效果也存在疑惑。如果不能解决这些问题,就很难突破实践 DevOps 的天花板。
那么,自动化测试究竟要解决什么问题,又适合哪些业务形态和测试场景呢?我们该如何循序渐进地推进建设,并且正确地度量效果以免踩坑呢?这些问题,就是我要在这一讲中跟你分享的重点内容。

自动化测试要解决什么问题?

产品交付速度的提升,给测试工作带来了很大的挑战。一方面,测试时间被不断压缩,以前三天的测试工作要在一天内完成。另一方面,需求的变化也给测试工作的开展带来了很大的不确定性。这背后核心的问题是,业务功能的累加导致测试范围不断扩大,但这跟测试时长的压缩是矛盾的。说白了,就是要测试的内容越来越多,但是测试的时间却越来越短。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《DevOps实战笔记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(4)

  • 桃子-夏勇杰
    设计明确、功能稳定,在快速开发的过程中,特别新产品的研发,有点过于理想。这个是自动化测试投入产出比不高的原因吧。有更快拥抱变化一点的自动化测试理论和实践么?

    作者回复: 其实说到底开发也好,测试也好都是为业务服务的,比如我之前内部创业的时候做了一个游戏平台,业务的目标非常激进,可以说在原型产品化的过程中,是没有测试环节的,基本就是产品经理在试用,研发自测的模式,因为业务的快速拓展和迭代是最重要的。
    回到你说的这个问题,如果想要跟上快速研发的节奏,在投入产出比能够接受的前提下,只有单测能在迭代周期里面同步实现,原因就是单测覆盖率是纳入到质量门禁指标里面的。对于接口测试来说,挑战不在于接口自身,而在于测试数据的准备和环境的准备方面,另外如何研发测试可以基于同一个接口管理平台来进行接口的定义,开发,调试,这对于实现你所说的拥抱变化会更有帮助,工具层面类似swagger这种框架使用到的还是蛮多的。

    2019-11-09
    1
    3
  • leslie
    自动化其实在OPS这块其实很多年了-10年左右了。自动化运维大规模使用国内其实主要还是互联网行业与金融行业:硬件设备过多、系统过多、人力随着环境的复杂而忙不过来;之前一个OPS需要维护的数目中小号2位数,不到10年这个基本上翻了近百倍,纯人力部署完全来不及,docker之类的产生背景不就是这个么。坑没跳过多少却见过不少,故而谈谈个人见解和感受吧。
           公司内部做互联网的普遍都是电商和网游:其它大多都是外包。其实python的使用和自动化有关系的:国内不少企业的自动化都离不开python,这是为何自己开始去学习它的原因。从两个方面去简述吧;
           一方面:从用户的角度说;其实就是如同老师所说的,大多数用户没有代码调教的能力且很多软件开发商不愿适当放开这块,这就导致了有些软件的使用度不太好。因为我们不可能比用户自己还了解系统,不适当放开自然用户就难以处理日常的小问题-得失直接的度其实非常不好,这个在国内普遍存在;
           另一方面:开发者/软件供应商;其实自动化只是减轻压力而不是有了自动化就可以不用管了,用户那边对于软件基本上要求彻底解决问题,可是就如同软件做不到完美一样;自动化运行中难免会有许多不合理或者说一些现实原因造成的坑,例如:环境的复杂性;我们认为我们都测试了;客户那边就实际环境中来个小众的东西-客户体验度又下来了,自动化又改人力了。
           这是以上个人切身经历过的和感受到的现状:其实一套成功的自动化同样是经历了九九八十一难才能基本顺利的部署成功。
          

    作者回复: 哈哈,感同身受,IT的进步就是历经磨难的过程,以我自己做开发的经验来说,完全封闭即便在公司内部也很难实现,即便一家公司的业务流程是E2DD模式的(Excel&Email驱动开发),在搬到线上化的过程也很难采用封闭革命的方式来颠覆现有流程,对自动化来说适当的灵活性和扩展性非常必要,一方面可以同已有的工具快速打通,不用什么都重新实现一边,另外一方面给有能力做一些扩展的团队留出余地,这一点蓝鲸的产品就比较值得借鉴,也是自动化成熟后的必经之路吧。

    2019-11-09
    2
  • 苦行僧
    自动化是守住软件质量的底线,点睛之笔,谢谢老师

    作者回复: 是的哈,这也是为什么自动化在回归领域比较推荐的原因,通过固化一定的测试用例集合,配合自动化的方式,来让繁琐的操作简单化,人力投入到更有价值的测试类型中。

    2019-11-25
  • 克利斯
    目前公司的自动化测试体系已经建立,也有单测覆盖率门禁的指标要求,但是总觉得单测的投入产出比不高,没有看到实际的收效。关于实际提升收效这方面,需要关注哪些指标进行分析和提升吗?

    作者回复: 这个问题特别好!其实我发现,很多公司对于单元测试的态度都是覆盖率驱动的,也就是先定义覆盖率,再后补单元测试用例,写单测的目的就是为了通过覆盖率检查,这样做虽然结果覆盖率上去了,但实际就会出现你所说的问题,花了大力气却没啥提升,核心原因是从一开始的目标就错了。
    我们这边也在推单元测试,但做与不做,覆盖率要求多少,由团队自己决定,平台团队只提供工具和数据量化的支持,先解决为了做而做的问题。在保证核心逻辑被覆盖之后,比较好的做法是通过发生的缺陷和问题适当的补充单元测试case,保证这类问题不再发生,并且重新审视测试的逻辑是否覆盖了多种场景。考查的指标在于有多少缺陷可以被单元测试覆盖,当然不建议把这个指标跟KPI挂钩,而只是为了团队内部学习,甚至适当的奖励识别出最多可以被覆盖问题的成员。
    另外,在团队内部是否可以沉淀一个持续更新的单元测试手册也是很好的习惯,在手册中可以积累如何写一个好的单元测试,命名规范是怎样的,哪些场景需要优先覆盖,常见的错误是怎样的,这会帮助团队成员不断学习。
    至于你的问题本身,说的其实还是如何度量生产力的事情,我推荐一篇文件给你: [https://www.martinfowler.com/bliki/CannotMeasureProductivity.html](https://www.martinfowler.com/bliki/CannotMeasureProductivity.html)

    2019-11-11
收起评论
4
返回
顶部