自動化測試框架的設計思路

1.自動化測試框架的概念

它是由一個或多個自動化測試基礎模塊、自動化測試管理模塊、自動化測試統計模塊等組成的工具集合。
以常見的前端UI測試爲例，一個測試框架大概包括測試對象，測試組件，基礎類和函數，工具類，測試數據，異常處理，測試日誌，斷言和測試報告等這些模塊。

2.框架的驅動模式

2.1 數據驅動模式

如果被測系統業務邏輯固定不變或變動較小，我們可以使用數據驅動，通過不同數據來保證測試覆蓋率，通常數據都是保存在外面文件或數據庫中，運行時自動獲取。特點是數據與測試腳本分離，基於模塊化的測試庫，一個驅動腳本可以執行多個相似測試，這樣非常容易建立新測試。

2.2 關鍵字驅動模式

關鍵字驅動測試也被稱爲“表格驅動測試”或“操作名測試”，他是一種軟件自動化測試的方法論，將數據與關鍵字結合來描述如何使用數據執行測試。這種方法具備數據驅動的優勢，同時非編程人員也能建立新類型測試。例如Robot Framework就是典型的關鍵字驅動模式。

2.3 模塊驅動測試

模塊驅動測試使用獨立的小腳本來對應待測試的模塊、零件和子功能。這些不同層級的小腳本按照一定規則組合成更大級別的測試，如此就實現了一個特定功能的自動化測試案例。在所有自動化測試架構中，這應該是最容易領會和控制的一種，其應用非常廣泛，即屏蔽組件的內部實現，僅提供組件的對外抽象接口。如此下層的測試組件發生變動時，對上層自動化測試案例來說是透明的。模塊驅動測試引入了抽象和封裝的原則，目的是提升自動化測試的可維護性和可擴展性。

2.4 混合自動化測試

混合自動化測試是由其他自動化測試框架綜合發展起來的。成功的自動化測試框架通常融合了“關鍵字驅動測試”和“數據驅動測試”。他們即擁有測試邏輯與測試數據相互分離的優點，又集成了關鍵字驅動的先進架構。這一架構會使得數據驅動腳本更加簡潔，並減少運行時意外失敗的可能性。另一方面，該架構可以實現一些純粹的“關鍵字驅動測試”難以實現的自動化測試任務。該架構由核心數據驅動引擎、功能函數組件，以及支持庫所構成。

2.5 基於模型測試

基於模型測試適合於採用“基於模型設計”的軟件系統。在這種架構下，會有一個成熟的測試模型來描述測試數據的所有方面，以及測試案例和案例執行環境。通常這一測試模型是全部或者部分從待測試系統功能模型中提取出來的。測試模型描述了待測試系統的抽象行爲，因此從測試模型中可以派生出功能測試案例。這些測試案例構成了抽象測試案例集，不過抽象測試案例集不能直接在待測試系統上執行。真正可以執行的測試案例集（可以與待測試系統進行交互），是從抽象測試案例集派生出來的。有些基於模型測試的測試工具，支持從模型（包含足夠信息）產生可執行測試案例集，從模型派生出案例，可以有很多種方式，因此測試很多時候是依靠經驗去嘗試，並沒有固定的最佳方法。你需要事先收集“測試需求、測試目標，用戶用例"因爲他們包含待測試系統模型的信息。測試案例集是從模型而非代碼派生出來的，因此基於模型測試可以被視爲某種黑盒測試。事實上，基於模型測試目前只適合於功能不太負責的軟件系統，複雜商業軟件系統的基於模型測試，還處於探索階段。

3.設計框架的原則

3.1 高內聚低耦合

高內聚就是每個模塊儘可能獨立完成自己的功能，不依賴於模塊外部的代碼；低耦合就是模塊與模塊之間接口的複雜程度，比如在類內部儘可能減少方法之間的調用，否則一個方法的變動會影響調用它的另一個方法。

3.2 腳本分離

對象、測試數據、業務邏輯相互剝離、靈活調用,在前端UI測試上可以得到明顯的效果，我們可以使用PageObject設計模式來實現對象和業務邏輯的剝離，使用DataProvider來實現數據業務邏輯分離。

3.3 模塊化設計用例，腳本的可重用

如果時間充裕且項目提供支持，可以遵循以下順序進行測試： 頁面對象 - 功能點 - 業務邏輯 - 業務流程。
從實現來說就是：先測試底層的頁面操作對象，通過調用操作對象、及業務邏輯實現對功能點的驗證，再通過調用業務邏輯組合功能點實現對業務流程的驗證。不同的業務流程，對於底層的操作組件、中間層的功能點函數是完全可以複用的，只是調用的業務邏輯的差異，或者是測試數據的差異性。這樣的好處是腳本相互獨立性，代碼複用，易維護，如有新的業務流程可以調用已有代碼來組合。

3.4 封裝基礎方法

對於一些較通用的方法，可以封裝，比如log，assert，異常處理，文件讀寫操作，數據庫讀寫操作，保存頁面截圖等等。在需要的時候直接在測試用例裏調用即可。