版本 |
作者 |
审批 |
备注 |
V1.0 |
XXXX |
创建测试方案文档 |
|
项目名称 |
XXX |
项目版本 |
V1.0 |
项目经理 |
XX |
测试人员 |
XXXXX,XXX |
所属部门 |
XX |
备注 |
本文档主要用于指导XXX-YY项目常用接口自动化测试工作的开展。本文档的主要目的在于提供项目接口自动化测试的技术方案、实施方案和计划方案等。
XXX-YY项目采用接口自动化测试,主要目的是为了应对迭代版本测试过程中的重复工作任务,以期达到效果如下:
虽然能达到上述预期效果,但实际实施过程中需要注意的是,接口自动化的高效应用,对于被测系统有着更高的要求,也需要遵循合理的方法流程,现总结如下:
系统范围:
自动化实施阶段 |
被测模块 |
功能接口范围 |
第一阶段 |
登录获取token,YY标签页 |
|
第二阶段 |
||
阶段范围:
这里我们优先测试一下登录的接口和一些插入XXX功能的接口。
脚本编码前,需要对项目有一个整体把握,合理预估接口数量与复杂度。结合版本迭代时间,预估自动化脚本开发时间,并制定出相应的接口自动化测试方案。
根据前面写好的接口自动化测试范围,分析每个接口的测试点,包含请求方式,传入参数,请求头,返回状态,返回数据等。这个过程中,需要和相对应的开发对接清楚在测试范围内的接口的相关信息,并提前在postman中逐一确认调通,必要时生成相应的测试文档或编写进入测试用例中。
此次接口自动化测试框架采用的是以Python语言为脚本开发语言,选用unittest接口测试框架。目的希望达成可配置,能自动运行脚本,自动生成测试报告并将生成的测试报告发送到指定邮件。
脚本首次实现不需要覆盖到每个接口。先预计挑选几个重要接口进行覆盖测试,等整体测试框架搭建好后,整体流程确认调通无误后,再后续维护完善脚本,覆盖更多的功能接口。
同上,初次脚本代码完成后,需要对现有自动化脚本进行升级持续集成开发,不断完成尚未覆盖到的接口,将这些接口加入到自动化测试的范围内,使得整体自动化程度进一步加深,更大程度上节约人力和时间成本。
脚本维护是在整体自动化脚本阶段性完成后,将现有生成的交付物归档整理好给相应的负责人管理,并进行阶段性的更新整理维护。包含项目日常版本迭代维护过程中对接口有改动的部分,和后续新加入接口得自动化覆盖等。
结合测试金字塔(从下到上依次是:单元测试,服务测试,用户界面测试)以及XXX-YY项目本身的流程特性考量,本次自动化实现主要是以接口自动化的形式来开展。整个自动化脚本以 Python3.X 中 requests 库为核心机制,以 unittest 为测试组织,以 HTMLTestRunner 生成最终测试报告,Jenkins 实现持续集成,并选取 Python3.X 作为编程语言实现。
3.2.1 接口自动化执行库--Requests
首先,Requests 是使用 Python 语言编写,基于 urllib,采用 Apache2 licensed 许可证的 HTTP 库。它比一般的 urllib 等库更加方便、简洁,可以节约我们大量的工作,完全满足HTTP 测试需求,总结为一句话:Requests 是 Python 实现的简单易用的 HTTP 库。其次,Requests 库安装和导入非常方便。
pip3 install requests ## 安装 Requests 库
import requests ## 导入 Requests 库到项目中
我们可以使用该库实现以下各种方法:
requests.get("https://url.cn") # GET请求
requests.post("http://url.cn") # POST请求
requests.put("http://url.cn") # PUT请求
requests.delete("http://url.cn") # DELETE请求
requests.head("http://url.cn") # HEAD请求
requests.options("http://url.cn") # OPTIONS请求
3.2.2 测试组织和断言机制--unittest
unittest 模块是 Python 中自带的一个单元测试模块,我们可以用来做接口自动化代码级别的测试组织和断言机制。其中比较重要的小组件模块有:TestCase,TestSuit,TestLoader,TextTestRunner,TextTestResult等。
TestCase:用来编写逐条的测试用例,是所有测试用例的基类,他是 unittest 模块中最基本的组成单元。一个 testcase 就是一个测试用例,是一个完整的测试流程,包括测试前的环境搭建准备 setUp,执行测试代码和断言机制,以及测试一条用例完成后的环境还原 tearDown 等。
TestSuit:多个TestCase就组成了一个TestSuit(测试用例集),这是用来存放一条一条测试用例的集合。
TestLoader:是用来将逐条的测试用例 TestCase 加载到用例集合 TestSuit 中,其中加载的方式有多种,就是从脚本项目中寻找到单独的用例,创建他们的实例,然后加载到一起,组成TestSuit,再返回一个TestSuit的实例。
TextTestRunner:是用来执行用例集 TestSuit 中的测试用例。
TextTestResult:用来保存测试结果,包含执行了多少条测试用例,成功与失败用例的条数等信息。
示意图如下(网络来源图):
3.2.3 测试报告生成--HTMLTestRunner
当我们批量执行完用例集 TestSuit 中的接口用例后,生成的测试报告是dos端文本格式展示的,不是很直观,这里我们引入一个第三方库--HTMLTestRunner,使用这个第三方库我们可以生产成 HTML 网页格式的测试报告。
3.2.4 持续集成机制--Jenkins
这里我们脚本持续集成选择 Jenkins 来实现,通过使用 Jenkins,我们能够实现脚本自动化执行,包含定时执行自动化测试脚本,和自动化脚本运行后的测试报告发送到指定的邮箱中。
3.3.1 封装思想
整个接口自动化测试脚本采用面向对象的封装思想,尽量将一些可配置的模块单独提取出来,便于后续操作配置,使得整体项目更加灵活多变,便于后续地迭代维护和二次开发。封装思想主要体现在测试环境可配置,测试用例可导入,测试数据和脚本分离,文件路径采用相对路径表示等,具体我们会在实际编码分层中得到体现。
3.3.2 数据驱动实现
数据驱动这里我们采用的是 Python 中的装饰器--DDT(Data Driven Tests)来体现。通过他我们可以复用我们的脚本代码,达到数据驱动测试的目的。官方对DDT的描述是:DDT(数据驱动测试)允许您通过使用不同的测试数据运行一个测试用例,并使其显示为多个测试用例。
这里官方网站中对DDT的介绍做一个简单描述。首先,DDT主要是由一个类装饰器 @ddt(用于我们脚本中的TestCase子类)和两个方法装饰器(用于我们想要批量处理的测试数据)分别是 @data(这里需要保持提供参数和被测参数个数一致)和 @file_data(将从JSON 或者 YAML 文件中加载测试数据)。其次,关于data修饰的方法传入的参数,会被当做一个整体传入,如果这些参数像是元组一类的参数,那么你必须将他们分解开传入到你的测试中。另外,你可以使用另一个装饰器 @unpack,来解压缩分解你的参数为多个参数。
目前暂未涉及到性能相关或者需要分布式执行的内容,因此对硬件要求不是很高,日常办公硬件即可。如果后续有涉及性能相关内容,硬件环境需要再另外的性能测试方案中体现。
软件相关 |
版本号 |
备注 |
Python |
v3.7 |
脚本编码语言为 Python3.x |
PyCharm |
v2016.3.3 |
|
组别/人员 |
职责 |
备注 |
测试任务 |
负责人 |
开始时间 |
备注 |
自动化测试方案制定 |
|||
接口用例编写 |
|||
自动化测试环境搭建 |
|||
自动化测试框架搭建 |
|||
自动化脚本代码编写 |
|||
持续集成实现 |
|||
测试报告输出 |
|||
脚本二次维护开发 |
交付物 |
负责人 |
备注 |
《自动化测试方案》 |
||
自动化框架 |
||
自动化脚本代码 |
||
测试执行报告 |