Robot框架下的軟件自動化測試技術

北京中電普華信息技術有限公司 張露雨 李 佳

軟件開發技術發展得越來越快的同時對軟件質量的要求越來越高，測試變得尤為重要，軟件測試是質量保證的重要手段。隨著開發周期日益縮短以及系統越來越復雜，手工測試很難在短時間內完成高質量的測試，會耗費大量的人力物力。引入自動化測試，可以明顯縮短測試工期，減少人力物力成本。自動化測試已經被廣泛應用于各種類型的測試中。本文主要內容有：自動化測試的優缺點、適用范圍，自動化測試框架及工具、Robot Framework在項目中的應用、常見問題處理方式等。

近幾年來，人們對軟件質量的要求越來越高，軟件生命周期中軟件測試工作變得越來越重要，軟件測試是軟件質量保證的關鍵步驟。傳統的手工測試速度慢、效率低，當測試周期很長、重復性操作過多時，手工測試很容易變得枯燥無味，也可能會出現由于間隔時間過長，缺陷描述不清晰等因素，導致回歸測試無法重現問題；自動化測試可以提高測試效率，減少測試時間，很好的解決了手工測試的瓶頸。本文將圍繞Robot框架分析研究自動化測試技術在項目中的應用。

1 自動化測試意義及適用項目特征

1.1 自動化測試的意義

自動化測試是將手工測試行為轉換為機器執行的一個過程，即通過自動執行程序語言編寫的測試腳本模擬手工執行測試用例對軟件進行測試。我們通常所說的自動化測試主要是說通過程序設計，使計算機按照預定的流程自動測試軟件，自動記錄軟件缺陷以及自動分析測試結果的一種測試，自動化測試可以節省人力資源、時間和硬件資源，有效提高測試效率。

一般情況下，大型軟件開發項目測試工作量普遍很大，測試又是軟件生命周期中十分重要的環節，幾乎占據一半的時間來進行軟件測試，一些可靠性要求非常高的軟件，測試甚至可以占據更多的時間，一個軟件從開發到上線需要經過很多次的回歸測試，每一次回歸測試工作存在大量重復性操作的情況，并要求做到細致準確，自動化測試最適合代替人工去完成大量的重復性工作。

表1展示了自動化測試的優勢及手工測試的局限性。

雖然與手工測試相比，自動化測試具有很大優勢，但自動化測試也有自己的限制，自動化測試往往是提供一個框架、一種工具，維護難度較大，且不是所有的測試用例都可以轉化為自動化測試用例，例如數據正確性、頁面布局是否美觀、業務邏輯是否滿足需求等還是需要手工測試來完成，此時手工測試發現的缺陷比自動化測試發現的缺陷更多。自動化測試可以提高效率、復用性、可靠性等，雖然有很多優點，但也只是軟件測試的一部分，無法完全代替手工測試，自動化測試是對手工測試的一種補充。

表1 自動化測試與手工測試

1.2 適合自動化測試項目特征

一般情況下，項目滿足以下幾點可采用自動化測試。

（1）項目周期足夠長

自動化測試前期需要很多準備工作，自動化測試框架的設計、測試腳本的編寫及調試均需要相對較長的時間來完成。如果項目周期較短，沒有足夠的時間去支持以上工作，那么此類項目就不適合做自動化測試。

（2）軟件需求穩定，不會頻繁變動

測試腳本維護成本很大程度上會受測試腳本穩定性的影響，針對頻繁變動需求的項目來說，測試人員需時刻關注并更新與變更后需求相關的測試腳本。測試腳本的維護本身也是一個代碼開發、調試的過程，必要的時候可能還需要修改自動化測試框架，如果維護測試腳本的成本高于節省人力的成本，則說明此類項目不適合進行自動化測試。如果一個項目中部分模塊需求穩定，則可僅針對這些模塊進行自動化測試，其余模塊依然采用手工測試。

（3）需要在多種平臺上重復運行相同測試場景

對于需要在多種瀏覽器或者大量不同移動端上執行相同測試場景的項目，如果采用手工測試則需要將每個測試用例反復執行多次，自動化測試是此類項目一個不錯的選擇，可以減少大量重復性操作，提高測試效率。

2 自動化測試框架簡要介紹

