标签：分析 水平 UI 1.5 分时 接下来 工作量 快速 功能
实际项目测试中，工作量评估会受很多因素的影响，开发的实现方案，开发的能力水平，测试范围的评估，测试类型的选择，测试深度，是否需要增加专项测试，质量要求，等都会产生干扰，因此准确评估工作量确实很难。 尤其是当功能还没有开发的时候去评估工作量，不确定性更大，开发是重构代码还是微调，是否需要做性能评测等等都会对最终工作量评估产生很大影响。
那么怎么做才能更加准确的评估测试工作量呢？
首先我们先要了解测试工作量都包含哪些部分，测试工作量是对测试过程时间消耗的评估，那么测试过程都包含哪些呢？ 我们可以从测试流程角度来分析，首先是需求理解，然后是和开发的技术沟通测试范围评估，测试用例的编写，专项测试方案准备，测试环境/测试数据准备，测试用例执行，专项测试执行，回归用例执行，上报bug以及bug验证，以及上线前的测试验证。那么测试工作量就应该是以上过程时间消耗的总和。一眼望去，过程好多，每个过程貌似都又有不确定性，例如bug上报和验证的时间直接受bug数量和开发修改bug改动大小的影响，用例执行不同功能的case执行时间可能又是不一样的，万一遇到阻塞问题，时间就更没法评估了。 这些过程并不是每个版本都会。
接下来我们逐一来分析一下每个过程如何精准评估工作量：
需求理解
需求理解一般是通过需求文档或需求讨论会来完成，这个过程通常会比较提前，例如需求文档都会提前发出事先可以去熟悉，工作量评估一般不包含这部分内容。
技术细节了解
技术细节的了解取决于了解的程度，这部分可能更多的需要根据以往的经验来评估，所以平时对于技术细节了解时间的留意很重要。
用例设计
这部分应该会比较耗时，时间的评估首先要评估用例的数量，评估用例的数量首先要把测试对象按功能切分，再由功能切分成测试点，针对每个测试点去评估用例数量。优秀的测试工程师对每个测试点大概有多少条用例需要做到心中有数，例如测试一个按钮的用例条数，下拉菜单的用例条数。这部分比较依赖平时的积累，能否把常见的测试点总结成公共用例，例如http的公共用例，地址栏公共用例，菜单的公共用例，如果公共用例比较齐备，会比较容易评估用例条数，而且也可以大大缩短用例设计的时间。用例设计过程中或多或少的会出现需求不清需要沟通确认，技术细节不了解需要沟通或调研的事情，这部分也需要根据之前的经验来判断。
专项测试方案设计
首先要评估是否需要进行专项测试，如果需要则要评估专项测试方案修改已有的还是要从头来设计。 一般情况下一份专项测试方案设计时间不超过4h。如果涉及到工具的开发则需要另行评估。
测试环境/测试数据准备
首先要评估是否需要这方面的准备，这个过程往往会比较忽略，测试过程中再去准备回比较被动和耗时，测试环境和测试数据往往是由测试开发或者开发准备，作为测试工程师重要的是及时提出需求来，并及时和开发方沟通工作量和完成时间点。
用例执行
这部分应该是整个测试过程最耗时的部分，用例执行的时间应该依赖于用例的数量和用例执行速度，之前我们已经评估了用例的数量，如何评估用例执行速度呢？首先不同功能的用例执行的难以程度不一样，纯黑盒的用例一般执行速度回比较快，例如UI的检查。偏逻辑层面的用例执行起来会慢一些，需要准备环境，或者通过工具验证结果等等。测试工程师需要有意识的去统计不同难度用例的执行时间，例如黑盒偏UI层面的用例一个合格的测试工程师一天可以执行200-300条用例等。偏逻辑验证的大概每天可以执行100条，大量需要环境准备和数据准备的每天30-50条等。
专项测试实施
专项测试每轮的测试时间相对固定，执行一次大概1小时，2小时等等，比较难评估的是如果测试出现问题开发可能会调优，执行多少次才能达到预期可能不太能评估。从以往经验来看一般2-3次基本可以完成，专项测试执行的时间可以按照两倍或者三倍时间去评估。
上报bug和验证bug的时间
这部分时间是最难评估的，无法按照数量来评估，bug都是在测试执行过程中产生的，一般会通过用例执行时间乘以一个系数来评估，这部分比较靠以往版本的经验，以往bug比较多或者修改起来连带bug比较多可以适当提高这个系数比例。例如项目里开发bug比较多，我们可以把这个系数提高到0.3，如果用例执行时间是3天，bug相关的处理时间可以按照一天计算。
测试工作量的评估是一个通过一定方法和测试经验不断积累来优化的过程，以上是小编我根据自己的总结和测试经验形成的方法，不同的项目不同的团队状态工作量评估的方法可能有比较大的差别，但要找到适合自己项目的评估方法需要大家不断的思考总结和积累经验。
软件测试qq群：507088
标签：分析 水平 UI 1.5 分时 接下来 工作量 快速 功能
原文地址：http://www.cnblogs.com/qq909283/p/6958496.html
