軟體測試基本原則

標籤：

 　　軟體測試經過幾十年的發展，測試界提出了很多軟體測試的基本原則，為測試管理員和測試人員提供了測試指南。軟體測試原則非常重要，測試人員應該在測試原則指導下進行測試活動。
　　軟體測試的基本原則有助於測試人員進行高品質的測試，儘早儘可能多的發現缺陷，並負責跟蹤和分析軟體中的問題，對存在的問題和不足提出質疑和改進，從而持續改進測試過程。

原則1: 測試顯示缺陷的存在
　　測試可以顯示缺陷的存在，但不能證明系統不存在缺陷。測試可以減少軟體中存在缺陷的可能性，但即使測試沒有發現任何缺陷，也不能證明軟體或系統是完全正確的，或者說是不存在缺陷的。

原則2: 窮盡測試是不可能的
　　窮盡測試是不可能的，當滿足一定的測試出口準則時測試就應當終止。考慮到所有可能輸入值和它們的組合，以及結合所有不同的測試前置條件，這是一個天文數字，我們沒有可能進行窮盡測試。在實際測試過程中，測試人員無法執行“天文”數位測試案例。所以說，每個測試都只是抽樣測試。因此，必鬚根據測試的風險和優先順序，控制測試工作量，在測試成本、收益和風險之間求得平衡。

原則3: 測試的儘早介入
　　根據統計表明，在軟體開發生命週期早期引入的錯誤占軟體過程中出現所有錯誤（包括最終的缺陷）數量的50%～60%。此外，IBM的一份研究結果表明，缺陷存在放大趨勢。如需求階段的一個錯誤可能會導致N個設計錯誤，因此，越是測試後期，為修複缺陷所付出的代價就會越大。因此，軟體測試人員要儘早地且不斷地進行軟體測試，以提高軟體品質，降低軟體開發成本。

原則4: 缺陷的叢集性
　　Pareto原則表明“80%的錯誤集中在20%的程式模組中”。實際經驗也證明了這一點，通常情況下，大多數的缺陷只是存在測試對象的極小部分。缺陷並不是平均而是叢集分布的。因此，如果在一個地方發現了很多缺陷，那麼通常在這個模組中可以發現更多的缺陷。因此，測試過程中要充分注意錯誤叢集現象，對發現錯誤較多的程式段或者軟體模組，應進行反覆的深入的測試。

原則5: 殺蟲劑悖論
　　殺蟲劑用得多了，害蟲就有免疫力，殺蟲劑就發揮不了效力。在測試中，同樣的測試案例被一遍一遍反覆使用時，發現缺陷的能力就會越來越差。這種現象的主要原因在於測試人員沒有及時更新測試案例，同時對測試案例及測試對象過於熟悉，形成思維定勢。
　　為克服這種現象，測試案例需要經常的評審和修改，不斷增加新的不同的測試案例來測試軟體或系統的不同部分，保證測試案例永遠是最新的，即包含著最後一次程式碼或說明文檔的更新資訊。這樣軟體中未被測試過的部分或者先前沒有被使用過的輸入組合就會重新執行，從而發現更多的缺陷。同時，作為專業的測試人員，要具有探索性思維和逆向思維，而不僅僅是做輸出與期望結果的比較。

原則6: 測試活動依賴於測試內容
　　項目測試相關的活動依賴於測試對象的內容。對於每個軟體系統，比如測試策略、測試技術、測試載入器、測試階段以及測試出口準則等等的選擇，都是不一樣的。同時，測試活動必須與應用程式的運行環境和使用中可能存在的風險相關聯。因此，沒有兩個系統可以以完全相同的方式進行測試。比如，對關注安全的電子商務系統進行測試，與一般的商業軟體測試的重點是不一樣的，它更多關注的是安全性測試和效能測試。

原則7: 沒有失效不代表系統是可用的
　　系統的品質特徵不僅僅是功能性要求，還包括了很多其他方面的要求比如穩定性、可用性、相容性等等。假如系統無法使用，或者系統不能完成客戶的需求和期望，那麼，這個系統的研發是失敗。同時在系統中發現和修改缺陷也是沒有任何意義的。
　　在開發過程中使用者的早期介入和接觸原型系統就是為了避免這類問題的預防性措施。有時候，可能產品的測試結果非常完美，可最終的客戶並不買帳。因為，這個開發角度完美的產品可能並不是客戶真正想要的產品。

原則8: 測試的標準是使用者的需求
　　提供軟體的目的是協助使用者完成預定的任務，並滿足使用者的需求。這裡的使用者並不特指最終軟體測試使用者。比如我們可以認為系統測試人員是系統需求分析和設計的客戶。軟體測試的最重要的目的之一是發現缺陷，因此測試人員應該在不同的測試階段站在不同使用者的角度去看問題，系統中最嚴重的問題是那些無法滿足使用者需求的錯誤。

原則9: 儘早定義產品的品質標準
　　只有建立了品質標準，才能根據測試的結果，對產品的品質進行分析和評估。同樣，測試案例應該確定期望輸出結果。如果無法確定測試期望結果，則無法進行檢驗。必須用預先精確對應的輸入資料和輸出結果來對照檢查當前的輸出結果是否正確，做到有的放矢。

原則10: 測試貫穿於整個生命週期
　　由於軟體的複雜性和抽象性，在軟體生命週期的各個階段都可能產生錯誤，測試的準備和設計必須在編碼之前就開始，同時為了保證最終的品質，必須在開發過程的每個階段都保證其過程產品的品質。因此不應當把軟體測試僅僅看作是軟體開發完成後的一個獨立階段的工作，應當將測試貫穿於整個生命週期始末。
　　軟體項目一啟動，軟體測試就應該介入，而不是等到軟體開發完成。在項目啟動後，測試人員在每個階段都應該參與相應的活動。或者說每個開發階段，測試都應該對本階段的輸出進行檢查和驗證。比如在需求階段，測試人員需要參與需求文檔的評審。

原則11: 第三方或獨立的測試團隊
　　由於心理因素，人們潛意識都不希望找到自己的錯誤。基於這種思維定勢，人們難於發現自己的錯誤。因此，由嚴格的獨立測試部門或者第三方測試機構進行軟體測試將更客觀、公正，測試活動也會達到更好效果。
　　軟體開發人員應盡量避免測試自己的產品，應由第三方來進行測試，當然開發人員需要在交付之前進行相關的自測。測試是帶有破壞性的活動，開發人員的心理狀態會影響測試的效果。同時對於需求規格說明的理解產生的錯誤，開發人員自己很難發現。
　　但是，第三方或者獨立的測試團隊這個原則，並不是認為所有的測試完全由他們來完成。一定程度的獨立測試（可以避免開發人員對自己代碼的偏愛），可以更加高效的發現軟體缺陷和軟體存在的失效。但獨立測試不是完全的替代物，因為開發人員也可以高效的在他們的代碼中找出很多缺陷。在軟體開發的早期，開發人員對自己的工作產品進行認真的測試，這也是開發人員的一個職責之一。

軟體測試基本原則