資料結構
網路
關係資料庫管理系統 (RDBMS)
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
服裝設計
法學什麼是探索式測試？（型別、示例）
探索式測試經常用於以異常的方式破壞系統。探索式測試最顯著的特點是它缺乏任何用於建立測試用例的測試設計方法。
此過程通常用於識別軟體缺陷。由於探索式測試缺乏測試用例，因此通常在沒有文件的情況下進行。
仔細看看這個過程。探索式測試是一種屬於“非結構化測試”類別的測試。
結構化測試與非結構化測試
結構化測試 - 此方法編寫了測試過程中發生的一切，從測試用例的開發到它們的順序執行。測試人員在執行測試時會遵循此指令碼。
非結構化測試 - 此方法通常透過猜測錯誤來進行測試，測試人員在測試過程中構建測試用例。
探索式測試
探索式測試是指即興進行的測試。如上所述，它是一種非結構化測試技術，在測試過程開始之前沒有制定系統的策略。因此，在測試之前不會進行任何需求規範或測試用例的準備和設計。
探索式測試通常由熟悉被測程式的測試人員進行，包括程式的功能和工作方式。這種測試是透過使用猜測錯誤隨機構建測試用例並執行它們來進行的，而不考慮任何測試標準。
查詢程式中可能存在錯誤的區域是此測試的一個重要方面。因此，它也稱為猴子測試或隨機測試。因此，只有那些對產品有深入瞭解的測試人員才能執行此測試。
探索式測試的優點是可以節省在諸如測試需求、測試用例規劃和設計等文件上花費的時間。它通常在完成結構化測試後進行。這樣做是為了發現遵循先前準備的測試用例無法發現的軟體問題。
探索式測試型別
以下是探索式測試的一些型別：
- 夥伴測試
- 猴子測試
- 結對測試
夥伴測試
在這種型別的探索式測試中，至少兩個人一起進行測試。這個團隊通常由至少一名軟體測試人員和一名軟體開發人員組成。
這種型別的測試發生在模組的單元測試完成後。
在這兩個“夥伴”在該模組上協作以開發有效的測試用例。
這樣做是為了確保測試人員不會報告由不正確的測試用例引起的錯誤。這種測試也可以被認為是單元測試和系統測試的混合體。
猴子測試
“猴子測試”一詞指的是這種測試中使用的方法的不可預測性。
向被測程式提供隨機輸入，並監視其關聯的輸出。
根據獲得的輸出，識別任何錯誤、不一致或系統故障。
結對測試
這種型別的測試類似於夥伴測試。但是，在這種情況下，只有一對測試人員協作測試模組。
他們透過在同一臺計算機上分享想法、觀點和專業知識來協作發現缺陷和問題。
為了獲得對每個問題的不同視角，測試人員會根據他們的知識水平和經驗進行配對。
探索式測試的特點
此測試發生在程式經過正式測試方法後。原因是進行探索式測試是為了發現測試前無法預見的應用程式異常。
只有那些深入瞭解程式工作原理的測試人員才能進行這種測試。這是因為只有當測試人員瞭解程式的功能和工作方式時，才能進行有效的“錯誤猜測”。
探索式測試方法最適合檢測應用程式中導致嚴重缺陷的不一致之處。此類錯誤通常難以發現。
這種型別的測試比其他型別的測試需要更少的時間。這是因為它是在沒有任何先前的規劃、設計或結構的情況下進行的。
探索式測試只進行一次，因為任何發現的缺陷都需要重新測試。
探索式測試示例
更改瀏覽器設定時測試應用程式的功能。例如，識別在不同瀏覽器中停用 JavaScript 選項時發生的錯誤。
在多個平臺上測試應用程式。測試生成的應用程式是否在各種作業系統和瀏覽器上平穩執行至關重要。
向系統提供超出有效輸入範圍的輸入，以檢視應用程式的響應是否足夠。
複製和修改應用程式的 URL 以使其在不同的瀏覽器中執行。這樣做是為了確保不會向任何未經授權的使用者授予對系統的未經授權的訪問許可權。
執行一系列隨機操作或在程式中隨機跳轉，以驗證使用某些奇數輸入組合獲得的結果。
何時應進行探索式測試？
當沒有足夠的時間進行全面徹底的測試（包括生成測試需求文件、測試用例和測試用例設計）時，通常會使用探索式測試。在完成正式測試方法後是進行此類測試的最佳時間。
另一方面，探索式測試可以在軟體開發過程中進行。它可以在程式完全建立後進行，甚至可以在僅建立少數模組後進行。它也可以作為正式測試過程的一部分進行。但是，有一些情況不需要進行此測試。因此，每個測試人員都必須知道何時避免此類測試。
以下是一些不應進行探索式測試的原因：
在進行 Beta 測試時，不應進行任何探索式測試。這是因為 Beta 測試涉及客戶評估生成的軟體，以便為應包含的新功能提出想法或修改其需求。
還建議不應在此測試中對已經包含問題的測試用例進行測試。在可以從系統中刪除錯誤之前，必須首先正確記錄它們。修復錯誤後，必須重新測試測試用例以確認它們執行正常。
探索式測試有哪些好處？
探索式測試的一個好處是，當僅使用正式測試方法時，可以發現許多未被發現的錯誤。透過隨機測試程式可以發現這些錯誤。
允許測試人員根據他們的直覺和對程式的理解隨意探索程式。然後，他們可以在繼續進行測試時執行測試，幫助他們在進行過程中識別錯誤。
測試人員和開發人員都可以輕鬆測試應用程式，因為不需要準備和建立任何測試用例。這使得開發人員更容易編寫更有效且無錯誤的程式碼。
此測試還可以幫助建立獨特的測試場景，這些場景可以有效地發現問題。因此，此類測試用例可以與正式測試中的其他計劃測試用例相結合。
由於探索式測試沒有正式方法，因此可以在軟體開發生命週期的任何時間點進行。
它可以與其他測試方法結合使用，以建立更明智和有效的發現。
探索式測試的缺點
由於測試方法未定義且未執行任何具體的測試用例，因此測試人員難以重現問題。這是因為測試人員必須記住他為獲得錯誤而採取的確切步驟，這並非總是可行的。
有時會報告錯誤的錯誤，這是因為測試人員隨機執行無效的測試用例，這會在後續的錯誤糾正操作中造成問題。
如果測試人員不瞭解被測應用程式的工作原理，則探索式測試將無法發現任何錯誤。這是因為測試人員必須透過猜測錯誤並在執行中構建和執行測試用例。
探索式測試不能保證發現錯誤。積極的錯誤猜測測試完全取決於測試人員的能力和經驗。
由於沒有預先建立和記錄的測試用例，因此無法確定此測試需要投入多少時間和精力。在某些情況下，即使發現一個錯誤也可能需要很長時間。
進行臨時測試：最佳實踐
為了正確執行臨時測試方法，理解最有效率的方法至關重要。因為如果測試沒有正確完成，投入的時間和精力就會浪費。因此，為了進行這種測試，必須瞭解可以幫助更全面地進行測試的最佳實踐。
軟體專業知識
確保分配給應用程式臨時測試的測試人員對應用程式有透徹的瞭解。
為了更好地支援對應用程式的“錯誤猜測”，測試人員必須熟悉程式的所有功能。
擁有足夠的資訊來支援測試人員的測試方法，可以更輕鬆地發現更多錯誤、缺陷和不一致之處。
識別潛在的易錯區域
如果測試人員不熟悉該程式，最佳方法是讓他們從查詢應用程式中發生大部分錯誤的部分開始測試。
為臨時測試選擇此類敏感位置可能有助於發現問題。
確定測試中應優先考慮的區域。
最好從程式中終端使用者或客戶最常使用的部分開始測試。這有助於保護關鍵功能並及早發現任何錯誤。
制定粗略的測試計劃。
儘管臨時測試不需要任何預先準備或文件，但基本的策略可能非常有益且高效。只需記下需要測試的重要要點和位置，就可以幫助測試人員在最短時間內覆蓋大部分程式。
工具
為了使測試更容易，您將需要必要的工具，例如偵錯程式、任務監視器和分析器。
3000+ 次瀏覽
