一盏小灯 一个测试平台的构思、搭建到完善

Jerry li · December 27, 2018 · Last by 心无旁骛 replied at December 27, 2018 · 2885 hits

前言

又到年底了。今年的工作内容和往年没有太大的变化,产品有条不紊地2-4周一个周期的迭代,在需求评审、设计评审、测试执行、问题跟进、客户支持之间团团转。
唯一一个基本上全年在持续做的,是在空闲时间开发了一个内部使用的测试平台,和不断地维护、更新。
之前把这个平台分享过一次(https://testerhome.com/topics/15534 ),有些朋友使用后会问里面的设计和运行逻辑,这里简单记录一下吧。

与自动化测试的那些年

初识自动化-QTP

08年毕业开始第一份工作时,团队里已经使用QTP(当时最主流的自动化测试工具)维护了很大规模的自动化测试用例。
不过不巧的是,我入职这家公司时,正好遇上几个时间点:

  • 08年次贷危机,公司主打北美小型贷款业务的产品线(占公司70%收入)直接被砍。测试团队包括老大在内的十来人陆续离职,最后包括刚转正的我在内只剩两人。
  • 另一个产品正好经历一次大规模的UI升级,原来的QTP用例基本无法执行,需要花费大量时间进行升级维护。

所以原来花了大力气搭建的QTP框架和用例系统,直接被废弃了。只有在空余时间自学了一下简单的QTP使用技巧,没有在项目中实践。

自动化实践 - vs code ui test

大约过了两年后,部门调整过来以为新的主管,在产品测试流程稳定下来之后,开始调研和推动重启自动化测试。
经过对原有的QTP框架分析后,最终选择了 visual studio 的 code ui test 组件来实施自动化测试。原因如下:

  • 产品是使用 c# 开发的,visual studio 的code ui test 也是使用c#编写脚本,正好是研发过来的主管所熟悉的体系。
  • 测试框架和产品开发采用同样的体系,可以进行更好的融合。

确定工具和框架后,由于主管对测试体系进行了一些思维碰撞和讨论,最终确定了一些自动化测试准则:

  • 自动化测试用例从功能测试用例而来。将功能测试用例按优先级分为 P1-P5,自动化测试先覆盖P1级别,待推广稳定后再根据决定是否扩大范围。
  • 用例原子性:用例之间不产生耦合。确保每个用例都能独立执行。
  • 用例重复性:用例的关键数据随机生成,确保每次执行都能产生相同的结果。
  • 环境配置化:将环境地址、登录用户/密码等信息用配置文件的方式进行管理,实现在不同环境间均可执行。
  • 数据恢复与初始化:测试执行前进行数据恢复,测试完成后进行数据清理。
  • 用例模块化设计:每个功能模块的用例需先进行设计,内部评审通过后才进行具体用例实现。

定下框架和流程后,很快把相关的用例建立了起来,而且运行效果很不错。
顺便简单介绍一下 visual studio code ui test 组件,它有一个特点是用一组信息(id、name等)来标记一个元素,如果某个属性无法定位,会尝试使用其他属性来定位元素。

偏好关键字驱动 - 入坑 selenium

13年入职一家以开源技术为主导的软件外包公司。由于公司理念是使用开源技术,于是开始入坑研究selenium。
在对比了当时流行的 java+selenium+ant (当时部门同事做过类似的分享)框架搭建自动化后,开始寻找不同的思路。 在调研不同的框架后,找到了一个用python编写的关键字驱动、Excel组织用例的开源框架(没错,就是前几天被人怒怼的“毒瘤”型框架)

对于这个框架,当时看上它的以下几个点:

  • 关键字封装。将通用的一些方法封装成对应的关键字。其实总结一下,一个项目里通用的自动化操作来来回回也就是点击、填写、验证、截图等步骤,而且项目由于是使用同一个技术框架进行开发,所以这些操作的通用性非常高。所以用关键字封装的方式非常高效。
  • Excel 管理用例,用例管理简单轻便。 在外包公司工作,临时性地短期项目是常态,因此用Excel 编写一批简单的冒烟测试用例非常方便,也适用于在客户现场临时找一台机器安装使用。
  • 关键字驱动,步骤简单清晰。 只要对你的用例步骤设计地清楚,写用例非常方便,只是一个格式转换;而且一般用例就是增删改查,通用性很强,把A模块的几条用例复制成B模块,简单修改一下里面的关键元素即可,所以上手后很短时间内就可以把几个基础模块的用例写好,不用占用太多的项目测试时间。

于是开始在自己负责的项目里尝试使用,并根据需求不断增加新的关键字封装。也是为了基于这套源码二次开发自己所需要的功能,才开始学习和接触 python,开始啃相关的方法:读写Excel、格式转换、多线程并发、环境配置,等等。

一条路走到黑 - 将简单框架扩展为一个平台

入职现在这家公司,开始做长期的产品迭代开发和维护。继续使用这套框架做自动化。由于使用场景的变化,遇到以下问题:

  • 由于涉及到团队合作,Excel管理用例的方式受到很大制约。
  • 测试报告较为简单。
  • 执行依赖于自己的PC机,无法作为固定环境进行使用。

改造方式:

  • 将用例改为到数据库中读写和保存。
  • 用例编写、维护需要通过界面来维护。于是最终决定搭建一个测试平台。
  • 用docker + selenium 的方式作为用例运行载体,拜托对PC 机的依赖。
  • 由于已经编写了不少的用例,且一直在使用,因此沿用原有的用例格式。

改造过程:

1. 设计对应的数据库表。

  • 用例管理: 分为test_case(原始测试用例)、test_suite(测试用例集) 、test_batch(测试用例执行记录) 三个表管理用例。达到的目的:一条用例可以在多个不同用例集中执行;一个用例集可以根据需求选择合适的测试用例。
  • 关键字管理: test_keyword ,用以管理对应的关键字封装,将关键字和具体的封装方法、参数列表进行映射。

2. 平台搭建和页面开发。

  • 使用flask 搭建平台。
  • 基于flask - bootstrap 编写对应的页面: 用例管理(增删改查)、用例集管理(增删改查、用例关联、执行记录和报告)、关键字管理(增删改查)

3. 测试执行核心代码改造

  • 启动一个主进程 coreservice, 定时查询数据库中是否有待执行状态的用例(页面中点击执行某条用例或某个用例集,会将对应 test_batch 记录修改为待执行状态)。如有,则开始执行。
  • 读取对应的测试用例列表,将对应test_batch id 以多进程方式并发分配执行。
  • 每条用例执行时,读取对应的用例,并逐步转换为对应的封装方法进行执行,直至步骤全部执行完成。
  • 用例执行完成后,将对应执行状态、失败步骤、截图等信息保存到数据库。
  • 具体任务执行,会使用 selenium remote 的方式在已启动的docker 容器内的selenium server 进行分配执行。
  • 报告生成和邮件通知。 用例执行完成后,自动发送测试报告。

因为改造方向很明确,所以开发比较顺利,很快将一整套框架开发搭建完成。

后续优化

随着这个平台稳定运行,逐步把一些测试相关的功能也集成进来:

  • android 自动化测试集成。开始选用的是macaca ,后来改为 atx 。 采取相同的用例结构和关键字格式。
  • 接口测试框架集成。
  • 集成百度脑图的 kityminder 框架,以思维导图的格式管理测试点。
共收到 2 条回复 时间 点赞

首先楼主的构思是很好的值得称赞,经历和我挺相似,不过感觉开发平台后就没什么目标和追求了(可能这就是测试吧)

很喜欢这篇文章风格,也是目前正在走的路线。

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up