如何评估自动化测试工作量

如何评估自动化测试工作量

美国项目管理专业资质认证委员会主席Paul Grace说：“在当今社会，一切都是项目，一切也将成为项目”。着名管理顾问David Cleland断言：“在当今纷繁复杂的世界中，项目管理是成功的关键。

一切有组织的活动，都可以看做是项目，如果我们把自动化测试看作是一个项目来管理的话，就会发现，其中有许多规律可循。

现代项目越来越朝着大型化、复杂化的方向发展，大大提高了项目测试的难度。自动化测试已经是不可缺少的测试管理之一。如何把自动化测试与项目管理更加紧密地结合起来，是当今测试管理研究的主要课题之一。工作分解结构方法是现代项目管理中的一个先进、有效的方法，是基于系统原理的方法，是测试计划、控制的基础。运用WBS（WBS：Work Breakdown Structure）即工作分解结构方法，可以很好地将自动化测试、更为有效地运用到项目管理中，对项目实行自动化测试管理，提高测试效率。

一、测试项目的分解

项目分解的主要目的是为项目测试控制确定具体的控制对象以及相应的控制目标。项目目标系统中的工期、费用和质量是项目控制中的主要控制目标。

1、分解机构（WBS）

项目的分解结构（WBS）可以将项目分解成可以管理的工作单元——工作包，从而能够更容易也更为准确地确定这些单元的费用和进度，明确定义及质量要求。

WBS方法是一种全面地、系统地分析项目的有效方法，也是项目管理的基础性工作。在项目中应将项目系统分解成可管理的活动。分解的结果被称为项目分解机构，即WBS。

关于WBS的定义，最早可从美国国防部国防系统开发工作的手册中得到解释：即工作分解结构（WBS）是一个以产品为中心的层次体系，由硬件、软件、服务和资料组成。它完全确定了一个项目。在确定的产品单元时，系统项目起着关键性的作用。WBS显示并确定了要研制或生产的产品，并将要完成的工作单元与最终的产品联系起来。具体可分为纲要性WBS、项目纲要性WBS、合同WBS和项目WBS等四类。

WBS作为项目管理的基础性工作，它的建立必须体现项目本身的特点和项目管理组织的特点，必须遵守整体性、系统性和可追溯性的原则。在对一个具体的项目的WBS设计时，要注意其三个基本要素的设计，即结构、测试代码和测试报告的设计。

2、工作包模型

工作包模型的基本构成单元是不作包。而工作包则是用项目分解结构对项目分解后，在分解结果的基础上形成的。该模型的主要思路是将“工作包”作为项目控制的具体的基本对象。每一个工作包的基本内容是由一项或几项项目活动或分项项目构成。工作包能作为工期控制的基本单元，同时将费用控制体系的控制帐户和质量控制体系的基本单元也建立在工作包上，这样每个工作包就能够作为项目控制项目中各单元控制的共同的具体控制对象，并为项目进展情况综合信息（工期、质量、费用信息）的采集、传递提供了共同的基础，保证了控制过程所需的信息来源的单一性和集成性。由于每个工作包具有上述属性，因而由其组成的层次结构体系便不仅能反映项目的整个生产过程，而且能反映其所有特性，内部相互关系和控制目标要求，从而成为项目总体控制对象体系，并能支持项目控制的全过程。

工作包模型建立后，就可以对各工作包进行测试，利用数据库技术对项目进行集成化管理。项目的分类和测试是否适合，对计算机能否在项目管理中得到广泛应用，显得尤为重要。

二、项目信息的分类体系

信息分类体系是建立一个合适的WBS基础。由于不同的项目参与者都是从自己所从事的行业出发，理解项目并制定信息分类体系，而这些信息分类体系所对应的测试体系一般各不

相同，参与方会按自己的一套测试体系来测试WBS，这就影响了项目参与各方的信息交流，严重影响了自动化测试的应用。

WBS与传统进度计划的主要区别在于，WBS是项目所有工作的集合，而传统进度计划一般不包含项目管理元素。最通俗的讲，WBS就是把一个项目的所有工作任务按照层次（树型结构）进行排列，从树状结构逐步到分面结构，再到树状与分面结构的混合方式。这种变化反映了项目测试管理所涉及的内容正逐步增加。可以一目了然项目的范围，以及任务之间的关系

这种分类体系基本上采用了ISO技术报告的框架，并在其基础上进行了细化。这种分解体系最大的特点是层次清晰，简单明了，突出重点，按照不同的重要级别划分项目，有利于对项目的控制，且包含了所有的软件项目，适应于WBS的编制。WBS按照这种方式分解，并在此基础上形成测试体系，便于具体项目的应用。

自动化测试的内容与方式

自动化测试的主要内容包括对项目分解体系的测试，从时间上对项目实施全过程进行分解的测试，对不同的功能模块、数据库、系统架构等进行测试。

自动化测试可采用需求分析、场景分析、流程分析、案例生成、执行测试、测试报告等组合流程。简单的测试如树状结构，这种结构有利于信息的汇总，上一级的测试是下一级所有测试的汇总，但这种分类方法存在着扩展性欠佳的问题。比较复杂的测试方式如分面结构，把测试分成不同的部分，如同积木，各个部分结合起来才有完整的意义。这种结构具有可扩展性。第三种测试方式是前两种的混合，即在同一“面”保持树状结构，改善汇总功能；但仍采取不同面的组合方式，以增加其扩展性。但项目的具体测试形式是随项目的类型和特点而定的，具体情况应具体对待。

