关注于测试自动化和测试管理，我是一个永远的测试新手。

测试计划的风险和规避模块

上一篇 / 下一篇  2011-01-12 17:14:28 / 个人分类：测试管理

查看( 1094 ) / 评论( 8 ) / 评分( 5 / 0 )
51Testing软件测试网0r3c/T,X4ZC%uI

qiguojie在51testing原创文章，转载请注明出处，谢谢。51Testing软件测试网6PeWn.h9L(E0U

51Testing软件测试网8{ ~o _wpO8o

前几天写了一个项目的测试计划，顺便理了理心中的一些想法，攒文如下，权当抛砖引玉之用：51Testing软件测试网(p?Le%D)['h.G

51Testing软件测试网,Y,?e#X~E5KAK

测试计划风险和规避
E.ww8ija|(W.V01、测试准备进度延误
&eYy,k7DQj0风险分析：如果计划执行过程中，测试准备阶段的测试需求分析到期未完成、测试需求评审未通过、测试设计到期未完成以及测试设计评审未通过，那么就会造成计划进度延误，影响后续测试工作的开展。

\8| g5YA.E'J0

/V%E7JO7j boc0规避方法：需要测试人员在进行测试准备的时候，严格按照既定计划执行，如果出现上述情况，则测试人员根据实际影响情况，申请加班来保证进度。如果进度被延误较多，则需要通知所有项目参与人员和领导，并申请调整测试计划。51Testing软件测试网&[\/u1I,T(IJ

,R-j%qU_zm02、BVT测试未通过51Testing软件测试网CJl;vJ"~ i
风险分析：如果开发提交的测试版本，执行BVT测试未通过，则版本必须打回重新提交，这样可能造成计划进度延误，影响后续的测试工作安排。

p2|R&\#|#Ur0O]051Testing软件测试网dj[2y5x

规避方法：在提交测试版本前，开发应该抽出时间进行自测，如果没有进行单元测试和集成测试，则需要安排进行。如果到期提交的版本被测试打回，为了不影响整体计划的进度，需要开发人员适当安排增加人手或者加班。51Testing软件测试网}|2F1z3v!\.z/E{

%yTN*ZM!WJ }h03、开发进度延误
B4BN3[8Zm B4|k(J0风险分析：如果开发到版本发布时不能按时发布测试版本，则造成后续测试工作的安排顺延，从而行程测试计划执行的风险。

{)o;gc#DFx0

Y*JE4v&WJ0规避方法：请开发组在项目进行过程中严格控制进度，如果有推迟的风险请立即通知测试人员，协商解决。如果到期仍然不能按时发布，则测试人员需要申请修改测试计划，并通知所有相关人员。如果版本发布时间不能修改，则测试人员需要申请加班，并通知主管领导。51Testing软件测试网"?K.m%dVz7@

-U9iD,KY(o6l2d04、难以修复的缺陷造成测试用例阻碍
8}"nL I6K7qew0风险分析：如果测试执行过程中，被测试版本发现难以修复的bug，造成被测试模块的功能阻碍无法执行测试，测试进度安排受到影响。51Testing软件测试网3W+s0G~!W grl

51Testing软件测试网!}1})i4g:e9Vb

规避方法：出现这样的问题，需要开发人员全力配合测试，及时修改出现的问题。如果不能完全修复，也要给测试提供可以测试被阻碍模块的接口。51Testing软件测试网V? m0Q&~-m

%H g6|-D){WU2V05、未修改缺陷过多导致测试不能结束
`a7Du!S,w/P;n0风险分析：在测试将要结束的时候，如果当前版本的现存缺陷过多，被测试版本的各个指标无法达到测试停止标准，那么测试不能结束，将会影响后续版本上线的进度。

\h8~ZV0U051Testing软件测试网U;`|6`Oqx?

规避方法：测试在执行过程中，需要不断的监控被测试项目的现存缺陷情况，如果发现缺陷数量保持一定数量或者不断上升，则需要立即和项目开发组以及领导进行沟通，共同处理。如果将近测试版本发布日期仍然不能有所改善，则需要申请版本延期发布。

&h)Zz1L:i@z051Testing软件测试网1R@q1m(\D

6、其他紧急项目抽调人手51Testing软件测试网|P\\ w6h
风险分析：如果在项目开发过程中或者测试执行过程中，出现项目开发人员或者测试人员被紧急项目调用，无法按照计划安排参与项目，那么会造成相应的计划进度延误。51Testing软件测试网2`(M5T$W3o [ j,c$T {:Z

tdJGa G1[0规避方法：出现上述情况，需要通知所有项目参与人员，共同协商解决。如果没有解决方案，则需要立即上报领导，申请加班或者申请进度延期。
.g/\(T zD)^-d9_+P051Testing软件测试网VzFuSlB:K


收藏 举报

TAG: 计划风险

feeling_6的个人空间 引用 删除 feeling_6   /   2011-03-02 17:21:34
这些风险，在我们项目里基本上都出现了，频繁出现的风险是开发进度延误，延误到什么时候也没个准信，一期项目做下来，特累~~
feeling_6的个人空间 引用 删除 feeling_6   /   2011-03-02 17:17:47
评 5 分
自动化测试和过程改进 引用 删除 bincard   /   2011-02-15 18:56:56
老兄写得很好，条理很清楚。不过从我们这边情况来看，你列出的这几条特别是2，3，4在每一个周期里几乎都会触发。我理解的风险应该是很小概率发生的情况，否则就应该列入正式的测试计划中。也就是说在一开始做计划的时候，就要给这些情况留出时间来，否则不延期还等啥。所以我觉得实际操作中，需要根据具体项目，把这几条的条件定义得更明确一点。比如bvt break占所有执行次数的比例等等。
当然也可能你这里只是列出大概，具体项目中你有更明确的指标。那么我就算抛砖引玉，希望老兄能拿出来给大家多提供一些参考。
582357212的个人空间 引用 删除 582357212   /   2011-01-15 14:06:54
再补充一句，头像很漂亮
582357212的个人空间 引用 删除 582357212   /   2011-01-15 14:04:30
首先老兄说的很好，我也只是提几个实际遇到的问题希望能了解下具体对策：
1. 测试准备进度延误
假设你测试方面的工作都能按照要求完成，但是原始需求都不明确，说白了，需求就没做好，原始需求的变更就更不会很及时让你知道，还怎么谈的上测试需求评审。
2.开发就是在发布前不测，他的理由是没时间，或者这不属于他的测试范围，老板一般都会为了完成编码任务而倾向于开发的，这时候也没办法谈第二点了
3.开发什么时候发布版本根本就不会跟你说，如果有项目计划，那一般实际情况是到了测试阶段进度计划已经被该的面目全非了，为了交付客户，也没人关心进度按没按照进度计划来了。
4.呵呵 第四点还有点可行性，只是不会要求开发，因为要求也没用，他不会理你，当然表面上还会说配合的，我们实际做法是，那一个模块算做failed，测完提交测试报告给更高层领导说明情况来给开发施压
5.这个基本没法避免，客户就是老大，耽误谁也不能耽误客户，你没测完也必须给客户，所以我们做法是在有限的时间内先测试重要功能的正向功能和常见的负向功能，有时间再测试其他的，但是报告中一定要给出没测试部分的风险预警。
6. 这项要看是什么如人，什么项目了，可以实施

我只是提出点疑问。老兄写得都好，希望能多多沟通交流
比较狠的测试间 引用 删除 qiguojie   /   2011-01-14 15:09:07
回msw cn同学：
非常感谢你提出的一些意见，其实我攒出这篇文章也只是心中有一些想法，想法还不成熟，这次项目中也是试运行一下。

其实在国内大部分的公司，计划风险是一直存在而且非常容易出现（动不动就延期），这和管理不规范，质量意识不足、测试重视不够，软件开发过程中特权阶级太多等等都可能有关系，本次尝试加入风险分析模块，也是无奈之举。

我公司这边情况也就不说了，不会比老兄的好多少，呵呵。
xin_晴的个人空间 引用 删除 xin_晴   /   2011-01-13 11:18:14
您好，我是51Testing软件测试网的编辑，您的本篇博文被推荐至51Testing软件测试网首页发表：http://www.51testing.com/html/18/n-227618.html
感谢您关注并支持51Testing博客，期待您更多的优秀原创博文。
msw_cn的个人空间 引用 删除 msw_cn   /   2011-01-13 10:49:58
非常欣赏老兄严谨的工作态度，写得很有条理。你所提到的风险，在我这里可能还无法规避，我说下自己的感受吧。

1. 目前我负责的测试还没有这么高的成熟度。需求我打算确保开发方需求能及时有效更新就可以了，至于测试设计还没法评审。管理成本太高，我这里人手少呀。

2. 看来单元测试和集成测试需要开发来做了，这点我非常不放心，不过也没有办法。不知道你们版本的发布周期是多少，如果每天都发布的话，大可不必列入风险。提高bvt缺陷的优先级，要求开发尽快修改缺陷就可以了。如果BVT不通过变成常态，测试工作的饱和度会受到影响，也是非常影响士气的。

3. 我这的版本是每天发布的，看来你们的版本发布是严格控制的。有一点，如果测试人员要为开发人员的延误买单，是否考虑到他们的情绪。感觉你们的风险控制太容易触发了，不要轻易动风险。风险发生太多弄得大家都很紧张，时间一长就麻木了。

4. 难以修复的缺陷经常发生，这时候及时通知各方面人员最为重要。如果这时要求对应的开发人员配合测试不太可能，因为他没有时间。

5. 从这条看，你们应该是一版一轮测试的模式。不妨想想版本和测试分离。测试退出这个问题一直很烦，真有进入风险的必要。我想应该和测试周期以及测试收敛情况联合度量吧。

6. 个人感觉抽点硬件还行，抽人是万万不行的。紧急项目这种东西非常扯的，很多情况都是管理层瞎编出来的。回过头一看，其实一点都不紧急，反而把你的管理拆得乱七八糟。

我只是提出点反对意见。老兄写得都很实际，有不少内容都教育了我。
 

评分：0

我来说两句

qiguojie

qiguojie

北京测试一草根儿

日历

« 2023-10-11  
日 一 二 三 四 五 六
1234567
891011121314
15161718192021
22232425262728
293031    

数据统计

  • 访问量: 119739
  • 日志数: 39
  • 图片数: 1
  • 建立时间: 2007-06-05
  • 更新时间: 2011-06-29

RSS订阅

Open Toolbar