自动化测试—自动化设计思路

自动化系统设计

1 分层的目的

1）用户在在玩ui元素与行为操作，各个page之间相互不干扰，需要分离

2）新增用例的时候，每个用例设计都需要考虑配置信息、页面元素信息、行为操作、具体流程设计。不同用例之间的配置信息、页面元素信息、行为操作会有重叠部分，只是流程有差异，因此，需要将业务操作和测试用例进行分离，进行分层设计。

一般，我们都采用Page Object Model 设计模式

2 设计分层

2.1 Data-binding 数据配置层

完成系统配置，例如，用户名、密码、测试地址、git等信息

2.2 Page层

完成单个页面元素、页面行为配置

2.2.1 CommonPage基础页面层

完成page交互的通用功能，比如：点击、切换、获取元素定位等，这是page的最底层，给ActionOperator行为操作层调用。

2.2.2 PageElement 页面对象层

保存不同page元素的path。当页面元素变化，直接修改单个元素

2.2.3 ActionOperator行为操作层

对每个Page用户独立的行为操作进行封装，比如登录，新增功能等，将业务和测试用例分离，可能多个用例是对应一个业务操作的。

2.2.4 workflow TCS工作流程层

对每个page可能的页面流程进行设计并校验

2.2.5 TestCase测试用例（Main TCS）

完成具体测试用例
调用Workflow工作流程层，进行流程组装

Setup和TearDown：为每个测试用例/用例集成提供用例执行的前置配置后后置配置

2.2.6 TestSuit测试用例套件层

每个testSuit中包含多个测试用例，可对TestCase进行分组，指定待执行的测试用例，配置Testsuit

2.2.7 log日志层

运行过程中的日志、截图

2.2.8 repor报告层

保存执行结果

3 数据驱动和关键字驱动概念

关键字驱动的来源非常自然，从面向对象的思路出发，同样的业务逻辑会自然的编写成一个类或者函数作为关键字来被不同的测试脚本所调用。当测试框架发展到所有 的测试过程都已经可以被写好的函数和类所组合完成时，就进化到了关键字驱动的一个高级阶段，这个时候测试用例的开发就变成了测试数据和关键字的组合，并把 这种组合工作简化为所有人都很熟悉的表格填写任务，从而最终达到一个由数据和关键字驱动整个测试的效果。

数据驱动的自动化测试框架是这样的一个框架，从某个数据文件(例如ODBC源文件、Excel文件、Csv文件、ADO对象文件等)中读取输入、输出 的测试数据，然后通过变量传入事先录制好的或手工编写的测试脚本中。其中，这些变量被用作传递(输入/输出)用来验证应用程序的测试数据。在这个过程中， 数据文件的读取、测试状态和所有测试信息都被编写进测试脚本里;测试数据只包含在数据文件中，而不是脚本里，测试脚本只是一个“驱动”，或者说是一个传送 数据的机制。

UI自动化实战（关键字驱动）：

config：数据配置层，账号密码、测试地址数据存储
basepage：基础页面的获取定位元素、点击、打开浏览器、元素输入等公共方法
pageobject：对每个页面的单个功能方法封装
actionopration：完成每个页面的行为操作，以及一个总的页面工作流设计
logs：保存日志
screenshots：保存截图
testsuit：用例套件，指定执行的测试用例

接口自动化实战（数据驱动）

dataconfig：包含测试用例excel文件、请求数据文件、header文件、用例执行结果的期望、实际的json文件。

data：获取excel表格每1列的数据配置，获取或写入excel文件的数据封装方法。

util：脚本通用方法（判断字符串是否相等、字符串中是否包含另一个字符串方法）、操作excel文件的方法、操作json文件的方法、发邮件的 方法。

base-runmethod：对请求方式方法的封装。

main：执行测试用例的方法

logs：日志存储文件