为什么测试阶段的进度最难控制？(2013.10.9)(获奖名单已公布)
本周的问题为“为什么测试阶段的进度最难控制？”此话题由会员愚人提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
获奖名单
奖项获奖名单奖励答案链接
一等奖土土的豆豆 京东购物卡50元#10
二等奖janeajue 300论坛积分#29
二等奖千里 300论坛积分 #15
本周的问题为“为什么测试阶段的进度最难控制？”
此话题由会员提供，如果你也有问题想提出来和大家一起讨 ...
lsekfe 发表于 2013-9-2 15:02 http://bbs.51testing.com/images/common/back.gif
大家可以开始讨论了哦！ 1. 人员变动问题，导致测试资源不够，测试时间只好延长。
2. 人员技术问题，测试执行时对计划中要用到的测试技术和测试工具不熟悉。
3. 员工工作效率低下，本来预期要完成的任务，各种delay。
4. 测试工具自身的缺陷，导致测试执行时出行各种无法预期的问题。
5. 开发fix bug的能力不够，导致bug的fix时间过长。 本帖最后由 liu44062405 于 2013-9-2 16:35 编辑
验收测试最难控制了，在需求的时候客户是啥都好说。等到验收的时候那变更好比东北的洪水 哇哇的变啊 我的那个神啊~~ 说来说去还是需求的问题。及时确定了需求 后期他也要各种改~~~伤不起啊
上帝的需求真的是不满足不行啊验收不过白干啊~~:Q 个人觉得测试阶段的测试环境很重要，一定要保证测试环境正常。 回复 5# pengyun3
正式环境和测试环境不是一个环境？这是最基本的吧 如果都不给你一个模拟真实的环境那真心没必要了~ 回复 3# Tesla9527
这些问题 都是后期的项目中的问题吧，如果可以的话 尽量细节都可以避免的 我个人觉得 还是那个命脉最关键吧 需求都不稳定 变动肯定大 再多的人员配置 再好的测试工具都抵不住需求的变更吧~ 回复 7# liu44062405
+1 1、代码的规范（导致bug出现后无法准确定位）
2、fix bug引起的问题（修复bug后引起相关模块的bug出现）
3、team的组成（人员经验不足[当然包括测试人员和开发人员]）
4、流程的规范（项目管理中出现问题，无法准时准确的解决问题）
5、最重要的一点需求不够明确，到中后期发现与主线有偏差后导致项目仓促的赶进度。 测试阶段地处软件开发生命周期的收尾阶段。从地理位置上看，本来就不是个好位置。因为前期项目的压力势必累积到一定程度会释放出来。而测试后面阶段即上纲上线——部署发布。
试问，一个不成熟的、问题遗留一大堆的、不可靠的系统能否上线运营呢？即便开始运营了，能持久否？
好了，回归本期话题：测试进度最难控制主要来自于以下这些因素的影响：
1、需求变更和需求定位不明确
最可怕的当属最先开始的需求部分！话说你都分析不透彻，需求不明确，或者在SDLC中后期来几波需求变更，这不是坑爹么！我们测试人员怎么去把握呢？作为验证需求是否正确的测试人员，在无理需求面前，在频繁变更需求时瞬间会无语、无助、无用，因为我们之前做的是无意义的！但现实如此，我们还是得测啊……
2、设计架构存在大方向错误或瓶颈
除去开始需求外，总体架构设计有明显错误的话，后面存在的漏洞是很恐怖的。开发人员会不断的为一个垃圾框架而不断打所谓的“补丁”，这样我们测试人员也得配合不时的测试。当然包括单元测试、模块测试、集成测试、系统测试整个测试流程步骤！先搞功能，然后性能，可能还有安全、稳定性等各种测试来一遍。时间呢，就这么多出来了……
3、开发人员代码质量低下
好吧，开发人员编码成就了程序/项目/产品的诞生。测试就是尽可能发现开发出来东东的一系列问题。开发人员的能力，即代码是否规范、程序是否健壮、系统模块是否都覆盖需求等等，决定了测试人员返工的情况。注意，这里是返工，即回归测试所花费的时间，因为好的开发人员遗留的问题较少，也同时给测试人员在系统的测试后期带来明显优势。
4、测试人员自身能力不足
什么？当然要说说我们自己测试人员。啥都怪人家需求不清楚，设计不健全，开发不规范，我们就没有自我反省过么？作为测试人员，在本身职责范围内，是否明确了需求？我们可以一开始就参与测试需求分析，明确业务功能点，尽早提出测试人员自己的看法，规避需求上的大问题。设计、开发阶段不管了么？错了，我们可以在概要/详细设计阶段就给出自己的建议，如用TDD等方法来让开发设计人员良性的写代码。对于所属测试执行阶段，我们的用例是否覆盖到全部？执行起来有和阻碍和困难？这些都是可以从测试阶段来考虑。
5、版本控制及配置管理
好吧，不得不说在SDLC中，配置管理和版本控制影响到了测试！我们知道仔细周全的环境对于测试多么重要。你为何不在测试开始前就搭建好所有被测系统的软、硬件环境呢？虽说测试人员也有能力责任去搭建测试平台/框架，前提是系统环境得有个基本保障，别到时候测到一般啥数据没有，代码未发布更新到最新程序集。
同样，版本控制很重要，多少项目在版本控制失常的情况下发布出去的？你测了半天的结果无视，然后回滚一堆旧的、甚至存在问题的版本就这么出去了，到头来又是测试人员的责任？没错！即便到了预上线运营阶段，我们测试人员花出去的心血是希望在稳定的版本上有个质量保障结果，而不是一而再，再而三的混乱状态。
6、领导对测试的意识和支持
领导永远先支持开发人员的，因为没有开发人员何来生产成型的程序/项目/产品？但是对于测试团队和业务的支持足以改变这个项目进度情况。我们希望领导重视测试部门，同样分配扶持力度甚至更加关心测试团队，毕竟测试阶段是SDLC中不可或缺的组成部分，为高效优质的程序/项目/产品给予质量保障的核心阶段！您得这么想，放弃或忽略测试阶段的领导，后期等着排队维护，甚至投诉吧。
综上，其实测试阶段进度难以控制不是一两个人，一两个阶段造成的。说白了还是综合项目管理的结果，也是所有SDLC中参与人员共同运维的结果。我们必须在项目开始初期，从需求分析、框架设计、代码开发、测试执行、运维管理等多方面保证每个阶段都按部就班的工作和执行，才可能按期完成任务，达到良性循环的效果。反之，需求不清、设计紊乱、开发缺陷、测试不足，各种管理混乱的话，测试进度只是项目进度难以控制在中后期的一个堆积点，其实反映出整个项目管理上的不足和混乱。
老生常谈的问题，个人拙见，请指正。 回复 10# 土土的豆豆
学习了 回复 1# lsekfe
测试进度不是仅仅取决于测试团队，测试中还得与研发人员进行交流，如果研发人员能够及时解决问题的话，一般都不会影响测试进度，但是很多情况下无法及时回复，另外，测试过程中如果遇到测试环境奔溃的情况下，很难处理。所以突发情况是要事先预估的 回复 9# junyjiang
+1 很多时候，测试基于开发，必须有开发人员才有测试。
开发的进度以及质量对测试的影响很大
如果没有完整的评审流程，测试过程中经常会出现小细节功能却对进度造成重大影响的情况。
软件开发本来就是一种智力活动，不能完全用工业化去标准，而测试却是对智力活动的再次活动，所以就更难以评估了。 本帖最后由 千里 于 2013-9-7 10:09 编辑
愚人的问题是一个好问题，提得非常好，所以一定要回复。
看了其他坛友的回复，说出了测试阶段进度难控制体现在哪些方面，那些方面是导致进阶难控制的原因。
我从项目管理的角度来谈一下这个问题吧，因为我觉得这个问题更是一个项目管理的问题。
难控制的意思就是经常超出自己的意料，实际进展不能吻合测试计划。
从计划角度来说，测试执行的阶段最难控制的原因主要体现在两个方面：
测试环境的不稳定性和缺陷的数量及修复难度
这两方面都将较大程度的影响测试主管制定测试计划和执行测试计划，正所谓计划赶不上变化
从项目的渐进明细角度来说，测试前期对整个测试周期的估算都是理想的，前期乐观后期悲观是咱们的常态。
无论计划、文档完整度、需求变更、程序质量、版本控制、测试人员自身能力甚至沟通顺畅度都是乐观的。
随着工作的开展，项目工作越来越明晰的时候，问题和风险就来了。
计划赶不上变化，文档也不够完善，需求竟然还变更了，程序缺陷无数、版本无法控制甚至与开发沟通的各种问题统统集中出现了。
而作为测试经理的领导在这个时候也无能为力，作为测试小兵的咱们已经痛苦不堪，早已习惯一旦进入执行阶段即意味着加班的无底洞。
这些问题大多在风险管理环境没有做好，前期阶段没有做好风险应对方案以及预留解决这些问题的时间，导致时间只能从执行阶段的加班时间中挤出。
风险管理没做好的结果是进入执行阶段将为前期没做好的事情买单。
本身环境不稳定和缺陷数据和修复难度就已经让测试阶段的进度难以控制了，再加上前期种种问题的积累，压在测试人员的身上喘不过气来。
PS:沟通管理在项目管理中是最重要的部分，包括前期测试人员对需求理解时与业务人员、开发人员所进行的沟通以及测试执行过程中缺陷汇报以及进度报告的沟通。
人在沟通上，感情和矛盾都是可以积累的，若积累的是矛盾将导致和包括开发在内的其他人员沟通越来越困难
无论在缺陷处理过程中开发不及时修复，还是验证阶段摆不平客户，这些都属于沟通管理的部分。 回复lsekfe
测试进度不是仅仅取决于测试团队，测试中还得与研发人员进行交流，如果研发人员能够 ...
tangyl 发表于 2013-9-2 18:33 http://bbs.51testing.com/images/common/back.gif
这属于沟通风险 说简单点就是做计划时，没有把可能发生的事情想全面了。计划过于理想化，说白了就是为计划而计划，不切实际。
哪些是可控的，哪些是不可控的，不可控的有风险高低之分。做好这些分析，你的计划还能不可控？
另一个，我们的项目经理，他不把项目搞复杂了，怎么有机会体现他的“本事”？你说对吧？ 说简单点就是做计划时，没有把可能发生的事情想全面了。计划过于理想化，说白了就是为计划而计划，不切实际 ...
Nio 发表于 2013-9-9 13:17 http://bbs.51testing.com/images/common/back.gif
不把问题搞复杂，就没办法向公司申请到更多的人力和资金，也没办法向客户签更大的合同。 测试阶段的时间，很大程度上取决于开发“提测”的质量，而这个质量比较难以量化。 学了
页:
[1]
2
