|
|
# 06 | 接口测试平台：工具和框架不可以兼容？
|
|
|
|
|
|
你好，我是陈磊。很高兴在接口测试课程中再次遇见你。
|
|
|
|
|
|
到目前为止，我们的课程重点介绍了完成测试任务的两种接口测试手段，第一种是使用如Postman这样的工具，第二种是打造属于你自己的测试框架。上节课我们还一起学习了RESTful风格的接口，并针对它的特点完善了我们自己的测试框架。
|
|
|
|
|
|
这节课我就教你如何用工具和框架的组合搭建接口测试平台，让你能更快速地完成测试任务。
|
|
|
|
|
|
## 工具的便捷性与框架的灵活性可以兼得
|
|
|
|
|
|
说到这儿，你一定有一个困惑，在前面我先讲了Postman这款非常好用的HTTP测试工具，后来又讲了怎么自己动手封装接口测试框架，它们各有特点，比如工具有便捷性，框架有灵活性，这无疑是两条都可以通向罗马的路，是两种都可以完成接口测试工作的方法，那学会一个不就可以了，为什么两个都要学会呢？
|
|
|
|
|
|
而且工具和框架，这两件事看起来互不相干，甚至有些互相排斥，那么这两种接口测试技术手段能相互支持，能融合到一起吗？下面我就来回答这个问题。
|
|
|
|
|
|
其实，工具和框架，这两条通向罗马的路可以并成一条快速通道，让你大踏步进军罗马。所以我既建议你要掌握一款好用的工具比如Postman，也建议你用自己的技术沉淀出自己的框架，如果你能正确地混合使用它们，实质上就可以搭建起一个接口测试平台，帮你更快速地完成测试任务。
|
|
|
|
|
|
在脚本的设计过程中，这样做有两个好处。
|
|
|
|
|
|
一是能充分发挥Postman界面化的优势，快速完成大量的脚本撰写工作；二是通过你自己的框架完成测试脚本的执行，所有的过程代码都会存储到你自己的代码仓，这样，既可以留下测试的过程资产，也便于版本控制，这也为持续集成、持续交付等平台提供了无人值守的、按需驱动测试的途径。
|
|
|
|
|
|
|
|
|
此外，这样做也可以提升团队的工作效率。
|
|
|
|
|
|
在我的团队中，有一些小伙伴很不喜欢写代码，相反，他们更喜欢使用工具，工具用得也非常溜，我相信在你的团队中也会存在这样的情况。但是，仅仅依靠工具，只能一个人完成一件事情，这并不方便团队内部的团队合作、交接和技术积累。
|
|
|
|
|
|
但是，我们又没有办法让所有人一下子都喜欢上写代码，那么该如何降低代码编写门槛呢？通过工具和框架搭建接口测试平台，其实就是一个很好的解决方案。这样，你既可以让你的团队有技术积累，又能给团队中一些编码能力比较薄弱的小伙伴学习时间，最重要的一点是，这不会影响整个工作的进度。
|
|
|
|
|
|
## 工具的便捷性可得
|
|
|
|
|
|
不知道在学完前面的课程后，你是不是还用过自己的Postman，当你再次打开Postman的时候会发现，你之前用它来完成的测试脚本是被保存下来了的，就如下图所示：
|
|
|
|
|
|
|
|
|
|
|
|
可以看到，我上次使用Postman测试“战场”系统的脚本还是存在的，如果你忘记了，可以在课后看一看你用来做测试的Postman，再分别看看那四个请求。
|
|
|
|
|
|
到这里，我想请你先闭上眼睛回想一下，你之前使用Postman做接口测试的整个流程，是不是清晰可见？你也可以同时回忆一下，你用自己封装的Common类，编写“战场”系统测试脚本的过程。你会发现，和工具的使用过程相比，在这里你不太容易回想出自己每一步都做了什么。
|
|
|
|
|
|
这也是UI操作和代码操作的区别之一，UI操作更加直观，可以在你的脑海里留下更深刻的印象；而代码操作给人留下的印象就比较模糊，但是，通过用代码写脚本来完成接口测试，比较便于维护、团队合作以及留存。
|
|
|
|
|
|
讲到这你肯定会问：“你把用Postman类工具完成接口测试，以及自我封装测试框架这两种方法各打五十大板，那它们到底哪个好？”其实我的目的并不是想让你分出个好坏，好坏之分都是相对的，每个人的习惯和喜好都不相同，但是我们却可以把它们的优点都利用好，把这两种技术的优势都发挥出来。
|
|
|
|
|
|
我们利用Postman设计接口测试直观、快速的优势，将它变成接口测试脚本的初始脚本的编写工具，其实Postman也可以配置Chrome插件录制请求，这些在Postman官方已经有很详细的介绍，所以我就不在这里详细讲解了，如果你感兴趣，课后可以自行学习。
|
|
|
|
|
|
我们以之前的测试脚本为例，选择第一个单接口接口测试的脚本，在右侧点击Code按钮。
|
|
|
|
|
|
|
|
|
|
|
|
在弹出框中，你可以选择各式各样技术栈的测试脚本，在这里，我们还是用在之前例子中所选取的Python，我们框架的依赖库是Requests，这样你就可以看到显示出的代码了，就如下图所示。看到这些代码，你是不是已经开始觉得，通过这样的处理来编写脚本更加容易。
|
|
|
|
|
|
|
|
|
|
|
|
由此可见，和写代码相比，使用Postman来设计接口测试要更容易使用，对于代码基础比较薄弱的测试工程师来说，这种方法也更容易掌握。
|
|
|
|
|
|
## 框架的灵活性亦可得
|
|
|
|
|
|
在刚刚高兴的心情慢慢冷静下来以后，你是不是在心里默默地埋怨我？既然有这么简单的方法，为什么还一直让你学习一门编码技术，还建议你如果什么都不会，可以学习一下Python？这是因为工具生成的代码可读性特别差，也并不适合我们将它作为团队的技术积累留存。
|
|
|
|
|
|
现在，我们一起看一看由工具生成的代码。先来看看第一个接口首页单接口对应的代码：
|
|
|
|
|
|
```
|
|
|
import requests
|
|
|
|
|
|
|
|
|
url = "http://127.0.0.1:12356"
|
|
|
|
|
|
|
|
|
headers = {
|
|
|
'cache-control': "no-cache",
|
|
|
'Postman-Token': "8c6247bb-744a-43d3-b27d-9e51af923c5d"
|
|
|
}
|
|
|
|
|
|
|
|
|
response = requests.request("GET", url, headers=headers)
|
|
|
|
|
|
|
|
|
print(response.text）
|
|
|
|
|
|
```
|
|
|
|
|
|
上面的这个代码你是不是似曾相识？这就和我们第一次写的第一个接口的单接口测试代码一样，是一个流水账一样的脚本，这些代码如果原模原样地存到你的代码仓中，对你再次使用它没什么好处。那么在这基础上，我们可以将它修改成自己框架的脚本，就如下面这段代码所示：
|
|
|
|
|
|
```
|
|
|
# 引入你的框架
|
|
|
from common import Common
|
|
|
#访问uri
|
|
|
uri_index = "/"
|
|
|
#调用你的Common类
|
|
|
comm = Common('http://127.0.0.1:12356')
|
|
|
# 完成方法
|
|
|
response_login = comm.get(uri_index)
|
|
|
# 打印response结果
|
|
|
print('Response内容：' + response_login.text)
|
|
|
|
|
|
```
|
|
|
|
|
|
这个代码你是不是很亲切？Common类可是我们的老朋友了。那么接下来，我们再看看第二个接口登录的单接口测试脚本，你可以用相同的方法，找到它的Python代码，为了方便有些不是很方便打开自己Postman的同学，我把对应的代码放到了下面：
|
|
|
|
|
|
```
|
|
|
import requests
|
|
|
|
|
|
|
|
|
url = "http://127.0.0.1:12356/login"
|
|
|
|
|
|
|
|
|
payload = "username=criss&password=criss"
|
|
|
|
|
|
|
|
|
headers = {
|
|
|
|
|
|
|
|
|
'cache-control': "no-cache",
|
|
|
|
|
|
|
|
|
'Postman-Token': "fdc805e1-4406-4191-ae44-ab002e475e03"
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
response = requests.request("POST", url, data=payload, headers=headers)
|
|
|
|
|
|
|
|
|
print(response.text)
|
|
|
|
|
|
```
|
|
|
|
|
|
如果你还记得我在测试代码及框架那一节课（也就是[04](https://time.geekbang.org/column/article/195483)）中讲的内容，就会发现，它和那里最开始部分的代码实现几乎一致，这和我们自己手动写的代码最大区别就是，它少了很多注释，而多出一些访问头信息，也就是上面代码的headers。
|
|
|
|
|
|
headers在我们“战场”系统的测试中并不是必须传递的参数，但是Postman这种工具会将其添加默认值传递给服务器。这是由这个工具添加的，你在写脚本时，如果它是非必填的，你可以忽略它。但是，工具这么做是为了匹配所有的情况，所以它会做一些和我们这次测试不相干的工作。
|
|
|
|
|
|
难道说Postman这么好的功能，对我们来说就没有一点好处吗？其实我们在上面代码的基础上，将其修改成引入我们自己框架的测试代码，完成修改后，再推送到接口测试项目的代码仓中，就如下面这个代码所示：
|
|
|
|
|
|
```
|
|
|
from common import Common
|
|
|
uri = "/login"
|
|
|
payload = "username=criss&password=criss"
|
|
|
comm = Common('http://127.0.0.1:12356')
|
|
|
response_login = comm.post(uri_login,params=payload)
|
|
|
print('Response内容：' + response_login.text)
|
|
|
|
|
|
```
|
|
|
|
|
|
这也无疑加快了我们测试脚本的编写，在上面这个过程中，我们也很容易再次发现需要封装到框架中的公共方法，这样循环下来，就加快了我们测试脚本的积累速度，同时我们也就可以有更多时间用在框架的维护上了。
|
|
|
|
|
|
通过代码的改写和封装，我们就可以将工具生成的代码完美结合到我们的框架中了，当我们需要修改已经存储在代码仓库的脚本时，我们只需pull 代码仓的代码，就可以看到易读、易维护的测试脚本了。
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
我们今天的课程到这里就结束了，现在你闭上眼睛回顾一下，如果你的头脑中就只有用Postman快速编写脚本，自己框架留存执行的话，只能说明你今天学习得很认真，但是并没接受我想告诉你的主旨思想。
|
|
|
|
|
|
我今天以Postman工具和你自己的框架相结合的例子，告诉你如何建立一个你自己的测试平台，你可以通过三步完成工具加框架的组合方式：
|
|
|
|
|
|
1. 借助Postman这类工具的易学、易操作的特点，将它变成你测试脚本中快速创建的脚本撰写工具；
|
|
|
2. 利用工具提供的导出代码功能，将其导出成我们流程化的测试代码；
|
|
|
3. 通过我们自己的框架，改写我们通过工具导出的脚本。
|
|
|
|
|
|
最后，你的测试脚本可以存入代码仓中为持续集成平台提供持续验证，这就完成了一套简单又灵活的接口测试平台的建设。
|
|
|
|
|
|
实际上，在本节课中，我更希望帮你建立一种解决问题思路，测试工程师的技术普遍会稍微弱于开发工程师，你要善于利用各种技术手段来帮助自己解决问题。
|
|
|
|
|
|
无论你团队中的小伙伴是用Postman生成测试脚本，再通过修改集成自己的框架，还是直接通过框架写测试脚本，它们都殊途同归，都是以最终统一的方式推送到了代码仓库中。这样，就不会让代码能力变成阻塞最终工作的一个关键节点，同时，这对于使用Postman编写脚本的小伙伴来说，他们也会越来越熟悉自己的框架，逐渐提升自己的技术能力，并加强自己的代码能力。
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
今天的课程中，我们把“战场”系统的测试脚本又拿出来测试了一次，不知道你是不是有点厌烦了，今天我仅仅给你演示了第一个和第二个单接口测试脚本，它们从工具到框架的演变过程，那么，你可以将后面的两个单接口测试脚本自己完成，并在留言区回复给我吗？如果你已经开始将这个方法应用到你的工作中了，那么我也希望你能将自己在使用过程中的心得体会分享给我。
|
|
|
|
|
|
我是陈磊，欢迎你在留言区留言分享你的观点，如果这篇文章让你有新的启发，也欢迎你把文章分享给你的朋友，我们一起来探讨和学习。
|
|
|
|