乐趣区

关于接口:服务端接口测试指南

jiezi

测试的第一指标是品质保障，所以咱们从品质保障的纬度，来理解接口测试。

1、理解接口

1.1 接口做了哪些事？

首先，从性能角度了解。
比方，从一个用户购买一个商品的业务流程来了解：

  • 新用户注册：通过注册接口 新增一条用户数据（Create）；
  • 注册胜利后登录：通过登录接口，首先依据用户名查问（Select）明码，而后校验明码，明码校验胜利，通过规定和加密 新建（Create）token 签名，将 token 发送给客户端；
  • 搜寻商品：通过商品搜寻接口搜寻指标商品，实质是从商品数据库中进行条件查问（Select）；
  • 查看商品详情：商品 ID + 商品详情接口，查问商品详情（Select）；
  • 抉择商品退出购物车：增加购物车接口，更新购物车数据，库存数据减一（Update）；
  • 创立地址并抉择地址：新建地址接口，新增一个新的地址（Create）；
  • 下单 & 结算：下单接口，新增一条新的订单数据（Create）；
  • 领取：领取接口，如果领取胜利，新增一条领取信息，订单状态更新为已领取，新增一条物流信息。
  • 接口的性能次要是客户端和服务端的数据交互，即通过接口对后端数据的增删改查，来实现用户和产品的交互。

1.2 如何保障接口品质

从京东网站的注册接口来看，咱们须要从哪些纬度保障品质。

剖析注册接口

注册页面：

Http 注册接口：

Request Header:

Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7
Connection: keep-alive
Content-Length: 6028
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cookie: shshshfpb=sJZnAsUTcZJjuNedVMhztBA%3D%3D; 
Host: reg.jd.com
Origin: https://reg.jd.com
Referer: https://reg.jd.com/reg/person?ReturnUrl=https%3A//www.jd.com/
sec-ch-ua: "Google Chrome";v="89", "Chromium";v="89", ";Not A Brand";v="99"
sec-ch-ua-mobile: ?0
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 11_2_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36
X-Requested-With: XMLHttpRequest

Request Body：（疏忽局部无奈解读参数）

uuid: 68455e864c894bda845de413849204d0
authCodeStrategy: 1  (验证码策略)
phone: +00861553605xxxx（手机号）mobileCode: 116547（手机验证码）regName: demo83520（注册的用户名）email: xxx@163.com（注册邮箱）mailCode: 661591（邮箱验证码）pwd: MvaEqtzkZ4/R4P3wMoRIuZpA4egWYBmz7bikspIWRYwozJgOHJQlQW8POp8elFhi7OXchoz1OPRoFwxqjWpwcWQCUABx5oovhFxLZ0p8CqB3s0lNDz9QlF8ZYMBanwk+Cne4mXMOTop9OGD8XF8YPqb4qkox8A=（明码加密字符串）

接下来，从接口开发设计角度，剖析注册接口。因为是纯黑盒角度，所以从 UI 交互和接口参数两方面剖析注册接口的设计逻辑。

UI 交互角度剖析

  • 同样手机号、不同邮箱最多能够注册 3 个账号；
  • 用户名：反对中文、英文、数字、”–“、”_”的组合，4-20 个字符，不能是纯数字；用户名不能反复；
  • 明码：长度只能在 8-20 个字符之间，倡议应用字母、数字和符号两种及以上组合；不能频繁注册；

接口参数剖析（取几种主要参数）

  • uuid：用户惟一 ID？uid 生成规定？
  • phone：注册手机号格局校验？
  • mobileCode：手机验证码位数、字符类型校验？
  • regName：用户名规定校验？
  • email：注册邮箱格局校验？
  • mailCode：邮箱验证码 位数、字符类型校验？
  • pwd：明码加密后字符串

2、如何测试接口

接口测试，次要分三步：

  1. 筹备测试数据（可能不须要）；
  2. API 测试工具，发动申请；
  3. 验证返回后果的 Response；

（1）测试数据

测试数据生成形式：

  • 基于 API 生成数据；
  • 数据库间接结构数据；
  • UI 操作生成数据；

