在讀了幾篇《探索式測試》筆記類文章，發現對于書中的諸如“旅館區測試類型”比喻，由于不理解前因后果，找不到關聯性，有點云里霧里，遂重讀原書，在原文章的基礎上進行了自己的重新梳理，以及典型BUG舉例，便于自己理解記憶。
個人覺得第3、4、5章是重點需要理解的地方，文后附 "軟件戒律"也可以學習下。
參考文章：
【1】探索式測試整理 https://blog.csdn.net/zimingzim/article/details/82466413#comments_18326875
【2】書籍點評 James Whittaker – 探索式軟件測試 (Exploratory Software Testing) https://testerhome.com/topics/11709

文章目錄

• • 一、軟件質量
  • • 1.1 軟件的魔力
    • 1.2 軟件失效
    • 1.3 小結
  • 二、手工測試
  • • 2.1 軟件缺陷的根源
    • 2.2 權限預防和檢測
    • 2.3 手工測試
    • 2.4 小結
  • 三、局部探索式測試法★
  • • 3.1 用戶輸入
    • 3.2 狀態
    • 3.3 代碼路徑
    • 3.4 用戶數據
    • 3.5 運行環境
    • 3.6 小結
  • 四、全局探索式測試法★
  • • 4.1 摘要
    • 4.2 目標
    • 4.3 旅游者比喻
    • 4.4 漫游測試
    • • 4.4.1 商業區測試類型 （指南針、賣點、地標、極限、快遞、深夜、遍歷）
      • 4.4.2 歷史區測試類型（惡鄰、博物館、上一版）
      • 4.4.3 娛樂區測試類型（配角、深巷、通宵）
      • 4.4.4 旅游區測試類型 （收藏家、長路徑、超模、測一送一、蘇格蘭酒吧）
      • 4.4.5 旅館區測試類（取消、懶漢）
      • 4.4.6 破舊區測試類型（破壞、反叛、強迫癥）
    • 4.5 漫游測試法實戰
    • 4.6 小結
  • 五、混合探索式測試法★
  • • 5.1 場景和探索
    • 5.2 使用基于場景的探索式測試
    • • 5.2.1 故事1：通過場景操作引入變化
      • 5.2.2 故事2：通過漫游測試引入變化
    • 5.3 小結
  • 六、實踐中的探索式測試
  • • 6.1 dynamics AX客戶端的漫游(Nicole Haugen 的體會)
    • 6.2 利用漫游查找隱錯(David GorenaElizondo 的體會)
    • 6.3 在windows mobile設備中的漫游實踐 (Shawn Brown 的體會)
    • 6.4 windows沒提播放器的漫游測試實踐(Bola Agbonile 的體會)
    • 6.5 停車場測試法及在VS測試版的應用(Geoff Staneff 的體會)
    • 6.6 漫游測試中的測試規劃和管理
    • 6.7 小結
  • 七、漫游與測試中的棘手問題
  • • 7.1 漫無目的
    • 7.2 重復性
    • 7.3 暫時性
    • 7.4 單調性
    • 7.5 健忘性
    • 7.6 小結
  • 【附 軟件誡律】

一、軟件質量

1.1 軟件的魔力

• 未來50年，軟件必將推動更多的發明創造軟件的魔力

• 在人類創造的所有產品中，軟件出問題的可能性是其他所有產品無可匹敵的

• 人類迫切需要軟件來實現未來的夢想，但是在現實生活中，軟件卻又是最不可靠的一種產品

• 軟件對我們的未來至關重要，但目前軟件故障率已達到讓人觸目驚心的程度

1.2 軟件失效

• 有些軟件缺陷會使用戶工作效率降低，軟件缺陷還會給用戶帶來各種各樣的不便，或者會讓用戶暗暗搖頭

• 軟件缺陷是軟件魔力上的瑕疵

• 理解軟件缺陷是如何產生的，熟悉查找軟件缺陷的各種方法，從而充分兌現軟件魔力的諾言

1.3 小結

• 科學孕育了軟件，給予它非凡的魔力，現在是通過軟件魔力來創造新科學的時代了，我們需要這種魔力來解決世界上亟待解決的各類問題

• 軟件在其中都扮演著重要的角色，這就迫切需要盡可能地提高軟件質量，過去的失敗再也無法忍受

二、手工測試

2.1 軟件缺陷的根源

• 軟件缺陷的根源來自于軟件開發本身

• 軟件現在不是毫無缺陷的，將來多半也不會是

我們會討論兩種缺陷：程序員引入的缺陷和運行環境導致的缺陷

2.2 權限預防和檢測

缺陷預防

缺陷檢測

測試人員該怎么辦呢？如果測試人員不能依靠開發人員的缺陷預防工具和自動化手段，他們還能希望于什么呢？唯一的答案就是手工測試

2.3 手工測試

2.3.1 概要

• 手工測試，就是需要人來動手進行測試

• 由人來進行手工測試，可以最大程度地發揮人的主觀能動積極性，設計出真實的用戶情況，在真實的用戶環境中使用真實的用戶數據，同時可以識別出那些顯而易見的缺陷和那些比較難以覺察的缺陷

• 如果想發現與應用程序業務邏輯相關的缺陷，手工測試是最理想的選擇

• 一直以來，軟件產業在手工測試都沒有很好地發展

2.3.2 手工測試中使用腳本

2.3.3 探索式測試

• 局部探索式測試法

• 全局探索式測試法

• 同時使用探索式測試和腳本測試

2.4 小結

• 從事手工探索式測試算得上是最有挑戰性和最讓人稱心的一份工作

• 長久以來，對探索式測試一直沒有比較好的參考指南，只有那些摸索探索式測試法多年并從實踐中掌握了經驗教訓的老手才真正地在使用它

• 本模型關于探索式測試法的大量經驗教訓和真知灼見，希望可以更快更多地培養出精通該技術的人才，為軟件產業提供高質量的軟件測試，為開發高質量軟件做一份貢獻

