Testing - 軟件測試知識梳理 - 自動化測試

軟件開發的過程是一個持續集成和改進的過程，而每一次的改進均可能引進新bug,所以當軟件的一部，或者所有修改時，都須要對軟件產品從新進行測試。
其目的是要驗證修改後的產品是符合需求的，而當沒有自動化測試代碼時，每每會因爲各類各樣的緣由，迴歸不充分，致使bug遺漏。

自動化測試模型

一個自動化測試框架就是一個集成體系，在這一體系中包含測試功能的函數庫、測試數據源、測試對象識別標準，以及種可重用的模塊。
自動化測試框架在發展的過程當中，不斷有新的模型（概念）被提出，目前經歷了幾個階段:模塊驅動測試、數據驅動測試、對象驅動測試。
自動化測試模型是自動化測試架構的基礎。

線性測試

經過錄制或編寫腳本，一個腳本完成一個場景（一組完整功能操做） ，經過對腳本的回放來進行自動化測試；
優點就是每個腳本都是獨立的，任何一個腳本文件拿出來就能單獨運行；
缺點也很明顯，用例的開發與維護成本很高；
這種模式下數據和腳本是混在一塊兒的，若是數據發生變也須要對腳本進行修改。這種模式下的腳本沒有可重複使用的概念；

模塊化與類庫

把腳本中重複使用的部分代碼獨立出來，造成公共的模塊或庫，須要的時候進行調用；
優勢：提升了開發效率，不用重複的編寫相同的腳本；方便了代碼的維護，代碼的更改限制在模塊以內；

數據驅動

數據的改變（更新）驅動測試自動化的執行，從而引發測試結果的改變；
能夠直白地理解成「輸入數據的不一樣從而引發輸出結果的變化」；
優勢是實現了數據與腳本的分離（參數化），加強的腳本的複用性；
在開發層面，易於實現；

關鍵字驅動

理解了數據驅動，無非是把「數據」換成「關鍵字」，經過關鍵字的改變引發測試結果的改變；
獨立以編程方式實現關鍵字驅動彷佛不太容易，通常是利用現有工具和框架；
在QTP、robot framework 等此類型的測試工具中， 「填表格」式的關鍵字驅動封裝了不少底層的東西，易用性強；
測試人員只要考慮三個問題：要作什麼？ 對誰作？怎麼作？

自動化測試用例

自動化測試用例	手工測試用例
執行對象是腳本，任何一個判斷都須要編碼定義。	較好的異常處理能力，能經過人爲的邏輯判斷校驗當前步驟的功能實現正確與否
用例步驟之間關聯性強。	人工執行用例具備必定的步驟跳躍性。
主要用來保證產品主體功能正確完整和讓測試人員從繁瑣重複的工做中解脫出來。	人工測試步步跟蹤，可以細緻的定位問題。
主要定位在冒煙測試和迴歸測試	主要用來發現功能缺陷

自動化測試替代不了手工測試，目的僅僅在於讓測試人員從繁瑣重複的機械式測試過程解脫出來，把時間和精力突入到更有價值的地方，從而挖掘更多的產品缺陷。

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

自動化測試用例設計

一些注意事項：

1. 不是全部的手工用例都要轉爲自動化測試用例。
2. 考慮到腳本開發的成本，不要選擇流程太複雜的用例。若是有必要，能夠考慮把流程拆分多個用例來實現腳本。
3. 選擇的用例最好能夠構建成場景。例如一個功能模塊，分 n 個用例，這 n 個用例使用同一個場景。這樣的好處在於方便構建關鍵字測試模型。
4. 選擇的用例能夠帶有目的性，例如這部分用例是用例作冒煙測試，那部分是迴歸測試等，固然會存在重疊的關係。若是當前用例不能知足需求，那麼惟有修改用例來適應腳本和需求。
5. 選取的用例能夠是你認爲是重複執行，很繁瑣的部分，例如字段驗證，提示信息驗證這類。這部分適用迴歸測試。
6. 選取的用例能夠是主體流程，這部分適用冒煙測試。
7. 自動化測試也能夠用來作配置檢查，數據庫檢查。這些可能超越了手工用例，可是也算用例拓展的一部分。項目負責人能夠有選擇地增長。
8. 若是平時在手工測試時，須要構造一些複雜數據，或重複一些簡單機械式動做，告訴自動化腳本，讓他來幫你。或許你的效率所以又提升了

一些原則：

• 一個腳本是一個完整的場景
• 一個腳本只驗證一個功能點
• 遵循用戶正常使用原則編寫腳本，儘可能只作功能中正向邏輯的驗證。不要考慮太多逆向邏輯的驗證（逆向邏輯的狀況會不少，須要編寫大量的腳本，並且非正常的邏輯難以被自動化腳本所驗證）
• 在整個腳本中只對驗證點進行驗證，不要對整個腳本每一步都作驗證。
• 若是對數據進行了修改，須要對數據進行還原。
• 腳本之間不產生關聯性，也就是說編寫的每個腳本都是獨立的，不能依賴或影響其餘腳本。

軟件過程自動化

• 構建自動化：自動化從各個模塊的源碼構建組裝成一個完整的產品
• 測試自動化：構建前自動完成相應的測試工做
• 部署自動化：對於經過測試的構建好的產品，作好成品測試後，自動化部署到生產服務器
• 自動化場合選取：儘可能對穩定的對象作自動化，如API接口；GUI不建議使用自動化，投資回報比過低，變動大
• 自動化比例：基於穩定的測試環境和測試計劃；在效率和質量上尋求平衡點

自動化測試的實施

適合作自動化測試的項目

• 軟件需求變更不頻繁
  測試腳本的穩定性決定了自動化測試的維護成本。
  若是軟件需求變更過於頻繁，測試人員須要根據變更的需求來更新測試用例以及相關的測試腳本。
  而腳本的維護自己就是一個代碼開發的過程，須要修改、調試，必要的時候還要修改自動化測試的框架，若是所花費的成本不低於利用其節省的測試成本，那麼自動化測試即是失敗的。
  項目中的某些模塊相對穩定，而某些模塊需求變更性很大。咱們即可對相對穩定的模塊進行自動化測試，而變更較大的還是用手工測試。

• 項目週期較長
  自動化測試需求的肯定、框架的設計、腳本的編寫與調試，這樣的過程自己就是一個測試軟件的開發過程，須要較長的時間來完成。
  若是項目的週期比較短，沒有足夠的時間去支持這樣一個過程，那麼自動化測試便成爲笑談。

• 自動化測試腳本可重複使用
  所測試的項目之間是否很大的差別性（如C/S系統和B/S系統的差別）；
  所選擇的測試工具是否適應這種差別；
  測試人員是否有能力開發出適應這種差別的自動化測試框架。

不一樣階段對應的自動化測試

• 單元測試
  關注代碼的實現邏輯，例如一個if 分支或一個for循環的實現；
  利用相應的單元測試框架，幾乎全部的主流語言，都會有其對應的單元測試框架。

• 集成、接口測試
  關注函數、類（方法）所提供的接口是否可靠。

• UI層的功能測試
  經過相應的自動化測試工具來模擬UI層的功能測試，從而解放重複的勞動。

自動化測試應該側重於單元測試與接口測試。而後有選擇有必要地經過自動化方式「部分解放」UI層的重複勞動。
三種測試的比例要根據實際的項目需求來劃分。
以google爲例，70%的投入爲單元測試，20%爲集成、接口測試，10% 爲UI層的自動化測試（《google 測試之道》）。

參考信息

• 聊聊自動化測試框架