接口测试平台搭建功能分享及心路历程【1】

故事1：接口和测试数据分离

做过接口测试的朋友应该都知道，接口的URL一般都不会变，在测试中多变的是请求头和请求体。
如果没有测试数据分离，当我们对一个接口进行多次请求测试时，就会形成很多条同时带有URL、消息头、消息体的脚本，如果这个接口一旦发生变化，每条数据都需要去修改，工作量是非常大的。

解决问题：使用参数入参的方式解决该问题

我们认为接口和测试数据是可以完全分离的，只要定义好接口模型，在需要测试的时候，把接口模型拿过来，进行数据的入参就可以了。
我们可以在接口的URL、headers、body，定义参数，格式是$，例如${exmaple}
只需要把在测试中该接口需要变化的地方，定义为参数就可以了。

这样我们的接口模型就定义好了。至于怎么入参，由于入参的方式非常多，放到后面详细介绍

---

故事2： 接口的协同

如果我们多人测试多个接口的时候，完成一个完整的流程，需要调用到其他人的接口，但我并不测试这个接口，如果我们需要从头调试用到的每个接口，也是非常繁琐的，会导致测试效率低下。

解决问题：

所以我们可以为接口模型定义名称，要求大家把接口名称定义得一看就知道是干啥的，并可以添加备注。让大家养成习惯，需要用到不是自己测试的接口，先去搜索一下，有没有人已经录入了这个接口模型，如果没有搜索到，可以直接根据URL进行搜索，以防疏漏，也可以校对他起的名字是不是容易找得到。

---

故事3：测试场景脚本的解耦和协同

当做接口测试涉及到多个接口，以及接口之间有流程关系，且有数据的依赖关系的时候，我们的场景脚本就会变得复杂起来了，当我们使用工具例如就jmeter编写时，往往会出现几个完整的测试场景，大部分是相似的，但又有些许的不同，一般这个时候测试的同学们就会写好场景1，整个copy一下，去修改为场景2。这样带来两个问题：首先你得了解场景1和场景2的区别，并知道在脚本中应该怎么修改，这一开始你可能很容易做到，但过了3个月后，很难再知道自己想干什么，更别说让其他人去跑你的脚本了。其次是一旦这个场景需要修改，你几乎不愿意在原有的脚本上进行修改，一般都会是重写的。那也会极大的降低了测试的效率

解决问题：拆解脚本为最小功能集，并可以进行拼装

我们认为一个复杂的测试场景，是可以进行拆解的，他是最小粒度的接口集合，他有很具体的功能，但他需要超过1个接口的调用，才能完成。
例如：【把 商品名称=“雨伞”，店铺=“京东京造”的所有商品加入购物车这样的操作】
那么可能需要调用两个接口：调用查询商品接口，传入：商品名称=“雨伞”，店铺=“京东京造”
然后把所有ID提取出来，作为加入购物车的接口的入参，再调用加入购物车接口。

我们认为这是一个最小粒度的测试场景，我们称之为场景模型。为什么是模型，因为你直接调用这个场景，是无法成功的，他就像代码里的函数（方法）一样。有入参，有具体实现，有出参。
还是上面的例子，那么这个场景模型的入参就是：商品名称=“”，店铺=“”，用户token。
出参就是：是否添加购物车成功
我们可以给这个场景模型的起个名字：通过商品名称和店铺名称，添加商品到购物车。

当我们在写测试脚本时，不再是写具体的脚本，而是从抽象的维度去思维问题，从最小功能集的拆解去思考，去写脚本，那么我们的场景模型就会越来越多，而且这些场景是活的，是可以给其他人使用的，他不需要了解具体的实现，只需要知道这个场景模型的入参是什么，然后再看出参就可以了。随着时间和模型的积累，我们的测试脚本编写过程就会越来越高效而且准确。

拼装这些场景模型成为一个完整的测试场景脚本，我们称为用例模型，为什么用例也叫模型，因为用例也是可以入参的。
在用例模型中，可以直接选择写好的场景模型、接口模型进行组合，并可以进行自定义入参，这样就可以快速的形成完整的用例，不再在花精力在调试接口、调试场景上

---

故事4：多系统协同环境的管理

在我们进行测试时，可能有这样一种情况：接口A是系统1的，接口B是系统2，此时我需要在一个测试过程中，同时调用他们。你一定会说，那直接在接口A和B里分别写上系统1和系统2的IP就好了呀，
这当然可以，但如果出现切换环境呢，系统1和系统2组成一个完整的环境。有测试环境、开发环境、UAT环境、灰度环境、生产环境。环境可能还有系统3、4、5、6…如果解耦，一键切换环境呢？当某个系统的ip发生变化时，怎么去修改呢？

解决问题：

给接口录入环境不在是具体的ip，而是一个序号，例如接口A，归属系统1，那么他的实际存储的是序号1，而不是系统1的IP端口。我们再做一个环境管理，一个环境，可以录入多个系统，系统1、系统2、系统3…当请求这个接口的时候，我们给过去的是整个环境信息，系统发起请求时，自动通过序号寻址到具体的ip。这样就完全做到了解耦，写接口时不需要再关心环境应该怎么写，选好序号，有变化修改环境就可以了。

---

故事5： 公共参数管理

我们知道做接口测试有些参数每个接口都必须要传的，最常见的就是sessionId或token了，有些可能需要传usrName、appKey等等。这些是公共的，写到某个接口、场景、用例里，都不合适，也不方便修改。

解决问题：

我们提供了运行参数管理，当运行时，自动的将运行参数里的所有值，作用于每一个接口、场景、用例，当需要切换的时候，选择另一个运行参数集，点击运行，就会立即发生变化。

---

故事6： 接口的加密管理

测试过需要加密的接口的朋友们应该知道，有一些加密算法需要把请求里body的每个字段都要参与加密，而我们的body大多情况下是我们的测试数据，是随时变化的，这可能直接导致很多朋友们直接不知道脚本怎么写了，没法做到自动加密了，需要先写好请求体，然后加密一下，得到了加密的结果，再放置到请求里，才能完成一次加密接口的测试。

解决问题：

我们在接口模型里提供了最后前置脚本功能，这个功能就是专门针对这种情况而生的，只要你在里面写好加密的逻辑，你就不需要再去管加密这个事情了，系统完全自动的为你完成，甚至是在运行中对请求体进行二次入参，都不会影响加密的效果。

---