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

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

什么是探索式測試

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

它的本質(zhì)是測試策略，邊學(xué)習、邊設計、邊測試、邊思考。換句話(huà)說(shuō)，探索式測試是測試人員自發(fā)進(jìn)行的測試工作，在執行測試的同時(shí)根據所獲得的信息來(lái)設計測試策略的方法。它強調要根據當前的實(shí)際情況來(lái)選擇最合適的測試技術(shù)，進(jìn)行測試。測試人員使用探索式測試從客戶(hù)的角度評估軟件的實(shí)際工作方式。它更注重的是「思考」和「學(xué)習」，不斷的發(fā)現新的問(wèn)題。

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

為什么探索式測試很重要

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

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

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

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

雖然不用事先創(chuàng )建測試用例，但是測試人員通過(guò)發(fā)散性的思維去思考每個(gè)模塊、每一步甚至每個(gè)按鈕可能會(huì )出現的缺陷問(wèn)題，可以讓測試人員的時(shí)間和精力更多地集中在創(chuàng )造性地思維上，發(fā)現更多隱藏的缺陷。

比如:

我模擬成為一個(gè)用戶(hù)做一些常用操作，一定可以發(fā)現傳統測試測不到的 BUG

在發(fā)現 BUG 的地方，一定可以發(fā)現更多的 BUG

在了解開(kāi)發(fā)的架構后，一定可以找到更隱蔽的更深層的 BUG

……

對于對產(chǎn)品質(zhì)量有近乎完美的「偏執狂」來(lái)說(shuō)，發(fā)散性的思維是一個(gè)完美測試人員的利器，一些隱藏的難以發(fā)現的缺陷，確實(shí)要求測試人員有發(fā)散性思維才能比普通的測試看的更多更廣更犀利。

探索式測試準備

理解探索式測試有兩個(gè)前提：

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

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

探索式測試的類(lèi)型

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

自由式探索式測試

基于場(chǎng)景的探索式測試

基于策略的探索式測試

基于反饋的探索式測試

如何進(jìn)行探索式測試

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

與項目組產(chǎn)品、開(kāi)發(fā)人員溝通，獲取更多業(yè)務(wù)信息和系統架構信息，以確定更多的風(fēng)險點(diǎn)。

與其他測試人員溝通，確定風(fēng)險點(diǎn)最高的模塊或功能點(diǎn)。

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

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

測試的過(guò)程中記錄軟件邏輯，發(fā)現 BUG，給開(kāi)發(fā)人員建立缺陷。

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

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

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

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

商業(yè)區：銷(xiāo)售特性，對應軟件包裝上面的對應特性，類(lèi)似我們的需求。

歷史區：繼承特性，上一個(gè)版本遺留下來(lái)的代碼、問(wèn)題或則曾經(jīng)出現多次 BUG 的功能或者特性。

旅游區：噱頭特性，即對應產(chǎn)品的新特性，能夠去更好的吸引新的用戶(hù)。

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

旅館區：平臺或維護特性，對應軟件內部的一些交互，不一定是由用戶(hù)來(lái)觸發(fā)的。

破舊區：?jiǎn)?wèn)題高發(fā)區，對應軟件的歷史穩定的代碼，一般很少人去接觸。

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

這里我們拿「Web 應用升級部署」來(lái)實(shí)踐該方法。

首先，我們先了解需要測試的模塊、功能點(diǎn)以及相關(guān)的內部邏輯。

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

執行探索式測試計劃，在測試的過(guò)程中按照旅行者測試方法的思路來(lái)創(chuàng )建用例：

按照旅行者測試方法的區域寫(xiě)出當前區域可能會(huì )發(fā)生的問(wèn)題，然后套用每個(gè)區域的方法引申出更多的潛在問(wèn)題，并依此進(jìn)行測試。

記錄用例的測試結果：

測試完畢

哪個(gè)測試點(diǎn)出了問(wèn)題，那么我們就應該重視該問(wèn)題，并在此基礎上發(fā)散，比如：

「系統重啟后應用無(wú)法啟動(dòng)」，我們知道了是因為磁盤(pán)沒(méi)有掛載，導致啟動(dòng)失敗，那么服務(wù)器防火墻被重置是否也會(huì )造成無(wú)法啟動(dòng)呢？那么這個(gè)問(wèn)題將在下次測試的時(shí)候執行。

最后，來(lái)看下我們的探索式地圖的設計：

可以看到通過(guò)探索性測試方法已經(jīng)分析出來(lái)了一些測試點(diǎn)，探索性測試另外一個(gè)重要的地方就是邊測試邊寫(xiě)測試點(diǎn)，過(guò)程中不斷分析、不斷學(xué)習，然后行程新的探索性測試點(diǎn)，這樣才能完成一次成功的探索性測試。

另外還有局部探索式測試和混合探索式測試方法，本文因篇幅問(wèn)題將不展開(kāi)論述。

結論

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

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