51Testing软件测试论坛

标题: 为什么测试阶段的进度最难控制？(2013.10.9)(获奖名单已公布) [打印本页]

作者: lsekfe 时间: 2013-9-2 15:02
标题: 为什么测试阶段的进度最难控制？(2013.10.9)(获奖名单已公布)
本周的问题为“为什么测试阶段的进度最难控制？”
此话题由会员愚人提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	土土的豆豆	京东购物卡50元	#10
二等奖	janeajue	300论坛积分	#29
二等奖	千里	300论坛积分	#15

[attach]87094[/attach]

作者: lsekfe 时间: 2013-9-2 15:02

本周的问题为“为什么测试阶段的进度最难控制？”
此话题由会员提供，如果你也有问题想提出来和大家一起讨 ...
lsekfe 发表于 2013-9-2 15:02

大家可以开始讨论了哦！

作者: Tesla9527 时间: 2013-9-2 16:19
1. 人员变动问题，导致测试资源不够，测试时间只好延长。
2. 人员技术问题，测试执行时对计划中要用到的测试技术和测试工具不熟悉。
3. 员工工作效率低下，本来预期要完成的任务，各种delay。
4. 测试工具自身的缺陷，导致测试执行时出行各种无法预期的问题。
5. 开发fix bug的能力不够，导致bug的fix时间过长。

作者: liu44062405 时间: 2013-9-2 16:32
本帖最后由 liu44062405 于 2013-9-2 16:35 编辑

验收测试最难控制了，在需求的时候客户是啥都好说。等到验收的时候那变更好比东北的洪水哇哇的变啊我的那个神啊~~ 说来说去还是需求的问题。及时确定了需求后期他也要各种改~~~伤不起啊
上帝的需求真的是不满足不行啊验收不过白干啊~~

作者: pengyun3 时间: 2013-9-2 16:33
个人觉得测试阶段的测试环境很重要，一定要保证测试环境正常。

作者: liu44062405 时间: 2013-9-2 16:36
回复 5# pengyun3

正式环境和测试环境不是一个环境？这是最基本的吧如果都不给你一个模拟真实的环境那真心没必要了~

作者: liu44062405 时间: 2013-9-2 16:44
回复 3# Tesla9527

这些问题都是后期的项目中的问题吧，如果可以的话尽量细节都可以避免的我个人觉得还是那个命脉最关键吧需求都不稳定变动肯定大再多的人员配置再好的测试工具都抵不住需求的变更吧~

作者: Tesla9527 时间: 2013-9-2 16:57
回复 7# liu44062405

+1

作者: junyjiang 时间: 2013-9-2 17:24
1、代码的规范（导致bug出现后无法准确定位）
2、fix bug引起的问题（修复bug后引起相关模块的bug出现）
3、team的组成（人员经验不足[当然包括测试人员和开发人员]）
4、流程的规范（项目管理[bug管理]中出现问题，无法准时准确的解决问题）
5、最重要的一点需求不够明确，到中后期发现与主线有偏差后导致项目仓促的赶进度。

作者: 土土的豆豆 时间: 2013-9-2 17:28
测试阶段地处软件开发生命周期的收尾阶段。从地理位置上看，本来就不是个好位置。因为前期项目的压力势必累积到一定程度会释放出来。而测试后面阶段即上纲上线——部署发布。
试问，一个不成熟的、问题遗留一大堆的、不可靠的系统能否上线运营呢？即便开始运营了，能持久否？

