資料結構
網路
關係型資料庫管理系統
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C 程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
時尚研究
法律研究測試型別 – 綜合列表
測試是執行軟體並查詢缺陷的過程。為了使我們的程式有效地工作，它必須沒有錯誤。如果測試成功完成，程式將沒有任何故障。
測試原則
以下是軟體測試的主要原則：
所有測試都必須滿足客戶的需求。
為了使我們的軟體測試更有效，我們應該使用第三方。
不可能進行詳盡的測試。我們需要根據應用程式的風險評估進行最佳數量的測試。
所有將要進行的測試都應在執行之前做好準備。
它遵循帕累托法則（80/20 法則），該法則聲稱 80% 的軟體錯誤是由 20% 的程式元件引起的。
從較小的元件開始，逐步擴充套件到較大的元件。
現在讓我們詳細討論各種**測試方法**。
單元測試
它專注於軟體開發中最小的方面。在這裡，我們測試單個單元或一組相互關聯的單元。程式設計師通常透過使用示例輸入並檢視相應的輸出結果來執行此任務。
示例
在程式中，我們檢查迴圈、方法或函式是否正常工作。
算術優先順序被誤解或錯誤。
初始化不完整或不正確
單元測試的優勢
單元測試為希望瞭解單元提供的功能以及如何使用它的開發人員提供了單元 API 的基本概述。
單元測試使程式設計師能夠在以後重寫程式碼，同時確保模組繼續正常工作（即迴歸測試）。實踐是為所有函式和方法建立測試用例，以便可以快速發現和糾正導致問題的任何更改。
由於單元測試的模組化結構，我們可以測試專案的各個部分，而不必等待其他人完成。
單元測試的缺點
期望單元測試能夠捕獲軟體中的每個錯誤是不現實的。即使在最簡單的程式中，也不可能評估所有可能的執行路徑。
根據定義，單元測試專注於一段程式碼。因此，它無法檢測整合或系統範圍的問題。
整合測試
目標是採用經過單元測試的元件，並使用它們來建立由設計決定的程式結構。整合測試涉及組合多個元件以實現結果。
整合測試有四種類型： (i) 自頂向下 (ii) 自底向上 (iii) 三明治 (iv) 大爆炸
示例
**黑盒測試** - 它是驗證工具。我們忽略底層工作機制，專注於結果。
**白盒測試** - 它是驗證工具。本節重點介紹內部機制，或如何產生輸出。
整合測試的優勢
整合測試具有以下優勢：
整合測試是一種系統地將軟體系統組合在一起並執行測試以查詢與介面相關的問題的方法。
測試應用程式以確保它滿足客戶的需求，並向開發團隊保證單元測試期間做出的假設是有效的。
整合測試不必等到系統的所有模組都編寫完成並進行單元測試後才能開始。相反，它可以在必要的模組可用時立即開始。
整合測試，通常稱為增量測試，是確保軟體模組協同工作所必需的。
系統整合測試中使用的策略包括增量、自頂向下、自底向上、三明治和大爆炸整合方法。
整合測試的缺點
整合測試的缺點包括：
軟體行業使用多種方法進行整合測試，包括：
大爆炸方法
增量方法進一步細分為以下部分。
自頂向下方法
自底向上方法
三明治方法結合了自頂向下和自底向上方法。
迴歸測試
每次新增新模組時，應用程式都會更新。這種形式的測試確保整個元件即使在將其他元件新增到程式後也能正常工作。
示例
在學校記錄中，假設我們有教職工、學生和資金的模組。組合這些模組並確認它們在整合後是否正常工作就是迴歸測試。
迴歸測試挑戰
以下是最常見的迴歸測試問題：
隨著執行更多回歸執行，測試套件的大小會增加。由於時間和財務限制，無法執行整個迴歸測試套件。
在最大限度地減少測試套件的同時仍然獲得最大覆蓋率是一項艱鉅的任務。
確定迴歸測試的頻率（例如，在每次修改、構建更新或一組問題補丁之後）很困難。
4. 煙霧測試
此測試確保被測程式已準備好或穩定，以便進行進一步評估。它被稱為煙霧測試，因為它是用來檢視它在第一次開啟時是否著火或產生煙霧。
例如，如果一個專案包含兩個模組，請確保模組 1 正常工作，然後再繼續執行模組 2。
煙霧測試的優勢
它有助於在測試過程中儘早發現問題。
它有助於檢測由於元件整合而產生的問題。
它有助於確保先前版本中修復的錯誤不會影響應用程式的主要功能。
要進行煙霧測試，只需要少量測試用例。
煙霧測試可以在短時間內完成。
煙霧測試有一些缺點。
煙霧測試不涵蓋廣泛的測試。
因為它是非詳盡測試，並且測試用例數量很少，因此我們無法發現其他嚴重缺陷。
5. Alpha 測試
這就是驗證測試。它是一種驗收測試，在產品向公眾釋出之前進行。QA 人員通常負責此項工作。
示例
當公司的軟體在內部進行測試時，稱為內部軟體測試。
進行 alpha 測試的優勢
**您完成了充分而嚴格的測試** - alpha 測試中使用了黑盒測試和白盒測試。使用黑盒測試方法將徹底測試系統的輸入和輸出功能。另一方面，白盒方法檢查系統的體系結構和內部結構。對於所有必需和可能的場景，檢查產品的輸入和輸出流至關重要。
**提高軟體質量** - alpha 測試包括在與將要使用的環境類似的模擬環境中對系統進行壓力測試。這會產生真實的測試場景，盡力與終端使用者產生共鳴。當然，如果程式進入 beta 測試，團隊將獲得來自真實使用者的反饋。任何和所有早期反饋都應該大大提高最終產品的質量。
**大量可用性和可靠性見解** - alpha 測試使開發人員能夠了解系統在釋出後將如何執行。產品團隊將能夠評估系統的效能並對其可用性和可靠性有一個初步的瞭解。這些見解將幫助產品團隊做出關於系統未來改進的最佳決策。
**alpha 測試幫助測試團隊**提前檢測潛在的生產問題，從而減少返工並加快交付時間表。這使開發團隊能夠在系統上線之前識別和解決任何潛在的生產問題。這減少了開發中的返工以及交付後續更新所需的時間。
進行 alpha 測試的缺點
alpha 測試是開發過程中的一個重要組成部分，我們始終建議團隊為此分配時間和資源。
但是，alpha 測試也有一些缺點。幸運的是，瞭解它們應該有助於減輕它們的影響
Alpha 測試需要更長的測試執行時間：在 Alpha 測試期間，將對整個產品進行高級別和深入的測試，並利用各種黑盒和白盒方法。因此，測試執行週期將需要更長的時間才能完成。測試周期的長度還取決於產品的特性以及在此過程中發現的問題數量。如果產品具有更多功能並且發現了大量缺陷，則測試過程將花費更長時間。
虛擬環境下對非功能性需求的測試是有限的。
6. Beta 測試
Beta 測試由軟體的終端使用者在一個或多個客戶地點進行。此版本僅提供給一小部分人進行即時測試。
示例 - 當軟體測試針對一小部分人群進行時，
7. 系統測試
該程式已進行全面測試，以確保它與各種作業系統相容。它由黑盒測試方法涵蓋。在這種情況下，我們只關注所需的輸入和輸出，而不關注內部操作。
包括安全測試、恢復測試、壓力測試和效能測試。
示例 - 這包括功能測試和非功能測試。
8. 壓力測試
在這個實驗中，我們將系統置於不利環境下，並觀察它的反應。
示例
執行需要最多記憶體或其他資源的測試用例。
在虛擬作業系統中，可能會導致爭用的測試用例
可能需要大量儲存空間的測試情況
9. 效能測試
其目的是評估軟體在整合系統環境下的執行時效能。它用於檢視軟體的速度和效率。它也被稱為負載測試。它確定系統在特定負載下的效能。
例如，檢查處理器週期數。
10. 面向物件測試
這種測試方法結合了許多不同的測試方法來評估和驗證面向物件的軟體。此測試按如下方式執行 -
需求測試，
設計和分析測試，
程式碼驗證
整合測試，
系統評估，
使用者測試
274 次檢視
