自動化測試: 真的是銀彈？

       沒有一種單純的技術或管理上的進步，能夠獨立地承諾在10年內大幅度地提高軟件的生產率、可靠性和簡潔性。Brooks鼓勵我們將技術和方法視作一種演進手段，而并非革命。將自動化技術引入測試工作時，我傾向于支持相同的觀點。

簡介
Frederick P. Brooks, Jr. 曾在1986年寫過一篇題為《沒有銀彈：軟件工程的根本和次要問題》的文章（No Silver Bullet - Essence and Aclearcase/" target="_blank" >ccidents of Software Engineering）。這篇文章列舉了人們對于軟件工程技術發展的一些期望，并與現實進行了對比。他的論點歸納如下：

沒有一種單純的技術或管理上的進步，能夠獨立地承諾在10年內大幅度地提高軟件的生產率、可靠性和簡潔性

Brooks鼓勵我們將技術和方法視作一種演進手段，而并非革命。將自動化技術引入測試工作時，我傾向于支持相同的觀點。

我與自動化測試產品和解決方案的潛在客戶打交道已有5年時間，其間碰到了許多"銀彈"思維方式。它們總以類似這樣的設想出現：

所有的測試都能夠實現自動化！
既然自動化測試能如此顯著地提高生產率，我們就能以更少的人員完成所有的測試（精減人員）。
自動化測試如此簡單，我們無需任何培訓。
自動化方法將縮減整體測試工作量。
我們無需制訂任何測試方案。
有了自動化測試，測試人員不就成了"過時的"或"多余的"了嗎？
那種耗時的測試設計工作不再必要了。
盡管我不愿打破人們美好的幻想，但總覺得有責任幫助他們理解，實施自動化測試和得到夢寐以求的神兵利器之間的區別。通常這意味著解釋自動化測試的真正含意，和自動化測試工具和解決方案的實際功能。

自動化測試不是銀彈嗎？
正是此意。自動化測試，或者說自動化測試策略及工具的實現，只是測試人員工具箱里的一件利器。注意我強調它是一個工具，位于工具箱中。我有意避免將自動化測試和試員人員等同起來，本來它也無法取代測試人員的地位。盡管如此，自動化測試仍然毫無疑問地具有強大功能，它能在測試效率和徹底性方面使我們獲益匪淺。關鍵在于確定發揮其功效的最佳時機及方式。我們提出另一個問題來具體闡述一下。

有足夠的時間測試每件事情嗎？
我想人們會異口同聲地回答 "沒有！"?？傆懈嗟臇|西可以測試，或者在另一個平臺上或以其他配置再試一次。但是隨著最終期限和產品交付日期的日益迫近，分配給每個測試周期的時間縮短了。那么，軟件開發項目經理和測試團隊如何處理這種情況呢？通常，他們削減軟件發布前每一個測試周期的測試量。您經歷過這種情形嗎？理想情況下需要做一些基于風險的分析，以便決定排隊哪些風險。然而更常見的情況是，測試團隊只是將整個測試周期的注意力集中到驗證已修復的缺陷上。更有甚者，連這樣的縮減之后的測試計劃也沒有足夠時間來完成。

多少產品是在完整測試之后交付的？這種情況我所知不多。開發團隊往往根據其他因素做出是否交付軟件的決定：

時間到了嗎？
預算超了嗎？
資源用盡了嗎？
還有比薩和啤酒嗎？
不幸的是，由于測試工作被任意刪減，開發團隊無法完全清楚地知道產品的總體質量，他們面臨所交付的軟件帶有嚴重問題的風險。借助于自動化測試的力量我們能夠擺脫這種困境嗎？我們接著探討一下。

自動化測試如何幫助我們？
在計劃實施自動化測試之前，您需要理解自動化測試的定義。換句話說，它對您意味著什么？這里有一些我聽到的其他人對自動化測試的描述：

完全無人干預的測試。
測試腳本。
測試工具。
不清楚。
有時人們將自動化測試的概念理解得過于狹窄，只關心由工具或編程產生的測試腳本。實際上自動化一詞包含了更為廣闊的含義?？纯匆粋€Quality Engineering團隊在構建一套自動化測試準則時對自動化測試的這個定義：

