共計 4999 個字符，預計需要花費 13 分鐘才能閱讀完成。
本篇文章給大家分享的是有關如何分析 SAP Cloud for Sales 自動化，丸趣 TV 小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著丸趣 TV 小編一起來看看吧。
今天我想基于目前 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 質量工程師在每日工作中需要去花心思琢磨的。而從團隊利益著手，考慮每一項質量活動的價值和意義，對質量工程師來說是一項全局觀的考驗，也是一場質量與效率的平衡。
以上就是如何分析 SAP Cloud for Sales 自動化，丸趣 TV 小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注丸趣 TV 行業資訊頻道。
