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