码迷,mamicode.com
首页 > 其他好文 > 详细

风险分析

时间:2020-04-11 16:56:15      阅读:89      评论:0      收藏:0      [点我收藏+]

标签:团队合作   条件   情况   回避   问题:   集中   用例   测试用例   超过   

一、风险识别清单

1、、需求

  • 产品的业务需求、用户需求、功能需求和系统需求是否完整、清晰?
  • 开发人员在产品开发设计之前是否充分了解需求?

2、设计

    (1) 是否使用了“新技术”?

  (2)系统中是否会存在一些设计“瓶颈”?如果存在,是否有应对措施?

  (3)产品是否设计得过于复杂,难以理解?

  (4)开发人员是否能够讲清楚产品设计?

  (5)开发人员对异常、非功能方面的内容是否考虑得足够全面?

  (6)开发人员在设计中是否存在一些比较担心的地方?

  (7)开发人员是否会考虑和设计一些可测试性或者易于定位的功能?

  (8)对一个需要多人(或多组)才能配合完成的功能,是否有人会进行整体的设计、协调和把关?

  (9)对有依赖或结束的内容,是否有充分考虑?

 

3、流程

  (1)项目是否使用了新的流程、开发方法等?

  (2)开发人员是否会进行自测?是如何进行自测的?测试的深度和发现问题的情况如何?

  (3)开发人员如何进行代码修改,是如何保证修改的正确性的?

  (4)开发人员是如何进行版本管理的?

 

4、变更

  (1)新版本在旧功能方面做了哪些修改?修改后的主要影响是什么?

  (2)在项目过程中,需求是否总是在变更?

 

5、组织和人

  (1)哪些模块是由其他组织开发的?他们在哪里开发?开发流程、能力如何?

  (2)产品的研发团队(包括需求、开发和测试)是否在于不同的地方?彼此分工如何?沟通是否顺畅?

  (3)团队人员能力如何?经验如何(包括需求、开发和测试团队)?

  (4)团队是否稳定(包括需求、开发和测试团队)?

  (5)团队人手是否充足(包括需求、开发和测试团队)?

  (6)团队环境是否具备(包括必备的工具、硬件设备)?

 

6、历史

  (1)哪些特性在产品测试时就存在有很多bug?

  (2)哪些特性存在较多的客户反馈问题?

  (3)历史上上哪些情况曾经导致过阻塞测试活动的问题?

 

 

二、风险评估

  风险评估的目的:确定风险优先级

1、  风险优先级正交表

  根据风险发生频率和风险影响程度,“高”“中”“低”相互交错来判断

 

2、需求类的风险

  • 需求的质量不高,不足以支撑后续开发和测试
  • 开发和测试未能正确理解需求

   需求类的风险,对设计、开发、测试的影响较大,因此风险的影响程度和风险发生频率设置为“高”,重点关注

 

3、设计类风险

  设计类的风险主要集中在设计的正确性和全面性上,这些风险一旦成了问题,就是产品缺陷。对于这些由风险引起的缺陷,评估一下:

  (1)测试容易发现这些缺陷吗?

  (2)开发修复这些缺陷的改动大吗?影响的功能模块多吗?

  (3)测试容易验证这个缺陷吗?回归测试的工作量大吗?

  (4)如果这个缺陷逃逸到了用户处,对用户的影响大吗? 

  一般来说,对于测试难于发现的缺陷,风险的影响程度更高;基础的、底层的、共用的设计,风险的影响程度更高;需要特殊测试工具或复杂测试环境才能验证的,风险的影响程度更高;在用户处发生概率高、会对用户的业务造成更严重影响的问题,风险的影响程度更高。

 

4、流程类的风险

  从风险影响程度来说,会影响团队合作,或是涉及规范性方面的风险,风险影响程度更高,建议至少为中级

 

5、历史类的风险

  历史上曾经发生过的问题,再次成为问题的风险依然很大。所以建议风险发生的概率应该总是高的

 

三、风险应对

  1、回避风险:指主动避开损失发生的可能性。

  2、转移风险:指通过某种安排,将自己面临的风险全部或部分转义给其他一方。

  3、减轻风险:指采取预防措施,已降低损失发生的可能性和影响程度。

  4、接受风险:指自己理性或非理性地主动承担风险。

 

四、常见风险及应对思路

1、需求类的风险

  (1)问题:产品需求在业务场景上描述不够完整、清晰,不能有效指导开发人员和测试人员的工作。

       解答:A、加强对业务场景的评审

          B、加强开发、测试和需求工程师对业务场景的沟通、讨论,保证开发、测试和需求工程师对场景的验收条件的理解是一致的。 

  (2)问题:开发人员在进行产品设计之前并没有充分理解了产品需求,特别是在易用性和性能需求方面

    解答:A、开展开发人员对需求工程师进行需求确认的活动,确保需求理解的一致性;

       B、开发人员需要逐一根据需求编写验收测试用例,确保需求能够被正确实现,无遗漏;

       C、开发人员针对易用性进行低保真、高保真设计,并和需求工程师进行评审确认;

       D、在需求中需要明确产品的性能规格  

       E、测试人员尽早展开和产品性能相关的摸底测试。

2、设计类的风险

  (1)问题:产品使用了新的技术平台

     解答:A、将新平台与旧平台进行差异化分析,确定变化点

        B、针对变化点进行专项测试

  (2)问题:产品设计得过于复杂,难以理解

    解答:A、和需求工程师进行沟通,确认设计没有超过需求要求的范围;

       B、要求开发人员对设计进行讲解

         C、增加这部分的测试投入

  (3)产品中存在需要多人(或多组)才能配合完成的功能,且缺少这个功能的总体负责人

    解答:A、建议开发增加一位总体责任人,负责确认接口、整体协调等;

         B、

  

风险分析

标签:团队合作   条件   情况   回避   问题:   集中   用例   测试用例   超过   

原文地址:https://www.cnblogs.com/syw20170419/p/12680847.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!