上面几种测试方式都已出现在不同国家和地区的项目测试体系中。随着测试水平的提高，目前国际上的研究倾向于采用第二种测试体系，都须具备稳定性，兼容性和灵活性的原则。

三、运行wbs可解决传统测试遇到的问题

自动化测试。通过工作包模型，在测试与项目管理之间架起一道桥梁，把它们紧密地联系在一起，极大地提高了项目测试的效率，和传统测试相比发生了质的飞跃。

工作量评估方法完整版.完整版.docx

关于工作量评估方法 为能清楚阐明论点。先举两个例子。 大家一定都听说过“龟兔赛跑”的故事，故事里乌龟是正面人物，而兔子作为反面人物受人讥讽，其中的寓意教育人们做事要像乌龟一样有坚忍不拔的精神。如果换个角度分析这个故事。则会有不同的结论。兔子在整个赛跑过程中做了两件事，那就是赛跑和睡觉；乌龟则仅做了一件事，就是不停地赛跑。如果我们试把时间延长（即看看它们在赛后又做了什么），可以想象乌龟由于比赛的疲劳，而跑回家呼呼大睡了；兔子呢？由于比赛中同时也保养了精神，赛后可以做其它更多自己想做的事。由此，不难得出整个过程兔子的效率更高。另外，乌龟并不擅长跑步，却安排它去参加这场比赛，其效率必然极低，把这种现象映射到企业管理中去，也颇发人深思。 试看一个说明工作效率与工作饱和相矛盾的例子：某工厂的一位计算机技术人员，现场发生了微机故障，从他的办公室到达故障点的方式有两种选择，其一是步行，需要10分钟；其二是骑自行车，只需2分钟。我们设步行到现场的为甲，骑车到现场的为乙，最后统计：两人去处理同样的一个工作，甲用了30分钟，而乙只用了15分钟，（这里是假设两人故障的修复时间相同，但事实上甲这类人在故障修复中要花更多的时间）。乙在剩下的15分钟又可以做其它更多的事情，单从这点出发，甲与乙在工作成效上就不仅是1：2的差距了，而是1：N（即甲做一件事的时间，乙做了N件事）的差距。但在现实中，甲往往成了“工作量饱满、劳动模范”的象征；而乙却常常恰好相反，这是管理人员认识上的一大误区，长此下去必然带来管理上的一系列问题。 工作效率由员工的自身因素决定，但如何激励员工提高工作效率，目前仍是管理上的问题。首先是工作分配的合理化，它直接影响工作的效率，让乌龟去赛跑，显然是不合理，所以对工作的合理分配是提高效率的首要条件，这与管理人员的工作密不可分，要求管理人员不仅清楚了解管辖范围内的工作内容，而且要对被管理人的基本情况有清楚的认识。 工作分配合理后，那如何主动去提高每个员工的工作效率呢？竞争是个好方法，奖惩也是个好方法，另一种就是让员工自身有好的素质，拥有正确的人生观及世界观，提高效率便成为很自然的事。前两种方法是被动的，也是目前企业管理中普遍采用的方法，而第三种方法突出了“人自身的因素，希望通过发挥主观能动性来提高工作效率。因为当一个人具有一定知识水平（包括综合知识和技能知识），拥有正确的人生观及世界观，那么我们说，从主观上他会自觉主动地提高效率，从效率中求饱和，再从饱和中追求效率。这样看来采用这种方法，不仅仅能提高效率，而且同时无形中也解决了效率与饱和间的矛盾。 由此可见，通过主观能动性来提高效率，关键就是如何提高员工的综合素质问题，这个素质并非仅仅指的员工的技术知识水平，更重要的还包含道德修养、情操和理想等一些深层次东西。目前企业对员工的素质教育，仅仅是偏重于技能知识的教育，认为员工只要有好的技术和熟练的操作，便有了效率，这是远远不够的。因此，素质的提高在于两方面：①个人专业技能及社会知识要丰富，这是效率的基本前提；②同时应丰富其它的各类知识，如自然知识及人文知识等等。企业管理中在对提高员工素质方面应该投人更多，这样可以更快的从被动地提高工作效率转变为主动地提高工作效率。 以上谈了工作效率问题。现在再来看看工作量问题。评价一个人工作饱和度高不高（注意这里是针对同一个工作），答案就只有两种：低效率饱和度高；高效率饱和度低。可见效率与饱和度存在着矛盾。而“工作饱和”的含义应该是指员工的有效工作时间与规定的劳动时间相等或近似相等，这里的工作时问是指有效的工作时间，强调“有效”二字，“有效”就包含效率和成效的意思。这又体现了效率与饱和度有统一的一面。而在现实的管理工作中，管理人员常常忽略“有效”的重要性，虽然这种“忽略”往往并不是有意的，自然也就无法正确评价如何才算是工作饱和，于是便出现了“整天忙个不停的员工就一定是个好员工”的谬论。所以如何科学地去看待工作饱和度其实也是管理上的问题，它要求管理人员自身具有好的素质及高的效率，这样才谈得上被管理的人有好的素质及高的效率。

几种测试工作量的估算方法

