自動化測試的概念與做法
工欲善其事，必先利其器 先別急著一頭熱就栽進開發的坑裡
在這之前應該能先知道自動化測試的基本概念與正確作法
對之後能夠建置一套有效、穩定、容易維護的自動化測試架構是很重要低~
來將測試項目分類吧
我們需要執行各種不同類型的測試來確保能交付穩定高品質的軟體應用程式
Brian Marick提出這張測試象限圖依照四個維度將測試工作進行分類
分別是商務導向、技術導向、程式支持度或是為了專案評估
每個區塊依照工作特性來決定可自動化程度
我們這裡可以知道哪些測試工作適合用做自動化完成
右上角的測試方式都屬於手動，是為了要確認我們交付給用戶的程式能符合他們的期待的樣子
驗收測試是確保開發的軟體能符合每個Story的驗收標準
這在Agile開發環境中是相當重要的，驗收測試讓開發者知道我是否已經開發完成
也能讓用戶知道這是我們想要的功能
功能性的驗收測試應該用自動化來完成，有些和capacity, security和performance有關的非功能性測試在市場上也有許多自動化工具能夠達成
與程式和功能特性相關的單元測試，系統測試應該由開發者來完成這些自動化測試程式
Agile自動化測試最佳實踐: 測試金字塔
- 對於走敏捷開發模式的團隊，測試金字塔是一種規劃Test Strategty的理想模式
Developer應該在開發時一併完成unit test, 並在commit時通過這些測試
這是執行速度最快也是金字塔的基礎
component test 使用mock的方式讓我們能單獨測試一部分模組功能
Integration test總是有其價值,只是我們要注意分配數量
這種測試比較不容易debug並且容易被其他模組變動影響執行結果
API Test是最值得開發的項目, 它不但容易開發, 穩定並能提供清楚的資訊
Exploratory Test 是最上層手動測試中特別有價值的測試方式
我們時常遺忘它, 但這卻能讓我們有機會去執行那些沒接觸到的程式碼或邏輯路徑
- 然而實際上我們的自動化測試常會變成這樣...
去推動自動化常常會落入像這種 ice cream cone anti-pattern 模式
這是因為大部分團隊都會專注在UI Level的自動化測試,但這樣的效果通常並不好
這兩種模式的差異在於:
Ice Cream mode想要找出Bug 而Test Pyramid則想要避免Bug出現
越接近UI Level的自動化測試開發需要更多時間與資源的投入少年維特的煩惱: 談自動化測試的困難
連少年維特都有煩惱了 更何況是我們工程獅呢 T_T開始推動與實作UI自動化測試常會遇到很多困難像是...
- 成本高:
- 人員成本高
既要懂框架又要具備程式能力還要熟悉業務邏輯的人才不容易培養
- 環境成本高
建構環境複雜, 安裝設定費時, 還需要教育訓練
維護測試環境需要額外時間與人力
- 人員成本高
- 效果不如預期:
這是阿里巴巴某部門一周的UI 自動化測試失敗原因分析
實際上各種外部或內部因素都可能造成自動化測試無法達到我們預期想要的效果
- 覆蓋率不足
- 無法覆蓋所有分支和邏輯
- 能用一個框架同時覆蓋所有功能點的測試
- 執行時想要檢查每個畫面和節點
- 無法覆蓋所有分支和邏輯
- 及時性不夠快:
- 功能變更頻繁, 維護速度跟不上
- 介面變更頻繁
- 執行速度不夠快
- 功能變更頻繁, 維護速度跟不上
我們在設計架構和測試案例時應該要遵守一些正確的原則與方法...
別擔心! 還是有辦法低: 自動化測試設計原則與方法
- 容易管理:
- 統一規劃測試項目與與組件
- 統一使用版本控制
- 以功能來區分測試案例
- 容易實現:
- 採用分層設計
- 支持多種技術的擴充能力
- 可重複使用的測試組件
- 測試案例專注於業務邏輯
- 維護性高:
- 測試組件與案例分離，區分變化與不變
- 盡量減少測試案例彼此間的依賴(dependency)
- 測試數據容易維護
- 易於定位:
- 減少測試案例複雜度
- 斷言定位的準確性
- 詳細錯誤處理機制
先人的智慧: 常用自動化架構設計模式
- Data Driven Automation Framework
- Keyword Driven Automation Framework
- Modular Automation Framework
- Hybrid Automation Framework
- Behavior Driven Development Framework
Data Driven
當我們要用不同輸入資料測試同一個功能時, 就需要將測試資料與測試邏輯分離
輸入資料通常會以key-value格式來存放
這樣就能依照各種輸入資料來產生測試案例
同時也能與定義好的驗證結果來做交叉比對
Keyword Driven
依照功能將Test case依照下面方式以一個個的Keyword來定義
1. Test Step
2. Test object
3. Action
4. Test Data
Modular Driven
依照物件導向的概念將整個待測應用程式切成多個邏輯上各自獨立的模組區塊
將那些會經常使用的功能和步驟加以模組化, 替每個模組建立測試腳本
這樣一個模組產生變動不會影響到其他模組的運行
讓之後開發能重複使用, 減少時間和錯誤
Hybrid mode
Hybrid 綜合以上三種模式的優點, 可依照需求來設計適合自己產品的測試架構
Behavior Driven Development
以BDD模式設計的架構在上層能以類似一般描述語言的Gherkin sytax來清楚表達每個user story想看到的條件與結果，並將下層的實作加以模組化重複使用
完整的自動化測試架構組成
一個完整的分層式自動化測試架構應該能擁有這些功能
自動化測試 in DevOps
這張圖很清楚的表達出自動化測試在DevOps流程中所扮演的角色:
自動化測試是DevOps不可缺少的一部分
讓自動化測試成為每一段流程的驗收標準
我認為 E2E Automation Test 可適用於
- Test環境的快速驗收(Smoke test)
- Test環境的功能驗證(Regression test)
- Staging環境的驗收項目(Acceptance test)
- Production環境的基本檢查項目(Sanity test)
Comments
Post a Comment