太多的历史悲剧告示我们风险无处不在，不学会控制它,就一定会被它所控制。软件中的风险小到可以影响你不能访问一个网页，大到可以让宇宙飞船失事。所以我们一定要注重控制软件中的风险。

        我们知道，完全测试一个软件是不可能也是不现实的，因为受到Cost，Schedule，Resource的影响。入下图所示，测试的时候的测试用例只可能是所有测试用例的一小部分。

        我们应该要根据Schedule，将Resource和cost合理的分配到一个软件系统中优先级最高，最关键，最需要被测试的地方去。而这个前提就是对软件系统或者软件项目做风险分析。

        作者告诉了我们两种风险的分类：

1．  软件风险

        这种风险分析主要是确定软件中要测试什么，测试的优先级，测试的深度

2．  规划风险

        这种风险主要是为了防范未计划的影响项目进度的事件的发生。比如测试人员突然离开导致人员不足、软件的需求的突然变更。

        好，首先来看看软件风险。作者提到了参与软件风险分析的人是来自各个领域的专家。项目经理，开发者，测试者，用户，界面设计者都需要来共同分析软件的风险。而且软件的风险分析要在项目的周期一开始就开始进行，因为风险越迟发现越会影响项目的成功。作者接着给出了软件风险分析的10个步骤，这个流程化的步骤相当好用，我在项目中运用中发现越是大的项目越是能受益于这种分析。不论开发人员、测试人员都能够明确系统中什么是最重要的。下面简要介绍一下：

1．  组建一个“头脑风暴”小组

        这个头脑风暴小组是由项目经理，开发者，测试者，用户，界面设计者等各个方面的专家组成。在我所经历的项目中，通常是由Program manager, Testers, Developers来进行讨论。当然比较有经验的比如Test Lead和Developer Lead会参与其中，利用经验发现一些潜在可能存在的风险。

2．  列出软件中的所有功能列表

        头脑风暴小组应该需要在讨论之前，拿到相应的文档比如需求文档，功能设计文档等。而且一开始可以是对大的方面进行分类，不需要过于细化，慢慢的随着讨论的深入才进行细化。

        举书中的ATM机器的例子，比如一开始可以分成

a)       功能性

a.1) 取钱

a.2) 存钱

a.3) 查余额

a.4) 转帐

a.5) 自动还款

b)      性能

c)      安全性

d)      可用性

3．  确定某个功能失败的可能性

        这个部分非常关键，就是要确定软件中的那个特性最可能导致失败。这个其实是客观和主观的因素同时才能决定的，可以从下面几方面来判断：

a)       功能对系统其它功能或者组件的依赖程度，依赖程度很高的话，失败可能性就高

b)      功能本身的复杂度

c)      功能的实现和设计者的经验，如果这个team是年轻和没有太多经验的，那么失败可能性就高

d)      如果用的是新技术或者实践，可能失败可能性高

e)       如果是旧的功能的改写，那么如果过去它Bug比较多，也是失败可能性较大的。

f)       如果是对旧功能的改写，那么改写几行代码的可能比大量改写失败可能性大，因为回归测试往往不充分

        回到书中的例子，