你的組織為自動化測試做好準備了嗎？

本文關注于一個實施自動化測試框架的組織的主要方面和影響。本文的意圖是提供一些能夠成功的實施自動化測試的指導方針。

　1. 簡介

本文關注于一個實施自動化測試框架的組織的主要方面和影響。本文的意圖是提供一些能夠成功的實施自動化測試的指導方針。

2. 測試自動化的神話

有很多關于自動化測試的神話。其中的一些是真實的，而其他的一些是不正確的設想，這些不正確的設想會嚴重的威脅到實施自動化測試的成功。本文將向大家介紹幾種我們面臨的主要幾種關于測試自動化的神話：

2.1. 我們在時間上是緊迫的 － 項目已經落后了 － 讓我們使用自動化測試吧！

這種情況將不能成為現實。實際上，正確的思想應該是 － 我們時間急迫 － 我們決不應該使用自動化測試。

如果項目已經陷入到了麻煩之中，不建議實施自動化的功能測試。項目很可能因為需要大量的測試框架的準備和實施會被托跨。我餓建議將重點放在以下的事情上：

• 優化測試的過程。調查并建議在目前工作基礎上的測試方法和過程。建議借鑒 RUP 的相關思想和過程。
• 引進或者使單元/組件測試正式化。這是我們能夠快速獲得受益的很好的方法。如果正式的組件測試被使用，我建議可以使用 Rational PurifyPlus 進行單元或者組件測試。根據我的經驗盡早的使用 Rational PurifyPlus 是非常值得的。在一個引入和 Rational PurifyPlus 的項目中，通常會在組件的級別得到 百分之三十的性能提升。
• 僅僅在項目團隊能夠對 下列問題的回答是"Yes"時：
  　　項目能夠被適當的推延。
  　　存在能夠通過實施自動化測試被達到的精確的目標。
  　　項目具備建立適當的測試框架的必要條件。

那么，你可以在一個時間緊迫的項目中適當的實施測試自動化。但是根據經驗這種情況是很難發生的。

總而言之，我只能說"對不起，銀彈根本不存在"。

2.2. 測試自動化就是捕獲和回放

在過去的日子中，自動化的測試工具只是被看作是一種捕獲和回放的工具。當前這個神話仍然在很多測試人員的思想中。而事實上自動化測試已經遠不止捕獲和回放這么簡單了。按照成熟度自動化的測試可以被劃分為 5 個級別。

2.2.1. 級別 1：捕獲和回放

這是使用自動化測試的最低的級別，同時這并不是自動化測試最有用的使用方式。

好處 自動化的測試腳本能夠被自動的生成，而不需要有任何的編程知識。

　缺點 你會擁有大量的測試腳本，同時當需求胡子和應用發生變化時相應的測試腳本也必須被重新錄制。

　用法 當測試的系統不會發生變化時 － 小規模的自動化。

2.2.2. 級別 2：捕獲、編輯和回放

在這個級別中，你使用自動化的測試工具來捕獲你想要測試的功能。將測試腳本中的任何寫死的測試數據，比如名字、帳號等等，從測試腳本的代碼中完全刪除，并將他們轉換成為變量。

好處 測試腳本開始變得更加的完善和靈活，并且可以大大的減少腳本的數量和維護的工作。

　缺點 需要一定的編知識。頻繁的變化可能會引起"意大利面條式的代碼"，并且變更和維護幾乎是不可能的。

　用法 當進行回歸測試時，被測試的應用有很小的變化，比如僅僅是針對計算的代碼變化，但是沒有關于 GUI 界面的變化。

你能夠使用這種技術通過快速的編制一些測試腳本以檢驗你的想法來探索你的預定的測試設計。當我在沒有任何象需求或者設計模型這樣的文檔的情況下第一次操作一個產品時和我需要獲得一系列內部構建版本的穩定性的第一印象時，我使用過這種技術。通常如果適當的軟件配置管理（SCM）與良好的內建設計相結合時，使用級別 2 的技術已經足夠了。

2.2.3. 級別 3：編程和回放

這個級別是面對多個構建版本的有效使用測試自動化的第一個級別。你需要在實際的投資開始顯現之前確保團隊和客戶對項目的安全感。如果沒有對測試自動化工具的適當的培訓測試人員將不具備到達這個級別的能力。在自動化測試工具中的所有測試功能都必須被很好的理解，并且要掌握測試腳本語言的知識。

好處 你確定了測試腳本的設計。適當的設計是必要的。編碼的習慣必須是適當的。使用與開發中相同的編碼習慣是非常好的。這將開始搭建起測試和開發之間的橋梁。

在項目的早期就可以開始自動化的測試。你能夠在項目的早期就開始進行測試腳本的設計。與開發人員交并調查他們認為可能會存在問題的區域。確保了開發人員關注在獲得能夠被測試的方案上。

　缺點 要求測試人員具有很好的軟件技能，包括設計、開發等。

　用法 大規模的測試套件被開發、執行和維護的專業自動化測試。

