本節用對話的形式討論探索式測試的概念與實踐。提問者是本書的一位虛擬讀者，回答者是本書的作者們。
問：探索式測試中的「探索」該如何理解？
答：所謂探索是指有目的的漫遊，即帶著使命在某個空間中漫遊，但沒有預先確定的路線
[kaner01]
。探索包括對產品與技術的深入研究和基於研究成果的實踐應用。
問：如何實施探索式測試？
答：本書第
3部分將專門討論該問題。這裡先介紹一種可行的探索式測試實施方法，其靈感**是基於測程
[1]的測試管理（
session-based test management
）[bach2000]。
探索式測試鼓勵測試人員依據當前語境選擇合適的測試流程與技術。在測試過程中，
smart
原則[2]
為測試者提供了很好的指導。 n
specific
（具體的）：測試需要乙個具體的目標。 n
measurable
（可度量的）：有明確的指標可以評估目標是否達成。 n
achievable
（可實現的）：目標應該是可實現的。這潛在地要求將乙個大目標分解為多個小目標，且每個小目標也是具體的、可度量的、可實現的。而且，追蹤小目標的完成情況提供了整體進度的可度量性。 n
relevant n
time-boxed
（有時間限制的）：為每個目標設定乙個合理的最後期限。這可以幫助測試人員在固定的時間視窗（
time window
）中排除不相關干擾，專注地工作。
依據smart
原則，測試人員可按如下描述展開探索式測試。 （
1）測試人員制訂測試計畫。分析被測試應用，確立若干個具體的測試使命（
mission
），每個使命針對乙個可能的產品風險。 （
2）測試人員將測試使命分解為一系列測試任務（
charter
），每個任務都有明確的退出條件和時間限制。 （
3）在短暫的測試計畫之後，測試人員根據優先順序選擇乙個任務，在乙個固定的時間視窗中執行探索式測試（視窗的長度是
60~120
分鐘，以
90分鐘為宜）。這樣乙個時間視窗被稱為乙個測程（
session
）。在該測程中，測試人員設計測試、執行測試、評估測試結果。他會根據獲得的知識和發現的疑問再設計測試用例，以拓展測試的廣度和深度。 （
4）在測程結束後，測試人員適當休息，放鬆思維。 （
5）隨後，他會反思當前的測試進展，並優化測試計畫。也許他會為當前任務追加乙個測程；也許他會再增加乙個新的任務以彌補先前測試計畫的不足；也許他會刪除一些任務以反映他對測試物件的最新認知。 （
6）這時，他會更有自信地開始新一輪探索式測試。
以上只是一種可能的探索式測試實施方法。負責任的測試人員一定會選擇他自己的方式展開測試，因為只有作為領域專家的他，才能做出最符合語境的決策。此外，集合整個團隊的力量，進行同行評審、頭腦風暴、結對測試等活動，有助於產生更好的測試結果。
問：探索式測試與即興測試（
ad-hoc testing
）有何區別？
答：探索式測試與即興測試都強調「即興發揮」，即利用直覺和經驗，快速地測試軟體，並不停地調整測試策略。軟體專家
andrew hunt
指出，直覺是非顯性知識的代名詞，是大腦富（
rich
）模式的傑出能力。如果人類只使用大腦的線性模式（包括語言可表達的顯性知識、抽象能力、邏輯能力等），而漠視富模式的能量，我們將浪費自身的巨大潛力
[hunt08]。
然而人是不完美的，某些直覺可能是認知偏見或錯誤。這就引出了探索式測試與即興測試的關鍵不同：探索式測試是帶著「反思」的測試。在探索式測試中，測試人員不斷地提出假設，用測試去檢驗假設，並分析測試結果來證實或推翻假設。在此過程中，測試人員持續完善頭腦中的產品模型和測試模型，然後利用模型、技能、經驗去驅動進一步的測試。通過將測試學習、設計、執行和結果分析作為相互支援的活動並行展開，探索式測試總是在不停地優化測試模型、測試設計和測試價值。因為測試設計和測試執行的切換速度很快，許多人誤以為探索式測試沒有計畫和設計。實際上，這些活動被劃分到細微的時間片中，被反覆執行。
即興測試往往利用錯誤猜測、典型風險和常見攻擊來快速地試探軟體，可以在短時間內發現許多軟體錯誤。但是即興測試不強調測試的系統性和完整性，測試遺漏的風險很高，也難以發現一些需要深入研究才能發現缺陷。探索性測試通過測試來透徹地理解被測試產品，從而拓展測試的廣度與深度，以持續優化測試的價值。
問：如果探索式測試是硬幣的正面，那麼硬幣的反面是什麼？
答：探索式測試的對立面是指令碼測試（
scripted testing
）。指令碼測試要求預先編寫好測試指令碼（
script
），指令碼規定了如何配置被測試軟體、如何輸入、如何判斷軟體輸出了正確的結果。編寫詳細的指令碼往往需要大量的測試資源。
如果運用得當，指令碼測試可能有如下收益
[kaner08]：
n測試人員可以仔細地思考被測試軟體。 n
測試指令碼可以被專案關係人（
stakeholder
）評審。 n
測試指令碼可以被復用。 n
測試團隊可以評估測試指令碼集的完備性。 n
測試團隊可以度量測試指令碼的執**況，以評估測試進度。
問：本書為什麼反對指令碼測試？
答：筆者不反對任何測試思想或方法，但是反對不分語境地濫用某一種測試思想或方法。例如，苛刻地要求編寫詳細的測試指令碼可能會導致如下測試風險。 n
在測試執行前，大量的測試資源被用於測試設計。但是，產品的發展往往難以預料，早期的預先設計不能有效地處理動態變化的情況。有可能花費了大量的時間，卻獲得了一批充滿缺點的測試指令碼。 n
過於詳細的測試指令碼壓抑了測試執行的靈活性，使得測試執行變成單調的過程。這可能導致測試人員對一些明顯的錯誤視而不見，因為它們不在測試指令碼的檢查範圍之內。此外，執行測試是觀察軟體行為、獲得測試靈感、設計新測試用例的極佳時刻，這要求測試人員在測試執行時全神貫注、頭腦靈活、反應敏捷。但是，枯燥的測試執行將使這些目標難以實現。 n
大量的詳細測試指令碼導致了沉重的維護代價。在進度壓力下，測試人員可能沒有時間更新測試指令碼，這使得測試指令碼不能隨需求和產品一同演化。隨著時間的推移，大量的測試指令碼成為過時的、無人問津的「擺設」，原先投入大量資源所獲得的測試資產幾乎消耗殆盡。 n
要求測試人員編寫求全責備的測試指令碼，很可能帶來不良的心理暗示：測試人員在不知不覺中將編寫指令碼看做測試的目的，而不是輔助測試的工具。他們會盲目追求指令碼的數量，而很少關注產品和專案的風險，用看似「完備」的指令碼集提供虛假的安全感。更糟糕的是，醉心於指令碼數量的測試領導很可能會鼓勵這種以「文案工作」為核心的測試流程，使測試的價值進一步流失。
相比「硬幣」的比喻，筆者更喜歡
cem kaner
的觀點：「純粹的探索式測試和純粹的指令碼測試好似區間的兩個端點。在實踐中，大多數測試者位於這兩者之間。然而，大多數好的測試非常接近探索式測試的一端。」
[kaner09]
此外，根據語境驅動測試的基本原則，測試人員需要經常反思：根據當前語境，測試策略是應該偏向探索式測試，還是指令碼測試？如何綜合它們的優勢，以獲得更好的測試結果？
本文節選自《探索式測試實踐之路》一書
史亮，高翔著
電子工業出版社出版
[1]在
session-based test management
中，session
是一段專門用於探索式測試的時間，其常用的中文術語「會話」並不適合該語境。經過慎重考慮，筆者將
session
翻譯為「測程」，以表達它是一段專注於測試的過程。
[2]
讀書筆記 探索式測試 混合探索式測試
1.講述使用者故事 2.描述需求 3.演示產品功能 4.演示整合場景 5.描述設定和安裝 6.描述警告和出錯情況 1.通過場景操作引入變化 操作後得到的新場景稱為衍生場景。刪除步驟 替換步驟 重複步驟 替換資料 替換環境 替換硬體 替換容器 瀏覽器相容性 替換版本 修改本地設定 cookie 登錄檔...
探索式測試的秘密
探索式測試的秘密 我們是測試工程師，我們是專門幹這個的 我們很好地理解了需求，我們使用了很多且很好的測試設計技術 我們有較多時間進行測試執行 開發人員或使用者沒有時間去進行測試 開發人員或使用者沒有時間不知道怎麼去進行測試 我們的運氣好，突然發現了這些好的bug 當然還有很多其他的因素，這裡就不列出...
探索式測試的秘密
我們是測試工程師，我們是專門幹這個的 我們很好地理解了需求，我們使用了很多且很好的測試設計技術 我們有較多時間進行測試執行 開發人員或使用者沒有時間去進行測試 開發人員或使用者沒有時間不知道怎麼去進行測試 我們的運氣好，突然發現了這些好的bug 當然還有很多其他的因素，這裡就不列出所有的了 其他測試...