項(xiàng)目背景

奧博杰天中國測試團(tuán)隊(duì)負(fù)責(zé)一套云端人力資源管理產(chǎn)品的自動化測試，產(chǎn)品簡稱WHMC (Workforce Management and HCM Could Solution )。 該產(chǎn)品幫助大型企業(yè)管理員工考勤、排班優(yōu)化，以及缺勤等復(fù)雜業(yè)務(wù)邏輯。它的客戶包含制造商、零售商、醫(yī)療機(jī)構(gòu)、服務(wù)機(jī)構(gòu)、交通運(yùn)輸和物流等全球數(shù)千家各種規(guī)模機(jī)構(gòu)。由于業(yè)務(wù)復(fù)雜，WHMC被拆分成15個組件，每個組件配備10-20人的研發(fā)團(tuán)隊(duì)。 研發(fā)團(tuán)隊(duì)以項(xiàng)目為單位分布在美國，加拿大，印度和中國多個不同的城市。WHMC作為一套SaaS云端解決方案，支持客戶按月購買服務(wù)， 同時也支持整套解決方案駐場部署在客戶的機(jī)房內(nèi)。該產(chǎn)品在研發(fā)上有以下幾個特點(diǎn)：

作為企業(yè)級SaaS，產(chǎn)品的功能組件多、集成和測試難度大。

國際化特征明顯，研發(fā)團(tuán)隊(duì)分布全球，溝通交流不便。

產(chǎn)品迭代更新快，每個研發(fā)團(tuán)隊(duì)都有自己的進(jìn)度，測試團(tuán)隊(duì)無法控制研發(fā)團(tuán)隊(duì)的工作安排。

面臨的挑戰(zhàn)

保證自動化測試用例集可持續(xù)運(yùn)行是企業(yè)級SaaS產(chǎn)品進(jìn)行持續(xù)集成和自動化部署(CI/CD)、實(shí)現(xiàn)敏捷開發(fā)的核心。這一挑戰(zhàn)由奧博杰天的測試團(tuán)隊(duì)來擔(dān)當(dāng)。我們的測試團(tuán)隊(duì)雖然之前做過很多國外大型項(xiàng)目的自動化測試，但是對測試功能點(diǎn)多、項(xiàng)目干系人分散、交付質(zhì)量要求又高的企業(yè)級SaaS還是第一次碰到。用之前的項(xiàng)目經(jīng)驗(yàn)去實(shí)施項(xiàng)目碰到了不少挑戰(zhàn)，主要集中在以下三方面：

測試技術(shù)的挑戰(zhàn)

自動化測試用例集分為UI 測試, API 測試, 和混合場景測試。我們使用TestNG (版本6.8.8)、Selenium (版本2.53.0) 的WebDriver、REST-Assured(版本2.9.0)作為測試框架的核心工具。開發(fā)完成的自動化測試用例上傳到Git倉庫進(jìn)行版本管理，由Jenkins進(jìn)行CI/CD。測試用例生命周期及測試結(jié)果通過惠普的ALM (Application Lifecycle Management) 進(jìn)行管理。 整體測試框架如下圖：

其中開發(fā)和執(zhí)行UI測試用例有兩個技術(shù)難點(diǎn)：

一，Selenium判斷異步加載的網(wǎng)頁元素是否完成和如何定位網(wǎng)頁元素。

這是Selenium 的WebDriver進(jìn)行UI測試的經(jīng)典技術(shù)問題。WHMC的很多網(wǎng)頁數(shù)據(jù)是通過Angular JS異步加載的，測試用例有時很難判斷待檢查網(wǎng)頁元素是否裝載完畢，造成超時或執(zhí)行失敗。例如，在計算工資的頁面，我們需要等員工的工時加載完然后點(diǎn)擊“計算”按鈕來計算應(yīng)付工資。由于工時的表格會動態(tài)刷新，則可能計算錯誤。

