外包项目测试工做量评估指南&外包项目测试验收流程

 

 

 

 ##php

 

###html

外包项目测试工做量评估指南

一、目的
        编写本指导书的目的旨在为我公司进行测试外包服务工做进行指导,帮助项目经理和相关人员编写测试方案、评估工做量、制定测试计划和测试策略等,以尽可能减少项目工做量评估上的风险。算法

二、适用范围和对象
        本指南的使用范围是对于测试外包服务项目前期作总体的测试方案时,须要对工做量进行评估的项目经理、测试专家参考的文档。安全

三、工做量评估原则
        一个特定项目须要的工做量依赖于不少变量。包括:组织文化或者组织的“测试程度度”、被测试项目的软件复杂度、须要测试的范围、执行测试的个体的技能水平以及承担测试工做的测试组织的类型。不过,就算给出影响工做量的变量也不能真正反映出实际付出的工做量,由于每一个项目都是不一样的。架构

        对于测试项目评估,在评估工做量时,从下面几点进行把握:ide

一、工做量评估是创建在商务沟通的基础之上的,客户比咱们更了解系统;性能

二、工做量评估采用的任何方法都只是一个估计,因此风险因素是要考虑的;单元测试

三、工做量评估必须通过领导、专家组组成的小组的评审。测试

四、外包测试项目
        根据外包测试项目主要有两种方式,一种是on-site,称为离岸外包,另外一种是off-site是在公司内部作。不论是以那种方式,都须要对工做量进行全面的评估,而对于人力外包的项目则不须要工做量评估。因为IT系统项目实施是智力型密级行业,到目前为止,尚未一套科学有效、准确的评估方法,尤为是对于咱们还不熟悉的行业,因此咱们根据搜集到的资料以及咱们的项目经验,整理出本文的几种方法,做为参考。字体

五、几种方法的对比
           x

六、开发比例法

        这个方法的基本前提是测试工做量依赖于开发周期/开发工做量。无论开发团队依据何种方式评估研发的工做量,咱们测试团队能够根据研发团队的研发周期,肯定大体的测试工做量。

        经过下面的方式得到开发周期/开发工做量:

A.       经过商务沟通或技术沟通得到研发的进度表或研发周期;

B.       得到客户计划的整个项目的时间;

C.       根据研发工做量经过参考下面的表格估计工做量。

        在评估须要的工做量以及相应的人员配置时,也要参考一下研发人员和测试人员的比例,若是测试团队在项目需求阶段就进入,则经过3:二、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的博客

字体:   | 上一篇 | 下一篇 |我要投稿 | 推荐标签:

七、项目经验类比法
        根据公司之前所作的类似项目,主要在项目性质,领域,规模上考虑,所积累的经验或历史数据来估算工做量。项目经验类比法估计结果的精确度取决于对历史项目咱们所收集数据的完整性和准确度。所以,项目经验类比法的前提条件之一是组织创建起较好的项目后评价与分析机制,对历史项目的数据分析是可信赖的。

        主要从下面几个方面借鉴原项目状况:

        一、项目所属的行业。不一样的行业,在类比时要考虑差别性。有无行业经验是须要考虑的。该考虑要体如今工做量中,可是不能体现方案中。

        二、项目的架构、规模、包括研发、测试工做量、代码行数等。这些数据对于评估可参考性比较强,注意项目实施中这些数据的收集。逐渐提升测试中的数据统计,提升咱们测试能力的成熟度。

        三、用户需求的数量。这个经过对比用户需求,大体估计系统特色、功能复杂程度,有无新技术应用等,这些数据可用于对比。

        四、开展的测试活动。注意在原项目所进行的测试活动,与当前项目所进行的测试活动,再借鉴上面开发时间百分比法。

        五、当时有无项目经验。原项目是不是新开拓的领域,则当时付出的工做量确定会多一些,当前项目与原项目为同一个行业领域,则会减小一些工做量。

        六、参与人员的状况。当前可参加到项目组人员状况与原项目人员状况进行对比。测试工程师以及业务分析师的项目经验是须要考虑的因素之一。

        七、客户的状况,例如对系统质量要求、重视的程度。客户若是对质量很重视,实施质量管理规范,则可能对研发团队要求也高,这样系统交付质量可能会高一些;

        八、项目系统使用对象。项目使用对象是须要考虑的,例如使用者对计算机的熟悉程度。系统是客户内部使用,仍是面对Internet用户,这样对系统的安全性要求程度不一样。 

        九、研发公司的状况。研发公司是否为知名公司,其研发能力的成熟度会高一些,对项目质量要求也可能高一些。该公司在行业中的作系统的名誉、口碑如何,也能够参考。

        评估流程可参考以下:

        一、在公司知识库中搜索类似项目,得到类似项目的信息;

        二、把当前项目与类似项目进行对比,找出差别性,可参考上面对比数据;

        三、对差别性进行分析,找出当前项目的特色;

        四、对当前项目进行评估,没有的测试阶段评估方法可参考其余的评估方法;

        五、最后统计出总的工做量,请相关的领导、项目经理、测试专家参与讨论,肯定下最后的工做量。

