网站建设初学软件,电脑建设银行怎样设置网站查询密码,seo算法培训,使用爬虫做的网站目录#xff1a;导读
引言
自动化测试
背景
测试团队
测试体系发展
测试平台
自动化测试现状
现状一#xff1a;
现状二#xff1a;
现状三#xff1a;
现状四#xff1a;
现状五#xff1a;
现状六#xff1a;
失败的背景
失败的经历
失败总结 引言 内…
目录导读
引言
自动化测试
背景
测试团队
测试体系发展
测试平台
自动化测试现状
现状一
现状二
现状三
现状四
现状五
现状六
失败的背景
失败的经历
失败总结 引言 内容已经有了但是标题想了很久最终还是决定用这个。简单清楚明了——总结一场失败的自动化测试案例。 文笔欠佳如有阅读不适请见谅
自动化测试 如今软件测试行业里人人都在讲自动化测试人人都在做自动化测试。如果谁说自己不会自动化测试都不好意思去面试。现在各大公司招聘信息都是必须会自动化测试一部分公司招人只招测试开发。甚至有些大头公司都不分测试与开发两个职位。 所以绝大部分公司都有人在搞自动化测试甚至有一部分公司有一套成熟的自动化测试体系。你可以把它看成标准化流水线类似现在讲的Devops。 这里我讲的当然是我在公司的一次自动化测试体会。由于保密协议这里简单介绍
背景 公司是一线大厂的子公司也可以称为合作伙伴。 类似华为旗下的荣耀。公司去年年初由于业务越来越繁多所以人员也是疯狂扩展所以迭代相当频繁标准是一周一个迭代紧急小迭代也有过两三天的时候。有人会说怎么做到的? 拼人啊加班啊。
测试团队 先说我们测试团队吧扩展后测试团队人数大概是40左右其中职位有自动化测试测试开发性能测试安全测试。唯独没有测试工程师。因为公司不招单纯的功能测试。 有人可能会质疑那业务测试谁来做 在这里我们公司业务测试全职测是自动化测试工程师他们兼任业务测试和所负责业务中的一部分自动化测试需求。 而测试开发是专职于测试体系建设中。性能和安全测试有时候会支援业务测试但是他们也是专职于性能和安全方面的测试面向全公司所有系统。
测试体系发展 起初测试团队是没有对测试技术体系思考大家做自动化测试都是各自做各自负责的业务系统那一块用的工具与方法各有千秋编程语言方面大致分两派java和python。 这种分散的自动化测试带来的弊端就是 1、数据无法可视化 2、脚本维护难 3、增加了学习成本 4、易用性、移植性差 5、无法统一管理 ... ... 这种分散的小作坊形式的很快就不适应快速迭代的需求和市场变化。最核心的一点是部门领导无法向老板展示数据。通俗的来讲就是无法向领导展示我们测试团队存在的价值。 嘴巴说谁都会。但是领导想看数据那么平台是唯一秀出测试团队工作中沉淀下来的数据的途径。这样有了数据团队的KPI就出来了。 你说你天天在测试天天在做自动化测试做了多少效果如何。领导不可能一个个找你们去统计去查看。不管你脚本写的多优秀框架设计得多么出神入化。终究没有所谓的正规化平台好。 然后就这么定了。几位测试开发大神在领导的安排下经过多番讨论的设计方案写了一套后台是Java的自动化测试平台。这里说明一下只所以是Java因为公司99%的系统是Java开发。
测试平台 时至今日平台已经完善得差不多了该有的都有没有的也有了。简单说一下测试平台的主要功能 1、接口测试 2、UI测试(app和web) 3、性能测试 4、流量监控 5、接口覆盖率统计 6、安全测试 7、代码质量扫描 8、生产发布卡点 .... 主流的功能就是这些其他小功能我就不一一列举了。这套平台已经集成了软件测试中绝大部分的测试技术在里面可以算得上一套标准的流水线了。 以前会自动化测试会觉得高大上现在平台搭建起来了并且已经维护了1万左右的测试用例在上面了。是不是更加牛逼了 答案我不知道平台搭建后是否真正牛逼了但是它的建设至少对测试团队的影响有如下几点 1、增加了团队的技术含量(至少领导不会认为我们只会点点点) 2、提高了团队的作战能力 3、提高了测试效率因人而异 4、降低了成本(待查) 5、提高了产品质量(待查) 6、降低了学习自动化的难度 ... 上面只列了六点对于我们测试团队的影响也算人们口中常讨论的自动化测试的意义。其实还有很多这里不一一复述了。
自动化测试现状 平台是完善好了前面说了平台已经维护了1万左右的接口测试用例其他数据我暂时没看。显然平台健壮性是毋庸置疑的易用性也很好入门简单。
那么问题来了对于迭代频繁的项目我们在什么时候去编写接口测试用例呢 这种问题绝大多数的人都知道常规的回答不限于这些 1、接口测试需求评审了(绝大多数是没有) 2、什么开发接口开发好了开发提供了接口文档之类的我们就可以去平台维护接口测试用例了 3、开发自测通过代码提交 ... ... 这些回答都很标准很理想。但是你有没有想过现实是很骨感的就是会出现如下情形
现状一 版本变化得让你根本没时间维护的时候你只有加班抽时间来维护而且这种情况只有在领导发话了大家才会去维护上去。有些人由于业务线确实忙所以没维护有些是自己写脚本根本不想维护上去。当然也有人主动的去维护。 针对这个现状领导又出必杀技将接口测试用例设计和覆盖率的指标定下来并且放到KPI考核项里去。 KPI你们都懂这里就不讲述它的作用了。这个大招一放大家都自觉的去平台上维护了。
现状二 现状二就是现状一的延伸版就是每次版本有新增的接口后大家为了KPI会主动上去维护。然后有一大部分人也仅仅上去维护这次后面版本接口有变更也不会花时间去更新已经维护上去的接口。 其中原因有些可能是真正的忙没有时间。有些可能因为懒不想去维护。总而言之测试团队中有一部分人是没有去更新接口测试用例的。
现状三 谈到自动化测试的用途时大家都会记得其中一个是用于回归测试减少人力投入到版本回归测试中去从而把节省出来的时间和人力用于更多的业务测试或者其他测试中去。 但是现实却是在版本变更中真正去执行以前维护的接口测试用例来回归测试的人太少了。据我观察和了解在短期迭代中上个迭代维护的用例这个迭代没人会去跑哪怕只用一分钟的时间。 出现这种情况一方面由于自信太自信于觉得之前的接口没有变动没必要去跑另一方面时间太短又要交付测试功能测好直接就进入产品业务验收环节。就把这一步省略掉。 当然还有其他很多原因这里不细说。结果都是一样没有去维护历史数据。
现状四 自从公司招进外包测试后现在部分项目测试工作分配如下 测试工程师专门负责设计用例然后交给外包团队来将这些用例再翻译成测试脚本这样的做法效率不低下才怪。 首先外包同志不熟悉业务线直接转化还是得从了解业务开始。 其次功能测试用例直接翻译成自动化测试脚本存在重复性劳动同时也会出现场景遗漏场景不可用的情况。 总而言之这种做法收益大大低于投入。 正确的姿势是测试工程师自己就将测试脚本交付出来。对于那些全栈工程师而言最正确的姿势是开发人员自己就动手将测试脚本写出来。根据我对微软的了解微软的 Visual Studio 团队就是这么做的他们根本就不区分开发和测试。
现状五 谈自动化测试的时候我们经常会讲到它的优点其中一个就是降低错误率发现人工无法发现的缺陷。那么在这里统计的结果我们做接口测试真正发现的缺陷是屈指可数凤毛麟角的。 有的甚至一个都没有。当然接口测试本身也是有局限性的他不可能完全代替手工去发现手工测试的缺陷。 这里只讲它的现状...
现状六 ... ... 综上所述还有很多现状我这里不一一列举可以看出来出现这种想象一方面是由于个人原因测试的责任和态度。 一方面领导要求所有项目都要做接口自动化测试从来不评估哪些项目适合做接口自动化测试。 有点盲目跟风做了自动化测试就闪光辉而实际带来的价值却是0。 还有一方面也是关键的一点领导对自动化测试管理方面的欠佳光靠KPI来触发是不行的。
失败的背景 上面已经讲了目前公司自动化测试存在的普遍问题。 现在从我这个小团队来讲项目要上阿里云就是系统上阿里云至于什么原因就不说了涉及保密协议。 系统上阿里云当然没有那么简单所有与系统相关的服务、数据库、中间件、流量等等相对于迭代版本这是一次比较大的变更过程。 然后我们测试在里面承担了什么角色呢 自动化测试在这次迁移的价值会是怎样呢
失败的经历 项目上云当然我们测试要保证项目上云后所有功能都能正常使用。但是切换的那一段时间你有多少时间去验证所有的功能都正常呢 只有两三个小时一年积累下来的功能两三个小时如何验证完呢 这个时候就是自动化测试该上场了。 这个项目自动化测试交给外包维护了是在我们测试平台上维护的主要是维护WebUI功能测试用例。接口测试用例是我们几个在维护。 到了那一天凌晨大家都准备好了准备上云。然后验证。 最后发现没有维护一个WebUI测试用例(生产环境)。 临近上云的几个小时前我问他维护了多少用例他说测试环境维护了生产环境没有。 我当时傻眼了因为这个外包是专职安排弄UI自动化用于上云验证。云上UI前端框架和云下前端框架是不一样也就是页面元素不一样所以测试环境维护的用例根本无法在生产环境使用。 然后我们这边由于时间太赶了接口测试用例还没有更新到云上环境的域名以及调试好。这个失职也是在于我。 导致我们这次上云验证没有跑过一个自动化相关的用例。 简单来说等于这次上云我们用于回归测试的自动化测试相关的用例及脚本没有一个。 但是我们投入在自动化测试的时间差不多跟我们业务测试用例编写的时间趋于一致。 投入与产出是1比0的结果是惨不忍睹。 我们4个测试靠着经久不衰的手法一路闪电带火花的点点点来验证系统所有功能是否在云上正常。 一直验到第二天上午人家来上班... 假设我们准备充分接口和UI自动化测试用例都遍历了所有功能我们也不至于熬了一个整整通宵也不会这么辛苦这么累。
失败总结 经过这次项目上云发现了平时我们打着自动化测试的口号降本增效提高质量。而到了实际要用时却发挥不出一点作用。当然这里有很多原因有个人也有团队管理方面的。 但是抛开原因不追究其惨痛结果反应一个问题自动化测试是有意义的也有价值。 但是如果你运用和管理不当它的价值没有发挥出来将成为一堆废铁终将百无一用。 试问有多少人多少公司做的自动化测试(那些BAT、TMD一线大厂里面的测试团队除外毕竟技术与管理体系已经非常完善)真正发挥了它的价值呢
你们有评估自动化测试(包括平台)的收益吗 如何评估的呢 真正达到产出高于投入的有多少呢 学习自动化测试的人越来越多自动化测试在软件测试中已经是人人参与的但是如果不真正发挥它的作用你们做的自动化测试包括测试平台可能就是 1、为了体现测试团队的技术(面子) 2、为了团队KPI 3、自娱自乐 4、为了面试拿高薪 5、安慰自己 6、为了装13 7、盲目跟风不管有没有价值先要有这个东西存在 ... ... 综上也有其他动机和目的但是在这里我想说的是做自动化测试一定要在做之前思考不限于以下六个问题 1、这个项目为什么要做自动化测试 2、什么项目适合做 3、什么时候做 4、做哪些核心业务模块 5、谁来做 6、如何做如何发挥它的核心价值 其实搞清楚1,4,6三个问题就可以了最关键的是做好第六点我想你做出来的自动化测试肯定在项目中得到良好的收益。
写在最后 如果你觉得文章还不错请大家 点赞、分享、留言 下因为这将是我持续输出更多优质文章的最强动力 看到这篇文章的人有觉得我的理解有误的地方也欢迎评论和探讨 你也可以加入下方的的群聊去和同行大神交流切磋
