第一篇：测试工作量统计方法
测试工作量统计方法
摘要：针对在实际项目测试工作中的一个突出问题，即测试工作量的统计问题，笔者在实际工作中进行摸索和尝试。本文是对笔者测试工作量统计实践的总结。关键词：测试 工作量 统计 计算
工作量的统计，从小方面来说，对于个人工作总结、工作方法改进、个人能力的提高很有帮助；从大方面来说，会影响一个组织的策略，如测试团队、项目组、公司组织。假设过了一个月后，你无法清楚的说出自己这个月的主要工作是什么，每项工作任务的投入是多少，那么你就很难发现自己的工作方法是否存在不足，并进行改进。对于一个组织来说，他需要知道目前的人力配置是否合理，是否有富余人力，现有分工是否最佳。所以，他也需要对组织的人力使用情况进行统计并进行分析，为后续决策提供参考。
一、问题的提出
1.目前测试工作越来越受到公司的重视，已形成规模，参与测试工作的人越来越多，投入也越来越大。与之不协调的是没有一个配套的、较为合理的工作量统计方法。
2.原有的测试工作量计算方法，一般是把测试人员进入项目的时间与进入项目的人员数量相乘，得到项目测试的工作量。该计算方法由于计算方便，容易操作，深受众多项目的推崇。但是，随着测试在项目的重要性的加深，测试工作分工日益细化，测试资源强调有效重用，测试团队协作越来越强，使用这种方法已经不能满足测试工作量计算的需要了。3.上级领导不了解整个测试团队资源的使用情况。
4.测试团队负责人难于对项目测试任务实际执行过程产生的工作量、成本进行跟踪。5.项目组在考核绩效时，遗漏了部分测试人员的工作量。
二、基本思路
首先就任务类型的设置达成一致；其次从每日的工作量收集开始，将测试任务按照一定的类别进行分类；然后将工作量数据按照不同的需求进行统计，得出不同的统计表；最后对这些统计表的数据进行分析，得出需要的结论。
三、工作量数据采集、统计及分析 1.设置任务类型
设置任务类型，是每日工作量数据录入的前提。任务类型需要在整个测试团队内达成一致，这样大家有了相同的标准，得出的数据才具有统计的意义。
某公司的项目测试任务类型如下：
表一 测试任务类型分类
上面提到的测试任务类型，在实践中会根据项目实际需要进行调整。例如，新增“测试工具学习”任务类型等。
另外，在上述的任务类型中，有一项比较灵活的任务类型——沟通。有的团队认为沟通都是有目的、有目标的，是一个为完成具体测试任务所进行的中间活动，所以他们把沟通作为具体测试任务的一部分。也就是说，对于这样的团队，他们没有“沟通”这个任务类型。有的团队则认为将沟通的内容很难划清界限，为避免测试人员填写工作量时发生混淆，所以，将“沟通”作为独立的任务类型。笔者认为这属于任务类型定义问题，测试团队可以根据将已经存在的约定俗成进行设置，只要在整个团队内达成一致就可以的。2.记录工作量基础数据
这项工作由团队成员根据当天的工作任务完成情况进行记录。它是后续工作量统计的基础，所以要保证这项基础数据收集的准确性，切不可应付了事，最好能在当天下班前填写好当天工作量分配情况。
坚持记录时间需要很强的自我约束能力（Watts S.Humphrey 2001），所以每天填写工作量记录需要一定的坚持力。在填写工作量记录时，需要为每个任务选择相应的任务类型，填写工作任务持续时间。工作任务持续时间最好最长不超过4小时，这是为了避免填写的任务过粗，不利于发现工作过程中的问题。及时记录、数据准确，是这个环节工作的原则。某公司使用的工作量记录表格如下：
表二 工作量记录表格
3.统计本周团队的人力占用情况
这项工作主要统计测试团队所有成员在各个项目中的投入情况，或者说是项目对测试人员的人力占用情况，每周统计一次。通过对人力占用情况进行统计，测试团队负责人可以得到一份人力占用表。这份人力占用表的主要用途的有三个： 1)供测试团队负责人和上级领导使用，方便他们了解测试团队对项目的支持情况及项目占用测试资源的情况。
2)让上级领导间接了解测试团队的人员饱和度。如果测试团队负责人要申请新增测试资源时，将整个团队的历史人力占用表作为数据证据提供给上级领导，可以增强申请的说服力
3)提供给项目经理参考。避免项目经理在进行项目人员绩效考核时，遗漏了部分测试人员的工作量。
人力占用表，主要包括人员姓名、人员进入项目的名称、人员在项目的占用/投入情况、人员计划退出项目的时间、各项任务对应的部门目标等。
这项人力占用情况统计工作，笔者建议使用者在每周末进行。统计结束后，测试团队负责人将统计结果作为测试团队工作汇报的一部分提交上级领导。
某公司某一周测试团队人力占用情况如下：
表三 测试团队人力占用表
在上面的例子里，测试团队在项目1一共投入了B、C、D三个人，B、C成员是100%资源投入。因为项目后续工作安排未知，而B、C成员又属于项目1核心测试人员，因此这两名成员的退出时间未知。另外一个测试成员D因为不属于项目1的核心测试成员，所以他参与2个项目。同时因为项目2规模较小，所以成员D在项目2中投入20%的资源，在项目1中投入80%的资源。考虑到公司在2005年3月将要启动一个新项目，所以，笔者经过和项目1的项目经理协商后达成一致，计划成员D在2005年2月退出该项目，这样他在2005.3月将投入新启动的项目。
通过及时更新、跟踪这张表的数据，笔者对团队内测试人员的工作情况心中有数，并可根据公司业务发展、部门建设、人员发展需要，合理安排团队成员的工作。4.统计项目测试工作量投入情况
这项统计工作是基于每日工作量统计的基础上整理得到的。每周测试团队成员提交工作汇报时，会将本周的工作量数据整理后一起提交。测试团队负责人定期（每周或半个月）对团队成员提交的数据进行汇总，并整理到项目工作量投入表中。这就解决了在实际测试执行过程中，测试人员无法对测试工作量进行跟踪的问题。
笔者曾经碰到一个项目，该项目的测试计划只安排了1.5人日的工作量，但是实际上该项目在测试计划上总共投入了9人日的工作量。这么悬殊的差距，是由于什么原因导致的？经过分析，笔者发现是两个原因导致这个问题的发生：一是测试人员在填写每日工作量记录时，部分任务的“任务类型”选错了；二是该项目测试组长在估算测试工作量时，没有考虑到实际测试执行过程中也需要进行测试计划工作，如每次测试执行的计划、实际工作过程中的计划更新工作等。通过这次分析后，该项目的测试工作量没有再发生偏差率类似－500%这么大的偏差了（偏差率＝（计划值－实际值）/计划值*100%）。所以说，测试工作量的统计、分析可以帮助使用者发现一些问题，并改进使用者的工作。某公司某一项目的测试团队工作量投入情况如下：
表四 某项目测试工作量统计表 通过这张统计表格，读者可以很清楚的了解某个人的工作量投入情况，及具体测试任务使用的工作量情况。5.汇总项目测试数据，升级测试资产库
在项目关闭时，测试团队负责人把整个项目测试过程中产生的数据以及项目基础数据进行汇总。测试过程中产生的数据包括：测试工作量、测试投入成本，它的数据来源于表四；项目基础数据包括：项目规模、项目总成本、项目总工作量，这些数据是向项目经理获取的。这里提到的测试成本，是把每个测试人员的人力成本系数和工作量数据相乘得到的。所有相关人可以通过这张统计表了解项目组中测试占开发总工作量的比例，以及项目组用在测试上的开销情况。这项工作是测试团队资产沉淀的很重要的一项工作。主要用途是： 1)从项目角度对项目测试整体情况进行分析；
2)把测试团队所承接测试的项目进行纵向对比，总结共性，发现问题。
例如，笔者可以对这些项目的测试数据进行分析，得出测试工作量估算公式。再如，笔者曾经通过数据的对比，发现测试文档编写工作量占整个测试工作量的比例较大。通过进一步分析，发现测试用例的维护占用了测试设计很大一部分的工作量，从而笔者考虑在团队内改进测试用例管理方法。某公司两个项目的测试数据如下：
表五 某测试团队测试项目资产库——测试数据 参考项目背景，笔者对几个项目的测试数据进行分析后，得到了项目测试总人力成本的估算公式： 测试总人力成本＝20%×项目总人力成本
另外，通过把几个项目的各项测试类型所花费的工作量进行对比分析后，笔者得出各项测试任务的工作量相对于测试总工作量的分配比例。对于后续的项目，项目测试组长可以参考这个分配比例进行测试工作量的估算。
表六 某测试团队各项测试任务的工作量比例
当然了，上面的介绍的估算公式和工作量比例，只是适用于笔者所在的测试团队。不同测试团队、项目组、公司组织情况都不一样，这里介绍这个例子，目的只是说明测试工作量统计的一个用途。
四、小结
测试工作量的统计，是整个测试团队管理的基础。测试团队的管理、决策、策划等需要数据的支持，即用数据说话，所以，数据的收集、统计是很重要的。在本文中笔者主要介绍的是测试团队的工作量统计，但实际上这些方法不仅适用于测试团队，也适用于个人、项目团队或者整个公司组织。实施时只需要调整“任务类型”等与测试有关的属性，并做一定的扩展即可。本文使用的表格，笔者都是在excel中建立和维护的。在团队规模不是很大时，或者处于试用初期时，使用很方便、实施成本也低。但是如果团队规模较大，团队成员比较多，数据量较大的话，这种手工方式就显得有些力不从心了。读者可以自行开发一个工作量管理系统，使用数据库的方式来记录、分析这些数据。在使用初期可先实现每日工作量数据的录入，以及针对个人、项目、任务类型等属性的统计分析功能即可。
第二篇：工作量统计说明
工作量统计
1.为了确保正常的教学秩序，各系部应注意做好7、8节课的教学检查和管理，由于7、8节教师上课产生的教学管理人员加班补助根据实际发生可暂按一次1节课时量计入普通课一栏内（非教师系列按每次10元补助）；
2.军班任课老师工作量计算注意问题：
1）军班任课老师周六日上课的按上述规定办理，计入工作量统计表的普通课时栏内；周六日无课的教师执行校内作息时间安排休息日，工作量正常计算。
2）此前相关的其他规定与本规定有不一致之处的，一律按本规定执行。
3.本月补考工作量按实际发生统计，出题按每份试卷2课时计入普通课，监考按每次2课时计入普通课，辅导答疑由各系部自行统计（原则上最多不超过三次，每次不超过2节）计入辅导栏内；补考判卷工作量由各系部统计后报教务处统一做支付单，具体参见附件2。
4.本月起暂用新模板（见附件3），并请各系部每月将工作量统计表及其他有关工作量表格电子版发于丽邮箱（yl890038@126.com）。
关于合班上课工作量计算的暂行规定
根据我院目前教师合班上课及排课的实际情况，至本学期末课时量计算暂按以下规定办理：
一、课时量按授课的班型和授课时间分别选取授课系数：
1.一个班授课乘以系数1.0，两个班授课乘以系数1.7，三个班授课乘以系数2.0，四个班以上授课乘以系数2.5；
原则上班型按学生人数未满60人时为一个班，学生人数达到60人但未超过100人时为两个班，学生人数在101人与150人之间时为三个班，学生人数超过150人时为四个班。
2.工作日第1~6节课授课按正常计算，第7、8节授课，乘以系数1.3，晚间及周六日休息日授课按18元/节标准折合工作量（不超课时按系数2.0，超课时按系数1.5；本规定适用于校内专任与兼课教师，校内兼课教师比照此标准折合工作量，不适用于外聘教师）。
二、教务处、系部相关管理人员根据实际情况给予补助（第7、8节值班补助10.0元、晚间30元、周六日50元/半天）。曹阳
5于玲 郭艳红 邓硕 张亚红 1 1 3 1
第三篇：教师教学工作量统计格式
药学院2013—2014第 一 学期
教学工作量（实际授课课时）
课程名称：（班级）（必修□选修□）计划学时：
理论学时：
任课教师：
实验学时：
任课教师：
教研室：
统计日期：姓名职称（就高）学时数实验分组数：实验总学时：姓名职称学时数
第四篇：工作量的评估方法
工作量的评估方法
1．软件开发价格估算方法
软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便于计算，给出一个计算公式：
软件开发价格＝开发工作量×开发费用／人·月 1.1开发工作量
软件开发工作量与估算工作量经验值、风险系数和复用系数等项有关： 软件开发工作量＝估算工作量经验值×风险系数×复用系数 1.1.1估算工作量经验值（以A来表示）
软什开发工作量的计算，曾有人提出以源代码行或功能点来计算，这些方法实施起来均有不少难度。目前国际上仍旧按以往经验的方式加以计算，国内各软件企业也是采用经验的方式加以估算工作量。
为了更好地规范估算方法，建议可按照国家标准“GB／T8566-2001软件生存周期过程”所规定的软件开发过程的各项活动来计算工作量。
工作量的计算是按一个开发工作人员在一个月内（日历中的月，即包括国家规定的节假日）能完成的工作量为单位，也就是通常所讲的“人·月”。
特别要提醒的是软件开发过程中既包括了通常所讲的软件开发，也应包括各类软件测试的活动。
1.1.2风险系数（以σ来表示）
估算工作量经验值亦会存在较大风险，造成软件危机的因素很多，这也是一个方面的因素。特别当软件企业对该信息工程项目的业务领域不熟悉或不太熟悉，而且用户又无法或不能完整明白地表达他们的真实的需求，从而造成软件企业需要不断地完善需求获取，修改设计等各项工作。因此：
l≤风险系数≤1.5 根据我们对软件企业的了解，超过估算工作量经验值的一半，已是不可接受，所以我们确定“1.5”为极限值。当然这既要看企业的能力，也要看用户能接受的程度。
1.1.3复用系数（以τ来表示）
估算工作量经验值是软件企业承担一般项目来估算的，但如果软件企业已经采用“基于构件的开发方法”，并己建立起能够复用的构件库（核心资产库），或者已有一些软件产品，仅作二次开发，从而使软件开发工作量减少。因此：
0.25≤复用系数≤1 根据国内外软件企业在实施基于构件开发方法（软件产品线）的经验数据，提高工作效率达到25%（最高值）。
1.2开发费用／人·月
软件企业的商务成本、国家税收、企业利润、管理成本和质量成本。均可摊分到各个软件开发人员头上。
开发费用／人·月＝（P＋Q＋R）×S×τ 1.2.1P（人头费）
人头费主要是员工的工资、奖金和国家规定的各项按人计算的费用。其总量在软件企业中的商务成本占70%－80%。
P＝B×1.476 国家规定的公积金7%，医疗保险金12%，养老金22%，失业金2%（即通常所说的四金），另外还有按工资总额计征的工伤保证金0.5%，生育保证金0.5%，残疾基金1.6%，工会基金2%，累计为47.6%。
B为平均工资，即企业支付给员工的工资、奖金、物质奖励等多项总和，除以企业员工数，分摊到每个月。
1.2.2Q（办公费）
办公费包括企业办公房屋租赁费和物业管理费、通信费、办公消耗品、水电空调费、设备折旧、差旅费，另外也包括企业对员工的在职培训所支付的费用，其总量在软件企业中的商务成本占20%－30%。
Q＝B／3 此处办公费用按商务成本的25%计算。1.2.3R（国家税收和企业利润）
由于国家实施发展软件产业的优惠政策，故不单独列出计算，但软件企业仍需承担缴纳国家税收的义务，可一并与企业利润一起考虑。
另外，软件企业的员工不可能全年满负荷地工作，即使一年十二个月都安排工作，但也需抽出时间进行在职培训和提职的岗前培训。据我们的了解，软件企业的员工一年能有10个月到11个月的工作也是正常的。
R＝B／3 此处为我们的建议方案，各软件企业可视情况加以变更。1.2.4S（管理系数）
通常每个机构的管理人员都会有一定的比例，参考一些机构的做法，按每十个软件人员配备两个管理人员即管理成本：
1≤S≤1.2 1.2.5T（优质系数）
提高软件质量，必然有所开支，即质量成本，对于不同的软件企业来说，其质量成本不尽相同。
软件企业与其他企业一样，也有诚信和品牌等诸多因素，从而增加企业的开支。
目前我们可以按通过ISO9000质量体系认证和CMM或CMMI的认证来确定，分别取值1.05、1.1、1.15、1.2。
今后建议可对软件企业的资质分为四级。由软件行业协会根据CMMI的认证、品牌、诚信程度等各种因素加以确定。此体系建设还有待进一步探索。
据此，我们综合上述各点：
开发费用／人·月＝（B×1.476＋B／3＋B／3）×l.2×T ＝B×（1.476＋2／3）×1.2×T ＝B×2.575×T ＝B×λ
当T＝1.05时，λ＝2.7 当T＝1.2时，λ＝3.09 因此，2.7≤λ≤3.09 对于承接国外软件外包业务，一方面员工的工资较高，另外工作的安排也较难满负荷工作，用此建议R＝B／2。因此
开发费用／人·月＝B（1.476＋1／3＋1／2）×1.2×T ＝B×2.767×T ＝B×λ
当T＝1.05时，λ＝2.906 当T＝1.2时，λ＝3.32 因此，2.9≤λ≤3.32 结论：
软件开发价格＝A×σ×τ×B×λ A：估算工作量经验值
B：软件企业的平均工资／人·月 Q：风险系数l≤Q≤1.5 T：复用系数0.25≤τ≤1 λ：综合系数2.7≤λ≤3.09 2.软件（系统）维护收费价格估算方法
在完成信心工程项目的系统集成和应用软件开发，并交付用户正式运行的一年内，对软件（系统）实行免费维护服务一年。
在正式运行一年后，软件企业应与用户签定软件（系统）维护合同。该合同属技术转让合同，也可属技术开发合同。
根据不同的用户要求，可分四种级别进行软件（系统）维护。2.1A级
软件企业派出技术人员常驻用户，解决日常运行中发生的问题。2.1.1U（系统建设投资额）
用户需要软件企业维护的系统，该系统建设的投资额。如用户只需要软件企业维护其所开发的应用软件，U就是该应用软件开发费；如用户需要软件企业维护整个系统，包括计算机硬件、软件、网络和应用软件，则U就是该信息工程项目的总投资额。
2.1.2N（技术人员数）
软件企业派出N个技术人员，常驻用户，因此： 软件（系统）维护费／年＝U×15%或B×λ×N×12 B、λ参见1.2.2B级
软件企业每周七天，每天24小时（即7×24小时）响应，2小时到现场，且每天派技术人员到现场进行软件（系统）性能调试，使之运行处于良好状态。
软件（系统）维护费／年＝U×10% 2.3C级
软件企业7×24小时响应，2小时到场。软件（系统）维护费／年＝U×5% 2.4D级
用户的信息工程系统或应用软件发生问题，由原承担的软件企业派人维护。2.4.1B’
这种维护方式要求软件企业需要保存所有的技术档案，更需要软件企业抽出专人来不断熟悉和全面掌握该软件（系统）的各项技术细节。因此，软件企业的这项支出必然要在维护费用收入中得到回报。
以1.1.3节中的B作为参数，将其人·月单位改为人·天，以B’表示。2.4.2τ’
软件企业如果采用基于构件开发方法，并建立起构件库，则会大大提高软件维护的效率。另外，如果有多家用户运行的系统大致类似，也可有所提高效率。
以1.1.3节中的τ作为参数，以τ’来表示。因此： 软件（系统）维护费／次＝B’×τ’×n 此次n表示所需要的人·天数。τ’的取值是0.2≤τ’≤1。3.系统集成价格的估算方法
将整个系统所涉及到的设备、软件、网络整和起来，并能正常地运行，其运行的结果能达到用户建立该系统的目标。这就是系统集成的含义。因此，可以理解为单纯的设备采购和供应并不涉及系统集成，以及单纯的应用软件开发也并不涉及系统集成。
系统集成费应与整个系统的规模、整个系统的复杂程度等项有关。系统规模往往与系统建设费用密切相关。为了简便计算，以系统建设费用（以U来表示）为参考坐标。复杂程度（以α来表示）可分四种级别来区分。
系统集成费＝U×α×T T参见1.2.5节 3.1A级
整个系统涉及到计算机硬件、软件、局域网络，且体系结构在三层次以下（含三层次）。
5%≤α≤8% 3.2B级
整个系统涉及到计算机硬件、软件、局域网络、互联网，且体系结构在三层以上（含三层次）。
7%≤α≤10% 3.3C级
整个系统涉及到计算机硬件、软件、局域网络、互联网以及多种网络接口。8%≤α≤12% 3.4D级
整个系统涉及到计算机硬件、软件、网络、通信以及各种数据采集设备接口或者与用主系统有接口。
10%≤α≤15% 4.系统解决方案费用估算方法 根据用户所提出的初步需求，软件企业根据以往的经验为之提供整个系统建设的方案，包括需购买的计算机硬件、软件、网络设备和应用软件开发的大体设想、费用估算、进度初步安排、信息化所涉及到的规章制度的一些规划，有时还会涉及信息中心的建设等等。这就是系统解决方案所要完成的工作。
目前国内市场对于系统解决方案是一种智力劳动成果的认识不足，以及国内多数招标公司并不熟悉信息技术，从而更加使得系统解决方案收费变得困难。因此，目前的收费处于过渡阶段。
系统解决方案费用与整个系统的规模、复杂程度等项有关。
系统规模往往与系统建设费用密切相关，为了简便计算，以系统建设的总投资（以U来表示）为参考坐标。
复杂程度就是用户的功能、性能要求复杂性、信息接口的类型和数量有关，以β来表示。
解决方案费用＝U×β×T T参见1.2.5节
关于β我们参照第3节所列各级。A级：0.7%≤β≤1.2% B级：1%≤β≤1.8% C级：1.5%≤β≤2.2% D级：2%≤β≤3%
第五篇：如何合理地减少软件测试工作量
如何合理地减少软件测试工作量?
1.减少冗余的测试
–白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙。在很多地方，白盒测试与黑盒测试会产生一模一样的效果（或者能推理出来），这样的测试是冗余的。
–在集成测试、系统测试阶段，可能要执行多次“回归测试”。每一次“回归测试”都会存在不少的冗余，应当设法剔除不必要的重复测试工作。
2.减少无价值的测试
–无价值的测试通常是由于不懂得测试技术引起的。例如功能测试，在等价区间之中，本来只要测试一个典型的输入就行了，如果有人在此区间测试了100次，那么其中99次就是无价值的。
3.如何“偷工减料”
–有一些“短、平、快”的项目，经费本来就少，用户对质量要求也马马虎虎。为了能多挣一点钱，开发方不得不采用“偷工减料”的方式来降低测试代价。偷工减料的途径无非就是减少测试的内容和频度。但不能砍得太狠，否则软件拿不出手。基本方法是找出软件中需要优先测试的部分（见下表），其它次要部分可以忽略或将来再测试。
3.1“偷工减料”方法的测试优先级：
–哪些功能是软件的特色？
–哪些功能是用户最常用的？
–如果系统可以分块卖的话，哪些功能块在销售时最昂贵？
–哪些功能出错将导致用户不满或索赔？
–哪些程序是最复杂、最容易出错的？
–哪些程序是相对独立，应当提前测试的？
–哪些程序最容易扩散错误？
–哪些程序是全系统的性能瓶颈所在？
–哪些程序是开发者最没有信心的？
点击咨询 