壹、質量需求或產品的特性理解不準確，造成測試範圍分析的誤差，結果某些地方始終測試不到或驗證的標準不對;
二、測試用例沒有得到百分之百的執行，如有些測試用例被有意或無意的遺漏;
三、需求的臨時/突然變化，導致設計的修改和代碼的重寫，測試時間不夠;
四、質量標準不都是很清晰的，如適用性的測試，仁者見仁、智者見智;
五、測試用例設計不到位，忽視了壹些邊界條件、深層次的邏輯、用戶場景等;
六、測試環境，壹般不可能和實際運行環境完全壹致，造成測試結果的誤差;
七、有些缺陷出現頻率不是百分之百，不容易被發現;如果代碼質量差，軟件缺陷很多，被漏檢的缺陷可能性就大;
八、回歸測試壹般不運行全部測試用例，是有選擇性的執行，必然帶來風險。 前面三種風險是可以避免的，而四至七的四種風險是不能避免的，可以降到最低。最後壹種回歸測試風險是可以避免，但出於時間或成本的考慮，壹般也是存在的。 針對上述軟件測試的風險，有壹些有效的測試風險控制方法，如： 測試環境不對可以通過事先列出要檢查的所有條目，在測試環境設置好後，由其他人員按已列出條目逐條檢查; 有些測試風險可能帶來的後果非常嚴重，能否將它轉化為其他壹些不會引起嚴重後果的低風險。如產品發布前夕，在某個不是很重要的新功能上發現壹個嚴重的缺陷，如果修正這個缺陷，很有可能引起某個原有功能上的缺陷。這時處理這個缺陷所帶來的風險就很大，對策是去掉(Diasble)那個新功能，轉移這種風險; 有些風險不可避免，就設法降低風險，如“程序中未發現的缺陷”這種風險總是存在，我們就要通過提高測試用例的覆蓋率(如達到99.9%)來降低這種風險; 為了避免、轉移或降低風險，事先要做好風險管理計劃和控制風險的策略，並對風險的處理還要制定壹些應急的、有效的處理方案，如： 在做資源、時間、成本等估算時，要留有余地，不要用到100%; 在項目開始前，把壹些環節或邊界上的可能會有變化、難以控制的因素列入風險管理計劃中; 對每個關鍵性技術人員培養後備人員，作好人員流動的準備，采取壹些措施確保人員壹旦離開公司， 項目不會受到嚴重影響，仍能可以繼續下去; 制定文檔標準，並建立壹種機制，保證文檔及時產生; 對所有工作多進行互相審查，及時發現問題，包括對不同的測試人員在不同的測試模塊上相互調換; 對所有過程進行日常跟蹤，及時發現風險出現的征兆，避免風險。 要想真正回避風險，就必須徹底改變測試項目的管理方式;針對測試的各種風險，建立壹種“防患於未然”或“以預防為主”的管理意識。與傳統的軟件測試相比，全過程測試管理方式不僅可以有效降低產品的質量風險，而且還可以提前對軟件產品缺陷進行規避、縮短對缺陷的反饋周期和整個項目的測試周期。