軟件測試經過幾十年的發展，測試界提出了很多軟件測試的基本原則，為測試管理人員和測試人員提供了測試指南。軟件測試原則非常重要，測試人員應該在測試原則指導下進行測試活動。

　　軟件測試的基本原則有助于測試人員進行高質量的測試，盡早盡可能多的發現缺陷，并負責跟蹤和分析軟件中的問題，對存在的問題和不足提出質疑和改進，從而持續改進測試過程。

　　原則1:?測試顯示缺陷的存在

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

　　原則2:?窮盡測試是不可能的

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

　　原則3:?測試的盡早介入

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

　　原則4:?缺陷的集群性

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

　　原則5:?殺蟲劑悖論

　　殺蟲劑用得多了，害蟲就有免疫力，殺蟲劑就發揮不了效力。在測試中，同樣的測試用例被一遍一遍反復使用時，發現缺陷的能力就會越來越差。這種現象的主要原因在于測試人員沒有及時更新測試用例，同時對測試用例及測試對象過于熟悉，形成思維定勢。

　　為克服這種現象，測試用例需要經常的評審和修改，不斷增加新的不同的測試用例來測試軟件或系統的不同部分，保證測試用例永遠是最新的，即包含著最后一次程序代碼或說明文檔的更新信息。這樣軟件中未被測試過的部分或者先前沒有被使用過的輸入組合就會重新執行，從而發現更多的缺陷。同時，作為專業的測試人員，要具有探索性思維和逆向思維，而不僅僅是做輸出與期望結果的比較。

　　原則6:?測試活動依賴于測試內容

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

　　原則7:?沒有失效不代表系統是可用的

　　系統的質量特征不僅僅是功能性要求，還包括了很多其他方面的要求比如穩定性、可用性、兼容性等等。假如系統無法使用，或者系統不能完成客戶的需求和期望，那么，這個系統的研發是失敗。同時在系統中發現和修改缺陷也是沒有任何意義的。

　　在開發過程中用戶的早期介入和接觸原型系統就是為了避免這類問題的預防性措施。有時候，可能產品的測試結果非常完美，可最終的客戶并不買帳。因為，這個開發角度完美的產品可能并不是客戶真正想要的產品。

原則8:?測試的標準是用戶的需求

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

　　原則9:?盡早定義產品的質量標準

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

　　原則10:?測試貫穿于整個生命周期

　　由于軟件的復雜性和抽象性，在軟件生命周期的各個階段都可能產生錯誤，測試的準備和設計必須在編碼之前就開始，同時為了保證最終的質量，必須在開發過程的每個階段都保證其過程產品的質量。因此不應當把軟件測試僅僅看作是軟件開發完成后的一個獨立階段的工作，應當將測試貫穿于整個生命周期始末。

　　軟件項目一啟動，軟件測試就應該介入，而不是等到軟件開發完成。在項目啟動后，測試人員在每個階段都應該參與相應的活動。或者說每個開發階段，測試都應該對本階段的輸出進行檢查和驗證。比如在需求階段，測試人員需要參與需求文檔的評審。

　　原則11:?第三方或獨立的測試團隊

　　由于心理因素，人們潛意識都不希望找到自己的錯誤。基于這種思維定勢，人們難于發現自己的錯誤。因此，由嚴格的獨立測試部門或者第三方測試機構進行軟件測試將更客觀、公正，測試活動也會達到更好效果。

　　軟件開發者應盡量避免測試自己的產品，應由第三方來進行測試，當然開發者需要在交付之前進行相關的自測。測試是帶有破壞性的活動，開發人員的心理狀態會影響測試的效果。同時對于需求規格說明的理解產生的錯誤，開發人員自己很難發現。

　　但是，第三方或者獨立的測試團隊這個原則，并不是認為所有的測試完全由他們來完成。一定程度的獨立測試（可以避免開發人員對自己代碼的偏愛），可以更加高效的發現軟件缺陷和軟件存在的失效。但獨立測試不是完全的替代物，因為開發人員也可以高效的在他們的代碼中找出很多缺陷。在軟件開發的早期，開發人員對自己的工作產品進行認真的測試，這也是開發人員的一個職責之一。

?

轉載于:https://www.cnblogs.com/qy15zj/archive/2012/11/29/2794722.html

總結

以上是生活随笔為你收集整理的软件测试原则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。