軟件測試風(fēng)險分析

1、作為軟件測試 計劃的一部分，軟件測試風(fēng)險的分析與控制是其中重要的環(huán)節(jié)。如果前期風(fēng)險分析與控制比較充分，那么會使軟件的測試成功性大大增加，且可將由風(fēng)險異常引發(fā)的額外成本（如人力，時間等）降到最低。 查閱了網(wǎng)上很多關(guān)于軟件測試風(fēng)險控制的 文章，其中不乏精品之作。 本文將此類知識進(jìn)行了歸納，查漏補(bǔ)缺，并在思維導(dǎo)向性上給出了簡單的實施步驟，以使得在實際應(yīng)用中能得到更好的運(yùn)用。第一部分：軟件測試項目級的風(fēng)險分析1. 從人、料、法、環(huán)、時等方面分析測試項目級的風(fēng)險分布探尋測試隱藏的風(fēng)險時，應(yīng)招集測試全組成員舉行會議，建議采用頭腦風(fēng)暴和詢問5Why 的方式進(jìn)行，以集思廣益和深度挖掘。下面就在魚骨圖中以TQM

2、 （全面 質(zhì)量管理 ） 的人、機(jī)、料、法、環(huán)等五個方面來全方位的分析和羅列項目級可能隱藏的風(fēng)險（注：考慮到在軟件測試中“機(jī) ”這一項更多的屬于環(huán)境這一分類，故刪除此類。另外時間對于軟件測試是一個非常重要的屬性，故添加之）。下面對魚骨圖中的各個分支及子分支進(jìn)行相應(yīng)注解：人，即測試人員：業(yè)務(wù)不熟：測試人員對被測系統(tǒng)的業(yè)務(wù)流程不熟悉，體現(xiàn)在對需求的理解上把握不準(zhǔn)、理解不透側(cè)、理解錯誤等。測試人員變動：離職，崗位調(diào)動，請假等。定位效應(yīng)：測試過的可靠的功能，特別是在多次回歸且沒有發(fā)現(xiàn)問題，在此后往往會認(rèn)為此功能是可靠的。疲態(tài)：某一些功能點(diǎn)一直由某一位測試人員測試，經(jīng)過多次回歸后，測試人員對該功能點(diǎn)的測試

3、顯示出倦意和缺乏興趣。同化效應(yīng)：經(jīng)過和開發(fā)的長時間接觸，往往會被開發(fā)的思維邏輯所同化，漸漸喪失從用戶角度出發(fā)的測試觀察點(diǎn)。料，即測試相關(guān)文檔（在TQM 中指的是生產(chǎn)原材料）：Spec （詳細(xì)規(guī)格說明書）缺失：只有 PRD（項目需求概要說明書），沒有 spec。筆者所在的公司，早些時候的產(chǎn)品更多的時候只有PRD，沒有 Spec。需求變更：這是最不想，但又最經(jīng)常發(fā)生的事情測試用例 / 數(shù)據(jù)設(shè)計不充分：某些時候由于編寫測試人員的個人因素或時間的限制等方面因素導(dǎo)致。質(zhì)量標(biāo)準(zhǔn)不統(tǒng)一：如某些Bug 的優(yōu)先級方面，測試和開發(fā)的認(rèn)同不一致。法，即測試方法和實施：錯誤或缺失測試方法：對功能點(diǎn)沒有采用正確的測試方

4、法，或某些測試方法沒有被忽視，如邊界測試等，導(dǎo)致測試不充分。場景的缺失或部分缺失：Spec 非常詳細(xì)，所有的精力放在功能點(diǎn)的測試上，忽視了業(yè)務(wù)場景（Spec 中無定義）的全（100%）測試。測試用例實施不充分：測試用例由于各種原因沒有完全測試，如在回歸測試中。環(huán)，即測試環(huán)境：被測軟件版本不統(tǒng)一：沒有有效的配置管理 ，這種情況及易出現(xiàn)測試軟件環(huán)境不一致：測試員之間或和開發(fā)之間的操作系統(tǒng) 類型不一致、操作系統(tǒng)的干凈程度不一致。測試硬件環(huán)境不一致：測試員之間或和開發(fā)的設(shè)備不一致，如CPU頻率，內(nèi)存大小等。測試硬件未及時到位時，即測試時間：測試時間不足：里程碑之間留給測試的時間無法滿足全測試要求。測試

