从零开始的软件测试学习之旅(七)接口测试流程及原则案例

接口测试介绍

接口介绍
不同主体之间进行通信的通道,它应具有一套规范/标准 (分类 硬件接口:USB接口 网线接口; 软件接口)

软件接口

1.软件系统中,前端和后端是两大重要组成部分

2.前端主要用于与用户交互,用户通过前端可以提交数据并查看响应的结果

3.后端主要处理用户提交的数据产生相应

比如:百度搜索,思考前后端分工前后端通过某个通道完成数据交互 搜索12306时,https://www.baidu.com/s?wd=12306

访问路径包括/s,建立通信管道 参数包括wd=12306符合标准

采用接口的好处
(实现了前后端分离)为了数据交互同时,
1.前后端都可以使用自己熟悉的技术
2.缩短了研发周期
3.保证代码安全
4.拓展性更好

接口预定义

落实到文档,该文档称之为API文档
前后端编码时,1.需要参考API文档/
2.前人总结的相关规范 如:RESTful架构风格

举例:
编写登录接口的API文档
描述:登录接口
URL:http://www.xxx.com/login
请求方式:POST
提交数据:账号 usename
密码 password
响应结果: 成功true 失败 false
前端实现:

后端实现:

1.获得用户提交的数据 2.查询结果相应数据(true/false)

接口测试的主要作用

主要作用 1.更好的辅助定位bug(前/后端) 2.发现程序中的安全隐患 3.提高测试效率

测试接口流程如下

1.绕过前端 2.通过URL定位接口资源 3.提交测试数据 4.判断响应是否满足预期

接口测试三要素

1. 定位接口资源 2.提交测试资源 3.判断相应资源

接口测试分类

1.B/S测试(web形式的接口测试): 1.服务器接口测试->自实现接口 2.外部接口测试 如支付宝接口,微信测试

2.C/S模块之间的接口测试

RESTful架构风格

为什么要学习RESTful架构风格?

避免千人千面, 使API文档风格统一

RESTful架构是一种接口设计架构, 约束了接口实现的规范

架构的作用:提高了文档的可读性

RESTful架构的设计在API文档中关于接口的描述也是围绕三要素展开的:

描述: 实现用户的登录功能
流程:
1、登录表单的数据提交到服务器: http://www.xxx.com/login, 请求方式 POST
2、提交的数据格式: username=xxxx&password=yyyy
3、响应结果:
200 {“msg”:“登录成功”}
200 {“msg”:“登录失败”}

注意: 一般响应结果的msg中, 提示信息很可能是英文

RESTful架构三要素

要素一

组成

• URL(统一资源定位符), 例如: http://www.baidu.com/s
  • 协议: 常见的有 http/ https/ ftp/ ftps
  • IP: 服务器 IP 地址
  • 端口: http默认端口一般是80, https默认端口一般是443
  • 路径: 一个资源路径映射一个接口实现
• 请求方式: 常见GET/POST/PUT/DELETE 分别对应 查/增/改/删 四种操作

get 和 post 的区别

• 提交方式不同
  • get 提交的数据显示在地址栏
  • post 是隐式提交, 更安全
• 可提交的数据量不同
  • get 提交的数据量有限制
  • post 无限制
• 执行效率不同
  • get 的效率比 post 高

要素二

两种常见的数据提交格式

• 键值对格式
• JSON格式(类似于 python 中的字典)

一般情况下, 使用 get 方式进行提交时, 使用的是键值对格式 使用 post 方式进行提交时, 使用的是JSON格式

要素三

状态码

• 1xx 请求正常, 但是无响应, 只在实验状态下使用
• 2xx 请求正常, 响应正常, 如: 200 201 204…
• 3xx 以其他方式获取响应, 如: 302 重定向 304 取本地缓存
• 4xx 浏览器端异常, 如: 404 资源路径有误
• 5xx 服务器端异常, 如: 500 服务器运行异常

响应体

常见的接口的响应体有两种类型

• 响应 html 文档, 例如: 访问百度搜索接口
• 响应 JSON 格式数据

RESTful架构风格实现

RESTful 只是一种规则, 并不是标准, 换言之, 不是硬性约束

restful架构案例

一.查询
1.1 学员-查询所有
请求方法：GET
请求地址：http://127.0.0.1:8000/api/students
1.2 学员-查询指定单个
请求方法：GET
请求地址：http://127.0.0.1:8000/api/students?s_id=S001
(注: s_id 为参数名称; S001,S005,S088 为学员ID;)
1.3 学员-查询指定多个
请求方法：GET
请求地址：http://127.0.0.1:8000/api/students?s_id=S001,S005,S088
(注: s_id 为参数名称; S001,S005,S088 为学员ID;)
1.4 学员-组合查询
请求方法：GET
请求地址：http://127.0.0.1:8000/api/students?chengji=A&banji=B01
(注: chengji：成绩; banji：班级;)

二.新增
2.1 学员-新增
1) 请求方法：POST
2) 请求地址：http://127.0.0.1:8000/api/newstudents/
3) 请求JSON报文：
4) 调用传入的json串如下（可新增多条，之间用,隔开）：

  {
            "data": [
                {
                    "s_id":"S009",
                    "s_name":"zhangsanfeng",
                    "banji":"B01",
                    "chengji":"A"
                }
            ]
        }

