探索性測試

探索性測試是一種測試風格，強調快速循環的學習、測試設計和測試執行。探索性測試並非嘗試驗證軟體是否符合預先撰寫的測試腳本，而是探索軟體的特性，提出發現，然後將其分類為合理行為或失敗。

探索性測試的心態與腳本測試形成對比。在腳本測試中，測試設計人員會建立一個測試腳本，其中會寫下每一次軟體操作，以及軟體預期的行為。這些腳本會分開執行，通常會執行多次，而且通常是由不同於撰寫腳本的人員執行。如果任何測試顯示的行為與測試設計的預期行為不符，我們就會將其視為失敗。

很長一段時間以來，腳本測試通常是由測試人員執行的，你會看到許多相對資淺的人員在隔間中按照腳本點擊螢幕並檢查結果。在很大程度上，由於像極限編程這樣的社群的影響，腳本測試已經轉向自動化。這讓測試可以更快執行，並消除了評估預期行為時的人為錯誤。我長久以來一直堅定支持這種自動化測試，並看到它大幅減少錯誤，取得了巨大的成功。

但是，即使是最堅定的自動化測試人員也意識到這種技術存在根本性的限制，這是任何形式的腳本測試的限制。腳本測試只能驗證腳本中的內容，只能捕捉已知的條件。此類測試可以是一張精細的網，可以捕捉任何試圖通過它的錯誤，但我們如何知道這張網涵蓋了它應該涵蓋的所有內容？

探索性測試旨在測試網路的界限，找出任何腳本中都沒有的新行為。它通常會找到可以新增到腳本中的新失敗，有時會揭露良性的甚至受歡迎的行為，但之前沒有想到。

探索性測試是一個比腳本測試更流暢、更非正式的過程，但要做好它仍然需要紀律。一個好的方法是在定時會議中進行探索性測試。這些會議專注於軟體的特定方面。一份章程可以識別會議的目標以及你希望找到哪些資訊，這是一個提供這種焦點的絕佳機制。

此類章程可以作為重點，但不要試圖定義會話中將發生的細節。探索式測試涉及嘗試各種事情、進一步了解軟體的功能、運用所學知識產生問題和假設，以及當下產生新的測試以收集更多資訊。這通常會引發超出章程範圍的問題，這些問題可以在後續會話中探討。

探索式測試需要技術熟練且好奇的測試人員，他們必須能夠在會話期間了解軟體並提出新的測試設計。他們也需要具有觀察力，留意任何看起來奇怪且值得進一步調查的行為。然而，他們通常不必是全職測試人員。有些團隊喜歡讓整個團隊執行探索式測試，可能是成對或單獨執行。

探索式測試應為軟體開發過程中定期進行的活動。遺憾的是，很難找到有關專案中應執行多少探索式測試的任何準則。我建議從每隔幾週進行一小時的會話開始，看看會話中會挖掘出哪些資訊。有些團隊喜歡在完成一個故事時安排半小時左右的探索式測試。

如果您發現錯誤會傳遞到生產階段，這表示測試方案中存在漏洞。值得檢視任何傳遞到生產階段的錯誤，並思考可以採取哪些措施來防止錯誤傳遞到生產階段，或在生產階段時迅速偵測到錯誤。此分析將有助於您決定是否需要更多探索式測試。請記住，如果您之前沒有進行過太多探索式測試，則需要花時間培養探索式測試的技能。

如果團隊根本沒有進行探索式測試，我會將其視為一個警訊，即使他們的自動化測試非常出色。即使是最好的自動化測試本質上也是腳本測試，而這並不足夠。