Exploratory Testing(探索測試)

概念

Cem Kaner

一種自由測試風格，強調tester同時開展測試學習、測試設計、測試執行、測試結果評估等活動，以持續優化測試工作

特徵：自由式，策略，場景，反饋

原則：

• 儘早發現軟件中質量風險
• 來源用戶行爲模型和軟件出錯模式的抽象
• 基於用戶場景，通過模擬用戶環境用戶操作，接近模擬複雜用戶的啓發式測試模式
• 是對傳統測試的一個重要的補充

漫遊模式：

爲了降低ET的重疊區域/提高覆蓋率，以旅遊者視角進行功能劃分

參考我買的那本《探索式測試》

歷史區：

• 對於軟件缺陷來說，歷史常常會重演
• 非常有效的一種方法
• 針對老代碼，一些已知的修復問題
• 方法
  • 惡鄰測試法
    • 指那些缺陷橫行的代碼段，測試人員應該在這些區域儘量多花些時間
  • 博物館測試法
    • 重視老的那些老的遺留代碼，另外包含累計許久沒有執行過的用例，確保他們同新代碼部分同等待遇
  • 上一版本測試法
    • 檢查新版本無法運行的測試用例，以確保產品沒有遺漏必須的功能，也就是說當前產品是對以前產品的更新，必須運行前一版本的場景和用例

商業區

• 軟件銷售特性的，產品的重要功能和特性
• 方法：
  • 指南針測試法
    • 主要測試人員通過閱讀用戶手冊、場景、產品需求進行的相關測試
  • 賣點測試法
    • 對於吸引用戶的特徵進行測試，可以向銷售諮詢
  • 地標測試法
    • 主要是尋找測試點，明確測試項，這裏的測試點就是“地標”
  • 極限測試法
    • 向軟件提出難以回答的問題，比如，如何使軟件發揮最大效能？那些數據或輸入會耗費軟件的最大效能？
    • 邊界之旅-- 文本框支持的最大字符或空字符？嵌套文件夾路徑最大？郵寄存儲空間沾滿？系統負荷大的時候？，系統負載最大時啓動
  • 快遞測試法
    • 要求測試人員專注於數據，即數據從輸入到輸出展現給客戶或界面過程中，數據執行的流程
  • 場景插入法
    • 從一個場景到另外一個場景，如看視頻時來個電話並接聽，接聽完了繼續看視頻，聽微信語音的時候來電話並接聽
  • 遍歷測試法
    • 選定一個目標，然後使用可以發現的最短路徑來訪問目標包含的所有對象。測試中不要求追求細節，只是檢查那些明顯的東西

娛樂區測試法：

• 是指針對輔助特性進行的測試
• 方法：
  • 配角測試法
    • 專注某些特定的特性，索然不是用戶使用的主要特性，但是臨近主要特性，容易被人注意和發現
  • 深巷測試法
    • 測試那些不太容易使用的功能，試着把最流行和最不流行的特性放在一起測試，因爲開發人員沒有想過他們在一起會出現什麼後果。
  • 通宵測試法
    • 軟件長時間與刑後，各個模塊是否正常，有點像穩定性測試。

破舊區測試法

• 破舊的區域是指那些問題高發區域，破舊區測試就是繼續“落井下石”，如輸入惡意數據、搞破壞操作、修改配置文件等，你能想到的“有害”的事情都往這個區域想就對了。
• 方法：
  • 破壞測試法
    • 那些缺陷橫行的代碼段/功能，測試人與應該多花時間進行測試
  • 反叛測試法
    • 要求輸入最不可能的輸入和數據，或已知的惡意數據。去肯德基店非要跟對門麥當勞一樣的巨無霸漢堡
    • 文件下載時候，下載一半就把臨時文件刪除
    • 故意刪除數據庫
  • 強迫症測試法
    • 強迫軟件一遍又一遍的輸入同一數據，反覆同樣的操作。此種會打破開發正常的流程，他設想一遍就是結束了，沒想到你這是。。。

