自动化平台搭建之代码结构总览

自动化框架总体工程结构

  之前写了一篇《自动化平台搭建之定制log系统》，确切说是还没写完。由于自己能力有限，自底向上进行搭建框架时很容易陷入到一个模块的详细实现中，所以尝试锻炼一下自顶向下的思维方式，先把整个框架搭起来，然后再对每个模块的具体实现进行详述。这一系列博客主要作为自己的学习笔记，初学者欢迎一起探讨进步，大神请包容指教。
  我工作用的更多的是Appium，但我在这一系列博客中打算用Uiautomator2进行实践，这样，我的思维受到原有架构设计限制的程度会大大降低。另外上一篇关于log定制的博客我后续会补上。
  先看下我的整体工程结构：

各个模块承担的责任如下：
1. applications
  借助Android系统分层设计思想，这一层主要是我们的用例开发层，最主要的就是cases目录下的用例集，在这里我们实现用例的自动化开发，并有效的组织起来。具体目录如下图所示。其中的Version1目录代表我们的软件版本或项目的迭代版本，版本下面又分为各个模块，对应项目的各个子模块， 该子模块可以是一个独立app，如图中的android原生时钟应用，也可以是系统中的一个独立模块。这样分，我们可以针对不同项目版本的不同模块，清晰地划分职责，有效提高自动化用例的开发和维护成本。

  每个模块下又分为不同的测试场景，所以针对不同的测试场景，我用scene这种字样的python文件组织起来，每个场景中有一个继承了UiTestCase的测试用例类，其中集中了该场景下的所有测试用例，如图所示：

  另外在应用层中还有datas、logs和reports三个目录，根据名称就可以猜到具体用处，就不细说了。
2.driver
  这一层之所以给它取名为驱动层，是因为它是Uiautomator2提供的一些基础接口，我们借助这个平台及其接口才能完成一系列自动化操作，我们顶层的所有自动化实现都要靠这层来驱动才能完成。这里我打算对Uiautomator2提供的连接和会话功能类进行简单的二次封装，方便管理设备的连接和会话跟踪，详细实现后面再讲。
3.framework
  这一层我们作为整个自动化平台的框架层，对于测试开发工程师或自动化工程师来说，是必须掌握的，我们这里开发出来的API和一些库调用，都是提供给applications的用例开发者进行调用的。框架层我们用到了PageObject设计模式。
  在这一层里，我们需要实现每个模块公共接口，如common文件夹，里面的目录结构对应cases，但还有一个顶层common，这个类中抽象出对整个Android系统的公用接口，其他模块级别的公共类都继承这个顶层公用类。
  还有一些组件类，如client对应一个设备客户端的抽象，server和client是一一对应的关系，这样抽象是为了以后拓展多个设备并行跑用例时不至于造成混乱；另外，UiDevice对应一台手机的抽象，里面有手机基本信息等内容，如下所示：

里面我简单的写了一些属性，具体可以根据自己的需要扩展一下这个类。UiConf主要管理启动一个设备后，对它的配置信息的汇总，比如各种路径管理，用例管理和加载，和设备信息管理等，简单demo如图所示：

  剩下的就是我们熟悉的page，这里我们利用PO模型对app的每个页面的共用接口进行了抽象。如图所示是google原生时钟各个页面的抽象类：

4.lib
  这个文件夹预留的，因为我们我们在进行自动化开发时，可能借助强大的三方库或自己开发的库，比如图像对比、排序比较算法、机器学习等等，这个目录和util的区别是，这里存放重量级偏算法类的工具库，util中存放的是诸如文件操作、数据库操作等轻量级简单的封装类。
  好了，以上即是我对整个自动化平台搭建的简单demo工程，后面每个模块的实现都会基于这个小框架，可能根据具体情况进行一些改动，但大致方向不会变。