軟體自動化測試流程與我們的自動化測試

標籤：style   blog   http   os   使用   檔案   資料   2014   問題   

摘要

每一個對軟體測試有興趣或者專業的軟體測試人員，在軟體自動化測試之初都會有濃厚的興趣也充滿著激情。因為都能理解到自動化做好之後會減輕測試人員重複勞動的工作量、全面的測試資料覆蓋可以提高軟體品質、豐富的日誌以及功能可以提升交付效率與便於分析問題等等的優點，都會令軟體自動化測試者為之瘋狂；然而，自動化測試卻常常帶給我們沮喪和失望，因為自動化在為我們解決問題的同時也會引入更多的問題，很多自動化技術的研究以及實施工作就會止步於此了。因此，在開展自動化測試之前，就應該制定自動化測試計劃，目前基本從改進軟體測試過程，定義需求，支援產品的可測試性，具有可延續性的設計，有計劃的部署。

改進軟體測試過程

我們在軟體測試的過程中，除了保證軟體品質之外更多的就是想著如何提升測試效率，因此首先就得定義好提升效率的具體過程，然後在投入人力物力的同時應該採用更簡單、成本更低的的方法。在這樣的一個過程中，我們就可以引入自動化測試。

在當下，越來越多的項目組引入了敏捷，頻繁的迭代、頻繁的迴歸與執行令匱乏測試人員的項目組大喊吃不消；因此無自動化不敏捷的思路也悄然散播開來。

現在很多項目組都在煙霧測試 (Smoke Test)與迴歸測試環節開始引入自動化測試。煙霧測試 (Smoke Test)需要在提測之初對其主幹流程進行測試的一個過程，例如某一航空公司電商網站每次的需求比較小(即每次改動比較小)，但每次提測都需要測試主幹流程如“預訂 -> 出票 -> 退票”；相對本次修改的功能，在這樣的一個主幹測試過程中會投入大量的人力保證主幹流程功能，如果這部分用自動化測試來代替測試人員，會把測試人員的主要精力都集中在本次修改的功能點。迴歸測試需要頻繁的執行，去檢查曾經執行過的有效測試案例沒有因為軟體的變動而執行失敗。迴歸測試需要反覆執行，並且單調乏味。此時需要測試負責人準確的分析可能因為變動哪些功能點會受到影響，將這些功能點做成列表形成迴歸測試文檔，然後對照列表與文檔檢查。引入自動化測試能夠大大減少工作量、與隨機性出錯；但是這項工作也會帶來很多問題，因為某些模組功能特性導致實現自動化非常困難。此時需要對提過的缺陷進行分析，針對每個缺陷寫了一個能夠發現該問題的測試執行操作，從而形成自動化測試的需求。擁有這樣一份良好的設計文檔，設計測試指令碼就是就是按部就班的事情了。

測試需求

自動化測試需求是要根據測試需求加上可測性分析，再加上自動化測試能取得的預期成效所決定的。自動化測試通常有解決如下這些問題的優點：重複的簡單邏輯的測試、覆蓋面範圍很廣的測試、加快測試進度提高發布進度等。

在設計測試需求時就應該明白自動化測試不只是為了自動化，而是為了能發現更多的缺陷而設計，不只為提高自動化測試人員的技能，而是為軟體品質與軟體發布服務的。

在制定測試需求的時候就應該確定自動化測試成功的標準，不要在測試過程去中隨意增加自動化測試功能點。也不要為了自動化的覆蓋率，強行在測試的每個部分都採用自動化方式，我們要尋找能夠帶來最大回報的部分，部分採用自動化是最好的方法，而不是僅僅了尋求挑戰在每個環節都採用自動化；也不要為了單純的追求複雜度與功能完整度，讓自動化完全替代手工將每個功能點細化到每一個細節，越做越複雜，最後做不動了；因此我們在做自動化測試的過程中就要去權衡一個回報與付出比，這是一個臨界點需要我們自動化測試人員的經驗去把控。

定義自動化測試專案的需求要求我們全面地、清楚地考慮各種情況，然後給出權衡後的需求，並且可以使項目相關人員更加合理的提出自己對自動化測試的期望。

支援產品的可測試性

產品的可測試性分析是自動化測試必不可少的環節，也是我從技術人員角度出發認為最重要的環節。特別是GUI的自動化測試，在整個開發過程中，圖形介面經常被修改或者完全重設計，如果處在圖形介面方案不停變動的時候，就開展 GUI 自動化測試是不會有任何進展的，你只能花費大量的時間修改測試指令碼，以適應圖形介面的變更。

