51Testing软件测试论坛

标题: 软件测试过程中有哪些风险？（09-04-27）（获奖名单已公布） [打印本页]

作者: 默默巫 时间: 2009-4-27 15:14
标题: 软件测试过程中有哪些风险？（09-04-27）（获奖名单已公布）
在编写测试计划的时候要考虑可能发生的风险，并提出应对措施。那么到底都有哪些风险要注意呢？如何解决呢？

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

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

相关文章：

测试风险的管理

回归的风险

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

更多内容请点击＞＞＞

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

作者: archonwang 时间: 2009-4-28 16:37
沙发

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

作者: 阿七 时间: 2009-4-29 18:33
占位

作者: lixiaoyan_smart 时间: 2009-4-30 18:05
 风险和问题

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

 解决方案

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

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

作者: gracech 时间: 2009-5-5 12:21
标题: 回复 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
设计方面：
风险：（1）没有详细设计说明书；
解决方案：测试人员要在开发阶段对相关设计及需求文档进行分析，对大体模块功能进行分类，分析业务逻辑，在不清楚的地方及时与开发人员沟通。
风险：（2）没有统一的界面设计规范。
解决方案：与项目负责人确认测试标准。

开发方面：
风险：（1）所有模块开发没有统一设计，开发人员有自己的设计方式；
解决方案：与项目负责人确认标准方式，与标准方式不一致的地方全部以BUG形式提交。
风险：（2）需求变更开发。
解决方案：建议将需求变更形成文档，对没有文档的需求变更，在测试过程中发现及时与开发负责人确认，并存档相关变更文档。

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

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

作者: wangjingying 时间: 2009-5-6 16:45
占楼，回去慢慢想~

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

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

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

作者: majun915 时间: 2009-5-6 16:54
对评测机构来说，拿不到钱的风险啊

作者: candy_83 时间: 2009-5-6 21:10
标题: zhan wei

作者: 贝贝酷 时间: 2009-5-7 15:29
测试风险是不可避免的、总是存在的，所以对测试风险的管理非常重要，必须尽力降低测试中所存在的风险，最大程度地保证质量和满足客户的需求。在测试工作中，主要的风险有：

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

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

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

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

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

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

作者: namisang 时间: 2009-5-7 15:37
（1）缺乏版本控制，难以保证测试进度
（2）缺乏版本控制，难以保证测试的一致性
（3）测试版本冗余，易出现误用风险
（4）容易导致本地版本和服务器版本不一致
（5）缺乏测试文档可追溯性

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

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

作者: bht2000 时间: 2009-5-7 16:47
13楼是转的希赛的资料吧?

作者: bht2000 时间: 2009-5-7 16:47
15楼也是.

作者: kuangquanshui 时间: 2009-5-7 17:17
学习中

作者: 默默巫 时间: 2009-5-8 09:20

原帖由 bht2000 于 2009-5-7 16:47 发表
13楼是转的希赛的资料吧?

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

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

作者: 郁闷的我 时间: 2009-5-8 14:09
顶顶看。

作者: 郁闷的我 时间: 2009-5-8 14:10
软件测试风险：是软件测试过程出现的或潜在的问题，造成的原因主要是测试计划的不充分、测试方法有误或测试过程的偏离，造成测试的补充以及结果不准确。

软件测试风险主要是对测试计划执行的风险分析与制定要采取应急措施，重点在措施。

测试计划的风险：一般指测试进度滞后或出现非计划事件；常见的有交付日期、测试需求、测试范围、测试资源、人员的能力、测试预算、测试环境、测试支持、测试工具。

作者: lanbiers 时间: 2009-5-8 19:18
1. 开发与测试的理解误差导致测试方向偏差
2. 测试对设计的不理解导致测试质量不高
3. 没有足够的大局观导致测试偏颇不全面
4. 过于依赖工具

作者: cagemm 时间: 2009-5-10 14:47
预见风险才能减少风险。
我是做公司内部验收测试的，产品为软硬件结合的产品。测试人员需要完成产品资料审核、目标文件编译、测试样品准备，然后才是测试设计、测试执行、测试报告和跟踪。在各阶段都会出现一定的风险。
1、资料审核阶段：测试接收准则的不完善，资料审核的覆盖率。
2、目标文件编译：编译过程中的，由于环境搭建或者组件编译中出现的源码错误造成编译工作延时。
3、测试样品准备：生产人员由于生产任务较多等原因造成准备测试样品的延时。
4、测试设计：测试人员对于产品功能理解的偏差；测试人员本身测试技术水平；测试用例的覆盖率。
5、测试执行：测试用例执行率。
6、测试报告：测试报告编写不够详细、对问题描述存在歧异。测试准则制定不规范，研发人员和测试人员对于Bug的确认存在分歧。
7、测试跟踪：研发部门对于问题解决的延时。

目前想到的就这么多

作者: 搂搂兔 时间: 2009-5-11 09:11
最大的风险就是领导瞎指挥，不懂的领导还好说，就怕那种一知半解的领导，弄的你很烦

作者: zhyb_2008 时间: 2009-5-12 09:51
希望谈个人工作中的总结多点儿.摘抄少一些.达到互动的目的.

作者: 贝贝酷 时间: 2009-6-10 09:40
标题: 回复 16# 的帖子
我是从其他的网站摘录的！

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)