本文關注于一個實施自動化測試框架的組織的主要方面和影響。本文的意圖是提供一些能夠成功的實施自動化測試的指導方針。
2. 測試自動化的神話
有很多關于自動化測試的神話。其中的一些是真實的，而其他的一些是不正確的設想，這些不正確的設想會嚴重的威脅到實施自動化測試的成功。本文將向大家介紹幾種我們面臨的主要幾種關于測試自動化的神話：
2.1. 我們在時間上是緊迫的－ 項目已經落后了 － 讓我們使用自動化測試吧！
這種情況將不能成為現實。實際上，正確的思想應該是 － 我們時間急迫 －我們決不應該使用自動化測試。
如果項目已經陷入到了麻煩之中，不建議實施自動化的功能測試。項目很可能因為需要大量的測試框架的準備和實施會被托跨。我餓建議將重點放在以下的事情上：
優化測試的過程。調查并建議在目前工作基礎上的測試方法和過程。建議借鑒 RUP 的相關思想和過程。 引進或者使單元/組件測試正式化。這是我們能夠快速獲得受益的很好的方法。如果正式的組件測試被使用，我建議可以使用 Rational PurifyPlus 進行單元或者組件測試。根據我的經驗盡早的使用 Rational PurifyPlus 是非常值得的。在一個引入和 Rational PurifyPlus 的項目中，通常會在組件的級別得到百分之三十的性能提升。 僅僅在項目團隊能夠對 下列問題的回答是“Yes”時：�。�1）項目能夠被適當的推延。
�。�2）存在能夠通過實施自動化測試被達到的精確的目標。
�。�3）項目具備建立適當的測試框架的必要條件。
那么，你可以在一個時間緊迫的項目中適當的實施測試自動化。但是根據經驗這種情況是很難發生的。
總而言之，我只能說“對不起，銀彈根本不存在”。
2.2.測試自動化就是捕獲和回放
在過去的日子中，自動化的測試工具只是被看作是一種捕獲和回放的工具。當前這個神話仍然在很多測試人員的思想中。而事實上自動化測試已經遠不止捕獲和回放這么簡單了。按照成熟度自動化的測試可以被劃分為 5 個級別。
2.2.1. 級別 1：捕獲和回放
這是使用自動化測試的最低的級別，同時這并不是自動化測試最有用的使用方式。
好處
自動化的測試腳本能夠被自動的生成，而不需要有任何的編程知識。
缺點
你會擁有大量的測試腳本，同時當需求胡子和應用發生變化時相應的測試腳本也必須被重新錄制。
用法
當測試的系統不會發生變化時 － 小規模的自動化。
2.2.2. 級別 2：捕獲、編輯和回放
在這個級別中，你使用自動化的測試工具來捕獲你想要測試的功能。將測試腳本中的任何寫死的測試數據，比如名字、帳號等等，從測試腳本的代碼中完全刪除，并將他們轉換成為變量。
好處
測試腳本開始變得更加的完善和靈活，并且可以大大的減少腳本的數量和維護的工作。
缺點
需要一定的編知識。頻繁的變化可能會引起“意大利面條式的代碼”，并且變更和維護幾乎是不可能的。
用法
當進行回歸測試時，被測試的應用有很小的變化，比如僅僅是針對計算的代碼變化，但是沒有關于 GUI 界面的變化。
你能夠使用這種技術通過快速的編制一些測試腳本以檢驗你的想法來探索你的預定的測試設計。當我在沒有任何象需求或者設計模型這樣的文檔的情況下第一次操作一個產品時和我需要獲得一系列內部構建版本的穩定性的第一印象時，我使用過這種技術。通常如果適當的軟件配置管理（SCM）與良好的內建設計相結合時，使用級別 2 的技術已經足夠了。
2.2.3. 級別 3：編程和回放
這個級別是面對多個構建版本的有效使用測試自動化的第一個級別。你需要在實際的投資開始顯現之前確保團隊和客戶對項目的安全感。如果沒有對測試自動化工具的適當的培訓測試人員將不具備到達這個級別的能力。在自動化測試工具中的所有測試功能都必須被很好的理解，并且要掌握測試腳本語言的知識。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
