資料結構
網路
關係資料庫管理系統
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C 程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
時尚研究
法律研究軟體測試方法論 – 學習 QA 模型
什麼是軟體測試方法論？
軟體測試方法論是指用於確保被測應用程式滿足客戶需求的策略和測試型別。為了驗證 AUT，測試方法論包括功能測試和非功能測試。單元測試、整合測試、系統測試、效能測試等都是測試方法論的例子。每種測試方法論都概述了測試目標、測試策略和交付成果。
許多公司將開發方法論和測試方法論這兩個術語互換使用，因為軟體測試是任何開發方法論的重要組成部分。與之前對測試方法論的定義相反，測試方法論也可能指瀑布模型、敏捷開發等 QA 方法。討論各種測試形式對讀者來說並沒有太大價值。因此，我們將回顧各種開發模型。
瀑布模型
在瀑布模型中，軟體開發逐步透過多個階段，例如需求分析、設計等。在此模型中，下一個階段只有在先前階段完成後才會開始。
什麼是測試方法論？
在瀑布模型中，第一個階段是需求階段，在此階段，在測試開始之前，所有專案需求都將完全確定。在這一階段，測試團隊會集思廣益，確定測試範圍，制定測試策略，並建立詳細的測試計劃。
只有在軟體設計完成後，團隊才會開始執行測試用例，以驗證構建的程式是否按計劃工作。
在此過程中，測試團隊只有在完成前一個步驟後才能進入下一步。
**優點** - 此軟體工程模型相對易於設計和管理。因此，具有明確定義和表達的需求的專案可以輕鬆地使用瀑布方法進行測試。
**缺點** - 在瀑布模型中，只有在完成前一階段後才能進入下一階段。因此，此模型無法適應意外情況和不確定性。此方法不適用於需求經常變化的專案。
迭代式開發
在此模型中，一個大型專案被分解成多個小塊，並且每個塊都經過多次瀑布迭代。在每個週期結束時，都會建立新的模組或改進現有的模組。此模組將構建到軟體體系結構中，並且整個系統將進行測試。
測試方法是什麼？
迭代完成後，將對整個系統進行測試。測試反饋可以立即獲得，幷包含在下一個週期中。
根據先前迭代的經驗，可以最大程度地減少後續迭代中所需的測試時間。
**優點** - 迭代式開發的主要好處是，在每個週期結束時，測試反饋會立即提供。
**缺點** - 由於必須在每個週期結束時提供有關交付成果、工作量和其他因素的反饋，因此此模型會大大增加溝通開銷。
敏捷方法論
傳統的軟體開發方法假設軟體需求在專案期間不會發生變化。但是，隨著需求變得越來越複雜，它們會經歷多次調整並隨著時間推移而發展。有時，購買者不確定自己想要什麼。儘管迭代模型克服了此問題，但它仍然遵循瀑布方法。
使用敏捷方法，軟體是按增量方式、快速週期構建的。客戶、開發人員和客戶端之間的互動優先於流程和工具。敏捷方法側重於適應變化，而不是進行大量準備。
什麼是測試方法論？
敏捷開發方法使用增量測試，確保每個專案版本都經過充分測試。這確保了在下一個版本釋出之前解決任何系統問題。
**優點** - 可以隨時對專案進行更改，以確保其滿足需求。這種漸進式測試方法降低了風險。
**缺點** - 客戶的持續參與給所有相關方帶來了更多的時間壓力，包括客戶、軟體開發和測試團隊。
極限程式設計
極限程式設計是一種敏捷方法，強調快速開發週期。簡單的工程活動被分組到一個專案中。程式設計師建立軟體的基本部分，然後提供給客戶反饋。客戶的反饋被納入考慮，工程師們繼續進行下一個任務。
極限程式設計通常在兩人一組的團隊中進行。
極限程式設計用於客戶需求頻繁變化的環境中。
什麼是測試方法論？
極限程式設計基於測試驅動開發方法，其定義如下：
向測試套件新增一個測試用例，以驗證尚未實現的新功能。
執行所有測試，由於該功能尚未開發，因此新的測試用例必須失敗。
編寫一些程式碼以實現該功能。
重新執行測試套件。由於該功能已編寫，因此新的測試用例這次應該透過。
**優點** - 極限程式設計可用於那些對軟體設計概念模糊的客戶。持續測試和整合小版本確保交付高質量的軟體程式碼。
**缺點** - 軟體開發團隊與客戶之間的會議增加了所需的時間。
您應該選擇哪種軟體方法論？
在軟體開發和測試中，有許多方法可供選擇。每種測試方法和方法論都針對特定目標，並且都有其自身的優缺點。
專案型別、客戶需求、專案時間表和其他因素都會影響所使用的方法。
某些方法鼓勵在開發生命週期的早期進行測試輸入，而其他方法則等到系統功能模型可用時才進行。
如何構建軟體測試方法論？
軟體測試方法論不應僅限於測試軟體程式碼。應該審查整體情況，並且測試方法論應滿足專案的首要目標。
**計劃** - 實施良好測試方法的關鍵是現實的計劃，並且該計劃應適應每個團隊成員的需求。
**已定義的交付成果** - 應提供明確定義的交付成果，以使所有團隊成員保持一致。交付成果的內容不應有任何歧義。
**測試方法論** - 完成計劃並提供已宣告的交付成果後，測試團隊應能夠建立適當的測試方法論。透過定義文件和開發會議，應讓團隊瞭解專案最合適的測試方法。
**報告** - 難以獲得透明的報告，但此階段定義了專案測試策略的有效性。
驗證和確認
V 模型方法是瀑布模型的一個分支，用於軟體需求明確定義的小型專案。它以“V 形”組織，包括編碼、驗證和確認。由於編碼是模型的基礎，因此每個開發階段都伴隨著測試，從而能夠在每個階段儘早發現錯誤。
測試方法論
在每個開發步驟執行的並行測試流程方面，“V 模型”與瀑布模型不同。驗證流程確保產品已正確構建，而確認階段確保它是適合該工作的正確產品。
模型中的靜態驗證階段從業務需求分析開始，然後是系統設計、體系結構設計和模組設計。之後，編碼步驟確保根據編碼標準和規則選擇適當的語言和工具。最後，驗證過程確保對每個模組和開發階段執行單元測試、整合測試、系統測試和應用程式測試。
優點
每個級別的測試和驗證使開發過程中能夠儘早發現錯誤。
這是一種低成本、快速週轉的測試方法。
由於其剛性，它非常適合小型專案。
驗證和確認過程在每個級別都包含明確定義的目標。
缺點
在測試過程中，沒有固有的能力來響應故障。
沒有明確的方法來消除軟體缺陷。
對於可能發生大量更改的大型專案，此方法效率低下。
它無法同時處理多個事件。
模組進入測試階段後，無法回頭。
案例研究
醫療裝置和軟體應用程式是兩種型別的醫療裝置。
政府的應用程式和軟體專案。
國防專案和應用程式。
商業應用程式可用。
快速行動開發方法論
測試模型是一種增量式方法，起源於敏捷軟體開發流程。RAD的核心是原型設計，同時構建軟體元件，允許測試人員專注於測試而不是計劃和文件。雖然每個軟體功能都被隔離並作為一個獨立的元件建立，但它們被組合起來構建原型，然後使用該原型收集終端使用者輸入並進行進一步修改。
測試方法論
RAD技術包括五個階段，在這些階段中，系統元件被同時設計和測試。每個階段都有一個設定的時間限制，並且必須儘快完成，這使其非常適合截止日期緊張的專案。
第一步稱為“業務建模”，它定義業務需求並建立資料流向各個業務渠道。在建立資料流後，“資料建模”步驟會根據業務模型檢查相關資料。
第三步“流程建模”將資料項轉換為建立業務資訊流。該階段指定了QA程式，以根據客戶輸入進一步修改資料項。這樣做是為了理解應用程式可能會隨著時間的推移經歷多次迭代。
原型步驟是“應用程式生成”的第四階段，並且使用自動化技術對模型進行編碼。最後，在“測試和移交”階段，每個原型都獨立進行測試，減少了整個軟體程式中的故障和風險。
優點
同時進行原型設計和可重用性減少了開發和測試時間。
透過在每個增量步驟中使用時間盒技術，可以降低軟體專案的總體風險。
由於反饋迴圈，客戶滿意度會提高。
進度是可觀察的並且基於事實。
更改易於實施。
缺點
對於過時的系統，很難應用此技術。
持續的客戶輸入和更改可能會導致部署延遲。
技術技能和資源非常重要。
由於自動化測試、工具和程式碼開發，成本會增加。
案例研究
新增到應用程式的圖形使用者介面。
原型應用程式（線框圖、設計和可點選原型）
系統的模組化。
609 次瀏覽
