13 | 自动化测试:DevOps的阿克琉斯之踵
该思维导图由 AI 生成,仅供参考
自动化测试要解决什么问题?
- 深入了解
- 翻译
- 解释
- 总结
自动化测试在DevOps实践中扮演着重要角色,但其实施普遍存在问题。文章指出,自动化测试应解决产品交付速度提升所带来的测试挑战,但并非所有测试活动都适合自动化。自动化测试适用于机械重复操作、稳定设计规范、兼容性测试和长时间执行测试等场景。然而,自动化测试面临投入产出比、上手门槛、维护成本和测试设备投入等问题。文章建议从单元测试、接口测试和UI测试三个层面入手,以中间层的接口测试为主,单元测试和UI测试为辅。文章强调了自动化测试的价值和局限性,为读者提供了对自动化测试的全面认识。 文章还介绍了自动化测试框架的开发和结果分析。在框架开发方面,文章提到了接口测试工具和平台的支持,以及UI自动化测试中的控件维护成本问题,并分享了解决方法和示例代码。在结果分析方面,文章强调了除了追求覆盖率外,还需关注测试误报率,提出了解决问题的方法和建议。 总的来说,本文全面介绍了自动化测试的实施挑战、框架开发和结果分析,为读者提供了深入了解自动化测试的机会。读者可以从中了解自动化测试的适用场景、实施路径和结果分析的要点,以及解决自动化测试困境和问题的方法。
《DevOps 实战笔记》,新⼈⾸单¥59
全部留言(7)
- 最新
- 精选
- 桃子-夏勇杰设计明确、功能稳定,在快速开发的过程中,特别新产品的研发,有点过于理想。这个是自动化测试投入产出比不高的原因吧。有更快拥抱变化一点的自动化测试理论和实践么?
作者回复: 其实说到底开发也好,测试也好都是为业务服务的,比如我之前内部创业的时候做了一个游戏平台,业务的目标非常激进,可以说在原型产品化的过程中,是没有测试环节的,基本就是产品经理在试用,研发自测的模式,因为业务的快速拓展和迭代是最重要的。 回到你说的这个问题,如果想要跟上快速研发的节奏,在投入产出比能够接受的前提下,只有单测能在迭代周期里面同步实现,原因就是单测覆盖率是纳入到质量门禁指标里面的。对于接口测试来说,挑战不在于接口自身,而在于测试数据的准备和环境的准备方面,另外如何研发测试可以基于同一个接口管理平台来进行接口的定义,开发,调试,这对于实现你所说的拥抱变化会更有帮助,工具层面类似swagger这种框架使用到的还是蛮多的。
2019-11-0929 - 克利斯目前公司的自动化测试体系已经建立,也有单测覆盖率门禁的指标要求,但是总觉得单测的投入产出比不高,没有看到实际的收效。关于实际提升收效这方面,需要关注哪些指标进行分析和提升吗?
作者回复: 这个问题特别好!其实我发现,很多公司对于单元测试的态度都是覆盖率驱动的,也就是先定义覆盖率,再后补单元测试用例,写单测的目的就是为了通过覆盖率检查,这样做虽然结果覆盖率上去了,但实际就会出现你所说的问题,花了大力气却没啥提升,核心原因是从一开始的目标就错了。 我们这边也在推单元测试,但做与不做,覆盖率要求多少,由团队自己决定,平台团队只提供工具和数据量化的支持,先解决为了做而做的问题。在保证核心逻辑被覆盖之后,比较好的做法是通过发生的缺陷和问题适当的补充单元测试case,保证这类问题不再发生,并且重新审视测试的逻辑是否覆盖了多种场景。考查的指标在于有多少缺陷可以被单元测试覆盖,当然不建议把这个指标跟KPI挂钩,而只是为了团队内部学习,甚至适当的奖励识别出最多可以被覆盖问题的成员。 另外,在团队内部是否可以沉淀一个持续更新的单元测试手册也是很好的习惯,在手册中可以积累如何写一个好的单元测试,命名规范是怎样的,哪些场景需要优先覆盖,常见的错误是怎样的,这会帮助团队成员不断学习。 至于你的问题本身,说的其实还是如何度量生产力的事情,我推荐一篇文件给你: [https://www.martinfowler.com/bliki/CannotMeasureProductivity.html](https://www.martinfowler.com/bliki/CannotMeasureProductivity.html)
2019-11-115 - 苦行僧自动化是守住软件质量的底线,点睛之笔,谢谢老师
作者回复: 是的哈,这也是为什么自动化在回归领域比较推荐的原因,通过固化一定的测试用例集合,配合自动化的方式,来让繁琐的操作简单化,人力投入到更有价值的测试类型中。
2019-11-254 - leslie自动化其实在OPS这块其实很多年了-10年左右了。自动化运维大规模使用国内其实主要还是互联网行业与金融行业:硬件设备过多、系统过多、人力随着环境的复杂而忙不过来;之前一个OPS需要维护的数目中小号2位数,不到10年这个基本上翻了近百倍,纯人力部署完全来不及,docker之类的产生背景不就是这个么。坑没跳过多少却见过不少,故而谈谈个人见解和感受吧。 公司内部做互联网的普遍都是电商和网游:其它大多都是外包。其实python的使用和自动化有关系的:国内不少企业的自动化都离不开python,这是为何自己开始去学习它的原因。从两个方面去简述吧; 一方面:从用户的角度说;其实就是如同老师所说的,大多数用户没有代码调教的能力且很多软件开发商不愿适当放开这块,这就导致了有些软件的使用度不太好。因为我们不可能比用户自己还了解系统,不适当放开自然用户就难以处理日常的小问题-得失直接的度其实非常不好,这个在国内普遍存在; 另一方面:开发者/软件供应商;其实自动化只是减轻压力而不是有了自动化就可以不用管了,用户那边对于软件基本上要求彻底解决问题,可是就如同软件做不到完美一样;自动化运行中难免会有许多不合理或者说一些现实原因造成的坑,例如:环境的复杂性;我们认为我们都测试了;客户那边就实际环境中来个小众的东西-客户体验度又下来了,自动化又改人力了。 这是以上个人切身经历过的和感受到的现状:其实一套成功的自动化同样是经历了九九八十一难才能基本顺利的部署成功。
作者回复: 哈哈,感同身受,IT的进步就是历经磨难的过程,以我自己做开发的经验来说,完全封闭即便在公司内部也很难实现,即便一家公司的业务流程是E2DD模式的(Excel&Email驱动开发),在搬到线上化的过程也很难采用封闭革命的方式来颠覆现有流程,对自动化来说适当的灵活性和扩展性非常必要,一方面可以同已有的工具快速打通,不用什么都重新实现一边,另外一方面给有能力做一些扩展的团队留出余地,这一点蓝鲸的产品就比较值得借鉴,也是自动化成熟后的必经之路吧。
2019-11-093 - 兮锅锅“解决方法就是操作层获取控件和控件本身的定位方法”,老师,感觉这种方法不错,可以告知一下有什么比较好的技术手段做到这一点么?
作者回复: 我们使用的不是什么高深的技术,TestNG就可以实现了,主要是框架的能力要支持,当控件定位发生改变时,不会影响我们在操作层的方法封装代码,把一处控件改动对应多处引用修改的一对多关系变为一对一关系,即无论引用了多少处此控件,只需要修改一处代码。 解决办法:为了使操作层在获取控件时与控件的定位方式解耦,在操作层通过获取自定义ID的方式来得到控件对象。此ID需要在控件的配置文件中定义好,再通过操作层之下的代理层来统一处理。
2020-05-14 - Geek_6bb688"API 接口测试为主,以单元测试和 UI 测试为辅",有哪些比较推荐的对应的测试框架2022-02-09
- BertGeek自动化测试不是很明确其他公司如何规划和项目落实 目前所在公司,每个私有环境,运维人员部署自动化测试2021-05-19