• 在測試軟件時，必須全神貫注，決不能心不在焉。本模型幫助我們集中精力，全力以赴，使測試更徹底、更完整

三、局部探索式測試法★

3.1 用戶輸入

需要先了解用戶輸入的基本知識、合法輸入和非法輸入

1. 輸入篩選器（輸入限制）

   第一，開發是否正確的實現了該功能？

   第二，是否可以繞過屏蔽器？或者當輸入值進入系統后還可以修改？

2. 輸入檢查

   測試必須仔細閱讀每一條錯誤信息，檢查該信息是否寫錯了，錯誤信息還可以透漏開發編程時的一些想法。

   輸入檢查和異常處理的區別：輸入值檢查提示的錯誤信息很精準，異常處理提示的錯誤信息比較籠統。

3. 使用異常處理

   如果測試看到一個空乏的通用出錯信息，建議測試再反復測試同一段函數，繼續很用剛才引發異常的輸入數據，或稍微修改一下，看看會不會導致出錯。嘗試運行其他一些要調用該函數的測試用例，看看會發生什么情況。

4. 常規輸入還是非常規輸入

   所有和Ctrl、Alt、Esc按鍵組合的字符都算的上是特殊字符，需要在應用程序中測試；

   操作系統、編程語言、瀏覽器和運行時環境的特定保留詞，如windows的COM1，輸入保留此可能會崩潰。

5. 默認輸入或用戶提供的輸入

   輸入空或者默認值

6. 使用輸出來指導輸入選擇

   把輸出分為合法輸出和非法輸出，這里主要測合法輸出。

   測試先確定用戶希望程序什么輸出結果，然后考察所有的用戶場景，看看如何去生成期望的結果。

   舉例：測試接口時，需要測試record_not_exists返回，可以通過刪除本地文件、修改本地文件名稱2種方式。

輸入選擇的復雜性只是測試人員在軟件測試中最先遭遇的技術難題。不斷地對軟件進行輸入后，就出現了軟件狀態的問題

3.2 狀態

應用程序和其運行環境進行交互和接收到的所有輸入導致軟件狀態發生變化。測試人員就是測試這些狀態變化的情況。測試其是否正確更新了

自身的當前狀態？是不是進入了一些它不應該進入的狀態？

輸入和狀態之間的關系相當關鍵，在局部探索式測試法建議如下方式：

1）使用狀態信息來幫助尋找相關的輸入

? 舉例：錄音暫停狀態，什么輸入可能會導致錄音暫停，手動按下暫停，應用退至后臺，來電、其他程序搶占麥克風等。

2）使用狀態信息來辨識重要的輸入序列

3.3 代碼路徑

測試人員必須明確知道程序里可能有哪些分支，并理解哪些輸入會導致軟件走這條分支而不另一條。

舉例：在if else的地方設計測試用例，覆蓋多種條件分支

3.4 用戶數據

如果預期軟件需要存取海量的數據存儲，比如一個數據庫或大批量的用戶文件，就需要在測試環境中設置一個數據存儲。且該數據應該和軟件真實用戶使用的數據盡量一致。

需要考慮：如何模仿真實的用戶數據，使用用戶真實數據時，如何解決“隱私問題”。

3.5 運行環境

當軟件被安裝到一個嶄新的卻它從來沒見過的環境中時，還可能會失效，這是因為環境本身就算是一種輸入源，所以測試人員在產品發布之前必須盡量嘗試各種各樣地用戶環境。

任何可以影響被測試軟件行為的因素都是運行環境的一部分，在測試中都必須考慮到

運行環境包括：

• 使用的操作系統 （如安卓的系統版本）

• 系統當前配置 （如用戶配置，權限通知管理等）

• 和被測試軟件進行交互的其他一些應用程序 （如OCR調用系統相機）

• 間接或直接影響被測軟件本身 或影響被測軟件運行 的任何驅動程序、代碼、文件、設置等 （如PC的硬件驅動、依賴開發環境、體驗產品的注冊表等）

• 軟件當前連接的網絡情況、網絡的可用帶寬、性能等 （如手機代理、移動網絡/wifi、限速）

3.6 小結

輸入、代碼路徑、狀態、被存儲的數據和運行環境等，這里有太多太多的因素，而每種因素又 有太多的變化可能，這一切使得軟件測試變得極其復雜，最終無論做了哪些測試，軟件測試的復雜性都決定了我們所作的總是遠遠不夠的。

探索式測試試圖把制定計劃、進行測試、重新制定計劃等多個過程有機地結合起來，每次只前進一小步，但這 每一步都是由軟件過去和當前的運行狀況、軟件在測試時表現出來的各種行為和軟件運行時留下的種種蛛絲馬跡來即時確定的。

測試本身很復雜，但是有效地利用探索式測試技術可以幫助我們馴服這匹桀驁不馴的烈馬，從而發布一個高質量的軟件產品

四、全局探索式測試法★

4.1 摘要

此方法用于幫助測試人員設計整體測試計劃 和 測試策略。

幫助測試人員在全局方面所必須做出的各種決定，比如在考慮特性交互、數據流以及在應用程序的用戶界面上如何選擇不同路徑完成某些實際功能時。不再考察在單個輸入面板上充當中間用途的原子輸入，轉而討論那些可以幫助測試達到更重要目的的輸入。

實際上需要我們在開始就做出一個全局目標，用于指導以后的測試過程。使用全局探索式測試法，做出的決定一僅僅影響單個的對話框或者單個用戶界面，它的范圍涉及到軟件的全局。不僅僅是確定如何測試某個單一功能，而是確定了如何對軟件進行探索式測試的整體方向。

4.2 目標

漫游測試法為測試提供了一個構架，

它可以幫助測試人員創建出比使用自由發揮的方式更有趣、也更有針對性的用戶場景；

它也為測試人員設定了一個目標，引導他們嘗試更有趣和復雜的使用路徑；

