测试过程估算Word文档格式.docx

1、可调整性：如果截止日期和资源的限制是不能变动的话，估算必须适应项目的真实情况。估算术语如表1所示。表1 测试过程估算术语术语解释项目为完成某一独特的产品或服务所做的一次性努力测试子项目测试团队为项目提供的项目子服务项目日程表（工作结构分解）将项目的阶段、活动和任务及其资源和依赖关系进行的层次分解2 分布解决 工作结构分解（WBS）是一个非常好的估算工具。WBS是项目（测试工作量）的阶段、活动、和任务的层次分解。测试项目需要包括以下阶段：策划;人员安排（适当的话）；测试环境获取和配置；测试开发；测试执行（包括：发现缺陷、缺陷纠正和再测试） 那些具有编程工作背景的人员可能对“分布解决”比较熟悉。一

2、旦判断出项目的阶段，将其分解为更小的任务单元，直到每个任务单元小到每个人员可以在一定的时间段（一般是15个工作日）内完成。这样在了解每个任务多久（时长）和多少工作（工作量）的基础上完成估算工作。因为所有的工作量和时长估算就从低层次的分解任务的估算中得到了。这种估算方法叫“自底向上估算法”。 对项目周期内的所有任务什么时候可以完成的度量有助于确保每个任务产生一个关键的可交付物，或是起码是一个草稿，亦或是可度量的关键交付物的组件。这些交付物对测试组（测试内部）来讲，可以是测试用例、测试工具或测试数据。这些可以在测试组内进行交付，比如第一次完整的特性测试发布、单元测试结果或是测试环境配置。可交付物对

3、项目（测试外部）来讲，可以是测试计划、缺陷报告系统和测试结果。这些可交付物通常是作为后续任务的输入。3 整合和估算 工作任务的分解可以单独进行，但是正确的预测任务的执行周期需要收集技术团队参与人员的意见。使用整个团队的知识可以获取更多的、更广泛的经验。整个团队参与估算使得生成的团队日志更有效。同时，这样也可以建立团队对估算的承诺。 在团队估算中有三个主要的技术：（1）Delphic法。每个团队成员都对任务执行周期进行估算。在估算评审中，每个任务的最高和最低估算值的估算者解释他们做出该估算值的解释。最低值估算者的可能指出最优化的方法用于加速任务的执行，比如使用随机数字生成器、电子数据表和剪切-粘

4、贴去生成大量的测试数据替代手工输入。最高值估算者的可能指出最有可能造成延迟的情况，比如从客户那里获取进口硬件原型的过程。估算过程重复进行两次，每次都将最高值和最低值的情况都考虑进去。这样每个任务的最后一轮估算的平均值就是该任务的估算值。（2）三点估算法。每个参与估算的人员不是进行一个估算而是三个。第一个是最佳情况估算，即，假设所有的情况都正常进行。第二个是最差情况估算，即，假设所有坏的情况都出现。第三个是期望估算。期望估算的平均值即是最终估算值，但是最佳情况和最差情况的估算都被文档化的记录用于理解估算的准确度，同时作为测试计划和风险管理的输入。（3）宽带技术，上面两种情况的结合。团队成员给出三

5、个数字。每个任务三种情况的最低和最高估算人员解释他们的估算。这种过程重复进行两次。期望估算的平均值即是最终估算值。最佳情况和最差情况估算的平均值就是每个任务的时间范围。 Delphic法可以提醒估算人员去预测项目的前景，例如风险。随着项目的进行，估算人员会发现一些可能影响估算值的情况。变更随时会发生。一般情况下，新的技术第一次不能正常工作。所以，在时间表上增加一些突发事件和宽裕时间是个不错的方法。这个值是依据以往的项目估算经验以及初识估算与最终时间的远近进行判断，一般情况下20%是个比较经典的建议值。4 依赖关系 也许有的测试经理在进行测试计划时希望使用足够多的资源开展工作，但是资源不是进度唯

6、一限制因素。任务之间是有依赖性的：后置任务不能开始，至少是不能完成，直到前置任务完成。 这样某些可交付物不能开始或是结束直到其他可交付物完成。依赖关系经常是由于可交付物的关系形成的。例如，你可能在测试开发之前需要一份完整的、批准的测试计划。这是内部测试团队的可交付物，这种依赖关系称作完成-开始依赖。再譬如，假设系统测试需要持续三周，但是需要在新的特性开发和最后较严重的测试变更完成后进行。这种依赖关系称作完成-完成依赖。 测试经理可以使用不同方法识别测试活动的依赖关系。对于小项目，测试经理可以让每个项目成员自己处理这些关系并且将数据直接输入项目管理工具中。 当所有依赖关系识别完全后，测试经理需要