八、WBS法
        WBS(work breakdown structure)估算法。将项目或产品分解为具体的工做,而后分别对各个工做进行时间估算,最终求和统计得出项目或产品的测试工做量。

        在工做拆分的原则应该是尽可能把工做拆分为能够用小时或人/日度量、能够安排给一个测试工程师完成、且能够有交付物的工做。

        在评估时,能够参考一下研发规模。例如代码行数(LOC)、等价的代码行数、功能点。

        在评估中根据咱们须要进行的测试活动,把每一个测试活动进行拆分,同时把测试需求、测试用例、测试用例执行、轮次、缺陷修复等都进行拆分,评估每一个活动须要的工做量。

        这种评估的输入是须要客户的需求规格说明书的,且须要该文档描述用户需求比较详尽、全面,才能比较准确的评估所须要的工做量。对需求规格说明书中的功能需求和非功能需求进行分解,能够经过一条或多条测试需求来描述。

        单元测试结果审核评估流程:

        一、若是有系统详细设计说明书,则依据详细说明书中划分的模块,来计算划分的单元模块数量;若是没有该文档,是否可经过其余文档估算单元模块的数量;

        二、肯定单元测试审核中每一个活动的工做量,例如,文档审核、测试用例审核,测试结果审查、缺陷报告审查、若是须要单元抽测,则须要单独计算工做量。

表2:单元测试结果审核评估表

       dddd

产品集成测试评估流程:

        一、把整个系统分解成子系统,肯定每一个子系统的接口数量。对于如何肯定接口,主要根据子系统是否与其余子系统存在输入/输出数据而肯定。

        二、对每两个子系统之间有接口的子系统进行评估,须要构造多少测试用例覆盖接口,也要考虑接口之间的测试方案,如何构造测试数据,如何知足集成测试环境等。

        三、须要考虑整个集成测试的所用的工做量,能够参考上面集成测试大约占整个测试的工做量的比例。

                   表3:集成测试工做量评估表
          ddd

系统功能测试评估流程:

        一、把整个系统中的各子系统分解成功能点,在各功能点上肯定操做数量,肯定功能点的口径,例如把下一个订单作一笔交易,作一次交易历史数据的查询做为一个功能点,即功能点应该是系统中独立的可以实现某个具体功能的一系列操做。在具体功能点中时,须要考虑功能点对应的操做数量,例如交易类型、查询中的升序、降序,都视做一个操做。把功能点和操做数量累计出来,造成一个功能点的需求数。

        二、统计出全部的需求点后为整个系统中的功能需求总数。再考虑测试中具体的方案的工做量,是否考虑自动化测试、是否须要构造大量基础数据等。

        三、须要考虑整个系统功能测试所用的工做量,能够参考上面系统测试大约占整个测试的工做量的比例。

                    表4:系统功能测试评估表

           d

系统性能测试评估流程:

        一、把整个系统中的性能需求点整理出来,注意咱们性能测试包括的范围是功能测试以外的全部测试活动;

        二、评估每一个性能点须要的工时,造成整个系统性能测试的总工时。

                      表5:系统性能测试评估表

            dd

        UAT测试评估流程:

        一、在商务沟通阶段,尽可能得到客户对UAT的指望,由客户来实施,仍是咱们协助来实施UAT测试;

        二、根据客户但愿咱们测试团队所作的工做,肯定大体的工做量。通常应该是咱们协助进行UAT测试,大概须要几位测试工程师进行支持便可。根据客户指望的UAT时间,来肯定咱们测试团队所付出的工做量。

九、Delphi法
        Delphi法是最流行的专家评估技术,在没有历史项目数据的状况下,这种方式能够减轻估算的误差。Delphi法鼓励参加者就问题相互讨论。这个技术,要求有多种相关经验人的参与,互相说服对方。
        Delphi法的评估步骤是:
        一、项目协调人向各测试专家和项目经理介绍项目规格和估计表格;
        二、项目协调人召集小组会,各测试专家和项目经理讨论与规模相关的因素;
        三、各测试专家匿名填写迭表明格;
        四、项目协调人整理出一个估计总结,以迭表明的形式返回测试专家;
        五、项目协调人召集小组会,讨论较大的估计差别;
        六、测试专家复查估计总结并在迭表明上提交另外一个匿名估计;
        七、重复4-6, 直到达到一个最低和最高估计的基本一致。

相关文章
相关标签/搜索