在测试项目管理中或编写测试计划时，经常需要对某个测试工作进行工作量的预算，很多时候都是凭个人的工作经验进行估算的，如能结合一些常规的估算方法，有助于估算的精确度。 以下是网上找到的一些常规的估算测试工作量的方法： 1、Ad-hoc方法 这种方法下的测试工作量不基于任何确定的期限。工作一直继续直到达到一些由管理或市场人员预先定下的时间表。或者，一直到用完了预算的经费。 这种情况普遍存在于非常不成熟的组织，并且时常有100%的错误差数。 2、开发时间的百分比法Percentage of development time。 这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。首先，开发工作量使用例如LOC或FP方法被估算出来，然后使用一些探索性的方法来限制测试的工作量。 这种方法变化比较大而且通常基于以前的经验。 通常预留项目的总花费时间的35%给测试。？5-7%给组件和集成测试？18-20%给系统测试？10%给接收测试（或回归测试等） 3、类比法（经验值法或历史数据法） 根据以前或相似项目（主要在项目性质，领域，规模上有相似）所积累的经验或历史数据来估算工作量。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。需要收集以下相关的历史数据：？在设计和实现阶段花费的时间？测试工作的规模，例如用户需求的数量，页面数，功能点？数据样式，例如实体，字段的数量？屏幕或字段数量？测试对象的规模，例如KLOC 4、WBS（work breakdown structure）估算法 将项目或产品分解为具体的工作，然后分别对各个工作进行时间估算，最终求和得出项目或产品的测试工作量/时间。 5、Delphi法 Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种相关经验人的参与，互相说服对方…… Delphi法的步骤是：1、协调人向各专家提供项目规格和估计表格；2、协调人召集小组会各专家讨论与规模相关的因素；3、各专家匿名填写迭代表格；4、协调人整理出一个估计总结，以迭代表的形式返回专家；5、协调人召集小组会，讨论较大的估计差异；6、专家复查估计总结并在迭代表上提交另一个匿名估计；7、重复4-6，直到达到一个最低和最高估计的一致。 6、PERT估计法 PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计。Pert 估计可得到代码行的期望值E，和标准偏差SD

岗位工作量测评分析报告(模板)

岗位工作量测评分析报告 一、目的 为适应汽车产销下滑的行业形势，相应配合上级单位对于合理配置人力资源的总体要求，同时为了解员工的实际工作情况，提高员工工作效率，优化组织架构，合理利用人工成本，特开展此项工作。 二、测评范围 公司职能及辅助岗位。 三、测评时间 *年*月*日-*年*月*日。 四、采用方法 工作量化分析法，即根据各岗位所写的岗位说明书，将职责细化为日常的工作步骤，对工作步骤完成的时间进行统计，与预先设计好的岗位工作判定标准进行对比，结合岗位任职人员的能力素质，对各岗位的工作量进行评估判断。 五、基本情况 1.测评部门 综合管理部（食堂、司机除外）、财务部、采购部、质量部、技术部（行政专员）、制造部（技能岗位除外），测评人员共计52人。 2.结合工作情况，将工作分为日常性、阶段性、突发性工作；年岗位工作量统计，1天按8小时，1周按5天，一年按250天计算，即50周。 3.本月共31天，周六、周日放假合计8天，本月实际出勤天数23天（按标准工作时间计算），共10166H。 六、公司整体数据分析 总体来说，本次员工岗位工作量测评虽有些方面不尽人意，但作为推行的一项管理措施，基本上没遇到较大的抵触，测评人员也算比较配合。 （一）工作日志完成情况 工作内容：通过近半个月的工作日志的核对，工作内容与岗位说明书一致。 （二）岗位工作结构占比 1.职能岗位工作结构 图标 2.辅助岗位工作结构 图标 根据部门评定后的数据可看出职能岗位日工作量饱满度范围为：50%-100%，日常工作量占总工作量比例范围为：48.92%-89.85%；辅助岗位日工作量饱满度范围为：71.25%-133.75%，日常工作量占总工作量比例范围为：55.30%-95.19%；测评岗位主要以日常性工作为主。 （三）工作日志数据、岗位测评填报数据与考勤数据对比

工作量考核方案

工作量考核方案 工 作 量 考 核 方 案 （拟定稿） 说明: 一.本包括考核制度和考核量表两部分。. 二.考核量表主要是测评教务处学生助理员的绩效，同时作为教 务处学生助理工作组工资发放的参考依据。 三.附考核流程图如下: 四、本制度每学期期末考试周前接受所有老师和教助意见并及时完 善，制度完善并施行前应专门召开集体会议，公开解释制度具体细节的构建理由和含义。最终解释权归教务处学生助理工作量评估小组。 五、本制度提交华中师范大学教务处学生助理工作组备案。

教务处学生助理考核制度 第一章 第一条总则考核的目的是通过客观评价教务助理的工作能力、态度，优化教务 处助理队伍，并客观合理地安置教务助理，做到人岗匹配，并以考 核结果为参考，发放教助的年终薪酬。 第二条本规定中使用的专业术语定义如下： (一)能力考核---------通过工作行为，观察、分析、评价教助具有的工作能力。 (二)态度考核---------通过对教助的工作努力情况和工作热情进行观察和评 价。 (三)业绩考核---------对教助分担的工作完成情况进行观察、分析和评价。(四)360度考核法----即全视角绩效考核法，通过不同的考核者（老师、同学、 其他教助等）从不同的角度来全方位考核教助工作情况。 (五)KPI法------------即关键业绩指标，选取一些关键的、与教助队伍目标实 现关系比较紧密的工作内容作为考核项目。 (六)考核者-------------老师、同学以及其他教助。 (七)被考核者----------2007－2008学年度教务助理。

