資料結構
網路
關係型資料庫管理系統
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
時尚研究
法律研究學習軟體測試中的V模型
V模型是一種非常嚴格的軟體開發生命週期模型，其中每個開發階段都緊跟著一個測試階段。V模型是瀑布模型的一個變體，其中測試在每個階段都與開發同步進行。
軟體工程術語
軟體開發生命週期 (SDLC) − SDLC 代表軟體開發生命週期。開發人員為了建立和構建高質量的軟體，會執行一系列任務。
軟體測試生命週期 (STLC) − 是軟體測試生命週期的縮寫。它是一套由測試人員有條理地執行的任務，以測試您的軟體產品。
瀑布模型 − 瀑布模型是一種順序模型，它將軟體開發活動劃分為多個階段。每個階段都旨在用於特定的活動。在瀑布模型中，測試過程僅在系統實現完成後才開始。
為了理解V模型，讓我們舉個例子。
假設您被分配了為客戶建立定製軟體的任務。無論您的技術經驗如何，請嘗試對您將採取的完成工作的操作順序進行有根據的預測。
這是正確的順序。
| 軟體開發生命週期的各個階段 | 每個步驟中執行的活動 |
|---|---|
| 需求收集階段 | 從客戶那裡儘可能多地獲取有關所需程式的具體細節和規範的資訊。這是收集需求的階段。 |
| 階段 1：設計 | 規劃程式語言（Java、PHP、.net）以及資料庫（Oracle、MySQL 等）。哪種適合該專案，以及某些高階架構和功能。 |
| 構建階段 | 設計階段完成後，構建階段開始，這只不過是軟體的實際編碼。 |
| 測試階段 | 之後，您測試軟體以確保它根據客戶的規格構建。 |
| 部署階段 | 在適當的環境中安裝程式。 |
| 維護階段 | 如果客戶請求，您可能需要在系統準備好使用後更改程式碼。 |
所有這些層都構成了軟體開發的瀑布方法。
瀑布模型的缺點
如您所見，該模型的測試僅在實現完成後才開始。
但是，如果您正在處理一個包含複雜系統的龐大專案，則很容易在需求階段忽略重要方面。在這種情況下，客戶將收到完全錯誤的產品，您可能需要重新啟動專案。或者，如果您正確記錄了需求但在軟體的設計和架構方面犯了嚴重錯誤，則您將不得不重新設計整個軟體以糾正錯誤。
根據對數百個專案的評估，在需求和設計期間引入的問題約佔所有缺陷的一半。
此外，隨著開發生命週期的進行，修復故障的成本會上升。在生命週期中越早發現缺陷，修復它的成本就越低。“及時縫針，省九針”，俗話說。
V模型是答案。
為了解決這個問題，建立了V模型測試，其中包括開發生命週期每個階段的測試階段。
V模型的驗證階段分為多個階段
單元測試 − 在V模型中，模組設計過程中會建立單元測試計劃 (UTP)。這些 UTP 用於查詢和修復程式碼或單元級別的錯誤。單元是最小的可以獨立存在的東西，例如程式模組。當與其餘程式碼/單元分離時，單元測試確認最小的物件可以正常執行。
元件測試 − 這些測試確保程式的最小的元件能夠正常工作。元件可以是模組、單元或類，具體取決於程式語言。因此，這些測試將被稱為模組測試、單元測試或類測試。元件測試在根據元件規範提供輸入後檢查元件的輸出。這些是 BDD 測試驅動方法的功能檔案。元件測試的特點是單獨評估單個元件，而無需與其他元件通訊。由於沒有涉及其他元件，因此查詢問題變得容易得多。
通常，測試框架用於實現測試，例如 JUnit、CPPUnit 或 PyUnit，僅舉幾個著名的單元測試框架。可以使用我們的程式碼覆蓋率分析工具 Coco 監控和檢查程式碼覆蓋率，以確保測試涵蓋儘可能多的元件原始碼。
除了功能測試（例如程式碼複雜性、適當的文件）之外，元件測試還可以涵蓋非功能因素，例如效率（例如儲存消耗、記憶體消耗、程式計時等）和可維護性。Coco 的程式碼複雜性分析和函式分析器也可以幫助完成這些任務。
整合測試 − 整合測試確保已單獨設計和測試的元件可以按計劃組合並互動。軟體系統的測試可能僅涵蓋兩個單獨的元件、元件組，甚至單獨的子系統。在元件在較低的元件測試級別進行評估後，通常完成整合測試。功能定義、系統架構、用例和流程描述都可以用於建立整合測試。整合測試側重於元件介面（或子系統介面），並揭示由它們的互動引起的錯誤，但如果元件單獨測試，則不會觸發這些錯誤。
整合測試還可以側重於與應用程式環境互動的其他軟體或硬體元件。與元件整合測試相反，這通常稱為系統整合測試。
根據程式型別，測試驅動程式也可能是單元測試框架。我們的 Squish GUI 測試器可以執行 GUI 應用程式的測試。除了被測應用程式之外，Squish 還可以自動化子系統或外部系統，例如配置工具。
系統測試 − 系統測試步驟檢查整個軟體系統。系統測試以使用者的角度構建，並側重於功能和非功能應用程式需求，而整合測試主要側重於技術規範。後者例如效能、負載和壓力測試。
儘管元件及其整合已過評估，但仍需要系統測試以確保滿足功能軟體需求。在不執行整個軟體系統的情況下，根本無法評估某些功能。系統測試中通常包含其他文件，例如使用者手冊或風險分析文件。
系統測試應在儘可能接近生產環境的環境中進行。如果可行，請使用與生產系統相同的硬體、作業系統、驅動程式、網路基礎設施或外部系統，並儘可能避免使用佔位符。另一方面，不應將生產環境用作測試環境，因為在系統測試期間發現的任何問題都可能影響生產系統。
為了避免耗時的手動測試，應自動化系統測試。Squish 現在可以自動化任何 GUI 程式並觸發和饋送非 GUI 程序，這要歸功於影像識別和光學字元識別。除了透過 GUI 驗證應用程式輸出之外，Squish 還可以訪問 GUI 和非 GUI 物件中存在的內部應用程式資料。測試單個自動化測試中的多個應用程式，即使它們使用不同的 GUI 工具包；嵌入式裝置測試；訪問外部系統（例如資料庫系統）；以及半自動化測試（包括手動驗證和驗證），涵蓋了大多數系統測試需求。
驗收測試 − 例如，對於尚未釋出的軟體版本，可以進行內部驗收測試。內部驗收測試通常由不參與開發或測試過程的人員執行，例如產品管理、銷售或客戶服務。
另一方面，驗收測試可能是由請求開發的公司或軟體的終端使用者執行的外部測試。
最終版本的程式是否符合客戶驗收測試期間的高階標準，也可能部分或全部由客戶決定。編寫報告是為了跟蹤測試結果，並促進開發實體與客戶之間的溝通。
與客戶驗收測試相比，使用者可接受性測試 (UAT) 可能是最終軟體釋出之前的倒數第二階段。它是一個以使用者為中心的測試，以確保產品真正支援需要完成的工作流程。這些測試可能包括可用性和整體使用者體驗等因素。
根據軟體的型別，用於驗收測試的時間和精力可能會有所不同。為特定客戶建立的定製開發可能會進行大量的測試和報告。對於現成的軟體，此測試階段的投入較少，驗收測試可能僅包括確認安裝和一些過程。
驗收測試通常是手動測試，只有極少數是自動化的，尤其是在它們可能只在開發過程結束時執行一次的情況下。另一方面，驗收測試側重於流程和使用者互動，因此我們建議使用 Squish 自動化驗收測試。所有利益相關者都可以將 BDD 作為一種通用語言和規範。考慮在整個軟體生命週期中針對軟體的多個版本或敏捷專案中的多個迭代所花費的驗收測試時間和精力。從中期和長期來看，測試自動化將為您節省大量時間。
除了 V 模型之外，還有迭代開發方法，其中軟體分階段開發，每個階段都新增新功能。
每個階段都包含其自身的一組開發和測試任務。
快速應用開發和敏捷開發是迭代開發生命週期的兩個很好的例項。
何時應使用 V 模型？
當需求明確且無歧義時。
對於需求明確且固定的中小型專案，應使用 V 形模型。
當具備所需技術技能的樣本文件技術資源可用時，應使用 V 形模型。
V 模型優勢（優點）
易於理解。
諸如計劃和測試設計之類的測試方法在編碼之前進行。
這可以幫助您節省大量時間。因此，它比瀑布模型更有可能成功。
防止缺陷向下蔓延。
此方法適用於具有簡單標準的小型計劃。
V 模型缺點（缺點）
極其僵化和缺乏靈活性。
這並不適合大型專案。
由於軟體是在實施階段開發的，因此沒有早期的軟體原型。
如果中間有任何修改，則必須更新測試文件以及所需的文件。
結論
有多種開發生命週期模型可供選擇。用於專案的開發模型取決於專案的目標和目標。
測試不是一項獨立的活動，必須根據專案的開發過程進行調整。
在任何模型中，都應在所有級別進行測試，從需求到維護。
747 次檢視