自動化測試已經在測試行業廣泛應用，如何選擇一個合適的測試框架變得尤為重要。為此，我們需要了解目前行業中主流的自動化測試框架，這樣才能從中選擇最適合自己接觸的項目的測試框架。現在主流的自動化測試框架有：Robot Framework、RedwoodHQ、Jasmine、Pytest等。

2.1 主流自動化測試框架簡介

（1）Robot Framework

Robot Framework（RF）是用于驗收測試和驗收測試驅動開發（ATDD）的自動化測試框架。基于Python編寫，但也可以在Jython（Java）和IronPython（.NET）上運行，提供跨平臺支持（Windows、Linux或MacOS）。

首先Robot Framework使用關鍵字驅動測試的方法，這樣簡化了自動化測試過程，對于沒有編程經驗的測試人員來說使用Robot Framework編寫的測試數據更加便于理解。其次Robot Framework由各種獨立項目開發的測試庫和工具組成，生態系統相對較為豐富，且Robot Framework具有較高的可擴展性，對于未來市場和行業出現的變化有較好的應對能力。

（2）RedwoodHQ

RedwoodHQ可以使用大部分流行的編程語言來編寫測試腳本，比如JAVA、C#、Python，并且RedwoodHQ支持多人協作編寫并運行測試用例。RedwoodHQ關注一個重大項目的全部測試過程，可以說是目前主流平臺中對用戶、測試人員最友好的測試平臺。

（3）Jasmine

Jasmine適用于網頁項目、Node.js項目，是一個由JavaScript的行為驅動開發的測試框架，也是一個單元測試框架。但是除了JavaScript之外Jasmine還可以在Python、Ruby語言運行，并且可以在服務器端運行客戶端測試。Cis支持比較廣泛，且內置用于斷言的語法，使用起來十分方便。但是Jasmine難以異步測試且大多數情況下Jasmine需要一個測試運行器才能進行測試。

（4）Pytest

Pytest是基于python語言的單元測試框架，適用于復雜度低且規模較小的項目。使用起來相當簡潔高效。最大的特點就是易于使用，它入門簡單，對沒有代碼編程經驗的人相對容易上手。官方提供了相當多的支持文檔與參考實例，支持參數化操作，支持部分測試步驟的跳過，可以重復執行失敗的case，對第三方插件兼容性較高，并支持自定義擴展。且Pytest編寫代碼相對簡單，代碼容錯率較高，可以搭配圖形用戶界面一起使用，使測試工作可以進行得更加輕松。但是Pytest只適用于復雜度、系統規模都不大的項目，性能和運行效率方面無法支持市面上規模較大的系統。

綜上所述，從擴展性、易用性、測試人員能力等方面綜合考慮得出結論Robot Framework框架是最適合當前公司項目使用的自動測試框架。

2.2 Robot Framework詳細介紹

Robot Framework是一款使用python創建的用于功能自動化測試框架，由于Robot Framework支持多個客戶端或者多個接口同時同步測試，又具有很高的擴展性，且可以通過關鍵字驅動，使用效率較高、難度較低，所以Robot Framework目前在測試行業中應用廣泛。

（1）Robot Framework使用txt文件保存測試用例，使用制表符分隔數據，便于適應不同的編輯軟件使用，甚至可以使用excel等軟件創建用例，使用十分方便。沒有編程基礎的業務人員也可以使用Robot Framework框架編寫測試用例。

（2）設計測試用例時可以根據使用需要設置變量，且Robot Framework架構支持常用的循環語句，有利于測試用例的泛用和復用。

（3）支持標簽操作，可以對測試用例進行分類，便于規范測試用例。執行時可以只執行部分測試用例。

（4）Robot Framework框架支持數據驅動、關鍵字驅動在內的多種驅動。

（5）Robot Framework框架支持對現有關鍵字的調用，可以以現有關鍵字為基礎創建新的關鍵字，方便創建更加復雜更加高級的測試用例。

（6）Robot Framework框架生成的測試報告、測試日志均是html格式文件，方便閱讀，方便提供給沒有編程能力的管理人員閱讀。

（7）Robot Framework自帶事件的監聽接口，用戶可以自行定義測試用例執行前執行后的對應動作。方便自定義測試用例中的前置條件和后置條件，便于測試用例的連續操作，能有效提高測試用例的泛用性和復用性。

