軟體測試之自動化測試

標籤：

自動化測試的優勢

能夠極大地提升測試的效率，測試人員可以迅速地在指定平台部署測試指令碼且對相應功能進行測試。

“弱化”了軟體測試人員個體差異對測試結果的影響。

提高整個測試團隊的技能水平。

自動化測試的缺陷

自動化測試的缺陷在於：總是按照既定的流程往下走，不能像人一樣隨機應變。一旦功能發生變動，就需要重新維護測試指令碼。

自動化指令碼的關鍵

要開發一套高品質的測試指令碼，並不是簡單的錄製/回放，而是需要滿足以下特點：

　　能夠有效發現產品缺陷
　　有良好的可讀性和錯誤記錄檔，能夠方便測試人員快速定位問題所在
　　能夠穩定、重複、獨立地運行，經過嚴格的審查流程
　　經過充分的指令碼驗收流程

在開發測試指令碼的時候，需要時刻記得指令碼的目的是暴露問題，任何在運行指令碼時拋出的異常都有可能是產品問題產生的，因此需要避免在代碼中隱藏問題。

一個好的自動化指令碼的開發人員首先必須是一個好的測試人員，只有對需要測試的產品非常熟悉，才能夠開發出真正有效測試指令碼。

如何提高測試指令碼的可維護性？這就要求指令碼有詳細的錯誤記錄檔和可讀性。

如何提高測試指令碼的穩定性？這就要求測試指令碼能夠具備運行獨立性和可重複性。

當一個指令碼運行失敗後，可能的原因有如下幾個方面：

　　由於產品本身的缺陷導致指令碼執行失敗
　　由於測試指令碼本身存在的缺陷導致誤判
　　由於測試環境搭建產生的問題導致失敗

不幸的是，在一個項目中，真正由於產品缺陷導致的指令碼執行失敗所佔的比率並不高，測試人員往往花費大量的時間去解決指令碼缺陷和測試環境導致的失敗。

因此，在開發測試指令碼的時候，需要注意：

　　環境搭建和資料載入後，需要有明確驗證步驟，如果資料載入失敗，及時中斷指令碼運行且提示出錯原因
　　對於每一個驗證點，需要在日誌裡輸出實際值和期望值，若驗證失敗，在日誌裡詳細描述
　　盡量不要在程式裡捕捉有可能出現的異常，應該將異常暴露給使用者，使測試人員能夠清楚地知道異常產生的位置

如何有效提高指令碼的可讀性？

　　通用的代碼編程規範
　　充分利用測試代碼中的注釋
　　將測試描述和測試代碼分離

如果沒有保證測試案例執行的獨立性，就可能產生如下問題：

　　由於所有用例之間的關係緊密，某一個用例執行失敗導致了後續一系列用例的執行失敗
　　增加了測試人員解決指令碼問題的難度，用例失敗，測試人員難快速定位問題原因
　　測試人員無法從中選取部分測試案例單獨運行

自動化測試架構

一個設計良好的自動化測試架構，能夠很方便地協助測試人員開發高品質的自動化測試案例。

在開發一個自動化架構之前，首先需要考慮該架構需要滿足什麼樣的要求。

一套自動化指令碼的運行周期中主要完成了以下工作：

　　測試環境配置
　　執行待測試的用例
　　測試結果的記錄
　　測試環境清除
　　測試報告產生

這些過程也構成了設計一個自動化架構的最原始的功能需求。

一個設計良好的自動化測試架構應該具備：

　　提高測試案例指令碼開發效率--如何能夠方便測試人員開發測試案例，能夠做到資料和執行過程分離
　　具有完善的環境搭建的支援--讓測試人員更加關注測試商務邏輯部分代碼的開發
　　具有完善的測試結果彙報功能--讓測試人員更好地測試商務邏輯

我們需要將環境準備的工作在測試自動化架構的層面進行實現，具體來說，需要實現以下功能：

　　測試環境的搭建和測試資料的清除
　　測試案例指令碼的執行調用
　　執行結果報告的產生

在設計這樣的自動化測試執行引擎時，首先需要考慮的是平台無關性。

制定自動化開發時間點時需要考慮的因素

不要在產品不穩定的時候開發自動化：初期缺陷較多，手動測試也可以熟悉產品，發現原有測試計劃的不足和覆蓋率缺失問題。

將測試指令碼用於迴歸測試中：功能相對穩定，且計劃也得到了較好的最佳化。

