app-UI自动化测试项目代码框架

一、项目框架

1. 项目分析

1.1 测试用例

1、需求说明分析
已有的手工用例时，在结合自动化测试框架，来开发自动化用例时，则优先分析手工用例，再定出自动化测试的结构

1.2 app界面

2、界面分析
可以分别从模块层、界面层及交互层三个方向进行分析。

模块层
模块层是对 app 应用的整体结构划分，如登录模块、注册模块、主界面模块，个人信息模块等，应用尽可能减少代码耦合，降低关联依赖性，而不至于牵一发而动全身。

界面层
界面层是 app 应用的基础界面，可以分成原生安卓界面和混合 Web 界面。原生界面的话，可以通过工具快速抓取界面的元素或是控件信息，方便在自动化测试脚本中针对性的对元素或是控件进行检查或是点击；
混合 Web 的界面是嵌入了一个 Web View 的控件，在这个控件上加载了 Web 的链接，从 app 应用测试的角度，是无法获取 Web 界面的元素或是控件信息的。
将两种不同的界面分到不同的模块分别进行测试

交互层
交互层指的是 app 应用在使用时，不同的预设前提或不同的步骤下，一个界面跳转到其他界面的过程。

数字标牌apk是混合web界面
如何判断是否webview？
1，可以通过断网看，原生的是会继续显示原来已经打开过的内容。webview会显示网络连接失败。
2，可以看加载条。当网络慢的时候会非常明显

1.3 专项测试

3、专项分析
接口测试、回归测试、兼容性测试、布局边缘测试等等。这些都算是专项测试的范围，接口测试这个部分可以转化成自动化脚本，兼容性测试、布局边缘测试等借助手工。

2. 架构分析

4、架构分析
实现架构可靠性，要求数据和脚本分离、业务与实现的逻辑分层

数据与脚本分离
数据与脚本分离，通常会采用关键字驱动测试技术对测试用例的脚本和测试数据进行分离，在自动化测试过程中，从测试脚本中将数据分隔出来，实现测试脚本的参数化，增加了测试脚本的可维护性。

业务与逻辑分层
业务与逻辑分层，分层之后，脚本代码的表层只留下业务的部分（测试逻辑），中间的（支撑）逻辑的部分可以通过代码调用，放在另一个统一管理的逻辑代码的脚本中。

2.1 架构实现

脚本架构设计：
这里设计四层结构，分别是 UI 层、公共库层、脚本执行层、静态数据层

1、UI 层设计
可设计 UI 层为只负责实现界面元素定位，其他层来调用元素。每个元素都由封装的方法统一定位，采用数据驱动模式，将元素的定位方法同元素的数据分隔开来数据分隔开来。

UI 层可分成基础 UI 层、模块 UI 层、界面 UI 层，分别进行管理。
基础 UI层一般是 app 应用大部分界面公用的元素，几乎不变动；（菜单）
将 app 应用按照模块分类，模块 UI层中一般是各模块及向下的界面的公共元素，版本迭代时会有少量修改；（二级菜单）
界面 UI 层针对各个独立的界面元素，版本迭代时根据情况会有适量的修改。（显示）

2、公共方法层设计
测试用例经常用到的前提和模块，进行公共方法层的设计，主要想法是：构建一个方法的基础类，在该类中对界面操作或是逻辑处理的基本方法进行封装，也可以根据需要在其中创建逻辑动作特定的方法，脚本执行层直接调用这些方法即可

共方法层可分成基础公共方法层、模块公共方法层、界面公共方法层，分别进行管理。
基础公共方法层一般是 app 应用大部分界面公用的方法，如点击、Toast 方法等，几乎不需要变动；
将 app 应用按照模块分类，模块公共方法层中一般是各模块及向下的界面的公共方法，版本迭代时会有少量修改；
界面公共方法层针对各个独立的界面的独立方法，版本迭代时根据情况会有适量的修改。

3、脚本执行层设计
在脚本执行层中，调用 UI 层定义的界面元素和公共方法层中实现的逻辑方法，及静态数据层本地存储的静态数据，来完成一条完整的自动化测试用例脚本。
综合上述，可将脚本执行层分层三部分，一是脚本启动，里面是脚本初始化环境的内容；二是脚本执行，这里是脚本执行步骤和验证结果的主题部分；三是脚本结束，这里是对脚本执行的收尾及测试环境的还原。

