探索式測試的奠基人和積極實踐者
cem kaner
和james bach
都支援語境驅動測試
[kaner12]
。語境驅動測試的
7條基本原則對於正確理解並應用探索式測試具有重要意義，本節將予以簡單討論。原則1
：任何實踐的價值都取決於其語境（
context
）。這條原則幾乎是不言自明的。中國人很早之前就有相似的認識，「南橘北枳」
[1]指相同的種子在不同的環境中會結出不同的果實。因此古人建議「因地制宜」
[2]，即根據當地的具體情況，採用合適的措施。
然而，軟體開發者往往會在無意中忘記這條原則。開發團隊會照搬以往的經驗，卻不考慮經驗可能已經過時；會不假思索地採用他人建議的開發方法，卻不懷疑南橘北枳的可能；會按照高層的指示亦步亦趨，卻不思索指令是否合理。更糟糕的是，在感覺到情況不妙後，卻將錯就錯，不思變更。因此，開發團隊需要頻繁地反思其開發實踐是否符合當前的語境，並做出相應調整。原則2
：在特定語境下存在好的實踐，但不存在最佳實踐。
這條原則看似有些武斷，畢竟軟體研發已經沉澱出一批公認的實踐方法，它們是現代軟體開發必不可少的核心實踐。但是，細細一想便會發現這些方法也需要因地制宜。「持續整合」是公認的最佳實踐，但是不同的團隊往往有不同的整合頻率。對於小型專案，一次簽入（
check-in
）會觸發一次完整的構建；對於大型專案，開發團隊可能每天做一次完整構建；對於超大型專案，做一次完整的構建可能需要幾天甚至更長的時間。不同的構建頻率和構建代價自然會導致不同的簽入策略和測試方法。雖然都在實施「持續整合」，但是不同的團隊會設計出不同的流程和方法。
對於測試工作者，這條原則表示任何一種測試方法（包括探索式測試）都不是無條件的最佳選擇。測試人員始終要評估當前情況，尋找適合當前語境的測試風格和技術。原則3
：人，在一起工作的人，是專案語境中最重要的部分。
這條原則強調了軟體開發的社會學因素。軟體開發專家
tom demarco
和tim lister
指出：「本質上，我們工作中的主要問題，與其說是技術問題，不如說是社會學問題」
[demacro99]
。而社會學因素的根源是「軟體開發是乙個創造與溝通的協作遊戲（
game
[3]）」
[cockburn07]
。在創造與溝通的過程中，一定是個體和他們的互動（
individuals and interactions
）起主要作用。
在軟體測試中，以下觀點反映了人的重要性。
n軟體開發是具有挑戰性的智力活動，開發人員（包括測試人員）的責任感、技能、狀態將強烈影響軟體實現和**質量。因此，招聘、培訓、挽留高水平開發人員是軟體企業最重要的工作之一。
n軟體開發是一種創造與溝通的遊戲。軟體企業應該營造一種開放、協作的工作環境，使得開發人員能夠自如地去思考、去發明、去創造。
n軟體測試的核心任務是尋找並傳遞資訊。在尋找資訊的過程中，測試人員的能力和相互協作的水平將在很大程度上決定資訊的數量和質量。
n軟體測試提供資訊服務。服務就意味著有客戶，測試人員是否成功，主要取決於是否很好地滿足了客戶的要求和最佳利益
[kaner01]
。也就是說，測試人員的重要任務是理解客戶，並與他們展開有效的交流。
以上觀點只涉及該龐大主題的一小部分。筆者建議讀者去閱讀此領域的經典書籍（請參考本書附錄中的「推薦閱讀」）以獲得更多見解。原則4
：專案的發展往往難以預料。
在一些語境中，專案的發展是可以預料的。圖
1.1摘自
steve mcconnell
所著的《軟體估算》，它顯示了（對專案範圍、代價、功能的）估算值是如何隨著專案的進展變得準確的
[mcconnell06]
。隨著時間的推移，專案的不確定性逐漸降低，當專案即將結束時，開發團隊能夠準確預期專案的結局。但是，圖
1.1也提示了在專案的開始階段，專案的不確定性非常高。在初始概念（
initial concept
）階段建立的估算值可能是實際值的4倍。
該原則並不是乙個悲觀的見解，相反它體現了一種實事求是的態度和對軟體風險的成熟認知。探索式測試有助於快速獲得資訊，從而降低軟體專案的不確定性。成功的測試團隊在整個專案過程中會結合廣度優先探索和深度優先探索，在特定的時間選擇適合的方法，從而更明智地利用測試資源。
圖1.1
根據日曆時間得到的不確定性錐（
cone of uncertainty）原則
5：產品是一種解決方案。如果問題沒有被解決，它就是無用的（
doesn』t work
）。成功的軟體必須幫助使用者解決現實世界中的問題，輔助他們獲得成功。在極端情況下，乙個符合規格說明且沒有技術缺陷的軟體會遭遇失敗，因為它沒有解決使用者的問題，甚至阻礙使用者解決問題。圖
1.1顯示，在需求完成（
requirements complete
）時，不確定的範圍會大幅縮小。但是，如果需求存在重大缺陷，甚至初始概念就是錯誤的，那麼穩定的開發過程只會「穩定地」產生失敗的產品。
這一原則要求測試工作者用軟體使用者的視角考察整個產品，從顯式規格說明（不完整、模糊、包含錯誤的專案文件）和隱式規格說明（包括競爭對手產品、相關產品、已發布版本、電子郵件討論、口頭討論、論壇反饋、部落格文章、領域專著、測試經驗等）中，挖掘、推導、發現需求。這是探索式測試人員需要掌握的探索技能。原則6
：好的軟體測試是乙個具有挑戰性的智力過程。
這又是一條
不言自明的原則，相信本書的讀者也會認同該原則。雖然您可能會質疑本書的一些觀點，但是您的閱讀已經說明軟體測試的挑戰性和複雜性需要認真研究與思考。
這條原則的推論是枯燥、機械、無成就感的測試過程不是好的軟體測試。這樣的過程壓抑了測試人員的創造性，分散了他們的注意力，降低了他們的智力水平。然而，本書的作者們也必須承認，我們在日常工作中也時常會感到枯燥、單調、缺乏創造力。對此，筆者的基本觀點是：第一，測試人員應該以合乎要求的質量完成自己的工作，這是測試人員必須履行的職責；第二，應該將單調的工作視為改進的訊號，通過改變工作內容和流程，將更多的時間用於具有挑戰性的工作。探索式測試、技術創新和測試自動化是筆者的常用工具。原則7
：只有通過判斷和技能，並在整個專案過程中協同練習（
exercise cooperatively
）它們，我們才能在正確的時間做正確的事，以有效地測試我們的產品。
軟體測試領域的一些文獻似乎在暗示，只要嚴格遵循「優秀」的測試過程或模板，就可以使普通的測試人員成為測試專家，並獲得理想的測試結果。這種觀點是不正確的，因為只有高素質的測試人員才能根據語境設計出合適的流程、計畫、策略和用例，而這些才是有效測試的基礎。
那麼該如何培養高素質的測試人員呢？
cem kaner
指出：「測試過程的乙個重要成果，是更好、更聰明的測試人員。」
[kaner01]
優秀的測試人員具備高超的技能，而這種技能只能通過持續的學習和實踐才能獲得。而且在乙個合作與分享的環境中，測試人員可以學得更快、練得更好。
本文節選自《探索式測試實踐之路》一書
史亮，高翔著
電子工業出版社出版
[1]語出《晏子春秋》，其成書於戰國，後經西漢劉向整理。
[2]語
出《吳越春秋》，成書於東漢。
[3]game
也可以翻譯為「博弈」。本書將其翻譯為「遊戲」是為了突出軟體開發的樂趣、協作、溝通與互助。軟體開發團隊的對手不是團隊成員，而是亟待解決的問題。
語境驅動測試7原則
探索式測試的奠基人和積極實踐者cem kaner和james bach都支援語境驅動測試 kaner12 語境驅動測試的7條基本原則對於正確理解並應用探索式測試具有重要意義，本節將予以簡單討論。原則1 任何實踐的價值都取決於其語境 context 這條原則幾乎是不言自明的。中國人很早之前就有相似的認...
原始碼時代軟測乾貨分享 探索語境驅動測試七大原則
這條原則幾乎是不言自明的。中國人很早之前就有相似的認識，南橘北枳 指相同的種子在不同的環境中會結出不同的果實。因此古人建議 因地制宜 即根據當地的具體情況，採用合適的措施。然而，軟體開發者往往會在無意中忘記這條原則。開發團隊會照搬以往的經驗，卻不考慮經驗可能己經過時 會不假思索地採用他人建議的開發方...
TDD 測試驅動開發的一般原則
這些年來，我喜歡下面三條簡單的規則來描述測試驅動開發 除非這能讓失敗的單元測試通過，否則不允許去編寫任何的產品 只允許編寫剛好能夠導致失敗的單元測試。編譯失敗也屬於一種失敗 只允許編寫剛好能夠導致乙個單元測試失敗的產品 仔細想想，就會發現如果不是去讓一些東西編譯或是執行，你就根本沒辦法去寫 確實，這...