敏捷開發模式下的利刃：探索性測試（ET）--測試用例如何設計？

探索式軟件測試是一種強大的黑盒測試思考方法，但卻被廣泛誤解。在某些情況下，它可以比自動化測試更加有生產力。它是一種經過深思熟慮的測試方式，沒有測試腳本，可以使你的測試超出各種明顯已經測試過的場景。

什么是探索式測試

探索式測試（Exploratory Testing）是一種軟件測試方法，也可以說是一種測試思維方法，最先是 Cem Kaner 在 1983 年提出的。這是一種強調個人自由與責任的測試方法，讓獨立測試人員可以借用不斷的學習來改善測試的規劃與測試的執行，而在測試的過程中也會同時改善測試案例達到相輔相成的效果。

它的本質是測試策略，邊學習、邊設計、邊測試、邊思考。換句話說，探索式測試是測試人員自發進行的測試工作，在執行測試的同時根據所獲得的信息來設計測試策略的方法。它強調要根據當前的實際情況來選擇最合適的測試技術，進行測試。測試人員使用探索式測試從客戶的角度評估軟件的實際工作方式。它更注重的是「思考」和「學習」，不斷的發現新的問題。

一般在時間相對較緊張，且測試對象說明不完善，即我們常說的「敏捷開發模式」的情況下，探索式測試可以起到突出的效果（但并不是說探索式測試是敏捷模式下特有的軟件測試方法）。

為什么探索式測試很重要

采用敏捷開發流程迫使測試團隊在更短的時間周期內完成測試。以前需要數周或數月才能測試的團隊，現在必須加速測試，以便在幾小時或幾天內提供更全面的測試結果。因此，必須在極大的時間壓力下進行測試，不僅如此還需要減少資源和預算。

由于探索式測試不需要預先進行費時費力的計劃，因此團隊通常會在開發完成后立即開始測試新功能。這促進了在極短的開發周期內快速檢測缺陷。

探索式測試是以用戶的角度來測試，它為傳統的結構化測試（即從底層開始測試）做了補充，以保護頻繁迭代的用戶體驗。這意味著探索式測試不僅關注系統設計是否良好，還關注用戶體驗，因此它更容易發現比結構測試更嚴重的缺陷。

探索式測試正在被越來越多的被應用于用戶體驗測試。它通常與傳統結構化測試形成對比，后者僅側重于系統邏輯驗證（即，是否滿足要求/用戶故事中概述的驗收標準）。結構化測試保障已知風險，而探索式測試主要側重于分析潛在風險。

雖然不用事先創建測試用例，但是測試人員通過發散性的思維去思考每個模塊、每一步甚至每個按鈕可能會出現的缺陷問題，可以讓測試人員的時間和精力更多地集中在創造性地思維上，發現更多隱藏的缺陷。

比如:

我模擬成為一個用戶做一些常用操作，一定可以發現傳統測試測不到的 BUG

在發現 BUG 的地方，一定可以發現更多的 BUG

在了解開發的架構后，一定可以找到更隱蔽的更深層的 BUG

……

對于對產品質量有近乎完美的「偏執狂」來說，發散性的思維是一個完美測試人員的利器，一些隱藏的難以發現的缺陷，確實要求測試人員有發散性思維才能比普通的測試看的更多更廣更犀利。

探索式測試準備

理解探索式測試有兩個前提：

測試之前一定會有一個全局的方針戰略，即整體的測試計劃，它可以避免走錯大方向、該測的部分沒有覆蓋到或者投入了大量時間到計劃之外的部分。

測試一旦開始，沒有固定的思路，測試人員不受任何先入為主的條條框框約束，根據測試途中獲取的信息，指導各自走不同的路徑，最終目的就是發現潛藏的缺陷。

探索式測試的類型

探索式軟件測試一共分為以下 4 種：

自由式探索式測試

基于場景的探索式測試

基于策略的探索式測試

基于反饋的探索式測試

如何進行探索式測試

從產品需求文檔（PRD）和原型等文檔中獲取需要測試的范圍和深度，識別軟件的根本目的，確定需要測試的核心功能點。

與項目組產品、開發人員溝通，獲取更多業務信息和系統架構信息，以確定更多的風險點。

與其他測試人員溝通，確定風險點最高的模塊或功能點。

制定探索式測程（Session）：測程表（Session Sheet）、時間盒（Time Box）、主題（Charter）。（可參見 Session-Based Test Management）

執行探索式測試計劃，在此過程中邊測試、邊學習、邊設計、邊思考，并根據具體情況隨時更改測試策略。

測試的過程中記錄軟件邏輯，發現 BUG，給開發人員建立缺陷。

基于旅行者的全局探索性測試方法

我們可以將軟件的測試比做是去一個城市的旅游。那么我們如何快速的去到我們想去的地方呢？一個辦法就是我們對這個城市很熟悉。另外一個辦法就是找一個導游或者一份地圖，用來指導我們去在這個城市旅游。

對于軟件測試來說，我們同樣需要對被測軟件很熟悉，同時也需要一份測試地圖或者測試指南，來幫助我們更好的探索性測試。

拿到地圖后，我們可以根據地圖將城市按照功能分為各種區域，而每個區域對應軟件相應的功能。比如：

商業區：銷售特性，對應軟件包裝上面的對應特性，類似我們的需求。

歷史區：繼承特性，上一個版本遺留下來的代碼、問題或則曾經出現多次 BUG 的功能或者特性。

旅游區：噱頭特性，即對應產品的新特性，能夠去更好的吸引新的用戶。

娛樂區：輔助特性，對應軟件的輔助特性和功能，可以做完補充測試。

旅館區：平臺或維護特性，對應軟件內部的一些交互，不一定是由用戶來觸發的。

破舊區：問題高發區，對應軟件的歷史穩定的代碼，一般很少人去接觸。

每個區都有特定的測試方法，有興趣的朋友可以去買『探索式軟件測試』這本書詳細了解。

這里我們拿「Web 應用升級部署」來實踐該方法。

首先，我們先了解需要測試的模塊、功能點以及相關的內部邏輯。

然后，我們根據項目的時間確定本次測試的主題和范圍，創建一次探索式測試計劃，如下圖：

執行探索式測試計劃，在測試的過程中按照旅行者測試方法的思路來創建用例：

按照旅行者測試方法的區域寫出當前區域可能會發生的問題，然后套用每個區域的方法引申出更多的潛在問題，并依此進行測試。

記錄用例的測試結果：

測試完畢

哪個測試點出了問題，那么我們就應該重視該問題，并在此基礎上發散，比如：

「系統重啟后應用無法啟動」，我們知道了是因為磁盤沒有掛載，導致啟動失敗，那么服務器防火墻被重置是否也會造成無法啟動呢？那么這個問題將在下次測試的時候執行。

最后，來看下我們的探索式地圖的設計：

可以看到通過探索性測試方法已經分析出來了一些測試點，探索性測試另外一個重要的地方就是邊測試邊寫測試點，過程中不斷分析、不斷學習，然后行程新的探索性測試點，這樣才能完成一次成功的探索性測試。

另外還有局部探索式測試和混合探索式測試方法，本文因篇幅問題將不展開論述。

結論

探索式測試試圖把制定計劃，進行測試，重新制定計劃等多個過程有機地結合起來，每次只前進一小步，但這每一步都是由軟件過去和當前的運行狀況，軟件在測試時表現出來的各種行為和軟件運行時留下的種種蛛絲馬跡來即時確定的。有效地利用探索式測試技術可以幫助我們發布一個高質量的軟件產品。

原文轉自：http://www.uml.org.cn/Test/201812113.asp