首先開發通用task：前期重點

測試自動化指令碼應該基於一個相對穩定的測試環境下，且依照成熟的測試計劃進行開發。如果初期開發大量自動化指令碼，往往會導致後期大量的指令碼返工量，反而降低了效率。

自動化測試的選取

自動化測試分為UI測試和API測試兩大類，API測試屬於更高層的測試方式，和單元測試相比，它更貼近使用者的操作。

GUI測試往往採用錄製/回放的方法，最大程度類比使用者操作，站在使用者的角度去發現問題，和終端使用者的行為聯絡緊密。但往往比預期要困難，因為UI設計變更會增加自動化測試複雜度，因此，GUI測試適用於當UI介面趨向於穩定的時候。

API測試通過直接調用軟體產品的外部介面來驗證返回是否符合預期，但無法覆蓋到介面UI的顯示正確性。API介面往往不會有頻繁的變化，能夠減少後期測試指令碼維護的工作量。

根據產品特點，可以採取不同方式去實施API測試，既可以直接調用產品暴露的API，也可以通過類比使用者的HTTP請求來調用伺服器端的Service。

測試指令碼的驗收

當完成指令碼開發之後，為了保證指令碼的高品質交付，需要制定高效的指令碼評審流程和驗收流程。

產品代碼清晰描述了某個功能點，能夠通過直觀的檢查確定功能是否完成。
自動化指令碼明確描述了測試流程、需要檢查的功能點，以及期望結果。

一套能夠永遠毫無差錯啟動並執行指令碼不一定是高品質的指令碼，因為這也有可能是由於指令碼沒有發現產品的問題。

自動化指令碼評審分成程式碼檢閱和功能點評審兩大方面。

程式碼檢閱：

　　代碼是否符合代碼規範
　　代碼的擴充性如何
　　閱讀代碼是否能清楚知道每個測試案例的測試步驟
　　是否能很好地暴露指令碼運行時發現的問題

功能點評審：

　　關注代碼是否涵蓋了所有的功能驗證點，測試步驟和驗證點是否和測試計劃保持一致

測試指令碼的驗收就是為了確保指令碼的使用者能夠順利地運行這套指令碼。

如果說評審是為了保證代碼的品質和功能點的涵蓋，驗收流程確保了自動化指令碼的運行穩定性和可重複性。

自動化指令碼驗收：

　　應當由非指令碼開發人員且具備中等技能的測試人員實施
　　支援跨平台的產品應覆蓋到不同平台
　　不僅僅關註腳本的運行是否順利，也要關注日誌是否詳細，是否有助於定位問題
　　驗收中發現的任何問題應該由指令碼開發人員負責解決

自動化測試的穩定性

測試自動化指令碼的穩定性直接決定了測試的效率。

影響自動化測試指令碼的穩定性因素：

　　指令碼中對某些輸入參數的寫入程式碼：這是影響指令碼穩定性最重要的因素。
　　指令碼等待時間寫入程式碼：在開發指令碼時機路的等待時間未必就是將來測試環境中的已耗用時間
　　跨平台問題：不同的作業系統或者資料庫可能存在不同，因此必須在多個平台上進行測試。

如何權衡手動測試和自動化指令碼開發的關係

對於比較穩定的測試專案，可以考慮在編寫測試計劃的時候同步編寫指令碼，測試計劃的作者同時也是測試指令碼的開發人員，這將極大提高自動化開發的效率，但前提是每一個測試人員都具有自動化指令碼開發的能力。

環境搭建和資料準備工作不會有頻繁的變更，可以考慮在項目初期先完成這部分的自動化工作。

把握測試自動化的度。

用公式平穀自動化指令碼開發的必要性

指令碼開發執行成本=指令碼開發工作量+(平均調試指令碼工作量+平均執行指令碼工作量)*每產品周期執行次數

手工執行成本=平均手工執行工作量*每產品周期執行次數

ROI=指令碼開發執行成本/手工執行成本

如果這個ROI比例在5以內，則說明需要用5倍的工作量去開發自動化指令碼。換句話說，這套指令碼如果未來執行了5次，我們就把成本賺回來了，以後每運行一次，我們就能盈利一次。而如果某功能點的手動測試需要半天時間，而我們需要花費1個多月的時間去開發自動化指令碼，這個比例就在60以上了，也就是說以後要運行60次以上才能收回成本。

軟體測試之自動化測試