• 风险分析


                       一、风险识别清单

    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、建议开发人员对该功能设计自测用例,并在评审开发自测用例时进行确认;

             C、将该功能作为接收测试用例,避免该功能造成测试阻塞;

    3、流程类风险

      问题:开发自测不充分

      解答:A、和开发人员约定,在本轮版本转测试的时候,需要提供详细的自测报告;

           B、评估开发人员自测用例的质量,必要时提供用例设计指导或直接提供测试用例;

         C、搭建自动化测试环境,供开发人员自测使用

    4、变更类的风险

      问题:项目过程中,需求总是在增加

      解答:A、和开发人员、需求工程师进行沟通,进行需求控制

         B、裁剪部分低优先级的需求

    5、组织和人

      (1)问题:测试团队大部分人员没有测试设计的经验

        解答:A、在进行测试设计之前,找 写的好的测试用例作为例子

           B、增加测试设计的评审检查点,如测试分析、测试标题和测试内容分别进行评审;

             C、必要时,测试架构师对测试工程师进行一对一的辅导

      (2)问题:xxx测试工具不具备,需要购买

         解答:A、定期跟踪工具购买进展;

            B、寻找是否有替代工具。

    6、历史类风险

      (1)问题:xx特性在基线版本中就存在很多bug

        解答:对基线版本该特性的缺陷进行分析,分析哪些测试手段容易发现该特性的问题,据此增加探索式测试

      (2)基线版本中,开发人员修改引入缺陷导致缺陷趋势无法收敛,对测试进度和产品发布造成了影响,在继承性版本中可能存在相同的风险

        解答:对基线版本中开发人员修改引入缺陷的问题进行根因分析,针对根因制定措施

         

      

  • 相关阅读:
    super的使用
    Django--自定义 Command 命令
    Django models
    二柱子的编程 四则运算2
    阅读《梦断代码》计划
    随机数计算小学四则运算
    人月神话有感
    软件演化
    软件测试
    软件实现
  • 原文地址:https://www.cnblogs.com/syw20170419/p/12680847.html
Copyright © 2020-2023  润新知