生成机会：

  • 实时创立：测试用例执行过程中生成（会导致测试用例执行工夫变长）；
  • 当时创立：测试执行前，批量生成所有测试数据（可能当时创立好的数据曾经被批改而无奈失常应用）；

留神⚠️：测试环境不稳固，会影响测试数据的顺利创立；

脏数据：

  • 概念：脏数据是指，数据在被理论应用前，曾经被进行了非预期的批改。

测试数据分类：

  • “活水数据”：指绝对稳固，不会在应用过程中扭转状态，并且能够被屡次应用的数据。这类数据适宜当时创立。

留神：“活水数据”是绝对稳固的，是否稳固由测试目标决定。比方用户数据，在测试非用户相干测试时根本稳固，然而对于专门测试用户账号的测试用例来讲，往往波及到用户登记之类性能，所以此时就是不稳固的。

  • “活水数据”：指只能被一次性应用，或者常常会被批改的数据。例如 优惠券、订单之类的数据。

（2）测试用例设计

用例设计从两个维度来设计，功能性需要和非功能性需要。

功能性需要

用例设计法参考：软件测试根底—流程和用例设计办法 -piecesof

非功能性需要 – 平安纬度

  • 敏感信息是否加密：明码前后端传输是否加密
  • sql 注入？（联合用户的输出数据动静结构 Sql 语句，如果用户输出的数据被结构成歹意 Sql 代码，Web 利用又未对动静结构的 Sql 语句应用的参数进行审查，则会带来意想不到的危险。）
  • 逻辑破绽：
    批量注册反复生产问题？（比方，同一时间，同样的参数，高并发申请，是否只有一个 Http 申请注册胜利）
    同一手机号，不同邮箱，是否能够注册超过 3 个用户？

非功能性需要 – 性能纬度

  • 基准性能是否达标？比方单申请要求小于 500ms？
  • 高并发性能评估：通过性能测试伎俩，评估注册接口性能。具体查看：服务端性能测试 – 入门指南 和 服务端性能测试 – 工具篇

功能性需要纬度：利用正交法，起码也有 29 条用例。
非功能性需要纬度 – 平安纬度：4 条用例。
非功能性需要纬度 – 性能纬度：2 条用例。

（3）如何做接口断言？

  • Http Response 断言：
    Http 状态码
    Response Body 字段、构造 校验
    Response Header
  • 数据断言：
    对数据库中的数据断言
  • 响应工夫满足要求吗？

3、如何用接口测试一个零碎？

（1）简单零碎测试用例构造

参考：HttpRunner 之 step/case/suite

测试步骤 (testStep) -> 测试用例 (testCase) -> 测试场景 / 测试用例集 (testSuite)

测试步骤 (testStep)

对于接口测试来说，每一个测试步骤应该就对应一个 API 的申请形容。

测试用例 (testCase)

测试用例（testcase）应该是为了测试某个特定的性能逻辑而精心设计的，并且至多蕴含如下几点：

  • 明确的测试目标
  • 明确的输出
  • 明确的运行环境
  • 明确的测试步骤形容
  • 明确的预期后果

测试用例设计准则：

  • 测试用例应该是残缺且独立的，每条测试用例都应该能够独立运行；
  • 测试用例由测试脚本和测试数据两局部形成。
  • 测试脚本：测试脚本只关注被测的业务性能逻辑，包含前置条件、测试步骤、预期后果等。
  • 测试数据：是对应测试的业务数据。
  • 测试数据和测试脚本拆散：不便实现数据驱动测试。通过对测试脚本传入一组数据，实现同一业务性能在不同数据逻辑下的测试验证。比方：购买商品接口，会员和非会员的商品价格是不一样的，优惠券逻辑也不一样。所以通过不同的用户数据，能够测试会员和非会员购物逻辑。

测试用例集 (testSuite)

测试用例集是测试用例的无序汇合，汇合中的测试用例应该相互独立，不存在先后依赖关系。

如果的确存在先后依赖关系，例如登录性能和下单功能。正确的做法应该是，在下单测试用例的前置步骤中执行登录操作。

（2）测试数据治理

起源：测试框架中的数据管理策略

