自動化測試架構設計參考準則

　　簡介

　　測試架構是在所有不同的測試自動化階段定義的一整套指導準則：需求分析階段、腳本設計階段、執行階段、報告和維護階段。架構即對于内部複雜架構的一種包裝，這樣的包裝可以使得最終使用者友善的使用。架構還具有對于流程标準的強制執行性。

　　問題描述

　　目前為止，還沒有一種關于如何開發測試架構以及在開發過程中需要考慮哪些因素的準則。有很多記載着各式各樣的測試架構以及它們各自是如何工作的白皮書，但是這些白皮書中還沒有任何一篇文檔是記錄着測試架構設計共同需要考慮的因素。本文基于測試架構需求，涵蓋了測試架構各個方面以及一些必備的基本要素。

　　1. 自動化測試架構的類型 – 目前普遍存在的架構有以下幾種：

　　資料驅動架構 – 當測試對象流程固定不變(僅僅資料發生變化)，可以使用這種測試架構。測試資料是由外部提供的，比如說Excel表、XML等等

　　關鍵字驅動架構 – 這種自動化測試架構提供了一些通用的關鍵字，這些關鍵字适用于各種類型的系統。它還為自動化測試工具和被測系統提供了抽象性。舉個例子，它可以使用相同的測試用例來測試類似的Web和Windows系統。

　　混合型的架構 – 混合型自動化測試架構同時具有資料驅動型和關鍵字驅動型架構的優點。這種測試架構不但具有通用的關鍵字，還有基于被測系統業務邏輯的關鍵字。例如“登入”、“退出”是可以被使用的僅局限于某系統的關鍵字。

　　2. 不要過分的改造 – 自動化測試架構應該盡可能的使自動化測試工具發揮它自己強大的功能，而不是通過實作新的關鍵字來重新定義整套語言。開發一套關鍵字驅動的自動化測試架構的代價是很大的而且非常耗時。開發一套混合型的自動化測試架構的代價就相對較小而且開發周期短。

　　3. 可重用性 – 測試架構應該盡最大可能提高可重用性。把單獨的Action組合成業務邏輯可以提供可重用性。舉個例子，可以把類似于“輸入使用者名”、“輸入密碼”和“點選登入”這些Action組合成一個可被重用的子產品：“登入”

　　4. 支援系統的不同版本 – 自動化測試架構應該允許重複使用基線化腳本，這樣可以保證這份腳本能被用來對被測系統的多個版本進行測試。對不同系統的支援有兩種方式：

　　複制和修改 – 這種方法包含了建立基線腳本的一個拷貝、修改這份拷貝用以測試特定版本的項目。

　　重用和更新 – 這種方法包含了重用基線腳本、提供一個此腳本的更新和優化用以測試特定版本的項目。這樣做可以最大化的保障可重用性，這也是推薦的方法。

　　5. 支援腳本版本化 – 測試腳本應該被儲存在類似于CVS、微軟的VSS等版本控制工具中。這樣做可以保障在災難發生的時候可以被恢複。

　　6. 将開發和釋出環境分開 – 自動化應當和其它開發項目同等看待。測試腳本應當在一個測試環境下建立和調試。一旦測試腳本測試通過後唯一該做的就是将它部署到釋出環境。在緊急釋出版本的情況也同樣适用這種方法。

　　7. 外部可配置性 – 腳本的可配置項應當被儲存在一個外部文檔中。系統的URL、版本、路徑等都可以被視作可配置項放在外部檔案中。這樣做可以使得在不同的環境中都可以執行測試腳本。需要注意的是外部配置檔案的路徑不要寫死，如果把它寫死了雖然在任何環境中都還是可以運作腳本，但是每次隻能在一個環境運作。配置檔案的路徑使用相對路徑即可解決這個問題。

　　8. 自身可配置性 – 理想的測試架構應該是自身可配置的。一旦部署到系統中之後應當不需要再做任何手工配置，腳本應當自動配置完成一些必要的設定。

