【摘要】本文講述某個企業級SaaS產品自動化測試項目的實踐過程。文章介紹了項目遇到的挑戰、應對策略和實施過程，最后總結了企業級SaaS產品給自動化測試帶來的新挑戰和項目的六點實踐經驗。

　　項目背景

　　奧博杰天中國測試團隊負責一套云端人力資源管理產品的自動化測試，產品簡稱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產品更新快這一挑戰非常有效。關于配置管理業界討論得比較多我就不詳細展開，只重點強調一下對于測試數據集的配置管理。