探索性測試并不是不使用工具的測試

　　人們經常會明確地區分“自動化”測試和“探索性”測試。這就如同明確區分“紅色”轎車和“家庭型”轎車一樣存在弊端。之所以這么說，是因為“紅色”(指一種顏色) 和“家庭型”(指某種目的概念) 是正交類型。一輛轎車，無論其用途是什么，都可以是任何一種或其他顏色;反之，無論其是什么顏色，都可以用于特定的用途。測試，無論是不是探索性測試，都可以或多或少地使用一些工具。測試，無論是否需要使用工具，都可以是高度腳本化測試或是高度探索性測試。

　　“探索性”測試也不是“手工”測試。無論怎樣，“手工”都不是一個令人滿意的形容軟件測試的詞匯。當你在測試時，其實并不是用手來做測試，這就好像當你在騎自行車時，并不是用腳來推動自行車前進一樣。實際上，是人的“大腦”在做測試;手，最多只是提供了一種手段來完成輸入以及與正在測試的事情進行交互而已。從是否使用工具或機器的意義上講，甚至“手工”測試也不是手動的。在測試時，你確實還是在使用計算機的，難道不是嗎?

　　(很好，大多數情況下如此，雖然并不總是這樣。如果你是在評審需求，規格說明書，代碼或者文檔，雖然你可能只是在看文件，但實際上你仍是在測試。一個思考實驗或者一次關于產品的討論，都可以是一種測試;因為您是在質疑一些東西以便對其進行評估，以一種隨意的方式把一些想法與其他想法進行對立和比較。你在評審時，是不是在用筆對正在閱讀的資料做批注?有沒有用記事本來記錄自己的觀察結果?有沒有在文檔的重要位置粘便簽?如果你有這樣做，那么你就是在使用工具了，即便這些工具的技術含量可能比較低。)

　　一提到測試自動化，有些人就會聯想到一個敲擊虛擬鍵盤的機器人，感覺這個機器人比人類更快速、更可靠、更精準。這無疑是測試自動化的一種可能的概念，但卻是非常局限的。對于測試自動化的傳統觀點認為，自動化主要集中在執行檢查，但這并不是自動化應用于測試的唯一方式。

　　在“快速軟件測試類別”中，James Bach 和我建議了一個更為寬泛的測試自動化觀點，即使用任何可能的工具來支持測試。這有助于使我們對以下觀點保持一種開放的心態：機器可以幫助我們完成幾乎任何的單一形態的、重復性的、非智能的測試方面，這樣我們才能夠將時間和精力集中在多形態的、可變的、智能的測試方面。探索是一項多形態的活動，但它可以包括單一形態的活動，且需要后者支持。Cem Kaner 和 Doug Hoffman 采取了類似的方法：探索性測試自動化是指“支持學習被測軟件質量的新信息的計算機輔助測試。”學習新信息是探索性測試的一個特征，它通常更多地強調變化而不是重復。

　　這就是說，即使你是在用高度探索性的方法，也可以有機械化重復的一席之地，例如當測試的重復方面是為了支持發現一些新的或意外的東西的時候。關鍵不在于你是否將活動機械化。關鍵在于當活動結束時發生了什么。一項活動的結果越無法提示后續測試，那么這個方法就越是腳本化的。如果重復是能夠立即對自身產生反饋的學習回路 (一個包括探索、發現、調查和理解的循環) 的一部分，那么這個方法就是探索性的。James 還發布了很多關于重復測試的動機，每一個 (“失效或無差異”可能例外) 都與探索完全相符且十分匹配。

　　對于部分不需要人類判斷或智慧的行為而言，使用工具可以比人類執行的更好。人性甚至可能妨礙得到理想的結果。例如，當你對產品一些方面的探索建立在統計分析的基礎上，而隨機選擇是測試設計的一部分時，就很有必要記得如果要人去生成隨機數，那將是非常糟糕的。即使人們相信他們是在隨機選擇數字，也會有潛在的 (且通常是相當無意識的) 模式和偏倚在預示著他們的選擇。這時候，如果你想生成隨機數，工具可以幫你。

　　工具可以在很多其他方面支持探索：數據生成;系統配置;模擬;記錄和視頻捕獲;檢查系統內部狀態的調查;檢測產品中特定類型的錯誤條件，或生成類似真實的結果以供比較的測試判定準則;數據集的可視化;要觀察的關鍵要素;關系，或定時，測試活動的記錄和報告。

　　幾年前，我曾經在一家銀行做柜員機工作站應用程序的測試 (我在如何降低軟件測試成本一書中曾提及)。當時，在國內交易領域工作的其他測試人員在工作時仍然依賴于腳本，且該腳本包含大量令人痛苦的，繁瑣而明晰的步驟及觀察結果。(腳本帶有截屏作為補充，但文字和圖像并不總是一致，這是痛苦產生的部分根源。)我的測試任務涉及外匯，且我接受的測試工作是沒有腳本的，即在很大程度上是自定義的。為了快速地學習這個應用程序，我不得不去探索，但這絕不意味著我不使用工具。相反，事實上在那個環境下，Excel 是我手邊最方便最強大的工具。我使用Excel (及其嵌入式 Visual Basic for Applications) 來執行以下任務：

　　· 維護和更新 (一個擊鍵) 規模巨大的貨幣、匯率、交易類型表

　　· 通過正則表達式解析來訪問表中相應的條目

　　· 在測試環境下模仿應用的業務規則

　　· 通過交易顯示預期的資金流向

　　· 為顯著的測試結果和測試場景添加可視標記

　　· 使用比較算法，提供清晰的結果以方便將產品的結果進行比較

　　· 幫助對測試理念進行非?？斓脑u估

　　· 創建客戶數據表，這樣我就可以使用各種人物角色進行測試

　　· 加速我對于產品和測試空間的理解

　　· 提升我關于布爾代數及其在算法中的使用的學習

　　· 記錄我的工作并為我的客戶闡述成果

　　· 在必要時進行快速計算

　　· 幫助我發現更多的實際問題，總數超過其他四個測試人員聯合起來發現的問題

　　所有這些活動都是以一種高度探索性的方式發生的;每一項活動都與其他活動相互作用。我以非?？斓闹芷趤韺徱曄旅嫘枰獙W習應用程序的哪一部分;嘗試并執行測試;編程;向主題問題專家、程序員、經理請教問題;報告;閱讀參考文檔;調試和學習。并行發生的緊湊的活動循環正是探索性進程的特點。但是，這并不是一項不使用工具的工作;在我對產品的探索和學習中，以及尋找程序錯誤的過程中，工具絕對占據著核心的地位。的確，如果沒有工具，關于能夠測試什么及如何進行測試，我的想法會非常有限。

原文轉自：http://www.developsense.com/blog/2011/12/what-exploratory-testing-is-not-part-3-tool-free-testing/