4、静态数据层设计
静态数据层主要存放一些本地静态的固定数据，如连接手机的数据信息，ip 信息部分会涉及到部分账号密码信息等，根据实际情况静态数据层分成启动数据层、接口数据层、其他数据层分类管理脚本相关的数据信息

2.2 关键字驱动

关键字驱动是一种基本的自动化测试框架，它是对数据驱动的逻辑扩展，把测试逻辑用关键字的形式，封装在数据脚本文件中。
-它将界面上的测试对象的元素一一映射，分别对应单独的逻辑对象

PO模式：
Page Object 模式(后续简称 PO 模式)是将界面元素的定位与元素的操作行为封装成一个 Page 类，PO 模式是把每个界面看作一个对象或是一个类。
Page层：类的属性(各个界面元素的定位)以及类的方法(各个界面元素的方法)，首先可以封装成一个 Base Page 类，该基本类可以封装一些基本方法，后续新创建每个 Page 类都可以继承 Base Page，每个新建的 Page 类都存放自己的私有方法
Class basepage()（共有属性方法） class loginpage()(私有方法) class loginui()（元素数据）
在实现的执行脚本中，调用登录loginpage即可

项目分层：
项目基本脚本主要在src文件夹下，其中可分四个部分：case作为脚本执行层，date Manage作为数据管理层，ui Manage 是 UI 属性层，utils 是公共方法层。
case 目录下存放用例的执行脚本，根据具体的项目需要可能在其中再延申创建更多的分支。app 应用的主界面有四个主 Tab，分别为首页、发现、管理、我的，则 case 下可以创建：01first、02discover、03manage、04mine。
date Manage 目录下存放数据文件，可分为 base Data 基础数据，存放项目中公共的静态数据。
ui Manage 目录下存放控件的 UI 属性，base UI 基本 UI 层，存放公共控件的 UI 属性；modular UI 模块 UI 层，存放项目按照模块划分后，各个模块的 UI 属性；page UI 单界面 UI层，存放单个界面自己独特的 UI 属性
utils 目录下存放项目需要调用的公共方法，集合上一节基本操作方法封装，utils 目录一级目录分为：base 存放常见的固定方法、basic 存放项目操作层级的方法、tool 存放工具类方法
自动化测试脚本都在 case 目录下，对于专项测试，可以在 case 目录下新建 05special 分支

设备初始化方法的封装：
把设备信息封装在hidevices.py里，并返回连接设备。在使用时直接import hidevices调用即可。
设置测试用例默认模板：
注释和unittest用例，注释：时间 项目 板卡 版本 测试人员 开发人员 测试模块 测试步骤 测试结果

1.3. unittest优化

1、unittest优化：
unittest优化 工作流程：编写 Test Case 用例，由 Test Loader 加载 Test Case 到 Test Suite，然后由Text Test Runner 来运行 Test Suite，最后将运行的结果保存在 Text Test Result 中

类的前后置和函数的前后置，区别在于类的前后置在执行用例的时候，只会执行一次，且需要在方法前添加映射—@classmethod；函数的前后置，会根据用例中有多少函数方法，就执行多少次。
set Up Class()：类的前置—测试脚本开始时执行，主要用于启动 app 应用以及部分用例会涉及到预设的前置条件。
tear Down Class()：类的后置—测试脚本结束时执行，主要用于关闭 app 应用以及把测试环境还原到最初的状态。
set Up()：函数的前置—测试脚本开始时执行，可在其中编写一些用例初始化以及前置条件，如登录、获取固定参数等操作。
tesr Down()：函数的后置—测试脚本结束时执行，可在其中编写一些用例后置条件，如退出 app 应用及测试数据的初始化。

二、代码架构

所以本项目，采用上述思想，

case：存放所有的用例，可根据项目大小包含模块类、页面类、功能类等细分；
data：存放所有数据，可根据项目大小包含静态数据、页面数据、输入数据等；
debug： 存放调试脚本，可验证所选模块的可行性；
file： 存放第三方文档，例如app升级文件、素材、第三方网站等；
report：存放测试报告，例如测试log、测试图片、视频等；
utils：存放测试方法，例如设备初始化方法、公共方法等；
init.py:：每层可包含init来初始化；