質量風險分析（下） 軟件測試
質量風險分析過程
不管選擇哪種技術，都可以遵循一個相似的質量風險分析過程。
1.識別質量風險分析小組；
2.選擇一種技術；
3.識別質量風險，對風險進行優先排序。選擇合適的風險緩解方式。（不僅包括測試的各個階段，而且包括審查需求、設計和代碼、編程技術等一系列檢查范圍等等）；
4.如果風險分析小組識別出需求、設計、代碼或其他項目文檔、模型或已交付產品的問題，會報告這些問題，尋求解決方法；
5.審核、修改和定稿質量風險分析文件；
6.檢查質量風險分析文件納入項目庫的變更控制之下。
7.定期（比如，重要的項目里程碑，如需求、設計和實施階段完成，測試準備及退出審查時）及出現新的信息（比如，測試周期完成）時，檢查并更新風險分析，增加新的條目并重新估算新條目的風險等級。
作者更喜歡利用頭腦風暴或類似有啟發性的技術，把步驟3作為一個單獨的單元進行。但是，在被風險分析控告的人和質量風險分析小組之間，他把這一步作為一系列會話，甚至是一對一的會話，執行了。
除了選擇合適的技術，為了在質量風險分析過程中獲得更多有用的東西，還有必要選擇合適的參與者。需要一個在測試和質量方面代表所有利益相關者利益的跨職能的小組。如果不是代表所有各方的利益，那么就有可能遺漏一些關鍵的風險，也可能過高或過低的估計了一些風險的等級。
誰是關鍵的利益相關者？一般的規則是有兩個群體。首先，理解顧客和/或用戶需求和利益的那些人，或者與測試過程有直接關系的那些人。（必要時，顧客和用戶也可能參與進來。）從商業方面考慮，他們能幫助評估出潛在問題的影響力。其次，洞察系統技術細節的那些人。從技術方面考慮，他們能幫助評估出潛在問題的可能性。
在過程中，除了有信息收集的性質，建立共識也是至關重要的。關注商業和關注技術的參與者都能、也應該協助進行風險優先級分類，并選擇可以減輕風險的戰略方案。
案例分析：質量風險分析過程
對互聯網應用來說，作者把質量風險分析看作一系列的會話，并與組織中的關鍵管理者和技術領導進行討論。他已經起草了銷售需求和設計規范，以及一個可在各利益相關者之間共享的高水平系統的構思。這個風險分析討論在作者和他的助手之間就測試工作已經達成了堅實的共識。
質量風險分析過程有兩個需要注意的副作用。第一，它解釋了系統的版本是不斷演變的，不是一成不變的，尤其是在細節上。對什么有風險、什么質量優良達成一致意見，有助于促進理解共識對系統質量的意義。第二，風險分析（連同隨后的測試設計工作）突出了需求和設計文檔的許多問題。解決問題，防止缺陷進入測試過程。
拿文檔安全應用來說，作者的客戶沒有書面的規范。拿互聯網應用來說，建一個共享版的系統。幸運的是，作者能夠利用一個下午的時間召集所有的利益相關者召開一個關于質量風險分析的會議。由此產生的文檔可作為測試重點指南和測試設計過程的第一步。
除了創建有用的文檔，還有兩個需要注意的副作用。第一，開發小組決定采取措施積極主動地預防缺陷發生。令人鼓舞的是質量風險分析會議上，開發主管和技術領導采取諸如加強設計和代碼審查的質量風險減緩措施。第二，風險分析文檔成為實際需要的文件。由于質量風險分析側重于不做什么，所以他們會否定地表達需求。
用質量風險的總體等級確定測試資源
質量風險分析應該識別風險本身及與其相當等級的風險。要確定風險的等級，其可能性和影響力是考慮的主要因素。作者喜歡把這兩項分為五個等級：非常高、高、中、地、非常低。失效模式及效應分析考慮三個因素--發現問題的嚴重性、優先級和可能性--變化范圍從1到10。
把這兩個（或三個）因素轉化為一個，聚合風險等級，人們可以運用質量風險分析小組的集體判斷，一個公式或一個表格。在互聯網應用案例的分析中，作者依靠集體判斷來決定風險適當的總體等級。在文件安全案例分析中，他按照失效模式和效應分析標準從三個因素的等級級別中得到從1到1000風險優先級數，然后它被分解成代表不同總體風險的等級范圍。要使用表，首先建立一個類似表3所示的查找表，然后在每個風險條目兩個因素的基礎上，用它來分配風險的總體等級。假設給定總體風險等級，然后人們就可以用它們來確定他或她想要進行測試的范圍。例如，可能采用的規則列于表4中。
在表4中，注意不進行非常低和低風險范圍的測試。對于中、高和非常高的風險，他或她承諾通過增加時間和工作量進行測試，以減少相關風險。那么每個級別合適的分界線在哪里呢？這是利益相關者的又一個問題。做那個界別的測試會使利益相關者感覺滿意，每個風險得到充分的緩解。
這個問題的答案必須是切合實際的。在沒有任何限制的情況下，人們可能喜歡對大多數而不是所有風險做大量測試。然而，如前所述，這是不可能的。所以，風險分析的每個參與者要問的是：“通過測試來減輕風險，我愿意消耗--在時間、項目預算、甚至是可能失去功能方面--的是什么？”
案例分析：把相關的質量風險作為向導
在互聯網應用項目中，作者遵照的是表4的規則。風險通過各種方式，把測試集和工具的高級設計降低為測試用例和數據的低級設計和執行。假如作者按照瀑布/V-模型系統開發生命周期著手于一個中型項目，那么這種程度的架構是合適的。
在文件安全應用項目中，這個方法是很不正式的。整個項目小組中的每個人都明白測試小組將會高度關注高風險，較少關注中風險，可能會完全不關注低風險。假設作者按照相對靈活的系統開發生命周期著手于一個小型項目，那么這種非正式是合適的。
整個生命周期風險的緩解和管理
到此為止，讀者已經看到質量風險分析過程是怎樣的，以及由此產生的文檔可作為測試設計的依據。但是，它也能在整個項目中為質量工作者提供指導。讓我們看看分析幫助緩解和管理質量風險的七種方式，。
第一，為什么等著測試來緩解重要的質量風險？就像文件安全案例分析（參見圖1）中顯示的，質量風險緩解活動包括各種質量安全工作。在作者做過的許多項目中，需求、設計、代碼的審查被證明是有用的。采用和遵照編碼標準有助于程序員避免有危險的架構。防御性的編程技術，如結對編程、測試第一編程，及代碼調試器逐步檢測代碼發展過程中的錯誤。在生命周期的各個階段，尤其是早期，越重要的質量風險，就越巧妙地包含了多個質量保證工作的重點。
第二，在他或她設計和開發測試的時候，他或她可使用質量風險分析文檔確保其完整性。暫時假設他或她按照表4的方法，在這種情況下，測試團隊開發的每個測試用例應該映射到一個或多個中、高或非常高的范圍，每個中、高、或非常高風險的風險范圍應該映射到一個或多個測試用例。相對風險越高，那個風險范圍的測試就越多。如果想要明確了解測試人員適當地涵蓋了所有風險，讓他們明確這個映射關系，有時稱為跟蹤矩陣（參見，例如， Craig and Jaskiel 2002）。
第三，在準備運行測試的時候，他或她可以用這個跟蹤矩陣，從風險到測試用例中選擇首先執行哪個測試。一個好的優先級測試用例執行的經驗規則是：在查找微小缺陷之前先查找重大的缺陷。所以，再次依照表4的方法，測試出的非常高的風險應該先于測試出的高風險，也應該先于測試出的中風險。
第四，在開始測試時，他或她應該收集實際測試結果并找到真正的--非潛在的--缺陷。在每個風險范圍內的缺陷種類和數量應該有風險分析準確的反饋意見。如果非預期的地方出現了很多缺陷，可能是技術風險--就是說，缺陷出現的概率與某些風險范圍相關--高于以前的想法。如果危險缺陷出現在認為缺陷微小的地方，可能是商業風險--就是說，缺陷的影響與某些風險范圍相關--高于起初的想法。如果能跟蹤測試結果，并且缺陷能恢復到測試執行的第一天，那么就可以在他或她認識的基礎上，調整風險分析和測試焦點（Black 2002）。
第五，繼續執行測試，他或她會發現測試的時間少于需要的時間。項目組扭轉非預期的規格變化、多于預期的測試周期、程序員和供應商的遲到交付：所有這些會給測試施加壓力。通過跟蹤伴隨特殊測試用例風險的相對等級，可以通過最小化風險增加的方法，智能地調整將要執行的測試量。
第六，到達開發項目的末期，他或她有時發現需要做較多變更，增加最后一個功能，或修復最后一個缺陷。經常需要做一些重復測試（即，回歸測試），以保證不會破壞之前可以正常工作（即，系統中沒有造成回歸測試）的地方。要選擇一個回歸測試集，人們可以--可能應該--分析變更，決定伴隨著特殊變更、條件或缺陷修復的回歸測試的可能性。但是，人們也可以--可能應該--用質量風險分析來選擇最重要的測試。
第七個和最后一個優勢，注意在這篇文章中作者多次提到可追溯性。捕捉和支持這里所描述的所有優點的最好方法是創建一個可追溯數據庫。這種數據庫的高級實體關系圖如圖2中所示。在這個圖表中，注意如何把質量風險與測試用例、測試用例與測試結果和缺陷、測試結果和缺陷與質量風險關聯起來。這使得報告測試結果不僅根據--畢竟相當抽象的數量--測試用例數量（例如，運行、通過和未通過的）和缺陷數量（例如，被發現、已修復和剩余的）而且根據通過測試緩解的風險和依然居高不下的風險。
一個警示性的案例分析
質量風險分析過程中的一個約定被打破了。作者的客戶有了詳細的書面規范，有一個8個人共享版系統的核心。但是，所有的利益相關者都太忙而沒有時間進行風險分析，他們讓作者和他的助手們進行風險分析。
他們是這樣做的，部分是面對面交談、通過電話、郵件聯系，但是大多數是根據需求和設計規范進行分析的。然后，他們對質量風險分析文檔的意見進行交流。少數利益相關者會提出意見，因為只有少數人閱讀了此文檔。不過，這個分析是他們關注的唯一指南， 他們制訂并準備執行這些測試。
在這一點上，計劃和預算的壓力使項目經理減少了廣度和深度測試，這些減少根本沒有按照風險分析去做。項目的管理團隊并沒有承諾進行風險分析，他們不清楚這會告訴他們什么。因此，他們根據他們對質量風險相關等級的有限理解，武斷地決定放棄哪個測試和保留哪個測試。根據這個經驗，作者得出了一個結論：對成功的質量風險分析過程來說，涉及適當的利益相關者，并確保利益相關者參與到合適的風險等級中去比提供大量的文件更重要。
結論
本文中，作者解釋了人們如何以及為什么把風險分析作為測試和其它質量保證工作的基礎。他討論了如何把傳統項目的風險管理思想擴展到包括系統在內的質量風險管理。他包括為潛在問題建立質量風險相關等級的可能性（技術風險）和影響力（商業風險）的因素。
在羅列了一般概念之后，作者轉移到了力學之上。他審查了五種質量風險分析技術：非正式的、ISO9126、暴露成本、失效模式和效應分析、危險性分析。他涵蓋了一個進行質量風險分析的通用的、適應性強的過程。
最后，作者回顧了應用于質量風險分析的多種方法。質量風險分析為智能的測試設計和開發提供了基礎。然而，這僅僅是個開始。作者也展示了在整個項目生命周期中，人們會繼續用質量風險分析開展重新評估、管理和緩解系統質量風險的工作。
參考文獻
Black, R. 2003. Critical testing processes. Boston: Addison-Wesley.
Black, R. 2002. Managing the testing process, second edition. New York: John Wiley and Sons.
Craig, Rick, and Stefan Jaskiel. 2002. Systematic software testing. New York: Artech House.
ISO. 2000. ISO 9126-1:2000 Information technology: Software product quality. Geneva, Switzerland: International Organization for Standardization.
Jones, T. Capers. 1995. Estimating software costs. New York: McGraw-Hill.
Juran, J. M. 1988. Juran on planning for quality. New York: Free Press.
Stamatis, D. H. 1995. Failure mode and effect analysis. Milwaukee: ASQ Quality Press.
傳記
Rex Black是RBCS公司的總裁和首席顧問，他是一個有20年軟件和系統工程的老手，軟件、硬件和系統測試的領導者。十多年來，RBCS為其全球范圍內的用戶提供培訓、咨詢、人員配備、現場、非現場、以及離岸項目實施方面的服務。RBCS的許多用戶遍及4大洲的16個國家，包括Adobe 公司（印度）， 上海貝爾阿爾卡特銀行， 第一銀行，思科， Comverse公司，戴爾公司，美國國防部，日立公司， NDS公司， Reef公司， 和Schlumberger公司。他受歡迎的第一個著作《Managing the Testing Process》，現已發行第二版，已經在全球賣了30，000冊，包括日語版、中文版、印度語版。他的最新著作《Critical Testing Processes》是2003年出版的，已經賣出了2，000冊，其中包括翻譯成日語和俄語的版本。Rex也寫了許多文章，同時還在各種美國和國際會議上發表論文、參加研討會和演講。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
