軟體檢查指導原則

測試表明缺陷的存在

每個應用程式在釋出到生產環境之前，都必須經過一系列測試階段，例如系統整合測試、使用者驗收測試和 Beta 測試等。無論進行多少測試，總會發現某種形式的缺陷。

測試團隊的核心目標應集中在查詢應用程式中的缺陷。檢查團隊必須使用不同的方法來發現儘可能多的錯誤。這有助於減少軟體應用程式中未發現的錯誤數量。即使測試團隊沒有發現任何缺陷，也並不意味著軟體是 100% 完美的。

假設一個電子商務應用程式經過多個測試階段，並順利透過所有測試。儘管該應用程式在生產環境中成功執行，但終端使用者尚未使用它。也許客戶會使用測試團隊可能忽略的罕見功能，因為他們認為沒有人會使用它。

在 SDLC 的早期階段進行測試使測試人員能夠在需求分析階段或文件階段發現缺陷。測試人員需要做的是在需求確定後立即進行測試過程。在早期階段修復缺陷的成本幾乎比在後期修復錯誤的成本低十倍。

測試團隊必須在將新程式碼新增到現有程式碼結構之前測試程式碼整合。此外，測試人員必須執行進一步的測試，以確保修改後的程式碼正確整合。這是引入 1:10:100 規則的地方。該規則指出，在使用者驗收測試期間修復缺陷的成本是開發階段修復缺陷成本的十倍。如果缺陷在釋出後未被發現，則成本將增加 100 倍。

為了成功進行早期測試，組織可以指定一個單獨的團隊來處理需求過程。最好為每個測試階段選擇一名代表。然後，測試人員檢查每個需求並在必要時進行修改。組織必須聘用經驗豐富的測試人員，他們能夠定義標準、指定意圖並以極高的準確性準備他們的測試用例。

該原則指出，使用有效和無效組合測試所有功能是不可能的。詳盡的測試不僅需要無限的努力，而且也不能提供預期的結果。因此，測試人員建議僅使用邊界值分析和等價劃分等各種技術的一些組合。

詳盡測試將需要無限的努力，並且大部分努力都是無效的。此外，專案時間表不允許測試如此多的組合。因此，建議使用等價劃分和邊界值分析等各種方法來測試輸入資料。

市場包含多個領域，例如醫療保健、銀行、旅遊、廣告等。每個領域的應用程式都具有獨特的功能。因此，它需要不同的需求、測試過程、風險分析和技術。這種領域的多樣性使測試成為一個依賴於上下文的流程。

開發的軟體攜帶相同程式碼的可能性非常小。這意味著測試人員不能遵循銀行應用程式的測試過程來測試電子商務應用程式。從方法、方法到測試型別，一切都因應用程式而異。

缺陷聚集是一種現象，當大多數缺陷或錯誤集中在少數模組上時發生。這可能是由於模組的複雜性造成的。

缺陷聚集原則遵循帕累托法則，該法則指出 20% 的模組可能包含 80% 的問題。在大型系統中，由於某些因素（例如）導致特定模組受到影響，這一點最為明顯。

缺陷聚集現象在測試設計人員中普遍存在。測試人員大多在風險評估和測試計劃中使用此資訊。測試人員通常專注於這些棘手區域以查詢更多缺陷，從而減少查詢缺陷的時間和成本。

這種現象殺蟲劑悖論指出，反覆測試軟體會使其對缺陷免疫，就像昆蟲對殺蟲劑產生抗藥性一樣。

沒有什麼比用例子來解釋殺蟲劑悖論更好的了。假設您正在對某個模組執行測試周期。您發現了一些錯誤並將其報告給開發團隊。然後，他們修復了它並向您提供了新的程式碼。

現在您使用相同的測試用例執行了另一個測試。這次您發現的錯誤比上次少。您再次將報告發送給相關團隊進行修復。現在，在執行相同的測試用例時，您錯過了某些內容。您過於專注於修復當前的缺陷，完全忘記了隨著最近的更改，一些新的錯誤可能已進入系統。

因此，建議測試人員使用一組新的測試用例，重點關注多個熱點或模組。將新的測試用例與現有測試用例一起新增也有助於避免殺蟲劑悖論。

該原則指出，沒有哪個軟體是 100% 沒有缺陷的。僅僅因為軟體經過測試證明 99% 沒有缺陷，並不意味著剩下的 1% 不值得關注。可能測試人員根據錯誤的要求對其進行了測試。

例如，一個測試團隊使銀行軟體 99% 沒有缺陷，並將其提交給管理層。儘管軟體沒有缺陷，但管理層並不滿意，因為它希望軟體具有簡單的 UI 和高使用者負載容量。在這種情況下，測試團隊無法滿足最終需求，因為他們過於專注於產品的質量。

Vineet Nanda

更新於：2021 年 3 月 6 日

220 次檢視

透過完成課程獲得認證

開始