在Jerry還在大學進行計算機理論知識學習時，我曾經把軟體開發裡的品質工程師(Quality Engineer)了解成是每天隻是簡單地做着運作開發人員編寫好的軟體，如果發現問題，通知開發人員去修改這種機械的體力活。後來進入SAP後，觀察團隊裡的品質工程師每天做的事情，才知道我當初簡直是很傻很天真。
我的兩位同僚，姚瑤和鄭曉霞，之前已經就她們在SAP品質工程師這個崗位上工作的一些體會做了分享：
今天，由Jerry的另一位同僚，Tang Minna繼續給大家帶來SAP标準産品品質控制方面的分享。
-
- *
大家好， 我是唐敏（Minna Tang），目前是SAP成都研究院C4S(Cloud for Service)團隊的品質工程師。除了本職工作以外，我喜歡烹饪蘇菜——少了川菜的熱烈與厚重，卻多了一份自然與純真；喜歡在圖書館裡拜讀名人傳記——看盡紅塵故事之後，靜靜地感受時光的流逝；閑暇時也喜歡尤克裡裡——跟随跳動的音符，感受人生的起起落落。
今天我想基于目前C4S産品的現狀和自身的技術背景，簡單聊聊自動化這個動人心魄、讓人又愛又恨的話題。
相信任何一個軟體開發團隊的每位成員，聽到“自動化”一詞，都會抱有熱烈的期待。對于老闆來說，這個詞意味着成本的下降及更高的ROI(Return On Investment，投資回報率)；從開發工程師的角度，自動化有助于更早地檢測到代碼變更對原有功能的影響；測試工程師當然是全力支援自動化的，因為省心和省力；産品經理自然也不會拒絕自動化，因為它能夠帶來更高效的傳遞和更快速的疊代。
然而，我們身邊也不乏自動化實施失敗的團隊。2013年在我前一家工作的公司裡，我曾參與某核心系統項目的開發工作，這個業務系統從需求到完整上線共耗時一年半，核心功能的開發更是耗時大半年之久。面對如此龐大的業務測試成本和強需求，PMO(Project Manage Office)在項目開發之初就啟動了自動化測試需求，然而在業務功能不穩定，産品需求、開發與測試基本屬于趕工狀态的情況下，與人工回歸相比，自動化所帶來的收益基本微乎其微。是以選擇适當的自動化時機和政策，是自動化成功與否的重要因素之一。
衆所周知，SAP衆多産品都在使用自研的ABAP進行開發。當我加入SAP後，我了解到這些運作在ABAP Netweaver之上的産品，均有完備的自動化測試。對于ABAP背景功能代碼，主要是開發人員為核心功能編寫完備的，覆寫率高的單元測試，然後用事務碼SUT排程成背景作業定期執行，如果自動化測試執行時發現故障，會自動發郵件通知相關人員。
前台UI代碼，無論是原生的Fiori應用還是CRM Web Client UI這種加了一層皮膚的類Fiori應用，都能通過Selenium來進行UI的自動化測試。
當然，SAP成都研究院也在進行衆多基于微服務架構的雲産品開發，主要使用Java程式設計，那麼自動化測試的實作也更加容易，Spring系列架構裡有大量成熟和流行的自動化測試套件可供使用。
從疊代釋出的角度講，C4S産品的釋出周期為一個季度一次，每個季度中有三個周期：前兩個周期主要完成新功能開發，第三個周期需要團隊成員既完成新功能測試，也需要回歸系統原有功能。與此同時，每個季度中還有5次更新檔的釋出，每一次都需要完成原有業務的回歸測試。夾在産品新特性測試和回歸測試之間的，是一望無際的工作量和對高效率、高品質測試的需求。
我為所在團隊負責的功能制定的自動化的政策是: 接口 + UI自動化覆寫。也許您會問，作為一個請求的最前端，既然UI的測試都能覆寫了，那自動化測試為什麼還需要接口的覆寫？工作量是否存在重複？從功能的角度來講，确實有些重複。但從收益的角度來講，對接口的自動化測試進行投入，收益遠超成本。
1. 對于任意一個系統，接口的穩定性在整個系統中的重要地位不言而喻。相對于後置的E2E（端到端）測試，接口測試能夠從基礎層減小變更對整個應用及下遊業務調用方的影響範圍。
2. 同時，接口的測試也能為UI自動化實施提供基礎資料。
UI自動化為了完成某個場景的測試，通常會有很多前置業務資料的依賴。這些UI自動化需要的測試資料如何生成?有同僚建議可以提前手工造資料。如果自動化測試的資料都要依靠手工來維護，在我看來，這個自動化不要也罷。通常，在接口測試完成之後會将已測試通過的接口封裝成工具類，供後續UI自動化的工程化調用，這樣既減少了UI自動化的資料依賴，對接口測試通過率也提出了更高的要求。是以一般的接口工程必須100%通過，才能完成觸發後續UI自動化的作用去執行功能測試。
3. 為性能測試準備打下堅實的基礎。
通常準備性能測試之前，接口測試的響應時間會成為回報接口性能的重要依據。我們在制定接口性能的SLA(Service-Level Agreement)時，其基本資料來源就是接口測試。而很多網際網路公司，相對于端到端的響應時間，他們更注重接口的響應時間，因為接口更底層。尤其針對多層接口依賴的系統，每年 618，雙11之前的線上大促壓測，接口全鍊路測試必定是重中之重。
我在C4S推薦使用的接口測試架構為Spring + Maven + Testng，語言為Java， 被測對象為C4S oData服務提供的HTTP API。其中Spring架構主要負責通過注解方式完成對象注入，Maven負責工程結構和Jar包管理，Testng負責具體的測試工作。對于不熟悉Java的朋友來說，借助現有工具諸如Postman也能很好地勝任這項工作。
1. 工程結構及說明
接口主體工程以Maven規範工程為模闆，所有的代碼和相關資源檔案均放置在src/test目錄下。工程子產品主要分為4部分：測試代碼、枚舉對象、工具類及相關資源檔案。
測試代碼：這是測試代碼的主要存放目錄。 通常根據業務的不同，我們将每一個接口的測試案例按照業務測試和參數測試分别編寫。
所謂業務測試，是指測試案例中涉及業務規則的部分。比如，某接口中存在一個channel(管道)字段。業務規則定義：當channel為all時，建立全管道使用的資料；當channel為特定值時，建立的資料隻能适用于特定的場景。則業務測試的案例有2個：
o Channel = all
o Channel = 特定資料
參數測試：主要測試接口參數字段是否為必填項。比如，某接口中存在一個channel為必填字段且必須為指定枚舉類型字元串，當傳入接口為null或blank或非枚舉值時，架構傳回HTTP 400參數錯誤，同時提示錯誤資訊。此時參數測試案例有3個：
o Channel = null
o Channel = “”（blank）
o Channel = “XXXX”（XXXX為非枚舉值）
枚舉對象：此部分是将業務中經常用到的固定參數使用枚舉的方式列出，友善整個工程使用。見下圖中httpEnum檔案夾中的類。
工具類：包括基本工具類和業務工具類部分。業務工具類是将特定接口進行封裝，友善下遊接口調用使用。
資源檔案：包括Spring相關配置，properties檔案以及參數測試中的資料來源檔案等。
2. 案例編寫
此處以實作oData的SocialMediaActivity 接口的自動化測試為例來進行說明。
我們借用顔值大師——李曉剛老師畫的圖來大緻了解SociaMediaActivity在C4S微信內建架構中的作用：
由上圖所知，C4S通過暴露SocialMediaActivity接口來友善Agent調用。
在C4S和Social Media內建的相關場景中，使用者可以通過關注微信公衆号來綁定一個特定的BusinessPartner(以下簡稱BP), 進而達到通過使用者在系統中自定義的微信Channel來直接與C4C服務子產品中的從業人員直接互動的目的。而Activity是針對指定的BP所進行的活動，例如建立ticket，點贊，回複等。故而完整的業務流程如下：
- 擷取系統token
- 擷取已關聯的BP資訊
- 建立ticket資訊
- 評論/點贊/回複操作
- 資料清理
- BeforeClass： 執行擷取token的準備工作。
- BeforeMethod： 建立/擷取已關聯的BP資訊。
- Test: 特定業務的測試案例。本處對Activity的層級和操作内容進行檢查，是以有2個測試方法。
- AfterMethod：清理已建立的Activity。此處需要重點說明是，為避免背景錯誤資料對應用正常使用的影響，每一次執行都需要對增量資料進行清除處理，保持環境幹淨整潔。
- AfterClass： 清理建立的BP資訊。
3. CI(Continuous Integration, 持續內建)
基于Maven工程的內建，本例中使用Jenkins進行示例，與此同時項目工程中需要使用surefire-plugin(一個用來執行測試用例的Maven插件)來配置相關的測試案例範圍。
在pom.xml中配置testng.xml檔案：
testng.xml檔案内容示例：
使用Maven的好處再次展現，隻需要簡單配置即可使用：
在Jenkins中加入testng report plugin展示，然後build即可。
雖然我更擅長使用基于Java的Selenium這個UI自動化架構，也明白接口測試完成之後，對UI自動化的巨大幫助，但由于C4S在印度和美國團隊内都使用現有的成型産品SAHI，是以這裡我隻介紹SAHI在C4S的應用。
SAHI是Tyto Software旗下的一個基于業務的Web應用自動化測試工具, 通過注入 JavaScript來通路 Web 頁面中的元素。相對于Selenium等自動化測試工具，SAHI在動态 ID元素查找和隐式頁面等待處理等方面具有一定的優勢。感興趣的同僚可前往官網進行嘗試。
此處以Social 案例為例：
- DD_CSV: 案例運作的的資料來源
- Function_Library: 該目錄中存放已封裝的基本共用函數，如登入、登出、工作中心通路、表格通路等。更加細緻的封裝則是将頁面元素抽象到Library中的IDS下，便于統一管理, 如下圖:
- SCRIPTS：特定的UI測試案例。
- SUITE：測試案例運作的範圍。
此處以RUI項目中SingleTab功能為例進行說明。
MultiTab和SingleTab功能是指在C4S産品中，當使用者在全屏模式下打開某一個或多個工作視圖時，系統會将多個工作視圖以Tab的形式顯示在工作區中；但是當使用者修改浏覽器大小到一定尺寸後，工作區中将隻顯示活動的那個Tab。
MultiTab顯示時，有活動與非活動Tab之分，同時要适配多個Tab的滑鼠操作切換和通過功能菜單的切換。如下圖所示：
SingleTab顯示：隻顯示目前活動的Tab，在顯示資料和形式上與MultiTab有差别，同時也要适配通過功能菜單的Tab切換。
與此同時，該特性需要測試系統在不同的主題、字型大小下此特性也能正常工作。是以測試案例的流程如下（可參考代碼注釋部分）：
(1) 重置相關特性：浏覽器大小，主題，字型大小，視圖類型，頁面預設過濾器
(2) 通路特定的工作視圖并顯示特定資料，驗證全屏模式下活動狀态的/非活動狀态的MultiTab的顯示和Tab上資料的正确性
(3) 縮小浏覽器大小：
- 驗證Tab上資料正确性
- 修改系統主題，驗證SingleTab的顯示
- 修改字型大小，驗證SingleTab顯示
3. CI內建
基于Jenkins的強大的插件功能，C4S通過将Jenkins與GTP(内部缺陷管理平台)的內建完成CI排程和運作。
UI自動化的CI內建，使得C4S産品的回歸測試的效率大大提升。以今年8月份釋出的版本為例，手工回歸的測試案例目前已接近7000個。如前文所述，諸多的測試案例在每個疊代中持續的回歸測試，則是一項耗時又耗力的工程。而且這僅僅隻針對回歸測試所執行的案例。
從手工回歸測試案例的數量不難看出，快速回報系統功能狀态機制在持續傳遞鍊中的重要性。而在對接口進行全覆寫測試之後，對UI自動化覆寫回歸測試主流程的需求也愈加強烈。
在C4S，我們借助Jenkins 并行測試完成UI自動化，并使用郵件通知測試結果。在節省人工回歸成本的同時，使得産品管理團隊能夠在短時間内快速、全面了解系統功能的運作情況，并給與團隊成員品質的信心。與此同時，在出現子產品功能失效甚至是系統當機時，這種快速回報鍊的建立為開發人員盡早盡快修複問題争取了時間，減少了後續修複的時間成本。
就目前的測試覆寫需求而言，由内到外的接口覆寫及端到端的UI覆寫，在滿足底層穩定可靠的同時，也保證前端功能的可用性。對于SAP品質工程師而言，工作内容遠非測試工作這一項内容，從團隊成員品質意識的提升到單元測試覆寫及檢查；從測試工作到團隊品質回報，都是SAP品質工程師在每日工作中需要去花心思琢磨的。而從團隊利益着手，考慮每一項品質活動的價值和意義，對品質工程師來說是一項全局觀的考驗，也是一場品質與效率的平衡。
以上就是我今天關于C4S自動化的分享，如有疑問或進一步探讨，歡迎聯系我們，感謝閱讀。
相關閱讀
本文來自雲栖社群合作夥伴“汪子熙”，了解相關資訊可以關注微信公衆号"汪子熙"。