手动测试做久了，总会想要尝试接触些新技术，UI自动化就是一个非常容易尝试的入门砖。
小白也能做，相信自己放手去试吧。
一、为什么需要做UI自动化
1.想一想，为什么需要做UI自动化
可以从解决问题的角度出发，想一下在工作中，哪些工作重复性非常高？
最最常见的重复性工作，那就是：功能回归测试啦。
现在市面上的大小公司都在推敏捷开发，几乎都是2周/3周发一次版本。
即2周/3周跑一次回归测试，而且Android和iOS都需要跑一次，即便分在个人头上的回归内容很少，其实也占据了大家大量时间。
当然，并不是说UI自动化只能在回归测试阶段发光发热，在测试的任何阶段都可以尝试跑UI测试脚本，可以根据公司需要调整运行阶段、运行次数，并且可以随时修正脚本内容。
2.做UI自动化可能需要克服的阻力
在一个技术氛围偏低的团队，如果想要尝试新技术，有可能会比较难以迈出第一步。
这时候你需要给出充足的理由，再开始跟领导沟通。
第一步，先做个demo，单纯的启动APP，跑通几个简单的主流场景。
第二步，整理一份简略版主流程测试点，作为后续使用UI自动化来实现的内容。
第三步，去找领导沟通吧
（1）有明确的启动实例，有明确待实现的主流程测试点，想清明确可以运行的测试阶段
（2）邀请组内同事一起加入，和团队伙伴们一起进步
（3）找迭代中闲暇的时间，梳理本期的新流程，并编写新脚本
相信有明确目标，有实例支撑，得到领导的支持应该不会太难。
二、UI自动化可以怎么做
1.常用工具
目前比较常用的有：Appium、Airtest、AppiumStudio
建议选择其中一个长期使用，推荐使用：Appium。
2.常用脚本语言
Python、Java均可，如果是零基础小白的话，Python上手可能会更快。
3.平台区分：iOS、Android
4.集成jenkins
如有稳定项目后，可以尝试集成到jenkins上，定期运行。
5.一个简单的UI自动化例子（iOS版本）
因为目前网上已有巨量的Android 自动化例子，这里给一份iOS 真机的示例。
运行iOS自动化，需要有一台mac，资金不充裕的话，建议入macmini。
（1） 启动APP
caps = {}
caps["platformName"] = "iOS"
caps["platformVersion"] = "13.1.3"
caps["deviceName"] = "xiaobai"
caps["xcodeOrgId"] = "xxx" # 需要跟开发同事要一份
caps["xcodeSigningId"] = "iPhone Developer"
caps["automationName"] = "XCUITest"
caps["startIWDP"] = "true"
caps["udid"] = "auto"
# 真机专用包，如/DerivedData下没有app，需要xcode上build一下
caps["app"] = "xxx"
（2）定位元素
iOS定位元素方式主要有以下几种：
ios_predicate、accessibility_id、class_name、xpath
以下的例子里使用的是xpath，查找效率十分低下。
在实际使用中大家可尝试使用ios_predicate。
cls.driver.find_element_by_xpath("//XCUIElementTypeButton[@name='跳过']").click()
（3）断言
推荐使用：Assertpy
pypi地址：https://pypi.org/project/assertpy/
github地址：https://github.com/ActivisionGameScience/assertpy
（在readme里，有相当详细的使用方法）
这个三方库库，实现了多种数据类型的断言方法。
不过对小白来说，可以单纯先尝试判断元素是否存在。
assert_that(self.find(By.NAME, "啦啦)).is_not_none()
6.还可以尝试什么
（1）可以考虑设计更复杂，更长链条的场景，但这点需要考虑各个公司的具体业务场景，可挖掘的业务点很多，可以拉同事一块讨论。
（2）UI自动化和接口数据校验拆开做，混杂在一起容易做的庞大冗余。
（3）可以在跑UI脚本过程中，尝试收集手机性能数据，标准可以暂定：首次收集到的数据，或者竞品的数据，不过竞品数据会比较难拿到。
请关注 私信回复：“测试”就可以免费拿到Python测试开发课程大纲及软件测试学习资料，快速让自己变强！
