乐趣区

关于前端:如何模拟后台API调用场景很细

jiezi

简介

在开发前后台拆散我的项目并且通过不同团队来实现的时候，如何将后盾设计的 API 精确的传达到前台，是一个十分重要的工作。为了简化这个过程，开源社区做了很多致力，比方 protobuf 技术，swagger 的诞生，以及前面 openapi 的演变，都在试图解决 API 形容和文档的问题。这些规范某些水平上大大简化了 API 文档的撰写和保护，然而 API 设计往往比较复杂，所以另外还有一些痛点没有解决：

  1. 若干 API 的调用程序是有要求的
  2. 若干 API 的输出和输入是互相关联的
  3. 若干 API 须要反复调用达到不同的成果

举了具体的例子, 某后端小伙伴 X 和前端小伙伴 Y 合作开发一款游戏, X 设计好 API 而后 Y 来调用实现:

Y: API1 基本调用不胜利, 得不到我想要的数据? X: balabala 介绍了一遍. (X 默默地欠缺了文档) Y: 如何触发这个游戏逻辑啊? X: 能够参考我的文档 (自信的说) Y: 这个文档基本看不懂啊, 还是给我举个例子吧? X: … balabala 沟通半天

过了几天来了一个新的前端开发 Z:

Z: 如何触发这个游戏逻辑啊 X: …

有时候咱们会发现很多时候 API 文档不足以实现前后端 API 设计的交换, 更多的工夫用在互相沟通中. API 治理平台的诞生，能够说解决了这些痛点. 说起 API 治理平台首先最胜利的的要数 Postman 了，笔者是 Postman 晚期用户，根本应用了大部分的高级性能，近几年开始推广 Team 概念. ApiFox 作为中国的一体化 API 合作平台，从一开始就定位于团队合作，能够说指标十分明确. 目前在尝试从 Postman 迁徙至 ApiFox，发现过程十分晦涩，涵盖了所有目前咱们应用性能.

本文次要介绍两方面内容:

  1. 如何从 Postman 迁徙至 ApiFox
  2. 如何应用 ApiFox 实现展现后盾 API 的调用场景

在介绍第二个方面内容时，尽可能介绍 Postman 对应的性能名称，从而给那些相熟 Postman 的开发者以参考.

Postman 迁徙至 ApiFox

构造比照

首先咱们先理解一下 Postman 和 ApiFox 的治理控制结构，

Postman: Team → Workspace → Collections → Any Level Folders → Request

ApiFox: Team → Project → Any Level Folders → Request

变量管制

两者相似:

  1. 反对全局变量
  2. 反对环境变量及切换

ApiFox 导入 Postman

通过下面的治理控制结构，咱们能够明确晓得，咱们只须要将对应的 Postman 的 Collection 导入 ApiFox 的 Project 中即可.

其中 ApiFox 提供了具体的文档介绍 Postman 的导出以及 ApiFox 导入. 通过测试，目前的 Postman 能够反对所有的数据映射，蕴含了 Postman 中的 Pre-req 和 test 脚本.

导入实现后两者比照，能够发现 Postman 的 Collection 映射到 Project 的 Root Folder 之后的构造齐全是雷同的:

这里惟一美中不足的是, 目前无奈导入环境变量, 应该还在开发中.

对于 Script 的导入

这里须要留神的一点是，在 Postman 中咱们能够间接在 Request 上进行编辑 pre-req 和 test 来管制 Request 的 Response. 在导入后，ApiFox 把默认的数据创立出一个 API Case，这个 Case 蕴含了 Postman 的 script 数据.

举个例子:

这是 Postman 中的一个 API，其中蕴含 Test script

在 ApiFox 中，Request 自身并没有蕴含这个 Script

ApiFox 创立了一个默认的 Passed API Case，而后在这个 API Case 中退出了这个 Script

ApiFox 展现 API 调用场景

介绍完导入工作，上面就开始重点介绍应用 ApiFox 来模仿 API 应用场景. 实现这个指标是基于如下性能:

  1. 有限级别目录
  2. 动静更新环境变量
  3. 每个申请反对 pre-processer 和 post-processer 来解决返回数据，实践上反对任何操作
  4. 测试用例反对增加某个目录来执行

总的来说，通过 ApiFox 的脚本引擎，来模仿客户端的一些操作，从而达到展现 API 应用场景的目标. 本文针对笔者目前应用教训介绍若干脚本的应用办法，如果须要深刻理解脚本零碎，请参考官网文档: 应用脚本. ApiFox 提供了比 Postman 更加弱小的脚本零碎，除了 Javascript，还反对其余语言的调用.

申请的后置脚本

上面咱们通过一个简略的游戏 API 案例来介绍以上性能的应用.

API 接口定义很简略，只蕴含两个 API

  1. Game_init: 初始化用户数据
  2. Game_round: 游戏的玩法很简略，玩家只须要点击一个按钮来进行抽奖，抽奖的后果是随机的，并且可能触发非凡游戏: 比方更换更高级的奖品. API 自身反对调试，就是通过输出参数来返回特定的抽奖后果.

当初咱们的指标就是模仿一次用户开始抽奖并且触发了非凡游戏获取高级处分，并持续抽奖最初获取处分的游戏场景. 通过 API 的接口定义，咱们能够看到 API 的调用逻辑应该是:

  1. 调用 Game_init 一次
  2. 调用 Game_round 屡次，直到游戏完结

所以游戏场景的 API 构造如下图:

