在【測試理論】如何做好探索性測試（一）—基礎篇 中，我們介紹了探索性測試的基礎內容，我們簡單回憶下主要包括：常規測試方案與探索性測試是相輔相成的、在工作中，尋找探索性測試點的時機(需求評審、用例評審)、尋找那些產品中的變數，比如：可計數的東西、地理位置、檔案和儲存、時間點等等、收集使用者的反饋(操作的漫無目的及隨機性)等。

今天我們接著來介紹探索性測試從不同的維度深入進去來挖掘測試點，其中還是以理論偏多，希望大家能耐心的看完。同時我也建議大家去讀一讀探索性測試的書，比如：《探索吧，深入理解探索式軟體測試》。因為我的文章也是參考的這本書，通過讀這本書，我深刻的感知到探索性測試確實可以作為我們常規測試的一個補充，因為它真的可以給我們提供不一樣的思路，從而幫助我們挖掘更深層次的問題。

改變順序和互動

試想過往我們經歷過的場景：你負責測試某一個功能模組，其中有一些表單頁面，當你對該功能模組非常熟悉時，你應該會使用相同的資料，快速的輸入，比如：姓名你會固定使用周杰倫，地址你會使用xxx街22號等、又或者你登入app後，總是切換到首頁的某個功能列表中等等。造成這種情況的主要原因有兩個：思維定勢和習慣，所以要有效的進行探索性測試，就必須打破這種常規習慣。

名詞和動詞

大家都清楚，一個正常的句子通常包含名詞、動詞和形容詞，對於被測的系統來講，我們可以盡情的找出其中的名詞和動詞，以測試某個郵件客戶端為例(書中的例子)，名詞或者事物可能包含：郵件、附件、聯絡人、賬戶和資料夾；而對應的動詞有：建立、傳送、編輯、轉發、複製、刪除、移動等。可以在表格中，將他們都列出來，這就可以得出如下圖所示的表格(可以在Excel中列出)：

當然上面我只是列出了一部分的組合場景，你還可以根據情況組合出更多可探索的測試點。不過需要注意的是，有些組合結果看上去像是不合乎邏輯，但我們不能就這麼放過這樣的組合，而應該多找找看看，有沒有辦法能解釋這些沒有意義的組合，從而可以找到可探索的點。比如上面表格中的"匯出簽名"，看上去意義不太明確，但可以考慮，是否可以理解在郵件客戶端中直接將簽名匯出儲存起來，或者將簽名複製貼上到其他地方存起來，總之不能放過任何的蛛絲馬跡。

隨機導航

回想下，我們測試某個app時，總是點選桌面的icon圖示來開啟被測應用，那你有沒有嘗試從歷史應用中開啟被測應用？或者通過adb 命令開啟被測應用？所謂隨機導航，其實需要你收集被測系統中，完成相同操作所需要的方法，然後可以將他們記錄到表格中，比如：

將所有的情況列出來之後，就可以開始探索不同操作方式。當然還可以結合著用例場景，對不同的操作方式進行組合，也能發現一些讓你驚喜的測試點。

角色人物

所謂角色人物，是指將測試系統的使用者群體進行細分，進而能抽象出不同的角色人物。針對不同的角色人物，你可以在測試時，設想他們的操作習慣、心理變化等，來探索他們在操作軟體時會做哪些操作。

拿手機淘寶app來舉個例子，手淘的使用者群體很廣，所以也給了我們充分的設計角色人物的空間，比如下面有三種角色：

• 小王，今年20歲，是個程式設計師，重度網際網路使用者，能熟練的使用app及適應其互動體驗，並且碰到各類問題，都願意自己嘗試搜尋解決。
• 老張，今年40歲，之前在智慧手機上就用過微信app聊天（僅限於聊天），缺乏耐心，是個急脾氣，使用軟體時會缺乏耐心。
• 老王，今年50歲，剛從老年機轉到智慧手機上，喜歡學習，所以手機app上面的各個功能都會點點看。

設想一個場景，比如：手淘使用某個功能時很卡，響應很慢，那麼上面三個角色的反應也是不同的：

• 小王：因為已經對網際網路產品比較熟悉，所以他能理解慢的可能原因是啥，可能是網路、或者是app本身的原因，所以他會嘗試等待一段時間，然後還不行，就會嘗試重啟app、清理手機記憶體等。
• 老張：雖然使用過微信聊天，但是不太能理解為啥app會響應慢，又因為缺乏耐心，所以會瘋狂的點選螢幕。
• 老王：他同樣不太理解為啥app會響應慢，但是他有耐心，喜歡學習。會做出不同的嘗試，比如：按home鍵前後臺切換等。

如果你們的產品有很詳細的使用者資料（年齡、職業、性別等），那就能更好的來設計角色人物。在做探索性測試時，你可以臨時的讓自己去扮演對應的角色，發揮自己的想象力，要注意這個角色試圖做的任何事情，然後觀察軟體是如何響應的。

探索實體及實體之間的關係