(八)考核执行者--------教务助理工作组。 第三条考核原则 (一)考核标准尽可能量化； (二)考核标准的制定以教助管理条例为依据，按照教务 处的标准制定。 第四条每位教务助理一学期工资标准在400元左右浮动，教务助理最后所 得工资根据考评结果而定。 第五条考核方法是360度考核法,由教务助理所在办公室老师,其他办公室 教助（即同事）共同参与，实行打分制，考核表由教务助理所在办公室老师填写，同时参考其他办公室教助（即同事）意见，运用KPI法确定绩效考核标准。 第二章考核流程与实施 第一条教务助理工作组开会讨论确定最终考核制度； 第二条由教助工作量评估小组整理制度材料，交给教务 助理工作组审核， 最后上交教务助理管理老师审批； 第三条制度执行，由各办公室老师对本办公室教助进行 考核； 第四条由教助工作量评估小组进行汇总，按分数列出等级，确定薪酬；

工作量的评估方法

工作量的评估方法 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%，残

软件工作量评估报告

XXXX软件成本评估 1. 概述 我们认真地阅读了软件的用户指南，与XXXX电脑部有关技术人员进行了深入的交流，并查看了软件的操作界面。在此基础上，我们对软件的功能进行了归纳和整理，并根据以往的经验对每个功能模块所需的编码工作量进行估算，再进一步地以此为依据，推算出整个软件生命期的工作量。 2. 编码工作量估算 本次评估的软件有两个，分别是《X软赠券电脑发放管理系统》和《X软联销资源管理系统》。为了更准确的估算出软件的工作量，我们对每一个软件功能模块所需工作量给出了三个估计值，分别是：1）悲观工作量（Epi）：这是一个最保守的估计，可能在编程人员技术不熟练，对业务理解不够，或有其他影响其正常工作的因素存在的情况上发生。 2）正常工作量（Eni）：这是一个正常的程序员可能付出的工作量估计。 3）乐观工作量（Esi）：这种情况可能在程序员技术相当熟练，对业务相当了解，且以前可能有类似项目开发经验的情况下所需的工作量。

针对每一项功能模块，其最终的工作量估算值按以下公式计算：Ei = （Epi + 4 × Eni + Esi）/ 6 下面的表1是对X软赠券电脑发放管理系统的编码阶段的工作量估算，表2是对X软联销资源管理系统的编码阶段的工作量估算。 表1：X软赠券电脑发放管理系统的编码阶段工作量清单 表2：X软联销资源管理系统的编码阶段工作量清单

上述两个软件的编码阶段的工作量合计为： Ec = Ec1 + Ec2 = 151.67 + 1631.67 = 1783.34(人.小时) 3. 软件生命期工作量估算 为便于估算，我们假定《X软赠券电脑发放管理系统》和《X软联销资源管理系统》均按照瀑布模型开发。 瀑布模型将整个软件生命期划分为计划与需求、产品设计、详细设计、编码与单元测试、集成与测试、移交等六个阶段，各阶段所占工作量如表3所示。 表3：瀑布模型阶段分布百分比 根据上表，编码与单元测试阶段仅占全部工作量的24%，因此《X

如何评估测试工作量

场景一：合同前的工作量估算 场景描述： 软件开发网 （1）没有实施过CMMI2级 （2）合同未签，需要给客户报价 （3）有客户的概要需求，有类似的项目数据可供参考 （4）需要估计整个项目的总工作量，以便于估算总成本，给客户报价 软件开发网 估算步骤： （1）寻找类似的历史项目，进行项目的类比分析，根据历史项目的工作量凭经验估计本项目的总工作量； （2）进行WBS分解，力所能及地将整个项目的任务进行分解； （3）参考类似项目的数据，采用经验法估计WBS中每类活动的工作量； （4）汇总得到项目的总工作量； （5）与第（1）步的结果进行印证分析，根据分析结果，确定估计结果。 场景二：基于详细需求的经验估计 场景描述： （1）只有详细需求，没有历史数据 估算步骤： （1）WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度；WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。 （2）采用经验法估计每个活动的工作量； （3）汇总得到：每个阶段的工作量、项目的总工作量。 其他说明： 在该场景下，只使用了经验法，无法对结果进行印证，难以判断结果的合理性。 场景三：由编码估算整体 场景描述： （1）有类似项目的历史数据 （2）有编码活动的生产率数据 （3）有详细需求 （4）实施了CMMI2级，但是没有积累历史项目的工作量分布数据软件开发网 估算步骤： （1）产品分解，将系统分为子系统，子系统分解为模块； （2）WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度；WBS分解时要

