項目背景

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

作為企業級SaaS，產品的功能組件多、集成和測試難度大。

國際化特征明顯，研發團隊分布全球，溝通交流不便。

產品迭代更新快，每個研發團隊都有自己的進度，測試團隊無法控制研發團隊的工作安排。

面臨的挑戰

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

測試技術的挑戰

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

其中開發和執行UI測試用例有兩個技術難點：

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

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

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

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

SaaS產品不同租戶能使用的功能、 API限制、和數據隔離等方式等都不完全相同，多租戶測試場景有別于傳統自動化測試項目。

產品更新快帶來的挑戰

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

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

多團隊跨國溝通的挑戰

由于研發團隊分散在不同的國家，項目的測試流程和溝通流程都存在不足。如圖：

測試用例的需求溝通完全通過ALM(Application Lifecycle Management)獲取。一些測試用例需求都寫得比較模糊，測試團隊需要花費很長時間和各組件負責人在ALM系統中來回澄清細節。

由于研發團隊都在國外，我們很難得到關于產品的技術支持。在測試用例開發過程中，一些測試用例執行失敗的原因需要技術團隊確認，只能通過郵件，對方回應不及時。

開發完測試用例，需要需求方review并接收。需求方確認不及時造成大量已完成的測試用例停留在待提交狀態不能提交到Git進行代碼管理，大量積壓的測試用例產生版本沖突。

項目從2017年1月開始啟動，經過3個月的實施，上訴問題帶來的結果是每次回歸的通過率徘徊在40-50%;測試用例的產出效率很低，近40人的團隊每天只能產出平均1個合格的自動化測試用例;因為得不到研發團隊的支持和理解，測試團隊士氣低落，內部彌漫著失敗的氣息。

應對策略

測試團隊意識到按照現有的流程再繼續下去是行不通的，于是在4月初果斷停止了所有進行中的任務，商量應對方法。 在總結了前述的各種的挑戰后， 提出了如下應對策略：

測試框架對常見的測試難點進行封裝

對于異步數據加載問題，我們將問題分為不同的場景，提供一個示例來描述問題的細節以及我們如何處理它的當前方式。 同時負責測試框架的小組系統地了解這些場景，并封裝成標準方法，并為每個場景設置最大延遲時間，如果到時不返回期望值，則拋出異常。

對于Web元素定位器問題，我們列出典型的情況，并與測試框架小組和國外各組件研發團隊合作，將穩定的查詢條件封裝成一個明確的查找方法。測試人員調用統一的方法進行測試。

加強配置管理

包括：正確使用git工具和提交流程;使用JIRA配合AML對需求進行管理;測試團隊內部代碼審查等。加強配置管理對于解決SaaS產品更新快這一挑戰非常有效。關于配置管理業界討論得比較多我就不詳細展開，只重點強調一下對于測試數據集的配置管理。

我們的測試數據集來源有兩部分:

運行整套測試用例集之前通過工具進行初始化填充。

測試用例內自行管理的測試數據。

因為之前關于如何維護測試數據集的定義是模糊的，在運行UI測試和API測試用例時都會對這兩部分數據集發生CRUD操作，造成了我們對于上述測試數據集的完整性無法保證。

針對這個情況， 我們加強了對數據集的配置管理，要求測試團隊應嚴格遵循以下規則：

將初始化測試數據視為只讀。

如果必須更改初始化測試數據，我們應該在測試用例退出之前改回原來的值。

將測試用例自己管理的數據視為例外情況，單獨管理這些測試用例。

優化測試開發流程和團隊溝通流程

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

和每個研發團隊指定點對點的聯系人，建立更緊密的聯系，獲得必要的技術支持。

在Git中增加Accept分支，測試用例開發完成后在測試團隊內部進行review，通過后提交到Git的Accept分支，研發團隊每周定期review，接收開發好的測試用例并Merge到Main分支用于生產。

實施過程

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

一，加強例框架研解決疑難技術點。例如在網頁上查找employee元素，如果employee元素不在屏幕內，這時定位就會報錯。 開發團隊使用WebDriver JavaScriptExecutor的executeScript方法進行滾屏操作，很好的解決了這一問題。現在只需要調用getEmployeeNameDiv()方法，傳入employeeName，就可返回要查找的employee元素：

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

三，增派架構師參與到測試框架設計工作中，處理諸如異步數據加載等技術挑戰， 同時指導測試數據管理，驗證方法抽象和經驗總結。

四，重新設計測試開發流程，增加架構師或業務分析師對測試用例的業務流程進行Review， 測試用例在本地的CI/CD環境進行daily run。并將新的流程對測試團隊進行培訓。

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

六，派專人出差到國外和各個組件團隊面對面溝通，就產品，API以及疑難的測試需求進行了深入的溝通。指定一對一的聯絡人，加快溝通的響應速度。

七，針對我們之前開發的623個測試用例進行了重構。

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

總結

對于企業級SaaS來說，在自動化測試領域會有如下新挑戰：

除了頁面自動化測試的技術挑戰，還要考慮SaaS產品多租戶對測試用例設計帶來的挑戰。

SaaS產品迭代周期快， 對自動化用例的開發效率，用例的通過率都帶來很大挑戰。

企業級SaaS產品研發團隊經常跨地域的特點，給處在不同地域的技術團隊帶來更大的溝通挑戰。

奧博杰天中國測試團隊在實施WHMC的自動化測試項目中得到的企業級SaaS產品最佳實踐是：

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

采用數據驅動測試來應對多租戶的挑戰。

配備經驗豐富的架構師參與測試框架設計，關鍵問題解決和經驗總結。

加強配置管理，有效應對產品更新快的挑戰。特別是測試數據集的管理，對于初始測試數據集保持只讀;如果必須更改初始化數據，需要在用例退出時恢復原值;特殊的測試數據單獨管理。

加強測試團隊和技術團隊的溝通，建立必要的跨團隊溝通流程，得到研發團隊的技術支持。

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