　　9. 任何對象改動引起的變動應該是最小的 – 自動化過程中最為常見的問題是對象識别的變更。測試架構應該支援可以很容易的來完成這些修改。這可以通過将所有的對象識别設定儲存在一個共享檔案來實作。這個檔案可以是XML檔案、Excel檔案、資料庫或者自動化所特有的格式。這裡有兩種可能的方式來實作對象識别設定的方式：

　　靜态方法 – 這種方法中，所有對象定義都在測試最初被加載到記憶體中。任何對象定義變更隻能通過停止和重新運作測試來實作。

　　動态方法 – 對象定義是通過需求拉動的。這種方式和靜态方式比較而言顯得較為緩慢。但是對于非常大的腳本而言，并且對象識别需要在運作時做修正的情況下，動态方法是适用的。

　　10. 測試執行 – 自動化測試架構也許需要滿足以下需求(基于實際需求)

　　執行單獨的測試用例；

　　批量執行測試用例(一組測試用例)；

　　隻執行失敗的測試用例；

　　可以在前一個(一組)測試用例執行結果的基礎上，執行下一個(一組)測試用例；

　　根據實際需求還會有許多其他情況。一個架構可能無法實作所有這些需求，但它應具有足夠的靈活性以适應今後此類需求。

　　11. 狀态監測 - 一個架構應允許實時監控執行狀态，一旦失敗能夠發出警報。這樣可以在出現failure之後迅速回報。

　　12. 報表 – 不同的系統對報表有不同的需求，有時候需要一組測試的整體報表，有時候隻需要單個測試用例級别的測試執行報表。一個好的測試架構應該有足夠的彈性來按需支援不同的報表。

　　13. 發生更改的時候對測試工具盡量小的依賴性 – 一些測試腳本的更改可能隻能在打開測試工具後，在測試工具中進行修改，然後儲存。測試腳本應該在沒有測試工具的情況下也可以對腳本進行更改。這樣的實作可以減少license的購買進而為公司節省開支。這樣的實作還可以讓所有想去修改腳本的人無需安裝測試工具也可以很友善的對腳本進行修改。

　　14. 友善的調試 – 調試在自動化過程中占據了大量的時間，是以在調試這個過程中需要加以特别的關注。關鍵字驅動的測試架構因為使用了外部的資料源(比如Excel資料表)去讀取腳本中的關鍵字和測試過程，是以較難調試。

　　15. 日志 - 生成日志是執行的重要組成部分。在一個測試案例的不同點生成調試資訊這是非常重要的。這些資訊有助于快速地找到問題的範圍，同時縮短了修改時間。

　　16. 易用性 - 該架構應易于學習和使用。對架構的人員教育訓練費時且昂貴。有一個好文檔的架構更容易了解和使用。

　　17. 靈活性 - 架構應該足夠的靈活，以适應任何改進，而不會影響已有的測試案例。

　　18. 性能的影響 – 架構還應考慮對執行性能的影響。一個複雜的架構會增加腳本的加載或執行時間，這一定不是我們所期望的。像緩存技術，當執行時編譯所有代碼到單個庫中等.。.隻要可能都應該用于性能的改善。

　　19. 架構支援工具 – 開發一些外部工具來完成任務，這對架構設計會有幫助。這是一些例子：

　　從本地檔案夾上傳腳本到QC

　　結合庫檔案到目前打開的腳本

　　同步本地和QC上的腳本檔案

　　20. 編碼标準 - 編碼标準應確定腳本的一緻性，可讀性和易于維護。編碼标準應包含下列内容：

　　命名規範(變量、子程式、函數、檔案名、腳本名稱等)，例如i_VarName為整數變量， fn_i_FuncName為傳回值是整數的函數；

　　庫、子程式、函數的頭部注釋。這應包含，如版本曆史，建立者，最後修訂者，最後修訂日期，說明，參數，示例；

　　對象命名規範。例如txt_FieldName為一個文本框；

　　總結

　　我們應該把自動化測試看作是一個開發項目，而不僅僅是記錄和回放事件。先有一個良好的架構，再開始自動化測試，這樣可以確定較低的維護成本。當你在開發一個架構，進行架構的需求分析時，可以參考本文談到的這些準則。