识别出所有的交付物、项目管理活动、工程活动等。 （3）建立WBS分解中的活动与产品元素的映射关系，识别出WBS中哪些活动可以采用模型法估算； （4）估计产品元素的规模，可以采用代码行法或功能点法，并估计每个产品元素的复杂度、复用率等； （5）根据历史的编码阶段的生产率数据和产品元素的规模估计、复杂度、复用率等采用模型法计算每个产品元素的编码工作量； （6）根据历史的类似项目的数据及估算人的经验估计其他活动的工作量，可以采用经验法。（7）汇总得到：每个阶段的工作量、项目的总工作量。 其他说明： 在该场景下，混合使用了经验法与模型法，这2种方法互相补充，而不是互相印证。 场景四：由总体印证基于WBS的估计 场景描述： （1）有类似项目的历史数据 （2）有类似项目的全生命周期的生产率数据（含管理工作量） （3）有详细需求 （4）实施了CMMI2级，但是没有积累历史项目的工作量分布数据 估算步骤： （1）产品分解，将系统分为子系统，子系统分解为模块； （2）估计产品元素的规模，可以采用代码行法或功能点法； （3）累计出整个产品的总规模，并估计产品总体的复杂度、复用率等； （4）根据类似项目的全生命周期的生产率数据和产品的总规模、复杂度、复用率等采用模型法计算总的开发工作量； （5）WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度；WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。 （6）根据历史的类似项目的数据及估算人的经验估计所有活动的工作量，可以采用经验法。（7）汇总得到：每个阶段的工作量、项目的总工作量。 （8）与第（4）步得出的工作量进行比较印证，如果偏差不大，则以第（7）步的结果为准，如果偏差比较大，要仔细分析原因，可能的原因举例如下： 类似项目的生产率数据不适合本项目； WBS分解的颗粒度不够详细； 估算专家的经验不适合本项目； 具体任务的估计不合理； 针对原因，对估算的结果进行调整，使其趋向合理。 其他说明： 在该场景下，对于项目的总工作量有2个结果或者多个结果，这些结果可以互相印证，以发现估算过程中的不合理之处，是估计更加合理。

软件开发实施项目工作量评估明细表

项目工作量统计表 项目名称：推进OA系统应用，强化业务整合 一、推进OA流程应用工作量 序号阶段工作内容人员 配备 人·日 1 项目准备现有系统配置情况检查 系统相关模块的基本数据情况检查 制定实施阶段计划，约定每个阶段的时长，准 确划分各阶段时间节点 预定培训实施期间培训日期安排 3 9 2 系统配置建立相关组织结构 建立相关角色 调整全局配置项 建立权限分配方案 2 12 3 流程调研落实需要上线的流程列表，这些流程主要包 括：党委发文流程、纪委发文流程、公司发文 流程、部门发文流程（报告、函、请示、通知）、 公司收文流程，以及：用印申请流程、出差申 请流程、会议管理流程等 培训流程图的标准画法 收集流程图，交流流程信息、修改流程图、流 程图定稿 4 36 4 设定流程建立流程，谁提交，谁批准，谁执行 建立流程表单，及相应说明 建立流程处理签 建立存档管理，配置相关归档目录 建立权限管理 5 85 5 模拟调试对所有流程进行模拟测试，特别是各个重要公 文流程，必须进行遍历测试 根据模拟测试发现的情况，对流程设置进行检 讨和调整 4 72 6 管理员培训对流程管理员进行培训，使其掌握流程异常情 况处理、流程微调技巧 2 8 7 用户培训根据项目实际整理培训资料 落实培训人员、场地、时间安排 三场用户培训，需用户积极配合协调 2 8 8 系统启用建立起与系统运行相适应的管理规章制度 发布正式启用系统的通知 系统检查与实施补充 问题收集、反馈、调整 2 12 9 项目收尾项目回顾 权限收回 2 2 合计244

二、新功能开发工作量 序号阶段工作内容人员 配备 人·日 1 需求调研、分析了解用户业务，获取用户对功能、性能等方面 的需求 4 20 2 需求确认用户方、开发方对需求进行审核确认 这些功能包括：安全认证、电子印章、规章制 度管理、业务整合 2 10 3 总体设计系统初步设计 2 10 4 总体设计评审用户方、开发方对总体设计审核确认 2 2 5 详细设计对系统功能、操作界面、处理逻辑、数据库、 代码体系等进行详细设计 2 20 6 详细设计评审开发组对详细设计方案审核确认 1 3 7 编程、单元测试编写程序、单元测试 系统管理（设置，备份还原） 操作人员管理及权限管理 2 24 安全认证 2 70 电子印章 2 64 规章制度管理 3 81 业务整合（初步） 2 20 业务整合（深入） 4 120 8 集成测试系统集成测试、系统测试，编程与测试可以交 叉进行 4 24 9 安装调试到用户现场安装调试开发好的系统，并与用户 一起试走业务流程，对系统进行功能确认测试 3 21 10 系统初始化将系统初始化；准备业务基础数据并录入系 统； 2 12 11 用户培训对用户操作人员、系统管理人员进行详细培训 1 4 12 项目跟踪与总 结 系统bug控制，操作指导 2 12 合计517 工作量总计：761人·日

常规估算测试工作量的方法(精)

