从快手薅羊毛说起之Appium/原生XCUITest/原生UIAutomator菜鸟级入门

1. 需求

像这样进入某一个账号(一般是发的视频时间都比较长的号),每个视频停留60s,然后自动往后翻,赚取金币,小弟两个账号已经小赚500了,嘻嘻。

2. 实现

2.1原生XCUITest

首先配置好xcode开发环境。通过xcode建立新项目,选择Single View App后

勾选UI Tests

我们就可以在后缀UITests的文件夹下快乐的编写我们的UI自动化代码了

这儿我偷了个懒,需要程序打开程序后我们手动进入某一个账号,接下来就倒杯肥宅快乐水等着哗哗收钱了。

其实有兴趣可以让进入某一个账号这一个过程也自动化起来。最后选中这个Target执行Command+u就可以了。

2.2 原生UIAutomator

首先配置好AndroidStudio开发环境。接着就是我们熟悉的傻瓜式无脑操作,先建立一个空白的AndroidApp项目.

接着就是在androidTest目录下撸我们的代码。

直接在指定设备启动我们的测试用例就行了。

2.3 Appium之iOS

推荐配置Appium+iOS环境的文章:

iOS 自动化测试踩坑(一): 技术方案、环境配置与落地实践

iOS 自动化测试踩坑(二):Appium 架构原理、环境命令、定位方式

Appium主要是借助WDA对ios设备进行UI控制。启动Appium Server后,此处利用pycharm编程。

2.4 Appium之Android

推荐配置Appium+Android环境的文章:

Mac下配置appium+Android​

Appium会自己装app到手机上接受Appium server的http协议下的信息,从而对安卓设备进行UI控制。

3. 发现问题与解决问题

原生的实现没遇到什么奇怪的错误。倒是在Mac下使用Appium的时候出现了几个问题值得思考。

3.1 问题1(ios出现)

这个一般是之前非法推出测试用例导致了8100端口没有正常kill掉,导致下一次启动测试用例无法让iphone上的端口映射到电脑上的8100端口。kill掉占用8100端口的进程即可。

3.2 问题2(ios出现)

socket hang up,着实是一个非常蛋疼的问题。本着用例程序访问Appium sever,Appium sever再访问WDA,WDA把指令推到iphone上的顺序,猜想可能是sleep时间太长,session在appium上过期了或者在wda上过期了。又或者是sleep时间太长,iphone把手机上的wda进程给杀死了。于是乎尝试了以下几种解决方案:

3.2.1 提高session在appium server的存活时间

实施:在capabilities中设置一个较长的newCommandTimeout时间。

结果:还是会出现socket hang up

 

实施:直接改源码中的NEW_COMMAND_TIMEOUT_MS参数,设置个较大的数值,位置有四处:

/Applications/Appium.app/Contents/Resources/app/node_modules/appium/node_modules/appium-base-driver/lib/basedriver/driver.js

Applications/Appium.app/Contents/Resources/app/node_modules/appium/node_modules/appium-base-driver/build/lib/basedriver/driver.js

/Applications/Appium.app/Contents/Resources/app/node_modules/appium-base-driver/lib/basedriver/driver.js

/Applications/Appium.app/Contents/Resources/app/node_modules/appium-base-driver/build/lib/basedriver/driver.js

改完重启Appium。

结果:还是会出现socket hang up

3.2.2 提高seesion在wda上的存活时间

实施:修改源码中wdaConnectionTimeout参数,设置个较大的数值,位置有两处:

/Applications/Appium.app/Contents/Resources/app/node_modules/appium/node_modules/appium-webdriveragent/build/lib/webdriveragent.js

/Applications/Appium.app/Contents/Resources/app/node_modules/appium/node_modules/appium-webdriveragent/lib/webdriveragent.js

改完重启Appium

结果:还是会出现socket hang up

3.2.3 缩短sleep时间

实施:每隔sleep 15秒就滑动

结果:没出现socket hang up

 

实施:每隔15秒点击一次屏幕,保持连接,每隔60s滑动

结果:没出现socket hang up

最最最最奇葩的是,隔了一天,直接sleep 60秒在iphone上又不会出现socket hang up了。不知道是不是这期间重启了电脑,修改源码生效了。

作为半桶水选手的代表人物,感觉自己几乎就是凭着自己的第六感在对server部分的源码指手画脚,至于最后到底能不能生效,只能听天由命了。

4. 总结

复杂的框架在拥有扩展性和通用性之后,也让测试人员丧失了对细节的把控。特别是当出现一些奇奇怪怪的bug时,追根溯源的过程中考验的除了测试人员的编码能力还有耐心。Appium的技术架构天生具有的分布式基因确实非常吸引人去使用它,但是当你需要对App的每一处细节把控的时候,并且让测试人员更能够融入到App源码的编写过程中去,原生的测试工具确实更加有魅力,毕竟原生测试技术可以流氓似的直接调用开发人员的源码。

目前来看Appium和原生相比各有优劣,特别是H5横行的现在,即便是Appium的分布式方案也可以被原生测试工具+分布式server的方式复现,appium和selenium的暧昧关系势必会让它在UI自动化测试占有一席之地。

所谓存在即合理,等正式踏入工作之后,自己会进一步提炼对工具场景化的思考和老铁们分享和交流。

广度思考,深度搬砖。测试不易,与君共勉。

 

猜你喜欢

转载自blog.csdn.net/qq_23912871/article/details/106998779