接
探索式測試的問與答（1） 既然學習非常重要，那么如何才能高效地學習呢？軟件專家Andrew Hunt指出：“一種高效的學習環境應該允許你安全地做三件事情：探索、創造和應用。”Andrew的解釋如下：
探索就是在陌生的環境中玩（Play）。你需要自由地探索才能學習。我們不僅僅接受信息，而是親自探索和構建思維模型。玩引入了一種新奇的感覺，也就是 樂趣。用一種好玩的方式學習新資料或者解決問題，可以讓這個過程變得更讓人享受，也讓學習變得更容易。為了更好地學習，請更好地玩。
你需要自由地創造--不介意自己的創造沒有成功。通過構造來學習，而不是通過學習來構造。這是“原型”、“曳光彈” 、持續集成等方法獲得成功的原因之一。
你需要在日常實踐中應用到你學到的東西。你持續使用和實踐的技能會在腦皮層競爭中占據統治地位，大腦會為它們提供更多方便。
這種探索應該相對沒有風險，因為你肯定不想因擔心害怕而止住探索的腳步。安全有助于更好地利用反饋，讓失敗也變得有意義。
雖然Andrew討論的是廣義的學習與探索，但是他的話解釋了探索式測試的成功之道：探索式測試在本質上鼓勵測試人員去自由地探索、創造和應用。
探索是帶著使命在某個空間中有目的的漫游，但沒有預先確定的路線。探索包括不斷學習和實踐。
探索式測試者持續應用他所學到的知識。所謂“學而時習之，不亦說乎”，探索式測試將學習與應用作為相互支持的活動逐步展開，為測試者的知識提升提供了平滑的學習曲線。
探索式測試有助于測試人員在合適的時間學習合適的內容，并立即應用，以獲得真實反饋。這提高了學習效率和效果，并降低了浪費測試資源的風險。
在探索式測試中，測試者創造出一切有助于學習和實踐的數據和工具。它們包括測試輸入數據、結果檢查腳本、數據分析報告和業務流程圖表等。
探索式測試是一項富有智力挑戰的活動，充滿了樂趣。
問：“學習”有助于獨立測試人員更好地工作與發展。從測試團隊和開發組織的角度看，探索式測試能夠提供什么幫助？
答：探索式測試有助于“機動性”，該特性在現在比以往任何時候都更重要。
隨著互聯網與Web應用席卷全球，軟件競爭比以往更加激烈。開發組織不僅要減少缺陷，還要跟蹤不斷變化的用戶需求和市場需求，在緊迫的時間約束下交付贏得用戶的產品。這要求軟件企業在業務、研發、營銷等方面均保持高機動性。其中，探索式測試可以在以下方面為產品研發提供幫助。
首先，探索式測試將許多測試決策置于更合理的時機，從而避免了浪費。在Web應用等高競爭性領域中，開發組織面臨模糊且持續變更的用戶需求。更重要的 是，他們必須在一切明朗之前著手行動，因為交付的時機將在很大程度上決定市場的反應，此外真實的用戶反饋將有助于下一次更準確地交付。面對高變動性的開發 過程，測試人員需要將測試設計合理地分配到整個開發周期，根據當前的開發進度和真實的測試反饋，做出恰當的測試決策。這有助于避免在信息不充分的情況下做 出錯誤的決定，從而導致嚴重的浪費和返工。
其次，探索式測試不停地根據實際情況，調整測試計劃，優化測試策略，因此能夠更有針對性地測 試，從而更快速地穩定（Stabilize）產品。探索式測試和語境驅動測試建議，測試人員總是自問：“我現在可以測試什么？應該如何測試？”這有助于測 試人員更動態地審視被測試產品和測試策略，并運用多樣化的手段去探索產品。隨著對業務領域的認識不斷深入，隨著逐漸了解產品的設計和弱點，隨著對測試技術 和工具的更加熟悉，測試人員會不斷調整測試策略，使得在整個產品開發過程中，重要錯誤的發現率都保持在比較高的水平[Kaner01]。而及時地發現重要 錯誤能夠幫助開發組織降低風險、快速推進。
測試需要探索，而探索要要大量的思考。積極思考的探索式測試是具有挑戰性的智力過程，常常需要以不確定的順序反復實施鉆研、嘗試、迂回、調整、評估等活動。好的探索式測試不會使測試更簡單，但是它會使測試更有效，從而在測試速度和缺陷發現上獲得更多的回報。
問：探索式測試是否只適用于功能性測試？
答：作為一種測試風格，探索式測試可應用于各種類型的測試。
以安全測試為 例，請想象一下黑客是如何攻破軟件產品的。他們的基本方法是“錯誤猜測”：通過分析已知的安全缺陷，抽象出可利用的缺陷模型，然后開發出相應的缺陷挖掘工 具。這些工具可以是黑盒工具，通過持續地輸入攻擊數據來發現缺陷；也可以是白盒工具，通過掃描（開源）源代碼來識別漏洞。他們運行工具，分析輸出中的蛛絲 馬跡，一旦發現疑似缺陷，便深入探索。整個攻擊過程常常需要廣泛掃描、深入挖掘、迂回前進、反復嘗試。從安全測試的角度看，黑客都是探索式測試的絕頂高 手。
相比安全測試只需“斷其一指”，性能測試需 要建立被測試產品的性能模型，并考察它在不同負載下的性能指標，因此需要更多的預先設計。然而性能測試的關鍵內容：用戶的行為模式、充足的高質量測試數據 和完整的性能監測指標（特別是面向業務的性能指標），是難以僅通過一次測試設計便可以獲得的。性能測試工程師需要與開發團隊緊密協作，通過閱讀、研究、實 驗等手段來探索性能測試模型和技術，并逐步挖掘用戶行為、制造測試數據及建立性能指標。
問：在功能實現之前，探索式測試是不是無用武之地？ 答：對于探索式測試有一個誤解，那就是探索式測試只通過運行測試以獲得知識。實際上，探索式測試者能夠也必須通過其他手段探索被測試軟件。
語境驅動測試認為：產品是一種解決方案，它必須解決現實世界中的問題。因此，探索式測試者必須從項目關系人（包括軟件用戶、項目投資人和開發團 隊等）的視角考察整個產品，研究顯式規格說明和隱式規格說明，從而發現軟件在概念、需求、設計、實現等層面上的缺陷。值得強調的是，測試人員應該主動探究 隱式規格說明，從而拓寬探索的范圍。以下是一些常見的隱式規格說明。
競爭產品。競爭產品不一定是軟件，例如筆記軟件的競爭者就包括紙質筆記本和鉛筆。
相關產品。軟件套裝（如Microsoft Office）中的軟件往往相互補充、相互約束。
同一軟件的已發布版本。向前兼容可能是非常重要的約束。
口頭討論、采訪、閑聊。
電子郵件、會議記錄、采訪記錄。
用戶反饋：電話支持記錄、論壇討論、Beta測試反饋。
技術反饋：軟件提交的崩潰信息、錯誤消息。
第三方評論：雜志文章、博客文章、社交網絡反饋。
技術標準。所有軟件都建立在一系列技術標準之上，某些標準會對測試產生重要影響。
法律法規。法律可能對軟件有強制性約束。
領域專著。測試財會軟件需要學習相關著作，以掌握財會知識。
測試人員經驗。
Cem Kaner擁有法律學位，對語言文字非常敏感。他認為積極閱讀（Active Reading）是探索式測試者需要具備的技能。積極閱讀是一個內涵豐富的主題，廣受好評的經典書籍包括《如何閱讀一本書》 、《探索需求》 和《你的燈亮著嗎？》 。
此外，在功能實現之前，可以通過小組討論、頭腦風暴等方式發掘測試策略和測試思路。針對一個開發中的功能，測試人員可以邀請幾個同事，組織一個 測試研討會。在會議上，大家自由發言，提出自己的測試策略，通過腦力震蕩相互啟發，從而獲得一批觀點各異、視角不同的測試策略。會后，測試負責人對這些相 對粗糙的測試思路進行整理，將完善后的結果寫入測試計劃。
問：如何評估探索式測試的測試效果？
答：評估探索式測試結果的前提是測試記錄。
探索式測試者常常在一個固定的時間窗口內（60~120分鐘），根據預設的測試目標，對軟件進行Z探索式測試。這樣的測試活動被稱為測程（Session）。
測程類似于科學實驗。一次科學實驗大致可以分為以下三個階段。
?。?）實驗設計：確定實驗目標?？茖W實驗的常見目的是假設檢驗，那么此次的假設是什么？
（2）實驗記錄：執行實驗步驟，并記錄實驗所發現的點點滴滴。
（3）實驗分析：分析實驗數據，總結實驗結果，為下一次實驗提供目標和假設。
相應地，一次測程包含如下三個階段。
?。?）測試計劃：明確測試目標。測試是獲得信息的過程，那么此次測試要獲得什么信息？
（2）測試執行：設計并執行測試用例，記錄測試所發現的點點滴滴。
?。?）測試分析：分析并總結測試所發現的信息，為下一次測試提供目標。
詳細的實驗記錄是科學實驗的基本要求之一。同理，詳略適當的測試記錄也是測試執行的自然結果，是測試評估的基本要求。通常，測試記錄可以包含如下內容。
測試目標：本次測試要提供什么信息？
測試范圍：本次測試覆蓋了哪些功能、模塊、用戶情景？
測試策略：本次測試使用了何種測試方法？
缺陷列表。
在測試過程中發現的疑問，它們值得進一步探索。
可以復用的測試資源：被測試軟件配置、測試數據和測試腳本等。
測程的耗時。
測程的時間分配：在測試設計與執行、缺陷調查與報告、測程的啟動與結束和非測試活動上各花費了多少時間。
測試記錄可以轉化為測試備忘錄，供今后的測程參考。測試記錄也可以提煉為測試報告，反映當前項目的進展。更重要的是，測試記錄是測試評審的素 材?；跍y試記錄，測試團隊可以開發出符合項目語境的評估方法，對測程進行專家評審和定量度量。這有助于度量探索式測試結果，并提出改進方案。
問：探索式測試只適合測試專家，不適合測試新手？
答：“探索式測試不適合測試新手”是一種似是而非的說法。第一，所有高效的測試都依賴于測試人員的測試技能 和行業知識。測試專家能夠準確地選擇測試策略、有效地運用測試方法，因此測試效果更佳。第二，測試新手采用任何測試方法，都需要指導和幫助。這有助于他們 充分利用方法的優點，并避免方法的潛在陷阱。可見，更有意義的問題是：如何幫助測試新手盡快地掌握測試方法，盡快地成長為測試專家？
從個人發展的角度看，探索式測試有助于測試新手快速學習。探索式測試將學習與應用作為相互支持的活動逐步展開，為測試人員的技能提升提供了平滑 的學習曲線。此外，并行地進行測試學習、測試設計、測試執行和測試評估為測試人員的成長提供了持續、及時、有效的反饋，這有助于他主動學習和快速調整。
從企業發展的角度看，測試團隊應該積極幫助測試新手成長?？梢圆捎玫姆椒òǎ簽樗才殴ぷ鲗?、評審其測試文檔、評審其測試記錄、在測程中安 排測試專家與他結對測試、定期進行一對一的會談等。這些活動會消耗測試團隊的人力資源，但是它們是幫助新員工成長最快速、最有效、最廉價的方法。
Peter Drucker指出：知識工人的創造性（Productivity）要求他們被視為企業的資產（Asset）而不是開銷（Cost）。培養高水平測試人員是測試團隊和測試領導不可回避的職責。
問：有什么工具可以支持探索式測試？
答：本書第5章將討論探索式測試的工具。這里強調兩個基本觀點。
第一，作為一種測試風格，探索式測試可以使用任何開發和測試工具。探索式測試者應該根據語境選擇合適的工具，去完成自己的使命。
第二，軟件測試存在大量的創新空間，測試人員應該勇于開發自己的探索式測試工具。
測試專家James A. Whittaker提出過一種測試工具構建方法，值得測試人員參考。
?。?）尋找缺陷：發現或收集軟件的缺陷。
（2）提煉模式：分析出缺陷的根本原因，編寫一個模式，用它捕獲相似的缺陷。一個模式是一個結構化的攻擊手段，它包含如下內容。
何時實施該攻擊？
該攻擊會捕獲何種錯誤（Fault）？
利用該攻擊如何識別軟件失敗（Failures）？
如何實施攻擊？
樣例和分析。
（3）開發自動化工具：識別出攻擊過程中機械的部分，編寫一個工具去自動化模式的應用。此處的測試自動化不是自動地執行測試用例，而是提供計算機輔助功能，其目的是讓計算機完成高負荷運算，讓人專注于富有智力挑戰的任務。
按照James的方法實施軟件測試，測試團隊可以積累一批有益的模式和測試輔助工具。這可以幫助團隊更有效地測試現在和未來的項目。
問：探索式測試能用于測試自動化嗎？
答：本書第6章將討論探索式測試與測試自動化。這里簡單陳述一下筆者的觀點。
測試自動化可以大致分為測試用例自動執行（Automated Test Execution）和計算機輔助測試（Computer-Assisted Testing）。
對于測試用例自動執行，探索式測試可以提供一批適合自動執行的測試用例。
對于計算機輔助測試，探索式測試要求人盡其才（自由發揮測試者的智能）和物盡其用（充分利用計算機的性能），利用計算機強大的計算能力去幫助測試人員完成測試使命。
許多復雜的測試自動化應該以探索式的風格來構造。對于困難的測試，應該先構建簡單的測試代碼，將其投入測試，利用測試反饋來改進測試代碼。然 后，將改進后的測試代碼投入測試實踐，分析測試反饋，再優化測試代碼。所謂探索式測試自動化，就是將學習、設計、實現、評估納入迭代開發，以逐步提高測試 自動化和產品的質量。
問：探索式測試與敏捷測試有何關系？
答：探索式測試在本質上是敏捷的，且可以很好地應用于敏捷項目。
2001年，17位軟件專家在美國猶他州雪鳥（Snowbird）城集會，締結敏捷聯盟，并發表敏捷宣言。與會者之一Brian Marick具有深厚的測試背景，因此軟件測試社區對敏捷宣言亦有貢獻。
敏捷軟件開發宣言
我們一直在實踐中探尋更好的軟件開發方法，身體力行，同時也幫助他人。由此我們建立了如下價值觀：
個體和互動高于流程和工具
工作的軟件高于詳盡的文檔
客戶合作高于合同談判
響應變化高于遵循計劃
也就是說，盡管右項有其價值，我們更重視左項的價值。
語境驅動測試的基本原則“任何實踐的價值都取決于其語境”和“人，在一起工作的人，是項目語境中最重要的部分”，與敏捷宣言的首條價值觀“個體 和互動高于流程和工具”不謀而合。高效的探索式測試不但需要優秀的測試人員，也要求測試人員、開發人員、客戶和項目關系人緊密協作、頻繁互動。
在思想層面，探索式測試要求測試人員不斷地研究產品，通過應對、激勵、擁抱變化來驅動對問題空間的積極探索。這不但符合敏捷價值觀，也可以應用 于其他類型的測試項目。敏捷測試專家Lisa Crispin和Janet Gregory指出：“敏捷測試可以發生在敏捷項目之外。例如探索式測試，無論它是否應用于敏捷項目，其本質是敏捷的。通過測試逐漸學習產品，并讓所學信 息指導測試實踐，這無疑符合敏捷價值觀：工作的軟件和響應變化。”
在實踐層面，探索式測試是評價產品的面向業務測試的主要手段。在用戶故事和測試策略的指導下，測試人員會模擬真實用戶去測試系統。當一部分代碼 被簽入，一部分用戶故事被實現后，測試人員就會探索新的區域，并逐步完善測試模型和測試策略。隨著測試人員對產品的了解，探索式測試不但可以彌補自動化測 試的不足，還可以揭示出更有效的自動化測試區域，為自動化測試設計添磚加瓦。此外，探索式測試能夠發掘新情景（Scenario），而這些情景往往會演變 成新的用戶故事，從而在需求層面提高產品質量。
從術語的歷史看，“探索式測試”（Exploratory Testing，Cem Kaner提出于1983年）的歷史比“敏捷軟件開發”（Agile Software Development，敏捷宣言締結于2001年）更悠久。它們都是在描述已經長期存在但是沒有得到合適命名的思想及實踐：Cem Kaner用“探索式測試”來描述一種已經長期存在的測試思維，敏捷宣言的締造者們用“敏捷”來描述他們對軟件開發的共識。雖然這些思想來自不同的頭腦、 實踐和社區，但是它們擁有相似的核心，并可以相互借鑒與補充。