一個好的構建過程
自動化測試的引入在"構建團隊"上加入了一些約束。為了實現自動化測試的高利用率(回歸測試),要求具有一個高的構建頻率。每周僅僅運行自動化的測試不是好的自動化測試的使用率。將回歸測試增加到每天一次將幫助快速的發現新的問題并使開發人員更加容易的發現問題的根源,因為對測試的反饋時間是比較短的(開發人員能夠記住他們昨天做了什么)。
所有權
不同的測試庫的所有權的定義是重要的。一個好的方案會將測試庫的組織劃分為三個級別:
級別 1 - 全局的
這個一個通常的級別。被存儲在這個級別的測試功能能夠被所有的項目訪問。通用的和通常的功能象登陸、創建一個用戶都是這個級別很好的候選者。
級別 2 - 項目
在這個級別的測試功能是與特定的測試項目相關的,但是通常在項目中有用的比一定在項目外是有用的。通常級別 2 是級別 1 的功能的提供者。
級別 3 - 腳本
功能被直接關聯到特定的測試腳本。 I在這個級別中,通常一個測試功能的第一個版本是被開發的。在新的測試腳本的創建期間已有測試功能的重用性被發現,并被移到了級別 2 中。
在這個級別上盡量最小化功能的數量,因為它將增加維護工作量。
還有很多有關測試框架的問題,但是這里所提及的是一些基本的要被解決的問題。
3. 在哪里使用自動化測試
有很多的情況下使用自動化的測試可以降低測試成本。我將盡量的突出在自動化測試中的不同的測試技術
技術 | 描述 | 備注 |
單元測試/組件測試 | 這個測試工作通常是開發人員的職責,很多不同的方法能夠被使用,比如"測試先行",它是一個測試框架,開發人員在編寫代碼前編寫不同的單元測試。當測試通過時,代碼也被完成了。 | 通過使用正式的單元測試,不僅能夠幫助開發人員產出更加穩定的代碼而且能夠是軟件的整體質量更加的好。 |
冒煙測試 | 冒煙測試是一般驗證別測試系統的功能性測試用例的集合。冒煙測試背后的思想是確?;A是可以工作的,以便"大的"測試工作能夠開始。 | 在構建過程能夠確保構建已經為測試準備好時,冒煙測試通常是自動化的運行。 |
功能/集成測試 | 這里測試的工作關注在驗證在不同的組件之間的集成上。 | 這些類型的測試通常是被測試系統的更加復雜測試的基礎,大量的邊緣測試被合并以制造出不同的錯誤處理測試。 |
系統測試 - 用例測試 | 這種測試是通過執行用戶場景模擬真實用戶使用系統以證明系統具有被期望的功能的測試。 | 這里不需要進行自動化的測試。安裝測試、安全性測試通常是有手工完成的,因為系統的環境是恒定不變的。 |
回歸測試 | 回歸測試實際上是重復已經存在的測試。通常如果是手工完成的化,這種測試只在項目的結尾執行執行一到兩次。 | 這里完全有潛力應用自動化的測試。你能夠在每次構建完成后執行自動化的回歸測試,以驗證被測試系統的改變是否影響了系統的其他功能。 |
性能測試 |
性能測試包括以下不同測試形式: - 負載測試 - 壓力測試 - 并發測試 -..... |
如果沒有自動化的測試工具,你將不能執行通過模擬用戶的負載實現的高密集度的性能測試。 |
4. 什么時候使用自動化測試
我對什么時候應該使用自動化測試和什么時候應該使用手工測試進行了一個概要的總結:
使用自動化測試 | 使用手工測試 |
|
|