本帖最后由 lzz 于 2011-3-1 16:28 编辑
1. Test Estimation Principles
The test estimation is different from other project estimations, because the number of failures is not known in advance—though it can be estimated as well. The number of necessary iterations before the completion criteria are met is usually not known either. As a rule of thumb, at least three iterationsmust be reckoned with—one is definitely not enough, unless the completion criterion is a simple execution of all test cases, and independent of the number of outstanding faults and coverage
The estimation must include:
1)Time to produce incident registrations
2)Possible time to wait for fault analysis
3)Possible time to wait for fault correction
4)Time for retest and regression test (minimunm three interations!)
Experience in the testing business shows that 50% of the original number of faults remains after correction. These are distributed like this:
Remaining faults after correction20%
Unveiled faults after correction 10%
New faults after correction 20%
These are general experience numbers. It's important that you collect your own metrics!
2. The Estimation Process
1). Define the purpose of the estimation—Is this estimation the first approach, for a proposal, or for detailed planning?
2). Plan the estimating task—Estimation is not a two-minute task; set sufficient time aside for it.
3). Write down the basis for the estimation—Here the scope and the size of the work are determined, and all factors that may influence
the estimates are registered. This includes factors related to the nature of the processes we are working by, the nature of the project
we are working in, the people we are working with, and any risks we are facing.
4). Break down the work—This is the work breakdown (i.e., the listing of all the tasks to estimate). Do this as well as possible in relation to
the purpose.
5). Estimate—Use more than one technique as appropriate.
6). Compare with reality and reestimate—This is the ongoing monitoring and control of how the work that we have estimated is actually going.
3. Estimation Techniques
1) FIA(finger in the air) or best guess
2) Experience-based estimation
3) Analogies and experts
4) Delphi technique
5) Three-point estimation (successive calculation)
6) Model-based estimation
7) Function points
8) Test points
9) Percentage distribution
10) Use cases
4.From Estimations to Plan and Back Again
The estimating does not stop with the preparation of the first schedule. Once the actual testing has started—from the first planning activities and onwards,we need to frequently monitor how realities correspond to the estimates.Based on the new information gathered through the monitoring, we must reestimate,when the deviations between estimates and reality get too large to stay in control. Only when all the testing activities are completed can we stop the monitoring and re-estimation.
5.Get Your Own Measurements
In order to get better estimates we need to collect actual data. The more empirical data we have, the better will the estimates be. In general we can say that (almost) any data is better than no data. From an organizational point of view it must be checked that all completed projects collect data, and the usage of these data must, of course, also be enforced.
发表下自己的意见，还请各位大侠多多指点：
1.软件功能模块多少，每个模块规划好时间。
2.软件测试执行难易度，用例再执行的过程中，会遇到很多其他的问题，比如发现致命bug，需要测试人员隔离分析，或者是测试环境搭建有误等其他异常，都需要考虑在内。
从实际工作出发说点我的感受：
预估的前提：有一定的测试经验、对类似项目有相关经验。
预估工作量嘛，当然是项目已经立项，还没正式开工，各个部门都开始计划自己的时间。
这个时期有几种情况：
1.需求是否明确（基本上只有客户意向）？
2.需求是否已经形成正式文档（和客户做过初步访谈，细节方面没敲定）？
3.需求是否正式确定已初步进入开发阶段？
不同时期，估算出来的测试时间是不一样的。
举例说明：
公司有一个项目——某企业要做一个企业网站，放一些企业相关资料上去。——大多数业务员接回来的单都是这样说的，然后项目经理问程序员开发这个要多长时间？问测试员测试这个要多长时间？
程序员说：我们有以前的模板，2个礼拜就可以搞定。
测试员：……
你怎么回答这个问题？
答案一：这个模板以前我们已经测试过，如果改动不大，我们三天就可以搞定。
OK，能答成这样，你已经是个合格的测试员了。
答案二：考虑到测试后的修改和回归测试的总体时间，应该在一个礼拜左右。
OK，给出这个答案的应该可以做个测试主管吧。
答案三：客户具体需求不给力、旧模板能适用客户需求的范围和旧模板要修改的程度也不知道，需要进一步的客户需求有比较可靠的判断。
如果你能给出第三种答案，那么你应该已经是测试经理了。
1、先看开发的工作量
2、在看项目上线的时间
3、预留修改bug的时间
4、考虑测试人员的技术水平
5、考虑测试人员的分配力度
1、先看开发的工作量
2、在看项目上线的时间
3、预留修改bug的时间
4、考虑测试人员的技术水平
5、考虑测试人员的分配力度
1、先看开发的工作量
2、在看项目上线的时间
3、预留修改bug的时间
4、考虑测试人员的技术水平
5、考虑测试人员的分配力度
回复 5# ailen1986 详细，客观。支持
上面说的都灰常有道理啊，咱说点实用的呗，我觉得一般情况下我们接到一个项目，大体上会从以下几个方面考虑：
1.根据项目的规模和复杂程度预估测试工作量A
2.根据以往的项目经验，对上步骤得出的工作量细化成B
3.根据公司的项目过程对B进行修改，结果为C
4.根据开发人员的配置，修改C，得到结果为D（这绝不是对开发人员侮辱，因为现实确实存在这种情况）
5.根据测试组成员，再将D修改为E（如果测试组除了负责人外都是新人，测试工作量无可厚非要增加吧）
当然肯定不是按照这个步骤一步一步来，综合考虑的大概就这几项吧！
回复 18# 582357212
我们公司的大致流程和你讲的差不多
1. 根据测试范围和测试方法来估计工作量：
a）制定测试计划以前，明确测试范围：
不同的测 ...
ailen1986 发表于 2011-2-23 18:47 http://bbs.51testing.com/images/common/back.gif
这个给力……
我个人认为测试的工作量是没有办法做到100%精确的，因为测试理论上是不可能发现软件中的所有bug的。那么如何尽量精确地预估呢？可以考虑从以下几方面考虑：1、参考以往的基线数据：比如日设计用来多少？日测试执行用例多少？基本上正规的测试部门应该有做类似数据的度量的；2、根据所测试软件的复杂度和历史发现bug做参考：基本上复杂度高的软件，测试的工作量是成指数倍增长的。一般情况下，发现的bug越多，遗留的未知bug也会越多，测试工作量也会增大；
大家伙的都值得借鉴啊
以上看到的都是对于以往经验的定性估算，我想借助于统计学，对历史数据进行定量计算
一。选取关系变量
1。项目大小：项目代码数，功能点数（系数1- 10）排除离群点项目
2。技术复杂度：项目实现的技术难度（系数1- 10）
3。自动化测试水平：自动化测试在测试过程中的应用程度（系数1- 10）
4。项目管理水平：公司项目管理水平成熟度（系数1 - 10）
5。测试人员水平：测试人员的技术能力，业务能力总体水平（系数1- 10）
6。项目总体质量指标：各项目所达到的质量水平（系数1- 10）
7。项目测试类型：各项目测试策略，方法的复杂度（系数1-10）
二。从以往项目数据中采集以上数据，并乘以相关系数
三。对以上数据和测试工作量建立一个多元线形回归方程（数学没那么高水平，用统计工具）
对数据进行方差分析，多元线形回归分析，判断回归方程的有效性，研究相关变量的显著性
四。将新的项目的相关参数代入回归方程，计算测试工作量。
以上都还停留在纸面上，最近听了几堂统计学的课，有感而发
不知道哪位大虾有过统计学在这方面的应用，指点一下
本帖最后由 Jackc 于 2011-3-8 16:08 编辑
回复 33# bicknuer
呃，多元线性回归方程.....这个....有点夸张了吧...
我觉得你提到的第1部分挺好的，提取影响项目进行的各个因素，并根据实际项目的的情况设置系数。
通常我们可以再次将项目因子分类，并规定不同类别间的运算关系和系数（为了与1中的系数区分，通常会再次引入一个新的系数，且这个系数往往是定值。当然，有些公司也把这个系数直接放到1中去了，但我认为这种做法风险稍大），最后估算出期望得到结果。
如，
将项目影响因子分为2大类：项目数据 / 团队数据
每类再分为 利/弊
这样分类后，就可以用简单的运算规则设计工作量统计的计算公式。也不需涉及到所谓的多元线性方程，四则运算就能构造公式的基本框架
——————————————
说实话，在实际操作中，1张项目因子表，1个有经验的管理者，再拍拍脑壳，工作量就估算出来了。（何来这么复杂的理论...）
先收藏一下，回头仔细看看，看一遍不够，在看一变。
看了前面各位同伴的回答都非常精彩，这里谈谈我个人的一些理解，欢迎沟通，讨论：
1、分析
首先，当我们接到测试的任务的时候，我们需要对这个任务做一定的分析。弄清楚我们的任务需要做什么事情？也就是范围？我们手头上有哪些资源？包括人力资源和非人力资源以及我们会得到什么样的支撑。另外，我们需要在多久的时间做完这个任务？这个任务的出口准则也就是常说的验收标准是什么？在这些都弄清楚之后，就进入我们的第二步。
2、初步估算
在弄清楚了以上的问题之后，我们也就知道了我们到底要做什么？进度是什么？有哪些资源等了，这个时候如果我们公司平常有比较好的数据的积累，即组织级的数据积累，我们可以参考这样的数据得出一个初步的工作量估算报告。多少人工？多少人月等？如果公司没有这样的组织级数据的积累，那么就可以grouptime的成员，大家坐在一起，用delphi的方法来进行预估，然后取出平均值。对了，在这之前，还需要在分析阶段属于一个WBS的工作分解结构，作为我们这里的delphi分析输入。在这一步完成之后，得到一个初步的工作预估表。类似于我们常说的详细的项目进度计划，只是在我们这里是测试进度计划。
3、监控、调优和积累
最后，就秉承先固化后优化的观点，在计划的执行过程中做到有效的监控，及时的发现问题进行调优和纠偏。项目完成之后，做相关的总结，将数据积累下来，便于后期的估算的参考等
一蹴而就的没有偏差的预算，我个人认为不是说没有，只是这个需要很长的一个过程的数据的积累，同时还有数据的一个维护和有效性的风险跟踪和管理，调整，因为，本身这也就是预算嘛，呵呵
个人之见，欢迎沟通，拍砖讨论。谢谢
转）
场景一：合同前的工作量估算
场景描述：
(1)没有实施过CMMI2级
(2)合同未签，需要给客户报价
(3)有客户的概要需求，有类似的项目数据可供参考
(4)需要估计整个项目的总工作量，以便于估算总成本，给客户报价
估算步骤：
(1)寻找类似的历史项目，进行项目的类比分析，根据历史项目的工作量凭经验估计本项目的总工作量;
(2)进行WBS分解，力所能及地将整个项目的任务进行分解;
(3)参考类似项目的数据，采用经验法估计WBS中每类活动的工作量;
(4)汇总得到项目的总工作量;
(5)与第(1)步的结果进行印证分析，根据分析结果，确定估计结果。
场景二：基于详细需求的经验估计
场景描述：
(1)只有详细需求，没有历史数据
估算步骤：
(1)WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度;WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。
(2)采用经验法估计每个活动的工作量;
(3)汇总得到：每个阶段的工作量、项目的总工作量。
其他说明：
在该场景下，只使用了经验法，无法对结果进行印证，难以判断结果的合理性。
场景三：由编码估算整体
场景描述：
(1)有类似项目的历史数据
(2)有编码活动的生产率数据
(3)有详细需求
(4)实施了CMMI2级，但是没有积累历史项目的工作量分布数据
估算步骤：
(1)产品分解，将系统分为子系统，子系统分解为模块;
(2)WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度;WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。
(3)建立WBS分解中的活动与产品元素的映射关系，识别出WBS中哪些活动可以采用模型法估算;
(4)估计产品元素的规模，可以采用代码行法或功能点法，并估计每个产品元素的复杂度、复用率等;
(5)根据历史的编码阶段的生产率数据和产品元素的规模估计、复杂度、复用率等采用模型法计算每个产品元素的编码工作量;
(6)根据历史的类似项目的数据及估算人的经验估计其他活动的工作量，可以采用经验法。
(7)汇总得到：每个阶段的工作量、项目的总工作量。
其他说明：
在该场景下，混合使用了经验法与模型法，这2种方法互相补充，而不是互相印证。
场景四：由总体印证基于WBS的估计
场景描述：
(1)有类似项目的历史数据
(2) 有类似项目的全生命周期的生产率数据(含管理工作量)
(3)有详细需求
(4)实施了CMMI2级，但是没有积累历史项目的工作量分布数据
估算步骤：
(1)产品分解，将系统分为子系统，子系统分解为模块;
(2)估计产品元素的规模，可以采用代码行法或功能点法;
(3)累计出整个产品的总规模，并估计产品总体的复杂度、复用率等;
(4)根据类似项目的全生命周期的生产率数据和产品的总规模、复杂度、复用率等采用模型法计算总的开发工作量;
(5)WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度;WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。
(6)根据历史的类似项目的数据及估算人的经验估计所有活动的工作量，可以采用经验法。
(7)汇总得到：每个阶段的工作量、项目的总工作量。
(8)与第(4)步得出的工作量进行比较印证，如果偏差不大，则以第(7)步的结果为准，如果偏差比较大，要仔细分析原因，可能的原因举例如下：
类似项目的生产率数据不适合本项目;
WBS分解的颗粒度不够详细;
估算专家的经验不适合本项目;
具体任务的估计不合理;
针对原因，对估算的结果进行调整，使其趋向合理。
其他说明：
在该场景下，对于项目的总工作量有2个结果或者多个结果，这些结果可以互相印证，以发现估算过程中的不合理之处，是估计更加合理。
场景五：三维印证基于WBS的估计
场景描述：
(1)有类似项目的历史数据
(2) 有类似项目的全生命周期的生产率数据(含管理工作量)
(3)有详细需求
(4)实施了CMMI3级，有历史项目的工作量分布数据(阶段分布、工种分布)
估算步骤：
(1)产品分解，将系统分为子系统，子系统分解为模块;
(2)估计产品元素的规模，可以采用代码行法或功能点法;
(3)累计出整个产品的总规模，并估计产品总体的复杂度、复用率等;
(4)根据类似项目的全生命周期的生产率数据和产品的总规模、复杂度、复用率等采用模型法计算总的开发工作量;
(5)根据历史项目的工作量分布数据及第(4)步估算的项目总工作量，计算：每个阶段的工作量、每个工种的工作量
(6)WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度;WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。
(7)根据历史的类似项目的数据及估算人的经验估计所有活动的工作量，可以采用经验法。
(8)汇总得到：每个阶段的工作量、每个工种的工作量、项目的总工作量。
(9)与第(4)、(5)步得出的工作量进行比较印证，如果偏差不大，则以第(7)步的结果为准，如果偏差比较大，要仔细分析原因，可能的原因举例如下：
类似项目的生产率数据不适合本项目;
WBS分解的颗粒度不够详细;
估算专家的经验不适合本项目;
具体任务的估计不合理;
针对原因，对估算的结果进行调整，使其趋向合理。
其他说明：
在该场景下，对于项目的总工作量有2个结果或者多个结果，并且采用2种方法都得到了每个阶段、每个工种的工作量、项目的总工作量，可以从上述的3个维度对这些结果进行互相印证，以发现估算过程中的不合理之处，是估计更加合理。
回复 34# Jackc
引入多元线性回归方程是为了充分利用以往项目采集的数据，而且随着项目的积累，不断递归，方程会越接近真实值。统计还可以分析条件因子对项目的影响指标。
只是设定系数的话这个系数设置的合理不合理也无从知道，只能在项目后期才能判断所有系数的总体是否合理，差距多大。
回归方程现在也不是太大问题，手工不太可能，但现在很多统计软件只要输入数据就能导出了
最大的问题是历史数据可能采集不全。
这每周一问 都快一个月了不换点新的问题！~！！！
这每周一问 都快一个月了不换点新的问题！~！！！
这每周一问 都快一个月了不换点新的问题！~！！！
这每周一问 都快一个月了不换点新的问题！~！！！
这每周一问 都快一个月了不换点新的问题！~！！！
这每周一问 都快一个月了不换点新的问题！~！！！
我觉得就算你预估好了工作量，但在实际工作中会增加额外的工作量，所以要尽量放宽时间
