1
前言
本期想跟大家分享下我們在接口自動化方面的實踐。
從測試金字塔模型看，接口測試位于第二層，相比UI自動化，接口會相對穩定一些，而且接口測試既可關注單個接口參數取值的合理性，也可以驗證産品功能的完整性和正确性。是以，基于合理的接口設計下，維護一套穩定可用的自動化case是比較理想的方案。
測試金字塔
2
現狀分析
随着客戶數量越來越多，觀遠産品目前正在高速發展的階段，産品版本快速疊代，每月甚至每周都會有一系列的疊代釋出，同時業務複雜度也越來越高，随之而來的是大量且不斷增多的測試用例，僅BI一條産品線目前就有4000+用例。在每個産品版本釋出上線之前，需要做大量的測試工作，包括新需求測試、主幹分支測試、回歸測試等，同時因為觀遠是私有化部署模式，是以還需要同時維護多個不同版本的産品，測試工作量就會随之翻倍，業務測試壓力可想而知。
以上現狀和帶來的業務痛點在一定程度上push我們盡快地通過自動化提升人效。接口自動化的投入産出比高，相對「實時」地發現缺陷，同時也能使測試左移，提早發現問題，這也是我們推動測試自動化的理由之一。
3
方案選型
市場有很多的自動化平台/測試工具，目前比較流行的開源自動化架構，如：unittest、JUnit、TestNG、Robot Framework等等。每個架構都有它的優缺點，哪一個是符合我們目前需求的架構呢？我們選擇了其中的幾種比較有代表性的架構做了一個簡單的對比。
| 架構 | unittest | JUnit | TestNG |
| 腳本語言 | python | java | java |
| 用例分類執行 | 可通過@pytest.mark來标記類和方法 | 不支援分組執行用例 | 可通過@group來分組 |
| 參數化 | 需依賴ddt庫 | 使用 @ParameterizedTest 注釋 | 利用@Parameter 注釋并将參數添加到給定的測試方法 |
| 斷言 | 支援多種斷言格式 | 支援多種斷言格式 | 支援多種斷言格式（assertEqual、assertTrue等等） |
| 報告 | 使用HTMLTestRunnerNew庫 | 以 XML 檔案格式提供資料 | 自動生成測試報告 |
| 失敗重跑 | 支援 | 不支援 | 支援 |
| 并行測試執行 | 不支援 | 支援 | 支援 |
通過參數化、斷言、報告等幾個次元的對比，可以看出TestNG測試架構在功能上更為強大。它擴充性強、易維護，且自帶注釋标簽、報告、case配置靈活性強。觀遠目前有多條産品線，TestNG允許我們自定義封裝各種協定接口，可以內建各個産品線個性化的項目架構。但原生的TestNG在一些功能上還不是特别能滿足我們的需求，比如原生測試報告比較簡陋，可讀性不高，我們希望能更直覺地展示測試版本、通過率、失敗詳情等資訊；原生TestNG隻支援通過xml配置分組測試，靈活性不高，而我們需要在不同的需求場景下執行不同優先級用例。是以結合觀遠業務的實際情況、項目架構及産品技術棧等，我們在此基礎上擴充，建構了一套适合觀遠業務模式的持續內建測試架構。
4
架構介紹
我們先通過一個簡單的圖來了解下觀遠持續內建測試架構主要做了哪些事情。
Update Check 前期環境準備：自動維護測試環境，使環境可用且符合測試需求，保證後續的測試執行是正确的。每日自動建立自動化測試執行計劃，若當日無代碼更新則不執行，減少伺服器資源損耗。
API Check 接口監控：每日監控新增的api并通知到責任人，保證接口自動化覆寫率。
API Testing 自動化測試：鏡像部署，測試執行，報告整理，消息通知。
以上組成了觀遠一站式的自動化測試，隻需要在jenkins上主動或者自動化發起測試計劃，就會根據選擇的配置進行測試，直至收到測試報告。下面我們主要來介紹一下核心部分 API Testing。
通過上圖可以看出一個case在API testing中被以下子產品執行的過程：
- jenkins子產品：測試同學主動選擇測試類型、測試分支及其他可選參數（如優先級等），觸發建構動作；也支援定時觸發。
- 用例資料接入子產品：擷取測試檔案中的資料（用例描述、入參、期望、忽略值等等）。同時為了友善管理，以業務子產品為準則進行劃分，如使用者子產品、系統設定子產品等，各子產品資料隔離。
- 用例執行子產品：基于測試資料，對基準資料進行預處理，觸發接口請求。
- 斷言子產品：擷取關鍵response，提供多樣化的斷言能力。
- 報告子產品：內建三方插件生成報告，內建jenkins和釘釘能力進行消息通知。
5
實踐和探索
有一個技術可行的架構其實隻是第一步，我們更注重的是架構的可維護性和易用性，如果日後還需要大量維護工作或者實際開發起來生澀難用，那麼也無法提高人效。我們在實際使用時也遇到了一些問題，TestNG架構需要一定的學習成本，大家的代碼基礎不太一樣，對于較薄弱的同學使用還是有一定的難度。為了降低大家的上手成本，觀遠自動化測試架構在資料接入、斷言服務等方面做了一些處理。
模闆化的資料接入
實際上在觀遠BI産品的疊代過程中，基準測試資料的變化，尤其是期望資料的變化還是比較頻繁的。很多時候用例失敗，可能隻是因為接口新增或者删除了一個字段，和接口請求本身沒有關系，如果這個時候還需要測試同學深入到代碼工程中調試就比較繁瑣了。
為了解決類似的問題，我們支援了用檔案進行資料接入，目前支援2種測試用例形式：yaml和excel，統一在測試伺服器上進行管理。檔案中包括用例描述、入參、期望、忽略值等字段值。
通過smb讀取檔案，整理後以Object[][]格式傳回給test類，即為請求入參。
/**
* 主要用于 DataProvider 提供測試用例
*
* @param path
* @return Object[][]
* @throws Exception
*/
public static Object[][] read(String path, InputStream io) throws IOException {
log.info("目前要讀取的檔案檔案名稱為:" + path);
Object[][] result = new Object[][]{};
if (path.endsWith(".xlsx")) {
result = ExcelReader.readInputStream(path, io);
} else if (path.endsWith(".yaml")) {
result = YamlUtil.getYamlObject(io);
}
io.close();
if (result == null) {
throw new RuntimeException("擷取檔案異常");
}
return result;
} 具體的用例執行時，通過TestNG的@DataProvider擷取包體資訊。
@Test(dataProvider = "dataPro", testName = "XXXXTest", groups = {"P2"})
public void enableUserTest(String description, String parameter, String expected) {
// TODO
smbUtils.read("excel path");
} 當一個用例發生了字段上的改變，隻需要修改excel檔案内容即可。同時，如果我們需要擴充接口場景，也隻需要在excel中新增一條記錄，一定程度上降低開發成本。近期，我們同時又開發一個B/S架構的用例管理平台，比檔案形式的資料管理更加易用，通過界面互動即可完成用例基準資料的更新，對代碼基礎薄弱的同學更加友好。
接口請求
執行一個用例之前，往往都要做大量的準備工作，像環境切換、使用者登入等。比如使用者登入，需要輸入域名、使用者名、密碼，調用登入接口，解析傳回包體擷取token等一系列操作，這些操作繁瑣且重複性高。是以我們将所有的測試類都繼承了ApiAbstract父類，父類中使用@BeforeSuite、@AfterSuite注解進行http連接配接、使用者登入、環境版本擷取等參數準備，以及接口耗時計算等。後續如果有全量性的需求也友善擴充。
public void setUp() {
client = HttpClientGenerator.getHttpClient();
user = new User(client, re);
auth = new Auth(client, re);
setting = new Setting(client, re);
publicAPI = new PublicAPI(client, re);
Response res1 = auth.signIn(Env.LOGININFO);
// 擷取ssotoken登入token
getSsoToken();
// 擷取publicapi
getPublicToken();
// 擷取server版本号
Env.version = PodServices.getVersion();
} 同時為了減少網絡不穩定等的影響，所有測試case接入監聽，針對失敗的用例重試，若三次後依然失敗，則認為存在缺陷或者性能問題。
public class RetryListener implements IAnnotationTransformer{
@Override
public void transform(ITestAnnotation testannotation, Class testClass,
Constructor testConstructor, Method testMethod) {
IRetryAnalyzer retry = testannotation.getRetryAnalyzer();
if (retry == null) {
testannotation.setRetryAnalyzer(Retry.class);
}
}
}
public class RetryTestNGListener extends TestListenerAdapter {
@Override
public void onTestSuccess(ITestResult tr) {
super.onTestSuccess(tr);
// 對于dataProvider的用例，每次成功後，重置Retry次數
Retry retry = (Retry) tr.getMethod().getRetryAnalyzer();
retry.reset();
}
@Override
public void onTestFailure(ITestResult tr) {
super.onTestFailure(tr);
// 對于dataProvider的用例，每次失敗後，重置Retry次數
Retry retry = (Retry) tr.getMethod().getRetryAnalyzer();
retry.reset();
}
} 多樣化的斷言
接口請求完畢後，對傳回包體進行斷言，這是相當重要的一環。因為産品場景的多樣性和不統一性，不同的接口往往在結構上存在很大的差異，這就要求我們針對不同接口有不同的斷言處理。
架構裡針對觀遠BI産品中最常見的json格式提供了幾種斷言方法，比如通過正規表達式校驗、結構體包含校驗、忽略順序的結構體校驗，主要是jsonPath斷言。具體每種斷言方式的使用場景和校驗邏輯我們會在未來繼續做分享。
可快速定位問題的測試報告
測試的目的是保證接口結果的穩定及準确性，當case執行失敗時，需要我們快速地定位可能出現問題的原因。目前大多的三方測試報告隻會提示部分錯誤資訊或者是錯誤代碼行數，測試同學去确認問題原因時會很耗費時間，有可能還需要重新執行才能确認。
我們在斷言結束後，若case結果不符合預期，則抛出異常，還會生成詳細的報告。我們對測試報告做了模闆化處理，最後的自動化報告内可以看到請求的錯誤消息以及錯誤報告，以便研發和測試同學快速定位失敗原因。同時，測試case執行完畢後，jenkins腳本會彙總所有測試報告，打包釋出至tomcat，友善線上檢視、未來回溯。
自動化能力拓展
架構能夠使自動化跑起來，但從嚴格意義上說還不算是可持續內建的架構，自動化執行計劃的建立、接口變化的監控、自動化結果的及時跟進等等能力都需要進一步滿足。’
打通持續內建到觸發自動化環節，自動化對代碼送出、新功能釋出進行快速驗證，建立自動化冒煙測試。自動化執行結果記錄儲存，包括失敗率，執行次數等，便于後續分析品質薄弱點。自動化需要在研發環節的更多階段發揮作用，持續的對開發送出代碼品質進行保證。目前我們已經完成了一部分，并持續地優化：
- 自動建立自動化測試執行計劃，如每日測試、回歸測試
- 每日監控新增的api并通知到責任人，保證接口自動化
- 測試報告自動發送給責任人并釘釘通知，儲存自動化執行結果記錄
6
總結
接口自動化已在觀遠多條産品線實踐，在提升回歸測試效率、測試左移等方面效果顯著。結合jenkins和git，我們建立了自動執行計劃，監控接口變化，并及時跟進自動化結果，持續保證産品的品質，更詳細的CI/CD實踐我們會在未來繼續分享。
作者:測試小張，觀遠測試開發工程師，深入産品業務，落地自動化規範，緻力于通過技術提高測試效率，保障産品品質。
來源-微信公衆号:觀遠資料技術團隊
出處:https://mp.weixin.qq.com/s/kGdlGSiC4ooyVbTdhRMVrA