【 prologue | 前言】尽管这是我一个我很偏爱的工具，它可以测试数据库连接，可以测试 HTTP 协议的接口，可以设定代理服务器，但是客观事实是，它尚不能和业界已经流行的 postman 进行竞争，因为这只是一个个人在业余时间开发的工具（它的开发包含我数年 C++ 和 Windows UI 方面的心血，它为我提供的帮助比任何我自己写的其他工具都大）。但如果有人愿意试用它来做接口测试的话，我将感到非常高兴，并且你可以为这个工具提出功能和增强方面的建议和意见。我非常希望有时间能进一步的加强它。包括将它的“客户端”改进为 SSH 客户端等。-- Jan-29-2024 Mon （民国 113 年）。
今天我将发布一个可以用来测试 WebService （后端接口），简单测试数据库连接（一些数据库需要额外安装驱动）的高性能的工具软件，它的高性能是因为它的无框架性（例如不使用 MFC 之类的框架），是完全基于纯 WIN32 API 开发，这使得它对机器配置的要求极低，运行效率高，启动速度快，内存占用低。它的名字最初叫做 DBTest，因为最初我只是像先写一个测试数据库连接是否正常的小程序，但是慢慢的随着我的想法的逐渐变化，这个程序最终成了一个“三合一”的程序，也就是说，它可以展现出三种外观（视图），就像是把三个分别独立的程序合为一个程序。这个灵感是来自于 《007 大战海底城》里的邦德使用的水陆两栖座驾车，当这辆车从陆地开到水里的时候，它的仪表盘和外观都进行了相应的变化，变成了类似一个潜水艇的模样。所以这个程序也是类似的，当在 【视图】菜单中切换到不同的视图时，整个程序的工具栏，状态栏，客户区都会发生相应的变更，每个视图在程序内部都独自维持着自己的工具栏，状态栏的信息。这个程序最初是在 2016 年开发，后来的这些年中，一直都是我用来测试 webservice 接口的一个重要工具，也因此随着我一边使用，我也一边的发现问题，并改进问题，并最终在 2022 年我又对它进行了一段时间的集中加强，使得它在某些我会经常常用的功能的地方，会更加好用。到今天为止，他虽然还不是非常完善，我还有很多想法想要继续把它加强。但我还是想先把它的现在的版本和成果发布出来，希望也能让其他人和我一样愿意使用它。
这个程序有三个视图：分别是（1）数据库连接测试（建议只测试读取数据库，不要做其他危险操作），（2）WebService 接口测试，（3）一个 socket 客户端。其中第三个因为是给专门的后台服务而开发，所以它不是通用的，所以（3）在日常中是用不到的，不过等我有精力的时候，我考虑把（3）改进成一个 BBS 客户端（虽然 BBS 已经没落了） ，甚至是 SSH 客户端，当然这只能作为业余的兴趣去做了。我自己使用最多的就是第二项，即，测试 WebService。所以我将主要简单介绍下测试 WebService 的用法。
主程序名字是 DBTest.exe ，其他可执行程序是挂在主程序的工具窗口下面的辅助程序。打开主程序以后，通过【视图】菜单切换到不同的视图。
下图是测试数据库连接的视图：
点击工具栏上的【执行】按钮执行查询数据库或者发起请求的任务。操作是非常直观的，下方的查询结果会根据结果的字段内容长度，自动调整每列的宽度。
下图，是测试 webservice 的视图：
从界面可见，它的大部分控件都是基本上同时可见的，所以用户可以整体看到所有重要的信息。只有最下方 response payload 和 response headers 这两个部分不能同时可见，它们同时占据客户区最下方的位置，需要通过上方的 radio button 切换它们的可见性，用户在同一时刻只能见到它们两个中的其中一个。URL 部分是单行的，但是有水平滚动条，这样在 URL 很长的时候，用户可以拖动水平滚动条来查看整个 URL 地址。
这里，我将主要介绍它的一些重要功能，或者说不同于其他的常用测试工具的一些特点。
（1）支持添加多个文件到文件列表中，这些文件可以用宏的形式插入到 Data （request payload）中，例如当需要把图片的 base64 编码嵌入到 Data 中作为 Data 的一部分的时候，或者需要以例如 form-data 的形式上传多个文件的时候，这个功能将非常的好用。
方法是首先点击【添加文件】按钮，选择文件，文件将出现在文件列表中 （你也可以直接把文件拖放到文件列表上放开，即可完成添加文件），这些文件在性质上相当于可供 data 自由引用的“附件“，如果在 data 中没有引用任何文件，那么这些文件列表对请求来说不起任何作用，只有当 data 的部分中引用了任何文件的时候，文件列表才对请求的 payload 有影响。在文件列表中右键点击某个文件，就会弹出上下文菜单，然后可以选择插入文件的例如 base64 编码到 data 中，那么它在 data 文本框里将以宏的形式出现。在发起请求的时候，程序会自动把这些宏替换成实际的数据。因此，你完全可以把普通的字符串和这些宏组合在一起。同时为了避免普通字符和宏出现冲突，当在你的 data 的字面值中需要有 $ 字符时，需要把它改写为 $$ 进行转义（就像 C 语言里对反斜杠进行转义时采用连续两个反斜杠那样）。
（2）支持设置代理服务器，用户可以选择 1) 不使用代理，2) 使用系统设置的代理服务器，或者 3) 使用用户自己设置的代理服务器。在工具栏上点击【代理】按钮即可弹出设置代理服务器的对话框，下面的对话框是一个高度灵活的对话框，这个对话框和对应的配置文件可以保存多个用户自定义的代理服务器（因此对这个配置文件的格式是比较灵活的，所以对这个配置文件的读写都是由我自己写的函数完成，而不是调用 win32 api ）。当选择手工配置代理时，右键单击代理服务器列表，可以进行新增，删除，编辑代理服务器的操作。用户也可以直接双击 listview 的某一个单元格，进行就地编辑，编辑完成一个单元格以后，可以按 TAB 键自动切换到下一个单元格的编辑状态。列表前面的绿色箭头，表示的是当前正被选中的代理服务器。如果用户有多个代理服务器，进行切换是非常简单的（这样的好处是，你不需要反复的覆写当前指定的代理服务器的信息）。
（3）由于 webservice 的响应有很多是 json 格式，且服务器返回的 json 通常是紧凑型，不利于人眼观察，所以程序针对 json 类型的响应数据，可以进行 json 自动格式化和代码着色，点击工具栏上的 【json 美化】即可完成。特别的是，我增加了对 JSON 中比较短的数组不换行的选项，这样可以使得格式化后的 JSON 数据行数更少，更美观。目前暂时还没有增加配色方案设置的选项，配色目前是写死的。这是一个非常重要的功能增强，是因为我经常测试的 webservice 接口大部分返回的是 JSON 数据，而为了分析数据方便，以前我经常要把他们拷贝到用于格式化 JSON 的网站上去格式化，因此很不方便。所以我特别为响应数据是 JSON 格式的增加了美化功能。但因为精力有限，对其他格式例如 xml 等格式的数据，暂时还没有代码格式化和代码着色的功能。同时如果 JSON 数据中有 "\uXXXX" 形式的内容，也会被就地翻译成对应的 unicode 字符。
点击工具栏 【json 美化】按钮旁边的下拉箭头，在弹出的菜单中，用户可以打开设定 json 美化的选项对话框，如下图所示：
（4）用户可以在响应数据中进行“查找”操作，点击工具栏的【放大镜】按钮即可弹出查找对话框，这个功能用于对响应的内容比较长的数据，通过这个功能可以快速定位到用户想要查看的内容。这个功能和我们在 IDE，文本编辑器等程序中的查找功能是几乎一样的，这里就不展示了。
（5）支持服务端的 Transfer-Encoding 为 chunked 的传输模式，当然这是必须的。
（6）程序自动获取响应内容的 charset （字符编码）。获取规则如下：首先从 response headers 的 Content-Type 中提取 charset 的值，并显示在状态栏上，并且根据获取到的 charset 对响应内容进行解码到字符串（如果响应类型是文本类型）。如果 Content-Type 中没有明确指定 charset，且响应的类型属于 html，则再尝试从 html 的前面的 head 中去获取页面编码。如果 Content-Type 和 html 内容中同时指定了 charset，则以 Content-Type 中设置的 charset 为准。如果还是没有获取到 charset，则程序默认使用 UTF-8 对响应的数据进行解码（此时状态栏上的 charset 将什么也不显示）。
例如，程序可以从类似下面的 html 代码中提取出 charset：
<html> <head><meta http-equiv="Content-Type" content="text/html; charset=gb2312"></head> ... </html> <!-- 或者是这样的形式：--> <html> <head><meta charset="UTF-8"></head> ... </html>
此外，关于这个程序的其他特点是：
（1）全部采用 WIN32 API 开发，没有使用任何其他的比较重的框架，例如它里面没有使用任何 MFC 或其他框架，完全是纯 WIN32 API 和一些我自己写的 C++ 类。从而使得它非常的轻量级，运行效率和内存占用方面也都是非常的高效率。因此，在界面方面，我的设计理念是微软所提倡的 -- 简单而强大，因此它的特点是界面简洁，优雅，审美风格保持一致，仅仅在“捐赠”对话框界面上使用了 GDI+ ，其他地方都是使用的传统 GDI。所以整体来说它的界面是质朴，简约，朴素而又美观的。
（2）所有配置文件被我统一到 UTF-8 with BOM 编码，这样可以使配置文件对任何程序，任何操作系统环境来说都没有编码方面的歧义。同时所有的配置文件我都采用了文本格式的配置文件，而尽量不采用二进制格式的配置文件（虽然二进制的配置文件的读取和保存，对编码实现来说其实难度要低很多），这是为了方便用户可以在其他文本编辑器中对这些配置文件进行手工编辑。也因此会引入比如处理字符编码，识别和跳过文本文件的 BOM，根据配置文件的格式，可能需要对很多字符进行转义的编码和解码，因此在读取和保存配置文件的时候，需要在编码方面花费更多精力。
（3）Webservice 测试界面的状态栏因为有比较多的 parts，所以这些 parts 的可见性是可以自定义的，只要在状态栏上右键点击，即可弹出上下文菜单，用户可以自由的选择显示或者隐藏那些 statusbar part。大部分 part 的宽度是 fixed，但有的 part 的内容因为变化比较大，所以可以根据内容自适应宽度，但是考虑到效率问题，我只对“代理服务器设置”这个 part 开启了宽度自适应，其他的 status part 的宽度目前基本是写死在程序中，用户目前是不能调节他们的宽度的。当用户把鼠标悬浮在任务栏的 statusbar part 上时，有的会显示 tooltip，解释这个 statusbar part 的含义。
（4）对于更技术性的细节信息，用户可以使用【命令】-【技术细节选项 ...】打开设置对话框，在这里用户可以设置例如 User-Agent，相关请求的一些选项。这些选项是针对技术领域的专家而提供的，不建议普通用户修改它们，对普通用户，使用默认值即可。在下面的选项中只列出了一部分用户可以控制的选项开关，还有的没有列出，是程序自动设置的，例如和 SSL 相关的选项。
（5）因为界面上的元素较多，所以为了方便用户把界面上的设置能否重复利用，程序提供了读取和保存“界面设置”信息的功能，点击工具栏上的【打开】和【保存】按钮，用户能够把当前界面上的设置内容保存到一个文本文件，也可以打开已经保存好的文本文件，从而快速的把之前的设置内容加载到界面上。在程序所在文件夹的 UIFiles 文件夹下面，我已经提供了一些界面设置内容的模板，例如测试 SqlServer 数据库等。
（6）在程序的主菜单【工具】下面挂载了一些工具，例如“猜测文件编码”，“计算文件 MD5” 等，这些程序也是我自己写的小程序。这个菜单的内容可以有用户自由配置，配置文件是 ：程序目录\conf\menu.ini。用户也可以理解了这个配置文件的格式后，自己编辑这个配置文件，挂载更多的自定义工具到这个菜单下面。
（7）界面上采用了我自己实现的 slider 拖动条（这个控件由 MulSelCtl.dll 提供），用户可以用鼠标拖动界面上的 slider，从而调整界面上各个部分的大小。对于测试数据库连接的视图，这些 slider 两端有限制，界面上的控件总是可见的，因此可以随意拖动。对于测试 webservice 的视图，会有点特殊，因为界面上的元素太多，所以拖动 slider 的时候，实际上是能够把一些“面板”给隐藏掉。所以当你发现某些控件在界面上不见了的时候，就是说明这个面板被隐藏起来了，只要拖住对应的 slider 向上或者向下拖动，那么它某一侧被隐藏的面板就会重新显示出来。在配置文件：conf\layout.ini 中记录了这些面板的尺寸比例，可以手工把他们改成 1:1:1:1，之后再启动程序，面板就会复位成均匀的分配缓冲区的空间，但每次程序退出时，都会把界面的布局信息保存到这个配置文件中。
最后是可执行文件的下载链接，此外还有一些常用数据库的驱动，例如 mysql 驱动，我也考虑以后会在本文中给出。
【下载链接】
（1）适用于所有 windows 操作系统（x86）：DBTest86 v1.2
（2）适用于 64 位 windows 操作系统（x64）：DBTest64 v1.2
备注：在 64 位系统上，使用 x64 版本的程序的运行效率会更好。但 x86 版本的程序的适用范围更广泛。
【更新历史】
（1）[v1.0] 2022-07-23 首次发布。
（2）[v1.1] 取消 URL 长度限制。对长度比较长的 JSON 数据的美化放在后台线程中做，并在状态栏上提供进度反馈。-- 2022-07-31。
（3）[v1.2] 查询数据库时，对 decimal 和 money 类型字段字符串化的方法调整为：对 decimal 字段使用 32 位十进制大整数进行字符串化，对 money 采用 int64 整数进行字符串化，使得这两种字段可以精确字符串化。-- 2022-08-19 Fri.
【已发现的问题或 BUG，以及正在开发和更新的内容】
（1）[版本 v1.0]：URL 长度限制问题，URL 长度在此版本中被限制在不能超过 259 个字符，将在下一版本中修复。--2022-07-23。
（2）[版本 v1.0]：Json 美化时，效率比较低，且是在 UI 线程中做，如果响应的内容数据比较多，就会消耗很长时间，导致 UI 停止响应。将在下一版本中改为在后台线程中进行美化，同时提供 UI 上的进度反馈。--2022-07-23。
（3）[ 版本 <= v1.1]：改进对数据库中的 decimal，money 类型的字段的字符串化方法，避免使用 double 类型中转而引入浮点数误差。在下一版本中将改为，对 decimal 类型使用 32 位的有符号十进制大整数算法来中转（最高位即存储值也表示数字的正负性符号），money 字段则直接使用 LONGLONG （int64_t）类型来中转。--2022-08-08。
【其他改进想法】
对这个程序我还有很多其他的改进想法，限于时间和精力的原因，不可能很快的完成。包括提供多语言版，增加 AES 加密解密功能，增加常用的 MD5, SHA-256 信息摘要算法，增加 16 进制 viewer 控件，可以展示二进制数据，对请求的 payload 和响应的 payload 加上数据 filter chain 的功能，对数据加上一个 filter chain，以及对 request payload 进行更灵活的发出请求前处理，以及更好的展示出各种各样的响应数据，例如如果响应的内容是图片的 base64 编码，如何将其展示成图片等。
从我自己的角度，我想做的功能还有太多，但是都不是一时半会能完成的。所以我还是把目前已经做到的功能给完善了完善，然后把它目前的状态作为一个阶段性成果先发布，希望它不仅仅是能够辅助我自己。
【这个工具和 postman 有什么不同】
刚才在闪存有个网友疑问说和 postman 没什么不同，问我我什么要造轮子。这个问题很好，不仅仅是这个网友，在开发到后来的时候，我自己也产生了这个疑问，那就是我的程序如果和 postman 是一样的，并且 postman 也已经足够强大已经满足了人们的需求，那显然别人没有理由去尝试一个新的工具。对我自己来说，当然有着很大不同，因为它是我自己开发的，所以我可以按照自己的需求和想法去改进它，而 postman 对我来说则不能。
这个问题我也一两句话说不清楚。简单来说，我只是把我业余时间写的一个工具给发布了，仅此而已。它最开始的初衷只是我为了测试我自己用 c++ 写的一个 webservie 类而已。但从 2016 年至今逐渐的发展到了今天这个地步。那么它到底有什么不同，就目前来说我觉得就是我插入文件的地方，和 postman 是不太一样的。postman 在这里做的反正我用着不顺手（或者说我不会用，也没有认真去研究和学习 postman 的功能）。下图是展示了一个上传两个图片的原始内容的设置：
在这里你可以看到就是说，宏 $(__file0) 代表的是第一个图片文件的二进制内容。$(__file1) 代表的是第二个图片文件的二进制内容。这样的方式就可以发送 form-data 同时上传两个图片文件了。当然 postman 也许也能做到，postman 也显然是一个强大的测试工具，只是我对 postman 不熟悉而已，因为我自己几乎不使用 postman。
从界面上可以看出，我认为我的工具相对 postman 来说，就是更加底层一点点，更贴近 http 协议一点点。而 postman 是在这个基础上是增加了许多高层的业务逻辑的，同时也使得用户距离协议层稍微远了那么一点点。当然在 win32 api 那里，api 也做了一点点业务逻辑（但是这种业务逻辑封装比较少，也就是说我们依然是很靠近 http 协议这一层深度）。
当然我也已经说过了，我的这个工具就是个绿色软件，而且是纯 win32 开发，它的文件尺寸很小，占用内存也将较少，而它的启动和运行效率将是非常高的。而 Postman 是一个多进程软件，它会启动多个进程（虽然主窗口只有一个），当然也就会占用更多内存，启动速度也更慢，对系统的资源和性能要求和占用都更高。当然在今天这个时代，人们是不是还在意这一点，可能已经不是那么在乎了，这就是另一个话题了，就不多说了。
【历史】
最后我还是想说一下这个工具的大概历史由来，在 2016 年我大概花了 3 个月时间，把它在和工作产品一同开发的过程中开发出来它的第一个版本，可想而知，在当时它只是我的一个小小的辅助工具，并且承载了一些我的技术创新和研究的用途，例如我首次在这个软件里实现了多个视图同时属于同一个主窗口，这在当时是我的一个小小的创新性实验，而且也获得成功，我也很满意。那时候他的功能主要是用来测试数据库是否连通，访问 webservice 是否正常，因为基本是同一份代码在两个软件里的两份拷贝。在当时它应该还是比较简陋的，功能比较少，但是也对当时来说是够用的。后来的工作里，我发现它对我依然有用，于是后来也就小修小补的做了一些很小的改进（因为我后来的工作非常忙碌，没有自己的时间，我的技术博客也在此期间因为工作压力占用我全部时间而停更），大概在 2017-2018 年的时候，完善了处理 Transfer-Encoding 为 chunked 模式的功能，大概也是再此期间，增加了文件列表的功能。2022 年的最近我再次花了一些精力对它做了比较多的完善，修正了一些有 bug 的地方，使得它变得比 6 年前更加强大了许多。所以他的主要两个进展，一个是 2016 年的首次开发出来，第一个是 2022 年的上半年我又对它做了一些增强（这里面有很多内容属于我对 UI 的一些尝试性的研究和实验，比如对 ListView 的就地编辑等等）。截止到目前，我统计所有代码文件（只包括文本性的代码文件，不包括图片等其他资源）的文件尺寸总计是 535 KB。我希望在将来也能有其他人发现这个工具以及它的价值和存在价值，并且让它也能为其他人带来方便。
