##
###
外包项目测试工作量评估指南
1、目的
编写本指导书的目的旨在为我公司进行测试外包服务工作进行指导，帮助项目经理和相关人员编写测试方案、评估工作量、制定测试计划和测试策略等，以尽量减小项目工作量评估上的风险。
2、适用范围和对象
本指南的使用范围是对于测试外包服务项目前期做整体的测试方案时，需要对工作量进行评估的项目经理、测试专家参考的文档。
3、工作量评估原则
一个特定项目需要的工作量依赖于很多变量。包括：组织文化或者组织的“测试程度度”、被测试项目的软件复杂度、需要测试的范围、执行测试的个体的技能水平以及承担测试工作的测试组织的类型。不过，就算给出影响工作量的变量也不能真正反映出实际付出的工作量，因为每个项目都是不同的。
对于测试项目评估，在评估工作量时，从下面几点进行把握：
1、工作量评估是建立在商务沟通的基础之上的，客户比我们更了解系统；
2、工作量评估采用的任何方法都只是一个估计，所以风险因素是要考虑的；
3、工作量评估必须经过领导、专家组组成的小组的评审。
4、外包测试项目
根据外包测试项目主要有两种方式，一种是on-site，称为离岸外包，另一种是off-site是在公司内部做。不管是以那种方式，都需要对工作量进行全面的评估，而对于人力外包的项目则不需要工作量评估。由于IT系统项目实施是智力型密级行业，到目前为止，还没有一套科学有效、准确的评估方法，尤其是对于我们还不熟悉的行业，所以我们根据搜集到的资料以及我们的项目经验，整理出本文的几种方法，作为参考。
5、几种方法的对比
6、开发比例法
这个方法的基本前提是测试工作量依赖于开发周期/开发工作量。不管开发团队依据何种方式评估研发的工作量，我们测试团队可以根据研发团队的研发周期，确定大致的测试工作量。
通过下面的方式获得开发周期/开发工作量：
A. 通过商务沟通或技术沟通获得研发的进度表或研发周期；
B. 获得客户计划的整个项目的时间；
C. 根据研发工作量通过参考下面的表格估计工作量。
在评估需要的工作量以及相应的人员配置时，也要参考一下研发人员和测试人员的比例，如果测试团队在项目需求阶段就进入，则通过3：2、3：1等这样的比例估计需要投入的测试人员，这个比例没有一定的约束，主要根据系统对错误的容忍度，例如，医疗设备系统或飞机控制系统不能容忍错误，而银行涉及到重大财产安全则应该也不能容忍大的错误存在。评估时，这也是需要考虑的一个方面。
表1：测试各阶段比例估算
| 单元测试结果审核 |
集成测试 |
系统功能测试 |
系统性能测试 |
系统验收测试 |
所占百分比合计 |
| 2%~5% |
8%~11% |
18%~24% |
8%~15% |
3%~5% |
39%~60% |
|
|
9%~12% |
18%~24% |
8%~15% |
3%~5% |
38%~56% |
|
|
|
22%~28% |
8%~15% |
3%~5% |
33%~48% |
|
|
|
|
14%~20% |
12%~20% |
26%~40% |
|
|
|
|
|
15%~24% |
15%~24% |
|
|
|
|
15%~21% |
|
15%~21% |
注：灰色背景表示不进行测试测试。
如果公司没有被评估项目所属的行业的项目经验，则应该在所占百分比基础上增加5%~10%的风险工作量。
上面表格中前三行我们所做的系统验收测试活动为辅助验收测试活动，即有辅助客户完成验收测试。而后面只有两行则验收测试则可以作为一个独立的测试，客户参与人员很少，所以需要更多的工作量，可以根据客户的实际情况进行相应调整。
外包项目测试工作量评估指南
发表于：2008-2-20 17:36 作者：manok 来源：manok的博客
字体：大 中 小 | 上一篇 | 下一篇 |我要投稿 | 推荐标签：
7、项目经验类比法
根据公司以前所做的相似项目，主要在项目性质，领域，规模上考虑，所积累的经验或历史数据来估算工作量。项目经验类比法估计结果的精确度取决于对历史项目我们所收集数据的完整性和准确度。因此，项目经验类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。
主要从下面几个方面借鉴原项目情况：
1、项目所属的行业。不同的行业，在类比时要考虑差异性。有无行业经验是需要考虑的。该考虑要体现在工作量中，但是不能体现方案中。
2、项目的架构、规模、包括研发、测试工作量、代码行数等。这些数据对于评估可参考性比较强，注意项目实施中这些数据的收集。逐渐提高测试中的数据统计，提高我们测试能力的成熟度。
3、用户需求的数量。这个通过对比用户需求，大致估计系统特点、功能复杂程度，有无新技术应用等，这些数据可用于对比。
4、开展的测试活动。注意在原项目所进行的测试活动，与当前项目所进行的测试活动，再借鉴上面开发时间百分比法。
5、当时有无项目经验。原项目是否是新开拓的领域，则当时付出的工作量肯定会多一些，当前项目与原项目为同一个行业领域，则会减少一些工作量。
6、参与人员的情况。当前可参加到项目组人员情况与原项目人员情况进行对比。测试工程师以及业务分析师的项目经验是需要考虑的因素之一。
7、客户的情况，例如对系统质量要求、重视的程度。客户如果对质量很重视，实施质量管理规范，则可能对研发团队要求也高，这样系统交付质量可能会高一些；
8、项目系统使用对象。项目使用对象是需要考虑的，例如使用者对计算机的熟悉程度。系统是客户内部使用，还是面对Internet用户，这样对系统的安全性要求程度不同。
9、研发公司的情况。研发公司是否为知名公司，其研发能力的成熟度会高一些，对项目质量要求也可能高一些。该公司在行业中的做系统的名誉、口碑如何，也可以参考。
评估流程可参考如下：
1、在公司知识库中搜索相似项目，获得相似项目的信息；
2、把当前项目与相似项目进行对比，找出差异性，可参考上面对比数据；
3、对差异性进行分析，找出当前项目的特点；
4、对当前项目进行评估，没有的测试阶段评估方法可参考其他的评估方法；
5、最后统计出总的工作量，请相关的领导、项目经理、测试专家参与讨论，确定下最后的工作量。
8、WBS法
WBS（work breakdown structure）估算法。将项目或产品分解为具体的工作，然后分别对各个工作进行时间估算，最终求和统计得出项目或产品的测试工作量。
在工作拆分的原则应该是尽量把工作拆分为可以用小时或人/日度量、可以安排给一个测试工程师完成、且可以有交付物的工作。
在评估时，可以参考一下研发规模。例如代码行数（LOC）、等价的代码行数、功能点。
在评估中根据我们需要进行的测试活动，把每个测试活动进行拆分，同时把测试需求、测试用例、测试用例执行、轮次、缺陷修复等都进行拆分，评估每个活动需要的工作量。
这种评估的输入是需要客户的需求规格说明书的，且需要该文档描述用户需求比较详尽、全面，才能比较准确的评估所需要的工作量。对需求规格说明书中的功能需求和非功能需求进行分解，可以通过一条或多条测试需求来描述。
单元测试结果审核评估流程：
1、如果有系统详细设计说明书，则依据详细说明书中划分的模块，来计算划分的单元模块数量；如果没有该文档，是否可通过其他文档估算单元模块的数量；
2、确定单元测试审核中每个活动的工作量，例如，文档审核、测试用例审核，测试结果审查、缺陷报告审查、如果需要单元抽测，则需要单独计算工作量。
表2：单元测试结果审核评估表
产品集成测试评估流程：
1、把整个系统分解成子系统，确定每个子系统的接口数量。对于如何确定接口，主要根据子系统是否与其他子系统存在输入/输出数据而确定。
2、对每两个子系统之间有接口的子系统进行评估，需要构造多少测试用例覆盖接口，也要考虑接口之间的测试方案，如何构造测试数据，如何满足集成测试环境等。
3、需要考虑整个集成测试的所用的工作量，可以参考上面集成测试大约占整个测试的工作量的比例。
表3：集成测试工作量评估表
系统功能测试评估流程：
1、把整个系统中的各子系统分解成功能点，在各功能点上确定操作数量，确定功能点的口径，例如把下一个订单做一笔交易，做一次交易历史数据的查询作为一个功能点，即功能点应该是系统中独立的能够实现某个具体功能的一系列操作。在具体功能点中时，需要考虑功能点对应的操作数量，例如交易类型、查询中的升序、降序，都视作一个操作。把功能点和操作数量累计出来，形成一个功能点的需求数。
2、统计出所有的需求点后为整个系统中的功能需求总数。再考虑测试中具体的方案的工作量，是否考虑自动化测试、是否需要构造大量基础数据等。
3、需要考虑整个系统功能测试所用的工作量，可以参考上面系统测试大约占整个测试的工作量的比例。
表4：系统功能测试评估表
系统性能测试评估流程：
1、把整个系统中的性能需求点整理出来，注意我们性能测试包括的范围是功能测试之外的所有测试活动；
2、评估每个性能点需要的工时，形成整个系统性能测试的总工时。
表5：系统性能测试评估表
UAT测试评估流程：
1、在商务沟通阶段，尽量获得客户对UAT的期望，由客户来实施，还是我们协助来实施UAT测试；
2、根据客户希望我们测试团队所做的工作，确定大致的工作量。一般应该是我们协助进行UAT测试，大概需要几位测试工程师进行支持即可。根据客户期望的UAT时间，来确定我们测试团队所付出的工作量。
9、Delphi法
Delphi法是最流行的专家评估技术，在没有历史项目数据的情况下，这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种相关经验人的参与，互相说服对方。
Delphi法的评估步骤是：
1、项目协调人向各测试专家和项目经理介绍项目规格和估计表格；
2、项目协调人召集小组会，各测试专家和项目经理讨论与规模相关的因素；
3、各测试专家匿名填写迭代表格；
4、项目协调人整理出一个估计总结，以迭代表的形式返回测试专家；
5、项目协调人召集小组会，讨论较大的估计差异；
6、测试专家复查估计总结并在迭代表上提交另一个匿名估计；
7、重复4-6， 直到达到一个最低和最高估计的基本一致。