常规估算测试工作量的方法 作为一个管理者，你是否被询问到某个项目要花多少时间，多少人力测试；或是作为一个普通的测试员，你是否被询问到要花多少时间来完成某个任务或是一次回归测试？我想大多数在软件行业的人或多或少都会碰到这样的关于工作量估计的询问。那么你是怎么回答的呢？你对你自己的回答有信心吗？你是否最终发现实际上花去的时间和原本估计的时间大相径庭呢？ 不同的人会使用许多不同的方法来估算及安排他们的测试工作量。不同的组织根据项目的类型，项目的内在风险，涉及的技术等而使用不同的方法。但是大多数时候测试工作量是和开发工作量合在一起的，没有一个单独的数字。 首先让我们来看看一些常规的估算测试工作量的方法： 1. Ad-hoc方法 这种方法下的测试工作量不基于任何确定的期限。工作一直继续直到达到一些由管理或市场人员预先定下的时间表。或者，一直到用完了预算的经费。 这种情况普遍存在于非常不成熟的组织，并且时常有100%的错误差数。 2.开发时间的百分比法Percentage of development time. 这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。首先，开发工作量使用例如LOC或FP方法被估算出来，然后使用一些探索性的方法来限制测试的工作量。这种方法变化比较大而且通常基于以前的经验。 通常预留项目的总花费时间的35%给测试。5-7%给组件和集成测试，18-20%给系统测试，10%给接收测试（或回归测试等） 3.类比法（经验值法或历史数据法） 根据以前或相似项目（主要在项目性质，领域，规模上有相似）所积累的经验或历史数据来估算工作量。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。需要收集以下相关的历史数据：在设计和实现阶段花费的时间？测试工作的规模，例如用户需求的数量，页面数，功能点。 4.WBS（work breakdown structure）估算法 将项目或产品分解为具体的工作，然后分别对各个工作进行时间估算，最终求和得出项目或产品的测试工作量/时间。

如何评估自动化测试工作量

如何评估自动化测试工作量 美国项目管理专业资质认证委员会主席Paul Grace说：“在当今社会，一切都是项目，一切也将成为项目”。着名管理顾问David Cleland断言：“在当今纷繁复杂的世界中，项目管理是成功的关键。 一切有组织的活动，都可以看做是项目，如果我们把自动化测试看作是一个项目来管理的话，就会发现，其中有许多规律可循。 现代项目越来越朝着大型化、复杂化的方向发展，大大提高了项目测试的难度。自动化测试已经是不可缺少的测试管理之一。如何把自动化测试与项目管理更加紧密地结合起来，是当今测试管理研究的主要课题之一。工作分解结构方法是现代项目管理中的一个先进、有效的方法，是基于系统原理的方法，是测试计划、控制的基础。运用WBS（WBS：Work Breakdown Structure）即工作分解结构方法，可以很好地将自动化测试、更为有效地运用到项目管理中，对项目实行自动化测试管理，提高测试效率。 一、测试项目的分解 项目分解的主要目的是为项目测试控制确定具体的控制对象以及相应的控制目标。项目目标系统中的工期、费用和质量是项目控制中的主要控制目标。 1、分解机构（WBS） 项目的分解结构（WBS）可以将项目分解成可以管理的工作单元——工作包，从而能够更容易也更为准确地确定这些单元的费用和进度，明确定义及质量要求。 WBS方法是一种全面地、系统地分析项目的有效方法，也是项目管理的基础性工作。在项目中应将项目系统分解成可管理的活动。分解的结果被称为项目分解机构，即WBS。 关于WBS的定义，最早可从美国国防部国防系统开发工作的手册中得到解释：即工作分解结构（WBS）是一个以产品为中心的层次体系，由硬件、软件、服务和资料组成。它完全确定了一个项目。在确定的产品单元时，系统项目起着关键性的作用。WBS显示并确定了要研制或生产的产品，并将要完成的工作单元与最终的产品联系起来。具体可分为纲要性WBS、项目纲要性WBS、合同WBS和项目WBS等四类。 WBS作为项目管理的基础性工作，它的建立必须体现项目本身的特点和项目管理组织的特点，必须遵守整体性、系统性和可追溯性的原则。在对一个具体的项目的WBS设计时，要注意其三个基本要素的设计，即结构、测试代码和测试报告的设计。 2、工作包模型 工作包模型的基本构成单元是不作包。而工作包则是用项目分解结构对项目分解后，在分解结果的基础上形成的。该模型的主要思路是将“工作包”作为项目控制的具体的基本对象。每一个工作包的基本内容是由一项或几项项目活动或分项项目构成。工作包能作为工期控制的基本单元，同时将费用控制体系的控制帐户和质量控制体系的基本单元也建立在工作包上，这样每个工作包就能够作为项目控制项目中各单元控制的共同的具体控制对象，并为项目进展情况综合信息（工期、质量、费用信息）的采集、传递提供了共同的基础，保证了控制过程所需的信息来源的单一性和集成性。由于每个工作包具有上述属性，因而由其组成的层次结构体系便不仅能反映项目的整个生产过程，而且能反映其所有特性，内部相互关系和控制目标要求，从而成为项目总体控制对象体系，并能支持项目控制的全过程。 工作包模型建立后，就可以对各工作包进行测试，利用数据库技术对项目进行集成化管理。项目的分类和测试是否适合，对计算机能否在项目管理中得到广泛应用，显得尤为重要。 二、项目信息的分类体系 信息分类体系是建立一个合适的WBS基础。由于不同的项目参与者都是从自己所从事的行业出发，理解项目并制定信息分类体系，而这些信息分类体系所对应的测试体系一般各不

软件开发成本估算