（8）Robot Framework內置命令接口，可以使用XML格式進行輸出，可以與其他測試工具、管理工具結合使用，進而實現整個測試過程的持續集成。

（9）Robot Framework內含大量的測試庫，可自動識別、操縱被測對象。

（10）Robot Framework提供了遠程測試執行的接口、支持遠程調試，方便線上交流。非集中辦公的項目也可以使用Robot Framework進行測試。

（11）Robot Framework基于python語言開發，相對較為便于初學者理解。

3 Robot框架在自動化測試中的應用

我司電力營銷系統開發周期較長，系統功能較多，涉及了三百多個功能，功能結構類似，其中增刪改查等基本維護類操作占據整個系統功能的70%左右，為了適應大眾的瀏覽器使用習慣，該系統需要做目前主流瀏覽器（IE8及以上、chrome50及以上、firefox50及以上版本）的兼容性測試。如果單純靠手工來進行測試，需要做大量重復性操作，既費力又耗時，重復性操作持續時間過長的話，可能會有一些測試點會被遺漏，回歸測試時也不能確保盡可能覆蓋測試點。針對這些功能開發自動化腳本進行測試是一個很不錯的選擇，接下來簡單介紹下基于Robot框架的自動化測試應用，選取新增渠道類型功能為例。

3.1 Robot framework自動化測試環境搭建

（1）安裝python，安裝完成后配置環境變量。

（2）安裝wxPython。

（3）安裝Robot framework。

（4）安裝robotframework-ride（RIDE是一個圖形界面的用于創建、組織、運行測試的軟件）。

（5）安裝selenium2library。

（6）下載各瀏覽器版本對應的驅動并拷貝到python安裝目錄下。

3.2 編寫測試腳本

登錄腳本編寫及調試：

該系統需要對瀏覽器兼容性進行測試，可以在open browser的瀏覽器參數部分輸入chrome、ie（默認為firefox，可不用輸入），并輸入測試地址、用戶名密碼進行登錄操作，由于后續操作基于登錄功能，為了節省腳本錄制時間，將登錄腳本進行封裝，后續操作時可直接使用，如圖1所示。

新增功能腳本編寫及調試：

（1）調試腳本時，如果遇到頁面跳轉后一直返回找不到元素的錯誤，先不用急著改腳本，可能原因是切換新頁面后頁面內容較多，部分元素還沒有加載完畢，導致找不到元素，可以在定位元素之前插入一條sleep操作，一般可以解決由于頁面內容未加載完導致的定位元素失敗問題，如果插入sleep依然找不到元素，接下來可以繼續查看是否是元素定位有誤。

（2）自動化測試常用元素定位方法有8種，包括：id定位、name定位、class定位、tag定位、link定位、partial_link定位、xpath定位、CSS定位。其中xpath定位時，使用瀏覽器中開發人員工具（F12）選中頁面元素后，右鍵copy其XPath，粘貼至ride中，部分頁面元素的XPath沒有明顯的id、name等唯一值屬性，只能從頁面html標簽開始向下尋找，如“/html/body/div /test /div/div/……/div[2]/button”，直接將其粘貼至ride中調試不成功，會報element not Found的錯誤，出現這種情況的原因主要是根據維護的元素定位路徑未找到元素，此時需要將其格式轉化為腳本執行時要求的格式，以//開始，//后面為元素唯一標識（路徑唯一的部分可用*替代）。

（3）selenium2library測試庫中常用點擊操作相關關鍵字包括：click button、click element、click link、click image等，由于該系統功能菜單/功能按鈕大多使用鼠標放在菜單名稱處無需點擊即可顯示下級菜單，因此不能單純采用click element、click button等點擊操作關鍵字來編寫該測試腳本，需要引入mouse up關鍵字來進行編寫。由于該模塊功能均需要進入同一模塊菜單進行操作，為了方便復用，將進入菜單過程進行封裝，如圖2所示。

圖1 登錄腳本編寫及調試

圖2 新增功能腳本編寫及調試

圖3 新增功能腳本編寫及調試

（4）參數化，robot framework-ride提供參數化設置，通過參數化設置可在腳本中引入變量，以此來解決一些特殊場景的需求。如頁面字段存在超長字符校驗時，可將該字段參數值設置為固定長度的變量，以此來避免手動輸入大量數據帶來的工作量。如果遇到頁面字段需要輸入唯一值的情況，也可將該字段參數值設置為變量的形式，為該變量賦值為隨機數等不易重復生成的數據，如圖3所示。

