最近找到去年上半年看過一本關于測試方面書籍的總結筆記，一直放在我的個人U盤里，當時是用Xmind記錄的，現在重新整理下分享給大家了！

James A.Whittaker [美]?詹姆斯·惠特克（軟件測試領域絕對的大師）著作《Exploratory Software Testing》，中文名《探索式軟件測試》，記得當時被這本書深深吸引啦（我不知道有多少做測試的小伙伴看過這本書）！感覺是測試方面一本必不可少的書籍，瞬間感覺測試的魅力！廢話不多說，直接來干貨，希望可以給對探索式測試喜歡或者感興趣的小伙伴一點幫助！

測試人員進行測試時必須回答如下的問題。
(1)軟件運行時的表現是否符合設計預期？
(2)用戶為了某個功能而購買了軟件，可是該軟件是否實現了這個功能？
(3)軟件運行時，是否足夠快、足夠安全、足夠穩定，等等？

從許多方面來講，測試的目的就是在這次測試中盡最大努力，同時確保下次可以做得更好。恰好探索式測試法可以提供很好的指導。

主要有兩種指導方法，它們都可以幫助測試人員做具體決策。一種稱為局部探索式測試法，它輔助測試人員在測試過程中即時作出決定。另一各稱為全局探索式測試法，它用于幫助測試人員設計整體測試計劃和測試策略。
如果把探索式測試和實質和使用腳本的手工測試合并起來，可以得到第三種探索式測試法，即混合探索測試技術。下面將分三部分來說明：

一、局部探索式測試法(exploratoy testing in the small)

此方法輔助測試人員在測試過程中即時作出決定。測試人員不需要知道很多信息就可以完成某些測試，比如決定文本框的輸入值，如何解釋錯誤消息，如何理解前一次后一次輸入值之間的關系。

解決測試人員很多細節問題，它并不適合建立一個完整的測試架構，也不應該用于測試用例的整個設計過程。

主要關注下面五個方面：

1、用戶輸入 ?輸入指的是由環境產生的一種刺激，該刺激導致被測試的應用程序有所響應。
? ? ? ? ? ? ? ? ? 測試包括合法輸入和非法輸入、輸入篩選器、輸入檢查、異常處理代碼、默認輸入或用戶提供的輸入、使用輸出指導輸入選擇。

2、狀態 ?軟件的一個狀態就是狀態空間中的一個點，它由所有內部數據結構的取值來唯一確定。

? ? ? ? ? ? 應用程序和其運行環境進行交互和接收到的所有輸入導致軟件狀態發生變化。測試人員就是測試這些狀態變化的情況。測試其是否正確更新了自身的當前狀態？是不是進入了一些它不應該進入的狀態？
? ? ? ? ? ? 輸入和狀態之間的關系相當關鍵，在局部探索式測試法建議如下方式：
? ? ? ? ? ?1）使用狀態信息來幫助尋找相關的輸入
? ? ? ? ? ?2）使用狀態信息來辨識重要的輸入序列

3、代碼路徑 ?一條代碼路徑就是一連串的代碼語句，它起始于軟件開始運行的語句，終止于一條特定的語句，往往就是那條代表軟件運行結束的語句。

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

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

5、運行環境 ?就是使用的操作系統和它的當前配置，還包括運行在同一操作系統上會和被測試軟件進行交互的其他一些應用程序，包括會間接或直接影響被測軟件本身或影響被測軟件運行的任何驅動程序、代碼、文件、設置等，還包括軟件當前連接的網絡情況、網絡的可用帶寬、性能等。

二、全局探索式測試法(exploratory testing in the large)

此方法用于幫助測試人員設計整體測試計劃和測試策略。幫助測試人員在全局方面所必須做出的各種決定，比如在考慮特性交互、數據流以及在應用程序的用戶界面上如何選擇不同路徑完成某些實際功能時。不再考察在單個輸入面板上充當中間用途的原子輸入，轉而討論那些可以幫助測試達到更重要目的的輸入。實際上需要我們在開始就做出一個全局目標，用于指導以后的測試過程。使用全局探索式測試法，做出的決定一僅僅影響單個的對話框或者單個用戶界面，它的范圍涉及到軟件的全局。不僅僅是確定如何測試某個單一功能，而是確定了如何對軟件進行探索式測試的整體方向。

主要參考于漫游測試，漫游測試法為測試提供了一個構架，它可以幫助測試人員創建出比使用自由發揮的方式更有趣、也更有針對性的用戶場景。它也為測試人員設定了一個目標，引導他們嘗試更有趣和復雜的使用路徑。漫游測試既能幫助測試人員思考如何測試應用程序，又能幫助他們組織實際的測試。當然這一系列的測試法可以編成一張測試核對表，這樣可以避免測試人員遺漏某種測試類型，也可以幫助測試人員把應用程序的功能和適合這些功能的測試技術相匹配。

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

根據漫游測試把軟件不同區域類型，下面就不同區的相應測試一一說明：

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

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

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

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

4）極限測試法 ?測試人員采用的途徑是向軟件提出很多難以回答的問題。比如如何使軟件發揮到最大程度？哪個特性會使軟件運行到其設計極限？

5）快遞測試法 ?測試人員專注數據。應該確認那些被存儲起來的輸入數據并“跟隨”它們走遍軟件。

6）深夜測試法 ?測試人員關注主要特性外的代碼運行情況，如各種維護任務等、應該程序自動做的些事情。變種的有清晨測試法，目的是測試軟件的啟動過程和腳本。

