如何分析SAPCloudforSales自動化-創(chuàng)新互聯

本篇文章給大家分享的是有關如何分析SAP Cloud for Sales 自動化，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

創(chuàng)新互聯長期為上1000家客戶提供的網站建設服務，團隊從業(yè)經驗10年，關注不同地域、不同群體，并針對不同對象提供差異化的產品和服務；打造開放共贏平臺，與合作伙伴共同營造健康的互聯網生態(tài)環(huán)境。為龍門企業(yè)提供專業(yè)的網站制作、做網站，龍門網站改版等技術服務。擁有十多年豐富建站經驗和眾多成功案例,為您定制開發(fā)。

今天我想基于目前C4S產品的現狀和自身的技術背景，簡單聊聊自動化這個動人心魄、讓人又愛又恨的話題。

相信任何一個軟件開發(fā)團隊的每位成員，聽到“自動化”一詞，都會抱有熱烈的期待。對于老板來說，這個詞意味著成本的下降及更高的ROI(Return On Investment，投資回報率)；從開發(fā)工程師的角度，自動化有助于更早地檢測到代碼變更對原有功能的影響；測試工程師當然是全力支持自動化的，因為省心和省力；產品經理自然也不會拒絕自動化，因為它能夠帶來更高效的交付和更快速的迭代。

然而，我們身邊也不乏自動化實施失敗的團隊。2013年在我前一家工作的公司里，我曾參與某核心系統項目的開發(fā)工作，這個業(yè)務系統從需求到完整上線共耗時一年半，核心功能的開發(fā)更是耗時大半年之久。面對如此龐大的業(yè)務測試成本和強需求，PMO(Project Manage Office)在項目開發(fā)之初就啟動了自動化測試需求，然而在業(yè)務功能不穩(wěn)定，產品需求、開發(fā)與測試基本屬于趕工狀態(tài)的情況下，與人工回歸相比，自動化所帶來的收益基本微乎其微。所以選擇適當的自動化時機和策略，是自動化成功與否的重要因素之一。

眾所周知，SAP眾多產品都在使用自研的ABAP進行開發(fā)。當我加入SAP后，我了解到這些運行在ABAP Netweaver之上的產品，均有完備的自動化測試。對于ABAP后臺功能代碼，主要是開發(fā)人員為核心功能編寫完備的，覆蓋率高的單元測試，然后用事務碼SUT調度成后臺作業(yè)定期執(zhí)行，如果自動化測試執(zhí)行時發(fā)現故障，會自動發(fā)郵件通知相關人員。

前臺UI代碼，無論是原生的Fiori應用還是CRM Web Client UI這種加了一層皮膚的類Fiori應用，都能通過Selenium來進行UI的自動化測試。

當然，SAP成都研究院也在進行眾多基于微服務架構的云產品開發(fā)，主要使用Java編程，那么自動化測試的實現也更加容易，Spring系列框架里有大量成熟和流行的自動化測試套件可供使用。

從迭代發(fā)布的角度講，C4S產品的發(fā)布周期為一個季度一次，每個季度中有三個周期：前兩個周期主要完成新功能開發(fā)，第三個周期需要團隊成員既完成新功能測試，也需要回歸系統原有功能。與此同時，每個季度中還有5次補丁的發(fā)布，每一次都需要完成原有業(yè)務的回歸測試。夾在產品新特性測試和回歸測試之間的，是一望無際的工作量和對高效率、高質量測試的需求。

我為所在團隊負責的功能制定的自動化的策略是: 接口 + UI自動化覆蓋。也許您會問，作為一個請求的最前端，既然UI的測試都能覆蓋了，那自動化測試為什么還需要接口的覆蓋？工作量是否存在重復？從功能的角度來講，確實有些重復。但從收益的角度來講，對接口的自動化測試進行投入，收益遠超成本。

1. 對于任意一個系統，接口的穩(wěn)定性在整個系統中的重要地位不言而喻。相對于后置的E2E（端到端）測試，接口測試能夠從基礎層減小變更對整個應用及下游業(yè)務調用方的影響范圍。

2. 同時，接口的測試也能為UI自動化實施提供基礎數據。

UI自動化為了完成某個場景的測試，通常會有很多前置業(yè)務數據的依賴。這些UI自動化需要的測試數據如何生成?有同事建議可以提前手工造數據。如果自動化測試的數據都要依靠手工來維護，在我看來，這個自動化不要也罷。通常，在接口測試完成之后會將已測試通過的接口封裝成工具類，供后續(xù)UI自動化的工程化調用，這樣既減少了UI自動化的數據依賴，對接口測試通過率也提出了更高的要求。所以一般的接口工程必須100%通過，才能完成觸發(fā)后續(xù)UI自動化的作用去執(zhí)行功能測試。

