軟體測試中必備的基本原則
阿新 • • 發佈：2019-01-08
軟體測試的基本原則有助於測試人員進行高質量的測試，儘早儘可能多的發現缺陷，並負責跟蹤和分析軟體中的問題，對存在的問題和不足提出質疑和改進，從而持續改進測試過程。
原則1: 測試顯示缺陷的存在
測試可以顯示缺陷的存在，但不能證明系統不存在缺陷。測試可以減少軟體中存在缺陷的可能性，但即使測試沒有發現任何缺陷，也不能證明軟體或系統是完全正確的，或者說是不存在缺陷的。
原則2: 窮盡測試是不可能的
窮盡測試是不可能的，當滿足一定的測試出口準則時測試就應當終止。考慮到所有可能輸入值和它們的組合，以及結合所有不同的測試前置條件，這是一個天文數字，我們沒有可能進行窮盡測試。在實際測試過程中，測試人員無法執行“天文”數字的測試用例。所以說，每個測試都只是抽樣測試。因此，必須根據測試的風險和優先順序，控制測試工作量，在測試成本、收益和風險之間求得平衡。
原則3: 測試的儘早介入
根據統計表明，在軟體開發生命週期早期引入的錯誤佔軟體過程中出現所有錯誤（包括最終的缺陷）數量的50%～60%。此外，IBM的一份研究結果表明，缺陷存在放大趨勢。如需求階段的一個錯誤可能會導致N個設計錯誤，因此，越是測試後期，為修復缺陷所付出的代價就會越大。因此，軟體測試人員要儘早地且不斷地進行軟體測試，以提高軟體質量，降低軟體開發成本。
原則4: 缺陷的叢集性
Pareto原則表明“80%的錯誤集中在20%的程式模組中”。實際經驗也證明了這一點，通常情況下，大多數的缺陷只是存在測試物件的極小部分。缺陷並不是平均而是叢集分佈的。因此，如果在一個地方發現了很多缺陷，那麼通常在這個模組中可以發現更多的缺陷。因此，測試過程中要充分注意錯誤叢集現象，對發現錯誤較多的程式段或者軟體模組，應進行反覆的深入的測試。
原則5: 殺蟲劑悖論
殺蟲劑用得多了，害蟲就有免疫力，殺蟲劑就發揮不了效力。在測試中，同樣的測試用例被一遍一遍反覆使用時，發現缺陷的能力就會越來越差。這種現象的主要原因在於測試人員沒有及時更新測試用例，同時對測試用例及測試物件過於熟悉，形成思維定勢。
為克服這種現象，測試用例需要經常的評審和修改，不斷增加新的不同的測試用例來測試軟體或系統的不同部分，保證測試用例永遠是最新的，即包含著最後一次程式程式碼或說明文件的更新資訊。這樣軟體中未被測試過的部分或者先前沒有被使用過的輸入組合就會重新執行，從而發現更多的缺陷。同時，作為專業的測試人員，要具有探索性思維和逆向思維，而不僅僅是做輸出與期望結果的比較。
原則6: 測試活動依賴於測試內容
專案測試相關的活動依賴於測試物件的內容。對於每個軟體系統，比如測試策略、測試技術、測試工具、測試階段以及測試出口準則等等的選擇，都是不一樣的。同時，測試活動必須與應用程式的執行環境和使用中可能存在的風險相關聯。因此，沒有兩個系統可以以完全相同的方式進行測試。比如，對關注安全的電子商務系統進行測試，與一般的商業軟體測試的重點是不一樣的，它更多關注的是安全測試和效能測試。
原則7: 沒有失效不代表系統是可用的
系統的質量特徵不僅僅是功能性要求，還包括了很多其他方面的要求比如穩定性、可用性、相容性等等。假如系統無法使用，或者系統不能完成客戶的需求和期望，那麼，這個系統的研發是失敗。同時在系統中發現和修改缺陷也是沒有任何意義的。
在開發過程中使用者的早期介入和接觸原型系統就是為了避免這類問題的預防性措施。有時候，可能產品的測試結果非常完美，可最終的客戶並不買帳。因為，這個開發角度完美的產品可能並不是客戶真正想要的產品。
原則8: 測試的標準是使用者的需求
提供軟體的目的是幫助使用者完成預定的任務，並滿足使用者的需求。這裡的使用者並不特指最終軟體測試使用者。比如我們可以認為系統測試人員是系統需求分析和設計的客戶。軟體測試的最重要的目的之一是發現缺陷，因此測試人員應該在不同的測試階段站在不同使用者的角度去看問題，系統中最嚴重的問題是那些無法滿足使用者需求的錯誤。
原則9: 儘早定義產品的質量標準
只有建立了質量標準，才能根據測試的結果，對產品的質量進行分析和評估。同樣，測試用例應該確定期望輸出結果。如果無法確定測試期望結果，則無法進行檢驗。必須用預先精確對應的輸入資料和輸出結果來對照檢查當前的輸出結果是否正確，做到有的放矢。
原則10: 測試貫穿於整個生命週期
由於軟體的複雜性和抽象性，在軟體生命週期的各個階段都可能產生錯誤，測試的準備和設計必須在編碼之前就開始，同時為了保證最終的質量，必須在開發過程的每個階段都保證其過程產品的質量。因此不應當把軟體測試僅僅看作是軟體開發完成後的一個獨立階段的工作，應當將測試貫穿於整個生命週期始末。
軟體專案一啟動，軟體測試就應該介入，而不是等到軟體開發完成。在專案啟動後，測試人員在每個階段都應該參與相應的活動。或者說每個開發階段，測試都應該對本階段的輸出進行檢查和驗證。比如在需求階段，測試人員需要參與需求文件的評審。
原則11: 第三方或獨立的測試團隊
由於心理因素，人們潛意識都不希望找到自己的錯誤。基於這種思維定勢，人們難於發現自己的錯誤。因此，由嚴格的獨立測試部門或者第三方測試機構進行軟體測試將更客觀、公正，測試活動也會達到更好效果。
軟體開發者應儘量避免測試自己的產品，應由第三方來進行測試，當然開發者需要在交付之前進行相關的自測。測試是帶有破壞性的活動，開發人員的心理狀態會影響測試的效果。同時對於需求規格說明的理解產生的錯誤，開發人員自己很難發現。
原則1: 測試顯示缺陷的存在
測試可以顯示缺陷的存在，但不能證明系統不存在缺陷。測試可以減少軟體中存在缺陷的可能性，但即使測試沒有發現任何缺陷，也不能證明軟體或系統是完全正確的，或者說是不存在缺陷的。
原則2: 窮盡測試是不可能的
窮盡測試是不可能的，當滿足一定的測試出口準則時測試就應當終止。考慮到所有可能輸入值和它們的組合，以及結合所有不同的測試前置條件，這是一個天文數字，我們沒有可能進行窮盡測試。在實際測試過程中，測試人員無法執行“天文”數字的測試用例。所以說，每個測試都只是抽樣測試。因此，必須根據測試的風險和優先順序，控制測試工作量，在測試成本、收益和風險之間求得平衡。
原則3: 測試的儘早介入
根據統計表明，在軟體開發生命週期早期引入的錯誤佔軟體過程中出現所有錯誤（包括最終的缺陷）數量的50%～60%。此外，IBM的一份研究結果表明，缺陷存在放大趨勢。如需求階段的一個錯誤可能會導致N個設計錯誤，因此，越是測試後期，為修復缺陷所付出的代價就會越大。因此，軟體測試人員要儘早地且不斷地進行軟體測試，以提高軟體質量，降低軟體開發成本。
原則4: 缺陷的叢集性
Pareto原則表明“80%的錯誤集中在20%的程式模組中”。實際經驗也證明了這一點，通常情況下，大多數的缺陷只是存在測試物件的極小部分。缺陷並不是平均而是叢集分佈的。因此，如果在一個地方發現了很多缺陷，那麼通常在這個模組中可以發現更多的缺陷。因此，測試過程中要充分注意錯誤叢集現象，對發現錯誤較多的程式段或者軟體模組，應進行反覆的深入的測試。
原則5: 殺蟲劑悖論
殺蟲劑用得多了，害蟲就有免疫力，殺蟲劑就發揮不了效力。在測試中，同樣的測試用例被一遍一遍反覆使用時，發現缺陷的能力就會越來越差。這種現象的主要原因在於測試人員沒有及時更新測試用例，同時對測試用例及測試物件過於熟悉，形成思維定勢。
為克服這種現象，測試用例需要經常的評審和修改，不斷增加新的不同的測試用例來測試軟體或系統的不同部分，保證測試用例永遠是最新的，即包含著最後一次程式程式碼或說明文件的更新資訊。這樣軟體中未被測試過的部分或者先前沒有被使用過的輸入組合就會重新執行，從而發現更多的缺陷。同時，作為專業的測試人員，要具有探索性思維和逆向思維，而不僅僅是做輸出與期望結果的比較。
原則6: 測試活動依賴於測試內容
專案測試相關的活動依賴於測試物件的內容。對於每個軟體系統，比如測試策略、測試技術、測試工具、測試階段以及測試出口準則等等的選擇，都是不一樣的。同時，測試活動必須與應用程式的執行環境和使用中可能存在的風險相關聯。因此，沒有兩個系統可以以完全相同的方式進行測試。比如，對關注安全的電子商務系統進行測試，與一般的商業軟體測試的重點是不一樣的，它更多關注的是安全測試和效能測試。
原則7: 沒有失效不代表系統是可用的
系統的質量特徵不僅僅是功能性要求，還包括了很多其他方面的要求比如穩定性、可用性、相容性等等。假如系統無法使用，或者系統不能完成客戶的需求和期望，那麼，這個系統的研發是失敗。同時在系統中發現和修改缺陷也是沒有任何意義的。
在開發過程中使用者的早期介入和接觸原型系統就是為了避免這類問題的預防性措施。有時候，可能產品的測試結果非常完美，可最終的客戶並不買帳。因為，這個開發角度完美的產品可能並不是客戶真正想要的產品。
原則8: 測試的標準是使用者的需求
提供軟體的目的是幫助使用者完成預定的任務，並滿足使用者的需求。這裡的使用者並不特指最終軟體測試使用者。比如我們可以認為系統測試人員是系統需求分析和設計的客戶。軟體測試的最重要的目的之一是發現缺陷，因此測試人員應該在不同的測試階段站在不同使用者的角度去看問題，系統中最嚴重的問題是那些無法滿足使用者需求的錯誤。
原則9: 儘早定義產品的質量標準
只有建立了質量標準，才能根據測試的結果，對產品的質量進行分析和評估。同樣，測試用例應該確定期望輸出結果。如果無法確定測試期望結果，則無法進行檢驗。必須用預先精確對應的輸入資料和輸出結果來對照檢查當前的輸出結果是否正確，做到有的放矢。
原則10: 測試貫穿於整個生命週期
由於軟體的複雜性和抽象性，在軟體生命週期的各個階段都可能產生錯誤，測試的準備和設計必須在編碼之前就開始，同時為了保證最終的質量，必須在開發過程的每個階段都保證其過程產品的質量。因此不應當把軟體測試僅僅看作是軟體開發完成後的一個獨立階段的工作，應當將測試貫穿於整個生命週期始末。
軟體專案一啟動，軟體測試就應該介入，而不是等到軟體開發完成。在專案啟動後，測試人員在每個階段都應該參與相應的活動。或者說每個開發階段，測試都應該對本階段的輸出進行檢查和驗證。比如在需求階段，測試人員需要參與需求文件的評審。
原則11: 第三方或獨立的測試團隊
由於心理因素，人們潛意識都不希望找到自己的錯誤。基於這種思維定勢，人們難於發現自己的錯誤。因此，由嚴格的獨立測試部門或者第三方測試機構進行軟體測試將更客觀、公正，測試活動也會達到更好效果。
軟體開發者應儘量避免測試自己的產品，應由第三方來進行測試，當然開發者需要在交付之前進行相關的自測。測試是帶有破壞性的活動，開發人員的心理狀態會影響測試的效果。同時對於需求規格說明的理解產生的錯誤，開發人員自己很難發現。
但是，第三方或者獨立的測試團隊這個原則，並不是認為所有的測試完全由他們來完成。一定程度的獨立測試（可以避免開發人員對自己程式碼的偏愛），可以更加高效的發現軟體缺陷和軟體存在的失效。但獨立測試不是完全的替代物，因為開發人員也可以高效的在他們的程式碼中找出很多缺陷。在軟體開發的早期，開發人員對自己的工作產品進行認真的測試，這也是開發人員的一個職責之一。
來源整理：千鋒