在开发新的软件系统过程中，由于存在许多不确定因素，软件开发失败的风险是客观存在的。因此，风险分析对于软件项目管理是决定性的。风险分析实际上就是贯穿在软件工程过程中的一系列风险管理步骤，其中包括：风险识别、风险估计、风险管理策略、风险解决和风险监督等。
要理解风险分析，我们首先要理解‘风险’这个名词。用汉语的逻辑去对这个词做一个通俗性解释，可以这么展开：风险=“一个不好的事情可能会发生”。这里要注意这句话里的两个要素：一是“可能”，即这是一种可能性的预测，他不是真实已经发生的或者100%一定发生了的事；二是“不好的事”，站在软件产品质量的角度而言，就是质量的一个瑕疵、问题。
那么总结一下，对于软件产品而言，产品的风险就是软件产品可能会有质量问题的情况（更直白一点就是，产品可能会有缺陷）。
我们引用ISTQB对于产品风险定义：
在软件或系统中的潜在失效部分（即将来可能发生不利事件或危险）称之为产品风险，因为它们对产品质量而言是一个风险，包括：
故障频发的软件交付使用；
软件/硬件对个人或公司造成潜在损害的可能性；
劣质的软件特性（比如功能性、可靠性、易用性和性能等） ；
低劣的数据完整性和质量（例如：数据迁移问题、数据转换问题、数据传输问题、违反数 据标准问题）；
软件没有实现既定的功能。
那么为什么我们研发的软件产品会有风险存在呢？其实问这个问题就等同于问’为什么软件产品可能会有缺陷呢‘？其实这个问题的本质就在于’人都是会犯错误的‘这样一个论断的成立。基于这个论断我们又可以推论出：’因为人都会犯错误，所以人开发出来的软件也就可能带有错误‘。这些在研发过程中我们犯的错误，遗留在产品中，就是缺陷；缺陷存在的可能性，就是产品风险。
我们还可以更具体的去讨论，哪些因素，可能导致我们研发软件时更容易在产品中遗留错误：
① 产品大小/代码量：工作量越大，那么我们就越有可能犯错。
② 技术因素：未曾使用过的新技术都存在风险。包括未使用过的新型硬件、支持软件，缺乏标准与规范的非传统的开发方法等。技术过时也是风险。技术风险一般难于改正。
③ 开发环境：适用的开发工具不足、不可靠、使用不方便等因素，都会降低开发效率。
④ 组织规模和人员经验：比如人手不足，人员经验不丰富，都有可能带来产品风险。
⑤ 客户因素：表现在客户需求经常矛盾，不了解客户的特殊需要，客户不了解项目中采用的新技术，且双方又难于沟通等。
所以，既然软件产品的风险是客观存在的，我们就要采取必要手段对风险进行处理，于是就引出了我们今天的课题，’风险分析‘。
首先描述一下风险分析的步骤，一般而言我们可以认为风险分析包括以下部分内容：
风险识别 想要控制风险，我们首先要知道有哪些风险，不然谈何控制？
风险评估 知道了有哪些风险，其次我们要判断风险有多大，有多严重
风险缓解 知道了风险有哪些和他的严重程度，我们就要想办法去缓解和规避风险
风险管理 最后我们要对风险进行管理，达到风控的目标
理论说了这么多，下面用一个简单的实际例子来诠释风险分析的过程。
我还是拿上一篇《实例！软件缺陷数据度量和分析》中的COTS项目为例，这个项目情况是这样的：
该项目为一个COTS产品的定制性二次开发项目
项目周期计划为4个月，实际完成时间为6个月
项目是一个总体人员不到10人的小型项目
采用持续集成，高速迭代的研发方式
第一步：列出软件的所有功能和特性
根据项目相关人员对本项目的调研，我们列出了以下的软件功能模块和特性：
所有主功能：订单支付模块、用户管理模块、后台管理模块、浏览展示模块、用户评价子系统、活动模块、促销管理模块
质量专项问题：功能性问题、性能问题、界面问题、易用性问题、安全性问题、计算错误、描述错误
用表格来展示就是这样的：
所有我们列出来的这些条目，就是所谓的“风险项目”。
那么风险识别这件事，在项目里应该由谁来做呢？一般情况下，风险分析的过程除了有专家的参与，更是一种集体智慧的体现，也就是说项目所有利益相关方，都应该参与到风险分析的过程中。在风险识别这个动作上，头脑风暴是一种可行的方法（即与会各方各抒己见，提出自己认为产品可能有的风险项）。
第二步：对每个风险项目做出风险等级评估
在风险评估过程中，我们要对上个阶段列出的风险项目做出评估，得出风险高低大小的一个排序。
这里我们要考虑风险的两个维度：风险发生的可能性大小，以及风险如果发生，带来的影响范围和严重程度有多大。
我们首先用定性的方法对风险进行评估，采用风险评估矩阵来指导我们的评估过程：
我们将前一阶段得出的风险项目列表进行两个维度的风险判断，得出如下结果：每一个风险项我们都从两个维度给他’高、中、低‘的判断：
那么这个填表过程是由谁来执行呢？答案仍然是集体智慧。风险评估会议要求各项目利益相关方参与，项目团队的成员，包括客户（如果可能的话）每个个体都可能在评估过程中表达自己在某一方面最权威的意见。打个比方说，上面表单里的’订单支付模块‘的影响范围，最适合对他进行评估的可能就是：客户、需求人员和测试工程师；而对于’后台管理系统‘的风险概率，最适合对他进行评估的可能是：开发组长或者对应的开发人员，以此类推。
得到这个评估表，我们使用先前的风险评估矩阵对他进行排序和整理，就得出以下结果：
进一步：
到此为止我们就完成了定性风险评估的过程。
不过这种定性分析还没有能够很细致的展示各风险项之间更细节的风险等级，比如上图标注红色，风险等级为高的三个项目，他们之间的排序我们并不能确定。
所以我们可以改为采用更为细致的一种定量分析，比如我们把’高、中、低‘这样的指标转换为’3，2，1‘这样的得分系统，可以得出如下结果：
可以看到，通过得分相加（采用发生概率和影响范围两个指标相乘是一种更合理的做法）这样的形式，我们得出了更为细致的风险等级划分。
实际上我们还可以更进一步细化，比如对于所有风险项的发生概率，我们可以结合其产生原因进行去量化分析：
对于风险的影响范围，我们从相关风险的使用频率和问题的严重程度去进行量化：
这样再从两个维度去对这个表格做一个运算，不管是用相加还是相乘的策略，我们就能得出更准确的一个风险排序。
当然风险评估除了矩阵法，还有一些其他的方法我们就不一一阐述了。
第三步：定义风险缓解措施
既然我们已经得到风险由高到底的一个风险结果，那么我们就要实施一些措施，对这些风险进行规避和缓解。
这里我们可以有很多种思路：比如将更有经验的开发人员投入到风险高的领域里面去，或者向风险高的领域投入更多的人手，等等。
还有就是：进行基于风险的测试。
实际上，软件测试活动，本身就可以被认为是一种风险控制措施。试想一下，我们测试团队，对于一个软件进行测试，发现了缺陷进行汇报，并督促开发团队去修复和解决问题。这是不是已经直观的降低了产品的风险？这个论断显然是成立的。而测试活动通过其反馈作用，去达到过程改进的效果，也可以更进一步的帮助项目去规避风险。
那么基于风险的测试应该怎么去组织呢？我们就是用风险分析的结果报告，去指导我们测试的开展，具体而言可以有如下措施：
- 基于风险确定测试优先级
- 基于风险确定测试完备性
- 基于风险确定测试资源分配
这样的一些措施要基于我们测试的几个基本原则：
1. “测试是不可能穷尽的” - 既然测试不可能穷尽，那么我们就应该优先去测试风险高的部分，把低的部分放到后续去做，如果时间不允许甚至有部分低风险的部分不测。
2. “缺陷具有集群性” - 即所谓的20%的模块有80%的bug，那么我们通过将风险可能性高的部分去准备更完备的测试（比如更多的测试用例覆盖，更多的执行轮次，更多的执行时间）和更有经验的人员，就可以实现软件质量的快速上升。
最后要注意：风险分析不是一个一次性的工作，我们要通过在项目实际研发过程中得到的信息和反馈，对风险等级进行调整，比如调高和调低风险等级。一个实际的例子是：我们在项目开始时，将某一个风险项目定为了高级，因此这个风险项引起了团队的重视。而正因为团队对这个风险项目很重视，以至于在后续工作开展过程中，团队投入了更多的资源和力量，导致最终测试阶段可能反而在这个模块里面没有发现太多问题，也即他真正展示出来的风险等级并没有预计的那么高。
所以我们测试活动的产出和收集到的信息要用来对风险评估结果进行持续的反馈和调整更新，并根据调整后的风险等级继续指导测试。风险分析应该是一个贯穿项目研发过程始末的工作。
欢迎来到testingpai.com！
注册 关于