zoukankan      html  css  js  c++  java
  • 测试风险管理

    参考:

    浅谈实施软件测试风险分析

    如何控制软件测试风险

    测试风险的管理

    测试风险分类

    1)技术风险

    软件项目采用的开发技术与开发平台是测试项目风险的重要来源之一。

    2)管理风险

    测试项目管理风险包括测试项目执行过程的各方面,如测试项目计划的时间、资源分配(包括人员、设备、工具)、测试项目的质量管理、测试管理流程、规范、工具的采用一级测试外包商的管理等。

    主要风险

    1)质量需求或产品的特性理解不准确,造成测试范围分析的误差,结果某些地方始终测试不到或验证的标准不对;

    2)测试用例没有得到百分之百的执行,如有些测试用例被有意或无意的遗漏;

    3)需求的临时/突然变化,导致设计的修改和代码的重写,测试时间不够;

    4)质量标准不都是很清晰的,如适用性的测试,仁者见仁、智者见智;

    5)测试用例设计不到位,忽视了一些边界条件、深层次的逻辑、用户场景等;

    6)测试环境,一般不可能和实际运行环境完全一致,造成测试结果的误差;

    7)有些缺陷出现频率不是百分之百,不容易被发现;如果代码质量差,软件缺陷很多,被漏检的缺陷可能性就大;

    8)回归测试一般不运行全部测试用例,是有选择性的执行,必然带来风险。

    常见的测试风险:按照风险内容分类

    1)测试时间进度风险:用户需求发生重大变更或设计计划的大幅调整压缩了测试时间,测试人员、测试环境、测试资源的不能准时到位也会对测试计划造成影响。

    2)测试质量目标风险:测试的质量目标不清晰,如易用性测试、用户文档的测试目标存在见仁见智的问题。

    3)测试范围认知风险:对产品质量需求或产品特性理解不准确,造成测试范围分析误差,出现测试盲区或验证标准错误。还有就是回归测试时,一般不允许全部测试用例,是有选择性的执行,必然带来风险。

    4)测试人员风险:测试开始后,测试人员、技术支持人员因故不能及时到位。

    5)测试充分性风险:部分测试用例设计时忽视了边界条件和深层次的逻辑关系;部分测试用例被测试人员有意无意的忽略执行。

    6)测试环境风险:测试环境无法与生产环境一致,致使性能测试的结果存在误差。

    7)测试工具风险:能否及时准备相关测试工具,测试人员对新工具无法熟练运用等情况也时有发生等。

    测试风险分类:按照TQM进行分类

    软件测试风险鱼骨图

    人,即测试人员:

    • 业务不熟:测试人员对被测系统的业务流程不熟悉,体现在对需求的理解上把握不准、理解不透侧、理解错误等。
    • 测试人员变动:离职,岗位调动,请假等。
    • 定位效应:测试过的可靠的功能,特别是在多次回归且没有发现问题,在此后往往会认为此功能是可靠的。
    • 疲态:某一些功能点一直由某一位测试人员测试,经过多次回归后,测试人员对该功能点的测试显示出倦意和缺乏兴趣。
    • 同化效应:经过和开发的长时间接触,往往会被开发的思维逻辑所同化,渐渐丧失从用户角度出发的测试观察点。

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

    • Spec (详细规格说明书)缺失:只有PRD(项目需求概要说明书),没有spec。笔者所在的公司,早些时候的产品更多的时候只有PRD,没有Spec。
    • 需求变更:这是最不想,但又最经常发生的事情
    • 测试用例/数据设计不充分:某些时候由于编写测试人员的个人因素或时间的限制等方面因素导致。
    • 质量标准不统一:如某些Bug的优先级方面,测试和开发的认同不一致。

    ,即测试方法和实施:

    • 错误或缺失测试方法:对功能点没有采用正确的测试方法,或某些测试方法没有被忽视,如边界测试等,导致测试不充分。
    • 场景的缺失或部分缺失:Spec非常详细,所有的精力放在功能点的测试上,忽视了业务场景(Spec中无定义)的全(100%)测试。
    • 测试用例实施不充分:测试用例由于各种原因没有完全测试,如在回归测试中。

    ,即测试环境:

    • 被测软件版本不统一:没有有效的配置管理,这种情况及易出现
    • 测试软件环境不一致:测试员之间或和开发之间的操作系统类型不一致、操作系统的干净程度不一致。
    • 测试硬件环境不一致:测试员之间或和开发的设备不一致,如CPU频率,内存大小等。
    • 测试硬件未及时到位

    ,即测试时间:

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

    风险应对

    为了避免、转移或降低风险,要事先做好针对不同情况的应对策略。

    风险预防:

    首先,在做测试计划时,对资源、时间、成本等估计要留有余地,避免风险发生时没有相应的资源及时支持应急方案。

    其次,测试开始前,对测试环境、测试工具等难以控制的因素进行检查,将这些因素纳入风险管理计划中。

    第三,通过培训提高测试人员的综合素质,降低由于质量目标不明确、项目背景不熟悉、测试技术及工具不能熟练掌握导致的测试风险。关键技术岗位要培养后备人员。

    第四,对所有过程做好日常跟踪,并进行完善的文档管理。

    第五,对所有工作多进行互相审查,及时发现问题,包括对不同的测试人员在不同的测试模块上相互调换。

    对于已经发生的风险,控制措施:

    image

  • 相关阅读:
    双系统安装,引导被覆盖-如何解决?
    关于apue.3e中apue.h的使用
    UML类图关系
    设计模式的原则
    插入排序Insertion Sort
    Xcode intellisense meaning of letters in colored boxes like f,T,C,M,P,C,K,# etc
    asp.net mvc 页面内容呈现Html.Raw HtmlString
    sqlserver通过设计器修改表结构保存时提示:保存到文本问题
    在windows下使用Cygwin模拟unix环境,并安装apt-cyg,svn等工具
    vs2015插件推荐 Productivity Power Tools 2015
  • 原文地址:https://www.cnblogs.com/miniren/p/6046588.html
Copyright © 2011-2022 走看看