项目说明
原项目基于ATX-Server的UI自动化测试框架，可以实现多设备的并行测试，并生成统一的测试报告。测试用例执行部分基于unittest。
运行方法
· android：修改TestSuite_*下的config下的Server地址为atx-server2的URL,token填写正确后,就可以正常运行了。
· ios：在设备接入到atx-server2之后, 可以参照demo下的wda_demo.py可以运行简单的网易云音乐的脚本操作。（ios版本受限于设备原因，并没有尝试过）
项目工程结构
工程结构如图所示：
· apk - 用于存放apk文件
· chromedriver - 用于存放Chromedriver文件
· demo - 原工程的demo，删除不影响功能
· Image - 原工程展示用的Image文件，删除不影响功能
· Monkey - maxim_monkey模块内容，这块功能还不是很清楚
· mydemo - 存放单个调试用的demo，删除不影响功能
· PageObject_* - 存放对应工程的页面对象，PO模式的核心。在该目录存放各页面PO元素的操作后，即可在测试用例中直接调用，大大降低用例编写及修改难度，节约重复编码时间。如图所示为物业城市的PageObject。
· Public - 通用的主要逻辑控制文件
· TestSuite_* - 用于存放对应工程的测试套件。如图所示为物业城市测试环境的测试套件。测试套件必须以TestSuite_开头，unittest将据此获取测试用例。
· .gitignore - git的忽略文件，此文件记录了不列入git管理的文件
· git git自动生成的文件
· README.md - 原项目的Readme说明文档
· run_all_case.by - 运行该项目内所有用例
模块说明
主要功能模块 Public
· Devices_new.py - 获取atx-server上特定设备（get_online_devices()）、或config.ini下devices IP列表的在线设备（get_devices()）、有线连接电脑的设备自动连接u2（connect_devices()）
· BasePage.py - 用于设备的初始化 u2.connect 以及一些公共模块的封装
· chromedriver.py - 和Ports.py 结合使用，启动chromedriver以便实现u2的- webview操作
· Casestrategy.py - 获取指定路径下的testcases
· Decorator.py - 有@testcase、@teststep这样的装饰器用例执行日志打印、错误后的处理（截图）
· Report.py - 对生成的报告的一些操作，备份Testreport的报告到TestReport_backup下、多设备统一报告的生成、报告的文件夹压缩、报告保留数量管理
· Test_data.py - 在执行测试前的测试数据的生成，会在Plubic下生成data.json，测试执行的时候各个设设备更具自己的serial获取对应的测试数据
· Drivers.py - 设备的获取，初始化准备，测试执行都是在这里完成的
· RunCases.py - 存放测试报告/日志/截图的路径的生成，以及最终通过HTMLTestRunner来执行用例
· config.ini - 一些需要用到的数据，atx-server地址、测试设备的ip、测试数据等。此文件在此工程Public中已被删除，放到各测试用例套件TestSuite里，以分别支持不同测试项目的不同设置。
· Readconfig - 读取各测试套件的config.ini文件
页面对象模块 PageObject_*
此模块用于存储编写的各测试项目的PageObject。
如图所示的是作为示例的两个PageObject文件login.py和Home.py，分别存储了登录页的PageObject和主页的PageObject。当用例中有需要用到该页元素时可以直接从此调用该元素的点击操作，不需要再重新做一次检查元素Xpath步骤。
PageObject完备时用例编写会变得十分方便快捷，用例编写人员只需要调用相应点击操作函数即可轻松完成一个用例编写，并且当页面元素Xpath发生改变时也可以在此处快速地修改而不影响用例，即PO模式。
每个测试项目可以有一个自己专有的PageObject_*目录。相关的测试项目也可以使用同一个，例如测试环境的项目和生产环境的项目，它们分别使用不同的测试套件和测试用例，但可以共用PageObject。
项目测试套件模块 TestSuite_*
TestSuite_*是某个测试项目的测试套件。里面包含了测试操作集action，测试用例集TestCase，报告目录TestReport_History，项目配置文件config.ini，测试用例运行入口runcase.py。
action
测试操作集。存放了测试的具体操作，用以支持不同的测试用例调用。
TestCase
测试用例目录。
· 测试用例文件需以test_开头，unittest模块才可读取并运行。
· 用例按照数字字母序加载，而不是按照写入顺序。
· 测试用例目录下也可以再新增目录进行测试用例集的划分。如图所示根据不同用户视角划分了几个用例集，用例集内的用例文件以功能来划分，例如安装，登录，登出等。
如图所示，测试用例文件内函数通过识别不同装饰器执行一些操作。
· @setUpClass 装饰器为测试类的setup装饰器，将在每个测试用例类执行前执行一次，可以用于进行测试前置操作。
· @teardownclass 装饰器为测试类的teardown装饰器，将在每个测试用例类执行后执行一次，可以用于进行测试收尾操作。
· @testcase 装饰器用于标识测试用例函数。被标识的函数会被当做一个测试用例运行。
· @unittest.skip 装饰器是unittest自带的装饰器，用于标识需要跳过的测试用例，被标识的测试用例不会执行。
除此之外还有很多其他可用的装饰器，包括原工程在Public.Decorator中封装的以及unittest自带的装饰器，需要使用时可以自己查一下。
TestReport_History
用于储存测试报告。每次运行将生成一份包含各设备测试结果的测试报告，测试报告超过一定数量时将自动删除最早的，默认保留10个。测试报告保留数量可以在config.ini里修改。
config.ini
一些需要用到的数据，atx-server地址、测试设备的ip、测试数据等。
· method只能选择一种，不能混用。例如不能同时获取分别使用USB与IP方式连接的设备。
· 测试数据使用“|”做分隔，需要注意每一格的数据与设备一一对应。如图所示例子，第一台设备数据即为以“|”分隔的第一列数据。
runcase.py
该测试套件的测试用例运行入口。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
