你好，我是陈磊。很高兴你又来和我一起探寻接口测试的奥秘了。
我们在前面一起学习了怎么分析和完成一个HTTP协议的接口测试，又一起学习了如何封装接口测试框架，以及如何搭建接口测试平台。我相信，现在你已经完全掌握了HTTP协议的接口测试了。
但是，这还不能说明你已经能独立完成接口测试了，为什么这么说呢？这是因为数据在网络传输上都是依靠一种协议来完成的，在上学的时候，你肯定学过包括TCP、UDP、HTTP等在内的一堆协议，但是如果你遇见了一个全新的协议，你知道怎么从零开始，完成接口测试吗？
今天我就以WebSocket为例，告诉你当你第一次接触一个完全陌生的协议接口时，你要如何开始完成接口测试工作。
作为一名测试工程师，在面对一个陌生协议的接口测试时，你是不是会常常感到很无助？面对这样的任务时，你的第一反应肯定是向开发工程师求助，因为开发工程师基于新协议已经完成了接口开发，向开发工程师求助显然是最好的办法。
我在工作中就遇见过类似的事情。记得那是在我参加工作的前几年，有一个被测项目的接口是一个私有协议，当我看到接口文档的时候，第一反应就是找开发工程师，向他求教一下这个私有协议。这个开发工程师人很好，他给了我一个学习脉络，其中包含了协议的说明文档、代码开发文档、实现代码等内容，我拿到这些资料后，马上按照上面他给出的学习顺序投入学习。
但是后来，在项目从交付测试到完成测试后，我发现自己走了一个弯路。因为作为测试工程师，我们不需要了解协议底层的原理，只需要了解新协议是如何传输数据，又如何返回数据库就可以了。也就是说，我们要想模拟一个客户端去验证服务端的逻辑，那么开始接口测试最快速的方法不是去看协议的说明文档，而是直接去看开发实现的客户端代码，这对于我们来说，能更直接地解决问题。但这也并不是说，那位开发工程师告诉我的学习脉络是错误的，只不过它并不是一个非常适合测试工程师的学习方法。
那在面对一个陌生的新协议时，测试工程师的首要任务是什么呢？
在我看来，就是要测试接口的正确逻辑、错误逻辑是否满足最初的需求，因此，我们需要快速地掌握验证手段。在时间紧迫的情况下，如果我们还是先学习新协议的基础知识，再学习怎么使用它，就无疑压榨了测试的工期，也会让我们在真正开始工作时手忙脚乱。
所以，我们要从解决实际问题的角度出发，直接拿到开发工程师提供的调用客户端代码，这样我们就可以快速完成工作了；在完成工作的后续时间里，我们也可以慢慢补充基础知识。这里需要你注意的是，我并不是说基础知识不重要，而是说在项目进行过程中，学习基础知识很多时候没有完成项目的质量保障工作重要。
我在前面说了一大堆方法论，你看到后可能还是摸不到头脑，那么现在，我就以一个我亲身经历的例子来告诉你，面对一个陌生协议接口要怎么去做测试。
大概是在2017年，我第一次接触到WebSocket协议的接口，当开发工程师告诉我这是一个WebSocket的接口时，我一脸懵，完全不知道要如何开始测试它。
我先做的就是和开发要了他们调用方的代码，当我第一次看到这个代码时，还是很难为情的，因为它是用Node.js编写的，当时我对这个技术知之甚少。但凭着自己的经验积累，我多多少少还能看懂一点这个代码，然而我在读了代码之后，发现自己基于这个代码写测试用例并不容易，因为我对Node.js技术实在太陌生了，陌生到我无法利用它来完成接口测试。
这种情况我相信你肯定也遇见过，那就是开发工程师很Nice地把代码给了你，但你却没办法利用它。但这里我想告诉你的是，面对一个陌生协议的接口测试任务时，无论如何，第一次你还是需要先拿到并了解开发工程师写的客户端代码，因为这样，你就可以对调用方式、参数等接口相关的一些内容有初步印象。在读完相关代码后，你就算是和这些接口完成了首次“会面”，下面你就要想办法敲开接口的大门，让自己能访问被测接口。
由于技术栈问题，我没办法借助开发工程师的力量完成接口测试任务，因此我接下来想到的是，借助一些自己已经熟悉的工具来完成本次测试。我第一个想到的就是我们在之前课程中一起使用过的Fiddler，因为在任何一个接口项目开始时，无论开发是不是给了我接口文档，我都会先用Fiddler访问看一下。
那么WebSocket用Fiddler怎么搞定？我当时搜索了一下，还真是有办法，具体的办法我就不在这里多说了，其实主要就是修改了Fiddler中Rules下的Customize Rules，如果你感兴趣可以自己去搜一下。我只是想告诉你，当你面对陌生技术问题的时候，你应该使用你最熟悉的技术去尝试解决问题。
但从下面的图中你可以看到，虽然我找到了Fiddler截获WebSocket接口的办法，却不难发现，所截获的全部消息都在日志里面，根本无法操作，所以我想用Fiddler完成WebSocket测试的想法也就胎死腹中了。
但是，我可以借助Fiddler分析WebSocket的接口，这也和我们一开始给Fiddler这款工具的定位一样，那就是通过它辅助分析我们的被测接口。
当用已有工具基础解决WebSocket接口测试这个想法破灭了后，我开始寻求通过编写代码，解决WebSocket的接口测试。在这里，我还是建议你要以你自己的技术栈为出发点，寻找解决问题的方法。由于我的主要编程语言是Python，因此下面一些讲解的示例代码段，我还是以Python为例，但是你要知道，解决问题的思路并不限于Python的编程语言，它可以是你使用的任何其它语言。
我发现Python提供了WebSocket的协议库，因此我只要用它完成客户端的撰写，就可以进行接口测试了。这里，我写下了第一个WebSocket的调用代码（这里我们以 http://www.websocket.org/demos/echo/ 为例)，如下面图中所示，我在代码里面写了详细的注释，你肯定能看懂每一句话的意思。
#引入websocket的create_connection类
from websocket import create_connection
# 建立和WebSocket接口的链接
ws = create_connection("ws://echo.websocket.org")
# 打印日子
print("发送 'Hello, World'...")
# 发送Hello，World
ws.send("Hello, World")
# 将WebSocket的返回值存储result变量
result = ws.recv()
# 打印返回的result
print("返回"+result)
# 关闭WebSocket链接
ws.close()
不知道你发现没有，上面的代码和HTTP协议的接口类似，都是先和一个请求建立连接，然后发送信息。它们的区别是，WebSocket是一个长连接，因此需要人为的建立连接，然后再关闭链接，而HTTP却并不需要进行这一操作。
我相信你肯定还记得在测试框架那一节（04）中，我们学习了一些线性的接口测试代码，然后通过分析这些代码抽象出Common类，随着Common类的不断丰富，就形成了你自己私有化的测试框架，那么现在问题来了：Common类中可以也放入WebSocket的通用方法吗？
看见上面的代码，我们的第一反应应该是，这里有什么东西可以放到我们自己的Common类中呢？你可以按照“测试代码即框架”这一思路将这个WebSocket接口封装进你的框架。
我们在前面课程中封装了Common类，你可以在它的构造函数中，添加一个API类型的参数，以便于知道自己要做的是什么协议的接口，其中http代表HTTP协议接口，ws代表WebSocket协议接口。由于WebSocket是一个长连接，我们在Common类析构函数中添加了关闭ws链接的代码，以释放WebSocket长连接。依据前面的交互流程，实现代码如下所示：
#!/usr/bin/env python
# -*- coding: utf-8 -*-
# python代码中引入requests库，引入后才可以在你的代码中使用对应的类以及成员函数
import requests
from websocket import create_connection
# 定义一个common的类，它的父类是object
class Common(object):
# common的构造函数
def __init__(self,url_root,api_type):
'''
:param api_type:接口类似当前支持http、ws，http就是HTTP协议，ws是WebSocket协议
:param url_root: 被测系统的根路由
'''
if api_type=='ws':
self.ws = create_connection(url_root)
elif api_type=='http':
self.ws='null'
self.url_root = url_root
# ws协议的消息发送
def send(self,params):
'''
:param params: websocket接口的参数
:return: 访问接口的返回值
'''
self.ws.send(params)
res = self.ws.recv()
return res
# common类的析构函数，清理没有用的资源
def __del__(self):
'''
:return:
'''
if self.ws!='null":
self.ws.close()
def get(self, uri, params=None):
'''
封装你自己的get请求，uri是访问路由，params是get请求的参数，如果没有默认为空
:param uri: 访问路由
:param params: 传递参数，string类型，默认为None
:return: 此次访问的response
'''
# 拼凑访问地址
if params is not None:
url = self.url_root + uri + params
else:
url = self.url_root + uri
# 通过get请求访问对应地址
res = requests.get(url)
# 返回request的Response结果，类型为requests的Response类型
return res
def post(self, uri, params=None):
'''
封装你自己的post方法，uri是访问路由，params是post请求需要传递的参数，如果没有参数这里为空
:param uri: 访问路由
:param params: 传递参数，string类型，默认为None
:return: 此次访问的response
'''
# 拼凑访问地址
url = self.url_root + uri
if params is not None:
# 如果有参数，那么通过post方式访问对应的url，并将参数赋值给requests.post默认参数data
# 返回request的Response结果，类型为requests的Response类型
res = requests.post(url, data=params)
else:
# 如果无参数，访问方式如下
# 返回request的Response结果，类型为requests的Response类型
res = requests.post(url)
return res
def put(self,uri,params=None):
'''
封装你自己的put方法，uri是访问路由，params是put请求需要传递的参数，如果没有参数这里为空
:param uri: 访问路由
:param params: 传递参数，string类型，默认为None
:return: 此次访问的response
'''
url = self.url_root+uri
if params is not None:
# 如果有参数，那么通过put方式访问对应的url，并将参数赋值给requests.put默认参数data
# 返回request的Response结果，类型为requests的Response类型
res = requests.put(url, data=params)
else:
# 如果无参数，访问方式如下
# 返回request的Response结果，类型为requests的Response类型
res = requests.put(url)
return res
def delete(self,uri,params=None):
'''
封装你自己的delete方法，uri是访问路由，params是delete请求需要传递的参数，如果没有参数这里为空
:param uri: 访问路由
:param params: 传递参数，string类型，默认为None
:return: 此次访问的response
'''
url = self.url_root + uri
if params is not None:
# 如果有参数，那么通过put方式访问对应的url，并将参数赋值给requests.put默认参数data
# 返回request的Response结果，类型为requests的Response类型
res = requests.delete(url, data=params)
else:
# 如果无参数，访问方式如下
# 返回request的Response结果，类型为requests的Response类型
res = requests.put(url)
return res
上面的代码很长，但我的注释很详细，我并不建议你一字不落地都看完，你只要在使用的时候看一下对应的方法就好了。它是一个超级工具集合，最后会变成你自己的类似哆啦A梦的万能口袋，你只要做好自己的积累就可以了。
那么，使用上述的Common类将上面那个流水账一样的脚本进行改造后，就得出了下面这段代码：
from common import Common
# 建立和WebSocket接口的链接
con = Common('ws://echo.websocket.org','ws')
# 获取返回结果
result = con.send('Hello, World...')
#打印日志
print(result)
#释放WebSocket的长连接
del con
现在，从改造后的代码中，你是不是更能体会到框架的魅力了？它能让代码变得更加简洁和易读，将WebSocket的协议封装到你的框架后，你就拥有了一个既包含HTTP协议又包含WebSocket协议的接口测试框架了，随着你不断地积累新协议，你的框架会越来越强大，你自己的秘密武器库也会不断扩充，随着你对它的不断完善，它会让你的接口测试工作越来越简单，越来越快速。
美好的时光过得都很快，又到了本节课结束的时候了，我今天主要讲了面对一个陌生协议时（比如说WebSocket），你该如何从零开始完成接口测试任务。
针对一个陌生协议的第一次接口测试，你要保持自己敏锐的测试嗅觉，依据自己的技术基础，尽快解决问题。总地来说，你可以通过三步快速完成测试任务：
我们今天一起学习了如何破解陌生协议接口测试难题的步骤，那么面对WebSocket的接口测试任务，结合你现有的技术栈，你是不是也有你自己的解决方案呢？你工作中如果有类似的陌生协议（既可以是第一次接触的协议，也可以是企业私有协议），你是如何解决的呢？欢迎你在留言区中留下你的疑问和你的做法。
我是陈磊，欢迎你在留言区留言分享你的观点，如果这篇文章让你有新的启发，也欢迎你把文章分享给你的朋友，我们一起沟通探讨。
评论