基于風險的測試，幾乎每個測試人員或多或少在測試實踐中運用它。對于基于風險的測試設計，測試人員首先需要考慮的是風險在哪里？即識別和分析測試對象中的風險是進行基于風險的測試設計的前提條件。

　　基于風險的測試設計可以采用的技術包括啟發式分析方法、攻擊，以及失效模式和影響分析FMEA，其中啟發式分析方法由從內到外的啟發式分析方法INSIDE-OUT和從外到內的啟發式分析方法OUTSIDE-IN組成。本文將對INSIDE-OUT分析方法進行簡單的描述。

　　INSIDE-OUT的基本思路是從具體分析測試對象的詳細信息和背景信息入手，識別與之相關的風險。采用該方法，測試人員在學習測試對象時需要不斷地提出這樣的問題“這里可能會存在什么樣的風險”。更加正確地說，針對測試對象的每個部分，測試人員需要回答下面3個問題。

　　● 弱點Vulnerabilities：測試對象有何種弱點或者可能的失效？

　　● 原由Treats：測試對象在何種輸入或者情況下會導致出現缺陷和弱點，并且觸發測試對象出現失效？

　　● 影響者Victims：弱點或者失效的影響對象是誰？其影響程度有多大？

　　INSIDE-OUT分析方法需要測試人員深入了解測試對象，例如：深刻理解測試對象的具體技術實現。INSIDE-OUT并不一定只是局限于測試團隊內部，也可以和開發人員合作進行。其常用過程可以是在帶有黑板/白板的會議室中測試人員詢問開發人員相關的問題（如這個功能是如何實現的？）；開發人員在黑板/白板上畫出相應的原理圖，并講解測試對象的內部工作過程；同時測試人員在開發人員畫原理圖時，快速地思考一些問題。

　　INSIDE-OUT通過這樣的一個過程，測試人員和開發人員之間可以很快的在測試對象工作原理方面有相當的認同。在測試人員存在疑慮或者不清楚時可以立即詢問開發人員。在了解測試對象的工作原理之后，測試人員即可開始查找其中的弱點或者可能的失效。下面是測試實踐過程中對INSIDE-OUT分析方法的模擬應用。

　　下面是開發人員和測試人員進行INSIDE-OUT的一個模擬場景，測試人員提出有關問題，開發人員解釋或者思考每個問題：

　　（1）測試人員指著測試對象原理圖中的一個模塊問道：“如果這個功能失效，會發生什么現象？”

　　（2）這個功能模塊會不會在不恰當時被調用？

　　（3）測試人員指著原理圖中的某個部分問道：“ 這里有沒有相關的錯誤檢查功能？”

　　（4）測試人員指著原理圖中的某個箭頭問道：“ 該箭頭的具體含義是什么？如果這個箭頭的通路不通，后果是什么？”

　　（5）測試人員指著原理圖中的某個數據流問道：“ 如果這個數據流出現中斷，如何發現這個問題？如果沒有發現這個問題，會出現什么后果？”

　　（6）這個功能能夠處理的大并發用戶數是多少？具體的性能如何？

　　（7）這個功能和其他功能之間是否存在交互？

　　（8）對這個功能沒有把握的部分是什么？從開發人員的角度應該如何測試？

　　上面的場景并不是一個完整的INSIDE-OUT方法，因此測試人員得到的也不是一個完整的問題列表，但是以這種方式開始溝通和交流是測試工作的一個好的開端。在開發人員回答相關問題時，測試人員可以了解開發人員的關注點，以及在哪些地方存在不確定或者猶豫不決。從而可以判斷開發人員在哪些地方可能沒有完全理解需求或者設計要求，而這通常是測試對象的風險所在。在識別風險的過程中，測試人員通常也會考慮如何測試并評估和管理這樣的風險。

　　通常這樣的討論會持續時間在一個小時左右，經過討論測試人員通常能夠更加清楚地了解測試對象。并且對可能的風險有一個初步的印象，從而可以幫助確定后續風險列表和測試策略。

　　INSIDE-OUT方法的優點很明顯，但是該方法的高效應用需要測試人員和開發人員之間具備很強的溝通能力和良好的合作關系。當然測試人員也可以針對測試對象單獨識別風險。不過，這樣會導致測試工作量的增加和效率的降低，因為測試人員需要獨立地學習、理解和分析測試對象。