精华内容
下载资源
问答
  • RPN全称为Risk Priority Number,含义为风险优先级数。 RPN是缺陷的严重程度、发生频率和检测等级三者之积,其值越大表明问题越严重,用来衡量缺陷的级别。 严重程度:定义一个问题对客户的影响。 发生频率:在使用...
  • RPN层解析

    千次阅读 2018-08-10 12:15:37
    所以作者提出RPN,专门用来提取候选框,一方面RPN耗时少,另一方面RPN可以很容易结合到Fast RCNN中,称为一个整体。 RPN的引入,可以说是真正意义上把物体检测整个流程融入到一个神经网络中,这个网络结构叫做...

    原文地址:https://blog.csdn.net/lanran2/article/details/54376126

    RPN全称是Region Proposal Network,Region
    Proposal的中文意思是“区域选取”,也就是“提取候选框”的意思,所以RPN就是用来提取候选框的网络;

    1. RPN的意义

    RPN第一次出现在世人眼中是在Faster RCNN这个结构中,专门用来提取候选框,在RCNN和Fast RCNN等物体检测架构中,用来提取候选框的方法通常是Selective Search,是比较传统的方法,而且比较耗时,在CPU上要2s一张图。所以作者提出RPN,专门用来提取候选框,一方面RPN耗时少,另一方面RPN可以很容易结合到Fast RCNN中,称为一个整体。

    RPN的引入,可以说是真正意义上把物体检测整个流程融入到一个神经网络中,这个网络结构叫做Faster RCNN;
    Faster RCNN = RPN + Fast RCNN
    这里写图片描述
    图1 Faster RCNN的整体结构

    我们不难发现,RPN在整个Faster RCNN中的位置,处于中间部分;

    2. RPN的运作机制

    我们先来看看Faster RCNN原文中的图:
    这里写图片描述
    图2 RPN的结构

    图2展示了RPN的整个过程,一个特征图经过sliding window处理,得到256维特征,然后通过两次全连接得到结果2k个分数和4k个坐标;相信大家一定有很多不懂的地方;我把相关的问题一一列举:

    1. RPN的input 特征图指的是哪个特征图?
    2. 为什么是用sliding window?文中不是说用CNN么?
    3. 256维特征向量如何获得的?
    4. 2k和4k中的k指的是什么?
    5. 图右侧不同形状的矩形和Anchors又是如何得到的?

    首先回答第一个问题,RPN的输入特征图就是图1中Faster RCNN的公共Feature Map,也称共享Feature Map,主要用以RPN和RoI Pooling共享;

    对于第二个问题,我们可以把3x3的sliding window看作是对特征图做了一次3x3的卷积操作,最后得到了一个channel数目是256的特征图,尺寸和公共特征图相同,我们假设是256 x (H x W)

    对于第三个问题,我们可以近似的把这个特征图看作有H x W个向量,每个向量是256维,那么图中的256维指的就是其中一个向量,然后我们要对每个特征向量做两次全连接操作,一个得到2个分数,一个得到4个坐标,由于我们要对每个向量做同样的全连接操作,等同于对整个特征图做两次1 x 1的卷积,得到一个2 x H x W和一个4 x H x W大小的特征图,换句话说,有H x W个结果,每个结果包含2个分数和4个坐标;
    这里写图片描述
    图3 问题1,2,3的解答描述图

    这里我们需要解释一下为何是2个分数,因为RPN是提候选框,还不用判断类别,所以只要求区分是不是物体就行,那么就有两个分数,前景(物体)的分数,和背景的分数;
    我们还需要注意:4个坐标是指针对原图坐标的偏移,首先一定要记住是原图;
    此时读者肯定有疑问,原图哪里来的坐标呢?
    这里我要解答最后两个问题了:
    首先我们知道有H x W个结果,我们随机取一点,它跟原图肯定是有个一一映射关系的,由于原图和特征图大小不同,所以特征图上的一个点对应原图肯定是一个框,然而这个框很小,比如说8 x 8,这里8是指原图和特征图的比例,所以这个并不是我们想要的框,那我们不妨把框的左上角或者框的中心作为锚点(Anchor),然后想象出一堆框,具体多少,聪明的读者肯定已经猜到,K个,这也就是图中所说的K anchor boxes(由锚点产生的K个框);换句话说,H x W个点,每个点对应原图有K个框,那么就有H x W x k个框默默的在原图上,那RPN的结果其实就是判断这些框是不是物体以及他们的偏移;那么K个框到底有多大,长宽比是多少?这里是预先设定好的,共有9种组合,所以k等于9,最后我们的结果是针对这9种组合的,所以有H x W x 9个结果,也就是18个分数和36个坐标;
    这里写图片描述
    图4 问题4,5的解答描述图

    这里宣传一下我的公共号,懒人学AI,欢迎大家关注,共同学习:
    这里写图片描述

    3. RPN的整个流程回顾

    最后我们再把RPN整个流程走一遍,首先通过一系列卷积得到公共特征图,假设他的大小是N x 16 x 16,然后我们进入RPN阶段,首先经过一个3 x 3的卷积,得到一个256 x 16 x 16的特征图,也可以看作16 x 16个256维特征向量,然后经过两次1 x 1的卷积,分别得到一个18 x 16 x 16的特征图,和一个36 x 16 x 16的特征图,也就是16 x 16 x 9个结果,每个结果包含2个分数和4个坐标,再结合预先定义的Anchors,经过后处理,就得到候选框;整个流程如图5:
    这里写图片描述
    图5 RPN整个流程

    展开全文
  • 如果前期风险分析与控制比较充分,那么会使软件的测试成功性大大增加,且可将由风险异常引发的额外成本(如人力,时间等)降到最低。查阅了网上很多关于软件测试风险控制的文章,其中不乏精品之作。本文...

     本文来源于:http://blog.csdn.net/roger_ge/article/details/5343039

     

      作为软件测试计划的一部分,软件测试风险的分析与控制是其中重要的环节。如果前期风险分析与控制比较充分,那么会使软件的测试成功性大大增加,且可将由风险异常引发的额外成本(如人力,时间等)降到最低。查阅了网上很多关于软件测试风险控制的文章,其中不乏精品之作。本文将此类知识进行了归纳,查漏补缺,并在思维导向性上给出了简单的实施步骤,以使得在实际应用中能得到更好的运用。

     

    第一部分:软件测试项目级的风险分析

    1. 从人、料、法、环、时等方面分析测试项目级的风险分布

      探寻测试隐藏的风险时,应招集测试全组成员举行会议, 建议采用头脑风暴和询问5Why的方式进行,以集思广益和深度挖掘。下面就在鱼骨图中以TQM (全面质量管理) 的人、机、料、法、环等五个方面来全方位的分析和罗列项目级可能隐藏的风险 (注:考虑到在软件测试中“机”这一项更多的属于环境这一分类,故删除此类。另外时间对于软件测试是一个非常重要的属性,故添加之)。

              

    下面对鱼骨图中的各个分支及子分支进行相应注解:

    ,即测试人员:

    l   业务不熟:测试人员对被测系统的业务流程不熟悉,体现在对需求的理解上把握不准、理解不透侧、理解错误等。

    l   测试人员变动:离职,岗位调动,请假等。

    l   定位效应:测试过的可靠的功能,特别是在多次回归且没有发现问题,在此后往往会认为此功能是可靠的。

    l   疲态:某一些功能点一直由某一位测试人员测试,经过多次回归后,测试人员对该功能点的测试显示出倦意和缺乏兴趣。

    l   同化效应:经过和开发的长时间接触,往往会被开发的思维逻辑所同化,渐渐丧失从用户角度出发的测试观察点。

     

    ,即测试相关文档(在TQM中指的是生产原材料):

    l   Spec (详细规格说明书)缺失:只有PRD(项目需求概要说明书),没有spec。笔者所在的公司,早些时候的产品更多的时候只有PRD,没有Spec。

    l   需求变更:这是最不想,但又最经常发生的事情

    l   测试用例/数据设计不充分:某些时候由于编写测试人员的个人因素或时间的限制等方面因素导致。

    l   质量标准不统一:如某些Bug的优先级方面,测试和开发的认同不一致。

                   

    ,即测试方法和实施:

    l   错误或缺失测试方法:对功能点没有采用正确的测试方法,或某些测试方法没有被忽视,如边界测试等,导致测试不充分。

    l   场景的缺失或部分缺失:Spec非常详细,所有的精力放在功能点的测试上,忽视了业务场景(Spec中无定义)的全(100%)测试。

    l   测试用例实施不充分:测试用例由于各种原因没有完全测试,如在回归测试中。

     

    ,即测试环境:

    l   被测软件版本不统一:没有有效的配置管理,这种情况及易出现

    l   测试软件环境不一致:测试员之间或和开发之间的操作系统类型不一致、操作系统的干净程度不一致。

    l   测试硬件环境不一致:测试员之间或和开发的设备不一致,如CPU频率,内存大小等。

    l   测试硬件未及时到位

     

    ,即测试时间:

    l   测试时间不足:里程碑之间留给测试的时间无法满足全测试要求。

    l   测试时间延长:由于需求方突然宣布原进度表中的里程碑时间点延后,导致项目的进度表一下松弛了许多。笔者参加过的两个项目就遇见过这种情况,我们为世界某著名品牌电脑供应商开发并提供随机软件。在项目进展到中后期时,客户忽然通知我们暂时不安排我们的软件在他们这一版本系统中进行安装,要等到下一版本,时间延迟可能长达三个月,甚至更多。

     

    注:以上五个方面不可能将所有软件测试中潜在的风险全部罗列,旨在给出思维方式。

                   

    2.          采用FMEA评估及分析风险项

    在采用FMEA对风险进行评估和分析前,有必要先熟悉一些FMEA的知识点。

    l  FMEA (Failure Mode Effects Analysis) :潜在失效模式和结果分析。即找出产品/过程中潜在的故障模式根据相应的评价体系对找出的潜在故障模式进行风险量化评估;列出故障起因/机理,寻找预防或改进措施。

     

    l  FMEA关键项

    ü  Function (功能要求): What is design/process/service supposed to do at this stage?

    ü  Failure Mode (潜在失效模式): A specific means by which a design (product), process, or service may fail.

    ü  Effect (潜在失效后果): What happens when the failure occurs?

    ü  Severity (严重度):  How serious is the consequence of the failure? The value is 1~10.

    ü  Cause (潜在的失效起因): What can occur to cause the failure?

    ü  Occurrence (频度): How often will the cause/failure occur? The value is 1~10.

    ü  Current Control (现行控制):  Current method to detect/prevent transmission of failures to subsequent “customers”.

    ü  Detection (探测度): Can the cause/failure be detected if it occurs? The value is 1~10.

    ü  RPN (风险顺序数): Review Risk Priority Numbers, RPN = (Severity) x (Occurrence) x (Detection)

    ü  Recommended Actions (建议措施): What can we do?

    ü  Responsibility & Target Completion Date (责任及目标完成日期): When it can be fixed?

    ü  Actions Taken Result (措施结果): The actually result after action have been taken.

     

    l  FMEA流程:

     

    本文只给出了简单流程示意图,更详细的流程做法,请参看《FAILURE MODES AND EFFECTS ANALYSIS》Kenneth Crow 中的FMEA Procedure章节。 

    下面给出一个FMEA的简单模板,可以参照下图的表格填写上面人、料、法、环、时五大因素中所提及的各个风险子项填写在Function一列,并按公司的切实情况填写后续各列。

     

     

    第二部分:软件测试用例级的风险分析

    1. 测试用例风险分析的目的

    在进行回归测试等情况下,从所有测试用例集(含功能点和场景测试两部分)中如何选择最小测试用例集,是一个值得思考的问题,本文仅想从测试用例风险系数等级划分来对这一问题进行部分探讨。对所有测试用例进行风险系数等级划分,并按等级数进行排序。在选择回归测试用例集时,从中挑选风险系数等级级别的高的测试用例进行优先测试,最后根据项目进度条件从风险等级高到等级低的合理选择回归测试用例集。

    2.采用风险矩阵评估及分析测试用例优先级 

     

    第三部分:总结与说明

    1.本文没有对项目管理方面的隐藏风险进行探寻,如项目经费成本风险分析等。仅从测试本身考虑了风险分布,角色定位于测试项目Leader,而前者则是PM。

    2.本文的标题定为测试风险分析,所以对于发生风险后所应该采用的规避措施,没有在文中给出,可采用根据公司内容的实际情况采用头脑风暴进行解决方案的探讨和筛选,也可参考网上一些文章所建议的解决方案。

    3.风险分析的方法有很多种,如Boehm的六步风险管理法、Rex Black在《软件测试核心过程》一书中提到的风险分析过程等都是比较优秀的方法,但其精髓和FMEA、风险分析矩阵是如出一辙,个人觉得以表格的形式展示更加形象化。

     

    参考:

    《测试有道 - 微软测试测试技术心得》 梁博,许珊等 电子工业出版社

    《测试风险的管理》http://www.51testing.com/html/90/n-9990.html

    《风险列表》 noone_pm http://bbs.51testing.com/viewthread.php?tid=7105&highlight=%B7%E7%CF%D5

    《软件测试管理常见问题及其回答》songfun  http://bbs.51testing.com/viewthread.php?tid=39181&extra=page%3D1%26amp%3Bfilter%3Ddigest

    展开全文
  • 浅谈实施软件测试风险分析-转载 作为软件测试计划的一部分,软件测试风险的分析与控制是其中重要的环节。如果前期风险分析与控制比较充分,那么会使软件的测试成功性大大增加,且可将由风险异常引发的额外...
     
    

    作为软件测试计划的一部分,软件测试风险的分析与控制是其中重要的环节。如果前期风险分析与控制比较充分,那么会使软件的测试成功性大大增加,且可将由风险异常引发的额外成本(如人力,时间等)降到最低。查阅了网上很多关于软件测试风险控制的文章,其中不乏精品之作。本文将此类知识进行了归纳,查漏补缺,并在思维导向性上给出了简单的实施步骤,以使得在实际应用中能得到更好的运用。

    第一部分:软件测试项目级的风险分析

    1.          从人、料、法、环、时等方面分析测试项目级的风险分布

                    探寻测试隐藏的风险时,应招集测试全组成员举行会议, 建议采用头脑风暴和询问5Why的方式进行,以集思广益和深度挖掘。下面就在鱼骨图中以TQM (全面质量管理) 的人、机、料、法、环等五个方面来全方位的分析和罗列项目级可能隐藏的风险 (注:考虑到在软件测试中“机”这一项更多的属于环境这一分类,故删除此类。另外时间对于软件测试是一个非常重要的属性,故添加之)。

                    软件测试风险鱼骨图

               

                    下面对鱼骨图中的各个分支及子分支进行相应注解:

                    ,即测试人员:

    l   业务不熟:测试人员对被测系统的业务流程不熟悉,体现在对需求的理解上把握不准、理解不透侧、理解错误等。

    l   测试人员变动:离职,岗位调动,请假等。

    l   定位效应:测试过的可靠的功能,特别是在多次回归且没有发现问题,在此后往往会认为此功能是可靠的。

    l   疲态:某一些功能点一直由某一位测试人员测试,经过多次回归后,测试人员对该功能点的测试显示出倦意和缺乏兴趣。

    l   同化效应:经过和开发的长时间接触,往往会被开发的思维逻辑所同化,渐渐丧失从用户角度出发的测试观察点。

     

                    ,即测试相关文档(在TQM中指的是生产原材料):

    l   Spec (详细规格说明书)缺失:只有PRD(项目需求概要说明书),没有spec。笔者所在的公司,早些时候的产品更多的时候只有PRD,没有Spec。

    l   需求变更:这是最不想,但又最经常发生的事情

    l   测试用例/数据设计不充分:某些时候由于编写测试人员的个人因素或时间的限制等方面因素导致。

    l   质量标准不统一:如某些Bug的优先级方面,测试和开发的认同不一致。

                   

                    ,即测试方法和实施:

    l   错误或缺失测试方法:对功能点没有采用正确的测试方法,或某些测试方法没有被忽视,如边界测试等,导致测试不充分。

    l   场景的缺失或部分缺失:Spec非常详细,所有的精力放在功能点的测试上,忽视了业务场景(Spec中无定义)的全(100%)测试。

    l   测试用例实施不充分:测试用例由于各种原因没有完全测试,如在回归测试中。

     

                    ,即测试环境:

    l   被测软件版本不统一:没有有效的配置管理,这种情况及易出现

    l   测试软件环境不一致:测试员之间或和开发之间的操作系统类型不一致、操作系统的干净程度不一致。

    l   测试硬件环境不一致:测试员之间或和开发的设备不一致,如CPU频率,内存大小等。

    l   测试硬件未及时到位

     

                    ,即测试时间:

    l   测试时间不足:里程碑之间留给测试的时间无法满足全测试要求。

    l   测试时间延长:由于需求方突然宣布原进度表中的里程碑时间点延后,导致项目的进度表一下松弛了许多。笔者参加过的两个项目就遇见过这种情况,我们为世界某著名品牌电脑供应商开发并提供随机软件。在项目进展到中后期时,客户忽然通知我们暂时不安排我们的软件在他们这一版本系统中进行安装,要等到下一版本,时间延迟可能长达三个月,甚至更多。

     

    注:以上五个方面不可能将所有软件测试中潜在的风险全部罗列,旨在给出思维方式。

                   

    2.          采用FMEA评估及分析风险项

    在采用FMEA对风险进行评估和分析前,有必要先熟悉一些FMEA的知识点。

    l  FMEA (Failure Mode Effects Analysis) :潜在失效模式和结果分析。即找出产品/过程中潜在的故障模式根据相应的评价体系对找出的潜在故障模式进行风险量化评估;列出故障起因/机理,寻找预防或改进措施。

     

    l  FMEA关键项

    ü  Function (功能要求): What is design/process/service supposed to do at this stage?

    ü  Failure Mode (潜在失效模式): A specific means by which a design (product), process, or service may fail.

    ü  Effect (潜在失效后果): What happens when the failure occurs?

    ü  Severity (严重度):  How serious is the consequence of the failure? The value is 1~10.

    ü  Cause (潜在的失效起因): What can occur to cause the failure?

    ü  Occurrence (频度): How often will the cause/failure occur? The value is 1~10.

    ü  Current Control (现行控制):  Current method to detect/prevent transmission of failures to subsequent “customers”.

    ü  Detection (探测度): Can the cause/failure be detected if it occurs? The value is 1~10.

    ü  RPN (风险顺序数): Review Risk Priority Numbers, RPN = (Severity) x (Occurrence) x (Detection)

    ü  Recommended Actions (建议措施): What can we do?

    ü  Responsibility & Target Completion Date (责任及目标完成日期): When it can be fixed?

    ü  Actions Taken Result (措施结果): The actually result after action have been taken.

     

    l  FMEA流程:

    FMEA实施流程

     

    本文只给出了简单流程示意图,更详细的流程做法,请参看《FAILURE MODES AND EFFECTS ANALYSIS》Kenneth Crow 中的FMEA Procedure章节。

     

    下面给出一个FMEA的简单模板,可以参照下图的表格填写上面人、料、法、环、时五大因素中所提及的各个风险子项填写在Function一列,并按公司的切实情况填写后续各列。

    FMEA表格模板

     

     

     

    第二部分:软件测试用例级的风险分析

    1.        测试用例风险分析的目的

    在进行回归测试等情况下,从所有测试用例集(含功能点和场景测试两部分)中如何选择最小测试用例集,是一个值得思考的问题,本文仅想从测试用例风险系数等级划分来对这一问题进行部分探讨。对所有测试用例进行风险系数等级划分,并按等级数进行排序。在选择回归测试用例集时,从中挑选风险系数等级级别的高的测试用例进行优先测试,最后根据项目进度条件从风险等级高到等级低的合理选择回归测试用例集。

    2.        采用风险矩阵评估及分析测试用例优先级

     

    测试用例

    风险

    出现概率(1~10)

    后果与影响(1~10)

    风险系数(=出现概率x影响)

    规避措施

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    第三部分:总结与说明

    1.          本文没有对项目管理方面的隐藏风险进行探寻,如项目经费成本风险分析等。仅从测试本身考虑了风险分布,角色定位于测试项目Leader,而前者则是PM。

    2.          本文的标题定为测试风险分析,所以对于发生风险后所应该采用的规避措施,没有在文中给出,可采用根据公司内容的实际情况采用头脑风暴进行解决方案的探讨和筛选,也可参考网上一些文章所建议的解决方案。

    3.          风险分析的方法有很多种,如Boehm的六步风险管理法、Rex Black在《软件测试核心过程》一书中提到的风险分析过程等都是比较优秀的方法,但其精髓和FMEA、风险分析矩阵是如出一辙,个人觉得以表格的形式展示更加形象化。

     

    参考:

    《测试有道 - 微软测试测试技术心得》 梁博,许珊等 电子工业出版社

    《测试风险的管理》http://www.51testing.com/html/90/n-9990.html

    《风险列表》 noone_pm http://bbs.51testing.com/viewthread.php?tid=7105&highlight=%B7%E7%CF%D5

    《软件测试管理常见问题及其回答》songfun  http://bbs.51testing.com/viewthread.PHP?tid=39181&extra=page%3D1%26amp%3Bfilter%3Ddigest

    展开全文
  • 浅谈实施软件测试风险分析

    千次阅读 2010-03-03 17:45:00
    作为软件测试计划的一部分,软件测试风险的分析与控制是其中重要的环节。如果前期风险分析与控制比较充分,那么会使软件的测试成功性大大增加,且可将由风险异常引发的额外成本(如人力,时间等)降到最低。查阅了网上...

                    作为软件测试计划的一部分,软件测试风险的分析与控制是其中重要的环节。如果前期风险分析与控制比较充分,那么会使软件的测试成功性大大增加,且可将由风险异常引发的额外成本(如人力,时间等)降到最低。查阅了网上很多关于软件测试风险控制的文章,其中不乏精品之作。本文将此类知识进行了归纳,查漏补缺,并在思维导向性上给出了简单的实施步骤,以使得在实际应用中能得到更好的运用。

    第一部分:软件测试项目级的风险分析

    1.          从人、料、法、环、时等方面分析测试项目级的风险分布

                    探寻测试隐藏的风险时,应招集测试全组成员举行会议, 建议采用头脑风暴和询问5Why的方式进行,以集思广益和深度挖掘。下面就在鱼骨图中以TQM (全面质量管理) 的人、机、料、法、环等五个方面来全方位的分析和罗列项目级可能隐藏的风险 (注:考虑到在软件测试中“机”这一项更多的属于环境这一分类,故删除此类。另外时间对于软件测试是一个非常重要的属性,故添加之)

                    软件测试风险鱼骨图

               

                    下面对鱼骨图中的各个分支及子分支进行相应注解:

                    ,即测试人员:

    l   业务不熟:测试人员对被测系统的业务流程不熟悉,体现在对需求的理解上把握不准、理解不透侧、理解错误等。

    l   测试人员变动:离职,岗位调动,请假等。

    l   定位效应:测试过的可靠的功能,特别是在多次回归且没有发现问题,在此后往往会认为此功能是可靠的。

    l   疲态:某一些功能点一直由某一位测试人员测试,经过多次回归后,测试人员对该功能点的测试显示出倦意和缺乏兴趣。

    l   同化效应:经过和开发的长时间接触,往往会被开发的思维逻辑所同化,渐渐丧失从用户角度出发的测试观察点。

     

                    ,即测试相关文档(TQM中指的是生产原材料)

    l   Spec (详细规格说明书)缺失:只有PRD(项目需求概要说明书),没有spec。笔者所在的公司,早些时候的产品更多的时候只有PRD,没有Spec

    l   需求变更:这是最不想,但又最经常发生的事情

    l   测试用例/数据设计不充分:某些时候由于编写测试人员的个人因素或时间的限制等方面因素导致。

    l   质量标准不统一:如某些Bug的优先级方面,测试和开发的认同不一致。

                   

                    ,即测试方法和实施:

    l   错误或缺失测试方法:对功能点没有采用正确的测试方法,或某些测试方法没有被忽视,如边界测试等,导致测试不充分。

    l   场景的缺失或部分缺失:Spec非常详细,所有的精力放在功能点的测试上,忽视了业务场景(Spec中无定义)的全(100%)测试。

    l   测试用例实施不充分:测试用例由于各种原因没有完全测试,如在回归测试中。

     

                    ,即测试环境:

    l   被测软件版本不统一:没有有效的配置管理,这种情况及易出现

    l   测试软件环境不一致:测试员之间或和开发之间的操作系统类型不一致、操作系统的干净程度不一致。

    l   测试硬件环境不一致:测试员之间或和开发的设备不一致,如CPU频率,内存大小等。

    l   测试硬件未及时到位

     

                    ,即测试时间:

    l   测试时间不足:里程碑之间留给测试的时间无法满足全测试要求。

    l   测试时间延长:由于需求方突然宣布原进度表中的里程碑时间点延后,导致项目的进度表一下松弛了许多。笔者参加过的两个项目就遇见过这种情况,我们为世界某著名品牌电脑供应商开发并提供随机软件。在项目进展到中后期时,客户忽然通知我们暂时不安排我们的软件在他们这一版本系统中进行安装,要等到下一版本,时间延迟可能长达三个月,甚至更多。

     

    注:以上五个方面不可能将所有软件测试中潜在的风险全部罗列,旨在给出思维方式。

                   

    2.          采用FMEA评估及分析风险项

    在采用FMEA对风险进行评估和分析前,有必要先熟悉一些FMEA的知识点。

    l  FMEA (Failure Mode Effects Analysis) :潜在失效模式和结果分析。即找出产品/过程中潜在的故障模式根据相应的评价体系对找出的潜在故障模式进行风险量化评估;列出故障起因/机理,寻找预防或改进措施。

     

    l  FMEA关键项

    ü  Function (功能要求): What is design/process/service supposed to do at this stage?

    ü  Failure Mode (潜在失效模式): A specific means by which a design (product), process, or service may fail.

    ü  Effect (潜在失效后果): What happens when the failure occurs?

    ü  Severity (严重度):  How serious is the consequence of the failure? The value is 1~10.

    ü  Cause (潜在的失效起因): What can occur to cause the failure?

    ü  Occurrence (频度): How often will the cause/failure occur? The value is 1~10.

    ü  Current Control (现行控制):  Current method to detect/prevent transmission of failures to subsequent “customers”.

    ü  Detection (探测度): Can the cause/failure be detected if it occurs? The value is 1~10.

    ü  RPN (风险顺序数): Review Risk Priority Numbers, RPN = (Severity) x (Occurrence) x (Detection)

    ü  Recommended Actions (建议措施): What can we do?

    ü  Responsibility & Target Completion Date (责任及目标完成日期): When it can be fixed?

    ü  Actions Taken Result (措施结果): The actually result after action have been taken.

     

    l  FMEA流程:

    FMEA实施流程

     

    本文只给出了简单流程示意图,更详细的流程做法,请参看FAILURE MODES AND EFFECTS ANALYSISKenneth Crow 中的FMEA Procedure章节。

     

    下面给出一个FMEA的简单模板,可以参照下图的表格填写上面人、料、法、环、时五大因素中所提及的各个风险子项填写在Function一列,并按公司的切实情况填写后续各列。

    FMEA表格模板

     

     

    第二部分:软件测试用例级的风险分析

    1.        测试用例风险分析的目的

    在进行回归测试等情况下,从所有测试用例集(含功能点和场景测试两部分)中如何选择最小测试用例集,是一个值得思考的问题,本文仅想从测试用例风险系数等级划分来对这一问题进行部分探讨。对所有测试用例进行风险系数等级划分,并按等级数进行排序。在选择回归测试用例集时,从中挑选风险系数等级级别的高的测试用例进行优先测试,最后根据项目进度条件从风险等级高到等级低的合理选择回归测试用例集。

    2.        采用风险矩阵评估及分析测试用例优先级

    测试用例

    风险

    出现概率(1~10)

    后果与影响(1~10)

    风险系数(=出现概率x影响)

    规避措施

     

     

     

     

     

     

     

     

     

     

     

     

     

    第三部分:总结与说明

    1.          本文没有对项目管理方面的隐藏风险进行探寻,如项目经费成本风险分析等。仅从测试本身考虑了风险分布,角色定位于测试项目Leader,而前者则是PM

    2.          本文的标题定为测试风险分析,所以对于发生风险后所应该采用的规避措施,没有在文中给出,可采用根据公司内容的实际情况采用头脑风暴进行解决方案的探讨和筛选,也可参考网上一些文章所建议的解决方案。

    3.          风险分析的方法有很多种,如Boehm的六步风险管理法、Rex Black在《软件测试核心过程》一书中提到的风险分析过程等都是比较优秀的方法,但其精髓和FMEA、风险分析矩阵是如出一辙,个人觉得以表格的形式展示更加形象化。

     

    参考:

    《测试有道 - 微软测试测试技术心得》 梁博,许珊等 电子工业出版社

    《测试风险的管理》http://www.51testing.com/html/90/n-9990.html

    《风险列表》 noone_pm http://bbs.51testing.com/viewthread.php?tid=7105&highlight=%B7%E7%CF%D5

    《软件测试管理常见问题及其回答》songfun  http://bbs.51testing.com/viewthread.php?tid=39181&extra=page%3D1%26amp%3Bfilter%3Ddigest

     

     

     

    展开全文
  • 2013年系统架构师考试题详解

    万次阅读 2017-11-03 14:16:47
    PCI是一种局部总线标准,它是在CPU和原来的系统总线之间插入的一级总线,具体由一个桥接电路实现对这一层的管理,并实现上下之间的接口以协调数据的传送。 JTAG是一个调试接口,用来供幵发人员调试CPU的工作状态...
  • IQ FMEA-失效模式及影响分析

    千次阅读 2020-02-25 16:51:09
    APIS IQ-Software是功能安全,风险分析和管理领域最专业的软件,多年来一直满足全球1000多家公司的最高标准, 主要涉及航空航天、国防、能源、汽车医疗工业等领域。 产品比较——整个APIS系列产品的所有功能概述 第一...
  • 第144期 视觉论文速览 --残差金字塔深度估计 --通道,空间特征提升模块 --感知评价 --动作数据集Kinetics-700 --细粒度食物数据集Foodx-251 --场景文字合成渲染
  • PMP总结

    2012-06-28 01:19:54
    项目:临时性、独特性、渐进明细(滚动式);产品、服务或成果 战略 > 项目组合 > 项目集 > 项目 >...项目管理办公室:常设部门、项目集变更、项目间依赖、方法论、整体风险 ...
  • 举例来说,比起设计定稿后的产品验证/确认,使用已证实的设计标准或最佳实践更加可取。 //这句话在上上章节,也就是叙述预防控制和探测控制的章节已经描述过了。 建议措施的目的在于改进设计。 所以,就作者看来...
  • 深度学习基础知识整理

    千次阅读 2018-07-19 15:43:11
    泛化性能是训练的效果评价中的首要目标,没有良好的泛化,就等于南辕北辙, 一切都是无用功。 实际训练中, 降低过拟合的办法一般如下: 正则化(Regularization) L2正则化:目标函数中增加所有权重w参数的平方之和,...
  • Fast R-CNN 2015 有哪些改进 ROI Pooling 前向传播 反向传播 为什么 RoI Pooling 比 SPP 效果好 Multi-task Loss Smooth L1 相比于 L2 损失, 在回归时有什么优势 SVD 奇异值分解简介 Faster R-CNN 2016 RPN网络 ...
  • DFMEA要点总结

    千次阅读 2019-05-05 13:43:17
    注:建议不要把RPN作为风险评估的首要方法,更不建议使用RPN阈值来决定是否需要采取措施,而需要优先处理严重度更高的项目。   建议: 可以根据下列顺序判断是否需要采取改进措施: 高严重度(9或10) ...
  • BAT机器学习面试1000题系列

    千次阅读 2017-11-30 18:58:18
    BAT机器学习面试1000题系列 整理:July、德伟、立娜、贾茹、王剑、孟莹等众人。本系列大部分题目来源于公开网络,取之分享,用之分享,且在撰写答案过程中若引用他人解析则必注明原作者及来源链接。...
  • 算法面试大全

    万次阅读 2017-11-30 11:36:12
    本文原文链接: ... 整理:七月在线July、德伟、立娜、孟莹、贾茹等众人。本系列大部分题目来源于公开网络,且注明来源链接。 ...说明:本系列自2017年9月28日开始,每周持续更新。首发于七月在线实验室公众号上:...
  • 图像识别 项目一:齿轮表面粗糙度自动检测 开发应用:python3+sklearn+opencv 项目描述:1)使用CCD相机获取齿轮表面图像 2)图片预处理,使用中值滤波,去除图片椒盐噪声,使用直方图均衡化进行图像增强 ...
  • 泛化性能是训练的效果评价中的首要目标,没有良好的泛化,就等于南辕北辙, 一切都是无用功。 过拟合是泛化的反面,好比乡下快活的刘姥姥进了大观园会各种不适应,但受过良好教育的林黛玉进贾府就不会大惊小怪。实际...
  • 机器学习面试

    千次阅读 2020-06-19 22:55:07
    泛化性能是训练的效果评价中的首要目标,没有良好的泛化,就等于南辕北辙, 一切都是无用功。 过拟合是泛化的反面,好比乡下快活的刘姥姥进了大观园会各种不适应,但受过良好教育的林黛玉进贾府就不会大惊小怪。实际...
  • 使用标准ResNext 101 DCN骨干网,我们在很大程度上提高了流行对象探测器的性能,并在54.0 AP下实现了新的现有技术。此外,利用最新的变压器骨干和额外数据,我们可以将当前最好的CoCo结果推动到60.6 AP的新记录。该...
  • 因此,欧氏距离适用于向量各分量的度量标准统一的情况。 曼哈顿距离,我们可以定义曼哈顿距离的正式意义为L1-距离或城市区块距离,也就是在欧几里得空间的固定直角坐标系上两点所形成的线段对轴产生的投影的距离总和...
  • FPN O、M2Det 四、数据集和标准 A、PASCAL VOC dataset 1)、Dataset 2)、Metric B、MS COCO基准 1)、Dataset 2)、Metric C、ImageNet基准 1)、Dataset 2)、Metric D、VisDrone2018基准 E、Open Image V5 1)、Dataset...

空空如也

空空如也

1 2 3
收藏数 42
精华内容 16
热门标签
关键字:

rpn风险等级评价准则