自動化測試框架UFT BASED

自動化測試，一個現在被炒的火熱的詞；各大公司都在嚷嚷著要上自動化測試的專案，都在招聘各種自動化測試人員。。。

本材料對於程式設計基礎較低初學者，在編寫和學習過程中可以接觸到很多旁枝側節的知識，這些都是做好自動化所有需要的知識；對於有一定技術儲備。

本框架不能幫你成為高大上的程式設計大牛，或者自動化測試的行家。但是，它可以引領你邁入自動化測試的領域。

師傅領進門，修行靠個人；一切的一切都還是要靠你自己去多多實踐，不是有一句名言麼？實踐是檢驗真理的唯一標準！

一、自動化測試基礎

手工測試VS自動化測試

手工測試：

手工測試就是由人去一個一個的去執行測試用例，通過鍵盤滑鼠等輸入一些引數，檢視返回結果是否符合預期結果。

自動化測試:

自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程。通常，在設計了測試用例並通過評審之後，由測試人員根據測試用例中描述的規程一步步執行測試，得到實際結果與期望結果的比較。在此過程中，為了節省人力、時間或硬體資源，提高測試效率，便引入了自概念。

自動化測試又可分為：功能自動化測試與效能自動化測試，在本文中我們著重探討功能自動化測試。

什麼樣的專案適合自動化測試

1、任務測試明確，不會頻繁變動

2、比較頻繁的迴歸測試

3、軟體系統介面穩定，變動少

4、需要在多平臺上執行的相同測試案例、組合遍歷型的測試、大量的重複任務

5、軟體維護週期長

6、被測軟體系統開發比較規範，能夠保證系統的可測試性

7、具備大量的自動化測試平臺

8、測試人員具備較強的程式設計能力

UFT簡介

UFT是Unified Functional Testing的簡稱，是一種自動測試工具。

以VBS為內嵌語言。

UFT自動化測試的基本功能包括：

建立測試

檢驗資料

增強測試

執行測試指令碼

分析測試結果

維護測試

UFT工具特點

特點：易於上手，開發簡單，功能強大

注：主流配置都能帶起了（選擇UFT11.5和UFT12.0）

二、自動化測試模型介紹

一個自動化測試框架就是一個整合體系，在這一體系中包含測試功能的函式庫、測試資料來源、測試物件識別標準，以及種可重用的模組。自動化測試框架在發展的過程中經歷了幾個階段，

線性測試

通過錄制或編寫指令碼，一個指令碼完成一個場景（一組完整功能操作），通過對指令碼的回放來進行自動化測試。這是早期進行自動化測試的一種形式。

參見下圖test1和test2例項：

通過上例，我們可以看出：

每一個指令碼都是獨立的，任何一個指令碼檔案拿出來就能單獨執行；當然，缺點也很明顯，用例的開發與維護成本很高。

一個用例對應一個指令碼，假如登陸發生變化，使用者名稱的屬性發生改變，不得不需要對每一個指令碼進行修改，測試用例形成一種規模，我們可能將大量的工作用於指令碼的維護，從而失去自動化的意義。

這種模式下資料和指令碼是混在一起的，如果資料發生變也需要對指令碼進行修改。這種模式下指令碼的沒有可重複使用的概念。

模組化與類庫

我們會清晰的發現在上面的指令碼中，其實有不少內容是重複的；於是我們就考慮能不能把重複的部分寫成一個公共的模組，需要的時候進行呼叫，這樣就大大提高了我們編寫指令碼的效率。

參見下圖：

通過閱讀上面的程式碼發現，我們可以把指令碼中相同的部分程式碼（登入）獨立出來，形成模組或庫。

這樣做有兩方面的優點：

一方面提高了開發效率，不用重複的編寫相同的指令碼；假如，我已經寫好一個登入模組，我後續需要做的就是在需要的地方呼叫，不同重複造輪子。

另一方面方便了程式碼的維護，假如登入模組發生了變化，我只用修改檔案中登入模組的程式碼即可，那麼所有呼叫登入模組的指令碼不用做任何修改。

資料驅動

資料驅動應該是自動化的一個進步；從它的本意來講，資料的改變（更新）驅動自動化的執行，從而引起測試結果的改變。這顯然是一個非常高階的概念和想法。其實，我們可直白的理解成引數化，輸入資料的不同從而引起輸出結果的變化。

參見下面例：

不管我們讀取的是陣列，還是字典、函式，又或者是csv、txt檔案。我們實現了資料與指令碼的分離，換句話說，我們實現了引數化。我們傳一千條資料，通過指令碼的執行，可以返回一千條結果出來。

同樣的指令碼執行不同的資料從而得到了不同的結果，是不是增強的指令碼的複用性呢！

關鍵字驅動

理解了資料驅動，無非是把“資料”換成“關鍵字”，通過關鍵字的改變引起測試結果的改變。

關鍵字驅動用程式設計方式就不太容易表現了。UFT、robotframework等都是以關鍵字驅動為主的自動化工具，因為這類工具主打的易用性，“填表格”式的關鍵字驅動幫我們封裝了很多底層的東西，我們只要考慮三個問題就可以了：我要做什麼？ 對誰做？怎麼做？。

三、自動化框架設計

環境要求

體系結構與驅動邏輯

檔案組織結構

檔案組織結構說明

1. Autotest資料夾,整個工程的最高一級目錄，名稱可以修改。

2. driver資料夾,這個是整個框架的入口，內有Driver.vbs驅動程式、wyz.vbs輔助程式和UFT測試專案資料夾

3. testpro資料夾,用於記錄有哪些專案，是否執行

4. testdata資料夾，用於設計測試用例，給testscript提供資料、期望值等資訊

5. testscript資料夾，存放測試指令碼，全部儲存為vbs檔案。類名對應專案名，對應檔名，一個函式對應一個用例（需和testdata中資訊對應），也可新增其他公共函式

6. library資料夾，按專案名稱分資料夾放置的物件庫檔案

注：testdata和testscript目錄下的內容，是真正需要開發的。

資料組織結構說明

資料組織總結

1、基於把測試設計和指令碼開發分開的思路，設計了testpro和testdata Excel表格。測試設計時，主要是設計testdata中的測試用例資料表格；

2、開發testscript中的測試用例指令碼；

因此，希望儘可能把這些Excel表格做得更易用。所謂的框架，就是把這幾個Excel 表格串起來的東西。

driver 指令碼驅動邏輯

優勢：

指令碼檔案少，並且佔用的空間也少了；

可以使用版本控制工具對單個的資料檔案或者vbs 檔案進行版本控制；

測試設計和指令碼開發解耦；

測試用例和資料的展現更加人性化。

缺點：

異常的捕獲考慮得很少；

日誌只是列印到output或輸出到檔案，不利於檢視。如果把日誌輸出到資料庫，就可以生成相應的測試執行報告；

測試用例的管理太過於簡陋。

注：該框架編寫和學習對於想要學習自動化框架編寫的同學，可以起到一個入門，可以幫助同學理清楚自動化框架設計的思路

以上內容皆為wyz私有版權，轉載請註明出處，如果有同學或者同事進行共同深入的研究，需要相關自動化材料和自動化框架的程式碼，請加QQ:2604947115，我們共同進行探討。