软件开发成本估算 软件开发成本估算主要指软件开发过程中所花费的工作量及相应的代价。不同与传统的工业产品，软件的成本不包括原材料和能源的消耗，主要是人的劳动的消耗。另外，软件也没有一个明显的制造过程，它的开发成本是以一次性开发过程所花费的代价来计算的。因此，软件开发成本的估算，应是从软件计划、需求分析、设计、编码、单元测试、集成测试到认证测试，整个开发过程所花费的代价作为依据的。 软件开发成本估算的经验模型 1.Putnam 模型 1978年Putnam提出的，一种动态多变量模型。 L = Ck * K1/3 * td4/3 其中： L-----------源代码行数(以LOC计) K-----------整个开发过程所花费的工作量（以人年计） td-----------开发持续时间（以年计） Ck----------技术状态常数，它反映“妨碍开发进展的限制”，取值因开发环境而异，见下表 软件开发成本估算 软件开发成本估算主要指软件开发过程中所花费的工作量及相应的代价。不同与传统的工业产品，软件的成本不包括原材料和能源的消耗，主要是人的劳动的消耗。另外，软件也没有一个明显的制造过程，它的开发成本是以一次性开发过程所花费的代价来计算的。因此，软件开发成本的估算，应是从软件计划、需求分析、设计、编码、单元测试、集成测试到认证测试，整个开发过程所花费的代价作为依据的。

软件开发成本估算的经验模型 1.Putnam 模型 1978年Putnam提出的，一种动态多变量模型。 L = Ck * K1/3 * td4/3 其中： L-----------源代码行数(以LOC计) K-----------整个开发过程所花费的工作量（以人年计） td-----------开发持续时间（以年计） Ck----------技术状态常数，它反映“妨碍开发进展的限制”，取值 因开发环境而异，见下表 从上述方程加以变换，可以得到估算工作量的公式： K = L3/(Ck3*td4) 还可以估算开发时间： td = [L3/(Ck3*K)]1/4 1.COCOMO模型(constructive cost model) 这是由TRW公司开发，Boehm提出的结构化成本估算模型。是一种精确的、易于使用的成本估算方法。 COCOMO模型中用到以下变量： DSI-------源指令条数。不包括注释。1KDSI = 1000DSI。

工作量考核方案范文

工作量考核方案范文 工 作 量 考 核 方 案 （拟定稿） 说明: 一.本方案包括考核制度和考核量表两部分. 二.考核量表主要是测评教务处学生助理员的绩效同时作为教 务处学生助理工作组工资发放的参考依据 三.附考核流程图如下: 四、本制度每学期期末考试周前接受所有老师和教助意见并及时完 善制度完善并施行前应专门召开集体会议公开解释制度具体细节的构建理由和含义最终解释权归教务处学生助理工作量评估小组 五、本制度提交华中师范大学教务处学生助理工作组备案 教务处学生助理考核制度 第一章

第一条总则考核的目的是通过客观评价教务助理的工作能力、态度优化教务 处助理队伍并客观合理地安置教务助理做到人岗匹配并以考 核结果为参考发放教助的年终薪酬 第二条本规定中使用的专业术语定义如下： (一)能力考核通过工作行为观察、分析、评价教助具有的工作能力 (二)态度考核通过对教助的工作努力情况和工作热情进行观察和评 价 (三)业绩考核对教助分担的工作完成情况进行观察、分析和评价 (四)360度考核法即全视角绩效考核法通过不同的考核者（老师、同学、 其他教助等）从不同的角度来全方位考核教助工作情况 (五)KPI法即关键业绩指标选取一些关键的、与教助队伍目标实 现关系比较紧密的工作内容作为考核项目 (六)考核者老师、同学以及其他教助 (七)被考核者XX－xx学年度教务助理 (八)考核执行者教务助理工作组 第三条考核原则 (一)考核标准尽可能量化；

(二)考核标准的制定以教助管理条例为依据按照教务处的标准制 定 第四条每位教务助理一学期工资标准在400元左右浮动教务助理 最后所 得工资根据考评结果而定 第五条考核方法是360度考核法,由教务助理所在办公室老师,其 他办公室 教助（即同事）共同参与实行打分制考核表由教务助理所在办公 室老师填写同时参考其他办公室教助（即同事）意见运用KPI法确定绩效考核标准 第二章考核流程与实施 第一条教务助理工作组开会讨论确定最终考核制度； 第二条由教助工作量评估小组整理制度材料交给教务助理工作组 审核 最后上交教务助理管理老师审批； 第三条制度执行由各办公室老师对本办公室教助进行考核； 第四条由教助工作量评估小组进行汇总按分数列出等级确定薪酬； 第五条召开全体教务助理大会宣布考核结果评定小组接受质询； 第六条合格者由教务处发放工资 第三章薪酬的确定方法 P1：所在办公室老师打分的平均分； P2：教务助理工作组打分的平均分；

工作量的评估方法

羀工作量的评估方法 肄1．软件开发价格估算方法 袅软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便 于计算，给出一个计算公式： 膂软件开发价格＝开发工作量×开发费用／人·月 螇1.1开发工作量 莇软件开发工作量与估算工作量经验值、风险系数和复用系数等项有关： 芄软件开发工作量＝估算工作量经验值×风险系数×复用系数 羂1.1.1估算工作量经验值（以A来表示） 螈软什开发工作量的计算，曾有人提出以源代码行或功能点来计算，这些方法 实施起来均有不少难度。目前国际上仍旧按以往经验的方式加以计算，国内各软件企业也是采用经验的方式加以估算工作量。 蒅为了更好地规范估算方法，建议可按照国家标准“GB／T8566-2001软件生存周期过程”所规定的软件开发过程的各项活动来计算工作量。 蚄工作量的计算是按一个开发工作人员在一个月内（日历中的月，即包括国家 规定的节假日）能完成的工作量为单位，也就是通常所讲的“人·月”。 蚃特别要提醒的是软件开发过程中既包括了通常所讲的软件开发，也应包括各 类软件测试的活动。 袀1.1.2风险系数（以σ来表示） 袇估算工作量经验值亦会存在较大风险，造成软件危机的因素很多，这也是一 个方面的因素。特别当软件企业对该信息工程项目的业务领域不熟悉或不太熟 悉，而且用户又无法或不能完整明白地表达他们的真实的需求，从而造成软件企业需要不断地完善需求获取，修改设计等各项工作。因此： 肃l≤风险系数≤1.5 蒃根据我们对软件企业的了解，超过估算工作量经验值的一半，已是不可接受，所以我们确定“1.5”为极限值。当然这既要看企业的能力，也要看用户能接受 的程度。