5、時間延長：由于需求方突然宣布原進(jìn)度表中的里程碑時間點(diǎn)延后，導(dǎo)致項目的進(jìn)度表一下松弛了許多。筆者參加過的兩個項目就遇見過這種情況，我們?yōu)槭澜缒持放齐娔X供應(yīng)商開發(fā)并提供隨機(jī)軟件。在項目進(jìn)展到中后期時，客戶忽然通知我們暫時不安排我們的軟件在他們這一版本系統(tǒng)中進(jìn)行安裝，要等到下一版本，時間延遲可能長達(dá)三個月，甚至更多。注：以上五個方面不可能將所有軟件測試中潛在的風(fēng)險全部羅列，旨在給出思維方式。2. 采用 FMEA 評估及分析風(fēng)險項在采用 FMEA 對風(fēng)險進(jìn)行評估和分析前，有必要先熟悉一些FMEA 的知識點(diǎn)。（1）FMEA （ Failure ModeEffects Analysis）：潛在失效模式

6、和結(jié)果分析。即找出產(chǎn)品/ 過程中潛在的故障模式根據(jù)相應(yīng)的評價體系對找出的潛在故障模式進(jìn)行風(fēng)險量化評估；列出故障起因 / 機(jī)理，尋找預(yù)防或改進(jìn)措施。（2）FMEA 關(guān)鍵項：Function （功能要求）：What is design/process/servicesupposed todo atthis stageFailure Mode （潛在失效模式）：A specific means by which a design (product),process, orservice may fail.Effect （潛在失效后果）：What happens when thefailure occ

7、ursSeverity （嚴(yán)重度）：How serious is the consequence of the failure The value is 110.Cause （潛在的失效起因）：What can occur to cause the failureOccurrence （頻度）：How oftenwillthe cause/failureoccur The value is 110.Current Control （現(xiàn)行控制）：Current methodto detect/preventtransmission of failures tosubsequent “ custo

8、mers ”.Detection（探測度）：Can the cause/failurebe detectedif it occurs The value is 110.RPN （風(fēng)險順序數(shù)）：Review Risk PriorityNumbers,RPN = (Severity) x (Occurrence) x (Detection)Recommended Actions （建議措施）：What can we doResponsibility & Target CompletionDate (責(zé)任及目標(biāo)完成日期): When it can be fixedActions Taken

9、Result （措施結(jié)果）：The actuallyresult afteraction have been taken.（ 3）FMEA 流程：本文只給出了簡單流程示意圖，更詳細(xì)的流程做法，請參看FAILURE MODES AND EFFECTSANALYSISKenneth Crow 中的 FMEA Procedure 章節(jié)。下面給出一個 FMEA 的簡單模板，可以參照下圖的表格填寫上面人、料、法、環(huán)、時五大因素中所提及的各個風(fēng)險子項填寫在 Function 一列，并按公司的切實情況填寫后續(xù)各列。第二部分：軟件測試用例級的風(fēng)險分析1. 測試用例風(fēng)險分析的目的在進(jìn)行回歸測試等情況下，從所有測

10、試用例集（含功能點(diǎn)和場景測試兩部分）中如何選擇最小測試用例集，是一個值得思考的問題，本文僅想從測試用例風(fēng)險系數(shù)等級劃分來對這一問題進(jìn)行部分探討。對所有測試用例進(jìn)行風(fēng)險系數(shù)等級劃分，并按等級數(shù)進(jìn)行排序。在選擇回歸測試用例集時，從中挑選風(fēng)險系數(shù)等級級別的高的測試用例進(jìn)行優(yōu)先測試，最后根據(jù)項目進(jìn)度條件從風(fēng)險等級高到等級低的合理選擇回歸測試用例集。2. 采用風(fēng)險矩陣評估及分析測試用例優(yōu)先級測試用例風(fēng)險出現(xiàn)概率 (110)后果與影響 (110)風(fēng)險系數(shù) (=出現(xiàn)概率x 影響 )規(guī)避措施第三部分：總結(jié)與說明1.本文沒有對項目管理方面的隱藏風(fēng)險進(jìn)行探尋，如項目經(jīng)費(fèi)成本風(fēng)險分析等。僅從測試本身考慮了風(fēng)險分布，

