各个阶段Bug数量估计

1.作测试计划的时候,是应该估计一下该软件的BUG数量,BUG集中点,以及修改该BUG的难度与时间 如果这些不估计,那编写测试用例的时候无法对某些重要模块作出着重测试 但是如何估计这个数量,那是任谁也帮不了你的,这得根据该团队的技术水平,以往项目测试的结果数据,本项目的系统分析报告及需求说明书来估计.而且这还不是想当然的去估计,是有公式的.但这套公式只有在历史数据最多的情况下预测出来的结果越准确. 其实也不需要这么麻烦,如果你测试过这个团队的项目,那你心里应该有个大体的预测,应该在哪些地方会出问题,哪些控件/事件/校验等等的处理的不完善

2.回楼上,不估计数量一样能作着重测试,但只适合老团队,老伙伴 如果是带领一个新的团队,或者带着一帮新手,你不作BUG数量估计,那你心中没办法有个度量 如果你估计的BUG数量是100,但检查出来的是10或1000 都说明这里面有很大的问题,就需要去找问题的根源了.. 这个估计BUG数量,只是可选的,不是必选的.随自己的工作习惯了~

3. 引用 5 楼 feng790607 的回复:回楼上,不估计数量一样能作着重测试,但只适合老团队,老伙伴  如果是带领一个新的团队,或者带着一帮新手,你不作BUG数量估计,那你心中没办法有个度量  如果你估计的BUG数量是100,但检查出来的是10或1000 都说明这里面有很大的问题,就需要去找问题的根源了..  这个估计BUG数量,只是可选的,不是必选的.随自己的工作习惯了~ 说的不错～～ 这种bug数量的精确预测是需要大量历史经验数据的，这要看公司的MA成熟度水平了 其实软件工程的理想状态当然是这样的，只有少数公司能够做到预测缺陷数量 预测缺陷数量是很必要的，因为如果实际测试出的bug数量远低于预测值的话，真的就要检查了，是预测出了问题还是测试组没有测试出应有的问题 按照bug 围堵理论来讲，最好在bug引入的阶段就将该bug查找出来，如果漏到下一个阶段甚至漏到交付给客户，那问题就大了，而且解决bug的成本也会成几何级数增长，而且对客户满意度指标，客户交付缺陷密度指标非常不利。