軟件測試是一項存在風險的工作，它是不可避免的，總是存在的。作為一名測試管理人員必須在平時的工作中，分析這些風險的類別，並且找出對策盡最大程度的降低這些風險。
一：軟件需求的風險主要表現在以下的幾個方面：
1.軟件需求本身不清晰或者開發商對產品的需求特性理解不准確有偏差，這樣導致最終開發的產品功能可能不是用戶真正想要的功能。
2.需求變更風險，在項目的后期用戶總是不停的提出需求變更，從而影響設計、代碼，並且最終反映到測試中來。需求變更后，測試用例沒有及時更新；更重要的是在項目的后期頻繁的需求會導致測試的時間不充分。
解決辦法：
1.在項目開發過程中的每一個階段，盡量讓有決策權的核心用戶看到產品已經實現的每個階段的功能，如果不是用戶想要的東西盡早提出來，總之要讓用戶參與進來。
2.另外對於后期用戶不停的提出需求變更作為開發商來說，應該多和有決策權的核心用戶多溝通，爭取更充分的研發時間和測試時間，或者最好能把后期提出的功能放到下一個版本中實現。
二：人員的風險
人員的風險常常表現在以下等方面：
1.核心測試人員的請假、離職
2.測試人員的工作態度不端正、工作狀態差
3.測試人員的測試技術不足，比如說產生測試的思維定勢，有些有問題的地方始終測試不到位
解決辦法：
1.對於核心的測試人員可能離職而延誤測試的情況，作為測試管理者可以在平時給這些核心人員配置一些可以候補的測試人員來向他們學習，以避免這些核心人的請假、離職的時候，可以立即補充上來。
另外，對於一些關鍵的業務和技術一定要有文檔。
2.另外可以通過對測試工程師進行考評的方式監督他們每天的工作情況，看看其工作態度是不是盡心盡力符合目前的項目測試工作，如果發現不符合的話，測試管理者可以找其單獨談話督促其改正。
3.每個測試工程師的思維方式肯定有差別，所以測試管理者多讓這些工程師在測試每一輪后，在進行不同模塊的交叉測試。
三：代碼質量的風險
如果開發人員提交上來的代碼質量很差、很爛的話，軟件缺陷很多，那么對於測試工程師來說漏測的可能性就越大。
解決辦法：對於程序員的提交給測試部門的代碼一定要在前期做好充足的單元測試、對於核心模塊的代碼一定要有資深的研發工程師進行前期檢查
四：測試環境的風險
測試人員在測試過程中搭建的測試環境，雖然原則上是盡可能模擬用戶實際使用的環境。但是不可能100%完全和用戶的環境一樣，這樣就會存在一定的風險，因為有些軟件的缺陷只有在特定的環境下（包括硬件、操作系統、殺毒軟件和軟件的不同版本的補丁和用戶實際使用的數據等）才能出現。
解決辦法：測試部門在測試過程中搭建的測試環境的時候，盡量盡一切可能無限制的模擬用戶使用的環境（硬件、操作系統的版本和補丁，數據庫的版本和補丁）在測試的時候盡量和用戶溝通要到用戶真實的數據進行測試。以減少風險。
五：測試工程師對產品的業務不熟悉
對業務產品的不熟悉一般表現在以下幾個方面：
測試工程師不了解用戶究竟是如何操作該產品和用戶的操作習慣
測試工程師介入到項目測試的時間太短
解決辦法：可以找一些相關行業的專家給測試人員進行培訓，當然用戶也就是最好的行業專家。另外測試人員一定要在項目的前期就介入到項目中去熟悉產品，對產品越熟悉找出的軟件缺陷越有價值。
六：測試深度和廣度的風險
1.測試的廣度，用戶的操作肯定是千變萬化的，測試工程師在測試的時候肯定不能100%覆蓋到這些千變萬化的操作。有些極端的情況容易被遺漏、測試不到。
2.測試的深度，比如有些軟件只有在特定的情況下，比如多用戶並發的情況下使用的過程中才會產生軟件的缺陷bug，但是測試工程師在測試的時候忽略了這種情況，只有某幾個測試工程師在測試使用這些功能。
解決辦法：測試工程師在寫測試用例的時候盡量提高測試用例的覆蓋率（在測試用例完成后組織進行測試用例的評審工作），如果測試用例能覆蓋不同的用戶千變萬化的操作最好。特別是一些邊界值、深層次的邏輯關系等。以及用戶實際使用環境下的場景（比如大用戶量的並發操作等）。
七：測試工具本身可能產生誤差
1.測試工具能模擬用戶的手工操作，但是這種工具本身就存在誤差、或者使用者操作不當產生的誤差，比如：在項目后期的回歸測試的時候使用自動化功能測試工具QTP進行回歸測試的時候，由於修改了某些腳步導致QTP每次測試都能通過，但是到用戶現場的話有可能會最簡單的功能都通不過。
2.在進行性能測試工具的時候大家常常使用Webload、Jemeter、Loadrrunner等，但是這些工具並不能100%模擬用戶的並發操作；比如用工具模擬500個用戶同時並發登錄系統，但是這些並發都是從1台或者某幾台測試機器上發出請求的。但是在用戶實際使用環境的情況下這500個用戶可能來自全國或全世界的各個地方。
解決辦法：
1.對於自動化的測試工具，一定要選擇一些知名大企業比較成熟的測試工具，比如：HP公司的Loadrunner，QTP或者IBM的系列測試工具
2. 測試工程師在使用測試工具的過程中應該大膽的排除一些不合理的測試值，比如：進行了5次的大用戶的並發測試，其中有一次的測試結果與另外4次的測試結果偏差較大，那么測試工程師就可以排除這1次偏差較大的測試（因為這1次測試結果可能受到一些其他因素的影響而導致不准確，比如受到網絡因素的影響等）。
3.另外測試工具僅僅是提高測試效率的，由於測試工程師在使用測試工具的過程中某些參數設置不合理而導致測試結果不准確。所以不要過分的相信測試工具，最后一定要進行人工的審核和檢查才可靠。
4.另外可以用不同的測試工具運行相同的測試場景，如果不同的測試工具運行相同的測試場景的測試結果相近的話，可以認為這種測試是有效的。
八：測試資源的不充分
測試資源的不充足表現在很多方面，比如：
1.硬件資源不夠，國內的很多小型的軟件企業開發和測試居然使用同一個環境，這樣肯定會影響測試效果的。
2.軟件資源不充分，比如在項目的后期進行回歸測試的工作量很大，但是測試的人手不夠。
3.測試的時間不充足，在企業實際的研發過程中，研發人員由於各種原因（如用戶提出修改或者新增某些功能、甚至研發人員的技術水平等）導致提交到測試部門的延遲，這樣無形中減少了測試人員的測試，測試時間不充足會影響到測試的效果的。
解決辦法：作為一名測試管理者有義務向公司里申請更多的測試資源，如購置獨立的測試服務器把測試環境和研發環境分開；要求招聘更多的測試人員；測試管理者應當做好測試風險的預估，比如：在制定測試計划的時候要預留一定的多余時間以應對臨時變化的一些特殊情況。