好了，回归本期话题：测试进度最难控制主要来自于以下这些因素的影响：
1、需求变更和需求定位不明确
最可怕的当属最先开始的需求部分！话说你都分析不透彻，需求不明确，或者在SDLC中后期来几波需求变更，这不是坑爹么！我们测试人员怎么去把握呢？作为验证需求是否正确的测试人员，在无理需求面前，在频繁变更需求时瞬间会无语、无助、无用，因为我们之前做的是无意义的！但现实如此，我们还是得测啊……
2、设计架构存在大方向错误或瓶颈
除去开始需求外，总体架构设计有明显错误的话，后面存在的漏洞是很恐怖的。开发人员会不断的为一个垃圾框架而不断打所谓的“补丁”，这样我们测试人员也得配合不时的测试。当然包括单元测试、模块测试、集成测试、系统测试整个测试流程步骤！先搞功能，然后性能，可能还有安全、稳定性等各种测试来一遍。时间呢，就这么多出来了……
3、开发人员代码质量低下
好吧，开发人员编码成就了程序/项目/产品的诞生。测试就是尽可能发现开发出来东东的一系列问题。开发人员的能力，即代码是否规范、程序是否健壮、系统模块是否都覆盖需求等等，决定了测试人员返工的情况。注意，这里是返工，即回归测试所花费的时间，因为好的开发人员遗留的问题较少，也同时给测试人员在系统的测试后期带来明显优势。
4、测试人员自身能力不足
什么？当然要说说我们自己测试人员。啥都怪人家需求不清楚，设计不健全，开发不规范，我们就没有自我反省过么？作为测试人员，在本身职责范围内，是否明确了需求？我们可以一开始就参与测试需求分析，明确业务功能点，尽早提出测试人员自己的看法，规避需求上的大问题。设计、开发阶段不管了么？错了，我们可以在概要/详细设计阶段就给出自己的建议，如用TDD等方法来让开发设计人员良性的写代码。对于所属测试执行阶段，我们的用例是否覆盖到全部？执行起来有和阻碍和困难？这些都是可以从测试阶段来考虑。
5、版本控制及配置管理
好吧，不得不说在SDLC中，配置管理和版本控制影响到了测试！我们知道仔细周全的环境对于测试多么重要。你为何不在测试开始前就搭建好所有被测系统的软、硬件环境呢？虽说测试人员也有能力责任去搭建测试平台/框架，前提是系统环境得有个基本保障，别到时候测到一般啥数据没有，代码未发布更新到最新程序集。
同样，版本控制很重要，多少项目在版本控制失常的情况下发布出去的？你测了半天的结果无视，然后回滚一堆旧的、甚至存在问题的版本就这么出去了，到头来又是测试人员的责任？没错！即便到了预上线运营阶段，我们测试人员花出去的心血是希望在稳定的版本上有个质量保障结果，而不是一而再，再而三的混乱状态。
6、领导对测试的意识和支持
领导永远先支持开发人员的，因为没有开发人员何来生产成型的程序/项目/产品？但是对于测试团队和业务的支持足以改变这个项目进度情况。我们希望领导重视测试部门，同样分配扶持力度甚至更加关心测试团队，毕竟测试阶段是SDLC中不可或缺的组成部分，为高效优质的程序/项目/产品给予质量保障的核心阶段！您得这么想，放弃或忽略测试阶段的领导，后期等着排队维护，甚至投诉吧。

综上，其实测试阶段进度难以控制不是一两个人，一两个阶段造成的。说白了还是综合项目管理的结果，也是所有SDLC中参与人员共同运维的结果。我们必须在项目开始初期，从需求分析、框架设计、代码开发、测试执行、运维管理等多方面保证每个阶段都按部就班的工作和执行，才可能按期完成任务，达到良性循环的效果。反之，需求不清、设计紊乱、开发缺陷、测试不足，各种管理混乱的话，测试进度只是项目进度难以控制在中后期的一个堆积点，其实反映出整个项目管理上的不足和混乱。
老生常谈的问题，个人拙见，请指正。

作者: liu44062405 时间: 2013-9-2 17:36
回复 10# 土土的豆豆

学习了

作者: tangyl 时间: 2013-9-2 18:33
回复 1# lsekfe

测试进度不是仅仅取决于测试团队，测试中还得与研发人员进行交流，如果研发人员能够及时解决问题的话，一般都不会影响测试进度，但是很多情况下无法及时回复，另外，测试过程中如果遇到测试环境奔溃的情况下，很难处理。所以突发情况是要事先预估的