漫游測試既能幫助測試人員思考如何測試應用程序，又能幫助他們組織實際的測試。

當然這一系列的測試法可以編成一張測試核對表，這樣可以避免測試人員遺漏某種測試類型，也可以幫助測試人員把應用程序的功能和適合這些功能的測試技術相匹配。

此外，這些測試法還可以幫助測試人員做出無數的決定，如何決定測試路徑，如何選擇輸入值，使用哪些參數進行測試。在無數的決定中，對比選擇不同的測試法，體會其精髓。這樣算得上是真正意義上的測試指南。

4.3 旅游者比喻

即使用上全世界所有的資金也不能保證可以測全軟件的所有方面

旅游者的目的對實際策略的選用起著舉足輕重的作用 作為測試人員，我們并不是經常能有機會在將來重新測試該應用程序，我們的第一次拜訪很可能會成為唯—一次挖掘和探索應用程序的機會

我們負擔不起漫無目的的游蕩，因為這會導致錯過重要功能和缺陷。我們必須使我們的每次訪問都有收獲

有組織有目標的旅游和自由風格漫無目的的閑逛緊密地結合起來

4.4 漫游測試

我們這里所說的特定測試通常要求把應用程序的多個特性和功能以嶄新的方式組合起來，而且這種組合方式是那些嚴格以特性為基礎的傳統測試模式無法做到的

軟件測試人員應該探索應用程序的運行路徑，以不同的順序執行許多特性。因此，在進行類比測試時，我們對旅游指南做了一些修改：

4.4.1 商業區測試類型 （指南針、賣點、地標、極限、快遞、深夜、遍歷）

對軟件來說，商業區是指“在那里完成實際業務”，位于軟件的啟動及關閉代碼之間，并包含用戶要使用的軟件特性和功能。“商業區”就是軟件包裝盒上描述的那些特性，還包括市場商業活動中演示的各種特性及實現代碼。

側重測試產品的賣點特性，并指導測試人員如何對這些特性的軟件代碼路徑進行測試。有如下測試法：

1）指南針測試法

類比旅游手冊，作者劃定界限，新手在此范圍內安排游玩，對軟件而言是用戶手冊。

要求測試人員通過閱讀用戶手冊并嚴格遵照手冊的建議執行操作。

變種一：博客測試法，遵循第三方的建議來測試；

變種二：專家測試法，根據差評創建測試用例

變種三：競爭對手測試法，測試人員遵循專家或博客為競爭對手們提供的建議來測試

2）賣點測試法

比較好理解，旅游區的代表景點，如埃及金字塔，軟件的賣點特性也是需要格外關注。

測試人員應該觀摩那些銷售演示，觀看銷售錄像并跟著銷售人員一起拜訪客戶。按照產品演示的步驟自己來執行一遍，并看看有沒有發生問題。

變種：質疑測試法：創建用戶非常在意的測試用例

3）地標測試法

戶外去某個目的地，使用指南針先斷定一個地標，走過去用指南針確定下一個地標，如此反復，只要所有地標都在一個方向上，就能到達目的地。地標測試法在vs團隊是最受歡迎且最有用的測試法。

測試人員提前確定那些關鍵的軟件軟性，就是這里的地標，在選擇完地標后，需要確定它們的前后順序，然后從一個地標執行到另一個地標來探索應用程序，直到訪問了列表中的所有地標。

4）極限測試法

作者舉了一個自己在英國旅行的例子，團隊中有個歷史專家，經常問導游一些極限的問題，最終戳穿了導游的謊言，他并不是從小生活在倫敦，而是僅居住5年。

對于探索式測試而言，極限測試法采用的途徑是向軟件提出很多難以回答的問題。比如如何使軟件發揮到最大程度？哪個特性會使軟件運行到其設計極限？哪些輸入和數據會耗費軟件最多的運算能力？哪些輸入可能欺騙它的錯誤檢驗例程？

測試文本處理器時：創建 充滿圖形、表格、多列和腳注等 錯綜復雜的文檔；

測試網上購物系統時：創造最復雜的訂單；

變種：找麻煩測試法：故意設置各種障礙來看軟件如何反應。

5）快遞測試法

在快遞測試法中，數據類似那些通過快遞系統中不斷被移動的包裹一樣，在軟件中也不斷的流動，數據從被輸入后就開始了它的生命周期，先被存儲在內部變量和數據結構中，然后在計算中被頻繁操作、修改和使用。最后，這個數據作為輸出被遞送給用戶或目的地。

測試人員必須于專注數據，應該確認那些被存儲起來的輸入數據并“跟隨”它們走遍軟件。如在購物網站輸入一個地址后，會顯示到哪里，哪些特性會用到該地址，在每個節點顯示正確。

如C2的錄音各種參數設置，在錄音筆模式和麥克風模式都能生效。

6）深夜測試法

晚上，旅游者不會選擇去商業區，但是測試人員需要關注，營業時間之后，軟件中執行賣點特性的代碼可能不運行了，但是還有其他應用程序在工作，他們執行各種維護任務，將數據歸檔，備份文檔等等。

測試人員關注主要特性外的代碼運行情況，如各種維護任務等、應該程序自動做的些事情。比如埋點數據、日志的上傳，靜默升級檢測程序。

變種：清晨測試法，目的是測試軟件的啟動過程和腳本。

舉例：2008.12.31，該年有366天，而程序中只處理了365天的情況，while（days>365）就會死循環，導致Zune設備播放器全部停機。

7）遍歷測試法

垃圾車司機采用最短路徑，挨家挨戶將垃圾運走，每家短暫停留。類比到軟件，就好比是有計劃的抽查，最短路徑，不追求細節以免影響測試進度，只檢查明顯的東西。

測試人員通過選定一個目標（例如所有菜單項、所有錯誤消息、對話框），然后使用可以發現的最短路徑來訪問目標包含的所有對象。

4.4.2 歷史區測試類型（惡鄰、博物館、上一版）