還有就是定位網(wǎng)頁元素，我們使用XPath定位，最常使用的是網(wǎng)頁元素的屬性值定位元素實(shí)例，例如div標(biāo)簽的ID、 img標(biāo)簽的href，input標(biāo)簽的type等屬性值。但是這些屬性在新版本中可能變化，造成查詢條件不穩(wěn)定。

二，SaaS模式下的多租戶測試。

SaaS產(chǎn)品不同租戶能使用的功能、 API限制、和數(shù)據(jù)隔離等方式等都不完全相同，多租戶測試場景有別于傳統(tǒng)自動化測試項(xiàng)目。

產(chǎn)品更新快帶來的挑戰(zhàn)

WHMC的 15個組件都有自己的開發(fā)計劃，開發(fā)團(tuán)隊(duì)沒有及時通知到測試團(tuán)隊(duì)，測試團(tuán)隊(duì)也很難去控制這些變化。組件發(fā)生變化后，其API文檔更新不及時或非常有限，很多變化的接口只有API的定義沒有參數(shù)說明，測試團(tuán)隊(duì)在理解和修改API測試用例時遇到很大麻煩。

另外，因?yàn)闇y試框架是和測試用例開發(fā)同步進(jìn)行的，測試框架發(fā)生的變化也對測試造成影響。測試框架新增了功能，意味著需要對已開發(fā)的測試用例進(jìn)行更新。 頻繁更新的測試框架，對發(fā)現(xiàn)測試用例失敗的原因也帶來新的不確定因素。

多團(tuán)隊(duì)跨國溝通的挑戰(zhàn)

由于研發(fā)團(tuán)隊(duì)分散在不同的國家，項(xiàng)目的測試流程和溝通流程都存在不足。如圖：

測試用例的需求溝通完全通過ALM(Application Lifecycle Management)獲取。一些測試用例需求都寫得比較模糊，測試團(tuán)隊(duì)需要花費(fèi)很長時間和各組件負(fù)責(zé)人在ALM系統(tǒng)中來回澄清細(xì)節(jié)。

由于研發(fā)團(tuán)隊(duì)都在國外，我們很難得到關(guān)于產(chǎn)品的技術(shù)支持。在測試用例開發(fā)過程中，一些測試用例執(zhí)行失敗的原因需要技術(shù)團(tuán)隊(duì)確認(rèn)，只能通過郵件，對方回應(yīng)不及時。

開發(fā)完測試用例，需要需求方review并接收。需求方確認(rèn)不及時造成大量已完成的測試用例停留在待提交狀態(tài)不能提交到Git進(jìn)行代碼管理，大量積壓的測試用例產(chǎn)生版本沖突。

項(xiàng)目從2017年1月開始啟動，經(jīng)過3個月的實(shí)施，上訴問題帶來的結(jié)果是每次回歸的通過率徘徊在40-50%;測試用例的產(chǎn)出效率很低，近40人的團(tuán)隊(duì)每天只能產(chǎn)出平均1個合格的自動化測試用例;因?yàn)榈貌坏窖邪l(fā)團(tuán)隊(duì)的支持和理解，測試團(tuán)隊(duì)士氣低落，內(nèi)部彌漫著失敗的氣息。

應(yīng)對策略

測試團(tuán)隊(duì)意識到按照現(xiàn)有的流程再繼續(xù)下去是行不通的，于是在4月初果斷停止了所有進(jìn)行中的任務(wù)，商量應(yīng)對方法。 在總結(jié)了前述的各種的挑戰(zhàn)后， 提出了如下應(yīng)對策略：

測試框架對常見的測試難點(diǎn)進(jìn)行封裝

對于異步數(shù)據(jù)加載問題，我們將問題分為不同的場景，提供一個示例來描述問題的細(xì)節(jié)以及我們?nèi)绾翁幚硭漠?dāng)前方式。 同時負(fù)責(zé)測試框架的小組系統(tǒng)地了解這些場景，并封裝成標(biāo)準(zhǔn)方法，并為每個場景設(shè)置最大延遲時間，如果到時不返回期望值，則拋出異常。

