软件测试风险分析

1、什么是风险/span>

• 当人们在做某件工作或从事某项事务时，可能会出现的一些异常情况，一旦这些异常情况发生，将带来一些不好的影响或后果。
• 由于承认了未来存在着不确定性，才会出现风险的概念。对今天一个动作的反应，很可能没有能力知道未来会发生什么。风险意味着特定的行为有着多个可能结果。

2、什么是软件风险

• 是指软件开发过程中及软件产品本身可能造成的伤害或损失.
• 分析工作：项目经理、开发人员、测试人员、用户、客户以及销售人员。
• 目的：确定测试对象、确定优先级，以及测试深度。

3、识别软件风险

• 产品规模-与要建造或要修改的软件的总体规模相关的风险.
• 商业影响-与管理或市场所加诸的约束相关的风险.
• 客户特性-与客户的素质,以及开发者和客户定期通信的能力相关的风险.
• 过程定义-与软件过程被定义的程度,以及它们被开发组织所遵守的程度相关的风险.
• 开发环境-与用以建造产品的工具的可用性及质量相关的风险
• 建造的技术-与待开发软件的复杂性以及系统所包含技术的“新奇性”相关的风险
• 人员数目及经验-与参与工作的软件工程师的总体水平及项目经验相关的风险。

4、商业风险

• 商业风险威胁到要开发软件的生存能力。
• 5个主要的商业风险

开发一个没有人真正需要的优秀产品或系统（市场风险） 开发的产吕不再符合公司的整体商业策略（策略风险） 建造了一个销售部门不知道如何去卖的产品（营销风险） 由于重点的转移或人员的变动而失去了高级管理层的支持（管理风险） 没有得到预算或人力上的保证（预算风险） 5、软件测试风险

• 指软件测试过程出现的或潜在的问题，造成的原因主要是测试计划的不充分、测试方法有误或测试过程的偏离，造成测试的补充以及结果不准确。测试的不成功导致软件交付潜藏着问题，一旦在运行时爆发，会带来很大的商业风险。
• 按测试阶段分：测试计划风险比较重要
• 开发过程尚不规范
• 测试逃逸
• 客户发现的问题
• 缺陷解决不彻底
• 没有合理的测试分析
• 测试方法不健全

6、软件测试与商业风险

• PDCA循环——  计划（PLAN）－执行(DO)－检查(CHECK)－改进(ACTIVE)
• 软件测试就是一种降低风险的控制措施。
• 通过CHECK来发现软件是否与预期目标相吻合，如不吻合则采取必要的ACTIVE。所以必须要有类似测试之类的活动。

7、风险分析步骤
发生的可能性－发生问题的可能性有多大 影响严重性－如果问题发生了会有什么后果。 步骤：

•    列出潜在问题标识
•    赋值然后进行测定
•    对结果进行排列
•    选取合适用例

8、风险分析方法

表分析法

• 风险标识－唯一
• 风险问题－简述
• 发生的可能性－（1–10）
• 影响的严重性－（1–10）
• 风险预测值－发生可能性和影响严重性的乘积
• 风险优先级－风险预测值从高到低的排序

矩阵分析法

9、软件测试计划风险

• 指：测试进度滞后或出现非计划事件。
• 常见的计划风险：交付日期、测试需求、测试范围、测试资源、人员的能力、测试预算、测试环境、测试支持、劣质组件、测试工具。
• 交付日期是主要风险之一
• 用风险来确定测试工作的优先等级

10、分析风险因素

• 相关资料的完整性。项目提供的文档是否完备否按照统一的标准编写的档里的信息是否足够试人员是否能够从中获得快速有效的参考。
• 时间安排。项目安排的测试时间是否充足没有准备时间同阶段之间的衔接是否合适现有的测试计划/安排是否冲突/li>
• 团队合作。如果有双方或多方参与测试，各方之间的配合是否默契方对测试项目的流程和标准的理解是否一致方的沟通方式是否恰当……
• 成员对系统/业务熟悉程度。测试人员对被测系统和业务的熟悉程度如何否据此进行足够的分析、设计和测试/li>
• 项目开发计划。软件系统的开发是否能够按计划完成测模块是否能够按计划提交测试/li>
• 配置管理。开发环境、测试环境与生产环境的区别大吗发环境编译的程序是否能够在测试环境和生产环境正常运行统各模块的Build是否正确……
• 需求变更。在项目过程中，系统的需求是否变更果变更，是否及时通知到所有相关团队和人员否需要相应地修改测试需求、测试用例和测试数据……
• 对于该项目的用途而言，哪种功能最重要/li>
• 哪种功能对用户最明显/li>
• 哪种功能对安全影响最大/li>
• 哪种功能对用户最有用/li>
• 对客户来说，该应用软件的哪个部分最重要nbsp;
• 在开发过程中，该应用软件的哪个部分可以最先测试/li>
• 哪一部分代码最复杂，容易导致出现错误/li>
• 哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的/li>
• 哪一部分程序与过去项目中引起问题的部分相类似/有关/li>
• 哪一部分程序与过去项目中需要大量维护的部分相类似/有关/li>
• 需求和设计的那些部分不清楚或不容易读nbsp;
• 开发人员认为在应用软件中哪些部分是高风险的/li>
• 哪些问题能造成最差的发行/li>
• 哪些问题最能引起用户抱怨/li>
• 哪些测试可以容易地覆盖多种功能/li>
• 哪些测试在覆盖高风险部分的测试时使用时间最少nbsp;

来源：测试道