對于軟件來說，它的歷史就是它從前版本留下的代碼，還有那些曾經出現較多缺陷的特性和功能，正如真正的歷史，遺留代碼通常難以理解，包含、修改或使用遺留代碼時，通常我們要做出許多假設。

主要針對老的功能和缺陷修復代碼。

1）惡鄰測試法

每個城市都有不好的社區，一般旅游者會被告知應避免訪問那里，對軟件而言，就是缺陷橫行的代碼段，應多花時間去測試這些區域。

隨著測試的深入，發現和報告越來越多的缺陷后，就可以把缺陷數目產品特性聯系起來，從而可以跟蹤究竟在哪些地方會出現產品的缺陷。

2）博物館測試法

展示古董的博物館深受旅游者喜愛，代碼中的老古董也應被多加關注。

那些老代碼或者接受重新修改，或者是沒有被改動就放到新環境中運行，很容易發生失效的情況。故應該也要測試遺留代碼和老的可執行文件。

3）上一版測試法

如果當前產品構造是對先前版本的更新，很重要的一點就是必須運行先前版本上支持的所有場景和測試用例。可驗證用戶已熟悉的功能在新產品上依然可行。如果新版本重新實現或者刪除了一些功能，測試人員應該選擇新版本定義方法來輸入數據和使用軟件。仔細檢查那些在新版本中無法再運行的測試用例，以確保產品沒有遺漏必需的功能。

4.4.3 娛樂區測試類型（配角、深巷、通宵）

旅游者游覽了所有景點之后，一些不需要費腦筋的休閑娛樂可以用來消磨時間，對于軟件而言，指的就是輔助特性和功能，使用娛樂區測試法，可以補充不足，使測試計劃更加完善。

這類測試幫助測試人員測試那些輔助特性（如頁面布局、背景等），而不是主線特性，并確保這兩種特性能夠實用而又有意義地結合在一起。

1）配角測試法

作者講述了在聽導游講解景點時，反而被旁邊的景色吸引，推理在銷售演示產品時，會有用戶的注意力分散到附近的其他特性上。

鼓勵測試人員專注于某些不是用戶主要使用的特性，但是會和主要特性一同出現在顯示器上，它們越緊鄰主要功能，越容易被人注意，所以必須給予重視。

2）深巷測試法

除了大家喜聞樂見的旅游區，還有一些小眾的地方，如迪士尼的“后臺內幕參觀之旅”，軟件中指的是最不可能、最不吸引用戶的特性。

如果測試部門跟蹤了代碼的覆蓋率，這個測試法要求測試人員想辦法去測試那些還沒有被沒測到的代碼。

變種：混合測試法，就是試著把最流行和最不流行的特性放在一起混著測。

3）通宵測試法

通宵旅游，專為晚上不想回家而在夜店狂歡的人設計，考驗人的身體素質能否堅持，程序長時間運行能堅持到最后嗎？

測試人員會讓程序一直保持運行，而不去關閉它。即連續不斷地使用某些特性或者將文件一直保持在打開的狀態。

4.4.4 旅游區測試類型 （收藏家、長路徑、超模、測一送一、蘇格蘭酒吧）

許多城市都設有旅游區，本地人不太會去，只有旅游者才去，在軟件中，指的是某些特性和功能對新用戶很有吸引力，然而老用戶不再使用它們。

關心的是快速訪問軟件的各種功能。

1）收藏家測試法

作者舉的例子是父母在一張空白地圖上標記，每去一個地方就涂色，并且收集當地有趣的東西。

建議測試收集軟件的輸出，收集得越多越好。應該確保能觀察到軟件能生成的任何一個輸出。比如對于文本處理器，要確保它能打印、拼寫檢查、格式化文本等。

2）長路徑測試法

作者舉例：一個朋友經常出差，三點一線，于是把賓館定在遠離工區的地方，盡可能走更遠的路了解城市。

就是測試離應用程序開始點盡可能遠的特性。比如哪個特性需要點擊N次才能被用到？選擇那個特性，一路點擊過去，然后測試它。這里的主要指導思想是到達目的地之前盡量多地在應用程序中穿行。

3）超模測試法

第一印象，不管測試什么，不要超過表面皮膚的深度。

重點不是在功能或測試功能間真正的相互作用，而只是測試界面。注意觀察界面上各個元素。比如它們有沒有被正確地繪制出來？性能是否良好？變化界面時，刷新情況如何？圖形界面的按鈕和控件與期房值相符合？

4）測一送一測試法

測試同時運行同一應用程序多個拷貝的情況。即測試時運行一個應用程序，然后運行該程序的另外一個拷貝，然后再運行一個拷貝。

5）蘇格蘭酒吧測試法

作者旅游時遇到一群蘇格蘭游客，他們擅長泡吧，作者加入之后，跟著他們去了很多酒吧，若沒有他們的帶領，自己絕對找不到。蘇格蘭酒吧測試法，測試人員需要事先知道如何去找到程序中的某個地方。

適用于大規模的復雜應用程序。對于程序某些地方，測試人員需要事先知道如何看到他們。可以找到用戶組并參與他們的討論，讀產業博客，花大量時間深入了解待測的應用程序。

4.4.5 旅館區測試類（取消、懶漢）

當軟件休息時，它實際上還是非常忙碌。適用于旅館區的測試法就是要測試軟件的這種特性。

1）取消測試法

人們在旅行中遇到天氣變化，可能取消行程。

就是啟動操作然后停止它。比如打印文件并在文件打印完成之前就取消打印。可對任何提供取消選擇的功能或者需要較長時間才能完成的功能做同樣的操作。至少應該確信被取消的操作可以再次執行并成功結束。

2）懶漢測試法

旅行團中的懶漢什么都不做，導游做更多工作調起它的興趣，軟件中當用戶不做決定時，默認的邏輯也會做大量的操作if else。

測試人員做盡量少的實際工作，就意味著軟件接受所有默認值……關注軟件是否對默認值進行了處理，是否運行處理空白輸入的代碼。