作者: 利勇lmm 时间: 2013-9-2 18:52
回复 9# junyjiang

+1

作者: IUHK 时间: 2013-9-2 21:16
很多时候，测试基于开发，必须有开发人员才有测试。
开发的进度以及质量对测试的影响很大
如果没有完整的评审流程，测试过程中经常会出现小细节功能却对进度造成重大影响的情况。
软件开发本来就是一种智力活动，不能完全用工业化去标准，而测试却是对智力活动的再次活动，所以就更难以评估了。

作者: 千里 时间: 2013-9-5 13:46
本帖最后由千里于 2013-9-7 10:09 编辑

愚人的问题是一个好问题，提得非常好，所以一定要回复。
看了其他坛友的回复，说出了测试阶段进度难控制体现在哪些方面，那些方面是导致进阶难控制的原因。
我从项目管理的角度来谈一下这个问题吧，因为我觉得这个问题更是一个项目管理的问题。
难控制的意思就是经常超出自己的意料，实际进展不能吻合测试计划。
从计划角度来说，测试执行的阶段最难控制的原因主要体现在两个方面：
测试环境的不稳定性和缺陷的数量及修复难度
这两方面都将较大程度的影响测试主管制定测试计划和执行测试计划，正所谓计划赶不上变化
从项目的渐进明细角度来说，测试前期对整个测试周期的估算都是理想的，前期乐观后期悲观是咱们的常态。
无论计划、文档完整度、需求变更、程序质量、版本控制、测试人员自身能力甚至沟通顺畅度都是乐观的。
随着工作的开展，项目工作越来越明晰的时候，问题和风险就来了。
计划赶不上变化，文档也不够完善，需求竟然还变更了，程序缺陷无数、版本无法控制甚至与开发沟通的各种问题统统集中出现了。
而作为测试经理的领导在这个时候也无能为力，作为测试小兵的咱们已经痛苦不堪，早已习惯一旦进入执行阶段即意味着加班的无底洞。
这些问题大多在风险管理环境没有做好，前期阶段没有做好风险应对方案以及预留解决这些问题的时间，导致时间只能从执行阶段的加班时间中挤出。
风险管理没做好的结果是进入执行阶段将为前期没做好的事情买单。
本身环境不稳定和缺陷数据和修复难度就已经让测试阶段的进度难以控制了，再加上前期种种问题的积累，压在测试人员的身上喘不过气来。
PS:沟通管理在项目管理中是最重要的部分，包括前期测试人员对需求理解时与业务人员、开发人员所进行的沟通以及测试执行过程中缺陷汇报以及进度报告的沟通。
人在沟通上，感情和矛盾都是可以积累的，若积累的是矛盾将导致和包括开发在内的其他人员沟通越来越困难
无论在缺陷处理过程中开发不及时修复，还是验证阶段摆不平客户，这些都属于沟通管理的部分。

作者: 千里 时间: 2013-9-7 08:54

回复 lsekfe

测试进度不是仅仅取决于测试团队，测试中还得与研发人员进行交流，如果研发人员能够 ...
tangyl 发表于 2013-9-2 18:33

这属于沟通风险

作者: Nio 时间: 2013-9-9 13:17
说简单点就是做计划时，没有把可能发生的事情想全面了。计划过于理想化，说白了就是为计划而计划，不切实际。
哪些是可控的，哪些是不可控的，不可控的有风险高低之分。做好这些分析，你的计划还能不可控？
另一个，我们的项目经理，他不把项目搞复杂了，怎么有机会体现他的“本事”？你说对吧？

作者: 千里 时间: 2013-9-9 13:23

说简单点就是做计划时，没有把可能发生的事情想全面了。计划过于理想化，说白了就是为计划而计划，不切实际 ...
Nio 发表于 2013-9-9 13:17

不把问题搞复杂，就没办法向公司申请到更多的人力和资金，也没办法向客户签更大的合同。

