• 1
  • 1
分享
  • 开发转测试:从零开始的6年自动化之路——软件测试圈
  • 曼倩诙谐 2022-08-03 14:04:18 字数 1980 阅读 1030 收藏 1

自动化初识

作为一个测试人,我们或多或少都听过或用过自动化,我们都曾在初入测试行业时,满怀期待的以为测试的尽头是不用测试员点点了,项目一提测,小手点下自动化的开关,瞬间测试的工作就完成了。

这就是我一开始从开发转向测试时最好奇的地方,带着这个好奇心,我激情满满地加入了公司刚成立的自动化组,一探测试到底是如何摆脱手工劳动而完成测试的,一干就是6年。

接下来,把我们的自动化在公司的使用进程一一介绍给大家,希望它能对你有所启发,有所帮助。

自动化启动

我相信每一个搭建起自动化团队的公司,无疑不是想通过自动化来提高工作效率、节省时间、节省人力。

但有一个致命的地方,很多初次起草做自动化的人,他可能根本不了解自动化的本质和特点,仅仅知道“做了自动化就可以像其他公司一样提高效率”,这是我们做了3年自动化之后觉悟出来的道理。

这不是在批评、埋怨谁,我很感谢感激走过那3年,人生每一段路都没有虚度,它让我深刻认识到什么样的做法是可以的什么样是行不通的。

我在这里说出来,只是想后来者可以不用花这么长时间来明白,希望你们在做出决策之前对自动化有更全面的认识。

2016年,领导决定测试部要做自动化,当时我才从开发转到测试没多久,还在做功能测试(体验功能测试阶段),做了一段时间便感觉挺繁琐的,加上自己平常也在查阅相关自动化领域的资料。

所以,当领导说要成立自动化组时,我特别兴奋,决定要加入自动化组,心想终于有真正的机会来尝试自动化这个新玩意了。

虽然我有一些蹩脚的开发功底,但毕竟没有实战过自动化,于是我们从外面招来了一个自动化方向的大牛。

技术大牛就是不一样,仅用2周就搭建起了我们的自动化项目架构,并进行了相关封装抽取。那个时候我真正知道了Selenium、Webdriver、TestNg、Jenkins集成起来的一套自动化系统的工作流程及用法。

写到这里,你大概已经知道,我们实现的是一套UI自动化方案。框架搭建完了,剩下的就开始收集用例、转化脚本了,也是在写脚本的过程中,我慢慢知道了所谓的自动化测试是如何实现自动的。

自动化初期,我们并没有什么经验,我们只知道至少要把公共主流程性的用例给自动化了。

于是,便以我功能测试几个月对业务的了解开始抽取了某一模块这种类型的用例,技术大牛和我分工把这些用例都给转化出来了,这个过程,对于我来说学到了很多,知道了PO模式、数据驱动、元素定位以及里面的一些坑等。

写脚本对于我来说上手很容易,很快我俩就完成了一期自动化用例,然后又把这些用例集成到Jenkins上,至此,自动化就算初步运作起来了。

探索自动化的意义

完成一期脚本转化以后,马不停蹄地开始做二期的脚本开发规划。有很长一段时间,我觉得我们做自动化好像失去了做它的意义,我们完成了脚本开发,为啥不用呢?怎么才能把它用到工作中去呢?

当自己做的东西没有在工作中发挥它的价值的时候,做的人就会逐渐丧失对这份工作的热情,因为他没有得到反馈,他不知道接下来奋斗的目标在哪里。当然,也依然会持续做着一些可有可无的工作。

次年,也就是2017年,领导开始跟我们一起想办法,一开始的办法是跟功能测试人员说,我们哪些模块一些什么样的用例已经实现自动化了,让他们在测试的过程中,如果需要执行那种类型的用例的时候,就去Jenkins上执行。

试运行了一段时间证明,靠自由自愿的方式就别想把工作干好。

大部分人都不选择用自动化,即使他的项目可以用。还有一部分有心用的同学,由于不懂开发相关技术,不会分析出错时的问题,常常需要找自动化开发者去帮忙看,加之,前期UI自动化脚本确实没那么稳定,运行错误的概率又更高了。

那不用自动化的原因就出来了:

1、不感兴趣,觉得手工测测挺好的;

2、想用,奈何自己技术有欠缺,不会分析脚本问题,加大使用难度;

3、想用,但脚本稳定性太差,丧失对自动化的信任度。

相比其他同事,自认为算是一个自动化的狂热者,不太相信自动化不能在工作中发挥作用。心想,一定是你们自己不会用才这样。于是,我申请了做一段时间适合自动化应用模块的测试。

我是怎么做的呢?以下,是一个正常项目测试中自动化应用流程图,直到今天我也依然使用的这个思路。