對于Web元素定位器問題，我們列出典型的情況，并與測試框架小組和國外各組件研發(fā)團(tuán)隊(duì)合作，將穩(wěn)定的查詢條件封裝成一個明確的查找方法。測試人員調(diào)用統(tǒng)一的方法進(jìn)行測試。

加強(qiáng)配置管理

包括：正確使用git工具和提交流程;使用JIRA配合AML對需求進(jìn)行管理;測試團(tuán)隊(duì)內(nèi)部代碼審查等。加強(qiáng)配置管理對于解決SaaS產(chǎn)品更新快這一挑戰(zhàn)非常有效。關(guān)于配置管理業(yè)界討論得比較多我就不詳細(xì)展開，只重點(diǎn)強(qiáng)調(diào)一下對于測試數(shù)據(jù)集的配置管理。

我們的測試數(shù)據(jù)集來源有兩部分:

運(yùn)行整套測試用例集之前通過工具進(jìn)行初始化填充。

測試用例內(nèi)自行管理的測試數(shù)據(jù)。

因?yàn)橹瓣P(guān)于如何維護(hù)測試數(shù)據(jù)集的定義是模糊的，在運(yùn)行UI測試和API測試用例時都會對這兩部分?jǐn)?shù)據(jù)集發(fā)生CRUD操作，造成了我們對于上述測試數(shù)據(jù)集的完整性無法保證。

針對這個情況， 我們加強(qiáng)了對數(shù)據(jù)集的配置管理，要求測試團(tuán)隊(duì)?wèi)?yīng)嚴(yán)格遵循以下規(guī)則：

將初始化測試數(shù)據(jù)視為只讀。

如果必須更改初始化測試數(shù)據(jù)，我們應(yīng)該在測試用例退出之前改回原來的值。

將測試用例自己管理的數(shù)據(jù)視為例外情況，單獨(dú)管理這些測試用例。

優(yōu)化測試開發(fā)流程和團(tuán)隊(duì)溝通流程

在新的溝通流程中(如圖)，我們主要做了以下改進(jìn)：

和每個研發(fā)團(tuán)隊(duì)指定點(diǎn)對點(diǎn)的聯(lián)系人，建立更緊密的聯(lián)系，獲得必要的技術(shù)支持。

在Git中增加Accept分支，測試用例開發(fā)完成后在測試團(tuán)隊(duì)內(nèi)部進(jìn)行review，通過后提交到Git的Accept分支，研發(fā)團(tuán)隊(duì)每周定期review，接收開發(fā)好的測試用例并Merge到Main分支用于生產(chǎn)。

實(shí)施過程

從4月開始，我們按計劃進(jìn)行了為期4周改變，具體的做法有：

一，加強(qiáng)例框架研解決疑難技術(shù)點(diǎn)。例如在網(wǎng)頁上查找employee元素，如果employee元素不在屏幕內(nèi)，這時定位就會報錯。 開發(fā)團(tuán)隊(duì)使用WebDriver JavaScriptExecutor的executeScript方法進(jìn)行滾屏操作，很好的解決了這一問題。現(xiàn)在只需要調(diào)用getEmployeeNameDiv()方法，傳入employeeName，就可返回要查找的employee元素：

二，采用數(shù)據(jù)驅(qū)動測試的方法解決多租戶測試需求。使用CSV來管理不同的測試數(shù)據(jù)集，只需裝載一次測試數(shù)據(jù)文件，就可使用不同數(shù)據(jù)集多次執(zhí)行測試用例，簡化了用例開發(fā)量。例如切換租戶只需要執(zhí)行如下代碼：