4.4.6 破舊區測試類型（破壞、反叛、強迫癥）

不吃香的地方，有很多違法亂紀的事，盡管吸引了某些旅客，但盡量還是少去為妙，但是破舊區對測試人員來說是必須要去的，因為這里可能存在非常令人討厭的漏洞。

1）破壞測試法

測試人員試圖利用每個可能的機會暗中破壞應用程序。

a. 強迫軟件做一些操作

b. 掌握軟件成功完成操作必須使用的資源

c. 在不同程序上移除那些資源或者限制使用那些資源。比如增加或者刪除文件，改變文件權限，斷開網線，在后臺運行其他應用程序，把要測試的應用程序布署在有問題的機器上等。

2）反叛測試法

旅行團中叛逆的旅客，別人進去酒吧，她在外面等，別人出來，她又進去點了一杯酒。

要求輸入最不可能的數據，或者已知的惡意輸入。

如果真正的用戶輸入字母a，那么使用反叛測試人員就永遠不輸入a，取而代之的是去找些沒意義的輸入值。

有三個方法可實現反叛行為：
a. 逆向測試法 每次輸入那些最不可能的數據 為了測試應用程序的錯誤處理能力。
b. 歹徒測試法 輸入一些不應該出現的數據 測試人員在測試中違反輸入會導致很多錯誤消息，輸入突破限制的數據
c. 錯序測試法 要求測試人員以錯誤的順序做事情。如空購物車結賬，退一個沒買的物品。

3）強迫癥測試法 強迫測試人員一遍又一遍地個輸入同樣的數據，反反得得地執行相同的操作。比如在屏幕上輸入一些數據，然后馬上回來再輸入一次，看看開發人員是否編寫了錯誤處理程序。

4.5 漫游測試法實戰

pass

4.6 小結

漫游測試法既能幫助測試人員思考如何測試應用程序，又能幫助他們組織實際的測試 ；

這一系列的測試法可以編成一張測試核對表，這樣可以避免測試人員遺漏某些測試類型，它還可以幫助測試人員把應用程序的功能和適合這些功能的測試技術相匹配；

漫游測試法還可以幫助測試人員作出無數的決定，如何決定測試路徑，如何選擇輸入值，使用哪些參數進行測試；

在微軟，漫游測試法被看作匯總各部門間測試經驗的一種機制，通過這一機制，一些測試法最終會被證明是很成功的。

五、混合探索式測試法★

5.1 場景和探索

• 摘要
• 測試場景
• 有價值的場景
• 探索型測試人員應盡力確保從所有這些分類中收集盡可能多的場景，然后的任務就是根據這些場景加入合適的變化。通過有系統地考慮輸入選擇、數據使用和環境條件，一個場景可以演變出許多測試用例。使用了兩個主要技術：場景操作和漫游測試。

5.2 使用基于場景的探索式測試

5.2.1 故事1：通過場景操作引入變化

為了使測試人員以更系統更策略的方式考慮替換路徑，引入了場景操作，就是對場景的步驟加以操作，來給場景注入變化。

• 插入步驟

  給場景增加額外的步驟可使它們更加多樣化，從而測試更多的功能，可以用到以下這些類型：

  • 增加更多數據
  • 使用附加輸入
  • 訪問新的界面

  注意這些步驟最終都需要測試人員返回到原始場景。我們的目的是加強場景，而不是徹底改變場景的基本目標。

• 刪除步驟

  我們可以去年冗余和可選的步驟，這個操作的想法是使場景的步驟盡可能地減少。也許因此而衍生的場景會缺乏那些設置初始條件的步驟，這種場景可以用來測試應用程序是否可以識別出現在缺少信息或者缺乏一些從屬功能。

• 替換步驟

  如果場景中某些步驟可以有多種方法完成，就可以用替換步驟的場景操作來修改這個場景。實際上是前面兩個操作的組合，就是先刪除步驟，然后再插入步驟。故測試人員必須研究其他替代的方法來執行場景中每個步驟或動作。

• 重復步驟

  場景經常包含非常明確的動作順序。重復步驟的場景操作通過重復單獨的步驟或者重復一組步驟來改變這個順序，以創建額外的變化。通過重復和重新安排步驟，我們可以測試新的代碼路徑，發現那些可能與數據初始化相關的缺陷。

• 替換數據

  理解應用程序連接和使用的數據源，并確保它們之前的交互是穩定可靠的。比如通過讀取、修改或者操作數據來代替默認的數據庫來測試當前場景。比如如果數據源的現有記錄數增加了十倍，會發生什么情況？

• 替換環境

  基本要點是測試場景本身并不改變，只是在軟件上執行這些場景時，所使用的系統發生了改變。

  需要考慮的因素：

  • 替換硬件 改變實測應用程序所運行的硬件。可以充分利用虛擬機的技術來完成這項任務。
  • 替換容器 需要確保測試場景可以在用戶有可能使用的所有主要容器中運行，如不同瀏覽器。
  • 替換版本 被測應用程序在老版本上運行得怎么樣？
  • 修改本地設置 測試應用程序是否使用cookie或者在用戶機器上寫文件嗎？它使用本地注冊表嗎？如果用戶修改瀏覽器設置來限制這類活動會怎樣？如果用戶直接改變應用程序的注冊表設置會怎樣？作為測試人員，最好能在應用程序發布前知道它如何處理上述情況。

5.2.2 故事2：通過漫游測試引入變化

場景操作側重于場景中小的、逐漸增加的變化以及可有可無的步驟，而漫游實際上可以創建出相當長的和范圍更廣的衍生場景。

• 賣點測試法
  模擬用戶已有的工作習慣，在原始場景中加入一些新功能，讓用戶使用過程通過學習某個功能，掌握它，然后隨著對應用程序的熟悉而逐漸轉移到新功能上。