系統和軟體，其實就是實體和實體構成的，所以當做探索性測試時，如果能基於它們之間的關係，挖掘一些測試點，也能幫助你發現很多問題。

認識被測系統中的實體、屬性和依賴

實體：實體也可以叫做事物，是一個系統或者軟體的基本組成部分，比如：一個賬戶、一個頭像、一條資料等都可以被稱之為實體。注意留意系統中的隱藏實體，比如：web頁面登入後建立的會話。

屬性：實體有對應的屬性，比如：電子郵件有收件人、主題和正文、商品有價格和數量等。

依賴：實體和實體之間，必然是有聯絡的，並且可能存在依賴關係。假如你看見這樣的句子格式："xxx有個xxx"時，一般就能找到依賴關係，比如：一張訂單有多個商品item、一款商品有多家供應商等。

有了上面的基礎概念，我們就可以來繪製實體之間的關係圖(ERD）。假如現在有一個庫存管理系統，系統的每一條庫存資料都對應了某一家供應商，他們之間的關係圖如下（其實和資料庫的表之間關係圖類似）：

CRUD方法

對資料庫熟悉的小夥伴應該對CRUD不陌生，它指的是對軟體中資料的增、刪、改、查。在探索性測試中，也可以找到實體在CRUD時，引起的一些變化，主要有以下幾個方面：

資料變數的CRUD：在進行CRUD時，改變實體的屬性值。比如：在新建立一條庫存資料時，將所有的欄位全都填寫上，然後再嘗試去掉某幾個值，並更新庫存資料。

其他CRUD方法：這個和前面提到的隨機導航類似，需要尋找不同的方式對實體進行CRUD操作，比如：新建立一個檔案，可以直接通過新建選單建立，或者可以針對一個現有檔案，選擇“另存為”新的檔案。再比如，在某些場景下系統會觸發自動建立一條提醒訊息，和使用者手動觸發建立的提醒訊息，它們經歷的工作流可能是有差別的。

零、單、多依賴的CRUD：主要考慮實體間的依賴關係，比如：你建立一個獨立的實體，不給它新增依賴項，看系統資料是否執行正常；另外假如刪除一個有很多依賴的實體，那麼觀察它的依賴是否也會被刪除。

在進行上面CRUD探索時，要時刻留意服務端的日誌，看是否有異常出現，以發現潛藏的問題。

發現狀態和轉換

我們經常會碰到某些bug極難重現的情況，可能是一個非常偶然的災難性錯誤，或者是無意間用到了受損的資料。這種情況，往往是湊巧碰上了一個短暫的脆弱期，因為其短暫且特殊，所以你可能花費很多時間去復現他們也會無功而返。

問題的關鍵是，我們怎樣去發現和利用出現問題時的脆弱期。幸運的是，可以採用系統化的分析方式，藉助於狀態模型，用於啟發我們如何去探索這樣的脆弱期。

事件觸發狀態的轉換

事件可以觸發系統中實體狀態的轉換，比如：你點選了軟體介面上的某個刪除按鈕，那麼就會觸發系統中刪除一條資料，在尋找事件過程中，注意以下事項：

• 外部產生事件：來自於軟體之外的任何事件，例如：對於監控檔案系統目錄結構的軟體來說，改變檔案系統的目錄結構就是一個外部產生事件的例子。
• 系統產生事件：這個比較好理解，是系統為了完成軟體功能而產生的相應事件，比如：匯入匯出資料、登入驗證使用者等等。
• 時間事件：和時間有關係的事件，比如超時、特定時間點的事件等。

在每個事件發生時，都會有對應的狀態發生變化。

狀態模型圖

以某個系統的登入模組為例，來展示一個狀態模型圖：

按照這種方式，系統或軟體可以被劃分成很多個模組，每個模組都可以來構建狀態模型圖。為了更有針對性，不至於分散，可以從如下幾個方面來考慮構建狀態模型圖。

• 專注：你可以控制狀態模型的範圍，只針對一個目標，比如說一個功能或者工作流，比如上圖中登入的流程，就涉及到已登出、登入、登陸中三種狀態，總之一定要讓自己選擇的模型可控，而不能過於分散。
• 確定一個角度：針對模組中的某一個角度來涉及狀態模型圖，比如：用微信聊天，那麼別人找你聊天是一個角度，你主動找別人聊天又是一個角度。確定特定的角度，也能幫助縮小狀態模型的範圍。
• 確定系統抽象層級：簡單說就是對於小的需求，可以儘可能的細緻描述其中的狀態轉變；對於相對複雜的系統，可以進行高度的抽象，將中間的一些小細節抽象為一個大的狀態就可以。比如：上面的登入模組例子中，假如還依賴了很多其他的服務或者應用，則可以將這些依賴服務統一起來，做成一個登入（中）的狀態。

探索狀態模型

有了上面繪製的狀態模型圖，就可以將它作為地圖，找到兩個狀態之間的所有路徑，也能很直觀的看到引起狀態發生變化的事件，我們接下來我們來看看如何去尋找狀態之間的所有途徑。

以開和關兩種常見的狀態為例，那麼可以考慮：

• 有哪些方式可以把關閉變為開啟？
  • 使用者手動啟動。
  • 作業系統啟動時自動啟動。
  • 很多軟體都有守護程序，由它們啟動。
  • 其他軟體調起了被測軟體。
• 有哪些方式可以把開啟變為關閉？
  • 使用者手動關閉。
  • 強制殺掉程序。
  • 關閉作業系統的螢幕。
  • 作業系統直接關機。

所以有了狀態圖，以及我們知道如何探索狀態之後，就可以結合難以復現的bug，實際操作下，繪製其關聯的狀態模型圖，然後探索從正常狀態到異常狀態之間的各種可能性。

狀態表格

此外，還可以將狀態模型圖轉換為狀態表格，這樣也許你有更多機會發現狀態的轉換（狀態模型圖可以幫我們從整體上來理清楚待測系統的各種狀態）。假設我們現在有一個鬧鈴，其功能介面如下：

如圖所示，其主要功能包含：

• 開啟、關閉鬧鈴
• 設定鬧鈴
• 重響功能，按下重響按鈕，鬧鐘會安靜9分鐘後再度響起。

其狀態模型圖如下：

狀態模型圖轉成表格狀態圖如下：

那結合上面的狀態表格，我們就可以進行探索，比如：設定+時間到點—>表示正好設定了一個當前時間，會怎麼樣？凡是我們想探索的不確定的全部都標記為？？？，而對於不需要探索或不符合邏輯的狀態組合，則標記為N/A。

探索生態系統

我們要測試的軟體，肯定不是單獨存在的，首先它肯定執行在作業系統上，然後它需要用到記憶體、檔案系統、資料庫和網路連線等系統資源，此外某些軟體還可能跟其他軟體或者外部服務有關聯。我們之前的討論都是基於內部系統，但從整個系統層面來考量軟體同樣重要。

繪製生態系統圖

軟體的生態系統圖包括軟體所處的環境、所有入口和所有外部依賴，我們可以把它作為一張探索地圖，圍繞連線和依賴進行鍼對性的系統探索，以便發現在系統控制範圍外跟系統各個部分相關聯的風險。我們以一個信用卡支付的web系統作為例子：

上面這張圖的各種元素含義如下：

• 中間的大圓圈表示軟體內外部依賴的邊界。
• 圓圈的外部右側表示軟體的使用者分類，這裡web系統包含管理員和普通使用者。
• 圓圈的外部左側表示軟體依賴的元件（或系統），這裡只列出了“支付閘道器”，但我們測試的軟體應該比這個複雜的多，應該有非常多的依賴，都可以列到系統圖中。
• 圓圈的內部是軟體的內部實現，主要考慮軟體的資料儲存、軟體的架構設計（根據情況，如果沒有探索的價值可不寫）及軟體的部署方式。
• 此外還可能包括，系統給外部提供的介面或元件等。

在畫系統圖時，如果不是特別清楚，可以諮詢開發，或者問他們要系統設計圖。通過這張系統圖，我們就能很直觀的，對軟體的整個執行環境瞭解，從而找到可探索的測試點。

探索信任邊界

所謂信任邊界，簡單的講就是：我們信任我們所依賴的外部系統（資料、介面、網路），以上面的生態圖為例，我們相信圓圈外部的“支付閘道器”能提供給我們正確的資料。

不過我們在做探索性測試時，要嘗試打破這種“信任邊界”，針對不同情況的外部依賴，我們可探索的情況如下：

網路資料

• 斷開網路
• 將系統的一部分放在防火牆或者網段的另一邊。
• 降低網速（弱網測試）。

檔案

• 刪除檔案
• 損壞檔案的內容
• 把檔案弄的非常大
• 設定檔案為只讀的
• 移除檔案的所有許可權
• 把硬碟裝滿，使得檔案無法再寫入。

外部依賴介面

• mock介面，讓介面不按照規則返回資料。
• 讓外部依賴介面掛掉。
• 讓外部依賴介面返回不同狀態碼的資料。

總結

因為本文內容特別多且多為理論知識，所以我們簡單回顧下上面介紹的內容：

• 第一節強調應該突破常規的作業系統，通過名詞和動詞的組合來尋找探索點，此外還可以針對軟體設計不同的角色人物。
• 第二節介紹了軟體系統中的實體、屬性、依賴，以及他們在CRUD過程中可探索的點。
• 第三節介紹軟體系統中的各種狀態，我們在進行探索性測試時，可以尋找不同狀態間的路徑，重而可以找到比較隱蔽的短暫中間狀態。
• 第四節介紹了軟體系統所處的外部環境，根據他們的改變，來觀察軟體系統的變化。

探索性測試目前還多以理論為主，但是看完相關的學習資料後，還是覺得它確實是我們做常規測試時的一個重要的補充，後面會慢慢的整理一些可以實操的行之有效的方法。但是我覺得理論知識同樣重要，希望大家能有所收穫