数据的两个属性：

  • 作用域：共享数据（实用于 testSuite 级别）、隔离数据（实用于 testCase 级别）
  • 创立形式：调用开发接口、应用 Sql、独立开发数据模版

测试数据的作用域

共享数据：所有 case 或一部分 case 独特应用的测试数据

  • 长处：速度快，数据只须要创立一次就能够给很多 case 应用。
  • 毛病：
    数据为很多 case 筹备的，你很难分清哪些数据是给这个 case 筹备的，哪些数据是给另一个 case 筹备的。case 的可读性低
    case 之间相互有影响。因为待测的性能自身就会对数据库造成影响。很可能一个 case 的失败或者胜利就会造成一批 case 的 fail
    数据自身不能扩大，略微一改变，影响就很宽泛。数个甚至数十个 case 的失败是很常见的。保护脚本的老本比拟高

隔离数据：每个 case 都有独享测试数据，case 之间互不影响，即每个 case 都做 setup 和 teardown 的操作。case 执行前发明数据，执行后销毁数据。

  • 长处：case 之间互不影响，数据之间互不影响。case 的稳定性，可维护性，可读性等都大大提高
  • 毛病：速度慢。。。。灰常慢。。。因为每个 case 都有很多的磁盘 IO 操作。。。保护数据的工夫比调用性能的工夫都要长的状况并不奇怪。OK，这种形式其实是咱们在测试中使用的最多的形式。尽管它很慢，而且对很多人来说实现起来也比拟难。然而它带来的可维护性切实太迷人。我再也不必终日保护那些不稳固的脚本了。慢点就慢点吧。反正咱们做接口测试和 UI 自动化测试的继续集成策略也是定时运行的。跑个 10 几分钟，几十分钟的我也不在乎。只有不是做监控代码变动的策略，所有好说。

敏感数据：账号、明码、key 等敏感信息，设置为有权限限度的环境变量。

  • 敏感信息不能公开的次要起因：
    增强权限管控：参加我的项目的开发人员可能会有很多，大家都有读取代码仓库的权限，然而像 key 这类极度敏感的信息不应该所有人都有权限获取；
    缩小代码透露的危害性：如果代码呈现透露，敏感数据信息不应该也同时透露。
  • 举荐的解决方案：
    对服务器进行权限管控，只有运维人员（或者外围开发人员）才有登录服务器的权限；
    运维人员（或者外围开发人员）：在运行的机器上将敏感数据设置到零碎的环境变量中；
    一般开发人员：只须要晓得敏感信息的变量名称，在代码中通过读取环境变量的形式获取敏感数据。

如何结构数据

调用开发接口

  • 长处：在脚本中实现起来绝对简略，不必深刻了解后盾数据库。
  • 毛病：
    耦合性太高，依赖产品的其余接口发明数据的形式注定了 case 是非隔离性的。留神隔离性是 case 品质的一个重要指标。一旦发明数据的接口 bug 了，你说得有多少个 case 失败。而且在实在环境中，须要调用 N 个接口去发明你须要的数据。无奈判断到底哪个接口的 bug。这未然变成了端到端测试了。可能疾速定位 bug 地位，也同样是 case 品质的重要指标。
    如果做隔离数据，产品中的接口往往很难满足你销毁数据的须要，举个最常见的例子。这个世界存在一种删除机制叫做逻辑删除，也是就是产品的接口并不是真正的删除了数据库中的数据，而是用一个逻辑标示位，标示这条数据被删除了。不要再反馈给用户了。这样其实就做不到“隔离数据了”
    应用倡议：不倡议应用。尽管该形式脚本保护成本低，然而造成用例耦合度高、隔离性差，问题定位老本高。一个被调用开发接口的 BUG，可能会导致大量用例失败。

间接应用 sql：就是间接写 sql 发明和销毁数据。

  • 长处：隔离性和 bug 追踪都很好。
  • 毛病：如果交给测试人员在脚本中写 sql 的话，难度，可读性都不太乐观，而且太依赖测试人员自身的能力，出错率较高。不过好在咱们能够在测试框架上做一些手脚，解决这个问题。
  • 应用倡议：除查问 sql 外，增删改 sql 谨慎应用，因为实现老本高、操作危险高。须要十分理解数据库表构造和业务逻辑，删改数据很可能影响理论业务或其他同学测试。