3. 為性能測試準備打下堅實的基礎。

通常準備性能測試之前，接口測試的響應時間會成為反饋接口性能的重要依據。我們在制定接口性能的SLA(Service-Level Agreement)時，其基本數據來源就是接口測試。而很多互聯網公司，相對于端到端的響應時間，他們更注重接口的響應時間，因為接口更底層。尤其針對多層接口依賴的系統，每年 618，雙11之前的線上大促壓測，接口全鏈路測試必定是重中之重。

我在C4S推薦使用的接口測試框架為Spring + Maven + Testng，語言為Java， 被測對象為C4S oData服務提供的HTTP API。其中Spring框架主要負責通過注解方式完成對象注入，Maven負責工程結構和Jar包管理，Testng負責具體的測試工作。對于不熟悉Java的朋友來說，借助現有工具諸如Postman也能很好地勝任這項工作。

1. 工程結構及說明

接口主體工程以Maven規(guī)范工程為模板，所有的代碼和相關資源文件均放置在src/test目錄下。工程模塊主要分為4部分：測試代碼、枚舉對象、工具類及相關資源文件。

測試代碼：這是測試代碼的主要存放目錄。 通常根據業(yè)務的不同，我們將每一個接口的測試案例按照業(yè)務測試和參數測試分別編寫。

所謂業(yè)務測試，是指測試案例中涉及業(yè)務規(guī)則的部分。比如，某接口中存在一個channel(渠道)字段。業(yè)務規(guī)則定義：當channel為all時，創(chuàng)建全渠道使用的數據；當channel為特定值時，創(chuàng)建的數據只能適用于特定的場景。則業(yè)務測試的案例有2個：

o Channel = all

o Channel = 特定數據

參數測試：主要測試接口參數字段是否為必填項。比如，某接口中存在一個channel為必填字段且必須為指定枚舉類型字符串，當傳入接口為null或blank或非枚舉值時，框架返回HTTP 400參數錯誤，同時提示錯誤信息。此時參數測試案例有3個：

o Channel = null

o Channel = “”（blank）

o Channel = “XXXX”（XXXX為非枚舉值）

枚舉對象：此部分是將業(yè)務中經常用到的固定參數使用枚舉的方式列出，方便整個工程使用。見下圖中httpEnum文件夾中的類。

工具類：包括基本工具類和業(yè)務工具類部分。業(yè)務工具類是將特定接口進行封裝，方便下游接口調用使用。

資源文件：包括Spring相關配置，properties文件以及參數測試中的數據來源文件等。

2. 案例編寫

此處以實現oData的SocialMediaActivity 接口的自動化測試為例來進行說明。

我們借用顏值大師——李曉剛老師畫的圖來大致了解SociaMediaActivity在C4S微信集成架構中的作用：

由上圖所知，C4S通過暴露SocialMediaActivity接口來方便Agent調用。

在C4S和Social Media集成的相關場景中，用戶可以通過關注微信公眾號來綁定一個特定的BusinessPartner(以下簡稱BP), 從而達到通過用戶在系統中自定義的微信Channel來直接與C4C服務模塊中的工作人員直接交互的目的。而Activity是針對指定的BP所進行的活動，例如創(chuàng)建ticket，點贊，回復等。故而完整的業(yè)務流程如下：

• 獲取系統token

• 獲取已關聯的BP信息

• 創(chuàng)建ticket信息

• 評論/點贊/回復操作

• 數據清理

• BeforeClass： 執(zhí)行獲取token的準備工作。

• BeforeMethod： 創(chuàng)建/獲取已關聯的BP信息。

• Test: 特定業(yè)務的測試案例。本處對Activity的層級和操作內容進行檢查，因此有2個測試方法。

• AfterMethod：清理已創(chuàng)建的Activity。此處需要重點說明是，為避免后臺錯誤數據對應用正常使用的影響，每一次執(zhí)行都需要對增量數據進行清除處理，保持環(huán)境干凈整潔。

• AfterClass： 清理創(chuàng)建的BP信息。

3. CI(Continuous Integration, 持續(xù)集成)

基于Maven工程的集成，本例中使用Jenkins進行示例，與此同時項目工程中需要使用surefire-plugin(一個用來執(zhí)行測試用例的Maven插件)來配置相關的測試案例范圍。

在pom.xml中配置testng.xml文件：

testng.xml文件內容示例：

使用Maven的好處再次體現，只需要簡單配置即可使用：

在Jenkins中加入testng report plugin展示，然后build即可。

