淺談SAP Cloud for Sales 自動化

在Jerry還在本科進行計算機理論知識學習時，我曾經把軟件開發裏的質量工程師(Quality Engineer)理解成是天天只是簡單地作着運行開發人員編寫好的軟件，若是發現問題，通知開發人員去修改這種機械的體力活。後來進入SAP後，觀察團隊裏的質量工程師天天作的事情，才知道我當初簡直是很傻很天真。

個人兩位同事，姚瑤和鄭曉霞，以前已經就她們在SAP質量工程師這個崗位上工做的一些體會作了分享：

• SAP成都研究院姚瑤：軟件質量保證工做的變遷
• SAP成都研究院鄭曉霞：Shift Left Testing和軟件質量保證的一些思考

今天，由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元素查找和隱式頁面等待處理等方面具備必定的優點。感興趣的同事可前往官網進行嘗試。

1. 工程結構及說明

此處以Social 案例爲例：

• DD_CSV: 案例運行的的數據來源
• Function_Library: 該目錄中存放已封裝的基本共用函數，如登陸、登出、工做中心訪問、表格訪問等。更加細緻的封裝則是將頁面元素抽象到Library中的IDS下，便於統一管理, 以下圖:

• SCRIPTS：特定的UI測試案例。
• SUITE：測試案例運行的範圍。

2. 案例編寫

此處以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自動化的分享，若有疑問或進一步探討，歡迎聯繫咱們，感謝閱讀。

相關閱讀

• SAP成都研究院姚瑤：軟件質量保證工做的變遷
• SAP成都研究院鄭曉霞：Shift Left Testing和軟件質量保證的一些思考

要獲取更多Jerry的原創文章，請關注公衆號"汪子熙":