数据模版：为外围业务测试数据，创立独立的数据模版，专人独立保护。

参考：测试能效平台的诞生 – 国际化商城智能物料平台

  • 实现思路：
    对于数据结构较简单，且数据关联业务多、异样数据危险高的数据（比方电商的物料数据），倡议基于开发接口封装通用函数，且针对性的做好异样解决和定位。
  • 长处：
    专人开发保护，极大升高构建简单数据老本和危险
    升高功能测试结构数据精力，冲破相干测试人力占用瓶颈。
  • 毛病：开发成本高，应用重量级业务零碎

4、接口测试进化

回顾一下后面接口测试的内容，发现几个问题：

  • 简单零碎动则几千个接口，回归测试工作量大；
  • 用例编写老本高，参数多的接口
  • 能够参考如下几个案例，对接口测试做一些生产力的晋升。

（1）回归测试工作量大？录制线上流量回归

参考：录制线上流量做回归测试的正确打开方式

（2）用例编写老本高？通用接口自动测试计划

参考：通用性接口健壮性扫描计划

（3）疾速校验接口数据结构变动？接口自动化全量字段校验

起源：接口自动化全量字段校验

实现：自定义接口返回数据格式 (【契约定义】)- 理论响应数据格式校验 (【契约校验】) 的性能

校验准则：

  • 理论返回字段名要严格等于或者含契约定义字段名 (依据不同匹配模式来确定)
  • 字段值能够值相等或类型相等

本文由在路上首发于 TesterHome 社区，原文链接 https://testerhome.com/topics/29928
是一篇外部分享文档，意在从根底到深刻分享单接口测试及零碎接口测试内容。此文借鉴和援用了多位同行的文章内容，均已标注内容起源。大家可通过链接查看相干内容原文。

以上是明天的分享，你学废了吗~

想学习更多干货常识和前沿技术？

想结识测试行业大咖和业界精英？

欢送关注 2022 MTSC 大会（第十届中国互联网测试开发大会）

业界对 MTSC 大会的评估：落地、求实、有深度、重分享

中国互联网测试开发大会 Testing Summit China，是由 TesterHome 发动的软件测试开发行业技术会议。还有个别名：Make Testing Super Cool！

MTSC 大会以软件品质保障体系和测试研发技术交换为次要目标，始于 2015 年，已胜利举办了九届。共有 1000+ 家企业，10000+ 测试工程师、测试经理、CTO 参会，受到了全行业的宽泛关注，是中国互联网质量保证行业的顶级会议。

为了保障议题品质，每年都会提前半年进行议题征集，再通过历时数月的审核，最终确定在大会分享的议题。MTSC 2022 的议题还在征集中，诚邀各位资深测试技术专家、品质治理经理和测试新秀们自荐 / 举荐议题！

提交议题形式

间接点击 https://www.wjx.top/vj/wZwCju… 进入投递入口，依照格局进行填写并提交即可，欢送自荐 / 举荐议题。

议题截止工夫

为便于评审组有更充沛工夫进行评审及与讲师进行沟通优化，为宽广参会者出现更好的议题，议题投稿（可无 PPT，有纲要等议题信息介绍即可）投递截止工夫提前为：2022 年 3 月 30 日

议题征集评比流程

总体流程：案例提交 > 初审核定 > PPT 提交 > 确认议题 > 会议演讲

总体工夫节点：

案例提交 >> 3 月 30 日

初审核定 >> 4 月 15 日

ppt 提交 >> 5 月 15 日

议题确认 >> 5 月 30 日

会议演讲 >> 7 月 22~23 日

分享讲师福利

  1. 锤炼演讲能力，加强集体品牌
  2. 取得和业内专家面对面交换的机会，博采众长
  3. 晋升公司品牌，给本人的团队减少吸引力
  4. 获取收费的大会门票和材料：
    每位讲师都会获赠 1 张大会门票，大会后续的 PPT 和视频都会第一工夫给到讲师
  5. 当地讲师由 MTSC 大会组委会承当差旅费用
退出移动版