軟體測試生命週期 - 測試基本原則

測試的共同目標是在儘可能早的階段發現缺陷。並且，一旦缺陷被修復，確保其按預期工作並且不會破壞任何其他功能。

為了實現這些目標，軟體測試提供了七個基本原則：

測試能說明什麼？

測試可以證明缺陷的存在，但無法證明產品中不存在缺陷。測試階段確保被測應用程式根據給定需求工作，並有助於降低應用程式中未發現缺陷的可能性。但是，即使沒有發現缺陷，也不意味著它絕對正確。我們可以假設 AUT 符合我們的退出標準並根據 SRD 維護需求。

窮舉測試是否可行？

除了瑣碎的情況外，100% 的覆蓋率或測試所有輸入組合和可能組合是不可能的。與其進行窮舉測試，不如使用風險分析和優先順序來定義測試範圍。在這裡，大多數即時場景都可以考慮包括最可能的負面場景。這將幫助我們跟蹤故障。

儘早測試

測試活動應儘早開始，並專注於測試策略和預期結果中定義的目標。測試的早期階段有助於識別需求缺陷或設計級別的差異。如果在初始階段捕獲到這些型別的錯誤，則有助於我們節省時間，並且也具有成本效益。儘早開始測試的原因很簡單 - 一旦收到 SRD，測試人員就可以從測試的角度分析需求，並可以注意到需求差異。

缺陷集中

根據以前的產品缺陷分析，可以說大多數缺陷是從對應用程式至關重要的一小組模組中識別的。這些模組可以根據複雜性、不同的系統互動或對其他不同模組的依賴性來識別。如果測試人員能夠識別這些關鍵模組，他們可以更多地關注這些模組以識別所有可能的錯誤。在一項研究中發現，10 個缺陷中有 8 個是從 AUT 的 20% 功能中識別出來的。

殺蟲劑悖論

什麼是殺蟲劑悖論 - 如果農作物上經常使用殺蟲劑，就會出現昆蟲產生某種抗藥性的情況，並且逐漸地，噴灑的殺蟲劑似乎對昆蟲無效。

同樣的概念也適用於測試。這裡，昆蟲是錯誤，而殺蟲劑是反覆使用的測試用例。如果同一組測試用例被反覆執行，這些測試用例在一段時間後會變得無效，測試人員將無法識別任何新的缺陷。

為了克服這些情況，應定期檢查和審查測試用例，並可以新增新的和不同的測試用例。這將有助於識別新的缺陷。

測試依賴於上下文

此原則指出，兩種不同型別的應用程式不能使用相同的方法進行測試，除非兩種應用程式的性質相同。例如，如果測試人員對 Web 應用程式和移動應用程式使用相同的方法，那完全是錯誤的，並且產品釋出質量差的風險很高。測試人員應針對不同型別和性質的應用程式使用不同的方法、方法、技術和覆蓋範圍。

無錯誤謬誤

此原則指出，查詢缺陷並修復它們直到應用程式或系統穩定，既費時又消耗資源。即使修復了 99% 的缺陷，應用程式也存在不穩定的風險。首先要驗證應用程式的穩定性和環境的先決條件。如果這兩個條件滿足，我們才能開始詳細測試。