51Testing软件测试论坛

标题: [原创]关于测试风险 [打印本页]

作者: smartbaby 时间: 2004-5-28 14:00
标题: [原创]关于测试风险
测试风险可以包括：
1.测试不能按期展开和进行、结束
2.测试资源不充分、不能如期到位
3.测试人员对于需求理解不充分
4.需求、设计变更频繁导致测试依据失效
5.BUG的生命周期过于长

抛砖引玉咯～～
希望大家不要仅仅是看，而是参与进来一起讨论，添砖加瓦，这样才能有进步，进步的更快～

我认为：
1.测试不能按期展开和进行、结束
这个问题如果发生的话，整个项目因此会有影响，因此对此的关注应该是从项目经理级就开始～
2.测试资源不充分、不能如期到位
这种风险在于对测试资源估计过于乐观，错误的以为测试人员随时可以调动，测试人员一大把随时可以备用～～
3.测试人员对于需求理解不充分
这种风险存在说明项目经理对测试不重视，测试人员进入项目过晚。导致测试不熟悉需求。
4.需求、设计变更频繁导致测试依据失效
这种风险是普遍存在于目前的项目中，几乎没有什么好的解决方法～
5.BUG的生命周期过于长
这个问题可以反映出开发与测试之间的矛盾以及项目经理级的领导对于测试不重视导致的～
当然咯。相应的解决方法随着原因分析出来就可以得到相应的答案了！

[ Last edited by smartbaby on 2004-5-31 at 10:00 ]

作者: skinapi 时间: 2004-5-28 21:50
引出相关的两个话题：
1。如何去规避这些风险？
测试风险体现在测试计划中，而如何规避这些风险呢？提到的这些风险应该是都可以规避的。
2。出现这些风险该怎么办？
对于这一点，测试计划中有相关的部分。

作者: smartbaby 时间: 2004-5-31 09:58
skinapi有什么好的看法嘛？

[ Last edited by smartbaby on 2004-5-31 at 10:00 ]

作者: skinapi 时间: 2004-5-31 20:16
其实我也就是看到你这篇原创才产生那两点想法，既然你又问了，我就再想想，呵呵。
1。测试风险是肯定存在的，不管是开发人员还是测试人员对被开发的对象都有一个认识过程，特别是复杂的对象，所以我们能做的是最大限度的减小这种风险。
2。多数测试风险的产生都在于测试过程没有在开发过程中占有其应有的位置，比如等UT结束才让测试人员介入做集成测试等。
3。我们一直都在强调公司不重视、项目经理不重视、开发人员不重视，这些都是实情，可是反过来看我们测试人员也有责任，我们没有去尽全力争取自己的权力，没有给那些不做测试的人去讲清什么是测试、测试为什么重要等问题。
4。不少测试人员或多或少都有一点自卑心理（我刚开始也有一点：）），做工作时和开发人员并不是处于一个平等的地位，而是处在被支配的地位。

下面再谈谈怎么去规避风险：
我把你提到的这些风险分成三类：
1。开发过程不完善导致的测试风险，如1、4、5
对于1，测试不能按期完成的一个很重要的原因就是UT的质量无法保证，很多开发人员对如何做好UT并没有一个很清晰的概念，UT发现不了的Bug就要放到IT中花数倍时间去发现。如何提高UT的测试效率，尽量多的发现Bug是一个需要开发团队好好考虑的问题。
对于4，需求和设计的变更通常是无法避免的，但一定要避免其频繁变更。需求的频繁变更多源自于和客户的交流不充分，而设计的频繁变更则多源自于仓促进入编码阶段，设计时考虑不周。所以和客户的交流一定要充分，统一认识，而设计时特别是高层设计时尽量让多的人参加（我一直考虑测试人员是不是也应该参与进去）。
对于5，除非是推迟到下一版本来解决，否则是不允许出现的，在能解决的Bug没有修复之前是不允许相应模块进行新功能的开发，测试人员应该起一个监督和督促的作用。
2。测试人员本身所导致的测试风险，如3
对于3，应该有两方面的原因：一是测试人员进入项目时间太晚，这只能通过规范开发流程来解决；二是被测对象需要测试人员具有相当的专业知识，这就需要测试人员加强自身的学习并积极和开发人员沟通。
3。项目管理不完善导致的测试风险，如2
对于2，主要是一个如何估算测试工作量的问题，这是一个长期的过程，需要不断的数据积累和尝试。
暂时就想了这么多，欢迎讨论！！！

作者: ting_yt2 时间: 2004-6-10 13:48
这些问题我都碰到过啊~~~~
需求不断变更影响到我测试用例的变更有的甚至是我在执行过程中发现了bug 经过与项目经理交流项目经理又会更改需求，从而提交的bug又不成立了～～～
有时也会有需求模糊个人有个人的理解导致不断地确认不断地修改

作者: smartbaby 时间: 2004-6-11 11:43
这种情况是满普遍的，不过既然存在，那就说明它的确是缺陷。
如果由于需求变了，那么相应的bug不存在了，这个也是正常的，关键是确定这些bug的确已经不存在了～～
至于它是用什么方法解决的，并不是非常重要的问题～
你觉得呢？

作者: ting_yt2 时间: 2004-6-11 12:30
原来的Bug就是因为不符合需求而成为bug的，当需求更改后，（其实是更改需求来适应目前的情况而不是修改程序来适应需求），那种类型的bug就相应不存在了

作者: luckhj 时间: 2004-11-4 13:06
学习学习

作者: babybear315 时间: 2004-11-9 12:55
风险分析是很重要的，但如何分析呢？

作者: little_student 时间: 2004-11-16 11:14
具体情况具体分析：
如果能做到整个开发流程都跟下来，在需求分析的时候，对于测试人员来说就决不能含糊，要弄得很清楚；
如果不能，也要详细分析需求分析报告，尽量在编码过程开始前把那些模棱两可的措辞弄得通透直白，这样才会尽量减少bug和返工的出现。
这是我的一点看法，不知道各位版主可否提出补充？

作者: 嘘garfield 时间: 2004-12-21 10:40
其实很多人都觉得测试人员应该从开发的第一天就跟着这个项目.测试应该跟开发不是同一个人.但是目前的情况,要不就是测试人员很晚才参与项目(好象测试人员就是随时从这项目调到那个项目);要不就是开发跟测试同一个人.

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