常用的工作量评估方法

常用的工作量评估方法在测试项目管理中或编写测试计划时，经常需要对某个测试工作进行工作量的预算，很多时候都是凭个人的工作经验进行估算的，如能结合一些常规的估算方法，有助于估算的精确度。 以下是网上找到的一些常规的估算测试工作量的方法： 1、Ad-hoc方法 这种方法下的测试工作量不基于任何确定的期限。工作一直继续直到达到一些由管理或市场人员预先定下的时间表。或者，一直到用完了预算的经费。这种情况普遍存在于非常不成熟的组织，并且时常有100%的错误差数。 2、开发时间的百分比法Percentage of development time。 这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。首先，开发工作量使用例如LOC或FP方法被估算出来，然后使用一些探索性的方法来限制测试的工作量。这种方法变化比较大而且通常基于以前的经验。 通常预留项目的总花费时间的35%给测试。？5-7%给组件和集成测试？18-20%给系统测试？10%给接收测试（或回归测试等） 3、类比法（经验值法或历史数据法） 根据以前或相似项目（主要在项目性质，领域，规模上有相似）所积累的经验或历史数据来估算工作量。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。需要收集以下相关的历史数据：？在设计和实现阶段花费的时间？测试工作的规模，例如用户

需求的数量，页面数，功能点？数据样式，例如实体，字段的数量？屏幕或字段数量？测试对象的规模，例如KLOC 4、WBS（work breakdown structure）估算法 将项目或产品分解为具体的工作，然后分别对各个工作进行时间估算，最终求和得出项目或产品的测试工作量/时间。 5、Delphi法 Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种相关经验人的参与，互相说服对方…… Delphi法的步骤是：1、协调人向各专家提供项目规格和估计表格；2、协调人召集小组会各专家讨论与规模相关的因素；3、各专家匿名填写迭代表格； 4、协调人整理出一个估计总结，以迭代表的形式返回专家； 5、协调人召集小组会，讨论较大的估计差异； 6、专家复查估计总结并在迭代表上提交另一个匿名估计； 7、重复4-6，直到达到一个最低和最高估计的一致。 6、PERT估计法 PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计。Pert 估计可得到代码行的期望值E，和标准偏差SD 1．软件开发价格估算方法 软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便于计算，给出一个计算公式：

员工工作量的评估和管理

POLICY NO: 5.6.17 EV ALUATION AND MANAGEMENT OF STAFF WORKLOAD OBJECTIVE To ensure that all employees has access and opportunity to liaise with management in relation to their workload if they perceive it to be excessive. POLICY STATEMENT The Town acknowledges that excessive workload, whether real or perceived can be a contributing factor in stress related psychological illness. Date Adopted: 21 December 2004 Date Amended: - Date Reviewed: - Date of Next Review: December 2009

GUIDELINES AND POLICY PROCEDURES FOR EVALUATION AND MANAGEMENT OF EMPLOYEE WORK LOAD – POLICY NO 5.6.17 The Town is committed to affording all employees the opportunity for review of workload on request and will take appropriate action should intervention be required. Employees are encouraged to discuss workload issues with their line management, but if they are unable to resolve the issues, a formal process will be undertaken. This action can be initiated by any employee providing they are willing to fully participate in the workload evaluation and subsequent processes. Those unable to participate in the process for any reason, must submit a written outline of issues pertaining to workload and reasons why they perceive the load excessive. They may also nominate a peer to represent their interests. Employees may also raise workload issues with their supervisor or Executive Manager, the Occupational Safety and Health representative, or directly with the CEO if they feel unable to address the issue with the above channels. The Town's Managers and Supervisors will ensure that those who seek workload evaluation will not be victimised or compromised in any way by their actions. The workload reviews will be supervised by the Manager Human Resources and the results and actions required will be forwarded to the CEO for ratification. Action will be taken against any level of management who is found to be discouraging or preventing employees from accessing an independent workload review. As a matter of course, all employee duty statements and workloads will be reviewed annually as part of the performance appraisal process. Workload Evaluation Process A review of the Job Purpose, Duties, Key Performance Indicators (KPIs) and Performance Measures will be carried out by a manager or supervisor from a different division, section or team as deemed appropriate and approved by the CEO. The employee will keep a work diary for two weeks (or longer if deemed appropriate) relating to tasks carried out, phone calls, meetings and customers interfaces. This will be evaluated against the job purpose, KPIs and Duty statements. An audit of the skills and training required to undertake the identified tasks and actions will be carried out at this stage, including interpersonal skills in dealing with customers and peers.