如何避免上述問題呢？這時候就需要對所測產品進行可測性分析了，更準確的說不是避免問題而是繞開困難，因為我們不能反對開發人員改進圖形介面。我們都知道軟體產品可能會用到的三種介面：命令列介面、應用程式介面(API )、圖形使用者介面(GUI)。從本質上看，API 介面和命令列介面比 GUI 介面容易實現自動化，因此可以從這兩個容易實現自動化的介面去入手，如果產品沒有類似的介面，需要鼓勵開發人員提供相應的介面，從而支援產品可測性。

往往我們最初的自動化都是從直接操作UI開始的，因為做自動化之初總希望機器能夠類比人工形象的在頁面上操作，不過UI頁面自動化測試卻是最複雜、最難維護、最不穩定的，因此做好WEB的UI自動化測試首先就是要做好可測性分析。最常見的就是把頁面穩定的流程、主幹功能點、重複性強的功能點等做為WEB的UI自動化測試的可測性標準。

無論你需要支援圖形介面介面、命令列介面還是 API 介面，還是直接操作UI的自動化測試，如果你儘可能早的在產品設計階段提出產品的可測試性設計需求，將會增加你的自動化測試信心，在這條路上繼續前行。

具有可延續性的設計

可能跟上面提到的測試需求裡所說的有些衝突，但是此處的具有可延續性的設計不是讓我們在同一版本中不停的擴充需求以滿足自動化測試需要，而是有計劃有階段性的完善相關文檔與指令碼。最初我們會把注意力放在如何使自動化運轉起來，導致測試自動化達不到預期的效果。自動化測試是一個長期的過程，為了與產品新版本的功能和其他相關修改保持一致，自動化測試需要不停的維護和擴充。自動化測試設計中考慮自動化在未來的可擴充性是很關鍵的，不過，自動化測試的完整性也是很重要的。如果自動化測試程式報告測試案例執行通過，測試人員應該相信得到的結果，測試執行的實際結果也應該是通過了。其實，有很多存在問題的測試案例表面上執行通過了，實際上卻執行失敗了，並且沒有記錄任何錯誤記錄檔，這就是失敗的自動化。這種失敗的自動化會給整個項目帶來災難性的後果，而當測試人員構建的測試自動化採用了很糟糕的設計方案或者由於後來的修改引入了錯誤，都會導致這種失敗的自動化測試。失敗的自動化測試通常是由於沒有關注自動化測試的效能或者沒有充分的自動化設計導致的。

可延續性設計必須注意指令碼的簡單性、可讀性、可維護性、獨立性、可重複性，自動化架構的測試庫設計、資料驅動測試，日誌結果的可分析性。指令碼方面的注意點跟我們平時編碼習慣是分不開的，這是一個長期磨鍊的過程，需要自動化測試人員的技術沉澱；而自動化架構、日誌結果方面就要求我們必須要選擇一個好架構來支撐我們龐大的自動化測試體系。

有計劃的部署

當自動化測試的前期準備工作與設計工作都完成之後，部署問題也尤為重要，是否是成功的部署將會直接影響到測試執行。

目前有許多流程的部署執行的工具，如開源工具jenkins等，只有有簡單的安裝、使用文檔就可以完成實施部署了。

Autosky架構的使用

這裡我們就不對Autosky架構進行過多描述了，我們有詳細的使用手冊文檔與Demo檔案，並且架構具備前面提到的可延續性設計裡的測試庫設計、資料驅動測試，日誌結果的可分析性。

測試庫設計：架構中有對Selenium使用方法的封裝、系統檔案的讀取、eTerm的PNR預訂與K座、HTTP請求的操作、擷取各種日期時間、XML與Excel資料來源的操作、壓縮檔的處理、截屏的處理等等，幾乎包含了所有UI與介面測試的測試庫。

資料驅動測試：架構支援XML、EXCEL、SQL的資料驅動測試，這裡展示一下EXCEL表的資料群組合形式。

日誌結果：

模組執行資訊：

用例執行資訊：

步驟資訊：

 

 

Flysky日誌管理平台

使用過Autosky架構之後都知道架構在執行完成後都會在本地形成一份完整的日誌報告，而Flysky也是在自動化項目執行完成之後向日誌管理平台發送日誌資訊，可以展示各個實施項目的日誌展示結果，方便自動化負責人或者測試經理監控項目執行情況，便於資料分析；且此平台還能接受其它自動化架構的介面調用。

 

軟體自動化測試流程與我們的自動化測試