11、角色定位于測試項目 Leader，而前者則是 PM。2.本文的標(biāo)題定為測試風(fēng)險分析，所以對于發(fā)生風(fēng)險后所應(yīng)該采用的規(guī)避措施，沒有在文中給出，可采用根據(jù)公司內(nèi)容的實際情況采用頭腦風(fēng)暴進(jìn)行解決方案的探討和篩選，也可參考網(wǎng)上一些文章所建議的解決方案。3.風(fēng)險分析的方法有很多種，如Boehm 的六步風(fēng)險管理法、Rex Black 在軟件測試核心過程一書中提到的風(fēng)險分析過程等都是比較優(yōu)秀的方法， 但其精髓和 FMEA、風(fēng)險分析矩陣是如出一轍， 個人覺得以表格的形式展示更加形象化。參考：1、測試有道- 微軟測試測試技術(shù)心得梁博，許珊等電子工業(yè)出版社2、測試風(fēng)險的管理3、風(fēng)險列表noone_pm4、軟件測試

12、管理常見問題及其回答 songfun 二軟件測試風(fēng)險是不可避免的、總是存在的，所以對測試風(fēng)險的管理非常重要，必須盡力降低測試中所存在的風(fēng)險， 最大程度地保證質(zhì)量和滿足客戶的需求。 在測試工作中， 主要的風(fēng)險有：一、質(zhì)量需求或產(chǎn)品的特性理解不準(zhǔn)確，造成測試范圍分析的誤差，結(jié)果某些地方始終測試不到或驗證的標(biāo)準(zhǔn)不對；二、測試用例沒有得到百分之百的執(zhí)行，如有些測試用例被有意或無意的遺漏；三、需求的臨時/ 突然變化，導(dǎo)致設(shè)計的修改和代碼的重寫，測試時間不夠；四、質(zhì)量標(biāo)準(zhǔn)不都是很清晰的，如適用性的測試，仁者見仁、智者見智；五、測試用例設(shè)計不到位，忽視了一些邊界條件、深層次的邏輯、用戶場景等；六、測試環(huán)境，

13、一般不可能和實際運(yùn)行環(huán)境完全一致，造成測試結(jié)果的誤差；七、有些缺陷出現(xiàn)頻率不是百分之百，不容易被發(fā)現(xiàn)；如果代碼質(zhì)量差，軟件缺陷很多，被漏檢的缺陷可能性就大；八、回歸測試一般不運(yùn)行全部測試用例，是有選擇性的執(zhí)行，必然帶來風(fēng)險。前面三種風(fēng)險是可以避免的，而四至七的四種風(fēng)險是不能避免的，可以降到最低。最后一種回歸測試風(fēng)險是可以避免，但出于時間或成本的考慮，一般也是存在的。針對上述軟件測試的風(fēng)險，有一些有效的測試風(fēng)險控制方法，如：·測試環(huán)境不對可以通過事先列出要檢查的所有條目，在測試環(huán)境設(shè)置好后，由其他人員按已列出條目逐條檢查；·有些測試風(fēng)險可能帶來的后果非常嚴(yán)重，能否將它轉(zhuǎn)化為其

14、他一些不會引起嚴(yán)重后果的低風(fēng)險。 如產(chǎn)品發(fā)布前夕， 在某個不是很重要的新功能上發(fā)現(xiàn)一個嚴(yán)重的缺陷， 如果修正這個缺陷， 很有可能引起某個原有功能上的缺陷。 這時處理這個缺陷所帶來的風(fēng)險就很大，對策是去掉 (Diasble)那個新功能，轉(zhuǎn)移這種風(fēng)險；·有些風(fēng)險不可避免，就設(shè)法降低風(fēng)險，如“程序中未發(fā)現(xiàn)的缺陷”這種風(fēng)險總是存在，我們就要通過提高測試用例的覆蓋率（如達(dá)到%）來降低這種風(fēng)險；為了避免、轉(zhuǎn)移或降低風(fēng)險，事先要做好風(fēng)險管理計劃和控制風(fēng)險的策略，并對風(fēng)險的處理還要制定一些應(yīng)急的、有效的處理方案，如：·在做資源、時間、成本等估算時，要留有余地，不要用到100%；·在項目開始前，把一些環(huán)節(jié)或邊界上的可能會有變化、難以控制的因素列入風(fēng)險管理計劃中；·對每個關(guān)鍵性技術(shù)人員培養(yǎng)后備人員，作好人員流動的準(zhǔn)備，采取一些措施確保人員一旦離開公司，項目不會受到嚴(yán)重影響，仍能可以繼續(xù)下去；·制定文檔標(biāo)準(zhǔn)，并建立一種機(jī)制，保證文檔及時