5. 新增成功返回报文：

   {
            "already_exist": {
                "results": [],
                "count": 0
                },
                "create_success": {
                "results": [
                    {
                        "s_id":"S009",
                        "s_name":"zhangsanfeng",
                        "banji":"B01",
                        "chengji":"A"
                    }
                ],
                "count": 1
            }
        }

	6) 新增失败id已存在-返回报文：
    {
        "already_exist": {
            "results": [
                {
                    "s_id":"S009",
                    "s_name":"zhangsan",
                    "banji":"B02",
                    "chengji":"B"
                }
            ],
            "count": 1
        },
        "create_success": {
            "results": [],
            "count": 0
        }
    }
	7) 新增失败json格式错误：

{
        "status_code": 400,
        "detail": "请求体参数格式错误。"
    }

三.更新
3.1 学员-更新
1). 请求方法：PUT
2). 请求地址：http://127.0.0.1:8000/api/updatestudents/S009/
(注：1：为学院ID)
3). 请求JOSN报文：

  {
        "data": [
            {
                "s_id":"S009",
                "s_name":"zhangsanfeng",
                "banji":"B01",
                "chengji":"A"
            }
        ]
    }
    4). 修改成功返回：
        {
            "s_id":"S009",
            "s_name":"zhangsanfeng",
            "banji":"B01",
            "chengji":"A"
        }

四.删除
4.1 学员-删除单个
请求方法：DELETE
请求地址：http://127.0.0.1:8000/api/deletestudents/S003/
(注:S003为学员ID)

s_id":"S009",
                "s_name":"zhangsanfeng",
                "banji":"B01",
                "chengji":"A"
            }

接口测试流程

1. 制定测试计划: 分配任务

   • 任务名称: 按模块去划分
   • 任务描述: 说明具体任务内容
   • 责任人
   • 工期: 以天为单位 开始日期—结束日期
   • 进度: 进行中/未开始
   • 备注

2. 从 API 文档中提取接口清单

   接口清单是对 API 文档的精简

   • API文档为了保证易读性, 说明信息较多, 导致测试过程中, API 文档内容稍显冗余
   • 需要从 API 文档提取测试必须的数据, 摒弃冗余数据 (提取的结果: 接口清单)

3. 设计测试用例并参数化覆盖测试用例

4. 编写脚本实现, 导入设计的测试数据

5. 生成测试报告

   • 接口功能名称
   • 接口用例描述
   • 预期结果
   • 实际结果
   • 是否Bug
   • 备注

接口测试原则

功能测试

应用场景
模拟用户的多样性操作, 查看实际结果是否符合预期

原则
1.设计各种正向 + 逆向的测试用例 2.接口覆盖率达到100%

自动化测

应用场景
程序升级

• 新功能(接口)可能会影响原有的功能(接口)
• 新版本上线前, 需要测试确保原有接口能够正常运行
• 版本迭代比较频繁, 使用自动化测试可以提高效率

原则

• 接口覆盖率没必要100%, 只需要测试重要的和被重复调用的接口
• 只需要提交正向的测试用例
• 自动化脚本需要保证可以重复执行
• 一个线程组建议对应一个取样器

性能测试

应用场景

高并发 :如, 模拟100个用户同时访问服务器资源, 要求平均响应时间在3s以内, 且错误率小于1%

高频率 :如, 模拟2个用户以20QPS的频率访问服务器资源持续15s, 要求平均响应时间在3s以内, 错误率为0

区间多用户:如, 模拟半个小时内 1000 个用户访问服务器资源, 要求平均响应时间在3s内, 且错误率为0

原则

1 线程组: 增删改查每个功能, 都需要单独的线程组, 而且避免在同一个线程组内有多个取样器
2 参数化: 参数化尽量避免从外部(csv文件)读取数据, 而是用函数生成测试数据
3 查看结果树: 必须清除单个请求内的查看结果树组件, 建议一个测试计划就一个查看结果树
4 报告: 性能测试报告可根据实际需求选择, 建议使用 聚合报告
5 分布式

扩展

实际登录场景

• 早高峰时段 8:50~9:10, 5000用户登录

  1. 业务量: 5000个
  2. 时间: 6020 = 1200s
     平均每秒处理 4.1个登录请求/每秒
     性能场景分析
     二八原则
     指80%的业务量是在20%的时间内完成的
     计算吞吐量: 实际吞吐量 = 业务量80% / (时间段*20%) = 4000 / 240s = 16.7/s
  • 备注

  实际上, 登录请求数分布是一个正态分布, 最高峰时肯定比 4.1/s 更高, 峰时段实际上完成了80%的业务量, 却只花了20%的时间
  注意
  1 二八原则计算的结果不是并发用户数, 是系统应该达到的处理能力(吞吐量)
  2 如果你的系统性能要求更高, 也可以选择一九原则或者更严格的算法, 二八原则比较通用

复习复盘

1.接口的概念是什么?
2.接口的作用是什么?
3.如何实现接口的通道?
4.如何预定义接口规则?
5.接口测试的概念是什么?
6.接口测试的作用是什么?
7.接口测试三要素是什么?
8.接口测试可以怎样分类?
9.RESTful三要素

10.接口测试流程是什么?
11.执行接口测试前都做了什么工作?
12.接口测试报告你们是怎么写的?
13. 注意不要忘记结论: 接口测试是否通过
14 接口功能测试的原则是什么?
15 接口自动化测试的使用场景是什么?
16接口自动化测试需要注意什么?
17接口性能测试包括哪些场景?
18请举例说明如何分析性能测试场景?