減輕產品風險的測試設計技術
| （ |
 Erik van Veenendaal是一名國際領先的顧問和培訓師，和一名在軟體測試和質量管理領域廣受認可的專家。 他是Improve Quality Services BV的創始人。 他保持著歐洲之星的記錄，三次獲得最佳導師將！ 2007年，因其對測試專業做出多年貢獻，他獲得了歐洲測試優秀獎。 他作為測試經理和顧問在各個領域工作了20多年。他撰寫了多篇論文和多部著作，包括“實用基於風險的測試： Prisma法”和“軟體測試ISTQB基礎” 。 他是TMap測試方法的核心開發人之一及一名國際需求工程局（ IREB ）的工作小組的參與者。 Erik曾是艾恩德霍芬科技大學的一名兼職高階講師及國際軟體測試認證委員會的副會長（ 2005-2009 ） ，目前是TMMi基金會的董事會成員。 |
在審查對“測試經驗”問題的貢獻時，我注意到，許多作者一開始就解釋如何使用和應用特定的測試設計技術。但是，我們不應該忘記我們為什麼要這樣做，即這樣做的目標是什麼。目標絕不“僅僅是”使用測試設計技術，而是使用正確的測試設計技術以減輕產品的風險，無論是功能性的還是非功能性的。
基於風險的測試
在基於風險的測試中，風險識別、風險分析、及風險緩解活動的制定奠定了定義測試方法的基礎[ 4 ] 。每個風險專案相關的風險級別決定每個風險相關的測試工作（即減緩行動）所需要的精力。某些安全相關的標準規定了：要用的測試方法和要達到的基於風險度（見下文）的覆蓋率。
測試設計技術
降低產品風險的一個選擇是使用測試設計技術。
風險的級別和型別應是一個：通過使用不同測試設計技術改變測試強度的主要引數。如：對高風險的測試專案使用決策圖表技術（decision table technique），對低風險測試專案使用“唯一”等價類劃分方法，或對高風險測試專案使用完整決策圖表技術，對低風險測試專案使用崩潰決策圖表技術（collapsed decision tables），等等。
釋出一個產品時的商業風險或許會受到質量問題（因此更正式的測試設計技術才合適），或上市時間問題的影響（因此探索性測試將是一個更合適的選擇） 。
當然，選擇要用的測試設計技術的時候，風險不是唯一因素（儘管是非常重要的一個）。
決策將基於多個因素，包括內部的和外部的，例如[2]：
內部因素
使用模型
測試員的知識及經驗
預期缺陷型別
可用文件
生命週期模型
生命週期階段，例如新開發或維護
外部因素（除了風險的級別和型別）
客戶/合同要求
系統型別
監管要求
時間和預算
基於風險的測試方法
圖1.系統測試的不同的基於風險的測試方法的例子
為了解釋基於風險的測試方法意味著什麼，下面提供了簡化的系統測試例項。基於產品風險矩陣的系統測試方法[4] ，如圖1所示。這個例子表明，最關鍵的項，第II象限，使用用例（包括備選流）及決策表的全面測試設計技術來進行測試。
該方法按比例縮小為第二最高風險級別就是第IV象限。 （請記住，系統測試主要關注商業風險）。用例（包括備選流）仍適用於第IV象限，但決策表，現在不再適用了。
相反，等價類劃分被用作一項通常比決策表技術定義更少測試用例的測試設計技術。用例仍然用於第I象限，但只執行主流，等價類劃分再次被用作測試設計技術。對於第III象限，只測試測試用例主流。根據風險等級和風險型別變換測試設計技術的另一個有用的例子可以在IEC 61508中找到[ 3 ] 。對展示了其如何根據軟體完整性等級（SIL ）（風險等級的另一術語表達）來區分測試技術的標準的一段引用，見下表：
1.該標準覆蓋了靜態和動態測試技術，並具有各種測試等級的和用於維護測試的特定表格。
表1.IEC61508軟體完整性等級（R：推薦，HR:強烈推薦）
另一個例子來自於DO-178B[1]。 此標準還採用了方法——將進行的強度測試應源於風險等級。
這些標準規定的測試方法，應用於每個安全級別，以及恰當的完成標準（見表2中的示例）。 專業測試應意識到：有用的標準是可獲得的，如在IEC61508[3]和DO-178B[1]中，兩者可以在使用測試設計技術定義不同的基於風險的測試方法時提供支援和靈感。
表2. 測試元件基於風險的方法 [1]
專注產品風險
詳細解釋所有提到的測試設計技術、它們如何與測試強度相關、它們如何相互關聯、以及他們如何在內部變化，都超出了本文的範圍。但是很明顯，為定義一個完整的測試方法，對測試設計技術有詳細瞭解是必須的。
許多測試員都是技術型的，有時往往會在測試設計技術的技術性中迷失自己。他們很可能設計和編寫出很棒的測試用例，但這些測試用例真的有必要和正確嗎？
本文的主題是：產品風險應是選擇是否測試設計技術是必要的，哪些是需要的，及他們該如何應用的主要驅動力。
經常去想想你為什麼要申請測試設計技術及目標是什麼。測試設計技術絕不是目標，他們只是達到目標的手段。專注對開發一個好產品很重要的事物。我相信這就是敏捷宣言所宣告的“全面文件層面的工作軟體”的意思。
使用測試設計技術肯定不是一件壞事（相反這是件好事），但要在他們有重要意義的，有附加價值的地方使用它們。用敏捷的，有效率的和以風險為本的方式使用他們。
參考文獻
[1] DO-178b (1992)， Software Considerations in Airborne Systems and
Equipment Certification， Requirements and Technical Concepts for
Aviation， RTCA SC167
[2] D. Graham， E. van Veenendaal， I. Evans and R. Black (2008)， Foundations in Software Testing– ISTQB Certification， 2nd edition， Cengage
Learning
[3] IEC 61508 (1998)， Functional Safety for electrical/electronic/ programmable electronic related systems， Industrial Electrical Committee
[4] E. van Veenendaal (2012)， Practical Risk-Based Testing， The PRISMA
Approach， UTN Publishing
版權宣告：本文出自 SPASVO澤眾軟體測試網：http://www.spasvo.com/news/html/2014324153302.html
原創作品，轉載時請務必以超連結形式標明本文原始出處、作者資訊和本宣告，否則將追究法律責任。
轉載於:https://my.oschina.net/spasvo/blog/212836