7）遍歷測試法 ?測試人員通過選定一個目標，然后使用可以發現的最短路徑來訪問目標包含的所有對象。

2、歷史區測試類型 ?主要針對老的功能和缺陷修復代碼。

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

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

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

3、娛樂區測試類型 ?這類測試幫助測試人員測試那些輔助特性，而不是主線特性，并確保這兩種特性能夠實用而又有意義地結合在一起。

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

2）深巷測試法 ?如果測試部門跟蹤了代碼的覆蓋率，這個測試法要求測試人員想辦法去測試那些還沒有被沒測到的代碼。變種混合測試法，就是試著把最流行和最不流行的特性放在一起混著測。

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

4、旅游區測試類型 ?關心的是快速訪問軟件的各種功能。

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

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

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

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

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

5、旅館區測試類型 測試人員放過那些主要的和最受歡迎的功能，而去測試一些經常被忽視的或者在測試計劃中較少描述的次要及輔助功能。

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

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

?6、破舊區測試類型?

1）破壞測試法 ?測試人員試圖利用每個可能的機會暗中破壞應用程序。a.強迫軟件做一些操作b.掌握軟件成功完成操作必須使用的資源c.在不同程序上移除那些資源或者限制使用那些資源。比如增加或者刪除文件，改變文件權限，斷開網線，在后臺運行其他應用程序，把要測試的應用程序布署在有問題的機器上等。

2）反叛測試法 ?要求輸入最不可能的數據，或者已知的惡意輸入。如果真正的用戶輸入字母a，那么使用反叛測試人員就永遠不輸入a，取而代之的是去找些沒意義的輸入值。

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

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

三、混合探索式測試技術

探索式測試可以和場景測試結合起來，幫助測試人員為給定場景引入大大小小的各種變化。如果場景描述的是用戶要采取的某些特定動作，下面的技術就可以用來改變這些動作的順序，并從場景中派生出衍生場景，用于測試不同狀態和不同代碼路徑。此技術主要使用基于場景的探索式測試，這種形式的探索式測試采用了給場景注入變化的方法。通過有系統地考慮輸入選擇、數據使用和環境條件，一個場景可以演變出許多測試用例。使用了兩個主要技術：場景操作和漫游測試。

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

1）插入步驟 ?給場景增加額外的步驟可使它們更加多樣化，從而測試更多的功能。

　　　　　　可以用到發下這些類型
　　　　　　a.增加更多數據
　　　　　　b.使用附加輸入
　　　　　　c.訪問新的界面
　　　　　　注意這些步驟最終都需要測試人員返回到原始場景。我們的目的是加強場景，而不是徹底改變場景的基本目標。

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

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

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

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

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

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

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

1）賣點測試法 ?模擬用戶已有的工作習慣，在原始場景中加入一些新功能，讓用戶使用過程通過學習某個功能，掌握它，然后隨著對應用程序的熟悉而逐漸轉移到新功能上。

2）地標測試法 ?從場景開始并從場景中選取特定功能的地標，然后隨機打亂這些地標的順序，這樣得到的場景就和原始場景不同了。如有必要，重復這個過程，不斷用新地標順序來運行測試。

3）極限測試法 ?檢查并修改場景以使軟件更加努力地工作，即挑戰軟件，向它提困難的問題。如很長的字符串輸入會產生問題嗎？

4）深巷測試法 ?關注使用最不可能用到的或者最沒有用的功能。

5）強迫癥測試法 ?重復場景中的每個步驟兩次或者三次。比如在軟件中四處移動數據歷來可以有效的找到重要缺陷。

6）通宵測試法 ?當測試場景可以被自動化或者可以被錄制回放時，最適合使用的是通宵測試法，只需要不斷重復運行場景而不需退出被測應用程序。

7）破壞測試法 ?在運行場景測試時，在資源調用處進行破壞活動。如場景要求在網絡上傳輸數據，可以執行步驟之前或者之中拔掉網線等。

8）收藏家測試 ?執行場景和衍生場景時用文檔記錄下所觀測到的每個輸出。

9）超模測試法 ?運行場景時只關注界面。確保所有元素都在它們應該在的位置上，界面應該設計合理，尤其要注意可用性問題。

10）配角測試法 ?測試人員不是執行測試腳本描述的功能，而是找到最近的鄰近功能來執行。

11）取消測試法 ?不但充分利用取消按鈕（運行場景時只要看到它就點擊），而且執行了啟動和停止功能。如在開始執行某些功能時，通過取消或者Esc來取消。

12）混票測試法 ?從一個場景跳到另一個，從而把兩個或者更多場景結合為一個具有混合目的的場景。檢查所有的場景并找出那些通用數據，側重于通用功能。

靜態場景測試和探索式（漫游）測試并不沖突。場景可以代表探索式測試的一個絕佳起點，探索可以給場景加入寶貴的變化，否則場景將很有限。明智的測試人員會把這兩種方法結合起來，以便更好地覆蓋應用程序，得到更多輸入序列、代碼路徑和數據使用的變化。

總結：凡是研究過探索式軟件測試的測試人員絕對會發現這是種可以給你們提供更多測試思路，可以找到軟件更多缺陷，從而更確保軟件的正確性、穩定性等等。當然由于其中思路方法之多，也絕不是看一兩下就可以體會的，需要測試人員多次閱讀并在實踐中努力嘗試其中的方法，不求全部用到，只用到其中一部分，我想肯定會給自己帶來很大的感受。正如大師所言，軟件測試是必不可少但有難度的事，望所有測試人員任重道遠！

轉載于:https://www.cnblogs.com/cnkemi/p/5481392.html

總結

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

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