自動化測試: 真的是銀彈？ 沒有一種單純的技術或管理上的進步，可以獨立地承諾在10年內大幅度地提升軟件的生產率、可靠性和簡潔性。Brooks鼓勵咱們將技術和方法視做一種演進手段，而並不是革命。將自動化技術引入測試工做時，我傾向於支持相同的觀點。 簡介 Frederick P. Brooks, Jr. 曾在1986年寫過一篇題爲《沒有銀彈：軟件工程的根本和次要問題》的文章（No Silver Bullet - Essence and Accidents 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 做者：Dawn Haynes 摘自：IBM