痛點、挑戰今天分享的重點是基于蘇甯的測試平台，結合中背景系統的業務特性，做接口自動化測試的一些思路，問題和解決方案。會從在我們接口自動化測試遇到的痛點切入，介紹我們的幾點解決方案、以及接口自動化實施後的成效，包括接口自動化的其他能力輸出，比如資料倉庫的概念，最後會簡單介紹下關于接口自動化我們後續的規劃。
蘇甯易購包含前中背景，其中中台串聯了前台和背景的核心邏輯，提供了幾乎所有核心交易流程需要的基礎服務，公共服務群組合服務，中台提供的接口服務将近2000個，幾乎所有的測試工作圍繞接口進行，同時，因為我們的測試工作對于上下遊系統的依賴非常大，是以無論測試效率，測試品質均遇到了非常大的挑戰。
随着系統拆分越來越細，我們的接口也越來越多，并且業務的複雜度越來越高，業務疊代更新的速度非常快，在這樣的大背景下，我們的測試人員其實是非常心累的，首先我們測內建測試中系統鍊路太長了，舉個例子，在售前環節，讓一個商品能在四級頁展示具備購買條件。這個鍊路包含了商品-采購-庫存-供應鍊/上下架-尋源-價格-四級頁展示衆多系統，涉及系統大概30多個，這隻能算是完成一個簡單的測試商品構造。在交易鍊路，物流鍊路、售後，财務等各個環節涉及的系統鍊路更加複雜，是以我們的內建工作效率是相對較低的，并且內建測試發現的缺陷抽絲剝繭，層層追溯下來，整個定位缺陷的效率也非常低。在這樣的大環境下，測試人員比較崩潰。是以我們的測試工作要換一個角度進行。
解耦，分層測試是我們唯一之路
我們聚焦接口測試，聚焦接口自動化測試
目前主流的接口測試工具很多，自動化工具和架構也讓人眼花缭亂，有輕量級的架構，簡單的基于浏覽器的插件，衆多開源的平台等等，但是這些每一個工具和架構放到我們業務系統的背景下看，支援力度上或多或少都有一些問題，比如對複雜接口場景的支援力度不夠，和中間件的內建做的不夠好，測試人員編寫和維護腳本的成本較高，等等。結合我們的業務特性，蘇甯研發了自己的一套測試平台，在自動化的架構中內建了SoapUI,rft,selenium等多個工具以及架構的思想和部分功能。
我們的測試架構分為用戶端工具和服務端平台兩部分，用戶端架構包含用例和執行器兩部分，分别提供用例管理，關鍵字管理，DataConfig的配置項管理等，執行器部分包含了基礎關鍵字和自定義的業務關鍵字。其中，基礎關鍵字部分是在Selenium，Appium，HttpClient基礎上進行的封裝。用戶端工具目前支援移動端，服務協定，浏覽器，以及SAP服務等各種類型的自動化用例編寫和執行。
蘇甯中台接口自動化測試政策
首先，我們的主旨是打斷依賴，聚焦單接口。上遊通過模拟請求消息，下遊通過mock擋闆的機制做接口測試。同時，我們的自動化用例實作用例和資料的高度分離，具體方法後面的片子會介紹。其次，我們會通過原子用例的機制去實作用例的高可維護性。另外，我們的接口自動化用例一般分為兩種，單系統的接口和依賴下遊服務的接口，第一種很簡單，模拟消息發出去，抓取本系統的傳回封包做校驗即可。第二種，下遊服務的接口，會通過模拟樁實作，我們的模拟樁根據使用場景不同，分為請求級的樁 和應用層面的全局樁。
關于模拟樁，簡單的埋樁似乎不夠
說到模拟樁，我相信做接口自動化的各位專家都會有很多成熟的方案 。那在蘇甯，接口自動化在涉及模拟樁的實作上也遇到一些問題，首先在傳統的ESB元件的架構下，我們模拟樁的實作，是通過設定過濾器的方式，發出去的請求會帶上樁标記，通過過濾器攔截到請求，把請求轉發到模拟樁服務，樁服務分析請求内容比對到正确的樁。--這種場景下，我們通過請求級的樁實作。在蘇甯的另一個元件RSF下實作模拟樁，在有些特殊場景下遇到了一些問題。
異步：1、MQ下發，job處理的場景，且後端需要調用接口的情況下，沒有地方帶入樁标記
多現場：2、多線程場景下，樁标記在上個線程已被銷毀，平行線程擷取不到
異步調下遊系統的場景還是比較多的：
針對MQ下發，比如，庫存系統通過MQ隊列接入活動，活動可用性檢查時會去調用尋源檢查商品是否有源，有源才将活動資料存表，無源則建立失敗不存表。這個異步場景下，找不到裝标記。
針對多線程，訂單支付處理的場景，先傳回處理成功，内部會在下個線程處理内部資源。
針對這些特殊場景我們需要另辟蹊徑，考慮解決方案。
全局樁：一種通過Servlet注入标記的方式
接口自動化重點—封包驗證
關于job應用的場景，觸發job方法
有了這些寫出的腳本就夠了了嗎？
原子用例：一種高度封裝，抽取業務邏輯的自動化最小單元
原子用例特性
原子用例為有效減低編寫和維護自動化成本提供了一種方案
除了業務邏輯封裝，我們還須資料的高度抽取
接口自動化實施後，我們的工作有哪些變化
我們的接口自動化隻做了這些嗎？NO
接口自動化能力輸出-資料倉庫
使用資料倉庫第一步先進行資料整理
資料倉庫在測試平台上的使用