7、将这些信息输入项目管理工具中了，因为再接下来已不是查看关键路径。关键路径是项目中的任务序列，任何关键路径上的任务的延迟将直接影响项目的预期完成时间。近关键路径是指那些产生12天的延迟不会对影响项目进度，但是如果产生重大延迟的话就会影响项目进度的任务。影响项目阶段的入口或出口准则的任务总是在项目关键路径上，因为许多依赖关系都是在项目阶段的开始或是结束日期点。外部的依赖关系是另一种经常引起项目延迟的来源。分析关键路径用于识别那些对项目延迟具有高风险级别的任务。这些任务需要在整个项目周期内进行监控。5 测试活动的投入 作为团队估算活动的一部分，项目任务需要分配资源（一些项目经理在进行估算会议之前就提

8、前确定了部分任务的资源）。准确的资源需求是以项目为目标的，但是资源经常划分为以下几类：（1） 人员；（2） 测试环境；（3） 测试工具和测试文档。 人力资源包括测试工程师和测试技术人员，同样也包括外部测试资源，比如测试实验室和专业测试团队。要知道使用一个技术欠佳的人员去完成一份特定的任务的时候，由于其欠缺特定的技术有可能增加实际的工作量和时间，所以需要根据人员的安排调整估算。同样，需要清楚了解到人员的对既定任务和工具的技能决定了估算的准确度。除非对每个日程的任务都有至少一名人员了解如何去执行该任务，否则估算可能会由于有技能的人员不可利用造成项目延迟。如果测试经理知道人手不够或是在部分领域没有有

9、技能的人员，测试经理需要与其项目经理进行沟通雇佣一名新的测试人员，给其提供雇佣合同或是减少测试任务。 测试环境资源包括硬件、软件、网络、设备等等。对于非常重要的环境资源等需要进行明确，比如非常贵重或是有较长交货期的物品。 测试工具和测试文档包括客户测试数据、测试用例、测试脚本（手动或自动测试）和测试运行工具，但不包括商业测试工具。在许多情况下，测试工具和测试文件都是测试早期阶段的可交付物。6 估算测试执行 测试执行阶段的估算经常是特别困难的。完成测试的执行需要花费多长时间关系到以下两个问题：每次至少需要花费多长时间去执行每个计划好的测试（脚本或试探性的测试）；何时能发现全部的缺陷，并修正缺陷和

10、验证缺陷修正。 为了解决第一个问题，在估算测试时间时，测试经理需要明确以下三个事情：你的测试工作策划了多少人时？假设你对项目每个的测试用例所执行的时间都进行了策划，那么你在项目上需要花费280人时的工作量；你每个星期有多少人工工时可以利用？假设项目的测试团队由7个人员，而且假设他们每个星期可以工作40小时。那么该团队就有280个人时可以利用;每个测试测试人员执行测试用例花费时间比例是什么（每个星期测试人员经常需要参加会议、确认缺陷关闭、更新测试脚本、读邮件，以及其它和计划的测试执行没有关系的事情）？假设项目的所有测试人员花费50%的时间在测试上面，这样改团队每个星期就有140人时与测试相关。

11、这样的话，项目团队就需要用两周的时间将所有的测试活动执行一遍。 第二个比较困难的问题是：需要花费多长时间发现所有的缺陷？Stephen Kan和Pankoj Jalote 分别在Metrics and Models in Software Quality Engineering和CMM in Practice中均提出缺陷移除模型。下面内容是一个简化版的该模型。 首先，我们需要预测缺陷总量。功能点和代码行数会作为度量数据进行引用，但是这样可能超出了我们的过程能力。假设你已经估算好了项目的总工作量（人时）。如果这样，我们可以去查验以往项目对工作量（人时）的估算以及最终发现的缺陷数量。如果没有估算项

12、目总工作量的话，也许我们还有其他的历史数据可以利用，比如说每个特性或程序员发现的平均缺陷数量。这种方法可以建立一个简单的数学模型使用电子数据表（使用一个或两个在估算阶段使用的矩阵）去计算最终测试中发现的缺陷总数。 其次，假定一个缺陷总数，我们需要花费多长时间去发现他们？使用历史数据我们可以计算出每个星期在系统测试中发现的现存的缺陷的比例。那么，我们需要花费多长时间修订这些缺陷以及验证缺陷的关闭呢？如果基于历史数据，每周发现缺陷的关闭率是什么？当我们根据比例得出缺陷数量，我们需要关注测试和开发团队的能力。如果项目（7个测试人员）的缺陷发现率的峰值时200 bug/week。那么，将这些信息纳入到

