默默巫 发表于 2009-4-27 15:14:53

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

在编写测试计划的时候要考虑可能发生的风险,并提出应对措施。那么到底都有哪些风险要注意呢?如何解决呢?

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


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

http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif

相关文章:

测试风险的管理

回归的风险

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

更多内容请点击>>>


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

archonwang 发表于 2009-4-28 16:37:03

沙发

bently 发表于 2009-4-28 22:04:15

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

阿七 发表于 2009-4-29 18:33:25

占位

lixiaoyan_smart 发表于 2009-4-30 18:05:32

        风险和问题
       
        市场的压力
        测试时间不够,主要是功能冻结后的系统测试的时间可能不够
        测试资源是否能及时到位(设备和人员)
        测试人员的流动和培训
        开发进度的变化,需求或设计的变更
        开发组的版本控制

        解决方案

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

aman_cao 发表于 2009-5-4 16:33:01

1.人员不足,或人员缺少相关测试经验,人员离职等---人员培训,备份,文档规范化。
2。测试环境问题,如布署,网络等--稳定的测试环境
3。开发进度------制定开发和测试计划,并做误差总结。
4。用户需求的变更----和用户有效的沟通

gracech 发表于 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收敛曲线,当足够收敛时即可结束测试任务。

liuchunyanli 发表于 2009-5-6 09:58:27

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

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


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

wangjingying 发表于 2009-5-6 16:45:14

占楼,回去慢慢想~:victory:

janeye 发表于 2009-5-6 16:52:18

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

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

[ 本帖最后由 janeye 于 2009-5-6 21:42 编辑 ]

majun915 发表于 2009-5-6 16:54:39

对评测机构来说,拿不到钱的风险啊

candy_83 发表于 2009-5-6 21:10:22

zhan wei

:)

贝贝酷 发表于 2009-5-7 15:29:17

测试风险是不可避免的、总是存在的,所以对测试风险的管理非常重要,必须尽力降低测试中所存在的风险,最大程度地保证质量和满足客户的需求。在测试工作中,主要的风险有:

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

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

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

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

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

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

namisang 发表于 2009-5-7 15:37:15

(1)缺乏版本控制,难以保证测试进度
(2)缺乏版本控制,难以保证测试的一致性
(3)测试版本冗余,易出现误用风险
(4)容易导致本地版本和服务器版本不一致
(5)缺乏测试文档可追溯性

namisang 发表于 2009-5-7 15:37:52

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

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

bht2000 发表于 2009-5-7 16:47:03

13楼是转的希赛的资料吧?

bht2000 发表于 2009-5-7 16:47:59

15楼也是.

kuangquanshui 发表于 2009-5-7 17:17:21

学习中

默默巫 发表于 2009-5-8 09:20:27

原帖由 bht2000 于 2009-5-7 16:47 发表 http://bbs.51testing.com/images/common/back.gif
13楼是转的希赛的资料吧?

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

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

郁闷的我 发表于 2009-5-8 14:09:36

顶顶看。
页: [1] 2
查看完整版本: 软件测试过程中有哪些风险?(09-04-27)(获奖名单已公布)