好像所有帶有『管理』字樣的東西都變得不那麼具體了。
一般這個東西就要對症下藥了，所以首先得知道有什麼樣的風險。在實際的工作中主要遇到過以下的風險型別：
1、需求變更，這個是最大的風險，因為最後期限是不變的，需求變了，就意味著更多的工作要在已計畫好的日程表中做完。風險可排老大
2、人員變動，在乙個可以持續2，3個月的專案中，中途可能有人離職
3、需求理解問題，由於缺少行業知識，業務背景，有可能對需求的認識不夠透徹
4、複查工作沒做好
5、需求覆蓋率不高
6、測試用例執行沒有達到100%
7、測試環境和實際環境有偏差
8、測試缺陷很難重現，導致無法定位根源從而沒有修復
針對第一條：估計每個公司都在這上面吃過虧吧。所以才有那麼多的軟體開發模型。我所經歷過的一些比較大的專案，採用的都是增量迭代的開發模式，所以在每乙個小的階段，需求是相對穩定的。但是也有變更的時候，這種時候，我們一般是要求走需求變更流程，根據變更的大小來確定策略：如果變更造成的工作量小於3天/人，作為乙個adhoc專案，如果大於3天/人，就作為另乙個新的專案。這個當然要和客戶達成一致。
針對第2條：最好是每個崗位培養備份的人員
3，4，5條其實可以歸結為一條，我們盡量在需求分析階段就把自己所有不明白，不清晰的問題提出來，整理成乙個文件，先內部回答，這個內部可以包含開發，然後發給需求方請求答案。測試用例評審會要組織好，在開始之前，要求每個人所設計的用例至少被2個不同級別的人員評審過，然後再評審會上確定最終的問題和解決方案，會後跟蹤這些評審會上出現問題的狀態。
第6條是完全可以避免的。如果時間確實很緊，按優先級別選擇最重要的case去跑。
第7條嘛，一般是在搭建測試環境之前，列出一些需要檢查的項，搭好後，讓人按這個檢查項一項一項的去檢驗。
說在最後的，做測試肯定要得到老大的支援和重視，否則風險控制都是空談啦。盡量每個階段都要文件化，規範化。
做任何事情都有風險，風險管理無非就是消除，消除不了就減少，減少不了就降低。降低到一定程度就不再有威脅，或者短時間沒威脅，沒威脅就不是風險了。
針對測試的各種風險，還是建立一種「防患於未然」或「以預防為主」的管理意識比較靠譜。
此文為個人經驗，不對之處請指教。
軟體風險管理
任何開發專案都可能存在著風險，如果我們提前重視風險，並且有所防範，就可以做到最大限度減少風險的發生。進行風險管理就是我們可以採用有效的手段之一。風險管理要求我們管理人員在資訊不完備的情況下作決定。其模式通常由三個步驟組成 風險確定 風險影響分析以及風險應對計畫。1 風險的分類 根據風險內容，我們可以...
軟體測試風險分析
軟體測試風險分析的基本方針 制定軟體測試計畫並排列優先順序。風險分析是對軟體中潛在的問題進行識別 估計和評價的過程。軟體風險分析的目的是確定測試物件 測試優先順序以及測試深度。有時還包括確定可以忽略的測試物件。通過風險分析，測試人員識別軟體中高風險的部分並進行嚴格徹底的測試 確定潛在的隱患軟體構件，...
軟體測試風險分析
1 什麼是風險？2 什麼是軟體風險 3 識別軟體風險 4 商業風險 開發乙個沒有人真正需要的優秀產品或系統 市場風險 開發的產呂不再符合公司的整體商業策略 策略風險 建造了乙個銷售部門不知道如何去賣的產品 營銷風險 由於重點的轉移或人員的變動而失去了高階管理層的支援 管理風險 沒有得到預算或人力上的...