Insomnia:开源Rest client使用心得

Insomnia : 开源 Rest client 使用心得

1. 简介

 Insomnia，一款开源的、跨平台的、桌面应用级的Rest client。

 与Postman、Apifox是一类工具，用于接口管理、测试。主要支持http-based协议。

2. 安装及简单使用

2.1 安装

 Insomnia官网安装地址.

 Kong/Insomnia-Git地址.

2.2 简单使用

 虽然网上上关于Insomnia这款工具的使用教程挺少的，但是其基础功能与常见的接口工具基本相同，因此也不是很难上手。所以我也偷个懒，想了解基础功能使用的朋友们，可以去官网看看，基本上面都有些，包括一些进阶的教程，如Templates tags、request chain之类的。下面我也提供了一篇可以参考的文章，写得挺详细的。

 Insomnia官方文档.

 Insomnia基本使用方法总结博客.

3. 为什么使用Insomnia

 成熟的接口测试工具非常多，诸如Postman、Jmeter、国内的Apifox，这些工具的功能都十分完善、生态也比较丰富，为什么我们要用偏冷门的Insomnia呢？每个团队在做技术选型时，需要考虑的东西很多，例如：易用性、契合度、技术成本、经济成本、是否易于二次开发等等。易用性方面，Insomnia与同类工具类型，都非常容易上手，相关文章虽少，但官网内容比较全面；成本方面，Insomnia免费版就能很好的通过Git进行团队协作，而同样的功能在Postman、apifox（不花钱只有sass版，不太适用）都是需要付费的，节约成本也是老板最喜欢看到的；二次开发方面，Insomnia的相关插件可以使用Nodejs编写，难度也不是太高；

 总结一下，Insomnia这款软件，免费版基础功能强大、支持团队协作、方便二开。

4. Design模块

 作为测试人员，刚接触这款软件时，更多的是使用Debug、Test模块，Design使用得很少。软件原话写的是:“Supported version fields are swagger:‘2.0’ and those that match openapi:3.0.n”。简而言之，Design模块中可以导入swagger、openapi用于共享api规范。

 我这以导入swagger为例：

 打开swagger网页后，点击图上框出来的连接，会显示Json格式的swagger，直接复制到Design模块就导入完成了。

 如果swagger报错的话，导入后Insomnia同样也会显示相关的错误信息，我们可以通过提供的details定位到错误的地方

 导入后，面临数量众多的接口，我们可以通过左侧的path进行手动点击查找或者搜索

5.Debug模块

 这里我只记录一些总结的进阶用法。

5.1 环境设置

 Insomnia的environment分为base和sub两种，base则是针对整个工作区的环境，sub则是用户在base基础上自己新建的。因此我们可以将一些工作区内公用的、稳定的variables定义在base environment中，而一些自定义的、常变化的则可定义在sub environment中。

 其次，sub environment中还包含普通的和private两种，private的特点是“will not be exported or synced”，导出以及上传git时，private environment是不会包含在里面的。

5.2 request chain相关记录

 在做接口测试时，我们最常遇到的就是接口依赖。与自己编写代码相比，使用工具实现接口依赖以及相关自动化就没那么灵活。同样，在使用Insomnia实现接口自动化时，也有一些坑，这个稍后再提。

 在Insomnia中，我们通常使用template tags来解决接口之间的依赖问题。tag可以说是这个软件的一大特色，功能比较强大，除了前面提到解决接口依赖，他还提供了一下功能：

 如图中的hash、uuid、各种类型的时间戳，除此之外，我们还可以二开自定义一些tag，例如一定范围的随机数。

 回到接口依赖问题，如果我们要将一系列的接口串联起来，我们就需要选择图中的Response Function。这个功能可以让下游接口去获取上游接口的response body的单个属性、整个response body、response header、请求的url。

  我们最常用的就是获取response body的单个属性，在tag里，我们可以通过Jsonpath或Xpath来对response body进行筛选（用哪种方法筛选取决于返回的是Json还是XML）。筛选完成后，我们可以在Live Preview里预览筛选结果。最后我们需要在Trigger Behavior中设置，下游接口何时去请求上游接口，Insomnia提供了4个方案。

 （1）Never resend request，顾名思义，永不重新请求，以最初的为准

  （2）No History – resend when no responses present

      在Insomnia中，请求完成后，会生成response history，用户可以查看history、删除当前response、清除所有response history。

  （3）When Expired – resend when exsting response has expired

    设置一个过期时间，一旦过期则重新请求。

  （4）Always resend，顾名思义

 如何设置，需要参考接口需要调用的参数的特性。如果是一个删除接口，tag里需要去获取一个id，这里就需要保证这个每次返回的id都是存在的，且状态是可以删除的。选择前两个则无法很好的保证接口返回值正确。

6.Test模块

 这个模块测试人员用得较多，可以通过创建一些测试套件、测试用例、编写一些断言，实现接口的自动化。

 支持Js编写断言，语法也比较简单，具体可以参考： Chai Assertion Library.

 在用例里输入"send"，则会弹出发送请求的窗口，在编写断言需要其他接口支持时，这个功能比较有用。

7.那些年遇到的坑

 开源软件是一座围城，外面的人想进去，里面的人想出来。

 Insomnia这款软件真是让我又爱又恨。我爱她简洁又不是格调的外表，爱她能为我的boss节约经费，爱她模块明确、功能健全，但世上没有完美的软件，就像青春总是充满着遗憾。

7.1 使用 template tag处理上下游接口之间的参数依赖时，灵活性较差

 虽说template tag是insomnia最具特色的功能，没有之一，但成也萧何，败也萧何。

 比如：上游接口返回数据

｛
	"records":[
				{
					...
					"id" = "123",
					"state" = 1,
					...
				},
				{
					...
					"id" = "456",
					"state" = 0,
					...
				}
				{
					...
					"id" = "789",
					"state" = 0,
					...
				}
​              ]
｝

 此时，下游接口需要state为0的数据的id，如果使用template tag，并用如下JsonPath进行筛选：

$.records[?(@.state==0)].id

 筛选结果是个array，并无法进一步选择:

[
	"456", "789"
]

 template tag显示 :

Returned more than one result: $.records[?(@.state==0)].id

 issue里已经有兄弟伙提过这个问题了，奈何官方貌似兴趣不高。。。本人也是暂时没有想出替代方法。

7.2 unit test里无法获取环境变量

 例如：在编写一些高级查询的单测时，需要校验请求的参数与响应的结果是否相符。

 但在unit test里，没有找到能获取request参数的api；也无法像postman一样，将查询的条件存在环境变量中，并通过pm.getEnvrionment()这样的api来获取，并做断言校验。

7.3 测试用例无法调整顺序

 在做接口自动化时，由于接口之间有依赖关系，因此哪个接口先跑，哪个接口后跑是需要精心设计的，这样才能保证整个接口自动化的成功率。但是Insomnia貌似不支持调整创建好的用例的顺序。因此后期迭代时，修改用例就比较痛苦了。