APPUI（Appium）自动化测试

背景：

随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自动化测试是趋势，执行自动化测试可以让测试有更多的精力来关注复杂场景，做更多更深层次的测试，特别是自动化回归测试来提高效率是很明确的目标。

😜加油吧 新时代的农民工🤪