（5）添加檢查點，檢查點需要根據實際系統實現來進行查找并添加，該系統新增成功后返回查詢頁面，頁面提示“成功”，因此添加檢查點可以使用關鍵字Page Should Contain，查找內容為“成功”。如果可以找到“成功”，說明該用例執行后新增數據成功，否則新增失敗，如圖4所示。

3.3 執行腳本

執行方式選擇pybot，點擊【start】開始執行測試用例腳本，用例執行結束后，輸出信息、運行日志以及結果報告生成保存至臨時文件夾，可以直接使用瀏覽器打開路徑進行查看，如圖5所示。

圖4 新增功能腳本編寫及調試

圖5 執行腳本

圖6 分析結果

圖7 分析結果

3.4 分析結果

Report顯示所有用例執行結果，包括用例總數、成功數、失敗數以及執行時間，Pass為用例通過，Fail為用例不通過，如圖6所示。

如果想查看具體執行情況，可點擊用例名稱鏈接跳轉至運行日志頁面查看詳情，如圖7所示。

4 自動化測試常見問題的解決方案

4.1 錄制腳本需要消耗大量時間

錄制測試用例腳本需要耗費大量時間，對于中小型項目來說，使用自動化測試偶反而會拖慢項目的進度。對于開發初期的項目，由于各個流程尚未開發完成，需求變化比較頻繁，編寫好的用例可能沒多久就完全不能用了，導致自動化測試用例的復用性大幅度降低。對以上類型項目可轉換測試策略：對于中小型項目，主要采取手工測試的方法，只對某些復用性較強且需要反復測試的項目進行自動化測試。對于大型項目，項目初期不進行自動化測試，通常等到項目中期，流程設計基本確定之后再進行自動化測試。

4.2 修改代碼后腳本無法復用

開發修改代碼后再執行用例報錯，需要重新閱讀代碼修改用例。

大型項目參與人員較多，不同開發人員修改代碼經常會導致以前的測試用例無法繼續執行。測試需要重新閱讀代碼進行排查，費時費力。有時由于測試人員代碼閱讀能力不夠，花很久也無法修正用例。對此團隊可以安排測試人員和開發人員不再按照職責化分工作，整個項目盡量按照負責模塊劃分，讓負責同一部分的業務、開發、測試人員坐在一起，并要求在用例無法復用且問題較難解決的時候開發人員配合測試人員進行修改。

4.3 自動化測試不夠細致

自動化測試只能發現既定的缺陷，對于新出現的缺陷有時無法識別。

自動化測試可以驗證流程不通，界面報錯等問題，但是對于界面設計錯位或者不美觀、等GUI問題一般無法識別。輸入預先設定的測試數據或測試數據組合之外的情況如果出現BUG，也無法識別。對此團隊決定采用手工測試與自動化測試結合的方式進行測試。每輪首先進行自動化測試，在自動化測試的主要問題解決后開始手工測試，盡量排查出自動化測試無法識別的問題。

4.4 系統架構復雜不好定位元素

現在常用的元素定位方法有8種：1）通過id定位；2）通過name定位；3）通過tag定位；4）通過class定位；5）通過css定位；6）通過link定位；7）通過partial_link定位；8）通過xpath定位。但是如果項目開發時沒有為元素設置唯一的標識，那么定位元素會十分困難，且代碼修改后用例極有可能無法復用。對此團隊可以規范開發過程，盡量對所有元素設定唯一標識，并且規范標識設定規則，這樣不僅規范了代碼書寫要求，還使代碼更便于閱讀與整改。對于無法設定唯一標識或者較難定位的元素，開發人員將配合測試人員進行定位。有時也可以為了方便測試對部分元素先設定臨時的唯一標識，項目測試基本結束時再刪去標識，進行相關功能的手工測試，保證刪去標識對系統流程驗證沒有影響。

自動化測試技術還在不斷的發展，雖然還有很多不成熟的地方，或許最終也無法完全取代手工測試，但是自動化測試帶給項目的便利與效率是毋庸置疑的，在科技日新月異、技術突飛猛進的時代，期待著自動化測試在未來能帶給我們更多驚喜。