WebSocket接口：如何测试一个完全陌生的协议接口？
未知的新协议接口并不可怕
那在面对一个陌生的新协议时，测试工程师的首要任务是什么呢？在我看来，就是要测试接口的正确逻辑、错误逻辑是否满足最初的需求，因此，我们需要快速地掌握验证手段。
第一次接触 WebSocket 接口
由于技术栈问题，我没办法借助开发工程师的力量完成接口测试任务，因此我接下来想到的是，借助一些自己已经熟悉的工具来完成本次测试。我第一个想到的就是我们在之前课程中一起使用过的 Fiddler，因为在任何一个接口项目开始时，无论开发是不是给了我接口文档，我都会先用 Fiddler 访问看一下。
可以借助 Fiddler 分析 WebSocket 的接口，这也和我们一开始给 Fiddler 这款工具的定位一样，那就是通过它辅助分析我们的被测接口。
自己写 WebSocket 测试代码
我发现 Python 提供了 WebSocket 的协议库，因此我只要用它完成客户端的撰写，就可以进行接口测试了。这里，我写下了第一个 WebSocket 的调用代码（这里我们以 http://www.websocket.org/demos/echo/ 为例)，如下面图中所示，我在代码里面写了详细的注释，你肯定能看懂每一句话的意思。
将 WebSocket 接口封装进你的框架
看见上面的代码，我们的第一反应应该是，这里有什么东西可以放到我们自己的 Common 类中呢？你可以按照“测试代码即框架”这一思路将这个 WebSocket 接口封装进你的框架。
总结
针对一个陌生协议的第一次接口测试，你要保持自己敏锐的测试嗅觉，依据自己的技术基础，尽快解决问题。总地来说，你可以通过三步快速完成测试任务：
- 借力开发工程师。你首先该借力就是开发工程师，但你不要进入开发工程师给你的那种，从技术基础和理论开始学起，再逐步应用的学习脉络。你要一击致命，直接把他的客户端代码拿来，尽最大可能挪为己用，将其变成自己的接口测试代码。
- 站在自己的技术栈之上，完成技术积累。如果开发工程师的代码并不能拿来使用，那么你就需要站在自己的技术栈上寻求解决方法，这其中既包含了你已经熟悉的测试工具、测试平台，也包含了自己的测试框架和编码基础。
- 归入框架。无论你使用哪一种方法，在完成测试工作后，你还是要掌握对应的理论基础，同时想办法将这个一开始陌生的接口，通过自己熟悉的方式合并到你自己的框架中，不断扩充自己框架的测试能力，不断丰富你自己的测试手段。
测试数据：是不是可以把所有的参数都保存到Excel中？
测试数据的好处：打造自动化测试框架
你可以通过一种更好的方式，将数据存储到一种数据存储文件中，这样代码就可以自行查找对应的参数，然后调取测试框架执行测试流程，接着再通过自动比对返回预期，检验测试结果是否正确。
这样做有两个好处。
- 无人值守，节省时间和精力。我们将所有的参数都存储到外部存储文件中，测试框架就可以自行选择第一个参数进行测试，在完成第一个测试之后，它也就可以自行选择下一个参数，整个执行过程是不需要人参与的。否则的话，我们每复制一组参数，就要执行一次脚本，然后再人工替换一次参数，再执行一次脚本，这个过程耗时费力，而且又是一个纯人工控制的没什么技术含量的活动。
- 自动检测返回值，提高测试效率。如果你用上面的代码段完成接口测试，就要每执行一次，人工去观察一次，看接口的返回是不是和预期一致，人工来做这些事情，不只非常耗费时间，效率也很低下。但是通过代码完成一些关键匹配却很容易，这可以大大提高测试效率，快速完成交付。
如何选取测试数据
首先，你先要定义一种参数的存储格式。那么我想问你的是，要是让你选择把数据储存在一个文件中，你会选择什么格式的文件呢？
我相信你肯定和我的选择一样，用 Excel。因为目前来看，Excel 是在设计测试用例方面使用最多的一个工具，那么我们也就可以用 Excel 作为自己的参数存储文件。
但在动手之前，你也应该想到，你的参数文件类型不会是一成不变的 Excel，未来你也有可能使用其他格式的参数文件，因此在一开始你还要考虑到参数类的扩展性，这样你就不用每多了一种参数文件存储格式，就写一个参数类，来完成参数的选取和调用了。
总结
今天我们接口测试数据准备的内容就到这里了，在接口测试的工作中，作为“巧妇”的测试工程师，还是需要参数这个“米”来下锅的，虽然我们之前课程中的代码涉及到参数的处理，但是都很简单粗暴，一点也不适合自动化的处理方式，因此今天，我带你完成了参数类的封装。
有的时候，我们也把参数类叫做参数池，这也就是说参数是存放在一个池子中，那我们准备好的池子就是 Excel。我相信未来你也会不断扩展自己参数池的种类，这有可能是由于测试接口的特殊需求，也有可能是由于团队技术栈的要求。因此，我们封装参数池是通过简单工厂设计模式来实现的，如果你的代码基础并不好，那么你可以不用搞清楚简单工厂设计模式是什么，只需要知道如何模拟上述代码，再进行扩展就可以了。
一个好用的测试框架既要有很好的可用性，也要有很好的扩展性设计，这样我们的私有接口测试武器仓库就会变成可以不断扩展的、保持统一使用方法的武器仓库，这样才能让你或者你的团队在面对各种各样的测试任务时，既可以快速适应不同接口测试的需求，又不需要增加学习的成本。
微服务接口：怎么用Mock解决混乱的调用关系？
情况描述: 微服务下混乱的调用关系
Mock 框架的抉择：用什么实现服务 B 的替身
我当时想到的就是使用 Mock 服务。其实 Mock 服务是一个错误的说法，关于这一点我推荐你看一下 Martin Flower 的这篇叫做TestDouble的文章，一般我们将 TestDouble 服务叫做测试替身，但是如今的国内业界里，绝大部分人已经习惯了叫 Mock 服务，因此在这里我们也还是叫 Mock 服务。
那么，到底应该怎么选择 Mock 服务框架呢？ 如果你的团队技术基础很好，开发能力很强，那么我建议你用对应语言的 Mock 框架，例如 Java 语言的Mockito 框架和 Python 语言的mock 框架。
如果你的团队技术基础相对比较薄弱，那么我推荐你看看moco，这个框架在开发 Mock 服务的时候，提供了一种不需要任何编程语言的方式，你可以通过撰写它约束的 Json 建立服务，并通过命令启动对应的服务，这就可以快速开发和启动运行你需要的 Mock 服务。
我的 Mock 服务设计经验
首先，简单是第一要素。无论原服务 B 处理了多么复杂的业务流程，你在设计服务 B 的 Mock 服务时，只要关心服务 B 可以处理几种类型的参数组合，对应的服务都会返回什么样的参数就可以了。这样你就能快速抓住 Mock 服务 B 的设计核心，也能快速完成 Mock 服务 B 的开发。
其次，处理速度比完美的 Mock 服务更重要。一个 Mock 服务要能按照原服务正确又快速地返回参数，你不需要把大量的时间都浪费在 Mock 服务的调用上，它只是用来辅助你完成接口测试的一个手段。你需要让它像打在墙上的乒乓球一样，一触到墙面马上就反弹回来；而不能把球打出后，需要去喝个茶或者坐下休息一会，才能收到反弹回来的球。如果你的 Mock 服务很耗时，你在只有一个两个服务时，可能影响还不是很明显，但如果你同时有多个 Mock 服务，或者需要用 Mock 服务完成性能测试的时候，这就会变成一个很严重的问题，后续会引发强烈的“蝴蝶效应”，使得整个被测接口的响应速度越来越慢。因此你要建立一套快速的 Mock 服务，尽最大可能不让 Mock 服务占据系统的调用时间。
最后，你的 Mock 服务要能轻量化启动，并且容易销毁。你要时刻注意，Mock 服务只是一个辅助服务，因此，任何一个团队都不希望启动一个 Mock 服务需要等待 5 分钟，或者需要 100M 的内存。它要能快速启动、容易修改并且方便迁移。既然 Mock 服务的定位是轻量化的辅助服务，那么它也要容易销毁，以便你在完成测试后，可以快速且便捷地释放它所占据的资源。
总结
微服务现在已经铺天盖地而来，尤其在中台化战略的推动下，业务中台服务的依赖关系会越来越复杂，并且随着团队内微服务数量越来越多，每个测试团队面临的被测系统都会是一团乱麻，很容易找不到头绪。
为了解决由于微服务间相互依赖而导致的混乱的系统调用关系，我建议你尽快掌握一个 Mock 服务框架，这样可以让你在混乱中理清思路，快速进行接口测试，交付高质量的项目。
最后我要提醒你的是，选择 Mock 的技术栈与选择测试框架的技术栈还是有些区别的，在选择 Mock 技术栈时，你重点要考虑的是学习成本，把学习成本降到最低，才是选择 Mock 框架的首要关注点。而且你不只要关注自己的学习成本，也要关注你所在团队的学习成本，因为现在每个项目都有可能需要 Mock 服务，这个时候，就要求每一个项目的测试工程师都具备自己独立建设 Mock 服务的能力，在 Mock 服务的技术选型上，还是要以团队整体的技术栈为基础，以自己的技术为参考进行选型。
加餐
那么如何使自己不断成长为高级测试工程师呢？ 就接口测试来说，学习路线就如同我在专栏中讲解的一样，从整理输入到使用工具，再到封装框架来完成测试任务，这其实也是一个技术的实践路线。如果你不知道如何将这些内容和工作结合到一起，不妨试试我在一开始说过的 Postman 这类小工具，用它敲开你的接口测试任务大门，随着工作的不断深入，后续你在写测试脚本和封装框架也就慢慢水到渠成了。所谓的高级测试工程师，也就是这样一步步修炼出来的。
陈磊老师建议你可以通过三步来规划你的学习：
- 从实际动手开始学习测试技术。你最好还是从一个实际例子出发开始学习，这就和大部分编程语言都从 Hello World 开始一样。直击问题，这样才更能激发你的学习兴趣。
- 不断遇见问题，不断解决问题。你在实际工作中，肯定会遇见很多问题，你一定要一个一个去解决，并不断地从问题中总结可复用的经验，这样就会形成一套你自己独特的学习思路，以及更适合你自己的技术学习方法，更重要的是，这样学习更不容易遗忘。
- 掌握理论知识。我之所以将理论知识的学习放到最后，是因为当你知道如何用一个测试技术解决问题的时候，再去学习理论，就不会出现由于理论枯燥、记不住而放弃学习这样的情况了。同时，实践后再学习理论，每看到一个知识点你就会有“原来是这样实现的啊”这种感觉，你就很容易理解并记住它了。
