Appium WebDriver 自动化测试演变之路,基于 appium,selenium 的自动化测试平台,中小公司自动化测试解决方案

阿斯克都 · 2016年09月02日 · 最后由 gaomengsuijia 回复于 2020年04月11日 · 4151 次阅读

一、概述
1、自动化测试相对于手工测试的优点
优化测试速度:可非常快速的运行上万条记录
提高准确性、稳定性:可以不为外界因素干扰,
准确运行测试用例确定性
重现缺陷提高工作效率:一边运行自动化测试,一边准备测试报告
提高技能:可提高测试人员技能,同时提高对测试的兴趣,防止对手工测试感觉枯燥
数据处理方面的优点
测试数据:自动化测试工具可以根据需要,准备大量的测试数据
数据处理:测试结果有时需要再进行相应的数据处理
用例准备:可以使用相关脚本技术准备大量的测试用例
2、自动化测试解决方案概述图

二、选用框架及理由
1、测试服务器:
Django:Web 应用框架
Django 是一个开放源代码的 Web 应用框架,由 Python 写成。采用了 MVC 的软件设计模式,即模型 M,视图 V 和控制器 C
自助管理后台,admin interface 是 Django 里比较吸引眼球的一项自带功能,让你几乎不用写一行代码就拥有一个完整的后台管理界面。
强大的 URL 路由配置,Django 让你可以设计出非常优雅的 URL,在 Django 里你基本可以跟丑陋的 GET 参数说拜拜。
Python:结合 Django 快速开发 web 测试管理工作站
开发快,语言简洁,入门容易
强大的支持库
社区活跃度高,资料丰富
Apache:部署 Django web 应用
稳定性强
处理高并发能力强
Mysql:储存和管理测试用例
2、测试 PC:
Selenium:web 测试框架,驱动游览器执行用例
Selenium 使用灵活,简单,写出的测试案例非常简洁,优美,也易于维护。
Selenium 支持用多种语言编写测试案例,你可以用 java,Python 等各种语言编写用例
容易和测试平台结合

Appium:移动端测试框架,驱动手机执行用例
包括 selenium 的所有优点
支持多系统:Android,IOS
三、自动化阶段进程
阶段一 Selenium  IDE:selenium 的录制工具,通过录制操作生成脚本

优点:  入门简单,安装之后就可以使用,也能自动生成代码,对无代码功底同仁不失为一个很好的学习范例
缺点: 脚本录制之后只能执行一次完全相同的操作,即使是数据相同,操作完全相同也无法执行第二次
阶段二 手工编写硬代码

优点:手工编写代码较 IDE 生成代码要灵活,可以断言,可以任意增加删除代码
缺点:相同操作代码要重复编写,而已每一行还很长
阶段三 操作方法二次封装
优点:代码量减少
缺点:手工编写繁琐,需要一定脚本基础
阶段四 POM(数据驱动)

从 Excel  中读取数据,代码和数据分离
阶段五 POM(页面对象管理)

从 Excel  中读取数据,代码和测试元素(控件)分离
阶段六 关键字驱动

编写自动化用例时不需要任何代码,全部用中文就可以实现编写完用例,这样公司也不需要自动化开发人员来编写代码,功能测试人员即可自主完成用例编写)
阶段七 自动化管理平台

终极形态:将元素,数据, 用例存放到服务器数据库中,执行时动态从数据为中读取数据
元素录入,用例管理,测试报告检索

四、自动化管理平台介绍

主要模块:
基础数据:控件查找方法管理,控件操作动作管理,控件管理
项目用例:项目 - 页面 - 用例 - 步骤,项目,页面,用例,步骤,前置用例
运行及结果:运行结果查看,生成脚本下载
模块介绍:
1、控件查找方法管理:保存控件查找方法,用于与脚本自动生成函数相匹配,此项内容为测试开发人员维护,添加与修改删除需要同步更改脚本自动生成函数进行匹配,一般功能性测试人员只需要进行调用

2、控件操作动作管理:保存控件操作动作,用于与脚本自动生成函数相匹配,此项内容为测试开发人员维护,添加与修改删除需要同步更改脚本自动生成函数进行匹配,一般功能性测试人员只需要进行调用。基本包含了 appium 和 selenium 常见的操作动作,使用中文的方式进行展现。

3、控件管理:使用数据驱动的方式,将元素实体和定义名称进行分离。可以很好的避免开发人员更改了元素实体后需要大量更改脚本中的元素实体。同时将元素实体进行中文命名可视化程度及记忆选择难度大大降低。同时一个控件元素绑定两种实体(安卓和苹果),一个用例可以同时生成两个系统的脚本。


4、项目 - 页面 - 用例 - 步骤:自动化平台的用例管理逻辑,核心内容。
从大到小的关联关系分别为:项目 - 页面 - 用例 - 步骤
他们的关系都是一对多的关系,也就是一个项目下可以有多个页面,以此类推,最小的为步骤就是单个操作动作

5、项目:用例逻辑的最高层,用于存储脚本生成时的基础数据,如选择运行 appium 时执行脚本的测试机,连接数据库的基本信息等等

6、页面:项目下属页面,用于关联项目和用例,避免所有用例都关联到同一个项目下,内容过多,同时在脚本大量生成时用于脚本分文件,目前逻辑为同一页面下的用例生成一个脚本文件

