在實際的項目中，往往由于時間緊，測試人員不足等原因，無法做完全的測試，需要對測試工作進行取舍。一般來說，需要確定測試的重點，排出優先級，根據優先級取舍。
那么，如何確定測試的重點呢？主要從以下方面考慮：
被測功能在系統中的地位
在一個軟件內部，不同功能模塊的質量標準一般來說也會有差異。客戶最關注的功能顯然應該得到測試的重視，需要投入較多的精力對其進行驗證。除此之外，對那些非核心功能、但對核心功能產生影響的模塊，我們也不應該忽視，至少要保證這些模塊在一般情況下能夠正常運轉，在遇到異常情況時能夠做出令人接受的合理反應，不會導致核心功能發生超出耐受度的錯誤。
客戶能夠容忍哪些錯誤存在
從另一個角度看，客戶對不同模塊中發生的不同錯誤的接受程度是不一樣的。某些模塊不允許出現任何功能錯誤，但少量的不嚴重的界面問題可以容忍，而另一些模塊偶爾出現功能錯誤也可以接受，但必須保證界面顯示正常。某些功能必須滿足長期運行的要求；而有些軟件允許在運行期間重新啟動，甚至可以允許有輕微的內存泄漏。
針對客戶能夠接受和不能接受的錯誤，我們可以相應地確立測試的側重點。比如：對功能要求高于界面要求的模塊，可以加強功能測試，減少界面測試用例個數或者減少界面測試用例的執行次數。
被測功能的使用頻率
使用頻率高的功能發生意外的可能性相對要高一些，而且，這些功能中一些小問題所造成的影響可能會隨著使用次數的增多而被擴大。對于這樣的模塊，測試的標準不能設置得太低，特別是核心功能中使用率最高的模塊，一般情況下應該重點測試。
發生異常情況的可能性
用戶輸入錯誤數據的可能性有多大，他們不太可能輸入什么樣的錯誤數據？用戶操作時可能會改變通常的執行順序嗎？為當前功能提供輸入數據的其他模塊的出錯機率高嗎？當一個功能需要多個模塊共同協作才能完成時，這些共同協作的模塊是否都足夠穩定？當前功能并發操作的可能性是否高？系統運行的相關軟硬件是否安全和健壯？有很多的因素我們需要考慮。
與不太可能出現的錯誤情況相關的測試用例，我們是否可以試著將其執行優先級設置低一些？例如：在多種錯誤輸入數據中，優先嘗試最有可能出現的錯誤數據；如果使用者一般不會對同一數據進行操作，那么對并發操作可以暫時不進行測試。
錯誤所造成的影響
不同模塊出現的錯誤造成的影響是不同的，這些影響可能是數據丟失、系統的異常退出等等。例如：某個操作數據庫的模塊出現異常后，有可能對數據庫造成死鎖，阻礙其他模塊的正常運行。對這樣的模塊，需要進行仔細的驗證。
被測功能是否是一個錯誤易發的功能
在執行測試的過程中，我們會發現某些模塊在幾輪測試中總是比其他模塊出現的錯誤多。這些模塊應該引起測試的注意，因為它們在以后的測試中仍然可能會出現很多錯誤，我們不能減少對它們的測試，如果這些模塊屬于核心功能或者是用戶常用的功能，可能還需要增加測試用例以更多地發現隱藏缺陷。對于那些錯誤少且錯誤數量已呈收斂趨勢的模塊，如果其本身功能未發生改變或者其他模塊的修改對其不造成影響，我們不妨適當減少對這些模塊的測試次數，例如：在后面的幾輪回歸測試中不對其進行測試，直至最后的回歸測試。
在同一模塊中也存在類似問題。如果一個模塊在前幾輪的測試中都沒有發現存在某些方面的錯誤，為檢查這些錯誤而設計的測試用例在后面幾輪回歸測試中可以減少執行次數。
測試是否足夠充分和合理與軟件交付時間和軟件質量直接相關，這不僅僅是測試組的責任。對于一個項目來說，測試工作的目的不是為了尋找錯誤而尋找錯誤，或者發現軟件的所有錯誤，而是在允許的人力條件下，保障項目組在規定時間內交付一個客戶能夠接受的軟件產品。
版權聲明：本文出自 shiningredstar 的51Testing軟件測試博客：http://www.51testing.com/?7622
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。