本文系《探索式
測試實踐之路》第1.2節，簡要的討論了“語境驅動測試”（Context Driven Testing）的7條原則。
探索式測試的奠基人和積極實踐者Cem Kaner和James Bach都支持語境驅動測試。語境驅動測試的7條基本原則對于正確理解并應用探索式測試具有重要意義。
原則1：任何實踐的價值都取決于其語境（Context）。
這條原則幾乎是不言自明的。中國人很早之前就有相似的認識，“南橘北枳”[ 語出《晏子春秋》，其成書于戰國，后經西漢劉向整理。]指相同的種子在不同的環境中會結出不同的果實。因此古人建議“因地制宜”[ 語出《吳越春秋》，成書于東漢。]，即根據當地的具體情況，采用合適的措施。
然而，軟件開發者 往往會在無意中忘記這條原則。開發團隊會照搬以往的經驗，卻不考慮經驗可能已經過時；會不假思索地采用他人建議的開發方法，卻不懷疑南橘北枳的可能；會按 照高層的指示亦步亦趨，卻不思索指令是否合理。更糟糕的是，在感覺到情況不妙后，卻將錯就錯，不思變更。因此，開發團隊需要頻繁地反思其開發實踐是否符合 當前的語境，并做出相應調整。
原則2：在特定語境下存在好的實踐，但不存在最佳實踐。
這條原則看似有些武斷，畢竟軟件研發已經沉淀出一批公認的實踐方法，它們是現代軟件開發必不可少的核心實踐。但是，細細一想便會發現這些方法也需要因地 制宜。“持續集成”是公認的最佳實踐，但是不同的團隊往往有不同的集成頻率。對于小型項目，一次簽入（Check-in）會觸發一次完整的構建；對于大型 項目，開發團隊可能每天做一次完整構建；對于超大型項目，做一次完整的構建可能需要幾天甚至更長的時間。不同的構建頻率和構建代價自然會導致不同的簽入策 略和測試方法。雖然都在實施“持續集成”，但是不同的團隊會設計出不同的流程和方法。
對于測試工作者，這條原則表示任何一種測試方法（包括探索式測試）都不是無條件的最佳選擇。測試人員始終要評估當前情況，尋找適合當前語境的測試風格和技術。
原則3：人，在一起工作的人，是項目語境中最重要的部分。
這條原則強調了軟件開發的社會學因素。軟件開發專家Tom DeMarco和Tim Lister指出：“本質上，我們工作中的主要問題，與其說是技術問題，不如說是社會學問題”。而社會學因素的根源是“軟件開發是一個創造與溝通的協作游 戲（Game[ Game也可以翻譯為“博弈”。本書將其翻譯為“游戲”是為了突出軟件開發的樂趣、協作、溝通與互助。軟件開發團隊的對手不是團隊成員，而是亟待解決的問 題。]）”。在創造與溝通的過程中，一定是個體和他們的交互（Individuals and Interactions）起主要作用。
在軟件測試中，以下觀點反映了人的重要性。
● 軟件開發是具有挑戰性的智力活動，開發人員（包括測試人員）的責任感、技能、狀態將強烈影響軟件實現和代碼質量。因此，招聘、培訓、挽留高水平開發人員是軟件企業最重要的工作之一。
● 軟件開發是一種創造與溝通的游戲。軟件企業應該營造一種開放、協作的工作環境，使得開發人員能夠自如地去思考、去發明、去創造。
● 軟件測試的核心任務是尋找并傳遞信息。在尋找信息的過程中，測試人員的能力和相互協作的水平將在很大程度上決定信息的數量和質量。
● 軟件測試提供信息服務。服務就意味著有客戶，測試人員是否成功，主要取決于是否很好地滿足了客戶的要求和最佳利益[Kaner01]。也就是說，測試人員的重要任務是理解客戶，并與他們展開有效的交流。
原則4：項目的發展往往難以預料。
在一些語境中，項目的發展是可以預料的。圖1.1摘自Steve McConnell所著的《軟件估算》，它顯示了（對項目范圍、代價、功能的）估算值是如何隨著項目的進展變得準確的[McConnell06]。隨著時 間的推移，項目的不確定性逐漸降低，當項目即將結束時，開發團隊能夠準確預期項目的結局。但是，圖1也提示了在項目的開始階段，項目的不確定性非常高。在 初始概念（Initial Concept）階段建立的估算值可能是實際值的4倍。
該原則并不是一個悲觀的見解，相反它體現了一種實事 求是的態度和對軟件風險的成熟認知。探索式測試有助于快速獲得信息，從而降低軟件項目的不確定性。成功的測試團隊在整個項目過程中會結合廣度優先探索和深 度優先探索，在特定的時間選擇適合的方法，從而更明智地利用測試資源。
圖1 根據日歷時間得到的不確定性錐（Cone of Uncertainty）
原則5：產品是一種解決方案。如果問題沒有被解決，它就是無用的（Doesn’t Work）。
成功的軟件必須幫助用戶解決現實世界中的問題，輔助他們獲得成功。在極端情況下，一個符合規格說明且沒有技術缺陷的軟件會遭遇失敗，因為它沒有 解決用戶的問題，甚至阻礙用戶解決問題。圖1.1顯示，在需求完成（Requirements Complete）時，不確定的范圍會大幅縮小。但是，如果需求存在重大缺陷，甚至初始概念就是錯誤的，那么穩定的開發過程只會“穩定地”產生失敗的產 品。
這一原則要求測試工作者用軟件用戶的視角考察整個產品，從顯式規格說明（不完整、模糊、包含錯誤的項目文檔）和隱式規格說明（包括競爭對手產 品、相關產品、已發布版本、電子郵件討論、口頭討論、論壇反饋、博客文章、領域專著、測試經驗等）中，挖掘、推導、發現需求。這是探索式測試人員需要掌握 的探索技能。
原則6：好的軟件測試是一個具有挑戰性的智力過程。
這又是一條不言自明的原則，相信本書的讀者也會認同該原則。雖然您可能會質疑本書的一些觀點，但是您的閱讀已經說明軟件測試的挑戰性和復雜性需要認真研究與思考。
這條原則的推論是枯燥、機械、無成就感的測試過程不是好的軟件測試。這樣的過程壓抑了測試人員的創造性，分散了他們的注意力，降低了他們的智力 水平。然而，本書的作者們也必須承認，我們在日常工作中也時常會感到枯燥、單調、缺乏創造力。對此，筆者的基本觀點是：第一，測試人員應該以合乎要求的質 量完成自己的工作，這是測試人員必須履行的職責；第二，應該將單調的工作視為改進的信號，通過改變工作內容和流程，將更多的時間用于具有挑戰性的工作。探 索式測試、技術創新和測試自動化是筆者的常用工具。
原則7：只有通過判斷和技能，并在整個項目過程中協同練習（Exercise Cooperatively）它們，我們才能在正確的時間做正確的事，以有效地測試我們的產品。
軟件測試領域的一些文獻似乎在暗示，只要嚴格遵循“優秀”的測試過程或模板，就可以使普通的測試人員成為測試專家，并獲得理想的測試結果。這種觀點是不正確的，因為只有高素質的測試人員才能根據語境設計出合適的流程、計劃、策略和用例，而這些才是有效測試的基礎。
那么該如何培養高素質的測試人員呢？Cem Kaner指出：“測試過程的一個重要成果，是更好、更聰明的測試人員。”[Kaner01]優秀的測試人員具備高超的技能，而這種技能只能通過持續的學 習和實踐才能獲得。而且在一個合作與分享的環境中，測試人員可以學得更快、練得更好。
版權聲明：本文出自 liangshi 的51Testing軟件測試博客：http://www.51testing.com/?298785
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。