Exploratory Software Testing

標籤：

最近找到去年上半年看過一本關於測試方面書籍的總結筆記，一直放在我的個人隨身碟裡，當時是用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）蘇格蘭酒吧測試法  適用於大規模的複雜應用程式。對於程式某些地方，測試人員需要事Crowdsourced Security Testing道如何看到他們。可以找到使用者組並參與他們的討論，讀產業部落格，花大量時間深入瞭解待測的應用程式。

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）混票測試法  從一個情境跳到另一個，從而把兩個或者更多情境結合為一個具有混合目的的情境。檢查所有的情境並找出那些通用資料，側重於通用功能。

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

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

Exploratory Software Testing