作者: powerson 时间: 2013-9-10 13:42
测试阶段的时间，很大程度上取决于开发“提测”的质量，而这个质量比较难以量化。

作者: zm51testing 时间: 2013-9-11 11:00
学了

作者: shine506 时间: 2013-9-11 15:30
需求
计划
质量
方法

作者: fanyincn 时间: 2013-9-12 10:24
万事开头难嘛.

作者: yaya1127 时间: 2013-9-12 11:20
如果对业务熟悉，以及了解修改点的话，进度还是比较容易把控的

作者: msnshow 时间: 2013-9-15 22:25
不仅仅是测试，开发的进度也一样不好评估

作者: zbl0531 时间: 2013-9-16 14:09
一点也不觉得难控制的。
系统测试阶段，取决于项目计划、测试计划，这些难控制嘛？
验收阶段，取决于客户。客户的理解力、执行力。但更取决于项目经理、测试经理的执行力、协调力。如何说服客户的资源获取、版本功能实现方案的改或者不改等等，这些就取决于项目经理的说服力了。

作者: cnuwwl 时间: 2013-9-22 11:11
在一些项目流程不规范的测试项目中，测试人员没有很早的介入产品的测试工作中，到了后期提交测试，测试人员才看到要提测的结果，不能保证全部需求点没有变动，开发质量也没有很好的了解，测试阶段开发人员的很多工作可能不只是修改bug，甚至会添加修改新的功能点；测试人员的用例不全面，一些重要bug不会在最初阶段大部分被发倔出来，都会导致测试阶段的进度难以控制

作者: 千里 时间: 2013-9-22 13:54

一点也不觉得难控制的。
系统测试阶段，取决于项目计划、测试计划，这些难控制嘛？
验收阶段，取决于客户 ...
zbl0531 发表于 2013-9-16 14:09

简单一点说，世界上没有难做的项目。

作者: li_feibo 时间: 2013-9-28 11:21
1、bug修复的进度
2、性能问题排查过程

作者: janeajue 时间: 2013-10-8 17:48
回复 1# lsekfe
1、开发的测试版本质量低下，同一个问题甚至修复好几遍，或者一个问题的修复会影响到系统其它部分，导致修复过程中新bug出现。
2、测试人员能力不高。比如在第一轮测试中未发现已经存在的bug，在开发修改重新提交后才发现本该早些发现的bug，导致测试进度拖延。
3、用户需求变更。不乏碰到一个模块已开发完毕提交测试，用户此时一定要变更需求，导致开发二次修改，拖延测试进度。
4、需求人员的需求设计不完善。需求人员在设计需求时，极有可能忽略某一细节，所以往往测试人员要在需求设计后抓紧时间解读需求并设计用例，在设计用例时，由于需要考虑全面周详，往往能够发现需求的问题。如果测试人员在开发完成后才介入测试，发现需求设计的问题时，就需要需求人员重新设计再交给开发人员，这样便会拖延测试周期。

作者: 真实的追求者 时间: 2013-10-9 09:55
回复 10# 土土的豆豆

写的好啊，学习了

作者: hotivy 时间: 2013-10-9 10:34
很传统的问题，对于老测试人员来说，对于“无法控制的进度”的都有些“麻木”了，自然也有各自应对的方法。两位斑斑大人总结的很到位。

   个人觉得无法控制是个很正常的事情，对于大多数国产项目来说，都是常态。说白了就是“陌生”造成的，陌生的业务、陌生的客户习性，陌生的技术，陌生人员......只能靠过程管理去尽量的完善。如果做长期维护或长期客户的项目大家会感到，也许不是很规范的开发流程，一样会有品质相当不错成果物，而且项目进度可控。还是千里斑斑说的风险控制，但是实际工作中，风险管理有多少能够好好执行的。

   个人建议，测试经理们在项目初期，尤其制定项目计划时要与项目组据理力争，早介入、争资源、争时间，要不然到了后期我们最遭罪。

作者: 海里的幸福 时间: 2016-10-31 17:41
挺酷,多发点

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