• 地標測試法
  從場景開始并從場景中選取特定功能的地標，然后隨機打亂這些地標的順序，這樣得到的場景就和原始場景不同了。如有必要，重復這個過程，不斷用新地標順序來運行測試。
• 極限測試法
  檢查并修改場景以使軟件更加努力地工作，即挑戰軟件，向它提困難的問題。如很長的字符串輸入會產生問題嗎？
• 深巷測試法
  關注使用最不可能用到的或者最沒有用的功能。
• 強迫癥測試法
  重復場景中的每個步驟兩次或者三次。比如在軟件中四處移動數據歷來可以有效的找到重要缺陷。
• 通宵測試法
  當測試場景可以被自動化或者可以被錄制回放時，最適合使用的是通宵測試法，只需要不斷重復運行場景而不需退出被測應用程序。
• 破壞測試法
  在運行場景測試時，在資源調用處進行破壞活動。如場景要求在網絡上傳輸數據，可以執行步驟之前或者之中拔掉網線等。
• 收藏家測試法
  執行場景和衍生場景時用文檔記錄下所觀測到的每個輸出。
• 超模測試法
  運行場景時只關注界面。確保所有元素都在它們應該在的位置上，界面應該設計合理，尤其要注意可用性問題。
• 配角測試法
  測試人員不是執行測試腳本描述的功能，而是找到最近的鄰近功能來執行。
• 取消測試法
  不但充分利用取消按鈕（運行場景時只要看到它就點擊），而且執行了啟動和停止功能。如在開始執行某些功能時，通過取消或者Esc來取消。
• 混票測試法
  從一個場景跳到另一個，從而把兩個或者更多場景結合為一個具有混合目的的場景。檢查所有的場景并找出那些通用數據，側重于通用功能。

5.3 小結

靜態場景測試和探索式測試并不沖突；

場景可以代表探索式測試的一個絕佳起點，探索可以給場景加入寶貴的變化，否則場景將很有限；

明智的測試人員會把這兩種方法結合起來，以便更好地覆蓋應用程序，得到更多的輸入序列、代碼路徑和數據使用的變化；

六、實踐中的探索式測試

6.1 dynamics AX客戶端的漫游(Nicole Haugen 的體會)

Dynamics AX 是企業資源規劃 (ERP) 解決方案，這些程序都是在 20 多年前全部采用 C++ 語言實現的。作為客戶端團隊，在這里，我們需要通過圖形用戶界面 (GUI) 來測試 Dynamics AX，在此之前，我的團隊主要測試公共應用程序接口 (API)，所以，這對我們是一種思維方式的轉變。在這個轉變過程中，我們學到以下幾件事情。

• 很多缺陷都不是通過測試設計中所定義的測試用例找到的
• GUI 測試引入的場景和復雜的用戶交互似乎無窮盡，不容易使用自動化測試
• 不管測試是手動的還是自動的，都必須放到回歸測試中加以維護。團隊中有成千上萬的測試用例，所以必須不斷地考慮每一個新測試用例所帶來的投資回報率
• Dynamics AX 是一個大型的應用程序，我們并不清楚其中的每一部分，更不用說應該如何對它進行測試。 探索式測試有助于我們解決以上所有的問題。最終我們是用下面的方法把它融入到我們的流程中。
• 在每個功能遷入 (check in) 之前，測試人員對代碼執行探索式測試。這樣做是為了在遷入前更快、更好地找到重要錯誤。如果代碼修復的是關鍵性的或高風險的缺陷，我們對他們也采取了同樣的做法。
• 探索式測試用于幫助我們在測試設計中開發出測試用例，它也可以幫助我們發現在官方說明書中可能漏掉的用戶場景。
• 手工測試階段，我們從測試腳本出發，然后引入探索式測試。個人經驗是，未經改動的手工測試很少能檢測到新問題；但是對現有測試做哪怕是最細微的改動都可能發現許多缺陷。
• 在缺陷” 大掃除”(bug bash) 時，我們采取了探索式測試，以引導我們到當前功能以外的地方去發現相關的缺陷。

有用的探索漫游

• 出租車測試法

  – 解釋：從強迫癥測試法派生出來，最終目標是重復執行某項特定的操作，但是不重復執行完全相同的測試路徑。條條大路通羅馬。
  – 典型缺陷：使用所有的路徑執行菜單項漫游，當時用快捷鍵訪問菜單，再接著按下某一菜單加速鍵崩潰

• 出租車禁區測試法

  – 解釋：目的是驗證無論選擇哪一條路徑用戶始終無法到達目的地，重點測試禁區功能無法被繞過達到。
  – 典型缺陷：用戶不能打開超過8個工作區，尋找用戶打開一個新工區的所有路徑，先打開7個，再遍歷路徑打開第8個，某一路徑可以打開9個工作區，導致程序崩潰。

• 多元文化測試法

  – 解釋：軟件的本地化測試

  a. 要求沒有硬編碼的文本，修改系統語言，驗證靜態文本、異常消息、工具提示、菜單項、窗口標題等是否已經不再顯示為英語，有些特定詞語不應該被翻譯

  b. 嘗試右往左的語言，如阿拉伯語，驗證控件窗口能正常運行，可以改變下窗口大小、檢查是否正常。

  – 典型BUG： windows<alt+W>沒有正確改編為意大利版本的 finestre <alt+F>

漫游測試策略

• 超模測試法與配角測試法相結合

  測試有圖形界面的產品時，超模測試法是去除界面中明顯缺陷的重要手段，在配角測試中，為了獲得整體效果，必須把注意力向左或向右轉10度 與配角測試法相結合。

• 深巷測試法與混合目的地測試法相結合

  目的是測試不同特性之間是如何交互的。

• 取消測試法

  取消被測對象之前應該改變它的狀態。

• 地標測試法

  對負責范圍之外的其他功能不熟悉，找一個互補的熟悉另一功能的專家結伴測試。

6.2 利用漫游查找隱錯(David GorenaElizondo 的體會)

