网站建设合同英文模板下载,wordpress 添加表格,杭州上城区网站建设,中国娱乐公司三大巨头摘要#xff1a;在我有限的软件测试经历里#xff0c;曾有一段专职的自动化测试经历。 接触自动化
那时第一次上手自动化测试#xff0c;团队里用的是Python#xff0c;接口自动化测试的框架是requestsExcelJenkins#xff0c;APP自动化测试的框架是Appium。
整个公司当…摘要在我有限的软件测试经历里曾有一段专职的自动化测试经历。 接触自动化
那时第一次上手自动化测试团队里用的是Python接口自动化测试的框架是requestsExcelJenkinsAPP自动化测试的框架是Appium。
整个公司当时有一款已有的APP因此在试用期内我的任务是完成对已有APP的自动化脚本编写和调试。
记得当时刚开始去很没有经验在跟功能测试同学了解了业务之后只顾埋着头部署环境突然有一天测试主管问我是否要输出一份自动化测试用例。我恍然大悟于是把功能测试的用例拿来参考了一下对用例做了一次筛选输出了一份自动化测试用例现在回过头看当时的做法真的很草率既没有一个自动化测试计划也没有对自动化用例做评审只知道功能测试同学的痛点就是迭代太快回归来不及做。
用例输出后大概花了一个月的时间完成了环境部署和基本用例脚本的编写那时候大概实现了四五十个场景并且完成了自动发送测试报告。剩下的两个月我就一步一步的将场景扩充为二百多个。
其间也遇到了一些问题比如登录图形验证码的获取不过使用OCR图形识别很快就得到了解决同事也有使用云打码一类的平台。
最大的一个问题是当APP版本更新迭代后固定页面所有的id、class等属性都会变化因为这些都是写死在代码里的如果要更改意味着每个page都要更改工作量非常之大而且获取这些属性还需要借助一些工具如UI AuTomatorviewer 、Appium自带的Inspector。
在忙碌了一段时间后先找到一个安卓开发跟他排查了一下他也找不到问题所在后面又找了另一个开发他排查之后发现是安卓混淆打包的问题他给我出了一个不做混淆打包的APP这才解决了这一问题。
另外一个比较大的问题是APP自动化测试的运行时间非常久我们两三百条用例如果加上失败重试大概要跑四五个小时而且还会出现中间脚本出错运行停止的问题。
记得一个印象比较深的事情是我们第二天要发版了头一天下班前我开始跑脚本等到晚上我一直没有收到测试报告的邮件于是晚上十点多赶回公司发现自动化脚本已经停止了。 对于时间久的问题后面我尝试引入UI AuTomator2以下简称u2框架来代替Appium毋庸置疑u2在执行速度上有很大优势。
我曾经对比过这两个框架同一个场景Appium需要耗时60多秒的u2只需要20多秒足足节省了三分之二的时间。
但随之而来新的问题是u2不太稳定Appium中查找元素有用到显式等待、隐式等待和强制等待而u2中看似不需要这些实际上多跑几遍场景就会发现u2执行太快会找不到元素因此还得手动加上强制等待。这样一来时间并没有节省多少。
这个问题当时没有得到解决反而是在我离职后的一段时间里通过学习pytest-xdist的文档发现pytest-xdist可以基于ssh和socket来实现分布式执行。
举个例子假如有200条场景同时启动2个执行机那么就会往执行机-1上推送100个场景往执行机-2上推送另外100个场景最终两个执行机的测试报告会集成为一个报告。这样的解决方案如果当时能应用到实践中那么APP自动化测试时间过长的问题会得到完美解决唯一需要注意的是每个场景要独立不能相互依赖。
话说回来APP自动化测试做下来好像没有产生多少收益因为只有我一个人开发和维护所以到了维护阶段就显得耗时耗力特别是本来一个固定的页面改了或者中间插入了一套新的逻辑就意味着相当多的页面需要调整。
第二次接触项目
差不多这样做了几个月后公司开始立新的项目新的项目一开始就下决心要做接口测试因此我又介入到这个项目中参加立项会议、参加技术评审了解了要做哪些并且接口文档怎么管理接口怎么定义等等之后就开始了新项目的接口测试。
那个阶段使用requests读取Excel的方式在接口不多的时候还挺方便因为代码框架比较固定只需要Excel里修改参数。
但随着接口越来越多也意味着接口之间的依赖越来越多Excel管理简直就是灾难在Excel里要理清不同接口的依赖关系是非常头痛的一件事。
后来我使用Postman做了一些快速测试等待时间充裕的时候再慢慢把整个主流程的接口测试加上。在接口测试阶段前前后后发现了一些问题但很大的不足是没有解决Excel存储数据的问题和没有做数据正确性的校验。
而且我们还是和支付相关的业务这使得接口测试结果只能保证服务是正常的返回码是正常的但是数据是否正确无从得知。
直到后来自动化团队换了一批人新来的同事开始推行Java栈使用SpringboothttpclientMaven来作为接口自动化框架基本舍弃了之前的Python自动化脚本。
那几个月好几位同事投入到同一个项目的接口自动化脚本的编写中对比之前我一个人负责两个项目的自动化情况的确好了很多。
这个自动化也是基于场景的有做正常和异常输入的校验以及最后的入库检查脚本量非常大所有异常场景的请求数据和期望结果都是入库的后续请求的时候先从数据库拿到请求数据发送请求得到响应结果再和数据库的期望结果做比较正常场景需要手动写逻辑响应结果里重要字段的值和数据库里的值做比较。
那个时候考虑了很多前端无法测到的复杂的场景并发、幂等之类的因此发现的缺陷更有意义一点但是维护成本依然比较高。 自动化是什么
最近的一两年我有时会想到自动化测试是什么自动化测试本来是为提高测试效率而生有时候使用不得当却成为测试活动中的累赘。
但不可否认的是自动化测试仍然是行之有效的区别只是使用的动机和使用的方式在我看来做好自动化测试需要规避以下几点
不要为了自动化为自动化
自动化测试不能基于KPI而要看当前的项目适不适合做自动化有没有足够资源的投入和外部团队的配合。
自动化不是万能的
不要贪多求全妄想所有的测试场景都能通过自动化实现尤其是更新迭代快的项目。能把稳定的功能实现并且做好回归 已经足够了。
自动化的场景
一种是基本场景另一种可以是前端无法实现的场景。
而对于接口中无穷无尽的字段进行严苛的异常校验来保证足够程序足够健壮有时候反而没有那么必要。
因为开发周期短的公司一周好几个版本开发根本就没时间对一些不太重要的字段做异常处理当然重要字段的类型、长度、非空校验等还是要做。
对自动化的认知
有些同行认为自动化就是为了发现缺陷的但是自动化发现的缺陷根本比不上功能测试发现不了缺陷的自动化就没有意义吗
事实并非如此尤其是一些回归测试的自动化一方面是为了提高效率一方面是为了增强上线前团队的信心。
团队人才的培养
遇到了一些公司好不容易做起了自动化做得也不错等到负责人离职之后就没人维护了然后再招一些自动化测试人员另起炉灶反反复复归根结底是没有人做技术备份。
很多测试同学虽然也意识到自动化的重要性。但由于技术基础薄弱缺乏系统性学习和过来人的指点又缺少全流程的实战演练环境很难在短时间内自学成才达到企业的用人要求。还有不少同学卡在编程语言/基础自动化测试技术这一关更不用说掌握高级自动化实战思维和经验并灵活应用了。
【自动化测试学习建议】
我的自动化测试之路一路走来都离不每个阶段的计划因为自己喜欢规划和总结所以我和朋友特意花了一段时间整理编写了下面的《自动化测试工程师学习路线》也整理了不少【网盘资源】需要的朋友可以文末免费获取网盘链接。希望会给你带来帮助和方向。
1. 自动化测试必备Python编程内容 2. Web UI 自动化测试基础内容 3. Web UI 自动化测试实战内容 4. APP UI 自动化测试基础内容 5. APP UI 自动化测试实战内容 6. API 接口自动化测试基础内容 7. API 接口自动化测试实战内容 8. CI/CD持续集成专项技术 9. 自动化测试框架实战技术 上面就是我整理出来的一份自动化测试工程师技术路径图。希望大家能在这个成长过程中收益良多。全方位提升测试技术建立一套属于自己的技术体系。帮助大家不断学习和优化技术栈跟进先进和主流的测试技术给到大家带来的不仅仅是技术和薪资的提升更多的是改变测试人在IT技术领域的地位和心态拔高测试行业的技术深度。
最后这里有我建立的一个专门交流软件测试方面问题的学习群里面也有很多大公司的技术大牛。很多时候技术大牛的几句话就会让我们醍醐灌顶少浪费时间如果想要多跟有经验的人学习就找我加入我的软件测试交流裙194117263以后有工作的内推机会都相互推荐一下毕竟我们是关系社会。
