軟件測試中自動(dòng)化測試框架設計參考準則
簡(jiǎn)介
測試框架是在所有不同的測試自動(dòng)化階段定義的一整套指導準則：需求分析階段、腳本設計階段、執行階段、報告和維護階段�？蚣芗磳τ趦炔繌碗s架構的一種包裝，這樣的包裝可以使得最終用戶(hù)方便的使用�？蚣苓�具有對于流程標準的強制執行性。
問(wèn)題描述
目前為止，還沒(méi)有一種關(guān)于如何開(kāi)發(fā)測試框架以及在開(kāi)發(fā)過(guò)程中需要考慮哪些因素的準則。有很多記載著(zhù)各式各樣的測試框架以及它們各自是如何工作的白皮書(shū)，但是這些白皮書(shū)中還沒(méi)有任何一篇文檔是記錄著(zhù)測試框架設計共同需要考慮的因素。本文基于測試框架需求，涵蓋了測試框架各個(gè)方面以及一些必備的基本要素。
1. 自動(dòng)化測試框架的類(lèi)型 – 目前普遍存在的框架有以下幾種：
o 數據驅動(dòng)框架 – 當測試對象流程固定不變（僅僅數據發(fā)生變化），可以使用這種測試框架。測試數據是由外部提供的，比如說(shuō)Excel表、XML等等
o 關(guān)鍵字驅動(dòng)框架 – 這種自動(dòng)化測試框架提供了一些通用的關(guān)鍵字，這些關(guān)鍵字適用于各種類(lèi)型的系統。它還為自動(dòng)化測試工具和被測系統提供了抽象性。舉個(gè)例子，它可以使用相同的測試用例來(lái)測試類(lèi)似的Web和Windows系統。
o 混合型的框架 – 混合型自動(dòng)化測試框架同時(shí)具有數據驅動(dòng)型和關(guān)鍵字驅動(dòng)型框架的優(yōu)點(diǎn)。這種測試框架不但具有通用的關(guān)鍵字，還有基于被測系統業(yè)務(wù)邏輯的關(guān)鍵字。例如“登錄”、“退出”是可以被使用的僅局限于某系統的關(guān)鍵字。
2. 不要過(guò)分的改造 – 自動(dòng)化測試框架應該盡可能的使自動(dòng)化測試工具發(fā)揮它自己強大的功能，而不是通過(guò)實(shí)現新的關(guān)鍵字來(lái)重新定義整套語(yǔ)言。開(kāi)發(fā)一套關(guān)鍵字驅動(dòng)的自動(dòng)化測試框架的代價(jià)是很大的而且非常耗時(shí)。開(kāi)發(fā)一套混合型的自動(dòng)化測試框架的代價(jià)就相對較小而且開(kāi)發(fā)周期短。
3. 可重用性 – 測試框架應該盡最大可能提高可重用性。把單獨的Act
4. 支持系統的不同版本 – 自動(dòng)化測試框架應該允許重復使用基線(xiàn)化腳本，這樣可以保證這份腳本能被用來(lái)對被測系統的多個(gè)版本進(jìn)行測試。對不同系統的支持有兩種方式：
o 復制和修改 – 這種方法包含了新建基線(xiàn)腳本的一個(gè)拷貝、修改這份拷貝用以測試特定版本的項目。
o 重用和升級 – 這種方法包含了重用基線(xiàn)腳本、提供一個(gè)此腳本的升級和優(yōu)化用以測試特定版本的項目。這樣做可以最大化的保障可重用性，這也是推薦的方法。
5. 支持腳本版本化 – 測試腳本應該被儲存在類(lèi)似于CVS、微軟的VSS等版本控制工具中。這樣做可以保障在災難發(fā)生的時(shí)候可以被恢復。
6. 將開(kāi)發(fā)和發(fā)布環(huán)境分開(kāi) – 自動(dòng)化應當和其它開(kāi)發(fā)項目同等看待。測試腳本應當在一個(gè)測試環(huán)境下創(chuàng )建和調試。一旦測試腳本測試通過(guò)后唯一該做的就是將它部署到發(fā)布環(huán)境。在緊急發(fā)布版本的情況也同樣適用這種方法。
7. 外部可配置性 – 腳本的可配置項應當被保存在一個(gè)外部文檔中。系統的URL、版本、路徑等都可以被視作可配置項放在外部文件中。這樣做可以使得在不同的環(huán)境中都可以執行測試腳本。需要注意的是外部配置文件的路徑不要寫(xiě)死，如果把它寫(xiě)死了雖然在任何環(huán)境中都還是可以運行腳本，但是每次只能在一個(gè)環(huán)境運行。配置文件的路徑使用相對路徑即可解決這個(gè)問(wèn)題。
8. 自身可配置性 – 理想的測試框架應該是自身可配置的。一旦部署到系統中之后應當不需要再做任何手工配置，腳本應當自動(dòng)配置完成一些必要的設置。
9. 任何對象改動(dòng)引起的變動(dòng)應該是最小的 – 自動(dòng)化過(guò)程中最為常見(jiàn)的問(wèn)題是對象識別的變更。測試框架應該支持可以很容易的來(lái)完成這些修改。這可以通過(guò)將所有的對象識別設置儲存在一個(gè)共享文件來(lái)實(shí)現。這個(gè)文件可以是XML文件、Excel文件、數據庫或者自動(dòng)化所特有的格式。這里有兩種可能的方式來(lái)實(shí)現對象識別設置的方式：
o 靜態(tài)方法 – 這種方法中，所有對象定義都在測試最初被加載到內存中。任何對象定義變更只能通過(guò)停止和重新運行測試來(lái)實(shí)現。
o 動(dòng)態(tài)方法 – 對象定義是通過(guò)需求拉動(dòng)的。這種方式和靜態(tài)方式比較而言顯得較為緩慢。但是對于非常大的腳本而言，并且對象識別需要在運行時(shí)做修正的情況下，動(dòng)態(tài)方法是適用的。
10. 測試執行 – 自動(dòng)化測試框架也許需要滿(mǎn)足以下需求（基于實(shí)際需求）
o 執行單獨的測試用例；
o 批量執行測試用例（一組測試用例）；
o 只執行失敗的測試用例；
o 可以在前一個(gè)（一組）測試用例執行結果的基礎上，執行下一個(gè)（一組）測試用例；
根據實(shí)際需求還會(huì )有許多其他情況。一個(gè)框架可能無(wú)法實(shí)現所有這些需求，但它應具有足夠的靈活性以適應今后此類(lèi)需求。
11. 狀態(tài)監測 - 一個(gè)框架應允許實(shí)時(shí)監控執行狀態(tài)，一旦失敗能夠發(fā)出警報。這樣可以在出現failure之后迅速反饋。
12. 報表 – 不同的系統對報表有不同的需求，有時(shí)候需要一組測試的整體報表，有時(shí)候只需要單個(gè)測試用例級別的測試執行報表。一個(gè)好的測試框架應該有足夠的彈性來(lái)按需支持不同的報表。
13. 發(fā)生更改的時(shí)候對測試工具盡量小的依賴(lài)性 – 一些測試腳本的更改可能只能在打開(kāi)測試工具后，在測試工具中進(jìn)行修改，然后保存。測試腳本應該在沒(méi)有測試工具的情況下也可以對腳本進(jìn)行更改。這樣的實(shí)現可以減少license的購買(mǎi)從而為公司節省開(kāi)支。這樣的實(shí)現還可以讓所有想去修改腳本的人無(wú)需安裝測試工具也可以很方便的對腳本進(jìn)行修改。
14. 方便的調試 – 調試在自動(dòng)化過(guò)程中占據了大量的時(shí)間，因此在調試這個(gè)過(guò)程中需要加以特別的關(guān)注。關(guān)鍵字驅動(dòng)的測試框架因為使用了外部的數據源（比如Excel數據表）去讀取腳本中的關(guān)鍵字和測試過(guò)程，所以較難調試。
15. 日志 - 生成日志是執行的重要組成部分。在一個(gè)測試案例的不同點(diǎn)生成調試信息這是非常重要的。這些信息有助于快速地找到問(wèn)題的范圍，同時(shí)縮短了修改時(shí)間。
16. 易用性 - 該框架應易于學(xué)習和使用。對框架的人員培訓費時(shí)且昂貴。有一個(gè)好文檔的框架更容易理解和使用。
17. 靈活性 - 框架應該足夠的靈活，以適應任何改進(jìn)，而不會(huì )影響已有的測試案例。
18. 性能的影響 – 框架還應考慮對執行性能的影響。一個(gè)復雜的框架會(huì )增加腳本的加載或執行時(shí)間，這一定不是我們所期望的。像緩存技術(shù)，當執行時(shí)編譯所有代碼到單個(gè)庫中等...只要可能都應該用于性能的改善。
19. 框架支持工具 – 開(kāi)發(fā)一些外部工具來(lái)完成任務(wù)，這對框架設計會(huì )有幫助。這是一些例子：
o 從本地文件夾上傳腳本到QC
o 結合庫文件到當前打開(kāi)的腳本
o 同步本地和QC上的腳本文件
20. 編碼標準 - 編碼標準應確保腳本的一致性，可讀性和易于維護。編碼標準應包含下列內容：
o 命名規范（變量、子程序、函數、文件名、腳本名稱(chēng)等），例如i_VarName為整數變量， fn_i_FuncName為返回值是整數的函數；
o 庫、子程序、函數的頭部注釋。這應包含,如版本歷史，創(chuàng )建者，最后修訂者，最后修訂日期，說(shuō)明，參數，示例；
o 對象命名規范。例如txt_FieldName為一個(gè)文本框；
總結
我們應該把自動(dòng)化測試看作是一個(gè)開(kāi)發(fā)項目，而不僅僅是記錄和回放事件。先有一個(gè)良好的框架，再開(kāi)始自動(dòng)化測試，這樣可以確保較低的維護成本。當你在開(kāi)發(fā)一個(gè)框架，進(jìn)行框架的需求分析時(shí)，可以參考本文談到的這些準則。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