• 取消測試法

  典型BUG：

  • 在取消和工程項目最初設置的連接后，我們就無法再通過手動方式連接到該項目
  • 再刪除一個配置變量時，無論取消還是確認都會被再提示
  • 選區不同的測試套件時，如果正在加載測試用例，該操作不會被取消
  • 反復刷新幾次，刷新時間開始成倍增長
  • 瘋狂刷新測試設置管理器，程序崩潰了

• 破壞測試法

  典型BUG：

  • 沒有tfs連接，卻試圖查看配置時，程序崩潰
  • 啟動時，如果config被破壞，持續崩潰
  • 配置文件很大時，程序崩潰

• 快遞測試法

  典型BUG：

  • 從工作項返回后，測試計劃沒有自動刷新
  • 修改一個測試計劃的屬性，程序崩潰
  • 測試計劃使用已刪除的版本會導致程序崩潰

• 測一送一測試法（關注多用戶）

  典型BUG：

  制定新的測試計劃屬性時，如果不是新的配置文件，程序會崩潰

6.3 在windows mobile設備中的漫游實踐 (Shawn Brown 的體會)

2000 年微軟發布一項產品，它是一種便攜式的設備，可移植性很多全功能計算機上才有的功能。這個設備叫做 Pocket PC，它開啟了 Windows Mobile 系列 (2009 年，微軟將其更名為 Windows Phone) 版本的發布。隨著 Windows Mobile 系列的發布，它的功能也越來越多。在我的 Windows Mobile 職業生涯期間，我負責測試連接管理器，一些較早版本的 Office 應用程序，還有就是我的最愛 ----- 打電話功能。
進行 3 小時的野外游，根據用戶的實際環境進行測試。目標是發現 20 個缺陷，結果他們找到了 25 個缺陷。且發現破壞測試法、超模測試法和強迫癥測試法最為有用。

• 取消測試法

  典型BUG：

  后臺搜索進程根據條件進行查詢，輸入一個預先知道不會返回任何結果的搜索字符串，刪除搜索字符串的第一個字符，結果與搜索字符不匹配的數據被顯示出來

• 使用破壞測試法

  • 解釋：如果測試的是使用網絡連接的應用程序，那就是使用破壞測試法的好地方
  • 典型BUG：模擬聯系人列表同步錯誤，導致同步看上去成功，但實際上存儲的是空白的快速撥號

• 使用超模測試法

  • 探索不同屏幕分辨率下的用戶界面中心點和定位點
  • 典型BUG：選擇一個不常見的屏幕分辨率，日歷月視圖中更改月份，沒有頂部對齊，而是中間對齊

6.4 windows沒提播放器的漫游測試實踐(Bola Agbonile 的體會)

• 遍歷測試法
  根據功能相似度進行分類，分貝是所有的用戶界面、對話框、文字框、邊界、所有按鈕，然后按照規定的次序進行測試
• 超模測試法
  發現文字拼寫錯誤的秘密，讀出一個單詞，然后默數一、二之后，再讀下一個單詞
• 極限測試法
  整理25個“假如”類型的問題，查看WMP是否工作正常

6.5 停車場測試法及在VS測試版的應用(Geoff Staneff 的體會)

停車場測試法，某種程序上，是地標和超模測試法的結合體

• 拿到版本之后，先做簡短的停車場漫游來了解應用程序的各個部分是如何協同工作的，再把那些值得關注和后續測試的區域記錄下來，下一步任務的重點是針對每個特性進行測試，通常在測試中還會有意識的加強某一方面的測試，例如可訪問性，或處罰所有的錯誤對話框，或強迫采用所有的默認值…… 一般情況下，上述執行之后，最明顯的缺陷基本都會被找到。
• 進行更有針對性，也更加徹底的一輪測試。主要采用深巷測試法和強迫癥測試法，這些測試方法都是基于過去幾天對產品行為的觀察和理解，以及和開發人員關于具體代碼實現的相互交流。 另外和開發人員約定一種低開銷的工作模式：如果開發人員可以再本周末前修復缺陷，那么測試人員就不會正式記錄該缺陷。對開發和測試人員都有好處：產品質量可以迅速提高，沒有人需要花額外的時間去上報缺陷和寫缺陷文檔。但是如果缺陷的周轉要好幾天而不是幾小時，那么就要上報缺陷。
• 通過分析缺陷和找到它們時使用的測試方法，對所找到的缺陷進行分類，結果如下：
  • 9%，出租車測試法 (鍵盤、鼠標等)
  • 9%，遍歷測試法 (釋放或者消除資源后，再進行檢查)-----------------------嚴重缺陷
  • 15%，深巷測試法 (試圖進行某種已知的不良操作，如關閉對話框兩次) -------嚴重缺陷
  • 18%，強迫癥測試法
  • 19%，地標測試法
  • 30%，超模測試法 ----------------------------------------------------- 大多不是嚴重缺陷

6.6 漫游測試中的測試規劃和管理

pass

6.7 小結

微軟內部使用的漫游概念有助于軟件測試人員更好地組織他們的手工測試，讓他們的測試更一致、針對性更強、目的性更強；

所有參加這些活動以及其他案例研究的測試人員們都覺得此概念很有用，他是一種用于描述測試技術和交流測試技巧的優秀方法；

現在測試人員們已經很少把注意力集中于底層單個的測試用例，而更專注于較高層的測試設計及測試技術等概念

七、漫游與測試中的棘手問題

7.1 漫無目的

• 決定需要測試什么

• 決定何時測試

• 決定如何測試

7.2 重復性

• 知道已經運行過哪些測試

• 知道什么時候注入變異

7.3 暫時性

大多數測試人員不生活在軟件中，他們只是“暫住”而已，一旦應用程序投入市場，他們就會轉到下一個項目；

發現軟件問題需要實際用戶在實際的環境中，用實際的數據，去做實際的工作。測試人員不會接觸到這些問題，這些問題的暴露需要時間；

最終測試人員是暫時性的，我們只能做力所能及的工作；

