發佈一個用於測試 Webservice 和資料庫連接的工具。 ...
今天我將發佈一個可以用來測試 WebService （後端介面），簡單測試資料庫連接（一些資料庫需要額外安裝驅動）的測試工具。它的名字最初叫做 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"> <title>xxxxx xxxxx</title> <style> ... </style> </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，之後再啟動程式，面板就會複位成均勻的分配緩衝區的空間，但每次程式退出時，都會把界面的佈局信息保存到這個配置文件中。
最後是我先給出這個程式的 x86 的可執行文件的鏈接，因為 x86 的版本可以適用於目前幾乎所有的 windows 操作系統。而 x64 的版本我考慮在未來編譯並提供。此外還有一些常用資料庫的驅動，例如 mysql 驅動，我也考慮以後會在本文中給出。
【下載鏈接】
（1）適用於操作系統 windows x86：DBTest86_v1.0.zip
【其他改進想法】
對這個程式我還有很多其他的改進想法，限於時間和精力的原因，不可能很快的完成。包括提供多語言版，增加 AES 加密解密功能，增加 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。
