【 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。我希望在將來也能有其他人發現這個工具以及它的價值和存在價值，并且讓它也能為其他人帶來方便。
浙公網安備 33010602011771號