在我們的環境中，"自動化"指的是對策略、工具和工件的使用，它增加或減少了手工或人為參與或干預非技巧性、重復或冗長工作的需要。

除該定義之外，準則還為該團隊提供了應用自動化方法的例子。表1列舉了一些。

這個小例子讓您換個角度看待自動化了嗎？現在，定義自動化對于您和您的團隊意味著什么是至關重要的。然后您就可以使用該定義開始構建一套自動化準則，從而團隊中的每個人都可以使用相同的方法、快速評詁一項任務是否適合應用自動化。

創建自動化測試準則
此處列舉了您定義自動化和制訂準則時可以考慮的一些策略和事項：

確定自動化測試的"用武之地"

將所有工作中的特定部分作為應用自動化的候選對象。
從高度冗余的任務或場景開始考慮。
將乏味且人工容易出錯的工作進行自動化。
首先關注開發成熟、理解透徹的用例或場景。
優先選擇應用中相對穩定的部分，而非易變的部分。
通過使用數據驅動的測試技術來提高自動化功效（增加測試覆蓋的深度和廣度）。
指派幾位專家負責自動化，不要讓測試團隊的每個人都做這項工作。
牢記不要追求100%的自動化，手工測試仍然至關重要。
計劃進行更多的測試

將重復的測試自動化，為其他方法的測試贏得更多時間。
增加試探性測試。
增加配置測試。
構建更多的自動化測試。
進行更多的人工測試，特別是在高風險特性方面。
謹慎規劃：將人工測試和自動測試分工，不能全盤自動化。
每一次設計都要設計所有的測試和文檔。如果某項自動化測試無法運行，確保它能夠手工完成。
將自動化視為一種投資

訓練使用者充分利用自動化工具。
構建一個可重用代碼庫。
保持測試模塊化，大小控制在一定范圍內，這樣易于維護。
文檔化測試腳本（代碼），以備校驗和重用。
強化備份過程。
利用源代碼控制。
認識到自動化是一項軟件開發工作，通常需要代碼生成。
逐步實施自動化測試

不要嘗試一天內實現所有測試的自動化。積累經驗，循序漸進。
從整個測試計劃的一小部分開始，逐步添加至自動化測試集合。（即以實際的、受控的方式遞增）
自動化還能為我做什么？
盡管自動化測試需要在前期的策劃和培訓上進行一筆不菲的投資，但確實能從幾個大的方面帶來增益。它能為您帶來如下利益：

更高質量的軟件－因為您能夠花費更少的時間和資源進行更多的測試。
更完備的測試覆蓋的潛力。
更多的時間投入到其他測試活動中，包括：
詳細計劃。
精心地設計測試。
構建更復雜的測試（數據驅動，增加用于條件分支和特殊報告的代碼等）
更多的人工測試，不是更少！
自動化測試還為您提供無形價值，它能給測試人員帶來：

獲取新技能的機會（即建立技能和學習技能的機會）。
在測試中了解更多關于系統的知識的機會，因為自動化能揭示系統內部狀況，如對象屬性和數據。（對系統的更多理解造就更好的測試人員）
現在您已知道什么是自動化測試以及它能勝任哪些工作，我希望您能運用這些知識為您的產品進行更多更好的測試。盡管自動化測試不是銀彈，但它仍不失為一件優秀工具；如果能夠將其應用于適合的工作，將為您帶來巨大收益。

參考資料

您可以參閱本文在 developerWorks 全球站點上的 英文原文。
關于本文部分主題的更多信息，請參閱Cem Kaner的網站上的下列文章。網址：http://www.kaner.com/articles.html

1. "Architectures of Test Automation"

2. "Improving the Maintainability of Automated Test Suites"

3. "Avoiding Shelfware: A Manager's View of Automated GUI Testing"

致謝
感謝Cem Kaner提供參考鏈接中文章。 同樣感謝IBM Rational的Ted Squire，和Satisfice, Inc.的James Bach仔細評閱本文，并在寫作中給予幫助。關于Satisfice及其廣受贊譽的測試講座的更多信息，請訪問www.satisfice.com。

關于作者
Dawn Haynes,技術專員,IBM Rational

原文轉自：http://www.anti-gravitydesign.com