接口自动化测试方案

 目录

1、引言

2、接口自动化实施目标

3、接口自动化技术选型

4、测试环境需求

5、人员进度安排


1、引言

  1.1 文档版本

版本

作者

审批

备注

V1.0

XXXX

创建测试方案文档

  1.2 项目情况

项目名称

XXX

项目版本

V1.0

项目经理

XX

测试人员

XXXXX,XXX

所属部门

XX

备注

  1.3 文档目的

    本文档主要用于指导XXX-YY项目常用接口自动化测试工作的开展。本文档的主要目的在于提供项目接口自动化测试的技术方案、实施方案和计划方案等。

2、接口自动化实施目标

  2.1 实施原则

    XXX-YY项目采用接口自动化测试,主要目的是为了应对迭代版本测试过程中的重复工作任务,以期达到效果如下:

  • 降低测试成本
  • 提高测试效率
  • 更频繁地执行覆盖重要接口
  • 提供更高的准确性和一致性
  • 节约时间成本

  虽然能达到上述预期效果,但实际实施过程中需要注意的是,接口自动化的高效应用,对于被测系统有着更高的要求,也需要遵循合理的方法流程,现总结如下:

  • 接口自动化的实施应该被用于解决测试过程中高重复性的工作,很大一部分是用于回归测试老的功能接口,否则其本身工作量投入会大于其收益,所以不能盲目对所有接口或功能追求自动化。
  • 对于提测版本,自身稳定性需要有一定程度的保障。过于频繁的接口变动,会加大后续接口自动化的实施难度,增加自动化脚本维护地成本。
  • 接口自动化的整体实现应采用分布进行,测试过程中优先覆盖功能稳定且比较重要的接口,进而逐步扩展到整体项目的接口回归。
  • 接口自动化测试是一个长期的过程,随着项目版本的不停迭代优化,项目本身的接口也会不断优化或新开发,所以后续自动化测试脚本的代码维护和调优也具有可观的工作量。

  2.2 接口自动化测试范围

    系统范围:

自动化实施阶段

被测模块

功能接口范围

第一阶段

登录获取token,YY标签页

第二阶段

    阶段范围:

      这里我们优先测试一下登录的接口和一些插入XXX功能的接口。

  2.3 接口自动化测试任务

  • 制定测试方案

脚本编码前,需要对项目有一个整体把握,合理预估接口数量与复杂度。结合版本迭代时间,预估自动化脚本开发时间,并制定出相应的接口自动化测试方案。

  • 提取分析测试点

根据前面写好的接口自动化测试范围,分析每个接口的测试点,包含请求方式,传入参数,请求头,返回状态,返回数据等。这个过程中,需要和相对应的开发对接清楚在测试范围内的接口的相关信息,并提前在postman中逐一确认调通,必要时生成相应的测试文档或编写进入测试用例中。

  • 搭建测试框架

    此次接口自动化测试框架采用的是以Python语言为脚本开发语言,选用unittest接口测试框架。目的希望达成可配置,能自动运行脚本,自动生成测试报告并将生成的测试报告发送到指定邮件。

  • 编写脚本代码

    脚本首次实现不需要覆盖到每个接口。先预计挑选几个重要接口进行覆盖测试,等整体测试框架搭建好后,整体流程确认调通无误后,再后续维护完善脚本,覆盖更多的功能接口。

  • 持续集成

    同上,初次脚本代码完成后,需要对现有自动化脚本进行升级持续集成开发,不断完成尚未覆盖到的接口,将这些接口加入到自动化测试的范围内,使得整体自动化程度进一步加深,更大程度上节约人力和时间成本。

  • 脚本维护

    脚本维护是在整体自动化脚本阶段性完成后,将现有生成的交付物归档整理好给相应的负责人管理,并进行阶段性的更新整理维护。包含项目日常版本迭代维护过程中对接口有改动的部分,和后续新加入接口得自动化覆盖等。

3、接口自动化技术选型

  3.1 整体体系

    结合测试金字塔(从下到上依次是:单元测试,服务测试,用户界面测试)以及XXX-YY项目本身的流程特性考量,本次自动化实现主要是以接口自动化的形式来开展。整个自动化脚本以 Python3.X 中 requests 库为核心机制,以 unittest 为测试组织,以 HTMLTestRunner 生成最终测试报告,Jenkins 实现持续集成,并选取Python3.X 作为编程语言实现。

  3.2 核心技术

    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 框架思想

    3.3.1 封装思想

    整个接口自动化测试脚本采用面向对象的封装思想,尽量将一些可配置的模块单独提取出来,便于后续操作配置,使得整体项目更加灵活多变,便于后续地迭代维护和二次开发。封装思想主要体现在测试环境可配置,测试用例可导入,测试数据和脚本分离,文件路径采用相对路径表示等,具体我们会在实际编码分层中得到体现。

    3.3.2 数据驱动实现

    数据驱动这里我们采用的是 Python 中的装饰器--DDT(Data Driven Tests)来体现。通过他我们可以复用我们的脚本代码,达到数据驱动测试的目的。官方对DDT的描述是:DDT(数据驱动测试)允许您通过使用不同的测试数据运行一个测试用例,并使其显示为多个测试用例。

    这里官方网站中对DDT的介绍做一个简单描述。首先,DDT主要是由一个类装饰器 @ddt(用于我们脚本中的TestCase子类)和两个方法装饰器(用于我们想要批量处理的测试数据)分别是 @data(这里需要保持提供参数和被测参数个数一致)和 @file_data(将从JSON 或者 YAML 文件中加载测试数据)。其次,关于data修饰的方法传入的参数,会被当做一个整体传入,如果这些参数像是元组一类的参数,那么你必须将他们分解开传入到你的测试中。另外,你可以使用另一个装饰器 @unpack,来解压缩分解你的参数为多个参数。(附:DDT官方文档:Welcome to DDT’s documentation! — DDT 1.5.0 documentation

4、测试环境需求

  4.1 硬件环境

  目前暂未涉及到性能相关或者需要分布式执行的内容,因此对硬件要求不是很高,日常办公硬件即可。如果后续有涉及性能相关内容,硬件环境需要再另外的性能测试方案中体现。

  4.2 软件环境

软件相关

版本号

备注

Python

v3.7

脚本编码语言为 Python3.x

PyCharm

v2016.3.3

5、人员进度安排

  5.1 职责分配

组别/人员

职责

备注

  5.2 进度安排

测试任务

负责人

开始时间

备注

自动化测试方案制定

接口用例编写

自动化测试环境搭建

自动化测试框架搭建

自动化脚本代码编写

持续集成实现

测试报告输出

脚本二次维护开发

  5.3 交付物管理

交付物

负责人

备注

《自动化测试方案》

自动化框架

自动化脚本代码

测试执行报告

  • 1
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值