|
|
知识路径： > 软件评测知识 > 软件测试过程模型 > 软件测试过程与管理 >
|
被考次数：2次
被考频率：低频率
总体答错率：41%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
考试要求：掌握
相关知识点：84个
|
|
|
|
|
|
|
软件公司的管理者制定整体软件开发战略时使用“计划—执行—检查—改进（PDCA）”循环理念，战略性的策略可以转为商业上的主动。在PDCA循环中，计划（plan）和执行（do）往往更被人们所重视，然而，检测（check）部分才是用来处理商业风险的关键过程。
|
|
|
|
软件测试是一种用来尽可能降低软件风险的控制措施。软件测试是检测软件开发是否符合计划，是否达到预期的结果的测试。如果检测（check）表明软件的实现没有按照计划执行或与预期目标不符，就要采取必要的改进行动（active）。因此，公司的管理者应该依靠软件测试之类的控制措施来帮助自己实现商业目标。
|
|
|
|
软件测试人员必须明白他们的任务之一就是通过测试来评估产品的商业风险，并将结果报告给公司管理者。从这个角度看来，测试人员首先要理解什么是商业风险，并且要以这些风险为重点来制定测试策略。
|
|
|
|
|
|
风险的定义为“伤害、损坏或损失的可能性；一种危险的可能或一种冒险事件。”风险涉及到一个事件发生的可能性，涉及到该事件产生的不良后果或影响。软件风险是指开发不成功引起损失的可能性，这种不成功事件会导致公司商业上的失败。
|
|
|
|
软件测试中的风险分析是根据预测软件将出现的风险，制定软件测试计划并排列优先等级。风险分析是对软件中潜在的问题进行识别、估计和评价的过程。
|
|
|
|
软件风险分析的目的是确定测试对象、测试优先级以及测试的深度。有时还包括确定可以忽略的测试对象。通过风险分析，测试人员识别软件中高风险的部分并进行严格彻底的测试；确定潜在的隐患软件构件，对其进行重点测试。在制定测试计划的过程中，可以将风险分析的结果用来确定软件测试的优先级与测试深度。
|
|
|
|
软件风险分析工作应由各部门的专家组成，一般包括：项目经理、开发人员、测试人员、用户、客户以及销售人员。
|
|
|
|
对所有的软件项目进行风险分析将是必不可少的。如果软件本身的缺陷与错误能够导致灾难性后果，如造成严重的经济损失或生命危害，这样的软件称为安全性重要软件，安全性重要软件在开发过程中的各个阶段都应进行安全性分析。
|
|
|
|
即使是非重要软件，在项目的初期进行风险分析，也有助于识别潜在的问题。这些问题可能会引发严重的后果，因此项目经理和开发人员在开发中要特别注意，以便预防风险。
|
|
|
|
测试人员可利用风险分析的结果选择最关键的测试，大部分的测试资源应该用在控制最高级别的商业风险上，而最低级别的商业风险应该占用尽可能少的测试资源。只有这样，软件测试人员才能制定合理的策略，控制软件开发的风险。
|
|
|
|
|
|
风险分析是一个对潜在问题识别和评估的过程，即对测试的对象进行优先级划分。风险分析包括两个部分：
|
|
|
|
|
|
|
|
风险分析由以下几个步骤组成：首先列出潜在问题，然后对标识的每个潜在问题发生的可能性和影响严重性赋值，进行风险测定。测试人员根据测试分析结果的排列，关注潜在问题，设计与选择测试用例。
|
|
|
|
通常风险分析采用两种方法：表格分析法和矩阵分析法。通用的风险分析表包括以下几项内容。
|
|
|
|
①风险标识（ID）——表示风险事件的惟一标识。②风险问题——问题发生现象的简要描述。
|
|
|
|
③发生的可能性——可能性值从1（低）~10（高）。
|
|
|
|
④影响的严重性——严重性值从1（低）~10（高）。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
可能性与严重性的乘积产生的风险预测值，决定了风险优先级的排序。预测值越高，优先级别越高，针对该问题的测试就越重要。根据表4-1的计算结果风险问题的排列为B、A、D、C、E。在风险计算过程中，可能出现具有相同预测值的情况，有的测试机构可以通过将可能性和严重性分别加权计算来进行进一步的分析。
|
|
|
|
本书风险分析的可能性值和严重性值的范围推荐使用从1~10，有些机构可能使用值的范围为1~100，或0~1之间的小数，也有的机构使用高、中、低三个等级来表示。至于使用哪种等级表示并不是很重要，只要这些值在分析过程中的使用是一致的，分析的效果都是一样的。
|
|
|
|
风险矩阵是风险分析的另一种有效的方法，测试人员可根据需要对风险潜在问题的可能性和严重性采用高（1）、中（2）、低（3）三个等级来表示，形成一个二维风险矩阵，而风险优先级可用二者值之和表示。这样，可能存在五个风险等级（即6、5、4、3、2，如下图所示）。
|
|
|
|
总之，风险优先级是由软件潜在问题影响的严重性确定的，是个相对值，而潜在问题的影响严重性是根据问题的可能性来评定的。
|
|
|
|
如下图中的风险优先级的确定是使用可能性和严重性等级值相加，但是如果使用两者值相乘，将会扩大有风险的区域。
|
|
|
|
|
|
|
|
综上所述，软件风险分析的目的是：确定测试对象、确定优先级，以及测试深度。在测试计划阶段，可以用风险分析的结果来确定软件测试的优先级。对每个测试项和测试用例赋予优先级代码，将测试分为高、中和低的优先级类型，这样可以在有限的资源和时间条件下，合理安排测试的覆盖度与深度。
|
|
|
|
|
|
软件测试的风险是指软件测试过程出现的或潜在的问题，造成的原因主要是测试计划的不充分、测试方法有误或测试过程的偏离，造成测试的补充以及结果不准确。测试的不成功导致软件交付潜藏着问题，一旦在运行时爆发，会带来很大的商业风险。
|
|
|
|
美国IEEE 829-1998《软件测试文档编制》标准中，在测试计划的模板中有一项为“风险与应急措施”。这表明软件测试风险管理是很重要的工作。主要是对测试计划执行的风险分析与制定要采取应急措施，降低软件测试产生的风险造成的危害。
|
|
|
|
测试计划的风险一般指测试进度滞后或出现非计划事件，就是针对计划好的测试工作造成消极影响的所有因素，对于计划风险分析的工作是制定计划风险发生时应采取的应急措施。一些常见的计划风险包括：交付日期、测试需求、测试范围、测试资源、人员的能力、测试预算、测试环境、测试支持、劣质组件、测试工具。
|
|
|
|
其中，交付日期的风险是主要风险之一。测试未按计划完成，发布日期推迟，影响对客户提交产品的承诺，管理的可信度和公司的信誉都要受到考验，同时也受到竞争对手的威胁。交付日期的滞后，也可能是已经耗尽了所有的资源。计划风险分析所做的工作重点不在于分析风险产生的原因，重点应放在提前制定应急措施来应对风险发生。当测试计划风险发生时，可能采用的应急措施有：缩小范围、增加资源、减少过程等措施。
|
|
|
|
比如，用户在软件开发接近尾声时，提出重要需求变动。
|
|
|
|
. 应急措施1：增加资源。请求用户团队为测试工作提供更多的用户支持。
|
|
|
|
. 应急措施2：缩小范围。决定在进行后续发布中实现较低优先级的特性。
|
|
|
|
. 应急措施3：减少质量过程。在风险分析过程中确定某些风险级别低的特征测试或少测试。
|
|
|
|
上述列举的应急措施要涉及到有关方面的妥协：如果没有测试计划风险分析和应急措施处理风险，开发者和测试人员采取的措施比较匆忙，将不利于将风险的损失控制到最小。因此，软件风险分析和测试计划风险分析与应急措施是相辅相成的。综上所述，计划风险、软件风险、重点测试、不测试，甚至整个软件的测试与应急措施都是围绕“用风险来确定测试工作优先级”这样的原则来构造的。
|
|
|
