你的組織為自動化測試做好準備了嗎?(3)

　　如果工具不具備使用內建的對象映射的可能性，那么這個方案對于消除與 GUI 相關的大部分維護成本是優秀的。在一些組織中已經創建了這種方案，并且他們其中的一些已經實現了高度的自動化(60%)，并且他們都得到了巨大的回報。如果測試框架是適當的，我們能夠使用 excel 來生成實際的測試用例。

　　這個級別對于那些按照正規基礎使用用例的組織或者項目來說是非常優秀的。有多少測試用的估計是被需要的，并且當用例適當時需要做的工作也是非常簡單的。你可以集中時間來生成第一個包含被需要的"對象映射"的測試用例(主流程)。依靠被測試應用的復雜程度，通常這會花費大約半天到一天的時間。后續的被需要的每一個測試用例大概會花費 15 到 20 分鐘的時間，因為通常多數的測試用例可以復制已有的測試用例，并對其進行必要的修改，通常這種修改是有限的。動作詞語框架能夠通過使用用例使緊密的并行測試用例的開發變得可能。

　　2.3. 我們不需要培訓!

　　我們所有的人都在某一些方面具有一定的經驗，我們沒有時間能夠花費在使用新工具的培訓上。當一個對自動化工具還不是很熟悉的組織或者項目團隊開始實施自動化測試時，培訓和指導是至關重要的。如果我們允許組織或者項目團隊在沒有關于應該如何做的任何知識的情況下實施自動化的測試，那將肯定會以失敗告終。用于實施自動化測試方案的預算會被超出，測試會被延誤并且更壞的情況是自動化測試將被放棄。組織和項目團隊需要盡量避免一些認識上的缺陷，尤其是自動化測試的維護成本和當測試人員嘗試和確認工具如何工作時產生的挫敗感。你需要確保你的測試過程是適當的 - 如果測試過程是不合理的，引入自動化測試只會給軟件組織或者項目團隊帶來更大的混亂。因此，我建議希望實施自動化測試方案的組織或者項目團隊應該在實施之前建立"訓練營"，并將重點放在培訓測試團隊能夠很好的利用一個原型的項目上。

　　為第一個原型項目制定一個實施計劃，下面包括原型項目的最小化的描述：

　　當先狀態

　　我們希望實現什么 - 建立成功的因素

　　期待的回報(第一次自動化測試工作被期望驗證什么)

　　找到一個"簡單的"測試的痛處并盡力的通過自動化測試解決它，這可以被作為在同一時間上使測試運行在多個平臺上的樣例

　　說明被需要的資源和時間

　　......

　　一開始你就要大聲的說出成功的信心 - 讓人們了解你所展示的進展。這將吸引更多的關注和資源。

　　2.4. 我們必須 100% 的自動化

　　從管理的角度來說，100% 的自動化目標只是一個從理論上可能達到的，但是實際上達到 100% 的自動化的代價是十分昂貴的。

　　一個 40-60% 的利用自動化的程度已經是非常好的了。達到這個級別以上將增加測試相關的維護成本。由于對每一個構建版本的需求變化的復雜度，你將花費更多的時間在變更測試用例上以使他們能夠正確的運行。在這種情況下，通過告知管理層 100% 的自動化目標是相當昂貴的來確立一個合理的期望值才是明智之舉。對于決定自動化一個測試用例的一般規則是這個測試用例必須被運行 4 次以上。這個數字是基于用戶對測試工具有良好的技能并且有一個良好的測試框架的。如果情況不是這樣的化，整個數字能夠是 10-20次或者更高。一個例子，在一個項目中測試人員花費和兩周的時間將手工測試的 23天的任務轉換成了自動化測試的用例。在完成使，項目能夠在 4 個小時在多個平臺上運行相同數量的測試用例。

　　2.5. 測試框架

　　測試框架對于產生成功的測試自動化的適當基礎是重要的。很多考慮必須被解決以使測試自動化更加有效地被使用。重點必須在：

　　維護成本

　　維護成本是成功的使用自動化測試的最重要的問題之一。維護成本直接聯系到前面已經提到過的自動化測試的成熟度。組織或者項目必須至少要在成熟度的 3 級使用高度的測試庫才能使維護和更新測試功能變得容易。

　　測試數據

　　什么樣類型的數據將被使用?要為每一個測試用例生成測試數據還是使用在被測試應用中已有的數據。在很多的情況下一個測試數據被創建了，刪除他們是不可能的。

　　可測試性

　　自動化測試方案能夠有效的測試嗎?例如，被適當命名的對象(不僅僅是索引 Id)。一個簡單的例子是所有的對話框都有相同的 #id 和相同的標題，所不同的僅僅是顯示的文字信息。當測試應該覆蓋多種語言的方案時，對話框的測試就是一個挑戰。

　　測試人員的技能

　　被包括在自動化測試的創建中的人員應該具有什么樣的技能呢?如果他們具有良好的開發背景，那么成熟度 3 級是足夠了。如果他們有很少的或者根本沒有開發的經驗，我們被迫使找到或者培訓一個自動化測試專家的小組，并直接到達成熟度 5 級，在成熟度 5 級測試的創建與實際的測試執行被分離開。

　　一個好的構建過程

　　自動化測試的引入在"構建團隊"上加入了一些約束。為了實現自動化測試的高利用率(回歸測試)，要求具有一個高的構建頻率。每周僅僅運行自動化的測試不是好的自動化測試的使用率。將回歸測試增加到每天一次將幫助快速的發現新的問題并使開發人員更加容易的發現問題的根源，因為對測試的反饋時間是比較短的(開發人員能夠記住他們昨天做了什么)。

　　所有權

　　不同的測試庫的所有權的定義是重要的。一個好的方案會將測試庫的組織劃分為三個級別：

　　級別 1 - 全局的

　　這個一個通常的級別。被存儲在這個級別的測試功能能夠被所有的項目訪問。通用的和通常的功能象登陸、創建一個用戶都是這個級別很好的候選者。

　　級別 2 - 項目

　　在這個級別的測試功能是與特定的測試項目相關的，但是通常在項目中有用的比一定在項目外是有用的。通常級別 2 是級別 1 的功能的提供者。

　　級別 3 - 腳本

　　功能被直接關聯到特定的測試腳本。 I在這個級別中，通常一個測試功能的第一個版本是被開發的。在新的測試腳本的創建期間已有測試功能的重用性被發現，并被移到了級別 2 中。

原文轉自：http://www.kjueaiud.com