7、用例:用于描述每个用例的测试目的及关联每个步骤,测试概念中的 testcase

用例中内嵌了两个函数一个是脚本生成函数一个是运行函数。将本套系统部署在服务器时,可以直接调用运行或脚本生成函数将组织好的用例进行生成到服务器和运行,如果在项目中设置 appium 的运行地址后可以直接调到测试 PC 所连接的测试机进行测试。

8、步骤:每个 step 的操作,其中的操作动作,操作元素,定位方法都是基础数据中配置好的直接进行选取组合

9、前置用例:用例的前置步骤(用例),主要功能是在主用例前可以执行前置用例,一般前置用例都被设置成环境清理或数据准备等动作

10、运行结果:通过平台运行的用例都会生成测试结果,可以在此处进行查看,或下载

11、脚本文件管理:通过平台运行或生成的脚本,都可以在此处进行下载

五、困难和未来规划
1、测试服务器:测试管理工作站页面优化(需要前端开发工程师配合)
2、测试 pc,测试手机的扩充和机房的搭建
3、应用程序端测试管理工作站(exe 文件)
4、完善 ios 脚本生成
5、接口测试整合进入平台中

自动化演变之路是受到了别人的文章启发从而开发了这个平台,在这里感谢可口可乐的围脖,详细的自动化演变之路可以去这个地址查看http://blog.csdn.net/wanglha/article/details/48176739

共收到 21 条回复 时间 点赞

我觉得各种讲自动化测试的工具、方案都没有讨论测试数据的维护,相对于脚本来说,测试数据的维护同样也是大头。
另外,这个工具如何接入持续集成?

当然,工具还是很强大的👏

感觉像 robot framework 的赶脚。。会写代码的还是自己写代码~
不会写的才会用用这些工具

讲的蛮详细的,有帮助诶~谢谢

前期用 xml 就够了,我用的 yaml

#1 楼 @skwinleo 你说的测试数据是指测试的基础数据(测试账号,各种前置数据)?如果是这样的话,我们一般都是通过前置用例去创建或者通过操作数据库插入数据。对于持续集成我目前也没有很好的解决方案,如果各位有什么方法可以一起讨论一下

#2 楼 @lucifer 一开始我们也是直接自己写代码,但是很多功能测试人员是不会写代码的,这个工具就是提供给他们用,类似于定制版的 robot framework

请教下,管理平台是基于什么架构?

#7 楼 @sunkuan2007 我不是在最开始的地方写了,django+appium+selenium

和我们目前的思想差不多,只是我们用的 robot framework,没有做这个前端的管理控制台

#10 楼 @okokhihi 自己开发一套这样的就比较灵活,而且扩展性比较好,以后还可以接入接口测试这类的,可以说是比较好的一个基础性内容

管理平台还是很重要的,关键是数据与用例本身的组织方式。
毕竟对于流程复杂的系统来说,这块是大坑。

#12 楼 @wingbestbest 不是很理解你的意思,能举个具体例子么?

UI 自动化真正要解决的是: 测试设计和测试执行彻底分开, 测试数据和测试用例分开,测试角色分层,测试框架和测试用例 对 测试环境 要有很大的适应性,比如测试用例能否同时适应 实验室测试环境 和 客户现场环境 。 如果自动化的工作只放在 技术测试人员(非手工测试)手中,基本作用不大。

#13 楼 @410637312
测试用例本身与对应的测试数据,如何匹配。
如果不能便捷且合理的通过管理界面进行搭配,并且适应对应客户的流程场景,那么使用起来会很费劲。
毕竟国内大多数测试人员,还在停留在手工测试,让他们可以使用,简单且符合用户场景,并且在后期维护时间少重复劳动,这个就要看管理平台的设计如何了。
比如测试用例有大量的输入数据的操作,且对应同一个流程,数据列有多份,也就是多种数据匹配的场景,如和让测试人员输入或操作更少的内容,以达到可以更方便的设计用例和数据。
同时还有调试数据的问题等等。
测试用例是否还分多层,比如模块用例、流程用例、任务用例等等。

#14 楼 @fisherdeng 你说的很有道理,所有才会有我这个测试自动化平台,这个测试自动化平台就是为了实现数据驱动的目的并且进行人员的普及化

#15 楼 @wingbestbest 这个平台很大的程度上有模仿华为的 TMSS 的测试工具,基本思想和测试用例的组织都和 TMSS 相似。现在测试用例有复制功能,也就是对于相同功能对应不同测试环境只需要修改部分输入数据环境配置这类的变量,就可以实现用例适应不同测试数据和环境

这个思路是对的: 终极形态:将元素,数据, 用例存放到服务器数据库中,执行时动态从数据为中读取数据。
另外考虑 自动获取和同步 UI 元数据到数据库中。
还有就是测试执行 一定要有现场记录(视屏或者图片),这样可以快速 还原测试执行的轨迹,知道问题出在哪里。。

#18 楼 @fisherdeng 目前已经实现了你说的终极形态了,但是自动获取和同步 UI 元素这个还真没什么很好的办法。对于执行过程的截图可以实现但是目前还没去扩充,希望以后能好好的完善这个平台

大神,请问你是怎么 web 连接上手机的呢?web 这一块,元素、数据。用例我已经搞定了。

大神,求项目源码!

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册