本節(jié)用對話的形式討論探索式測試的概念與實踐。提問者是本書的一位虛擬讀者，回答者是本書的作者們。
問：探索式測試中的“探索”該如何理解？
答：所謂探索是指有目的的漫游，即帶著使命在某個空間中漫游，但沒有預(yù)先確定的路線。探索包括對產(chǎn)品與技術(shù)的深入研究和基于研究成果的實踐應(yīng)用。
問：如何實施探索式測試？
答：本書第3部分將專門討論該問題。這里先介紹一種可行的探索式測試實施方法，其靈感來源是基于測程的測試管理（Session-Based Test Management）。
探索式測試鼓勵測試人員依據(jù)當(dāng)前語境選擇合適的測試流程與技術(shù)。在測試過程中，SMART原則 為測試者提供了很好的指導(dǎo)。
Specific（具體的）：測試需要一個具體的目標(biāo)。
Measurable（可度量的）：有明確的指標(biāo)可以評估目標(biāo)是否達(dá)成。
Achievable（可實現(xiàn)的）：目標(biāo)應(yīng)該是可實現(xiàn)的。這潛在地要求將一個大目標(biāo)分解為多個小目標(biāo)，且每個小目標(biāo)也是具體的、可度量的、可實現(xiàn)的。而且，追蹤小目標(biāo)的完成情況提供了整體進(jìn)度的可度量性。
Relevant（相關(guān)的）：目標(biāo)要切合當(dāng)前語境，符合團(tuán)隊利益，且不忘企業(yè)愿景。
Time-boxed（有時間限制的）：為每個目標(biāo)設(shè)定一個合理的最后期限。這可以幫助測試人員在固定的時間窗口（Time Window）中排除不相關(guān)干擾，專注地工作。
依據(jù)SMART原則，測試人員可按如下描述展開探索式測試。
（1）測試人員制訂測試計劃。分析被測試應(yīng)用，確立若干個具體的測試使命（Mission），每個使命針對一個可能的產(chǎn)品風(fēng)險。
（2）測試人員將測試使命分解為一系列測試任務(wù)（Charter），每個任務(wù)都有明確的退出條件和時間限制。
（3）在短暫的測試計劃之后，測試人員根據(jù)優(yōu)先級選擇一個任務(wù)，在一個固定的時間窗口中執(zhí)行探索式測試（窗口的長度是60~120分鐘，以90分鐘為宜）。這樣一個時間窗口被稱為一個測程（Session）。在該測程中，測試人員設(shè)計測試、執(zhí)行測試、評估測試結(jié)果。他會根據(jù)獲得的知識和發(fā)現(xiàn)的疑問再設(shè)計測試用例，以拓展測試的廣度和深度。
（4）在測程結(jié)束后，測試人員適當(dāng)休息，放松思維。
（5）隨后，他會反思當(dāng)前的測試進(jìn)展，并優(yōu)化測試計劃。也許他會為當(dāng)前任務(wù)追加一個測程；也許他會再增加一個新的任務(wù)以彌補先前測試計劃的不足；也許他會刪除一些任務(wù)以反映他對測試對象的最新認(rèn)知。
（6）這時，他會更有自信地開始新一輪探索式測試。
以上只是一種可能的探索式測試實施方法。負(fù)責(zé)任的測試人員一定會選擇他自己的方式展開測試，因為只有作為領(lǐng)域?qū)＜业乃拍茏龀鲎罘险Z境的決策。此外，集合整個團(tuán)隊的力量，進(jìn)行同行評審、頭腦風(fēng)暴、結(jié)對測試等活動，有助于產(chǎn)生更好的測試結(jié)果。
問：探索式測試與即興測試（Ad-hoc Testing）有何區(qū)別？
答：探索式測試與即興測試都強調(diào)“即興發(fā)揮”，即利用直覺和經(jīng)驗，快速地測試軟件，并不停地調(diào)整測試策略。軟件專家Andrew Hunt指出，直覺是非顯性知識的代名詞，是大腦富（Rich）模式的杰出能力。如果人類只使用大腦的線性模式（包括語言可表達(dá)的顯性知識、抽象能力、邏輯能力等），而漠視富模式的能量，我們將浪費自身的巨大潛力。
然而人是不完美的，某些直覺可能是認(rèn)知偏見或錯誤。這就引出了探索式測試與即興測試的關(guān)鍵不同：探索式測試是帶著“反思”的測試。在探索式測試中，測試人員不斷地提出假設(shè)，用測試去檢驗假設(shè)，并分析測試結(jié)果來證實或推翻假設(shè)。在此過程中，測試人員持續(xù)完善頭腦中的產(chǎn)品模型和測試模型，然后利用模型、技能、經(jīng)驗去驅(qū)動進(jìn)一步的測試。通過將測試學(xué)習(xí)、設(shè)計、執(zhí)行和結(jié)果分析作為相互支持的活動并行展開，探索式測試總是在不停地優(yōu)化測試模型、測試設(shè)計和測試價值。因為測試設(shè)計和測試執(zhí)行的切換速度很快，許多人誤以為探索式測試沒有計劃和設(shè)計。實際上，這些活動被劃分到細(xì)微的時間片中，被反復(fù)執(zhí)行。
即興測試往往利用錯誤猜測、典型風(fēng)險和常見攻擊來快速地試探軟件，可以在短時間內(nèi)發(fā)現(xiàn)許多軟件錯誤。但是即興測試不強調(diào)測試的系統(tǒng)性和完整性，測試遺漏的風(fēng)險很高，也難以發(fā)現(xiàn)一些需要深入研究才能發(fā)現(xiàn)缺陷。探索性測試通過測試來透徹地理解被測試產(chǎn)品，從而拓展測試的廣度與深度，以持續(xù)優(yōu)化測試的價值。
問：如果探索式測試是硬幣的正面，那么硬幣的反面是什么？
答：探索式測試的對立面是腳本測試（Scripted Testing）。腳本測試要求預(yù)先編寫好測試腳本（Script），腳本規(guī)定了如何配置被測試軟件、如何輸入、如何判斷軟件輸出了正確的結(jié)果。編寫詳細(xì)的腳本往往需要大量的測試資源。
如果運用得當(dāng)，腳本測試可能有如下收益：
測試人員可以仔細(xì)地思考被測試軟件。
測試腳本可以被項目關(guān)系人（Stakeholder）評審。
測試腳本可以被復(fù)用。
測試團(tuán)隊可以評估測試腳本集的完備性。
測試團(tuán)隊可以度量測試腳本的執(zhí)行情況，以評估測試進(jìn)度。
問：本書為什么反對腳本測試？
答：筆者不反對任何測試思想或方法，但是反對不分語境地濫用某一種測試思想或方法。例如，苛刻地要求編寫詳細(xì)的測試腳本可能會導(dǎo)致如下測試風(fēng)險。
在測試執(zhí)行前，大量的測試資源被用于測試設(shè)計。但是，產(chǎn)品的發(fā)展往往難以預(yù)料，早期的預(yù)先設(shè)計不能有效地處理動態(tài)變化的情況。有可能花費了大量的時間，卻獲得了一批充滿缺點的測試腳本。
過于詳細(xì)的測試腳本壓抑了測試執(zhí)行的靈活性，使得測試執(zhí)行變成單調(diào)的過程。這可能導(dǎo)致測試人員對一些明顯的錯誤視而不見，因為它們不在測試腳本的檢查范圍之內(nèi)。此外，運行測試是觀察軟件行為、獲得測試靈感、設(shè)計新測試用例的極佳時刻，這要求測試人員在測試執(zhí)行時全神貫注、頭腦靈活、反應(yīng)敏捷。但是，枯燥的測試執(zhí)行將使這些目標(biāo)難以實現(xiàn)。
大量的詳細(xì)測試腳本導(dǎo)致了沉重的維護(hù)代價。在進(jìn)度壓力下，測試人員可能沒有時間更新測試腳本，這使得測試腳本不能隨需求和產(chǎn)品一同演化。隨著時間的推移，大量的測試腳本成為過時的、無人問津的“擺設(shè)”，原先投入大量資源所獲得的測試資產(chǎn)幾乎消耗殆盡。
要求測試人員編寫求全責(zé)備的測試腳本，很可能帶來不良的心理暗示：測試人員在不知不覺中將編寫腳本看做測試的目的，而不是輔助測試的工具。他們會盲目追求腳本的數(shù)量，而很少關(guān)注產(chǎn)品和項目的風(fēng)險，用看似“完備”的腳本集提供虛假的安全感。更糟糕的是，醉心于腳本數(shù)量的測試領(lǐng)導(dǎo)很可能會鼓勵這種以“文案工作”為核心的測試流程，使測試的價值進(jìn)一步流失。
相比“硬幣”的比喻，筆者更喜歡Cem Kaner的觀點：“純粹的探索式測試和純粹的腳本測試好似區(qū)間的兩個端點。在實踐中，大多數(shù)測試者位于這兩者之間。然而，大多數(shù)好的測試非常接近探索式測試的一端。”
此外，根據(jù)語境驅(qū)動測試的基本原則，測試人員需要經(jīng)常反思：根據(jù)當(dāng)前語境，測試策略是應(yīng)該偏向探索式測試，還是腳本測試？如何綜合它們的優(yōu)勢，以獲得更好的測試結(jié)果？
問：探索式測試編寫測試文檔嗎？
答：探索式測試者創(chuàng)建任何有助于實現(xiàn)其目標(biāo)的文檔，他會撰寫并維護(hù)符合語境的測試文檔。這里提出一種可能的測試計劃編寫方法，供讀者參考。
在不同的開發(fā)組織，測試計劃有不同的名稱：測試計劃、測試規(guī)格說明和測試設(shè)計文檔等。但是，大多數(shù)測試計劃會涵蓋產(chǎn)品概述、測試范圍、測試風(fēng)險、測試策略、部分詳細(xì)測試用例、資源分配和日程安排。
與腳本測試在測試執(zhí)行前編寫大量文檔不同，探索式測試在整個測試過程中持續(xù)編寫、修改、優(yōu)化測試計劃。測試計劃的內(nèi)容、格式、詳略是由項目語境決定的。
在項目計劃階段，測試計劃可以包含產(chǎn)品概述、測試范圍、測試風(fēng)險、測試策略、資源分配和進(jìn)度安排。編寫文檔的目的是建立對產(chǎn)品的整體認(rèn)知，根據(jù)風(fēng)險提出相應(yīng)的測試策略，并安排測試任務(wù)和日程。測試計劃不必面面俱到，用精簡的格式記錄必要的內(nèi)容即可。此時項目的不確定性較大，未知因素較多，很可能不適合做出詳細(xì)的測試決策。
在項目計劃階段，應(yīng)該邀請項目關(guān)系人對測試計劃進(jìn)行評審。評審的形式可以多種多樣，會議評審、桌面走查、郵件評審、在線文檔批注、頭腦風(fēng)暴皆可。評審的目的是發(fā)現(xiàn)“大圖景”上的缺陷，并豐富測試策略。眼界開闊的項目經(jīng)理、負(fù)責(zé)任的開發(fā)人員、經(jīng)驗豐富的測試同事能夠提供很好的建議。
在測試階段，測試人員需要根據(jù)測試進(jìn)展持續(xù)更新測試計劃，內(nèi)容可能包括產(chǎn)品模型、檢查列表、測試策略、覆蓋大綱和風(fēng)險列表等。測試計劃應(yīng)該是“活”的文檔，能夠反映測試人員對產(chǎn)品和項目的最新認(rèn)識。對測試范圍、測試風(fēng)險、測試策略和進(jìn)度安排的重大變化應(yīng)該寫入測試計劃，重要的測試用例（如發(fā)現(xiàn)嚴(yán)重缺陷的測試用例）也應(yīng)該及時融入測試策略。測試計劃應(yīng)該盡可能地精簡，這有助于文檔的持續(xù)更新，而冗長的文檔將不利于閱讀、增刪和修訂。
當(dāng)測試人員認(rèn)為測試計劃相對完整之后，他還應(yīng)該邀請項目關(guān)系人對測試計劃進(jìn)行評審。評審的目的是發(fā)現(xiàn)測試遺漏，補充測試策略，提高測試覆蓋率。
以上方法有三個重要的特點。
測試計劃的編寫與改進(jìn)貫穿整個測試過程。在測試執(zhí)行之前，對測試計劃不必求全責(zé)備。在測試執(zhí)行中，測試人員根據(jù)測試反饋，動態(tài)地調(diào)整測試范圍、項目風(fēng)險和測試策略，生成新的測試用例，并對測試計劃做必要的更新。
測試人員持續(xù)地收集對測試計劃的意見，并將改進(jìn)意見納入測試實踐。正式和非正式的測試計劃評審可以識別潛在風(fēng)險，豐富測試策略。在一些測試流程中，測試計劃評審只發(fā)生在測試開始之前。但是，筆者建議在測試流程的中期再次評審測試計劃，目的是進(jìn)一步豐富測試策略的多樣性，并發(fā)掘可能的測試遺漏。這時，測試團(tuán)隊對產(chǎn)品與風(fēng)險擁有更深刻的理解，能夠提出更具針對性和多樣性的測試策略，也可以幫助測試人員發(fā)現(xiàn)測試盲點，從而提高測試覆蓋率。
測試計劃側(cè)重測試規(guī)劃（一組指導(dǎo)測試過程的想法）和測試策略（一組指導(dǎo)測試設(shè)計的想法）[Kaner01]，而不是腳本化（Scripted）的測試用例，即測試計劃用精簡的格式表達(dá)測試人員的測試想法，而不必詳細(xì)記錄測試用例的設(shè)置、步驟和預(yù)期結(jié)果。測試人員可以用文字、列表、表格、思維導(dǎo)圖等任何合適的方式表達(dá)想法，目的是激發(fā)測試靈感，并促進(jìn)測試思想的交流。此外，他會利用發(fā)現(xiàn)缺陷的測試用例來完善測試策略，而不是讓過去的測試用例控制未來的測試。
關(guān)于其他形式和內(nèi)容的測試文檔，測試專家Michael Bolton的文章What Exploratory Testing Is Not：Undocumented Testing提出了很好的建議。
問：探索式測試的核心優(yōu)勢是什么？
答：探索式測試的核心優(yōu)勢是有助于“學(xué)習(xí)”。此處的學(xué)習(xí)是指學(xué)（獲取知識）與習(xí)（應(yīng)用知識）的持續(xù)過程。
對于測試人員，軟件測試是一個持續(xù)學(xué)習(xí)并實踐的過程。他的學(xué)習(xí)范圍如下。
行業(yè)知識：為什么需要這個軟件？軟件如何幫助使用它的人和團(tuán)體去獲得成功？
用戶角色：目標(biāo)用戶是誰？他們有什么特點，有什么期望？軟件如何幫助他們?nèi)カ@得個人成就？
軟件產(chǎn)品：產(chǎn)品是一種解決方案，它解決了行業(yè)和用戶所面臨的問題嗎？
計算平臺：只有深刻理解軟件所依賴的計算平臺（如操作系統(tǒng)、中間件和網(wǎng)絡(luò)協(xié)議等），才能更好地進(jìn)行測試。
開發(fā)技能：理解項目所使用的具體技術(shù)，知曉典型的技術(shù)缺陷，具備測試開發(fā)的能力。
測試技術(shù)：針對當(dāng)前項目，選擇合適的測試技術(shù)，并能夠熟練地應(yīng)用。
程序缺陷：研究已知的軟件缺陷，提煉錯誤模式，制訂緩解或預(yù)防方案。
開發(fā)團(tuán)隊：語境決定策略和實踐。在一起工作的人，是所有項目語境中最重要的組成部分。
測試人員不需要在項目之初就掌握所有知識，他可以通過每天的工作去逐步理解用戶、項目、技術(shù)和團(tuán)隊。更重要的是，他需要在每天的工作中實踐所學(xué)的內(nèi)容：規(guī)劃測試方案、創(chuàng)建并執(zhí)行測試用例、分析測試結(jié)果和編寫測試報告。實踐是練習(xí)，是“學(xué)”的自然延伸。知行合一才構(gòu)成“學(xué)習(xí)”的完整內(nèi)核。
學(xué)習(xí)的一個重要成果是成為更優(yōu)秀的測試人員。他們可以根據(jù)項目語境，選擇合適的流程、技術(shù)和工具來高效地測試，以推動軟件質(zhì)量的提高。