你好，我是陈磊。很高兴在接口测试课程中再次遇见你。

到目前为止，我们的课程重点介绍了完成测试任务的两种接口测试手段，第一种是使用如 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）中讲的内容，就会发现，它和那里最开始部分的代码实现几乎一致，这和我们自己手动写的代码最大区别就是，它少了很多注释，而多出一些访问头信息，也就是上面代码的 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 编写脚本的小伙伴来说，他们也会越来越熟悉自己的框架，逐渐提升自己的技术能力，并加强自己的代码能力。

思考题

今天的课程中，我们把“战场”系统的测试脚本又拿出来测试了一次，不知道你是不是有点厌烦了，今天我仅仅给你演示了第一个和第二个单接口测试脚本，它们从工具到框架的演变过程，那么，你可以将后面的两个单接口测试脚本自己完成，并在留言区回复给我吗？如果你已经开始将这个方法应用到你的工作中了，那么我也希望你能将自己在使用过程中的心得体会分享给我。

我是陈磊，欢迎你在留言区留言分享你的观点，如果这篇文章让你有新的启发，也欢迎你把文章分享给你的朋友，我们一起来探讨和学习。