各个阶段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的成本也会成几何级数增长，而且对客户满意度指标，客户交付缺陷密度指标非常不利。

4.引用 10 楼 ericzhangali 的回复:不要拿这理论那概念的忽悠初学者了。  这人做测试，那人写代码，这人在计划的时候去估计那人会出多少个bug，想想都好玩。  至于“如果你估计的BUG数量是100,但检查出来的是10或1000 都说明这里面有很大的问题,就需要去找问题的根源了..”，根源就是估计就是瞎估的，估到一个数量级也是碰巧。 这不是忽悠 说实在真正的软件工程是基于度量的，都是要有精确数据的 只不过现在大部分公司不太重视，没有收集这方面的数据而已 这些所谓的理论也都是很多公司的最佳实践，没有这些实践作为基础，是不能随便就出个理论的

5.引用 9 楼 steedhorse 的回复:不是很理解。  这么说，测试还带着很大的主观性？  假如预测有100个bug，那么当QA测出120个的时候，就完全可以高枕无忧地去玩游戏了？或者反过来，假如辛苦了俩星期还是只测出80个，就那得周末加班继续给我测？ 也不要理解的太机械了，这些历史数据的积累只能提供一个参考值，尽管是参考值随着公司的积累也会不断的趋于精确，如果你预测的精确的话，测出120个的时候就要分析原因了，测出80个再怎么测也测不出来，甚至换个人也测不出来，同样也要分析原因，当然这都要有标准，这要看公司了，有些公司以偏离值10%作为标准，正负10%以内视为正常，不用做原因分析，如果超出了就要做CAR了 公司没有这方面的历史数据就没必要了，但是如果没有这种意识，公司永远不会有这方面的数据积累，也不会进步 这都是基于大量的历史数据的 同类别的项目，规模近似的项目，使用的技术语言相同，同时综合考虑其他因素：编程人员技术水平，功能实现难度... 而且不光是bug，还有评审缺陷，在评审设计文档时的缺陷个数也是要积累的