咱们应用 Scene1 来示意上述演示的调用场景. 上面咱们开始对每个 API 的 Request 进行解决，从而达到模仿 API 间断调用.

Game_init API 的输出和输入很简略:

输出:

{"gameId": "{{fe}}"，"player": {"isDummy": true}
}

输入 

{
  "player": {
        "playerId": "Demo"，"name": "Demo"，"balance": "1000000"，"balanceRate": "100"，"currency": "FUN"，"isDummy": true
  }
}

Game_init API 调用实现后，咱们须要继续追踪玩家数据的变动，所以这里咱们须要将返回的用户信息贮存在环境变量中，咱们能够通过 Post-processors，增加一个 Custom Script 来实现:

pm.test("Get Response"，function () {var jsonData = pm.response.json();
    console.log(jsonData)
    // we update playerData in the environment
    pm.environment.set('playerData'，JSON.stringify(jsonData.player))
});

这段代码有两个关键点:

  1. 将 API 的返回后果解析为 JSON 数据: pm.response.json()
  2. 将 JSON 数据中的 player 信息出处到环境变量中，并且命名为 playerData: pm.environment.set('playerData'，JSON.stringify(jsonData.player))

实现这脚本后，咱们能够执行这个 Request，而后查看咱们的环境变量信息，playerData 动静增加进来:

Game_round API 的输入输出

输出:

{"gameId": "{{fe}}"，"cheat": {"cheatId": 1}，"player": {{playerData}}，"betContext": {{betContextData}}
}

输入 

{
    "player": {
        "playerId": "Demo"，"name": "Demo"，"balance": "1015000"，"balanceRate": "100"，"currency": "FUN"，"isDummy": true
    }，"betContext": {
        "roundsAwarded": 1，"currentBetMode": "A"，"nextBetMode": "B"
    }，"gameRoundResult": {}}

咱们在解决 Game_round API 的时候和 Game_init 相似，每次失去 Game Round 的返回的 JSON 后，更新 playerData 和 betContextData. 同时咱们还发现，该申请的输出数据同样应用了环境变量 playerData 和 betContextData，从而屡次调用 Game_round API 后，玩家数据和游戏数据是一直进行更新的.

pm.test("Get Response"，function () {var jsonData = pm.response.json();
    console.log(jsonData)    
    // we update playerData and game context in the environment
    pm.environment.set('playerData'，JSON.stringify(jsonData.player))
    pm.environment.set('betContextData'，JSON.stringify(jsonData.betContext))
});

通过这种办法在执行这 3 个 API 的过程中，就能够查看用户数据的变动以及每次游戏后果，从而帮忙前端开发者了解和应用 API.

  1. GameInit 游戏初始化
  2. Round1 进入非凡游戏
  3. Round2 非凡游戏处分

减少断言验证 API

咱们在设计 API 应用场景的时候，能够同时对 API 进行测试. 在不同场景下 API 的返回可能是不同的，所以这里进行测试断言能够更准确的定位问题.

比方咱们上述的案例，第二个申请须要触发用户进入非凡的游戏模式，这里须要后盾 API 反对非凡的测试参数，通过这个参数能够跳过随机后果间接获取须要的后果.

"cheat": {"cheatId": 1}

也就是说如果 Game_round 申请的输出数据中蕴含如下数据，那么这个申请的数据肯定是进入了非凡模式. 在这个案例中就是说，输入的 nextBetMode 肯定是模式 SpeicalMode

"betContext": {
        "roundsAwarded": 1，"currentBetMode": "A"，"nextBetMode": "SpeicalMode"
}

这时候咱们就能够断言: $.betContext.nextBetMode equl SpeicalMode

如果咱们在执行 request 的时候断言出错，就会失去一个 Error，如下图 (这里是成心配置谬误的断言后果)

在 Postman 中这个性能是通过 test 脚本来实现的, 比方 pm.expect(pm.response.json()).to.deep.include("xx");, ApiFox 提供的形式更加人性化.

应用测试执行场景 API 序列

目前咱们上述场景构建的 3 个 API 是手动顺次执行的，咱们还能够创立一个 Test Case 能够一次性执行多个 API. (该性能在 Postman 中是在各级文件夹下的 Run 性能)

首先创立一个新的 Test Case

而后导入咱们之前创立的一组 API Case, 留神这里抉择 API Case, 也就是带有后置脚本的申请.

最初执行 Run，能够看到最初返回的后果

通过这个性能, 后续如果 API 呈现变更, 能够间接运行这个 Test Case 来进行回归测试.

另外相似于 Postman 的 newman 命令行工具, ApiFox 也有本人的 CLI 工具, 通过 CLI 工具, 咱们还能够应用咱们本人的 CI/CD 零碎主动执行这个 Test Case, 从而将 API 测试深刻的交融到整个开发生命周期中.

apifox run https://api.apifox.cn/api/v1/api-test/ci-config/349571/detail?token=xxxx -r html,cli

总结

这篇文章次要介绍如何通过 ApiFox 来构建 API 场景测试，通过后置脚本能够将多个 API 的输出和输入进行串联，从而达到模仿客户端行为的目标. 同时本文还对照了 Postman 的相应的性能，帮忙相熟 Postman 的开发者疾速上手.

基于弱小的脚本引擎, 应用前置和后置脚本实践上能够模仿所有客户端的行为. 当然在进行 API 测试和场景模仿设计的过程中, 并不需要太简单的管制, 只须要对要害数据和场景相干的数据进行管制即可.

官网地址：www.apifox.cn

                                                                  作者：孟新
退出移动版