一、說在前面基於微服務或者soa的自動化測試系統每個公司都有自己的特有的，我今天就主要介紹一下，我們研發的一套mock測試系統。
二、目前面臨的問題1、測試人員面臨的測試問題舉個例子：拿網際網路支付系統來說，某個團隊新增了支付交易的需求，這時候要進行測試，測試人員除了要測試支付交易需求本身是否正確，同時也要結合上下游的服務整體進行回歸測試，這時候開發人員往往在支付交易系統中採用「硬編碼」的方式對上下游的系統進行「擋板」，如果測試人員對測試資料有所調整那麼「擋板」也要跟著調整，同時在專案正式上線的時候，如果開發人員沒有將「擋板」程式去除乾淨，將面臨嚴重的線上問題。
2、測試人員如何驗證資料
三、mock模擬系統的產生業務系統呼叫眾多其他系統完成功能邏輯，而想要得到其他系統介面的特定輸出，需要做相應的運營配置，增加很多的溝通成本；甚至偶發性bug只能在特定的環境狀況下復現，只能作為不可測的邏輯。
以風控系統為例，如果業務系統需要測試某個商編某個商品類別下的累積限額，需要風控的同事配合不斷修改限額閾值，目前的情況是多個業務系統都在接入風控，配合測試的人力成本和時間成本是很高的。為此設計了擋板模擬系統，其功能結構如下：
針對測試人員測試用例資料無法沉澱和復用的問題，我們將採用「用例與日誌錨點庫」方案：
四、mock系統的技術方案1、系統的功能點
說明：
上圖羅列了整個mock測試系統的功能點有哪些，共分為：配置介面資料、建立測試用例、建立測試集、建立測試計畫、執行測試計畫以及生成測試報告等大功能。
說明：測試執行結果的用例結果，實際返回的應該是sucess或者fail提示資訊。
2、系統的功能流程圖
說明：
依據上下文環境，利用工廠類動態注入spring對遠端介面的依賴，保持線上與測試的**一致。在測試環境中，通過mock系統管理端，可以隨時調整請求的流向，「指哪打哪」
說明：
執行某項測試用例， 利用mock將被測試介面與底層依賴介面隔離開來，可以方便的模擬資料，並監控輸入輸出。用例執行完畢後，使用返回斷言、sql查詢、日誌標記等多種手段驗證。
五、感謝與後續在整個mock測試系統的設計和開發過程中，要特別感謝我的同事劉洋洋，給與的大力支援，目前系統正在部門內推廣使用中。自動測試的目的是模擬人的行為，用機器代替人工，高效而且便捷，節省人工成本並且有效的解決目前業務系統頻繁公升級導致的大量回歸測試。
小程眼裡的微服務
最近一直在研究微服務有了一點小小的成果，前段時間給公司部門同事做了分享，在此將ppt發出來與大家分享。這裡寫描述 這裡寫描述 這裡寫描述 這裡寫描述 這裡寫描述 這裡寫描述 這裡寫描述 這裡寫描述 這裡寫描述 這裡寫描述 這裡寫描述 這裡寫描述 這裡寫描述 這裡寫描述 這裡寫描述 這裡寫描述 這裡寫...
微服務 Dubbo的最佳實踐
這樣的配置可以讓 provider 的實現者一開始就思考 provider 端的服務特點和服務質量等問題。建議在provider端配置的屬性有 timeout 方法呼叫的超時時間 retries 失敗重試次數，預設是 2 加上第一次呼叫，會呼叫 3 次 loadbalance 負載均衡演算法 有多個...
基於python tkinter的點名小程式
讀取花名冊第一列資料進行隨機點名並生成點名記錄，並根據點名記錄確保點名的公平性，點名記錄每使用五天清理一次缺陷 1.依賴於花名冊，且花名冊第一列 忽略首行 必須有資料 2.依賴第三方庫openpyxl 3.檢視記錄 花名冊依賴第三方工具，如記事本 office def info t random.r...