7.4 單調性

測試是枯燥的

實際上測試充滿了有趣的策略問題，它既有娛樂性又有挑戰性

在急于測試的情況下，測試策略問題常常被忽略，因為解決策略問題會增加測試量；

測試的戰術方面實際上包括運行測試用例并報告錯誤，這是工作中樂趣較少的那部分；

有頭腦的測試經理和測試主管要認識到這種現象，確保每一個測試人員把他們的時間合理分配在測試策略和測試戰術上；

這種識別、記錄、共享和優化以漫游為基礎的測試方法的行為（漫游測試） ，稱得上是一種高效率、高產出率、高創造性和更有趣的測試方法；

7.5 健忘性

測試任務從時間上來說比較側重當前狀況；

我們計劃測試、設計測試、運行測試、分析結果，測試結束后馬上就忘；

我們沒有花大量時間思考如何在應用程序的未來版本中或其他測試項目中使用同樣的測試；

測試團隊對未來要干什么想的就更少了。測試用例被創建、被運行、最后被廢棄；

測試用例并不是解決這種記憶問題的最好方法。對應用程序的改變常常導致測試用例的維護開銷大幅上升，而且殺蟲劑悖論也降低了現有測試用例的價值

漫游測試在一定程度上效果更好，因為一條漫游路徑可以代表任何數量的實際測試用例

7.6 小結

/

【附 軟件誡律】

1. 汝應使用大量輸入反復錘煉汝之應用程序

用大規模隨機測試來面對無窮盡的排列組合的輸入。測試人員無論如何都要打起精神來面對無窮。這是每個測試人員工具箱里必備的一個工具。極少測試項目能夠沒有它。
大規模測試必須是自動化的。雖然第一次做總是有些難度，但是隨著項目的積累會越來越簡單，最終變為機械的工作。它可能不會找到大量的缺陷，但是它是對剩余測試用例的一種極好的健全性檢查，隨機測試有時能找到一些高質量 (盡管數量上很少) 的缺陷；僅僅在編寫大規模隨機測試計劃的過程中，我幾乎總能找到缺陷或是想到一些很好的測試點子。

2. 汝應貪圖汝之鄰居的應用程序

不要將應用程序孤立起來測試。否則很可能陷入” 應用程序兼容性” 的噩夢里。一種方法是儲備一些應用程序 (舊的，新的，借來的……并且保證在運行應用程序的同時也運行這些程序。當然針對操作系統也要進行這項工作。例如安裝某個操作系統升級服務包之后因公用程序無法運行……。所以我們要開始貪圖那些應用程序和服務包，越多越好。

3. 汝應親自尋找睿智的預言家

我們測試軟件的時候需要知道該軟件是否按照既定的方式回應我們的輸入。如果無法驗證，測試就無法有效進行。測試人員在談到知道所有答案的睿智的預言家時，稱其為” 預言家難題”(oracle problem)。這需要我們的預言家 (也就是測試的基準) 清楚地了解在給定特定輸入和環境條件組合的情況下，應用程序應有的行為。將測試基準進行自動化是很困難的一件事，但是很值得去追求，因為這不僅僅可以創建一個很有價值的測試工具，其本身也是一個啟迪智慧的追求過程。無論你最終是否成功的是測試基準自動化了，強迫你自己像它一樣思考，常常比你可能選擇做其他任何事更有工作效率。

4. 汝不應崇拜無法重現的失效

這條誡律的教育意義是雙向的。第一，盡你最大的努力注意并記住 (或記錄下來) 對軟件才去的動作次序，同時記住應用程序的響應。第二，考慮使用調試器之類的能追蹤動作和軟件狀態的工具。

5. 汝應尊重你的模型和自動化測試

誡律 1 是關于隨機測試的重要性 ------ 重點在于隨機。而這條誡律是關于智能的隨機測試 ------ 重點在于智能。把智能和自動化測試合二為一，其結果就是基于模型的測試 (model-based testing)。這是主導未來的自動化測試技術。
好的模型可以使自動化測試足夠聰明，能響應錯誤和覆蓋那些笨拙的自動化測試無法覆蓋的代碼。哪怕你沒有耐心實現自動化建模，進行建模的過程也至少能讓你更好地準備測試。

6. 汝應利用開發人員的過錯與他們作對

如果開發人員編寫某個模塊時犯了一個錯誤，我們應該假設其它開發人員在類似的模塊中可能會犯同樣的錯誤。如果某個開發人員傾向于寫死循環，那么我們需要保證在該開發人員編寫的每個模塊都需要測試這類錯誤。這就是” 從經驗中學習”，我們的任務是保證我們的開發人員采取正確的行為：理解他們的錯誤模式，從而避免那些錯誤。

7. 汝應醉心于謀殺應用程序

作者清楚地記得他的第一個藍屏缺陷，它好像就發生在昨天。任何一個缺陷不能不進行深入調查就輕易放過。這條誡律的教育意義是在每一個好的缺陷背后，都可能隱藏這一個更好的缺陷。在確實了解缺陷的影響程度和破壞力之前永遠不要停止探索。

8. 汝應保持安息日的圣潔

作為測試人員，我們只是需要在給定的時間之內完成盡可能多的工作。我們不應該抱怨發布日期，而是應該提前警告后果。這是我們的職責范圍，也是我們應該擔心的范圍。

9. 汝應貪圖開發人員的源代碼

如果可以接觸到源代碼，就好好利用它。我們應該像一個測試人員而不是像開發人員那樣利用源代碼。閱讀源代碼可以學習到很多東西。閱讀源代碼時，我工作列表上的第一項就是尋找錯誤處理代碼和能為我們指明錯誤代碼正在執行的對話框。從用戶界面上最難見到或得到的代碼就是錯誤處理代碼。花時間理解代碼中寫了哪些錯誤處理，哪些輸入能觸發它們，這樣做是值得的。

總結

以上是生活随笔為你收集整理的探索式软件测试学习笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。