雖然我更擅長使用基于Java的Selenium這個UI自動化框架，也明白接口測試完成之后，對UI自動化的巨大幫助，但由于C4S在印度和美國團隊內都使用現有的成型產品SAHI，所以這里我只介紹SAHI在C4S的應用。

SAHI是Tyto Software旗下的一個基于業(yè)務的Web應用自動化測試工具, 通過注入 JavaScript來訪問 Web 頁面中的元素。相對于Selenium等自動化測試工具，SAHI在動態(tài) ID元素查找和隱式頁面等待處理等方面具有一定的優(yōu)勢。感興趣的同事可前往官網進行嘗試。

1. 工程結構及說明

此處以Social 案例為例：

• **DD_CSV: **案例運行的的數據來源

• **Function_Library: **該目錄中存放已封裝的基本共用函數，如登錄、登出、工作中心訪問、表格訪問等。更加細致的封裝則是將頁面元素抽象到Library中的IDS下，便于統一管理, 如下圖:

• SCRIPTS：特定的UI測試案例。

• SUITE：測試案例運行的范圍。

2. 案例編寫

此處以RUI項目中SingleTab功能為例進行說明。

MultiTab和SingleTab功能是指在C4S產品中，當用戶在全屏模式下打開某一個或多個工作視圖時，系統會將多個工作視圖以Tab的形式顯示在工作區(qū)中；但是當用戶修改瀏覽器大小到一定尺寸后，工作區(qū)中將只顯示活動的那個Tab。

MultiTab顯示時，有活動與非活動Tab之分，同時要適配多個Tab的鼠標操作切換和通過功能菜單的切換。如下圖所示：

SingleTab顯示：只顯示當前活動的Tab，在顯示數據和形式上與MultiTab有差別，同時也要適配通過功能菜單的Tab切換。

與此同時，該特性需要測試系統在不同的主題、字體大小下此特性也能正常工作。因此測試案例的流程如下（可參考代碼注釋部分）：

(1) 重置相關特性：瀏覽器大小，主題，字體大小，視圖類型，頁面默認過濾器

(2) 訪問特定的工作視圖并顯示特定數據，驗證全屏模式下活動狀態(tài)的/非活動狀態(tài)的MultiTab的顯示和Tab上數據的正確性

(3) 縮小瀏覽器大?。?/p>

• 驗證Tab上數據正確性

• 修改系統主題，驗證SingleTab的顯示

• 修改字體大小，驗證SingleTab顯示

3. CI集成

基于Jenkins的強大的插件功能，C4S通過將Jenkins與GTP(內部缺陷管理平臺)的集成完成CI調度和運行。

UI自動化的CI集成，使得C4S產品的回歸測試的效率大大提升。以今年8月份發(fā)布的版本為例，手工回歸的測試案例目前已接近7000個。如前文所述，諸多的測試案例在每個迭代中持續(xù)的回歸測試，則是一項耗時又耗力的工程。而且這僅僅只針對回歸測試所執(zhí)行的案例。

從手工回歸測試案例的數量不難看出，快速反饋系統功能狀態(tài)機制在持續(xù)交付鏈中的重要性。而在對接口進行全覆蓋測試之后，對UI自動化覆蓋回歸測試主流程的需求也愈加強烈。

在C4S，我們借助Jenkins 并行測試完成UI自動化，并使用郵件通知測試結果。在節(jié)省人工回歸成本的同時，使得產品管理團隊能夠在短時間內快速、全面了解系統功能的運行情況，并給與團隊成員質量的信心。與此同時，在出現模塊功能失效甚至是系統宕機時，這種快速反饋鏈的建立為開發(fā)人員盡早盡快修復問題爭取了時間，減少了后續(xù)修復的時間成本。

就目前的測試覆蓋需求而言，由內到外的接口覆蓋及端到端的UI覆蓋，在滿足底層穩(wěn)定可靠的同時，也保證前端功能的可用性。對于SAP質量工程師而言，工作內容遠非測試工作這一項內容，從團隊成員質量意識的提升到單元測試覆蓋及檢查；從測試工作到團隊質量反饋，都是SAP質量工程師在每日工作中需要去花心思琢磨的。而從團隊利益著手，考慮每一項質量活動的價值和意義，對質量工程師來說是一項全局觀的考驗，也是一場質量與效率的平衡。

以上就是如何分析SAP Cloud for Sales 自動化，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注創(chuàng)新互聯-成都網站建設公司行業(yè)資訊頻道。

文章名稱：如何分析SAPCloudforSales自動化-創(chuàng)新互聯
文章鏈接：http://bm7419.com/article32/dcopsc.html

成都網站建設公司_創(chuàng)新互聯，為您提供定制開發(fā)、網站制作、定制網站、網站設計、ChatGPT、App設計

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