好像所有帶有‘管理’字樣的東西都變得不那么具體了。
一般這個東西就要對癥下藥了，所以首先得知道有什么樣的風險。在實際的工作中主要遇到過以下的風險類型：
1、需求變更，這個是最大的風險，因為最后期限是不變的，需求變了，就意味著更多的工作要在已計劃好的日程表中做完。風險可排老大
2、人員變動，在一個可以持續2，3個月的項目中，中途可能有人離職
3、需求理解問題，由于缺少行業知識，業務背景，有可能對需求的認識不夠透徹
4、復查工作沒做好
5、需求覆蓋率不高
6、測試用例執行沒有達到100%
7、測試環境和實際環境有偏差
8、測試缺陷很難重現，導致無法定位根源從而沒有修復
針對第一條：估計每個公司都在這上面吃過虧吧。所以才有那么多的軟件開發模型。我所經歷過的一些比較大的項目，采用的都是增量迭代的開發模式，所以在每一個小的階段，需求是相對穩定的。但是也有變更的時候，這種時候，我們一般是要求走需求變更流程，根據變更的大小來確定策略：如果變更造成的工作量小于3天/人，作為一個ADHOC項目，如果大于3天/人，就作為另一個新的項目。這個當然要和客戶達成一致。
針對第2條：最好是每個崗位培養備份的人員
3，4，5條其實可以歸結為一條，我們盡量在需求分析階段就把自己所有不明白，不清晰的問題提出來，整理成一個文檔，先內部回答，這個內部可以包含開發，然后發給需求方請求答案。測試用例評審會要組織好，在開始之前，要求每個人所設計的用例至少被2個不同級別的人員評審過，然后再評審會上確定最終的問題和解決方案，會后跟蹤這些評審會上出現問題的狀態。
第6條是完全可以避免的。如果時間確實很緊，按優先級別選擇最重要的CASE去跑。
第7條嘛，一般是在搭建測試環境之前，列出一些需要檢查的項，搭好后，讓人按這個檢查項一項一項的去檢驗。
第8條，還真沒什么好辦法，如果你有，麻煩告訴我下。我們一般遵循的是只要是出現過的，哪怕一次也是缺陷，都要記錄在案的。也可以在交付客戶時說明并一同交付。
說在最后的，做測試肯定要得到老大的支持和重視，否則風險控制都是空談啦。盡量每個階段都要文檔化，規范化。
做任何事情都有風險，風險管理無非就是消除，消除不了就減少，減少不了就降低。降低到一定程度就不再有威脅，或者短時間沒威脅，沒威脅就不是風險了。
針對測試的各種風險，還是建立一種“防患于未然”或“以預防為主”的管理意識比較靠譜。
此文為個人經驗，不對之處請指教。