# 軟件測試方法：了解質量檢查模型 > 原文： [https://www.guru99.com/testing-methodology.html](https://www.guru99.com/testing-methodology.html) ### 什么是軟件測試方法？ 軟件測試方法被定義為用于證明被測應用程序滿足客戶期望的策略和測試類型。 測試方法包括功能測試和非功能測試以驗證 AUT。 測試方法的示例包括[單元測試](/unit-testing-guide.html)，[集成測試](/integration-testing.html)，[系統測試](/system-testing.html)，[性能測試](/performance-testing.html)等。每種測試方法都有定義的測試目標 ，測試策略和可交付成果。 **注意**：由于軟件測試是任何開發方法的組成部分，因此許多公司通俗地使用術語“開發方法&測試方法”。 因此，與上述“測試方法”的定義相反，“測試方法”還可以引用“瀑布”，“敏捷”和其他 QA 模型。 對各種測試類型的討論不會為讀者增加價值。 因此，我們將討論不同的開發模型。 在本教程中，您將學習- * [瀑布模型](#2) * [迭代開發](#3) * [敏捷方法](#4) * [極限編程](#5) * [選擇哪種軟件方法？](#6) * [如何設置軟件測試方法？](#7) ## 瀑布模型  **這是什么？** 在[瀑布模型](/what-is-sdlc-or-waterfall-model.html)中，軟件開發通過需求分析，設計等各個階段-**依次**進行。 在此模型中，只有在前一個階段完成后，下一個階段才開始。 **什么是測試方法？** 瀑布模型的第一階段是需求階段，在此階段，在開始測試之前，所有項目需求都已完全定義。 在此階段，測試團隊會集思廣益測試范圍，測試策略并草擬詳細的測試計劃。 僅在軟件設計完成后，團隊才會著手執行測試用例，以確保開發的軟件按預期運行。 在這種方法中，測試團隊僅在上一個階段完成時才進入下一個階段。 **優勢** 該軟件工程模型非常易于計劃和管理。 因此，可以使用瀑布模型輕松測試需要明確定義和事先說明需求的項目。 **劣勢** 在瀑布模型中，只有在上一個階段完成后才能從下一個階段開始。 因此，該模型無法容納計劃外事件和不確定性。 這種方法不適用于需求經常變化的項目。 ## 迭代開發  **What is it?** 在此模型中，將一個大項目分為幾個小部分，每個部分都要經歷瀑布模型的多次迭代。 在迭代結束時，將開發新模塊或增強現有模塊。 該模塊已集成到軟件體系結構中，并且整個系統都經過了測試 **什么是測試方法？** 迭代完成后，整個系統將進行測試。 來自測試的反饋立即可用，并將在下一個周期中合并。 可以根據從過去的迭代中獲得的經驗來減少連續迭代中所需的測試時間。 **Advantages** 迭代開發的主要優點是在每個周期結束時都可以立即獲得測試反饋。 **Disadvantages** 該模型顯著增加了通信開銷，因為在每個周期結束時，必須給出有關可交付成果，工作量等的反饋。 ## 敏捷方法論  **What is it?** 傳統的軟件開發方法是在整個項目中保持軟件需求不變的前提下工作的。 但是隨著復雜性的增加，需求經歷了許多變化并不斷發展。 有時，客戶本人不確定自己想要什么。 盡管迭代模型解決了此問題，但它仍基于瀑布模型。 在敏捷方法論中，軟件是以遞增，快速的周期開發的。 強調了客戶，開發人員和客戶之間的交互，而不是流程和工具。 敏捷方法論側重于對變化的響應，而不是廣泛的計劃。 **What Is The Testing Approach?** 敏捷開發方法中使用了增量測試，因此，對項目的每個發行版都進行了徹底的測試。 這樣可確保在下一個版本之前修復系統中的所有錯誤。 **Advantages** 可以根據需要隨時在項目中進行更改。 這種增量測試將風險降到最低。 **Disadvantages** 持續的客戶交互意味著對所有利益相關者（包括客戶本身，軟件開發和測試團隊）施加時間壓力。 ## 極限編程 **** **What is it?** 極限編程是一種敏捷方法論，認為開發周期短。 一個項目分為簡單的工程任務。 程序員編寫一個簡單的軟件，然后返回給客戶以獲取反饋。 合并了來自客戶的評論點，開發人員繼續執行下一個任務。 在極限編程中，開發人員通常成對工作。 [極限編程](/agile-scrum-extreme-testing.html)用于客戶需求不斷變化的地方。 **What Is The Testing Approach?** 極限編程遵循測試驅動的開發，描述如下： 1. 將[測試用例](/test-case.html)添加到測試套件中，以驗證尚未開發的新功能 2. 運行所有測試，顯然添加的新測試用例必須失敗，因為該功能尚未編碼 3. 編寫一些代碼以實現功能 4. 再次運行測試套件。 這次，新的測試用例應該通過了，因為功能已被編碼 **Advantages** 考慮軟件設計模糊的客戶可以使用極限編程 持續測試和持續集成小發行版，確保交付的軟件代碼具有高質量 **Disadvantages** 軟件開發團隊和客戶之間的會議增加了時間要求。 ## 選擇哪種軟件方法？ 有大量方法可用于軟件開發及其相應的測試。 每種測試技術和方法都是針對特定目的而設計的，各有其優缺點。 具體方法的選擇取決于許多因素，例如項目的性質，客戶要求，項目進度表等。 從測試的角度來看，有些方法會在開發生命周期的早期推動測試輸入，而另一些方法則等到系統的工作模型準備就緒為止。 ## 如何設置軟件測試方法？ 不應僅出于測試軟件代碼的目的而設置軟件測試方法。 應該考慮全局，并且測試方法應滿足項目的主要目標。 **安排** 切實可行的計劃是成功執行測試方法的關鍵，計劃應滿足團隊中每個成員的需求。 **已定義的可交付成果** 為了使團隊的所有成員都在同一頁上，應提供定義明確的可交付成果。 交付品應包含直接內容，沒有任何歧義。 **測試方法** 一旦計劃完成并提供了確定的可交付成果，測試團隊就應該能夠制定正確的測試方法。 定義文件和開發人員會議應向團隊說明可用于項目的最佳測試方法。 **報表** 透明的報告很難實現，但是此步驟確定了項目中使用的測試方法的有效性。