沒有一種單純的技術或管理上的進步,能夠獨立地承諾在10年內大幅度地提高軟件的生產率、可靠性和簡潔性。Brooks鼓勵我們將技術和方法視作一種演進手段,而并非革命。將自動化技術引入測試工作時,我傾向于支持相同的觀點。
簡介
Frederick P. Brooks, Jr. 曾在1986年寫過一篇題為《沒有銀彈:軟件工程的根本和次要問題》的文章(No Silver Bullet - Essence and Accidents of Software Engineering)。這篇文章列舉了人們對于軟件工程技術發展的一些期望,并與現實進行了對比。他的論點歸納如下:
沒有一種單純的技術或管理上的進步,能夠獨立地承諾在10年內大幅度地提高軟件的生產率、可靠性和簡潔性
Brooks鼓勵我們將技術和方法視作一種演進手段,而并非革命。將自動化技術引入測試工作時,我傾向于支持相同的觀點。
我與自動化測試產品和解決方案的潛在客戶打交道已有5年時間,其間碰到了許多"銀彈"思維方式。它們總以類似這樣的設想出現:
所有的測試都能夠實現自動化!
既然自動化測試能如此顯著地提高生產率,我們就能以更少的人員完成所有的測試(精減人員)。
自動化測試如此簡單,我們無需任何培訓。
自動化方法將縮減整體測試工作量。
我們無需制訂任何測試方案。
有了自動化測試,測試人員不就成了"過時的"或"多余的"了嗎?
那種耗時的測試設計工作不再必要了。
盡管我不愿打破人們美好的幻想,但總覺得有責任幫助他們理解,實施自動化測試和得到夢寐以求的神兵利器之間的區別。通常這意味著解釋自動化測試的真正含意,和自動化測試工具和解決方案的實際功能。
自動化測試不是銀彈嗎?
正是此意。自動化測試,或者說自動化測試策略及工具的實現,只是測試人員工具箱里的一件利器。注意我強調它是一個工具,位于工具箱中。我有意避免將自動化測試和試員人員等同起來,本來它也無法取代測試人員的地位。盡管如此,自動化測試仍然毫無疑問地具有強大功能,它能在測試效率和徹底性方面使我們獲益匪淺。關鍵在于確定發揮其功效的最佳時機及方式。我們提出另一個問題來具體闡述一下。
有足夠的時間測試每件事情嗎?
我想人們會異口同聲地回答 "沒有!"??傆懈嗟臇|西可以測試,或者在另一個平臺上或以其他配置再試一次。但是隨著最終期限和產品交付日期的日益迫近,分配給每個測試周期的時間縮短了。那么,軟件開發項目經理和測試團隊如何處理這種情況呢?通常,他們削減軟件發布前每一個測試周期的測試量。您經歷過這種情形嗎?理想情況下需要做一些基于風險的分析,以便決定排隊哪些風險。然而更常見的情況是,測試團隊只是將整個測試周期的注意力集中到驗證已修復的缺陷上。更有甚者,連這樣的縮減之后的測試計劃也沒有足夠時間來完成。
多少產品是在完整測試之后交付的?這種情況我所知不多。開發團隊往往根據其他因素做出是否交付軟件的決定:
時間到了嗎?
預算超了嗎?
資源用盡了嗎?
還有比薩和啤酒嗎?
不幸的是,由于測試工作被任意刪減,開發團隊無法完全清楚地知道產品的總體質量,他們面臨所交付的軟件帶有嚴重問題的風險。借助于自動化測試的力量我們能夠擺脫這種困境嗎?我們接著探討一下。
自動化測試如何幫助我們?
在計劃實施自動化測試之前,您需要理解自動化測試的定義。換句話說,它對您意味著什么?這里有一些我聽到的其他人對自動化測試的描述:
完全無人干預的測試。
測試腳本。
測試工具。
不清楚。
有時人們將自動化測試的概念理解得過于狹窄,只關心由工具或編程產生的測試腳本。實際上自動化一詞包含了更為廣闊的含義??纯匆粋€Quality Engineering團隊在構建一套自動化測試準則時對自動化測試的這個定義:
在我們的環境中,"自動化"指的是對策略、工具和工件的使用,它增加或減少了手工或人為參與或干預非技巧性、重復或冗長工作的需要。
除該定義之外,準則還為該團隊提供了應用自動化方法的例子。表1列舉了一些。
原文轉自:http://www.uml.org.cn/Test/200502013.htm