背景：
随App产品不断迭代更新，给测试人员也增加了测试工作量，为了保证发布的内容确保没有问题，每次回归测试是保证发布前的最后一道防锁线，项目与迭代每次发布的时候打包平均要四次左右，每次打包都要回归测试或者回归测试的时候发现问题修改再次打包，就要再次整体回归测试，这样给测试增加了大量繁琐重复的测试，耗费了大量的时间与精力进行回归。
探索减少重复的回归测试，避免每次上限前重复的人工回归测试且保证发布版本的稳定，迫切的需要引进自动化测试来协助我们进行回归测试，最终目的是为了保证产品质量。
自动化实现过程：
1.框架的选取
常用的框架：Appium、Airtest、Robotium、UIAutomator等
选取Appium框架（相比其他框架）：开源、实现跨平台（iOS、Android）、多语言（python、Java、JavaScript、nodejs ）、丰富的定位元素方式、更高的脚本复用性等
2.框架的支撑（python+appium+unittest+ios/android）
备注：配置环境不在本章中涉及
2.1.设计自动化测试用例
自动化测试用例设计的要点：1.一个脚本是一个完整的场景；
2.尽量只做功能中正向逻辑的验证，不要考虑太多逆向逻辑的验证（除非有必要）；
3.脚本之间不要产生关联性，也就是说编写的每一个脚本都是独立的，不能依赖或影响其他脚本；
简单来说就是不是所有的手工测试都可以转成自动化测试，自动化测试是协助配合手工测试而不是取代手工测试，毕竟手工测试看一下就知道是不是正确，但是自动化需要写一堆代码验证是否正确，这样会花费大量的时间编写脚本与维护，这样也不划算例如：考试任务主要验证作答、保存进度、提交、查看解析等主要功能点，至于同个用户在不同端提交、删除题目、提交失败等不需要考虑在自动化测试中。
2.2.测试数据驱动
说完测试用例设计思路，因为每个模块或者每个功能点都有测试用例数据（标题、数据、期望值、实际值等），就不得不提数据与代码分离（数据驱动）。修改测试数据而不影响代码。
实现(Excel+OpenPyXl):
1.Excel编写测试用例：
说明：id：测试用例的ID，读取写入方便定位、title：测试用例的标题，方便阅读、data:测试用到的数据、expected:测试用例的预期结果、result：实际测试的结果、actual：运行结果（成功：PASS、失败：FALL）
2.OpenPyXl读取数据：
OpenPyXl是一个Python的模块 可以用来处理excle表格,支持读取与写入数据。
读取数据的实现：用for循环读取excel中的数据，读取后存入一个数组中。方便后面用到的时候直接调用
写入数据（测试结果的写入到excel中)：封装写入方法，执行用例后调用该方法写入数据
2.3.获取元素定位的方式
测试用例设计完成后，怎么执行呢？怎么把用例变成自动化测试呢？那就不得不提到执行自动化测试的基石：元素定位
自动化测试最根本的就是操作页面上的元素，首先我们要找到这些元素，然后才能操作这些元素。
Appium:
步骤1：
步骤2：
配置参数：platformVersion：系统版本、deviceName：设备名称、platformName：平台版本（Android/IOS)、appPackage：包文件名、appActivity：app启动的入口的activity
步骤3：获取元素定位
2.4.元素定位操作：
元素定位方式（八种方式定位）：
备注：下面常用的定位方式也是我经常用到的
1.ID定位： find_element_by_id()
2.class定位：find_element_by_class_name()
3.文本定位Android独有：find_element_by_android_uiautomator()
4.xpath定位：find_element_by_xpath()
2.5.unittest框架:单元测试框架
获取了元素定位后，怎么执行用例断言是否符合预期与生成一份测试报告呢？
unittest是Python单元测试框架，类似于JUnit框架。
unittest的使用：
1.testcase必须继承unittest.testcase
2.常用的断言：
assertEqual(a, b) a == b
assertNotEqual(a, b) a != b
assertIn(a, b) a in b
assertNotIn(a, b) a not in b
3.执行测试用例生成报告：
1.添加testcase文件到TestSuite中，执行所有的test开头的py文件。
2.添加执行测试报告，添加执行标题、执行人员等，执行完成后存放的位置。
3.执行所有的testcase文件。
备注：HTMLTestRunner要下载引用，百度一下就可以找到
执行完成后的测试报告：
2.5.PO（Page Object）设计模式：
走到这一步后，实际上自动化测试已经走了90%（😁心里想着真是不容易呀😂），知道怎么获取元素与元素定位后，再通过unittest框架就可以实现自动化测试了,那为什么还引用PO设计模式呢？那请思考下面的问题😱？
问题：自动化测试就是通过大量的元素定位来操作，随着自动化测试的丰富，测试套件的增长，脚本也变得越来越多。如果我们需要维护10个页面，100个页面？那么页面元素的任何改变都会让我们脚本维护变得繁琐复杂，而且容易耗时易出错（干货来了）。
那么怎么解决呢？
UI自动化中，常用的一种方式，引入PO：页面对象模式来解决，PO能让我们的测试代码变得可读性更好，可维护性高，复用性高。
实现：在PO下，应用程序的每一个页面都有一个对应的page class,每一个pageclass维护这该元素集和操作这些元素的方法。
例如：进入网校的模块
元素定位：UI-page
测试执行：testcase
在testcase中调用joinschool中的方法，使得testcase中只有逻辑，没有大量的元素定位业务，假如进入网校界面中的元素修改，不用修改逻辑代码，只修改定位元素即可
优势：
1、PO提供了一种业务流程与页面元素操作分离的模式，这使得测试代码变得更加清晰。
2、页面对象与用例分离，使得我们更好的复用对象。
3、可复用的页面方法代码会变得更加优化
4、更加有效的命名方式使得我们更加清晰的知道方法所操作的UI元素。
总结：
以上就是APP实现自动化测试的思路（web自动化除框架不同，思路大致相同），看下来实现起来并没有那么难，但是难的是以后花费时间去维护自动化代码🙃。
但是APP自动化测试是趋势，执行自动化测试可以让测试有更多的精力来关注复杂场景，做更多更深层次的测试，特别是自动化回归测试来提高效率是很明确的目标。
😜加油吧 新时代的农民工🤪