三，增派架構(gòu)師參與到測試框架設(shè)計工作中，處理諸如異步數(shù)據(jù)加載等技術(shù)挑戰(zhàn)， 同時指導(dǎo)測試數(shù)據(jù)管理，驗(yàn)證方法抽象和經(jīng)驗(yàn)總結(jié)。

四，重新設(shè)計測試開發(fā)流程，增加架構(gòu)師或業(yè)務(wù)分析師對測試用例的業(yè)務(wù)流程進(jìn)行Review， 測試用例在本地的CI/CD環(huán)境進(jìn)行daily run。并將新的流程對測試團(tuán)隊(duì)進(jìn)行培訓(xùn)。

五，對測試人員進(jìn)行技能培訓(xùn)，例如：Git使用，測試數(shù)據(jù)管理，與異步數(shù)據(jù)加載相關(guān)的Web元素的最佳做法，和代碼審查清單等。

六，派專人出差到國外和各個組件團(tuán)隊(duì)面對面溝通，就產(chǎn)品，API以及疑難的測試需求進(jìn)行了深入的溝通。指定一對一的聯(lián)絡(luò)人，加快溝通的響應(yīng)速度。

七，針對我們之前開發(fā)的623個測試用例進(jìn)行了重構(gòu)。

經(jīng)過上述改變，測試用例集回歸通過率從4月底的50%提升到了80%。未通過的用例進(jìn)行人工維護(hù)更新。大部分是系統(tǒng)更新引起的變化，一次性調(diào)整測試框架就能解決大部分。新的測試策略大大提高了CI/CD的可重用性，做到了SaaS產(chǎn)品自動化測試用例的高可用性。

總結(jié)

對于企業(yè)級SaaS來說，在自動化測試領(lǐng)域會有如下新挑戰(zhàn)：

除了頁面自動化測試的技術(shù)挑戰(zhàn)，還要考慮SaaS產(chǎn)品多租戶對測試用例設(shè)計帶來的挑戰(zhàn)。

SaaS產(chǎn)品迭代周期快， 對自動化用例的開發(fā)效率，用例的通過率都帶來很大挑戰(zhàn)。

企業(yè)級SaaS產(chǎn)品研發(fā)團(tuán)隊(duì)經(jīng)?？绲赜虻奶攸c(diǎn)，給處在不同地域的技術(shù)團(tuán)隊(duì)帶來更大的溝通挑戰(zhàn)。

奧博杰天中國測試團(tuán)隊(duì)在實(shí)施WHMC的自動化測試項(xiàng)目中得到的企業(yè)級SaaS產(chǎn)品最佳實(shí)踐是：

基于成熟第三方測試軟件開發(fā)適合產(chǎn)品需要的自動化測試框架，封裝測試中遇到的疑難技術(shù)點(diǎn)，例如網(wǎng)頁元素定位和判斷異步加載成功。

采用數(shù)據(jù)驅(qū)動測試來應(yīng)對多租戶的挑戰(zhàn)。

配備經(jīng)驗(yàn)豐富的架構(gòu)師參與測試框架設(shè)計，關(guān)鍵問題解決和經(jīng)驗(yàn)總結(jié)。

加強(qiáng)配置管理，有效應(yīng)對產(chǎn)品更新快的挑戰(zhàn)。特別是測試數(shù)據(jù)集的管理，對于初始測試數(shù)據(jù)集保持只讀;如果必須更改初始化數(shù)據(jù)，需要在用例退出時恢復(fù)原值;特殊的測試數(shù)據(jù)單獨(dú)管理。

加強(qiáng)測試團(tuán)隊(duì)和技術(shù)團(tuán)隊(duì)的溝通，建立必要的跨團(tuán)隊(duì)溝通流程，得到研發(fā)團(tuán)隊(duì)的技術(shù)支持。

多地辦公的團(tuán)隊(duì)有必要指定一對一聯(lián)系人，肉身出差對于跨國團(tuán)隊(duì)溝通是最有效的辦法。