计划
质量
方法 万事开头难嘛. 如果对业务熟悉，以及了解修改点的话，进度还是比较容易把控的 不仅仅是测试，开发的进度也一样不好评估 一点也不觉得难控制的。
系统测试阶段，取决于项目计划、测试计划，这些难控制嘛？
验收阶段，取决于客户。客户的理解力、执行力。但更取决于项目经理、测试经理的执行力、协调力。如何说服客户的资源获取、版本功能实现方案的改或者不改等等，这些就取决于项目经理的说服力了。 在一些项目流程不规范的测试项目中，测试人员没有很早的介入产品的测试工作中，到了后期提交测试，测试人员才看到要提测的结果，不能保证全部需求点没有变动，开发质量也没有很好的了解，测试阶段开发人员的很多工作可能不只是修改bug，甚至会添加修改新的功能点；测试人员的用例不全面，一些重要bug不会在最初阶段大部分被发倔出来，都会导致测试阶段的进度难以控制 一点也不觉得难控制的。
系统测试阶段，取决于项目计划、测试计划，这些难控制嘛？
验收阶段，取决于客户 ...
zbl0531 发表于 2013-9-16 14:09 http://bbs.51testing.com/images/common/back.gif
简单一点说，世界上没有难做的项目。 1、bug修复的进度
2、性能问题排查过程 回复 1# lsekfe
1、开发的测试版本质量低下，同一个问题甚至修复好几遍，或者一个问题的修复会影响到系统其它部分，导致修复过程中新bug出现。
2、测试人员能力不高。比如在第一轮测试中未发现已经存在的bug，在开发修改重新提交后才发现本该早些发现的bug，导致测试进度拖延。
3、用户需求变更。不乏碰到一个模块已开发完毕提交测试，用户此时一定要变更需求，导致开发二次修改，拖延测试进度。
4、需求人员的需求设计不完善。需求人员在设计需求时，极有可能忽略某一细节，所以往往测试人员要在需求设计后抓紧时间解读需求并设计用例，在设计用例时，由于需要考虑全面周详，往往能够发现需求的问题。如果测试人员在开发完成后才介入测试，发现需求设计的问题时，就需要需求人员重新设计再交给开发人员，这样便会拖延测试周期。 回复 10# 土土的豆豆
写的好啊，学习了 很传统的问题，对于老测试人员来说，对于“无法控制的进度”的都有些“麻木”了，自然也有各自应对的方法。两位斑斑大人总结的很到位。
个人觉得无法控制是个很正常的事情，对于大多数国产项目来说，都是常态。说白了就是“陌生”造成的，陌生的业务、陌生的客户习性，陌生的技术，陌生人员......只能靠过程管理去尽量的完善。如果做长期维护或长期客户的项目大家会感到，也许不是很规范的开发流程，一样会有品质相当不错成果物，而且项目进度可控。还是千里斑斑说的风险控制，但是实际工作中，风险管理有多少能够好好执行的。
个人建议，测试经理们在项目初期，尤其制定项目计划时要与项目组据理力争，早介入、争资源、争时间，要不然到了后期我们最遭罪。 挺酷,多发点
页:
1
[2]
