本篇文章給大家分享的是有關(guān)如何分析SAP Cloud for Sales 自動(dòng)化,小編覺(jué)得挺實(shí)用的,因此分享給大家學(xué)習(xí),希望大家閱讀完這篇文章后可以有所收獲,話不多說(shuō),跟著小編一起來(lái)看看吧。
創(chuàng)新互聯(lián)長(zhǎng)期為上1000家客戶提供的網(wǎng)站建設(shè)服務(wù),團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年,關(guān)注不同地域、不同群體,并針對(duì)不同對(duì)象提供差異化的產(chǎn)品和服務(wù);打造開(kāi)放共贏平臺(tái),與合作伙伴共同營(yíng)造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為龍門(mén)企業(yè)提供專業(yè)的網(wǎng)站制作、做網(wǎng)站,龍門(mén)網(wǎng)站改版等技術(shù)服務(wù)。擁有十多年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開(kāi)發(fā)。今天我想基于目前C4S產(chǎn)品的現(xiàn)狀和自身的技術(shù)背景,簡(jiǎn)單聊聊自動(dòng)化這個(gè)動(dòng)人心魄、讓人又愛(ài)又恨的話題。
相信任何一個(gè)軟件開(kāi)發(fā)團(tuán)隊(duì)的每位成員,聽(tīng)到“自動(dòng)化”一詞,都會(huì)抱有熱烈的期待。對(duì)于老板來(lái)說(shuō),這個(gè)詞意味著成本的下降及更高的ROI(Return On Investment,投資回報(bào)率);從開(kāi)發(fā)工程師的角度,自動(dòng)化有助于更早地檢測(cè)到代碼變更對(duì)原有功能的影響;測(cè)試工程師當(dāng)然是全力支持自動(dòng)化的,因?yàn)槭⌒暮褪×?;產(chǎn)品經(jīng)理自然也不會(huì)拒絕自動(dòng)化,因?yàn)樗軌驇?lái)更高效的交付和更快速的迭代。
然而,我們身邊也不乏自動(dòng)化實(shí)施失敗的團(tuán)隊(duì)。2013年在我前一家工作的公司里,我曾參與某核心系統(tǒng)項(xiàng)目的開(kāi)發(fā)工作,這個(gè)業(yè)務(wù)系統(tǒng)從需求到完整上線共耗時(shí)一年半,核心功能的開(kāi)發(fā)更是耗時(shí)大半年之久。面對(duì)如此龐大的業(yè)務(wù)測(cè)試成本和強(qiáng)需求,PMO(Project Manage Office)在項(xiàng)目開(kāi)發(fā)之初就啟動(dòng)了自動(dòng)化測(cè)試需求,然而在業(yè)務(wù)功能不穩(wěn)定,產(chǎn)品需求、開(kāi)發(fā)與測(cè)試基本屬于趕工狀態(tài)的情況下,與人工回歸相比,自動(dòng)化所帶來(lái)的收益基本微乎其微。所以選擇適當(dāng)?shù)淖詣?dòng)化時(shí)機(jī)和策略,是自動(dòng)化成功與否的重要因素之一。
眾所周知,SAP眾多產(chǎn)品都在使用自研的ABAP進(jìn)行開(kāi)發(fā)。當(dāng)我加入SAP后,我了解到這些運(yùn)行在ABAP Netweaver之上的產(chǎn)品,均有完備的自動(dòng)化測(cè)試。對(duì)于ABAP后臺(tái)功能代碼,主要是開(kāi)發(fā)人員為核心功能編寫(xiě)完備的,覆蓋率高的單元測(cè)試,然后用事務(wù)碼SUT調(diào)度成后臺(tái)作業(yè)定期執(zhí)行,如果自動(dòng)化測(cè)試執(zhí)行時(shí)發(fā)現(xiàn)故障,會(huì)自動(dòng)發(fā)郵件通知相關(guān)人員。
前臺(tái)UI代碼,無(wú)論是原生的Fiori應(yīng)用還是CRM Web Client UI這種加了一層皮膚的類Fiori應(yīng)用,都能通過(guò)Selenium來(lái)進(jìn)行UI的自動(dòng)化測(cè)試。
當(dāng)然,SAP成都研究院也在進(jìn)行眾多基于微服務(wù)架構(gòu)的云產(chǎn)品開(kāi)發(fā),主要使用Java編程,那么自動(dòng)化測(cè)試的實(shí)現(xiàn)也更加容易,Spring系列框架里有大量成熟和流行的自動(dòng)化測(cè)試套件可供使用。
從迭代發(fā)布的角度講,C4S產(chǎn)品的發(fā)布周期為一個(gè)季度一次,每個(gè)季度中有三個(gè)周期:前兩個(gè)周期主要完成新功能開(kāi)發(fā),第三個(gè)周期需要團(tuán)隊(duì)成員既完成新功能測(cè)試,也需要回歸系統(tǒng)原有功能。與此同時(shí),每個(gè)季度中還有5次補(bǔ)丁的發(fā)布,每一次都需要完成原有業(yè)務(wù)的回歸測(cè)試。夾在產(chǎn)品新特性測(cè)試和回歸測(cè)試之間的,是一望無(wú)際的工作量和對(duì)高效率、高質(zhì)量測(cè)試的需求。
我為所在團(tuán)隊(duì)負(fù)責(zé)的功能制定的自動(dòng)化的策略是: 接口 + UI自動(dòng)化覆蓋。也許您會(huì)問(wèn),作為一個(gè)請(qǐng)求的最前端,既然UI的測(cè)試都能覆蓋了,那自動(dòng)化測(cè)試為什么還需要接口的覆蓋?工作量是否存在重復(fù)?從功能的角度來(lái)講,確實(shí)有些重復(fù)。但從收益的角度來(lái)講,對(duì)接口的自動(dòng)化測(cè)試進(jìn)行投入,收益遠(yuǎn)超成本。
1. 對(duì)于任意一個(gè)系統(tǒng),接口的穩(wěn)定性在整個(gè)系統(tǒng)中的重要地位不言而喻。相對(duì)于后置的E2E(端到端)測(cè)試,接口測(cè)試能夠從基礎(chǔ)層減小變更對(duì)整個(gè)應(yīng)用及下游業(yè)務(wù)調(diào)用方的影響范圍。
2. 同時(shí),接口的測(cè)試也能為UI自動(dòng)化實(shí)施提供基礎(chǔ)數(shù)據(jù)。
UI自動(dòng)化為了完成某個(gè)場(chǎng)景的測(cè)試,通常會(huì)有很多前置業(yè)務(wù)數(shù)據(jù)的依賴。這些UI自動(dòng)化需要的測(cè)試數(shù)據(jù)如何生成?有同事建議可以提前手工造數(shù)據(jù)。如果自動(dòng)化測(cè)試的數(shù)據(jù)都要依靠手工來(lái)維護(hù),在我看來(lái),這個(gè)自動(dòng)化不要也罷。通常,在接口測(cè)試完成之后會(huì)將已測(cè)試通過(guò)的接口封裝成工具類,供后續(xù)UI自動(dòng)化的工程化調(diào)用,這樣既減少了UI自動(dòng)化的數(shù)據(jù)依賴,對(duì)接口測(cè)試通過(guò)率也提出了更高的要求。所以一般的接口工程必須100%通過(guò),才能完成觸發(fā)后續(xù)UI自動(dòng)化的作用去執(zhí)行功能測(cè)試。
3. 為性能測(cè)試準(zhǔn)備打下堅(jiān)實(shí)的基礎(chǔ)。
通常準(zhǔn)備性能測(cè)試之前,接口測(cè)試的響應(yīng)時(shí)間會(huì)成為反饋接口性能的重要依據(jù)。我們?cè)谥贫ń涌谛阅艿腟LA(Service-Level Agreement)時(shí),其基本數(shù)據(jù)來(lái)源就是接口測(cè)試。而很多互聯(lián)網(wǎng)公司,相對(duì)于端到端的響應(yīng)時(shí)間,他們更注重接口的響應(yīng)時(shí)間,因?yàn)榻涌诟讓?。尤其針?duì)多層接口依賴的系統(tǒng),每年 618,雙11之前的線上大促壓測(cè),接口全鏈路測(cè)試必定是重中之重。
我在C4S推薦使用的接口測(cè)試框架為Spring + Maven + Testng,語(yǔ)言為Java, 被測(cè)對(duì)象為C4S oData服務(wù)提供的HTTP API。其中Spring框架主要負(fù)責(zé)通過(guò)注解方式完成對(duì)象注入,Maven負(fù)責(zé)工程結(jié)構(gòu)和Jar包管理,Testng負(fù)責(zé)具體的測(cè)試工作。對(duì)于不熟悉Java的朋友來(lái)說(shuō),借助現(xiàn)有工具諸如Postman也能很好地勝任這項(xiàng)工作。
1. 工程結(jié)構(gòu)及說(shuō)明
接口主體工程以Maven規(guī)范工程為模板,所有的代碼和相關(guān)資源文件均放置在src/test目錄下。工程模塊主要分為4部分:測(cè)試代碼、枚舉對(duì)象、工具類及相關(guān)資源文件。
測(cè)試代碼:這是測(cè)試代碼的主要存放目錄。 通常根據(jù)業(yè)務(wù)的不同,我們將每一個(gè)接口的測(cè)試案例按照業(yè)務(wù)測(cè)試和參數(shù)測(cè)試分別編寫(xiě)。
所謂業(yè)務(wù)測(cè)試,是指測(cè)試案例中涉及業(yè)務(wù)規(guī)則的部分。比如,某接口中存在一個(gè)channel(渠道)字段。業(yè)務(wù)規(guī)則定義:當(dāng)channel為all時(shí),創(chuàng)建全渠道使用的數(shù)據(jù);當(dāng)channel為特定值時(shí),創(chuàng)建的數(shù)據(jù)只能適用于特定的場(chǎng)景。則業(yè)務(wù)測(cè)試的案例有2個(gè):
o Channel = all
o Channel = 特定數(shù)據(jù)
參數(shù)測(cè)試:主要測(cè)試接口參數(shù)字段是否為必填項(xiàng)。比如,某接口中存在一個(gè)channel為必填字段且必須為指定枚舉類型字符串,當(dāng)傳入接口為null或blank或非枚舉值時(shí),框架返回HTTP 400參數(shù)錯(cuò)誤,同時(shí)提示錯(cuò)誤信息。此時(shí)參數(shù)測(cè)試案例有3個(gè):
o Channel = null
o Channel = “”(blank)
o Channel = “XXXX”(XXXX為非枚舉值)
枚舉對(duì)象:此部分是將業(yè)務(wù)中經(jīng)常用到的固定參數(shù)使用枚舉的方式列出,方便整個(gè)工程使用。見(jiàn)下圖中httpEnum文件夾中的類。
工具類:包括基本工具類和業(yè)務(wù)工具類部分。業(yè)務(wù)工具類是將特定接口進(jìn)行封裝,方便下游接口調(diào)用使用。
資源文件:包括Spring相關(guān)配置,properties文件以及參數(shù)測(cè)試中的數(shù)據(jù)來(lái)源文件等。
2. 案例編寫(xiě)
此處以實(shí)現(xiàn)oData的SocialMediaActivity 接口的自動(dòng)化測(cè)試為例來(lái)進(jìn)行說(shuō)明。
我們借用顏值大師——李曉剛老師畫(huà)的圖來(lái)大致了解SociaMediaActivity在C4S微信集成架構(gòu)中的作用:
由上圖所知,C4S通過(guò)暴露SocialMediaActivity接口來(lái)方便Agent調(diào)用。
在C4S和Social Media集成的相關(guān)場(chǎng)景中,用戶可以通過(guò)關(guān)注微信公眾號(hào)來(lái)綁定一個(gè)特定的BusinessPartner(以下簡(jiǎn)稱BP), 從而達(dá)到通過(guò)用戶在系統(tǒng)中自定義的微信Channel來(lái)直接與C4C服務(wù)模塊中的工作人員直接交互的目的。而Activity是針對(duì)指定的BP所進(jìn)行的活動(dòng),例如創(chuàng)建ticket,點(diǎn)贊,回復(fù)等。故而完整的業(yè)務(wù)流程如下:
獲取系統(tǒng)token
獲取已關(guān)聯(lián)的BP信息
創(chuàng)建ticket信息
評(píng)論/點(diǎn)贊/回復(fù)操作
數(shù)據(jù)清理
BeforeClass: 執(zhí)行獲取token的準(zhǔn)備工作。
BeforeMethod: 創(chuàng)建/獲取已關(guān)聯(lián)的BP信息。
Test: 特定業(yè)務(wù)的測(cè)試案例。本處對(duì)Activity的層級(jí)和操作內(nèi)容進(jìn)行檢查,因此有2個(gè)測(cè)試方法。
AfterMethod:清理已創(chuàng)建的Activity。此處需要重點(diǎn)說(shuō)明是,為避免后臺(tái)錯(cuò)誤數(shù)據(jù)對(duì)應(yīng)用正常使用的影響,每一次執(zhí)行都需要對(duì)增量數(shù)據(jù)進(jìn)行清除處理,保持環(huán)境干凈整潔。
AfterClass: 清理創(chuàng)建的BP信息。
3. CI(Continuous Integration, 持續(xù)集成)
基于Maven工程的集成,本例中使用Jenkins進(jìn)行示例,與此同時(shí)項(xiàng)目工程中需要使用surefire-plugin(一個(gè)用來(lái)執(zhí)行測(cè)試用例的Maven插件)來(lái)配置相關(guān)的測(cè)試案例范圍。
在pom.xml中配置testng.xml文件:
testng.xml文件內(nèi)容示例:
使用Maven的好處再次體現(xiàn),只需要簡(jiǎn)單配置即可使用:
在Jenkins中加入testng report plugin展示,然后build即可。
雖然我更擅長(zhǎng)使用基于Java的Selenium這個(gè)UI自動(dòng)化框架,也明白接口測(cè)試完成之后,對(duì)UI自動(dòng)化的巨大幫助,但由于C4S在印度和美國(guó)團(tuán)隊(duì)內(nèi)都使用現(xiàn)有的成型產(chǎn)品SAHI,所以這里我只介紹SAHI在C4S的應(yīng)用。
SAHI是Tyto Software旗下的一個(gè)基于業(yè)務(wù)的Web應(yīng)用自動(dòng)化測(cè)試工具, 通過(guò)注入 JavaScript來(lái)訪問(wèn) Web 頁(yè)面中的元素。相對(duì)于Selenium等自動(dòng)化測(cè)試工具,SAHI在動(dòng)態(tài) ID元素查找和隱式頁(yè)面等待處理等方面具有一定的優(yōu)勢(shì)。感興趣的同事可前往官網(wǎng)進(jìn)行嘗試。
1. 工程結(jié)構(gòu)及說(shuō)明
此處以Social 案例為例:
**DD_CSV: **案例運(yùn)行的的數(shù)據(jù)來(lái)源
**Function_Library: **該目錄中存放已封裝的基本共用函數(shù),如登錄、登出、工作中心訪問(wèn)、表格訪問(wèn)等。更加細(xì)致的封裝則是將頁(yè)面元素抽象到Library中的IDS下,便于統(tǒng)一管理, 如下圖:
SCRIPTS:特定的UI測(cè)試案例。
SUITE:測(cè)試案例運(yùn)行的范圍。
2. 案例編寫(xiě)
此處以RUI項(xiàng)目中SingleTab功能為例進(jìn)行說(shuō)明。
MultiTab和SingleTab功能是指在C4S產(chǎn)品中,當(dāng)用戶在全屏模式下打開(kāi)某一個(gè)或多個(gè)工作視圖時(shí),系統(tǒng)會(huì)將多個(gè)工作視圖以Tab的形式顯示在工作區(qū)中;但是當(dāng)用戶修改瀏覽器大小到一定尺寸后,工作區(qū)中將只顯示活動(dòng)的那個(gè)Tab。
MultiTab顯示時(shí),有活動(dòng)與非活動(dòng)Tab之分,同時(shí)要適配多個(gè)Tab的鼠標(biāo)操作切換和通過(guò)功能菜單的切換。如下圖所示:
SingleTab顯示:只顯示當(dāng)前活動(dòng)的Tab,在顯示數(shù)據(jù)和形式上與MultiTab有差別,同時(shí)也要適配通過(guò)功能菜單的Tab切換。
與此同時(shí),該特性需要測(cè)試系統(tǒng)在不同的主題、字體大小下此特性也能正常工作。因此測(cè)試案例的流程如下(可參考代碼注釋部分):
(1) 重置相關(guān)特性:瀏覽器大小,主題,字體大小,視圖類型,頁(yè)面默認(rèn)過(guò)濾器
(2) 訪問(wèn)特定的工作視圖并顯示特定數(shù)據(jù),驗(yàn)證全屏模式下活動(dòng)狀態(tài)的/非活動(dòng)狀態(tài)的MultiTab的顯示和Tab上數(shù)據(jù)的正確性
(3) 縮小瀏覽器大小:
驗(yàn)證Tab上數(shù)據(jù)正確性
修改系統(tǒng)主題,驗(yàn)證SingleTab的顯示
修改字體大小,驗(yàn)證SingleTab顯示
3. CI集成
基于Jenkins的強(qiáng)大的插件功能,C4S通過(guò)將Jenkins與GTP(內(nèi)部缺陷管理平臺(tái))的集成完成CI調(diào)度和運(yùn)行。
UI自動(dòng)化的CI集成,使得C4S產(chǎn)品的回歸測(cè)試的效率大大提升。以今年8月份發(fā)布的版本為例,手工回歸的測(cè)試案例目前已接近7000個(gè)。如前文所述,諸多的測(cè)試案例在每個(gè)迭代中持續(xù)的回歸測(cè)試,則是一項(xiàng)耗時(shí)又耗力的工程。而且這僅僅只針對(duì)回歸測(cè)試所執(zhí)行的案例。
從手工回歸測(cè)試案例的數(shù)量不難看出,快速反饋系統(tǒng)功能狀態(tài)機(jī)制在持續(xù)交付鏈中的重要性。而在對(duì)接口進(jìn)行全覆蓋測(cè)試之后,對(duì)UI自動(dòng)化覆蓋回歸測(cè)試主流程的需求也愈加強(qiáng)烈。
在C4S,我們借助Jenkins 并行測(cè)試完成UI自動(dòng)化,并使用郵件通知測(cè)試結(jié)果。在節(jié)省人工回歸成本的同時(shí),使得產(chǎn)品管理團(tuán)隊(duì)能夠在短時(shí)間內(nèi)快速、全面了解系統(tǒng)功能的運(yùn)行情況,并給與團(tuán)隊(duì)成員質(zhì)量的信心。與此同時(shí),在出現(xiàn)模塊功能失效甚至是系統(tǒng)宕機(jī)時(shí),這種快速反饋鏈的建立為開(kāi)發(fā)人員盡早盡快修復(fù)問(wèn)題爭(zhēng)取了時(shí)間,減少了后續(xù)修復(fù)的時(shí)間成本。
就目前的測(cè)試覆蓋需求而言,由內(nèi)到外的接口覆蓋及端到端的UI覆蓋,在滿足底層穩(wěn)定可靠的同時(shí),也保證前端功能的可用性。對(duì)于SAP質(zhì)量工程師而言,工作內(nèi)容遠(yuǎn)非測(cè)試工作這一項(xiàng)內(nèi)容,從團(tuán)隊(duì)成員質(zhì)量意識(shí)的提升到單元測(cè)試覆蓋及檢查;從測(cè)試工作到團(tuán)隊(duì)質(zhì)量反饋,都是SAP質(zhì)量工程師在每日工作中需要去花心思琢磨的。而從團(tuán)隊(duì)利益著手,考慮每一項(xiàng)質(zhì)量活動(dòng)的價(jià)值和意義,對(duì)質(zhì)量工程師來(lái)說(shuō)是一項(xiàng)全局觀的考驗(yàn),也是一場(chǎng)質(zhì)量與效率的平衡。
以上就是如何分析SAP Cloud for Sales 自動(dòng)化,小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘9ぷ鲿?huì)見(jiàn)到或用到的。希望你能通過(guò)這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道。
文章名稱:如何分析SAPCloudforSales自動(dòng)化-創(chuàng)新互聯(lián)
文章鏈接:http://www.rwnh.cn/article32/dcopsc.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供定制開(kāi)發(fā)、網(wǎng)站制作、定制網(wǎng)站、網(wǎng)站設(shè)計(jì)、ChatGPT、App設(shè)計(jì)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容