學習探索式測試的問與答

　　本文摘錄自《探索式測試實踐之路》第1.3節，用對話的形式討論探索式測試的概念與實踐。提問者是本書的一位虛擬讀者，回答者是本書的作者們。

　　問：探索式測試中的“探索”該如何理解?

　　答：所謂探索是指有目的的漫游，即帶著使命在某個空間中漫游，但沒有預先確定的路線 [Kaner01]。探索包括對產品與技術的深入研究和基于研究成果的實踐應用。

　　問：如何實施探索式測試?

　　答：本書第3部分將專門討論該問題。這里先介紹一種可行的探索式測試實施方法，其靈感來源是基于測程的測試管理(Session-Based Test Management)[Bach2000]。(在Session-Based Test Management中，Session是一段專門用于探索式測試的時間，其常用的中文術語“會話”并不適合該語境。經過慎重考慮，筆者將Session翻譯為“測程”，以表達它是一段專注于測試的過程。)

　　探索式測試鼓勵測試人員依據當前語境選擇合適的測試流程與技術。在測試過程中，SMART原則為測試者提供了很好的指導。

　　Specific(具體的)：測試需要一個具體的目標。

　　Measurable(可度量的)：有明確的指標可以評估目標是否達成。

　　Achievable(可實現的)：目標應該是可實現的。這潛在地要求將一個大目標分解為多個小目標，且每個小目標也是具體的、可度量的、可實現的。而且，追蹤小目標的完成情況提供了整體進度的可度量性。

　　Relevant(相關的)：目標要切合當前語境，符合團隊利益，且不忘企業愿景。

　　Time-boxed(有時間限制的)：為每個目標設定一個合理的最后期限。這可以幫助測試人員在固定的時間窗口(Time Window)中排除不相關干擾，專注地工作。

　　依據SMART原則，測試人員可按如下描述展開探索式測試。

　　測試人員制訂測試計劃。分析被測試應用，確立若干個具體的測試使命(Mission)，每個使命針對一個可能的產品風險。

　　測試人員將測試使命分解為一系列測試任務(Charter)，每個任務都有明確的退出條件和時間限制。

　　在短暫的測試計劃之后，測試人員根據優先級選擇一個任務，在一個固定的時間窗口中執行探索式測試(窗口的長度是60~120分鐘，以90分鐘為宜)。這樣一個時間窗口被稱為一個測程(Session)。在該測程中，測試人員設計測試、執行測試、評估測試結果。他會根據獲得的知識和發現的疑問再設計測試用例，以拓展測試的廣度和深度。

　　在測程結束后，測試人員適當休息，放松思維。

　　隨后，他會反思當前的測試進展，并優化測試計劃。也許他會為當前任務追加一個測程;也許他會再增加一個新的任務以彌補先前測試計劃的不足;也許他會刪除一些任務以反映他對測試對象的最新認知。

　　這時，他會更有自信地開始新一輪探索式測試。

　　以上只是一種可能的探索式測試實施方法。負責任的測試人員一定會選擇他自己的方式展開測試，因為只有作為領域專家的他，才能做出最符合語境的決策。此外，集合整個團隊的力量，進行同行評審、頭腦風暴、結對測試等活動，有助于產生更好的測試結果。

　　問：探索式測試與即興測試(Ad-hoc Testing)有何區別?

　　答：探索式測試與即興測試都強調“即興發揮”，即利用直覺和經驗，快速地測試軟件，并不停地調整測試策略。軟件專家Andrew Hunt指出，直覺是非顯性知識的代名詞，是大腦富(Rich)模式的杰出能力。如果人類只使用大腦的線性模式(包括語言可表達的顯性知識、抽象能力、邏輯能力等)，而漠視富模式的能量，我們將浪費自身的巨大潛力[Hunt08]。

　　然而人是不完美的，某些直覺可能是認知偏見或錯誤。這就引出了探索式測試與即興測試的關鍵不同：探索式測試是帶著“反思”的測試。在探索式測試中，測試人員不斷地提出假設，用測試去檢驗假設，并分析測試結果來證實或推翻假設。在此過程中，測試人員持續完善頭腦中的產品模型和測試模型，然后利用模型、技能、經驗去驅動進一步的測試。通過將測試學習、設計、執行和結果分析作為相互支持的活動并行展開，探索式測試總是在不停地優化測試模型、測試設計和測試價值。因為測試設計和測試執行的切換速度很快，許多人誤以為探索式測試沒有計劃和設計。實際上，這些活動被劃分到細微的時間片中，被反復執行。

　　即興測試往往利用錯誤猜測、典型風險和常見攻擊來快速地試探軟件，可以在短時間內發現許多軟件錯誤。但是即興測試不強調測試的系統性和完整性，測試遺漏的風險很高，也難以發現一些需要深入研究才能發現缺陷。探索性測試通過測試來透徹地理解被測試產品，從而拓展測試的廣度與深度，以持續優化測試的價值。

　　問：如果探索式測試是硬幣的正面，那么硬幣的反面是什么?

　　答：探索式測試的對立面是腳本測試(Scripted Testing)。腳本測試要求預先編寫好測試腳本(Script)，腳本規定了如何配置被測試軟件、如何輸入、如何判斷軟件輸出了正確的結果。編寫詳細的腳本往往需要大量的測試資源。

　　如果運用得當，腳本測試可能有如下收益[Kaner08]：

　　測試人員可以仔細地思考被測試軟件。

　　測試腳本可以被項目關系人(Stakeholder)評審。

　　測試腳本可以被復用。

　　測試團隊可以評估測試腳本集的完備性。

　　測試團隊可以度量測試腳本的執行情況，以評估測試進度。

　　問：本書為什么反對腳本測試?

　　答：筆者不反對任何測試思想或方法，但是反對不分語境地濫用某一種測試思想或方法。例如，苛刻地要求編寫詳細的測試腳本可能會導致如下測試風險。

　　在測試執行前，大量的測試資源被用于測試設計。但是，產品的發展往往難以預料，早期的預先設計不能有效地處理動態變化的情況。有可能花費了大量的時間，卻獲得了一批充滿缺點的測試腳本。

　　過于詳細的測試腳本壓抑了測試執行的靈活性，使得測試執行變成單調的過程。這可能導致測試人員對一些明顯的錯誤視而不見，因為它們不在測試腳本的檢查范圍之內。此外，運行測試是觀察軟件行為、獲得測試靈感、設計新測試用例的極佳時刻，這要求測試人員在測試執行時全神貫注、頭腦靈活、反應敏捷。但是，枯燥的測試執行將使這些目標難以實現。

原文轉自：http://www.anti-gravitydesign.com