【csdn转】系统软件测试：风险分析

zealzpc

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

我们知道，完全测试一个软件是不可能也是不现实的，因为受到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) 如果是对旧功能的改写，那么改写几行代码的可能比大量改写失败可能性大，因为回归测试往往不充分