?傳統認知中的軟件測試是一個使用測試用例設計技術設計用例并執行測試用例的過程。

測試用例技術的目的是確保能夠更多地覆蓋、檢測軟/硬件錯誤，減少冗余測試。自動化測試或多或少地被認為是機械地執行測試腳本，將預定義的測試用例輸入被測系統，對比系統輸出和預期結果。

然而，在實際的工程實踐中我們會發現，現實世界的測試很少是基于嚴格、系統、以及完成記錄去運行預定義的測試用例。

相較于傳統的測試方法，探索性測試（ET）方法更具創造性。

測試設計、執行和學習并行，不斷地學習、反饋、優化測試方法并在實踐中應用。但是ET通常被認為是一種經驗類方法或錯誤猜測法，更多地依賴隱性的經驗知識，我們不否認ET的這個特點。

容易理解的是：累積的經驗知識可以幫助我們更好地進行測試設計，可以幫助我們更好地辨認測試過程中的異常或故障（例如，從日志中觀察到某個WARNNING輸出，如何確定它是否是軟件故障導致的異常輸出）。

這也是本篇文章討論ET圍繞的核心問題：如何辨認故障。問題關鍵是：如何利用經驗知識拓展ET測試技能辨認故障。

那么，我們需要哪些經驗知識呢？在這里，總結出了三大類經驗，是我們提高ET測試技能時需要的，分別是：領域知識、系統知識、通用軟件技術知識。

一、領域知識

領域知識又可以分為用戶視角和應用領域視角。

什么是用戶視角？在測試設計過程中我們經常提倡的一個理念是：從用戶角度使用我們的產品。

1. 用戶視角

用戶視角要求了我們需要學習和了解真實用戶的使用習慣、方式，和在真實場景中我們產品的交互方式和內部運行情況。

因此，用戶視角又可以分為：產品使用過程關聯的上下文情景，上下文中的信息內容和表示形式，以及用戶真實使用案例。

(1) 產品使用過程關聯的上下文情景

測試人員通常是系統本身的常用用戶，具有豐富的使用經驗。

當測試人員意識到他們使用程序方式與實際用戶使用方式相沖突的時候他們會很快地改變測試策略或測試方法，而所有的測試失敗都與測試情景和測試上下文關聯。

因此，基于此我們在進行ET測試的時候可以使用“產品使用過程關聯的上下文情景“經驗知識提高我們的測試技能。

詳細來說，主要就是兩點：模擬用戶真實使用場景，準備盡量真實的測試數據進行測試。

(2) 上下文中的信息內容和表現形式

當測試人員模擬真實場景進行測試的時候，需要理解和觀察情景中展現的上下文信息內容和表現形式。

當軟件系統以一種“不盡人意”的方式呈現數據、展現結果，或者展現錯誤的、有缺陷的數據時，那么可能會提醒測試人員，選擇更多測試數據樣本進行測試，觀察軟件系統的表現方式。

例如：某個web系統頁面按鈕點擊無反應，或者某個輸入框輸入特殊字符導致頁面布局錯亂。這些案例都可以成為激發測試人員發散性思考的閃光點。

(3) 客戶真實案例中披露的問題

當測試人員進行探索性測試時，了解具體的真實案例、客戶所在，按照客戶的使用習慣測試軟件系統，能夠提高識別軟件系統風險的能力。

例如：當測試人員測試一個新特性的向前兼容性時，導入了一個歷史的復雜數據導致軟件系統異常。這樣的案例在客戶真實情境中不乏多見，利用客戶真實案例評估或測試改變的特性有助于披露隱藏在軟件設計或開發中的風險問題。

2. 應用領域視角

應用程序域視角代表的是應用領域的相關知識，包括測試人員掌握的自然知識和應用程序的理論、規則和技術細節域，而不是使用上下文。

我們把這透視分為兩種：概念性知識學科內容，以及學科的實用知識物質和工具。

(1) 概念性知識和學科內容

概念性知識和學科內容在此可以通俗理解為測試人員掌握的一些邏輯推理知識、測試經驗等。

例如：測試人員根據某個web系統的頁面提示，推理、篩選得知是應用前端問題還是應用后臺程序問題。

(2) 對工具的實用性知識

工具可以幫助測試人員提高測試效率，對工具的熟悉和操作的熟稔度直接影響測試效率和測試結果分析。使用工具進行測試，測試結果可以作為測試人員的參考。

總的來說，訓練測試人員的探索性測試思維需要測試人員了解相關的領域知識。圖表總結，該部分知識如下：

二、系統知識

應用系統知識的兩個主要視角：交互特性和系統視角，以及單個特性和功能視角。

測試人員的對系統及其相關知識和理解特征可以進一步分為知識的系統的工作機制、邏輯和交互相關知識。

1. 交互功能和系統內視角

測試人員對系統及其相關知識和理解特征可以進一步分為知識系統的工作機制、邏輯和交互，以及歷史版本故障。測試人員知道特性是如何一起工作的以及系統的基本工作邏輯。

測試人員了解系統應該如何對某些事物做出反應，輸入數據或配置的各種變化和可以基于這種理解來認識失敗。

重點是不一定是細節的準確性，而是系統應該如何反應、系統是否有反應、反應是否正確。

例如：一個測試人員正在測試一個模擬現實生活的系統基于工程模型的情況。在這種情況下，通過觀察系統的響應測試人員意識到系統未能正確反應以變化的仿真參數和性能該模型。系統要么完全沒有反應，要么只反應了一部分。

值得注意的是：了解工作機制、邏輯和互動是通過觀察整體反應來應用的，使系統的配置、狀態或數據發生變化或者通過模擬現實的使用場景。這方面的知識也被應用于識別發生在不是直接在測試焦點中的區域，例如無意的變化。

最后，當系統知識作為測試人員一個新特性時，將一致性啟發式以相似的特征和故障識別為基礎，同一系統的新特性與類似特性不一致。

2. 單個特性和功能視角

單個特性和功能視角幾乎是每個測試人員經常測試的類別，針對單個特性設計測試用例進行測試。

在此，我們說明探索性測試技能的時候給大家建議的是：鍛煉測試人員分析日志的能力，要有敏感的“嗅覺”，能夠及時發現日志中的異常打印和錯誤信息，并逆向追蹤導致系統異常的場景、代碼等。

總結一下，本部分系統知識的分類和知識類型及使用方式如下表所示：

三、通用軟件工程知識

通用軟件工程知識指的是能夠明顯發掘的錯誤，不需要經過深層分析。

例如：GUI層面的功能錯誤、布局錯誤，很容易讓測試人員一目了然判斷它是否是故障。

又例如：功能層面的可用性，可以讓測試人員參考用戶手冊很容易判定它是否滿足用戶需求，是否簡單可用。

它又可以分為通用正確性視角、可用性視角和直接錯誤視角。具體如下表所示：

總結

探索性測試是一種自由、靈活的測試風格，近年來被許多測試人員推崇，相應地也誕生了一些測試技巧，如局部探索性測試方法和全局探索性測試方法。

雖然我們不斷強調探索性測試不是單純的經驗性測試，但卻也不能否認豐富的經驗為探索性測試帶來的好處。

本文從三個角度簡單闡述了如何豐富探索性測試經驗，加強探索性測試技能，希望能對大家有所幫助。?