测试开发之自动化篇——自动化测试框架设计
原创- 2022-09-01 08:59:00
- 2674
本篇目录
今天,给大家介绍如何进行自动化测试框架的设计。这里所说的框架,是建立在一些主流类库、框架或工具的基础上的,自行研发的、适合公司的自动化测试资产。
如今有很多UnitTest测试框架,已经提供了数据驱动、用户并发、断言、报告等优异的特性,完全可以被用来进行单元测试之外的功能、性能、接口等方面的测试,建议大家可以基于他们来实现。
这里给出我们建议的、自动化测试框架的分层结构,下面将围绕此给大家逐一做介绍。
测试用例脚本
在此实现业务的自动化测试,这一层面的脚本同手工测试用例具有最直接的对应关系。
公共业务脚本
一些提取出的、可在业务层面复用的函数、类库或脚本。比如网上购物系统的登录、加购物车、下单、付款等常用的业务操作。也可包括一些应用系统层面、或有安全限制的Knowledge Base的实现,如笔者曾经在测试电子支付系统时使用的、向全球央行打款的命令行工具,其由公司核心人员开发,执行于安全性极高的隔离环境中。
脚本解析
用于解析类似关键字驱动(Data Driver)、自然语言理解(NLU)等更高形式的测试脚本,将其转换成某种编程语言的可执行代码。如解析QTP关键字视图的脚本到VBScript代码,转换RobotFramework自定义关键字的脚本到Python3代码的过程。
数据管理
实现自动化测试的数据管理和数据驱动。比如,大家习惯用Excel维护二维的表格数据,在脚本中读取后再迭代引用;也可以类似前一篇文章中的例子,为数据文件或ZenData数据接口编写DataProvider,然后在脚本中使用Java标注的形式,将数据循环、逐条地”喂给“业务测试方法。
执行调度
分布式测试框架中,用于控制测试执行发生在什么样的系统、设备或节点等环境上。可以类似Jenkins的代理,执行测试于不同的远程机器中;也可以类似禅道的ZAgent开源项目,执行测试于指定特征的虚拟机、容器或手机设备中。
结果断言
通常是对一些主流测试框架的断言和日志特性做封装,使其用起来更方便、更适合公司的业务。比如,在用例做验证点检查的同时,打印、朝数据库存储、向日志系统推送指定格式的、更为详尽的消息,以利于后续的统计分析。
日志消息
除了上述断言有关的、验证点检查所输出的 期待结果、实际结果、通过与否等信息,也可以包括:基于UI的自动化测试中、每个步骤的控件定位结果、操作结果;基于协议的接口测试中,请求、响应的消息和状态,如此等等各类有益于排错和分析的日志。
统计分析
对测试步骤、检查点、用例、测试集、执行计划等各个层面的输出结果做采集和分析,生成完整的自动化测试统计报告。
测试资产管理
集中管理不同类型的测试资产,包括物理服务器、虚拟测试机、手机或嵌入式设备,甚至是AI测试中的 语音识别(ASR)语料、自然语言理解(NLU)说法、人脸识别的图库。
基础工具类库
一些常用的、特定编程语言层面的类库。如字符串处理、文件解析、协议请求、消息发送等等。
基础框架和工具
基于的第三方自动化测试类库、框架或工具来实现类似测试集组织、(分布式)执行调用、数据提供者等功能。如上文提及的JUnit、TestNG、Selenium、Appium、JMeter、QTP等优秀的开源和商业项目。大部分时候,我们不需要重复去造基础的轮子。
以上所述的模块和功能,算是囊括了一个自动化测试平台的方方面面。实际工作中,大家可以按需、逐步的进行实践,适合的永远是最好的。