什麼是探索性測試?(技術、示例)
顧名思義,探索性測試是關於觀察和了解程式,它做什麼,它不做什麼,什麼有效,什麼無效。測試人員始終在決定接下來檢查什麼以及在哪裡投入他或她(有限的)時間。當沒有或很少有需求並且速度至關重要時,此方法特別有用。
探索性測試可以與其他方法結合使用。
什麼是探索性測試?
探索性測試是一種實踐方法,測試人員儘可能少地進行準備,儘可能多地進行測試執行。
測試計劃過程從生成測試章程開始,測試章程是對一個簡短的(1 到 2 小時)時間盒測試嘗試範圍的簡要陳述,以及要使用的目標和潛在方法。
通常,測試設計和執行操作同時進行,不記錄測試條件、測試用例或測試指令碼。但這並不排除使用其他更正式的測試程式。例如,測試人員可以選擇進行邊界值分析,但只會考慮和測試最關鍵的邊界值,而不會將其寫下來。在探索性測試會話期間,會做一些筆記,以便稍後進行審查。
在執行測試時,會進行測試記錄,記錄已檢查內容的基本部分、發現的任何缺陷以及關於未來可能測試的任何建議。
它還可以用來補充其他更正式的測試,從而增加對程式的信任。在這種方法中,探索性測試可以作為對正式測試過程的檢查,幫助發現最關鍵的問題。
[Kaner,2002] 和 [Copeland,2003] 討論了探索性測試。[Whittaker,2002] 描述了更多探索性測試方法(“攻擊”)。
何時使用探索性測試?
探索性測試在 SDLC(軟體開發生命週期)的早期階段非常有用,此時程式正在經歷頻繁的修改。
開發人員可以使用此方法執行單元測試,而測試人員可以使用此方法熟悉應用程式。
探索性測試專業知識可能有助於在軟體開發生命週期的後期編寫測試指令碼並進行更多測試。
在敏捷開發環境中,衝刺週期很短,構建嚴格的測試設計和指令碼存在設計時間限制。由於能夠跟上短衝刺週期,探索性測試非常適合敏捷環境。
在進行探索性測試時,測試設計是在過程中建立的,這為測試人員節省了大量時間。可以在每個衝刺週期結束時收集關鍵的探索性測試,以供將來的衝刺使用。
測試方法 - 如何進行探索性測試?
要進行測試,請利用測試人員自行調整事物的能力。
測試用例的計劃和實施是同時進行的。
由於測試人員的發現,測試用例的數量不斷增加。
測試人員將他們學到的東西應用到考試中。
等價劃分、錯誤猜測、決策表測試、邊界值分析和其他測試方法可以與探索性測試整合。
測試人員可以在專注於任務的同時將他們的想法付諸實踐。
探索性測試不使用測試自動化,而是依靠測試人員的專業知識、洞察力和技能。
探索性測試可以基於會話來保持注意力並提供結構。
探索性測試的優點
需要最少的準備,並且可以快速發現關鍵錯誤。
建議進行批判性思考並快速響應,並且可以發現更多缺陷。
對於測試人員來說,更加註重擴充套件他們的專業知識和理解。
它可以用來檢查其他測試人員的工作。
探索性測試可以發現測試用例中可能未被發現的缺陷。
當時間緊迫時,可以使用探索性測試來評估新功能,而可以使用迴歸測試來評估現有功能。
探索性測試的缺點
由於測試是隨機建立和執行的,因此無法事先檢查,並且可能難以確定必須執行哪些測試。
測試依賴於測試人員的專業知識、才能和經驗。
熟悉應用程式需要一些時間,因此如果測試人員不熟悉網站或程式,則有可能忽略問題。
探索性測試示例
假設某人在沒有地圖的情況下駕駛車輛到新區域的某個地點。駕駛汽車的人將採用各種標準策略到達那裡,包括:
獲取周邊區域的地圖
隨機方向行駛以找到位置
聯絡朋友並詢問路線
前往附近的加油站詢問路線
類似的概念可以應用於探索性測試。
假設您已獲得對醫院管理系統進行探索性測試的任務。
探索性測試有多種方法。
猜測
猜測用於識別軟體中更可能包含錯誤的區域。先前在類似產品/軟體/技術上的工作經驗有助於猜測。
在醫院管理系統的示例中,您可以預期付款元件會存在更多錯誤,因為它必須連線到支付閘道器;如果未正確管理,交易可能會超時並導致問題。
架構圖和用例
架構圖描繪了不同元件和模組之間存在的連線和連結。用例從使用者的角度提供了對產品功能的瞭解。
這些圖紙和用例可用於探索方法中以測試產品。
醫院管理系統 - 您回想起一個用例,其中許多人可以使用相同的電話號碼,並且應用程式必須允許它;您決定測試這種情況。
您還從架構圖中回想起,報告功能與主應用程式單獨部署,並且生成和傳送給使用者需要幾分鐘時間,因此您決定對其進行測試,以確保生成報告並正確配置電子郵件功能。
過去的缺陷
檢查過去版本中遇到的問題有助於識別程式哪些方面最可能存在缺陷。
以前,醫院管理系統的報告模組曾經佔用大量 RAM 並存在各種錯誤,因此您決定對其進行測試。
錯誤處理
錯誤處理是在系統發生故障時啟動必要措施的程式碼部分。可以使用各種場景執行探索性測試以驗證友好的錯誤處理。
醫院管理系統的報告模組會佔用大量記憶體,有時會崩潰。您決定對其進行測試,以確保即使出現問題,也能夠儘快生成已儲存到生產環境中的結果。
討論
探索性測試也可以根據專案討論和簡報中對軟體的理解來制定。
問題和清單
諸如“什麼、何時、如何、誰和為什麼”之類的問題可能會為探索性軟體測試提供提示。
探索性測試的類別
自由式探索性測試
在自由式探索性測試中,應用程式是自發地檢查的,幾乎沒有標準或流程。但是,探索性測試在以下情況下可能會有所幫助:
測試人員必須快速熟悉程式。
測試人員必須確認其他測試人員的工作。
測試人員必須調查缺陷。
測試人員希望儘快完成冒煙測試。
基於場景的探索性測試
基於場景的探索性測試涉及根據場景執行測試。場景可能由客戶提供或由測試團隊建立。在早期測試之後,測試人員可以根據新獲得的資訊和能力開發測試。
基於策略的探索性測試
基於策略的探索性測試將決策表測試、因果圖和錯誤猜測等常見測試方法與探索性測試相結合。此類測試的優秀測試人員將是熟悉應用程式的人。
敏捷中的探索性測試
敏捷方法使用大約一個月長的短衝刺,並有非常嚴格的時間表。由於時間短且注重即時結果,探索性測試在敏捷中非常有效。一旦測試人員理解了標準,他或她就可以根據其專業知識和理解進行測試。
隨著測試人員越來越熟悉應用程式的功能和操作,他將能夠為將來的測試設計額外的測試用例,並可能發現更多缺陷。
由於敏捷中的探索性測試獨立於正式程式和文件要求,因此測試人員不需要為所有內容保留文件,但保留嘗試過的物件、檢測到的問題等的簡要報告以供將來參考將很有用。
敏捷中探索性測試的優點
可以向開發團隊提供有關專案的即時反饋。
可以發現各種各樣的缺陷。
由於每個人可能擁有不同的視角,並且沒有特定的測試用例,因此開發人員、測試人員、設計師和業務分析師可能會進行探索性測試。
如果當前需求不可靠,則探索性測試可能有助於在有限的時間範圍內評估新需求。
探索性測試與自動化/指令碼測試的區別
探索性測試 | 自動化/指令碼測試 |
---|---|
在探索性測試的情況下,不需要保留文件。 | 在進行自動化測試時,需要大量的文件。 |
這種方法在測試執行之前幾乎不需要或不需要準備時間。 | 在此策略中,在測試開始之前必須經過大量的時間。 |
生成文件和閱讀文件都沒有成本。 | 在測試執行之前,編寫測試指令碼和開發文件需要大量工作。 |
在探索性測試中,沒有明顯的或可量化的測試覆蓋率。 | 為了驗證測試覆蓋率,可以將測試指令碼追溯到原始標準和需求。 |
根據測試人員對應用程式如何執行的瞭解和資訊來評估應用程式。 | 根據標準測試應用程式。 |
在此方法中,只能複製問題;不能進行測試。 | 測試可以簡單地複製。 |
探索性測試的實際示例
在處理即時專案時,可能會要求測試人員進行即時探索性測試,以任意測試程式的各個方面以發現問題。探索性測試方法可用於評估來自任何領域的應用程式,例如電信、醫療保健和金融。換句話說,探索性測試方法不是特定於領域的。
通常,當測試人員希望測試程式的某些功能時,探索性測試最有用,這些功能在開發團隊給定程式碼版本中未解決任何問題。換句話說,探索性測試在現實環境中進行健全性檢查更有益。
探索性測試面試問題
什麼是探索性測試,以及何時應該進行探索性測試?
您如何進行探索性測試?
探索性測試的主要優點和缺點是什麼?
探索性測試的多種型別是什麼?
探索性測試與自動化/指令碼測試的主要區別是什麼?
提供探索性測試的示例。
探索性測試總結
探索性測試不是一種傳統的測試方法,但它是一種非常有效的應用程式測試方法。
它鼓勵稱職的測試人員跳出框框,為問題檢測建立即時測試場景。由於探索性測試是非結構化的,因此可以在任何需要最少文件的流程上進行,無論它是在使用敏捷方法、瀑布模型還是任何其他軟體開發生命週期原型。