1.png

按照这样的流程,磕磕绊绊地应用了几个项目。真实的效果是:

1、使用了自动化以后确实发现了一些问题,但分析定位出那是一个bug确实不是肉眼一下就能看出的;

2、效率上看,若考虑投入成本/产出,这谈不上提高了我多少测试效率,但若是一份脚本开发维护,多人使用,那又是不一样的;

3、Jenkins上执行用例并没有那么方便,常常看得头昏眼花。

也只有在我真正参与使用了我们的自动化以后才认识到,咱们这个自动化确实有很多不完美的地方,那我也总算清楚了,下一步也知道调整的方向在哪。


作者:月亮    

来源:http://www.51testing.com/html/52/n-7792352.html

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   前言  UI测试是测试应用中的各种交互是否达到了实现的效果。常用的UI测试框架有Espresso和UIAutomator。  今天给大家分享5个可能不曾听过的新自动化测试框架。  1.Kaspresso  Kaspresso是一个基于Espresso和UIAutomator构建的测试自动化框架。并针对Espresso的一些已知缺点进行优化:  ·解决flakiness问题;  · 解决Espresso不支持adb问题;  · 优化代码可读性;  以如下示例说明代码可读性:  Espresso测试示例写法:  @Testfunlogout(){   onView(with...
            0 0 2051
            分享
          • owasp top10漏洞SQL注入失效的身份认证和会话管理跨站脚本攻击 XSS直接引用不安全的对象安全配置错误敏感信息泄露缺少功能级的访问控制跨站请求伪造 CSRF使用含有已知漏洞的组件未验证的重定向和转发xss如何盗取cookie?通过存储型XSS漏洞嵌入脚本代码,用户访问的时候直接用js脚本将cookie发送给攻击者的服务器渗透测试的流程是什么(分为黑盒测试和白盒测试)信息收集判断域名ip(是否CDN)站长之家whois信息,子域名,DNS记录查找真实ip识别网站指纹找到CMS对应漏洞整站分析(主机和端口扫描):服务器系统、中间件、脚本类型、数据库类型旁站(同一ip不同的网站)和C端(x...
            13 13 3873
            分享
          •   测试人员应该为项目做什么?这可能是每个测试人员都会思考的问题。  角色是一种关系,虽然你不能控制自己的角色,但可以控制自己角色锁承担的职责。只有清楚了自己的角色,才能给自己的角色设定合理的期望值。并且在因为产品质量问题受到责(背)备(锅)时,进行反驳。  那么,测试人员应该如何正确看待自己的角色呢?  测试人员服务多个“客户”  测试是一个服务角色,服务意味着客户,你的成功主要取决于你如何满足客户的愿望和最大的利益。  而测试人员有很多“客户”,在项目开发中,你的客户主要是“项目经理”、“开发人员”和“终端用户”。他们都有自己的需求,而且他们的共同需求不一定一致:  项目经理  指导项目是...
            0 0 1168
            分享
          •   刷脸支付,刷脸进站,刷脸打卡,一“脸”走天下的时代悄然来临。人脸识别的技术让人们的生活告别繁琐,如何验证人脸识别技术的功能正确性、安全性、识别率等关键问题,在测试领域也逐渐成为至关重要的课题。本文将结合实际工作中的探索与总结,阐述如何针对人脸识别技术开展测试。  一、什么是人脸识别?  人脸识别是基于人的脸部特征信息进行身份识别的一种生物识别技术,用摄像机或摄像头采集含有人脸的图像或视频流,并自动在图像中检测和跟踪人脸,进而对检测到的人脸进行脸部识别的一系列相关技术。人脸识别技术分为人脸检测,人脸跟踪,人脸比对三个部分。通过人脸检测可以在复杂的背景和场景下判断是否存在活体面像,并将其分离出...
            14 15 1166
            分享
          • 问:你在测试中发现了一个bug,但是开发经理认为这不是一个bug,你应该怎样解决。首先,将问题提交到缺陷管理库里面进行备案。然后,要获取判断的依据和标准:根据需求说明书、产品说明、设计文档等,确认实际结果是否与计划有不一致的地方,提供缺陷是否确认的直接依据;如果没有文档依据,可以根据类似软件的一般特性来说明是否存在不一致的地方,来确认是否是缺陷;根据用户的一般使用习惯,来确认是否是缺陷;与设计人员、开发人员和客户代表等相关人员探讨,确认是否是缺陷;合理的论述,向测试经理说明自己的判断的理由,注意客观、严谨,不参杂个人情绪。等待测试经理做出最终决定,如果仍然存在争议,可以通过公司政策所提供的渠道...
            11 12 3031
            分享
      • 51testing软件测试圈微信