我们说到了用 Postman 来完成接口测试，但随着你的接口测试项目逐渐增加，你会发现越来越难以管理它的脚本，虽然测试工具导出的测试脚本也可以存放到代码仓库，但是，如果只是通过代码来查看是很难看懂的，你必须用原来的测试工具打开，才能更容易看懂原来的脚本做了什么样的操作。
做接口测试脚本开发的技术选型上，我更建议你根据自己的技术实力和技术功底来选择，而不要以开发工程师的技术栈来选择。
我们作为测试工程师，无论是使用自动化的接口测试，还是界面的手工测试，第一目标都是保障交付项目的质量，那些业务侧的表现，在大多数情况下不是我们关心的重点
测试框架的形成是在撰写大量测试脚本的过程中不断抽象封装出来的，然后，再用这个不断完善的框架，改写原有的测试脚本。循环往复这个过程，你就会慢慢获得一个独一无二的、又完全适合你工作的接口测试框架。
那在面对一个陌生的新协议时，测试工程师的首要任务是什么呢？在我看来，就是要测试接口的正确逻辑、错误逻辑是否满足最初的需求，因此，我们需要快速地掌握验证手段。
由于技术栈问题，我没办法借助开发工程师的力量完成接口测试任务，因此我接下来想到的是，借助一些自己已经熟悉的工具来完成本次测试。我第一个想到的就是我们在之前课程中一起使用过的 Fiddler，因为在任何一个接口项目开始时，无论开发是不是给了我接口文档，我都会先用 Fiddler 访问看一下。
可以借助 Fiddler 分析 WebSocket 的接口，这也和我们一开始给 Fiddler 这款工具的定位一样，那就是通过它辅助分析我们的被测接口。
我发现 Python 提供了 WebSocket 的协议库，因此我只要用它完成客户端的撰写，就可以进行接口测试了。这里，我写下了第一个 WebSocket 的调用代码（这里我们以 http://www.websocket.org/demos/echo/ 为例)，如下面图中所示，我在代码里面写了详细的注释，你肯定能看懂每一句话的意思。
环境的文档
测试的文档
进行压测，把数据库搞崩
Citus 数据库是 Postgres 的一个开源扩展，可以让你在任何规模上都感受到 Postgres 的伟大ーー从一个节点到一个庞大的分布式数据库集群。由于 Citus 是 Postgres 的一个扩展(而非分支) ，因此当您使用 Citus 时，也在使用 Postgres。您可以利用最新的 Postgres 特性、工具和生态系统。
使用 Citus，您可以获得分布式 Postgres 功能，比如分片、分布式表、引用表、分布式查询引擎、柱状存储—到 Citus 11.0 为止，您可以从任何节点进行查询。Citus 将并行性、在内存中保存更多数据以及更高的 I/O 带宽结合在一起，可以显著提高多租户 SaaS 应用程序、面向客户的实时分析仪表板以及时间序列工作负载的性能。
获得 Citus 的两种方法:
包含视图、函数知识、防止 SQL 注入攻击等内容。
大多数 SQL 实现支持以下类型的函数。
❑ 用于处理文本字符串（如删除或填充值，转换值为大写或小写）的文本函数。❑ 用于在数值数据上进行算术操作（如返回绝对值，进行代数运算）的数值函数。
❑ 用于处理日期和时间值并从这些值中提取特定成分（如返回两个日期之差，检查日期有效性）的日期和时间函数。
❑ 用于生成美观好懂的输出内容的格式化函数（如用语言形式表达出日期，用货币符号和千分位表示金额）。
❑ 返回 DBMS 正使用的特殊信息（如返回用户登录信息）的系统函数
SQL 函数不区分大小写。随你的喜好，不过注意保持风格一致，不要变来变去，否则你写的程序代码就不好读了。