自動化測試基本策略(4)

　　自動化測試架構設計的時候的一些基本的策略：

　　1、 自動化測試腳本與自動化測試架構的代碼分離，自動化測試架構的代碼實現自動化測試的基本功能，自動化測試腳本包含業務邏輯。

　　2、 設計清晰的腳本和配置文件的存放目錄。

　　3、 數據驅動

　　1) 測試系統相關的配置、模擬器的配置等系統級的配置用系統級配置文件存放，不要把這些值寫死在腳本或代碼中，否則當測試系統的環境變化的時候相應的維護成本也會很高。

　　2) 測試系統所使用到的一些規范定義取值，定義在配置文件中，在腳本中需要使用的時候引用變量定義，這樣即使規范定義改變了也不需要修改腳本，只要簡單的修改配置文件即可;如果外部規范定義和內部的定義取值不一樣，最好有對應的mapping定義表。

　　3) 測試數據的數據模型如果比較復雜，最好也在配置文件中對數據模型以及字段的取值進行定義，方便在腳本中創建數據時使用。

　　4) 協議或Schema或話單的格式，在配置文件中定義，當協議的格式改動的時候，只需要修改配置文件即可。

　　5) 腳本中盡量少用常量，輸入參數、腳本運行時提取的值、測試結果的對比等，都可以使用變量，避免腳本的常量寫死后引起的維護工作。

　　4、 測試數據準備

　　1) 測試數據準備，有兩種類型，一類是腳本運行前事先可以準備好的數據，這種類型的數據，可以在自動化測試前自動創建好并保存到文件中提供給測試腳本使用;另一類是腳本運行時要創建的特殊數據，這些數據可以在腳本運行的過程中調用基礎腳本進行創建。

　　2) 公用的數據，如果在腳本運行的過程中被修改，在該腳本運行結束后需要恢復到原樣，避免因為公用數據的修改引起其它腳本運行失敗。

　　5、 模塊化：對基礎腳本進行封裝，一些可以公用的腳本單獨封裝給其余的測試腳本調用，當公用的業務邏輯改變的時候，只需要修改基礎腳本，而不需要對所有的測試腳本進行改動。

　　6、 提供自動化腳本編寫模版，新寫的腳本只需要在模版的基礎上做很小的改動就可以實現功能，可以節省腳本編寫的時間和降低腳本編寫的門檻。

　　3.4 自動化測試腳本編寫

　　自動化測試腳本的編寫功力很重要，寫得好的腳本，可以減少維護的工作量。自動化測試腳本一般由測試的輸入、業務邏輯、測試輸出和測試結果驗證幾部分組成。自動化腳本的編寫，要注意全局的把握和review，不同的人會有不同的風格，稍不注意就會問題多多。在自動化腳本編寫前，給相關同事提供技術和架構的培訓，培訓的內容包括被測試系統的基本功能介紹、自動化測試工具的架構、自動化測試的配置說明、自動化測試的編寫原則、自動化腳本編寫示例等。自動化測試腳本的例子也很重要，建議在腳本編寫前對系統準備實現自動化測試的功能進行分類，由資深的自動化測試工程師根據每個分類都先寫一個例子并且review通過后作為這些功能的自動化測試腳本的編寫模板，其余的同事可以參照例子按照自動測試架構編寫規范寫腳本。

　　編寫腳本時應該注意腳本的可重用性和可維護性，如果腳本中充滿了硬編碼的值，這些值應該被參數化，否則腳本僅僅適用于一個測試情況，腳本還應該加入條件判斷、循環等結構，以便增強測試腳本的靈活性。

　　在編寫腳本的時候必然會遇到技術問題或業務問題，需要有資深的工程師或TL協助解決，并且在整體的架構上全局把握。腳本編寫完成后，需要有一個抽查Review的過程，挑幾個典型的腳本review一下，看看是否存在不足的地方，然后改進。

　　3.5 自動化測試腳本測試

　　當每一個測試用例所形成的腳本通過測試后，并不意味著執行多個甚至所有的測試用例就不會出錯。輸入數據以及測試環境的改變，都會導致測試結果受到影響甚至失敗。而如果只是一個個執行測試用例，也僅能被稱作是半自動化測試，這會極大的影響自動化測試的效率，甚至不能滿足夜間自動執行的特殊要求。

　　自動化測試腳本最基本的原則是測試結果可信，也就是在批處理運行這些腳本的時候，該測試通過的就測試通過，該測試失敗的就測試失敗，如果出現本應該失敗的腳本在運行的時候通過了或本應該通過的腳本在運行時失敗了，測試結果就變得不可信了，自動化測試也就失去它本應該有的意義。

原文轉自：http://www.uml.org.cn/Test/201005042.asp