自動化測試框架與模型

一個自動化測試框架就是一個整合體系，在這一體系中包含測試功能的函式庫、測試資料來源、測試物件識別標準，以及種可重用的模組。 自動化測試框架在發展的過程中經歷了幾個階段，模組驅動測試、資料驅動測試、物件驅動測試。 自動化測試模型是自動化測試架構的基礎。 自動化測試的發展過程中，不斷有新的模型（概念）被提出，瞭解和使用這些自動化模型將有助構建一個靈活可維護性的自動化架構。 自動化測試的幾種不同的模型，並非後者淘汰前者的關係； 在實施自動化更多的是以需求為出發點，混合使用，目的是解決問題，使指令碼更易於開發與維護；     線性測試 --- 早期自動化測試的一種形式

• 通過錄制或編寫指令碼，一個指令碼完成一個場景（一組完整功能操作） ，通過對指令碼的回放來進行自動化測試；
• 優勢就是每一個指令碼都是獨立的，任何一個指令碼檔案拿出來就能單獨執行；
• 缺點也很明顯，資料和指令碼是混在一起，指令碼無法重複使用，導致用例的開發與維護成本很高；

模組化與類庫

• 把指令碼中重複使用的部分程式碼獨立出來，形成公共的模組或庫，需要的時候進行呼叫；
• 優點：提高了開發效率，不用重複的編寫相同的指令碼，方便了程式碼的維護，程式碼的更改限制在模組之內；

資料驅動

• 資料的改變（更新）驅動測試自動化的執行，從而引起測試結果的改變；
• 可以直白地理解成“輸入資料的不同從而引起輸出結果的變化”；
• 優點是實現了資料與指令碼的分離（引數化），增強的指令碼的複用性，在開發層面，易於實現；

關鍵字驅動

• 理解了資料驅動，無非是把“資料”換成“關鍵字”，通過關鍵字的改變引起測試結果的改變；
• 獨立以程式設計方式實現關鍵字驅動似乎不太容易，一般是利用現有工具和框架；
• 在QTP、robot framework 等此型別的測試工具中， “填表格”式的關鍵字驅動封裝了很多底層的東西，易用性強；
• 測試人員只要考慮三個問題：要做什麼？ 對誰做？怎麼做？

 

簡要對比手工測試用例與自動化測試用例

• 較好的異常處理能力，能通過人為的邏輯判斷校驗當前步驟的功能實現正確與否。
• 人工執行用例具有一定的步驟跳躍性。
• 人工測試步步跟蹤，能夠細緻的定位問題。
• 主要用來發現功能缺陷

自動化測試用例

• 執行物件是指令碼，任何一個判斷都需要編碼定義。
• 用例步驟之間關聯性強。
• 主要用來保證產品主體功能正確完整和讓測試人員從繁瑣重複的工作中解脫出來。
• 目前自動化測試階段定位在冒煙測試和迴歸測試

兩者之間的關係 自動化測試替代不了手工測試，目的僅僅在於讓測試人員從繁瑣重複的機械式測試過程解脫出來，把時間和精力突入到更有價值的地方，從而挖掘更多的產品缺陷。 目前自動化測試更多的時候是定位在冒煙測試和迴歸測試；

• 冒煙測試執行的是主體功能點的用例
• 迴歸測試執行全部或部分的測試用例

 

自動化測試用例選型注意事項

1、 不是所有的手工用例都要轉為自動化測試用例。 2、 考慮到指令碼開發的成本，不要選擇流程太複雜的用例。如果有必要，可以考慮把流程拆分多個用例來實現指令碼。 3、 選擇的用例最好可以構建成場景。例如一個功能模組，分 n 個用例，這 n 個用例使用同一個場景。這樣的好處在於方便構建關鍵字測試模型。 4、 選擇的用例可以帶有目的性，例如這部分用例是用例做冒煙測試，那部分是迴歸測試等，當然會存在重疊的關係。如果當前用例不能滿足需求，那麼唯有修改用例來適應指令碼和需求。 5、 選取的用例可以是你認為是重複執行，很繁瑣的部分，例如欄位驗證，提示資訊驗證這類。這部分適用迴歸測試。 6、 選取的用例可以是主體流程，這部分適用冒煙測試。 7、 自動化測試也可以用來做配置檢查，資料庫檢查。這些可能超越了手工用例，但是也算用例拓展的一部分。專案負責人可以有選擇地增加。 8、 如果平時在手工測試時，需要構造一些複雜資料，或重複一些簡單機械式動作，告訴自動化指令碼，讓他來幫你。或許你的效率因此又提高了  

編寫自動化測試用例的幾個原則

1、一個指令碼是一個完整的場景 2、一個指令碼指令碼只驗證一個功能點 3、儘量只做功能中正向邏輯的驗證，不要考慮太多逆向邏輯的驗證，       逆向邏輯的情況很多，驗證一方面比較複雜，需要編寫大量的指令碼，       另一方面自動化指令碼本身比較脆弱，很多非正常的邏輯的驗證能力不強。 （遵循使用者正常使用原則編寫指令碼即可） 4、指令碼之間不要產生關聯性，也就是說編寫的每一個指令碼都是獨立的，不能依賴或影響其他指令碼。 5、如果對資料進行了修改，需要對資料進行還原。 6、在整個指令碼中只對驗證點進行驗證，不要對整個指令碼每一步都做驗證。    

---