从快手薅羊毛说起之Appium/原生XCUITest/原生UIAutomator菜鸟级入门
1. 需求
像这样进入某一个账号（一般是发的视频时间都比较长的号），每个视频停留60s，然后自动往后翻，赚取金币，小弟两个账号已经小赚500了，嘻嘻。
2. 实现
2.1原生XCUITest
首先配置好xcode开发环境。通过xcode建立新项目，选择Single View App后
勾选UI Tests
我们就可以在后缀UITests的文件夹下快乐的编写我们的UI自动化代码了
这儿我偷了个懒，需要程序打开程序后我们手动进入某一个账号，接下来就倒杯肥宅快乐水等着哗哗收钱了。
Swift实现：
Object-C实现
其实有兴趣可以让进入某一个账号这一个过程也自动化起来。最后选中这个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自动化测试占有一席之地。
所谓存在即合理，等正式踏入工作之后，自己会进一步提炼对工具场景化的思考和老铁们分享和交流。
广度思考，深度搬砖。测试不易，与君共勉。