1)所有的測試都應追溯到使用者需求。

軟體測試的目標在於揭示錯誤。從使用者角度來看，最嚴重的錯誤是那些導致程式無法滿足需求的錯誤。

(2)應該在測試工作真正開始前的較長時間內就進行測試計劃。測試計劃可以在需求模型一完成就開始，詳細的測試用例定義可以在設計模型被確定後立即開始。因此，所有測試應該在任何程式碼被產生前就進行計劃和設計。

(3)pareto原則：測試發現的錯誤中80%很可能起源於20%的模組中。

當某個功能出問題，其對使用者的影響有多大?然後根據風險大小確定測試的優先順序。優先順序高的測試，優先得到執行，一般來講，針對使用者最常用的20%功能(優先順序高)的測試會得到完全執行，而低優先順序的測試(另外使用者不經常用的80%功能)就不是必要的，如果時間或經費不夠，就暫時不做或少做。

(4)測試無法顯示軟體潛在的缺陷，“測試只能證明軟體存在錯誤而不能證明軟體沒有錯誤”。最初的測試通常把焦點放在單個程式模組上，進一步測試的焦點則轉向在整合的模組簇中尋找錯誤，最後在整個系統中尋找錯誤。在測試中不可能執行路徑的每一種組合。然而，充分覆蓋程式邏輯，並確保程式設計中使用的所有條件是有可能的。

(5)應由獨立的第三方來構造測試。

第三方測試最大的特點在於它的專業性、獨立性、客觀性和公正性。

(6)充分注意測試中的群集現象。

測試後程序殘存的錯誤數目與該程式中已發現的錯誤數目或檢錯率成正比。不要在某個程式段中找到幾個錯誤就誤認為該程式段就沒有錯誤而不再測試，相反應該對錯誤群集的程式段進行重點測試。

(7)儘量避免測試的隨意性。

測試計劃應包括：所測軟體的功能，輸入和輸出，測試內容，各項測試的進度安排，資源要求，測試資料，測試工具，測試用例的選擇，測試的控制方法和過程，系統的配置方式，跟蹤規則，除錯規則，以及迴歸測試的規定等以及評價標準。

(8)兼顧合理的輸入和不合理的輸入資料。

(9)程式修改後要回歸測試

修改程式後，應該重新進行測試以確認修改沒有引入新的錯誤或導致其他程式碼產生錯誤。

(10)應長期保留測試用例，直至系統廢棄。

妥善儲存測試計劃，測試用例，出錯統計和最終分析報告，為維護等提供方便。

1. 確認測試標準

實現軟體確認要透過一系列墨盒測試。確認測試同樣需要制訂測試計劃和過程，測試計劃應規定測試的種類和測試進度，測試過程則定義一些特殊的測試用例，旨在說明軟體與需求是否一致。

無論是計劃還是過程，都應該著重考慮軟體是否滿足合同規定的所有功能和效能，文件資料是否完整、準確人機介面和其他方面。

確認測試的結果有兩種可能，一種是功能和效能指標滿足軟體需求說明的要求，使用者可以接受；另一種是軟體不滿足軟體需求說明的要求，使用者無法接受。專案進行到這個階段才發現嚴重錯誤和偏差一般很難在預定的工期內改正，因此必須與使用者協商，尋求一個妥善解決問題的方法。

2. 配置複審

確認測試的另一個重要環節是配置複審。複審的目的在於保證軟體配置齊全、分類有序，並且包括軟體維護所必須的細節。

3. α、β測試

事實上，軟體開發人員不可能完全預見使用者實際使用程式的情況。例如，使用者可能錯誤的理解命令，或提供一些奇怪的資料組合，亦可能對設計者自認明瞭的輸出資訊迷惑不解，等等。因此，軟體是否真正滿足終端使用者的要求，應由使用者進行一系列驗收測試。

驗收測試既可以是非正式的測試，也可以有計劃、有系統的測試。有時，驗收測試長達數週甚至數月，不斷暴露錯誤，導致開發延期。一個軟體產品，可能擁有眾多使用者，不可能由每個使用者驗收，此時多采用稱為α、β測試的過程，以期發現那些似乎只有終端使用者才能發現的問題。

學習軟體測試推薦來中公優就業哦~