基于风险的测试，几乎每个测试人员或多或少在测试实践中运用它。对于基于风险的测试设计，测试人员首先需要考虑的就是风险在哪里?即识别和分析测试对象中的风险是进行基于风险的测试设计的前提条件。

　　基于风险的测试设计可以采用的技术包括启发式分析方法、攻击，以及失效模式和影响分析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方法的优点很明显，但是该方法的高效应用需要测试人员和开发人员之间具备很强的沟通能力和良好的合作关系。当然测试人员也可以针对测试对象单独识别风险。不过，这样会导致测试工作量的增加和效率的降低，因为测试人员需要独立地学习、理解和分析测试对象。