旅館區測試法

• 針對平臺或維護特性，軟件休息時還運行的特性
• 方法：
  • 深夜測試法 當我們部隊測試對象操作時，程序是否完成類似數據歸檔/自動記錄發生的異常等等，程序自動處理的功能是否正確
  • 取消測試法 -- 啓動操作，然後停止他，查看測試對象的處理機制，例如功能的取消，回退，關閉以及強制關閉
  • 懶漢測試法  -- 默認值運行

旅遊區

噱頭的功能

測試法：

• 收藏家測試法
  • tester通過手機軟件的輸出，將那些可以到達的"地方"都到達一遍，並把觀察到的輸出實際結果記錄下來，收集的越多越好
• 長路徑測試法
  • 訪問離應用的某個開始點儘可能遠的特性，哪個特性需要點擊N次才能用到
• 超模測試法
  • 要求tester關係哪些表面的東西，只測試界面。注意觀察界面的元素。界面變化。是否一致。顏色等。
• 測一送一測試法
  • 測試同一個應用多個複製的情況。測試程序同時處理多個功能要求時候，是否正常，多個功能是否同時處理，是否相互影響
  • 反覆分享同一個圖片操作10次以上
  • 反覆下載刪除，最後檢查內存情況。

總體測試方法：

思路1： 進行全局場景探索

思路2：進行特性漫遊探索

思路3：進行局部功能點探索

設計探索地圖（mindmap）

管理

爲了有效的管理，測試領導需要評估測試團隊的生存力、當前測試的進度、測試覆蓋的範圍、已經暴露的風險、測試人員是否需要幫助等因素。一個好的測試流程可以幫助測試領導和測試團隊瞭解這些因素，並實施積極的管理。爲了使探索式測試滿足軟件開發團隊對可管理性的要求，Jonathan Bach和James Bach提出了基於測程的測試管理（Session-Based Test Management，簡稱SBTM）[Bach2000]。

如幻燈片的標題和右側的圖畫所示，SBTM的重要特徵是將測試過程分解爲一組測程，從而提高整個測試項目的可說明性（Accountability）。爲此，一個測程包含四個要點：主題（Charter）、時間盒（Time Box）、可評審的結果（Reviewable Results）和簡報（Debriefing）[Bach2004]。

主題（Charter）是一個測程需要完成的任務。該任務應該是清晰且具體的，可以在90分鐘的時間內完成，並提供有價值的簡報。主題通常用一段簡練的文字描述，其內容可以是測試一個功能、檢查一個風險、測試一組用戶情景（User Scenario）等。以下是兩個實例[Michael2007]：

• Create a test coverage outline and risk list for DecideRight. （爲產品測試大綱（mindmap）和風險列表）
• Explore a decision created with QuickBuild – the wizard that guides the user through the options, criteria, and weights needed to calculate the best decision. （探索QuickBuild如何產生一個決策——用戶嚮導應該引導用戶使用選項、標準和權重來計算最佳決策）

時間盒（Time Box）是一段不受打擾的測試時間，其長度一般在60~120分鐘，以90分鐘較爲常見。在此期間，測試人員不回答問題、不回覆郵件、不應答即時消息，只專注地實施測試。從工程師的角度，時間盒使測試人員能排除干擾，全力應對測試的智力挑戰。從測試團隊的角度，固定且專屬的時間盒使得測試規劃和進度追蹤變得更容易。

可評審的結果（Reviewable Results）是測程的產出，常見的形式是測程表（Session Sheet），其內容可以包括：

• 主題（Charter）
• 測試人員
• 測試所覆蓋的區域
• 測試設計和測試發現
• 測試所發現的缺陷（Bugs）
• 測試所發現的問題（Issues）
• 測試所使用的數據文件
• 測試活動的時間統計：在產品安裝、測試設計與執行、缺陷調查與報告、非測試活動中各花費了多少時間。