51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 14230|回复: 25

软件测试过程中有哪些风险?(09-04-27)(获奖名单已公布)

[复制链接]

该用户从未签到

发表于 2009-4-27 15:14:53 | 显示全部楼层 |阅读模式
在编写测试计划的时候要考虑可能发生的风险,并提出应对措施。那么到底都有哪些风险要注意呢?如何解决呢?

另外这些风险如何在计划中写明呢,不会写“张三可能要离职”,“开发提交代码可能会延期”吧:)


感谢会员fmsbai5提供此精彩问题!如果你也有问题想提出来和大家一起讨论,请点击此处>>
说不定下期讨论的问题就是由你提出的哦,请快快参与吧!



相关文章:

测试风险的管理

回归的风险

缺乏版本控制测试易陷混乱风险

更多内容请点击>>>


注:把8#、13#、15#的答复结合起来看就比较全面了,其中回答也是本贴相关文章中的摘抄,故不评奖。
回复

使用道具 举报

  • TA的每日心情
    奋斗
    2018-2-28 18:04
  • 签到天数: 40 天

    连续签到: 1 天

    [LV.5]测试团长

    发表于 2009-4-28 16:37:03 | 显示全部楼层
    沙发
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2009-4-28 22:04:15 | 显示全部楼层
    依赖不满足即形成风险
    一、进度风险
    依赖1:版本提交延迟
    依赖2:版本安装人员进度控制不严
    依赖3:人力资源不足
    依赖4:需求变更频繁
    二、质量风险
    依赖1:开发人员新手较多,代码未经自测;修改问题速度慢
    依赖2:测试人员经验不足,前期积累少
    依赖3:缺乏相应的测试工具
    三、环境风险
    依赖1:测试环境冲突或测试资源少
    应对措施其实就是解决依赖
    回复 支持 反对

    使用道具 举报

  • TA的每日心情

    2015-9-10 15:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    发表于 2009-4-29 18:33:25 | 显示全部楼层
    占位
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2009-4-30 18:05:32 | 显示全部楼层
            风险和问题
           
            市场的压力
            测试时间不够,主要是功能冻结后的系统测试的时间可能不够
            测试资源是否能及时到位(设备和人员)
            测试人员的流动和培训
            开发进度的变化,需求或设计的变更
            开发组的版本控制

            解决方案

            在项目开始前,把一些可能会有变化(需求的变更、市场的压力和开发组的版本控制)、难以控制的因素列入风险管理计划中;   
            在做时间估算时,要留出时间来预防一旦测试需要延长时间的风险
            做好资源(设备和人员)的估计,要留有余地,不要用到100%
            对每个关键性技术人员培养后备人员,作好人员流动的准备,采取一些措施确保人员一旦离开公司,    项目不会受到严重影响,仍能可以继续下去
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2014-10-24 09:36
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    发表于 2009-5-4 16:33:01 | 显示全部楼层
    1.人员不足,或人员缺少相关测试经验,人员离职等---人员培训,备份,文档规范化。
    2。测试环境问题,如布署,网络等--稳定的测试环境
    3。开发进度------制定开发和测试计划,并做误差总结。
    4。用户需求的变更----和用户有效的沟通
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2009-5-5 12:21:48 | 显示全部楼层

    回复 1# 的帖子

    1.来自上游的风险
    1.1质量:上游研发工程师未经自测或自测不严格导致的产出物质量低,直接影响后续的测试——解决方案:对上游的测试进行复核以及检查确认,有问题部分打回研发重新自测
    1.2工期:上游对于工期控制不严格导致测试的工期受挤压——解决方案:事先约定提交日期以及粗线条计划,如有变动项目组内及时知会
    1.3需求变动:最上游的需求提出方发起变更,导致整体的开发、测试需要进行对应的更改——解决方案:一方面增加变更的代价从而控制变更次数,另一方面,应对此类变更,整体项目都需要调整,针对新的需求重新估算即可。

    2.测试阶段本身的风险
    1.1质量:对测试设计、人员的依赖度高,中途如果出现变化很难控制——解决方案:测试同样分拆成不同的阶段(测试计划、测试设计、工具开发、执行等等),分阶段进行产出的控制,这样可以在一定程度降低人员的影响:比如加入用例设计的review,可以降低用例质量带来的风险;另一方面对用例设计、书写规范做要求并尽量自动化,可以减少人员变动带来的执行层面的风险。这就需要测试计划时预留用例review以及自动化书写的时间。
    1.2工期:测试周期难估算并且不可控,特别是研发修复问题时间不可控——解决方案:一方面,进行测试计划的时候预留出buffer时间来(这个部分需要依赖经验判断),并且对于大周期项目明确mailstone(类似xx时间完成一轮测试或xx时间完成所有bug的修复);另一方面,计划本身是可调整的,那么我们要做的是尽量去控制它的变动,让调整发生在可控的范围之内。如果发现很难按照时间来给出测试计划,那么可以换一个角度,分步用质量来控制测试的工期:每一轮测试给出发现的bug数目,绘制bug收敛曲线,当足够收敛时即可结束测试任务。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2009-5-6 09:58:27 | 显示全部楼层
    设计方面:       
    风险:(1)没有详细设计说明书;
    解决方案:测试人员要在开发阶段对相关设计及需求文档进行分析,对大体模块功能进行分类,分析业务逻辑,在不清楚的地方及时与开发人员沟通。
    风险:(2)没有统一的界面设计规范。
    解决方案:与项目负责人确认测试标准。
           
    开发方面:
    风险:(1)所有模块开发没有统一设计,开发人员有自己的设计方式;
    解决方案:与项目负责人确认标准方式,与标准方式不一致的地方全部以BUG形式提交。
    风险:(2)需求变更开发。
    解决方案:建议将需求变更形成文档,对没有文档的需求变更,在测试过程中发现及时与开发负责人确认,并存档相关变更文档。

    测试本身:
    风险:(1)人力资源;
    解决方案:保证稳定的人员安排。
    风险:(2)硬件资源;
    解决方案:事先分析测试所需硬件资源,及时申请,保证测试工作顺利进行。
    风险:(3)版本控制;
    解决方案:严格控制版本,BUG以版本为单位进行提交。在测试过程中及BUG确认阶段禁止任何代码更新。
    风险:(4)测试时间不足。
    解决方案:动员测试人员完成测试任务,必要时,应给予相应物质奖励。


    有点儿搬门弄斧,很多问题都是在工作中实际遇到的,希望看到精彩的答案。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2009-5-6 16:45:14 | 显示全部楼层
    占楼,回去慢慢想~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2009-5-6 16:52:18 | 显示全部楼层
    先占座,等空下来也探讨下
    从培训毕业后,从去年的10月份开始到现在,一直在做一个项目,由于项目的庞大,问题比较突出,把经历在其中的事情也简单说说:
    风险是一直就存在的,没有风险的系统感觉基本不存在,因为有变化就存在风险
    第一:对于项目来说,需求的变更来的最严重,在这个项目中,需求变更的频繁性,更加大了风险的系数
         解决方案:前期对需求的调研要更加的仔细,需求变更的频度需要进行控制,需求变更应做流程上的控制,每个需求变更需要及时更新文档,并通知相关人员
    第二:时间的评估上,前期对需求,开发,测试总的时间评估的过于热观,导致需求时间上的压缩,开发时间上的压缩,导致最后给测试的时间几乎不够
          解决方案:其实对这个最吃亏的就是测试了,前面总以为后面够时间一拖再托,导致后面没有时间进行,因此需要进行时间点上的控制,前期的时间评估也需要评估到这些时间预留点,到点了就需要严格执行
    第三:代码的质量问题,开发没有进行代码review,没有严格按照流程来进行自测,单元测试等,导致重复对同个问题进行多次修复,这样就导致了时间的被压缩
         解决方案: 开发每提交一个代码,需要严格按照流程进行交叉review,而且需要对自己的代码进行自测,提高代码的质量
    第四:由于前面的延迟,给测试的时间是越来越少,导致正常的测试时间严重压缩了,还压缩了回归测试的时间,也压缩了release的时间,最终带bug上线
         解决方案:还是流程的控制,时间点的把控上,要严格按照流程来执行,给测试充足的时间进行测试,会降低测试上的风险,不会顾此失彼

    :时间风险,需求变更风险,人员流动风险,没有依赖流程进行执行的风险,优先级上的风险,各个系统交互接口之间的风险,架构上的风险,等等,都需要考虑到测试计划中进行分析

    [ 本帖最后由 janeye 于 2009-5-6 21:42 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2009-5-6 16:54:39 | 显示全部楼层
    对评测机构来说,拿不到钱的风险啊
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2009-5-6 21:10:22 | 显示全部楼层

    zhan wei

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2009-5-7 15:29:17 | 显示全部楼层
    测试风险是不可避免的、总是存在的,所以对测试风险的管理非常重要,必须尽力降低测试中所存在的风险,最大程度地保证质量和满足客户的需求。在测试工作中,主要的风险有:

        一、质量需求或产品的特性理解不准确,造成测试范围分析的误差,结果某些地方始终测试不到或验证的标准不对;
        二、测试用例没有得到百分之百的执行,如有些测试用例被有意或无意的遗漏;
        三、需求的临时/突然变化,导致设计的修改和代码的重写,测试时间不够;
        四、质量标准不都是很清晰的,如适用性的测试,仁者见仁、智者见智;
        五、测试用例设计不到位,忽视了一些边界条件、深层次的逻辑、用户场景等;
        六、测试环境,一般不可能和实际运行环境完全一致,造成测试结果的误差;
        七、有些缺陷出现频率不是百分之百,不容易被发现;如果代码质量差,软件缺陷很多,被漏检的缺陷可能性就大;
        八、回归测试一般不运行全部测试用例,是有选择性的执行,必然带来风险。

        前面三种风险是可以避免的,而四至七的四种风险是不能避免的,可以降到最低。最后一种回归测试风险是可以避免,但出于时间或成本的考虑,一般也是存在的。
        针对上述软件测试的风险,有一些有效的测试风险控制方法,如:

        ·测试环境不对可以通过事先列出要检查的所有条目,在测试环境设置好后,由其他人员按已列出条目逐条检查;
        ·有些测试风险可能带来的后果非常严重,能否将它转化为其他一些不会引起严重后果的低风险。如产品发布前夕,在某个不是很重要的新功能上发现一个严重的缺陷,如果修正这个缺陷,很有可能引起某个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大,对策是去掉(Diasble)那个新功能,转移这种风险;
        ·有些风险不可避免,就设法降低风险,如“程序中未发现的缺陷”这种风险总是存在,我们就要通过提高测试用例的覆盖率(如达到99.9%)来降低这种风险;

        为了避免、转移或降低风险,事先要做好风险管理计划和控制风险的策略,并对风险的处理还要制定一些应急的、有效的处理方案,如:

        ·在做资源、时间、成本等估算时,要留有余地,不要用到100%;
        ·在项目开始前,把一些环节或边界上的可能会有变化、难以控制的因素列入风险管理计划中;
        ·对每个关键性技术人员培养后备人员,作好人员流动的准备,采取一些措施确保人员一旦离开公司,    项目不会受到严重影响,仍能可以继续下去;
        ·制定文档标准,并建立一种机制,保证文档及时产生;
        ·对所有工作多进行互相审查,及时发现问题,包括对不同的测试人员在不同的测试模块上相互调换;
        ·对所有过程进行日常跟踪,及时发现风险出现的征兆,避免风险。

        要想真正回避风险,就必须彻底改变测试项目的管理方式;针对测试的各种风险,建立一种“防患于未然”或“以预防为主”的管理意识。与传统的软件测试相比,全过程测试管理方式不仅可以有效降低产品的质量风险,而且还可以提前对软件产品缺陷进行规避、缩短对缺陷的反馈周期和整个项目的测试周期。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2009-5-7 15:37:15 | 显示全部楼层
    (1)缺乏版本控制,难以保证测试进度
    (2)缺乏版本控制,难以保证测试的一致性
    (3)测试版本冗余,易出现误用风险
    (4)容易导致本地版本和服务器版本不一致
    (5)缺乏测试文档可追溯性
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2009-5-7 15:37:52 | 显示全部楼层
    在测试工作中,主要的风险有:
        一、质量需求或产品的特性理解不准确,造成测试范围分析的误差,结果某些地方始终测试不到或验证的标准不对;
        二、测试用例没有得到百分之百的执行,如有些测试用例被有意或无意的遗漏;
        三、需求的临时/突然变化,导致设计的修改和代码的重写,测试时间不够;
        四、质量标准不都是很清晰的,如适用性的测试,仁者见仁、智者见智;
        五、测试用例设计不到位,忽视了一些边界条件、深层次的逻辑、用户场景等;
        六、测试环境,一般不可能和实际运行环境完全一致,造成测试结果的误差;
        七、有些缺陷出现频率不是百分之百,不容易被发现;如果代码质量差,软件缺陷很多,被漏检的缺陷可能性就大;
        八、回归测试一般不运行全部测试用例,是有选择性的执行,必然带来风险。

        前面三种风险是可以避免的,而四至七的四种风险是不能避免的,可以降到最低。最后一种回归测试风险是可以避免,但出于时间或成本的考虑,一般也是存在的。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2009-5-7 16:47:03 | 显示全部楼层
    13楼是转的希赛的资料吧?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2009-5-7 16:47:59 | 显示全部楼层
    15楼也是.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2009-5-7 17:17:21 | 显示全部楼层
    学习中
    回复 支持 反对

    使用道具 举报

    该用户从未签到

     楼主| 发表于 2009-5-8 09:20:27 | 显示全部楼层
    原帖由 bht2000 于 2009-5-7 16:47 发表
    13楼是转的希赛的资料吧?


    一楼的相关文章就提供了连接呀

    测试风险的管理
    http://www.51testing.com/html/90/n-9990.html
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2009-5-8 14:09:36 | 显示全部楼层
    顶顶看。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-3-29 21:24 , Processed in 0.089760 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表