通過有效的手工測試向測試自動化推進

　　本文來自于 Rational Edge：作為邁向開發生命周期一部分的軟件自動化測試的第一步，測試團隊可以利用 IBM Rational Manual Tester 來調整并組織他們使用最頻繁的測試流，然后用 IBM Rational Functional Tester 將這些實踐自動化。本文闡明了必要的步驟和好處。

　　現代軟件開發的快速節奏給測試團隊帶來了極大的難題。在線的軟件更新和頻繁的版本周期為測試自動化工作生成了“移動的目標”。

　　沒有逾越簡單記錄或回放自動化測試的企業不久將了解到所記錄的測試腳本將在一些被測軟件的項目迭代中廢棄。從歷史觀點上看，成熟的測試企業試圖通過大力投入自動化框架或關鍵字驅動方法來緩解該問題。他們期望該方法可以隨時間推移給投資帶來回報。然而，在今天的市場中，很少的測試企業可以承受將他們大部分高級團隊成員分配去建立很少能立即獲得回報的框架。

　　本文概括了 IBM 推薦的解決測試自動化難題的方法，并且了解了大多數測試首先是手動完成的。IBM Rational Manual Tester 迅速地增加了人工測試的效力。當書寫人工測試腳本時，它還鼓勵所有技能水平的測試人員通過拖拽和復制粘貼來建立鏈接的內容。Manual Tester 的復用視圖中的此鏈接的內容允許測試團隊首先集中于將最頻繁的重復流自動化。IBM 的方法加速了投資回報以及實現關鍵字驅動測試的好處，同時，它提供了更好的測試腳本文檔。

　　為了使用 Manual Tester 更容易地組織測試內容，我們將查看一個最佳實踐方案。一旦組織完成了，測試內容就可以準備由 IBM Rational Functional Tester 進行自動化了。此種由 Manual Tester 開始的模塊化方法減少了人工和自動測試的維護成本。通過采用此種測試自動化的增量且迭代的方法，您將從人工測試工作中得到立即的投資回報，而同時將您的測試團隊推向可靠的自動化實踐。

　　不投入框架成本但能獲得框架的益處

　　測試自動化專家經常為支持跨多個在測軟件版本的自動化宣稱框架的好處。然而，這些好處出自對建立框架的巨大前期投資的代價。與其重訪對前期投資的不同業務情況，在沒有前期的框架成本而將測試企業推向框架利益時，讓我們考慮人工測試如何立即地有效實現投資回報。

　　我們可以將自動框架的本質提出一些核心思想，最重要的是：1) 數據驅動測試、2) 從測試腳本中提取用戶界面細節，以及 3) 重復流的復用。支持前兩個思想的工具不是新的，所以我們將簡要地說明 IBM Rational 工具如何實現這些。然而，缺乏對第三種思想的可達到的解決方案已經阻止大多數非開發人員的測試人員不能完成可以忍受的測試自動化。我們將在剩下的文章中介紹重要的思想“重復流的復用。”我們將描述測試企業如何通過采用 IBM 的經過有效的人工測試推進測試自動化的方法，不花費框架成本來獲得框架的好處。

　　數據驅動測試

　　人工測試經常要求測試人員向被測應用程序中輸入數據并驗證結果信息與期望值匹配。如果測試人員不注意地輸入了錯誤的數據或漏看了不匹配數據，測試結果就無效了。通過為測試人員將數據輸入和數據驗證過程自動化，IBM Rational Manual Tester 減少了人的錯誤。

　　測試人員經常需要用不同的數據多次執行同樣的事務處理。IBM Rational Functional Tester 的數據驅動測試向導使自動化該工作變得簡單。使用類似電子表格的數據編輯器，測試人員創建或引入定制的數據集，在回放的過程中插入到腳本中。

　　Manual Tester 和 Functional Tester 在不需要構建單獨的框架基礎結構的情況下交付數據驅動測試。

　　從測試腳本中提取用戶界面細節

　　在人工測試人員記錄測試腳本時，Functional Tester 自動地創建用戶界面細節的對象地圖。該對象地圖存儲著當測試在方便的地方執行過程中所需的信息。改變現有測試界面細節不再需要測試人員修改每個測試腳本。測試人員可以在一處進行修改，因為所有自動的腳本都參照此集中的對象地圖。

　　Functional Tester 由其即將注專利的 ScriptAssure™ 技術進一步推進。ScriptAssure 是一個匹配系統，在為改變的用戶界面細節而定制的參數中尋找最合理的匹配。該功能使測試腳本在一次次的普通的用戶界面修改中得到保護。

　　可重復流的復用

　　測試是乏味且重復的。測試團隊為已知的軟件項目書寫并執行成百甚至上千的測試腳本文檔。當開發人員改變在測軟件時，測試人員就必須修改這些文檔。這些文檔，以及后繼的自動記錄，有許多共同的流程，包括：

　　建立被測的應用程序(例如，啟動，登錄)

　　填寫表單(例如，創建客戶賬戶)

　　導航到應用程序中的具體位置(例如，導航到訂單輸入屏)

　　執行公共的驗證(例如，數據庫正確地表現事務了嗎?)

　　超過應用程序功能的期望值或界限(例如，當輸入無效的信用卡號時，恰當的錯誤處理啟動了嗎?)

　　數據驅動測試腳本的一個子流程(例如，登錄并為五十個不同用戶賬戶執行相同的事務)

　　執行高階的業務流，包括那些構成其他可重復流的內容(例如，下訂單，賣股票)

　　內容副本問題

　　大部分測試人員在他們許多的測試腳本間重寫或復制粘貼這些可重復的流。記錄或回放誤導許多測試人員使用自動化來分別地重復記錄可重復流的每個實例。兩種方法都會導致內容副本。

　　測試腳本中的內容副本是隱伏的，因為軟件變更需要測試人員修改可重復流出現的每個腳本。從維護適當的文檔到確?？芍貜偷那乙恢碌臏y試工作，該開銷阻礙了測試團隊。維護此復制的內容是乏味的且增加人出錯誤的風險。這個根本的原因使測試團隊不能在多重軟件版本中維持自動化。

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