13、电子数据表中，建立一个模型去计算累计的缺陷开启和关闭数量。 如果项目的测试经理建立了缺陷移除模型，其预计的缺陷发现和修订率如图1中所示。如果拥有同类型项目的历史数据越多，那么这些预测就将越准确。7 影响测试估算的因素 系统工程（包括测试）是一个复杂的、高风险的、人员参与的工作。因此，将好的估算技术与对影响工作量、时间、依赖关系和资源的因素的理解联系起来非常重要。这些因素，诸如过程、工具、测试环境、技巧、团队组成和管理，可以拖滞或加速项目进度。然而其他的情况若出现则仅仅是延迟项目。 当进行一个测试的估算时，测试和那些协助进行测试估算的人员必须考虑上述因素对测试估算结果造成何种影响。忽略任何一个因

14、素都有可能将一个可行的估算结果变成不可行。 假设你作为测试经理向管理层提供一份可靠的、可控的日程安排，那么在对测试任务进行裁剪时，需要明白可做的事情是放松测试的入口准则。通常情况下，入口准则这样被定义：下一个阶段开始前必须完成上一个阶段的任务。但是假设你放弃系统测试的“特性完成”的入口标准而去接受“差不多完成”的发布。但是人们必须了解到重叠部分会增加系统质量的风险。亦或是测试一个未准备好的系统是不充分的，这样会导致不彻底的测试。 针对管理层对时间的要求的情况，另外一种解决办法是增加人员。假设测试和开发人员可以增加的话，你可以提前一周进行测试并提高到两倍的缺陷解决率。在上面的假设案例中，这样可以

15、将测试估算时间提前五周。这样，3月26日是一个新的截止日期，提前了40%。但是人力资源成本就大大增加了，也许是成倍的增加。而且，你也不能确保一定能够招到新人同时确保他们可以积极的参与到项目中去。 针对以上困难情况，经常被建议的方法是专断的减少测试时间。然而减少测试是压缩日程中最有风险的策略。就日程而言，如果系统在截止日期不能正常工作的话会怎样？就预算而言，这样刚好满足截止时间的要求是在人员日均成本高的情况下形成的。就产品质量而言，缺陷将在测试后期发现，这样就没有时间去解决它们。这样你就会丢弃有缺陷的功能。而这时你已经花费了大部分的时间和成本去实现这些特性。 如果你想冒质量的风险，你需要时刻关注

16、那些风险。这样做的话，需要小心考虑减少测试工作量而带来的风险。一个选项是减少测试的覆盖范围。识别有低级别的风险的测试范围，同时或者减少覆盖范围或是那个范围的测试，这时你只能使用其他测试来代替它们。另外一个选择是减少测试的内容。在高风险范围内识别最低的风险，同时在测试方法上确定一个平衡（宽度而不是深度）。这样你可以推迟一些自动化测试或者通过外部资源（尤其是测试实验室）来减少测试环境的费用。不论你采用哪种技术，将创造性的计划以一种前瞻的方式去减少测试要求的时间。 相对于减少测试内容，你可以减少产品的特性。对于假设的案例来讲，假设你放弃相当大一部分的功能。这样可以减少25%的测试工作量。所以根据开发

17、的工作量计算，测试可以提前完成，但是同样发布许多小的版本增加产品衰退相关的质量风险。因此，这些特性必须在下一个正规版本中进行实现。 当然，在测试过程中以下2点也是建议重点控制的内容：对于上述情况还有其他方法可以解决时间压力。比如周末加班。如果团队可以一周7天都工作的话，日程可以锐减40%。但是，这种情况很少出现在估算的时间中，相反地会出现在落后于某个时间而要赶上某个时间点的情况下会出现很多;另一个非常有风险的技术是为测试人员设定一个“伸展目标”式的非常紧凑的日程。为了达到有一半的机会实现项目按期交付，每个任务（特别是关键路径和近关键路径任务）必须达到有一半的机会按期解决。否则，进度会越来越落后。“伸展目标”是个失败的策略。参考文献：1 郑文强、马均飞.软件测试管理M.北京：电子工业出版社，2010. 2 马均飞、郑文强.软件测试管理M.北京：电子工业出版社,2011. 3 正确估算软件测试周期EB/OL. 4 常规的估算测试工作量的方法如何估算测试工作量EB/OL.