HTTP Server Mock 從手工到平臺的演變
大家都知道，不管是 Web 系統、還是移動 APP，各自在與內部、外部系統之間進行資料互動時，大多數情況下都是依賴介面。在基於介面約定開發的模式下，依賴介面的產出時間如果延遲，將直接影響了整個研發除錯的效率；如果不能對介面進行及早測試，那發現問題的時間就要被推遲了。既然雙方約定了介面格式，為何不按照這個規範直接測試，何必在乎依賴介面什麼時候產出，優先做到及早自測，後續只要替換介面聯調通過即可。下面主要講解基於 HTTP 協議的 API 介面模擬，從手工 Mock 到平臺的演變過程。
遇到的問題
曾經遇到的困擾：在研發過程中介面除錯對接難的問題：
場景一：
【需求階段】Portal 前、後端約定基於介面開發
【開發階段】前端開發完畢，後端介面尚未開發完畢，前端只能硬編碼資料進行測試，造成介面對接除錯延後，而且每次進行更多場景的資料除錯，需要頻繁重啟服務、本地部署；
研發自測階段無法及早開展，依賴介面約束大。
場景二：
【需求階段】新功能開發，Portal 依賴計費的介面，雙方約定基於介面開發（內部、外部依賴介面場景均通用）
【開發階段】Portal 在開發進行中，計費尚未開發完畢，Portal 遲遲不能與計費對接除錯（也有可能版本迭代步伐不一致的情況），測試階段一直被推遲；
另外，即使計費介面開發完畢，Portal 需要修改計費約定的介面資料進行除錯，當發現沒有對方介面許可權或者計費沒有過多人力資源來配合時，也無法進入更豐富的資料細節除錯；
【測試階段】測試人員無法及早介入到除錯階段進行介面測試，造成發現缺陷的最佳時期被推遲；
場景三：
【需求階段】移動 APP 專案依賴後端獲取頻寬資料的介面
【開發階段】移動 APP 端通過後端系統 API 獲取頻寬資料，繪製頻寬圖，APP 端繪圖工具開發完畢，後端 API 頻寬介面尚未開發完畢，移動 APP 端只能硬編碼資料進行測試，造成對接延後，每次進行更豐富的資料除錯，需要頻繁重啟服務、本地部署；
研發自測階段無法及早開展，依賴介面約束大。
總而言之，如圖所示：
依賴介面開發完畢，才能夠進入到介面聯調測試階段，即使 Portal 的功能開發已經完成，也無法進行自測聯調，消耗的等待時間代價是不可估量的，效率低，。
圖 -1- 傳統的介面對接除錯流程
手工作坊 -Nginx 反向代理
要解決在研發過程中介面對接除錯難的問題，無非是所需即所有，減少等待時間，增加研發自測環節，同時也讓測試及早參與進來，因此需要能夠把依賴介面模擬出來（白盒方面的 Mock 有許多解決方案，這裡主要講的是基於 HTTP 請求的 API Server Mock），以便提高生產效率，改進流程如圖所示：
圖 -2- 改進的介面對接除錯流程
當前最簡單的想法是要解決：基於 HTTP 請求、固定 url、能夠正則匹配，在這個需求的驅動下，通過 Nginx 的反向代理能夠解決問題。
匹配具體路徑下某 html 檔案
location ~ ^/live/(.*)\.html$ {
root /home/htmlfile/ms;
}
location ~ ^/live/([A-Z0-9]+)$ {
}
定義具體返回碼
location ~ ^/schedule/.*\.(json)$ {
error_page404/404.html;
}
定義其它狀態碼也是同樣道理：
error_page 403 /error/403.html; error_page 500 501 502 503 504 /error/500.html;</pre>
俗話說：術業有專攻，Nginx 並不擅長做 Mock API 的工具，在管理配置檔案即使可以通過 svn 進行管理，依然是維護比較困難，對於不熟悉 Nginx 的測試工程師，也有一定的學習成本。
拿來主義：不重複造輪子 - 開源 WireMock
經歷了 Nginx 的配置繁瑣，決定另尋新路，有開源的 WireMock（ ofollow,noindex">http://wiremock.org/ ）：
Ø WireMock 是一個靈活的庫，用於 Web 服務測試，和其他測試工具不同的是：WireMock 建立一個實際的 HTTP 伺服器來執行你的 Web 服務以方便測試；
Ø 支援 HTTP 響應存根、請求驗證、代理 / 攔截、記錄和回放；
建立一個基於 WireMock 的 JavaProject（執行在 tomcat 下管理）：
圖 -3-ServerMock Project
web.xml 配置如下：
<?xml version="1.0" encoding="UTF-8"?> <web-app id="WebApp_9" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"> <listener> <display-name>wiremock-startup-listener</display-name> <listener-class>com.github.tomakehurst.wiremock.servlet. WireMockWebContextListener</listener-class> <description>Loads WireMock and populates the servlet context with its services</description> </listener> <context-param> <param-name>WireMockFileSourceRoot</param-name> <param-value>/WEB-INF/wiremock</param-value> </context-param> //如果對軟體測試、介面測試、自動化測試、效能測試、LR指令碼開發、面試經驗交流。 <context-param> //感興趣可以175317069，群內會有不定期的發放免費的資料連結，這些資料 <param-name>verboseLoggingEnabled</param-name> //都是從各個技術網站蒐集、整理出來的 <param-value>false</param-value> //如果你有好的學習資料可以私聊發我，我會註明出處之後 </context-param> //分享給大家。 <servlet> <servlet-name>wiremock-mock-service-handler-servlet</servlet-name> <servlet-class>com.github.tomakehurst.wiremock.jetty6. Jetty6HandlerDispatchingServlet</servlet-class> <init-param> <param-name>RequestHandlerClass</param-name> <param-value>com.github.tomakehurst.wiremock.http. StubRequestHandler</param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>wiremock-mock-service-handler-servlet</servlet-name> <url-pattern>/*</url-pattern> </servlet-mapping> <servlet> <servlet-name>wiremock-admin-handler-servlet</servlet-name> <servlet-class>com.github.tomakehurst.wiremock.jetty6\. Jetty6HandlerDispatchingServlet</servlet-class> <init-param> <param-name>RequestHandlerClass</param-name> <param-value>com.github.tomakehurst.wiremock.http. AdminRequestHandler</param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>wiremock-admin-handler-servlet</servlet-name> <url-pattern>/__admin/*</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>index.json</welcome-file> <welcome-file>index.xml</welcome-file> <welcome-file>index.html</welcome-file> <welcome-file>index.txt</welcome-file> </welcome-file-list> <mime-mapping> <extension>json</extension> <mime-type>application/json</mime-type> </mime-mapping> <mime-mapping> <extension>xml</extension> <mime-type>application/xml</mime-type> </mime-mapping> <mime-mapping> <extension>html</extension> <mime-type>text/html</mime-type> </mime-mapping> <mime-mapping> <extension>txt</extension> <mime-type>text/plain</mime-type> </mime-mapping> </web-app>
web.xml 的這項配置可以改變原始檔位置
<context-param> <param-name>WireMockFileSourceRoot</param-name> <param-value>/WEB-INF/wiremock</param-value> </context-param>
使用 Maven 管理依賴，配置如下：
<dependency> <groupId>com.github.tomakehurst</groupId> <artifactId>wiremock</artifactId> <version>1.53</version> <!-- Include everything below here if you have dependency conflicts --> <classifier>standalone</classifier> <exclusions> <exclusion> <groupId>org.mortbay.jetty</groupId> <artifactId>jetty</artifactId> </exclusion> <exclusion> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> </exclusion> <exclusion> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-core</artifactId> </exclusion> <exclusion> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-annotations</artifactId> </exclusion> <exclusion> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-databind</artifactId> </exclusion> <exclusion> <groupId>org.apache.httpcomponents</groupId> <artifactId>httpclient</artifactId> </exclusion> <exclusion> <groupId>org.skyscreamer</groupId> <artifactId>jsonassert</artifactId> </exclusion> <exclusion> <groupId>xmlunit</groupId> <artifactId>xmlunit</artifactId> </exclusion> <exclusion> <groupId>com.jayway.jsonpath</groupId> <artifactId>json-path</artifactId> </exclusion> <exclusion> <groupId>net.sf.jopt-simple</groupId> <artifactId>jopt-simple</artifactId> </exclusion> </exclusions></dependency>
具體的部署這裡就不介紹了，說說 WireMock 的配置：
Ø WireMock 的檔案目錄
如圖所示：
mappings: 存放對映描述的檔案
__files: 存放對映匹配結果的檔案
Line"/>
圖 -4-WireMock 的檔案目錄
WireMock 的匹配規則示例
分兩種：完整 Url 匹配和正則 UrlPattern
Url：完全匹配
mappings:cities-mapping.json
{
"request": {
"method": "GET",
"url": "/cities"
},
"response": {
"status": 200,
"bodyFileName": "/cities.json",
"headers": {
"Content-Type": "application/json",
"Cache-Control": "max-age=86400"
}
}
}
__files:cities.json
{
"cityName": "公司操作間",
"shortname": "WS",
"provinceName": "北京",
"provinceNameEn": "BeiJing City",
"code": "0001",
"cityNameEn": "Workshop"
}
UrlPattern：正則匹配任何 6 位數的，例如：/customer/123456/
mappings:cities-mapping.json
{
"request": {
"method": "GET",
"urlPattern": "/customer/[0-9]{6}/"
},
"response": {
"status": 200,
"bodyFileName": "/customer.json",
"headers": {
"Content-Type": "application/json",
"Cache-Control": "max-age=86400"
}
}
}
__files:customer.json
{
"channels": [],
"code": "781",
"companyName": "",
"enable": true,
"name": "163",
"password": "[email protected]",
"userState": "COMMERCIAL"
}
高效平臺化
使用 WireMock 通過 mappings 和 __files 資料夾可以有效管理對映和返回內容檔案，但是所有檔案的有部分可抽取未固定模板，而這些部分目前是手動編輯，關注這些部分會分散業務的精力，如果可以做成平臺化管理，所有介面通過建立完成，檔案命名規則全部由系統進行管理，將節省的時間更多投入業務關注和及早進行自測，這樣子的收益將會更大。
那怎麼樣的平臺才算能夠滿足當前需求呢？
- 基於 HTTP 協議
- 支援 Url、UrlPattern 匹配
- 支援資料儲存
- API 介面規範化管理
- 提交表單即可生成 mapping 和 __files 所需檔案
- 不同專案介面有不同的字首
- 能夠返回指定格式（json|xml|文字）內容
圖 -4-ServerMock-v1.0- 架構圖
根據架構圖，做了總體規劃如下：
圖 -5-ServerMock-v1.0 規劃
如果對軟體測試、介面測試、自動化測試、效能測試、LR指令碼開發、面試經驗交流。感興趣可以175317069，群內會有不定期的發放免費的資料連結，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。
技術選型
由於原來的測試平臺使用 Python 編寫，為了保持風格一致，從介面錄入到檔案生成處理依然採用 Python，後臺工具使用 WireMock 的 standalone 模式，通過 shell 指令碼進行一鍵啟停管理，以及實時重新整理 url、mapping 對映；
HTTP API Mock 專案管理 Web 前臺
使用 Python+Django+SQL/">MySQL 進行開發，分為專案配置和介面配置兩大部分。
專案配置頁
介紹：配置協議、進行 mock 伺服器的重啟、重新載入（有新的介面檔案生成系統會自動 reset 即可，當然手工 reset 也可以，即時載入無須重啟服務等待）。
圖 -6- 專案配置頁
介面列表頁
介紹：展示列表，列出相關 URL、方法、是否正則、返回碼、返回型別。
圖 -7- 介面列表頁
介面配置頁
介紹：選擇方法、URL 型別，填寫 URL（如果選擇 URL 型別為 UrlPattern，則填寫正則表示式），填寫狀態碼、返回介面，以及返回頭，就可以完成一個 mock 介面的建立。
圖 -8- 介面配置頁
介面配置有三種輸入形式：
直接輸入返回結果
圖 -9- 手工輸入
一般場景在返回結果 500k 以內的內容，可以直接輸入，儲存進入資料庫；
通過 url 抓取返回結果
圖 -10-url 抓取
一般場景在返回結果超過 500k 以上內容，目標 Mock 介面已經存在，可以直接抓取生成檔案；
通過檔案上傳返回結果
圖 -11- 上傳檔案
一般場景在返回結果比較大|目標 Mock 介面還未開發完成，手工上傳返回內容的檔案即可。
以上三種靈活的儲存返回內容方式，最終儲存的介面會按照以下格式生成 mapping 和 __files 所需檔案：
圖 -12-mapping 和 __files 檔案格式
Mock 專案管理 Server 後臺
使用 Java-WireMock 進行後臺服務，在專案配置頁通過按鈕：重啟、重新載入，呼叫後臺指令碼：wiremock_controller.sh，僅供參考：
#!/bin/bash if [ "$#" = 0 ];then echo "Usage: $0 (start|stop|restart|reset)" exit 1 fi dirWiremock=`pwd` getCount=`ps -ef | grep "wiremock-1.53-standalone" | grep -v "grep" |wc -l` wiremock_jar=${dirWiremock}/wiremock-1.53-standalone.jar port=9999 wiremock_url=http://localhost:${port} stop(){ count=${getCount} if [ 1==${count} ];then curl -d log=aaa ${wiremock_url}/__admin/shutdown echo "Stop success!......" else echo "Already stop" fi } start(){ count=${getCount} if [ 0==${count} ];then nohup java -jar ${wiremock_jar} --verbose=true --port=${port} & echo "Start success!......" else echo "Already start" fi } if [ "$1" = "restart" ];then count=${getCount} if [ 1==${count} ];then echo "Wiremock is running,wait for restarting! ...." stop echo "Start wiremock......" start else start fi elif [ "$1" = "start" ];then echo "Start wiremock......" start elif [ "$1" = "stop" ];then echo "Stop wiremock......" stop elif [ "$1" = "reset" ];then count=${getCount} if [ 0==${count} ];then echo "Wiremock must be running before reset,wait for starting! ...." start fi curl -d log=aaa${wiremock_url}/__admin/mappings/reset echo "Reset success!......" fi
其中：
“nohup java -jar {port} &”：在 linux 系統後臺執行 WireMock；
“curl -d log=aaa ${wiremock_url}/__admin/mappings/reset”：是通過傳送 POST 請求，重新載入新生成的配置檔案，在 WireMock 的原始碼中可以看到：reset 的作用：
public interface Admin {
void addStubMapping(StubMapping stubMapping);
ListStubMappingsResult listAllStubMappings();
void saveMappings();
void resetMappings();
void resetScenarios();
void resetToDefaultMappings();
VerificationResult countRequestsMatching(RequestPattern requestPattern);
FindRequestsResult findRequestsMatching(RequestPattern requestPattern);
void updateGlobalSettings(GlobalSettings settings);
void addSocketAcceptDelay(RequestDelaySpec spec);
void shutdownServer();
}
通過一系列原始碼追溯，可以找到重置：
@Override
public void reset() {
mappings.clear();
scenarioMap.clear();
}
可以推測對映檔案是存放到列表的：
public class SortedConcurrentMappingSet implements Iterable<StubMapping>{
private AtomicLong insertionCount;
private ConcurrentSkipListSet<StubMapping> mappingSet;
......
}
當 WireMock 啟動，日誌有以下描述：
2015-02-12 11:38:37.844 Verbose logging enabled 2015-02-12 11:38:38.657:INFO::Logging to STDERR via wiremock.org.mortbay.log.StdErrLog 2015-02-12 11:38:38.664 Verbose logging enabled /$/$ /$/$/$/$ | $/$ | $|__/| $$/$$| $ | $ /$$| $ /$/$$$/$$$ | $$/$$/$$$/$$$$| $/$ | $/$ $ $| $ /$__$ /$__$| $ $/$ $ /$__$ /$_____/| $/$/ | $$_$$| $| $\__/| $$$$| $$$| $| $\ $| $| $$$/ | $$/ \$$| $| $| $_____/| $\$ | $| $| $| $| $_$ | $/\$| $| $|$$$$| $ \/| $|$$$/|$$$$| $ \$ |__/\__/|__/|__/\_______/|__/|__/ \______/\_______/|__/\__/ port:9999 enable-browser-proxying:false no-request-journal:false verbose:true
如果對軟體測試、介面測試、自動化測試、效能測試、LR指令碼開發、面試經驗交流。感興趣可以175317069，群內會有不定期的發放免費的資料連結，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。
圖 -13-WireMock 啟動
成功處理請求的日誌：
2015-02-12 11:41:10.320 Received request: GET /test/today/dkfDF123/1234/ HTTP/1.1 Host: 192.168.32.55:9999 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Cookie: csrftoken=alXbvCtMyTBI1wnSnRoljguTaBnTDbPo; sessionid=tvoi9rzs66umnt1a26wsj36eqry2e2lo Connection: keep-alive
總結
HTTP API 介面測試痛點是什麼？很多公司劃分不同研發組，各組系統之間的資料互動通過介面來實現，那很多時候就是集中在介面開發不同步，測試無法及早參與，對接除錯難的問題。或許很多團隊遇到這種問題，就是選擇同步開發或者等待。當你選擇等待的時候，你的產品質量就得不到及時驗證，因為根本沒有測試過，在當前快速迭代的開發模式中，時間是最致命的要素，如果不能及時交付，交付的質量又得不到保證，那是相當被動的局面，最後返工的成本比你當時願意追加測試的成本會來的更高。
遇到這類問題是想辦法解決，而不是迴避，我們可以使用 Mockito 對依賴進行 Mock，那同樣道理，使用 Mock 技術也可以對 HTTP API 進行 Mock，按照這個思路探索下去，看看有沒有開源解決方案，是否能夠解決當前問題，如果可以就不用重複寫一套解決方案；如果不行，那能否基於開源的做二次開發呢？當團隊經歷過測試痛點，調研收集了一定的資料，這些問題的答案就會浮出水面了。
或許有人要問，使用之後能夠提高多少效率呢？看回《圖 -2- 改進的介面對接除錯流程》，根據我們的經驗，要統計當前迭代中有多少 API 需要對接除錯，如果對比舊的模式來說,API 介面除錯效率提升至少有 10%；可想而知，迭代中全是依賴 API 介面開發的話，那提升的效率就相當可貴了。