級別 3 使你能夠使用自動化測試并構建不同的回歸測試（重用已有的自動化測試用例）。根據我的經驗在看到更多切實的回報之前，為了達到這個級別，有大量的工作和影響項目的活動必須被做。因此快速的建立和證明自動化測試的價值是至關重要的。找到乏味的測試（例如，邊緣測試和特定的功能測試用例是首先進行自動化測試的良好候選者）。首先創建少量的能夠測試一些基本功能（比如，登陸和創建用戶等）的測自動化測試用例。

2.2.4. 級別 4：數據驅動的測試

對于自動化測試來說這是一個專業的測試級別。你現在要利用測試工具提供的所有的測試功能。你擁有一個強大的測試框架，這個測試框架是基于能夠使你根據被測試系統的變化快速創建一個測試腳本的測試功能庫的。維護的成本相對是比較低的。你在你的測試中會使用到大量真實的數據。

好處 你能夠維護和使用良好的并且有效的模擬真實生活中數據的測試數據。

　缺點 軟件開發的技能是基礎，并且需要訪問相關的測試數據。

　用法 大規模的測試套件被開發、執行和維護的專業自動化測試。

級別 4 要求一些非常良好的測試數據。一個測試人員必須要花費一些時間來識別在哪里收集數據和收集哪些數據。使用現實生活中的數據是最基本的以從測試中得到完全的回報。使用適當的數據將為你提供通常僅僅在項目的后期才會發現的或者是有客戶發現的錯誤的能力?，F在你能夠通過使用現實的數據開運行大量的測試。

2.2.5. 級別 5：使用動作詞的測試自動化

這是自動化測試的最高級別。主要的思想是將測試用例從測試工具中分離出來。這個級別要求有一個具有高技能測試人員測小的團隊，這些測試人員能夠將測試工具的非常深層次的知識與他們具備的較深的編程能力結合起來。這個團隊負責在測試工具中生成并維護測試的功能性，能夠使測試工具從外部的來源，比如 excel 表或者數據庫中執行測試用例。這種測試概念最初是由 CMG 開發的。與 CMG 方案相比，其他的可能的開放源碼的方案有被 Carl Nagle 和SAS Institute 開發的 DDE。使用 DDE 的概念，關注點是當在Excel表中創建測試用例的時候，放置使用包括被使用的特定動作詞語的一些類型的模板。執行的過程是從 Excel 表中讀取測試用例，并將測試用例轉換成為測試工具能夠理解的形式，然后使用不同的測試功能來執行測試。

這個概念變得越來越流，因為測試與用例一起使用是非常有用的。

好處 測試用例的設計被從測試工具中分離了出來 － 關注在設計良好的測試用例上。允許快速的測試用例的執行和基于用例的更好的估計。

　缺點 需要一個具有工具技能和開發技能的測試團隊，以提供并維護測試工程（框架）。

　用法 專業的測試自動化將技能的使用最優化的結合起來

如果工具不具備使用內建的對象映射的可能性，那么這個方案對于消除與 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 中。
在這個級別上盡量最小化功能的數量，因為它將增加維護工作量。

還有很多有關測試框架的問題，但是這里所提及的是一些基本的要被解決的問題。

3. 在哪里使用自動化測試

有很多的情況下使用自動化的測試可以降低測試成本。我將盡量的突出在自動化測試中的不同的測試技術

4. 什么時候使用自動化測試

我對什么時候應該使用自動化測試和什么時候應該使用手工測試進行了一個概要的總結：

如果你正在從事自動化測試，那么一定要記住要關注將自動化測試與手工測試結合起來使用。首先，對于自動化測試率的目標是 10/90 （10% 的自動化測試和 90% 的手工測試）。當這些目標都實現了，可以將自動化測試的使用率提高。記住創建自動化測試的測試用例要比創建手工測試的測試用例花費更多的時間。不要將你所有的測試時間都用在自動化的測試用例上。同時也要記住在測試期間對每一個被發現的錯誤都要花費一定的時間去處理。

5. 自動化測試的好處

如果你正在你的組織中引入自動化測試，記住有很多不同的方面被包含了進了。今天在測試工作如何被進行上有很多不同的視圖。為了能夠成功的實施自動化測試你應該提出這些問題：

• 測試覆蓋什么？－ 我們沒有覆蓋什么？
• 由于遺漏的測試我們沒有發現的"bug"會帶來什么樣的成本？
• 由于不好的測試，破壞已有功能性的成本是多少？
• 如果"瑣碎的"測試被每天的運行，對于你的項目意味著什么？
• 如果我們能夠每天向開發人員提供他們最近代碼變更相關的反饋，對項目有怎樣的影響？
• 這些問題都能夠被自動化測試滿足。你必須從自動化測試成熟度的級別 1 或者 級別 2 開始，并開始測量結果。根據我的經驗快速的
• 開發人員反饋并每天運行測試對于向自動化測試成熟度的級別 4或者 級別 5 是非常有好處的。

自動化測試有以下的貢獻：

• 降低風險 － 你知道你測試了什么和沒測試什么
• 測試能在項目的早期開始并隨著時間一直擴展
• 快速的反饋 － 自動化測試用例能夠隨時的運行
• 在多個平臺上的測試能夠同時進行
• 更好的估計 － 你能夠對測試進度和被使用的時間有更好的了解
• 優秀人員的集中 － 你能夠得到一個專家的團隊，并將他們的知識傳播給其他的項目
• 喜悅 -你和你的團隊正獲得著成功

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