软件研发人员考核的基本原则
软件研发人员的考核一直是软件企业管理的难点，总结了进行软件研发人员考核的一些基本原则，整理出来与大家共享：
要体现公司的价值观
公司的价值观体现了公司认可什么类型的人员？要挽留哪些人？提倡做什么？对这些人员的认可可以通过具体的考核办法落实下来。比如企业鼓励在某一个业务领域内积累丰富的领域经验，鼓励在某个技术方向上进行深入钻研等，对于提倡的这些行为，要有具体的奖励措施。所以在定义考核办法时，需要首先考虑清楚要体现企业的哪些价值观。
要体现多劳多得，质与量并重
不能让那些完成了大量艰苦工作的人员吃亏，否则就会打击真正努力工作的人员的积极性。多劳多得原则的实现，基于对工作量的计算。规范的管理都是“以人为本、以过程为核心、以度量为基础”的。要做到多劳多得就需要做好对工作量的度量，如果仅仅注重工作量而不关注工作质量，显然是不对的，而对于质量的考核，可以通过多个渠道来获得数据，如发现的缺陷个数、客户的反馈等等。
当然多劳多得的前提是团队的目标达成了，如果目标未完成，多劳未必多得。
要鼓励创新与规范管理
管理与创新是软件企业发展的2个轮子，通过规范管理可以确保企业的常规发展，通过创新实现企业的跳跃式发展，管理为创新提供了转化为生产力的基础，创新可以快速地提高企业的竞争能力，因此在考核办法中要体现出来对这2者的认可。有的企业设立了创新基金，专门用来奖励那些技术创新、管理创新等，有的企业在研发人员的考核指标中加入了对过程改进工作的支持等指标。
要鼓励技术复用
成功的软件企业必须在人员、技术、过程三个方面加大投入。软件复用是目前软件公司提高软件生产率的最有效的手段之一，为了在企业内建立组织级的技术复用体系，首先就要鼓励大家主动去提取可复用的各种构件，主动贡献可复用的构件。对于这种提取可复用构件的行为，应根据其可能带来的收益，适当给予奖励。
要因时而变，但要尽可能保持连续性
考核办法的制定都有一定的针对性，具有一定时限性，随着公司内外部环境的变化，随着公司文化的逐步稳定，对考核办法要逐步调整，在改变考核办法时，要注意保持考核办法的连续性，不要变化太大，否则就会让被考核人无所适从，产生观望的心态，或者在研究考核办法上花费很多时间，造成不必要的生产效率的下降。
要量化与非量化结合
如果没有量化的考核指标，全靠非量化的指标，对于开发人员来讲，很难体现多劳多得的原则，很容易走向“吃大锅饭”的模式，无法调动开发人员的积极性。如果全量化也很难，在开发过程中，有很多工作难以量化，比如需求开发的工作，就很难定量的计算工作量。因此在考核时，在尽可能量化的基础上，也允许有一些非量化的指标的存在。至于2者的比重，可以根据当前企业的管理水平来确定。对于管理比较规范的企业，成熟度比较高的企业，可以采用量化的指标多一些，量化的比重大一些。
要区分不同的岗位，不能一刀切
对于项目经理、需求分析人员、设计人员、程序员、测试人员、质量管理人员等，工作性质、能力要求、绩效表现的特征都有比较大的差别，因此要区别对待。这样便于体现考核办法的内部公平性与外部公平性。比如对于质量管理人员，大部分是日常的事务性的工作，其工作业绩的体现是长期的，他们的工作重心是预防缺陷的产生，采
用量化的数据就比较困难，可以考虑采用改进率等指标来考核，而程序员的主要工作是实现设计，任务的规模与他们的工作效率、质量是可以量化的，这2种类型的考核办法就应该是不同的。
要保证被考核人的及时知情权
事先要将考核办法告知被考核人，考核结果要及时通知被考核人。考核的目的是为了发现改进工作业绩的方法，激励员工更加努力地工作，考核办法也代表了公司的价值观，因此要让被考核人对考核办法很清楚，让他们知道什么是应该努力去做好的，这样才能起到激励作用。考核的结果应及时通知被考核人，这样能够给他们一个及时的肯定或者否定的刺激信号。
不以被考核人自己提供的数据为考核依据
如果以被考核人自己提供的数据作为考核依据，则会造成数据的失真。在软件企业中推行开发人员的个人日志时，遇到的最大的问题就是日志的失真问题，为什么呢？因为开发人员担心自己填写的日志会成为自己的考核依据，会成为评价自己的工作努力程度的依据，因此本能地会倾向于满负荷地填写自己的工作量。
考核指标要和被考核人直接相关，被考核人对考核指标的达成能发挥重要的作用
在很多软件公司中，经常发现员工的考核与公司的利润、部门的利润或者项目的利润挂钩，对于销售部门、事业部或者其他直接与市场相关部门，这种考核是有激励作用的，对于研发人员来讲，这种办法的激励作用就不那么明显了。利润的形成有多方面的原因，可能大部分原因不是开发人员所能决定的，将不由开发人员所决定的因素与其考核挂钩，是不合理的，即使开发人员再努力，也不能对利润的形成起到实质性的帮助作用，为什么要和利润挂钩呢？
古人云：知易行难。道理很简单，落实时却涉及了企业的方方面面，有历史的原因，有现实的问题，有未来的不确定性，但是这些都不应该成为逃避考核问题的理由，必须去尝试，才有可能解决这个问题！
如何量化考核软件开发人员绩效
软件人员管理，一向被认为是一件难题。尤其是年中年底的评价问题，涉及到加工资，发奖金，稍有差池，就会民怨沸腾，来年是该走的不走，不该走的全走了。
在开始一个软件项目之前，公司领导要与该项目主管对需要完成的工作内容、时间期限、考核的标准达成一致。项目主管把任务进行分解，和每个软件开发人员对各自所需完成的工作内容、期限和考核标准达成一致，特别是各个模块之间的接口，并形成一份完整的“任务说明书”。在期限结束时，主管根据每个开发人员的工作状况及原先制定的考核标准来进行考核。为了避免到最后才发现问题过多、难以收拾，可以在开发期间设置几个考核点，设置相应的阶段性目标，根据完成目标情况给出考评的分数。
开发人员应具有较强的事业心、责任感和较深厚的基础理论知识，并不断提出新的思想和观念，为创造新产品和新技术提供条件。通常研发一个软件项目所需的时间较长，我认为按项目的里程碑或项目来安排对软件人员的考核，若项目周期超长也可在年中和年末进行考核，以目标管理(Management By Objectives，简称为MBO）为原则设定KPI (Key Performance Index)，考评分用技术指标决定，如工作量用完成的功能点来衡量，工作质量用每千行代码Bug数衡量，技术人员会认为这很公平，从而有动力更努力。
根据客户关注点确定考核指标，同时将客户的满意度与做为考核的衡量标准，一个项目完成后，公司不要把该项目的奖金一下子全发给软件人员，可以留下30%～40%待一年后发放，给客户一年的时间发现问题，软件公司可根据问题的大小从余下奖金中相应扣除。
用下面的七项指标对开发人员进行绩效考核评定：
1. 工作态度
2. 软件质量(bug的等级和个数，回归次数，重要模块系数)
3. 工作难易度(功能性，可靠性，易使用性，高效性，可维护性和可移植性，功能点数，复杂度)
4. 工作效率/能力(完成百分比，工作经验)
5. 主动性
6. 沟通能力
7. 程序规范程度
1) 非常及时，随时都可以查阅任意相关文档；
2) 非常规范，较及时，随时可以查阅近期文档，文档编写滞后3天以内；
3) 较规范，较及时，一般可以查阅近期文档，文档编写滞后3～6天；
4) 较规范，但不及时，常常难以查阅，文档编写滞后6天以上；
5) 不规范，不及时，常常难以查阅，甚至没有编写相关文档。
代码应该有统一的代码库管理，而不是只保存在程序员个人手里；Bug也要存在缺陷管理库中，不是只是去跟程序员讲一下。每个项目结束时，每项统计指标的计算也是烦琐的工作，需要人力和耐心。
微软公司对软件人员的绩效考核每半年进行一次，先由员工自己为这半年来的业绩做一个评估，打一个分数，然后放到网上，等待部门经理签字、打分。没有经过部门经理打分、签字的信息呈红色; 经理打完分后，如果员工认为经理的评价比较符合事实，再进行最后的确认，确认后信息变为绿色，业绩考核的过程就完了。此外，部门经理打分的同时还要为每位员工制定下个半年的目标。如果员工对经理的评价存有异议，便可以拒绝确认，更高层经理及人力资源部的人员看到后，会与员工沟通，直至查到员工拒签的原因。
也有些知名的IT公司已将软件开发人员的绩效评估建立形成了一个体系，每年有年度的绩效考核，开发部门有开发成本考核。从每年12月开始到第二年1月份的两个月期间，公司上上下下都认真地做绩效考核，因为晋升调薪需要这个依据。考核完后，经理要跟员工面谈，将考核结果告诉他。考核的关键是评估后的沟通，这比评估更重要。让员工知道他的不足在哪里，优势在哪里，员工自己要提出想法。考核后排在后5％的员工要内部下岗，实际上是降工资，留岗观察。
公司软件开发人员绩效评价标准
总则：
通过量化的指标准确的评定软件开发人员的绩效，从而对薪酬分配提供可靠的依据。
基本说明：
绩效评价，包括业绩考核和能力评定。对软件开发人员的绩效评定，每一项问答表现优秀加一分，表现不佳扣一分，表现平平不得分，最后计算总分。
业绩考核：
此项考核主要考核在一定时间内软件开发人员的任务完成情况。主要包括有以下指标：目标的完成度、难易度、贡献度。目标完成度
●完成情况：
能否总是在规定期限内完成工作？或者尚能在规定的时限内完成工作，还是经常需要上级的催促才能按时完成工作，或者一贯拖延工作期限，即便在上级的催促下也不能按时完成工作？
在困难或者环境变化的情况下，是否也完成了计划的工作？
是否很快、很迅速、高标准、高质量、创造性的完成交给的工作？
是否在完成工作的同时，又能很好地控制成本？
如果工作没有完成是由于环境的变化还是个人能力的问题？或者是工作太多了，根本无法完成？
在工作中是仅仅要求完成任务还是主动进行工作流程的改进，高效运用相关资源来解决工作中出现的问题？
上级人员交给其工作时是否放心？
●完成质量：
提交的程序是否经常出现很多BUG？是否经常需要修正或调整？编码是否严格遵守代码规范性？用户对其开发的软件是否满意？
●完成时间：
总是提前完成任务，还是总是强调客观原因而无法准时完成任务？是否经常需要有人催促才能完成工作？
难易度
所完成的工作是否是一般人不愿意干的工作？或者是很烦很累枯燥无味的工作？
所完成的工作是一般程序员都可以充分达成的目标，还是不易达成的挑战性目标？
如果本人不在，本部门或本小组是否有替代的人？
贡献度
其所作的工作对公司创造了多少直接效益？多少间接效益？或者降低了多少成本？
工作完成后的成本情况如何？是否有效地控制成本？
是否在圆满完成本职工作以外，还积极主动地从事其它相关事情？
是否尽力为公司创造最大利益，在各方面尽了最大努力并取得了一定的成果？能力评定：
能力评定是通过对员工的日常工作的工作表现，观察、分析、评价其所具备的工作能力。对其开发人员的能力评定，主要包括以下几项：技术能力、理解力、沟通能力、主动性、团队精神、领导能力。领导能力用于项目经理评价。技术能力
●业务知识：
上级交待工作时是迅速、准确地抓住工作的关键还是反应迟钝，迟迟不能理解？
是否在一个月内就迅速熟悉了新岗位的工作？还是在新岗位工作超过三个月了还对许多业务流程不很熟悉，从而不得不经常问别人？
是否经常有人来请教相关技术问题还是总是有问题问别人？
是否本部门有一些业务只有他熟悉？
●解决问题能力：
在自己的工作中遇到障碍是自己独立解决还是遇到不懂的问题就立刻问别人？
是否一些新知识从未学过，却能很快地上手？
是否为实现目标和解决问题努力寻找合理的新方案？
遇到难题，是否能坚持不懈地完成工作？
●市场能力：
在编写程序时是否总是考虑使用者的需求？
在编写程序时是注重界面的实用性、客户的满意度还是老谈所谓的概念，技术？
●工作效率：
在工作中是否有很强的工作效率意识？
是否总是比别人快地完成任务？
理解力
是否总是迅速地掌握部门或上司的方针，并准确地反映到程序开发当中？同时常常能够立刻提出更好的解决方案？
是否迅速理解客户的需求？
布置任务是否不能很快理解，总是反复询问？
交待任务时是否总是显示出迷惑不解的表情？
沟通能力
是否能够很好地和同事相处？是否乐于帮助别人？特别是对后来者给与积极帮助？
对上司、外来人员的言谈举止是否富有礼节？
是否给人以诚实、开朗的印象？
是否属于高傲的人？是否很少有朋友，而且常与人有无谓的争执？
和人谈话时是否认真倾听对方的诉说，虚心接受对方的意见？
主动性
是否对公司的状况提出过建议、意见和合理化建议？
开发程序中是否努力改善工作质量，以一贯的态度将工作从头到尾做完，并使程序尽善尽美，一定要把工作做完才离开公司。还是常说“算了，就这样吧？！”之类的言语？
在工作中给人的感觉是踏实，有始有终还是懒懒散散，吊儿郎当？
上班时是否常打私人电话，是否经常浏览不相关的网页？
是否上级没有具体指示之前自觉完成业务？是否经常寻找与自己业务相关的业务做？
是否积极学习业务知识？对其不在监督也能迅速的完成任务？
是否对上司是否有敷衍的情况？是否有辞职或调动的打算？是否经常对公司抱怨？是否对别人不愿意干的工作也主动承担？
是否具有不满足于现状，积极奋进的精神还是有过一天算一天的想法？
团队精神
●纪律性：
是否遵守理解公司各种规章制度而努力？并能规劝他人?
是否努力理解上级的批命令并圆满的贯彻执行？
是否严格遵守工作时间？有无经常迟到、早退、无故缺勤的情况？
在工作时间里是否热衷于工作？
●主人翁精神：
是否存在浪费的现象？
是否经常利用职务之便为自己牟利？
是否注意收拾和整理工作场所？
●协作性：
是否能和同事很好的合作？是否使人觉得经常多嘴多舌、指手划脚？是否不推不动，只求自己方便、合适？
是否经常支持并积极参加公司各种活动？
领导能力
是否能组织手下员工高效地工作？
是否能促使本组员工和睦相处、团队协作？
是否能关心手下员工，鼓励优秀、批评落后？
是否积极地帮助手下员工？
软件公司研发人员绩效考核制度 1总则 1.1绩效考核的LI的是通过对既定考核指标的评定，发现和评价员工在考核周期内的工作中存在的成绩与不足，督促员工积极进步，实现员工与企业共同发展的忖标。 1.2以客观事实为依据。 1.3以考核制度规定的内容、程序与方法为准绳。 1.4考核力求公平、公正。 1.5此制度适用于公司研发人员。 2绩效考核的职责与权限 2.1考核部门的职责与权限 2.1.1人力资源部是考核工作的组织者和指导者，负责制定有关绩效考核的原则、方针和政策；拟订考核制度和考核工作计划；组织和协调各部门的考核工作；设计符合研发岗位特点的考核办法。 2.1.2各适用部门是绩效考核办法的执行者。 2.1.3直接上司是其下级的主要考核者；考核者针对员工绩效考绩表所列内容对被考核者逐项评定，考核结束后，考核者必须让被考核人了解到工作中取得的成绩与存在的不足。 2.1.4下级对上司的考核拥有申诉权，如个人认为考评结果不公平，可向公司人力资源部部反映 2.2考核者与被考核者的职责与权限。 221考核者代表公司，按照既定的统一的评定标准，公平、公正地考评下级。考核者要准确地把握考核规则和考核尺度，杜绝主观因素的影响。 2.2.2被考核者应明确自己的工作职责和考评的评判标准，对自己的工作有一个客观的评价, 并有向公司综合部申述的权利。 3绩效考核内容 研发人员绩效考核内容分为工作任务、工作质量、工作效率、工作态度、规章制度、奖励机制和惩罚措施七部分，按照不同工作岗位设置不同的考核指标，并作为评判标准。 4绩效考核细则 4.1公司的绩效考核采用月考核制，员工应于每月3日前提交个人当月月工作计划，并以此作为本月考核中工作任务的依据。（见附件1） 4.2每月3日前，员工对上月工作完成自评并将绩效考核表提交至部门负责人处；每月7日
软件测试的十大原则 文章出处：博客作者：朱少民发布时间：2006-08-16 原则是最重要的，方法应该在这个原则指导下进行。软件测试的基本原则是站在用户的角度，对产品进行全面测试， 尽早、尽可能多地发现Bug, 并负责跟踪和分析产品中的问题，对不足之处提出质疑和改进意见。 零缺陷(Zero-Bug) 是一种理念，足够好（Good-Enough）是测试的基本原则。 在软件测试过程中，应注意和遵循的具体原则，可以概括为十大项： 1.所有测试的标准都是建立在用户需求之上。正如我们所知，软件测试的目标就是验证 产品的一致性和确认产品是否满足客户的需求，所以测试人员要始终站在用户的角度 去看问题、去判断软件缺陷的影响，系统中最严重的错误是那些导致程序无法满足用 户需求的缺陷。 2.软件测试必须基于“质量第一”的思想去开展各项工作，当时间和质量冲突时，时间 要服从质量。质量的理念和文化（如零缺陷的“第一次就把事情做对”）同样是软件 测试工作的基础。 3.事先定义好产品的质量标准。有了质量标准，才能依据测试的结果对产品的质量进行 正确的分析和评估，例如，进行性能测试前，应定义好产品性能的相关的各种指标。 同样，测试用例应确定预期输出结果，如果无法确定测试结果，则无法进行校验。 4.软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试。在代 码完成之前，测试人员要参与需求分析、系统或程序设计的审查工作，而且要准备测 试计划、测试用例、测试脚本和测试环境，测试计划可以在需求模型一完成就开始， 详细的测试用例定义可以在设计模型被确定后开始。应当把“尽早和不断地测试”作 为测试人员的座右铭。 5.穷举测试是不可能的。甚至一个大小适度的程序，其路径排列的数量也非常大，因此， 在测试中不可能运行路径的每一种组合，然而，充分覆盖程序逻辑，并确保程序设计 中使用的所有条件是有可能的。 6.第三方进行测试会更客观，更有效。程序员应避免测试自己的程序，为达到最佳的效 果，应由第三方来进行测试。测试是带有”挑剔性” 的行为，心理状态是测试自己 程序的障碍。同时对于需求规格说明的理解产生的错误也很难在程序员本人测试时被 发现。 7.软件测试计划是做好软件测试工作的前提。所以在进行实际测试之前，应制定良好的、 切实可行的测试计划并严格执行，特别要确定测试策略和测试目标。 8.测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去 设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。除了检 查程序是否做了应该做的事，还要看程序是否做了不该做的事；不仅应选用合理的输 入数据，对于非法的输入也要设计测试用例进行测试。 9.不可将测试用例置之度外，排除随意性。特别是对于做了修改之后的程序进行重新测
软件开发团队 绩效考核制度 湖南XX科技发展有限公司
目录 1目的 (1) 2方法和原则 (1) 3适用范围 (1) 4绩效考核 (1) 5项目考核内容和各阶段考核所占权重 (1) 6项目目标调整 (2) 7项目考核内容 (2) 7.1、项目进度考核 (3) 7.2、项目质量考核 (3) 7.3、项目客户满意度考核 (4) 7.4、技术资料汇总考核 (4) 9项目成员考核 (4) 10考核中的沟通与绩效考核 (5)
1目的 为更好地完善公司项目管理和软件团队内部管理机制，保证项目的按期、高效、高质完成，促进团队和员工自身的发展，特制订本制度。 2方法和原则 1、绩效考核采用项目考核和个人考核相结合的方法，以项目考核为主，个人考核为辅。 （1）、项目考核是指以项目为单位，在项目过程中，对项目所涉及的团队的阶段工作成果进行评估；在项目完结后，对参与项目的人员进行绩效考核。 （2）、个人考核是指以团队为单位，项目负责人对其项目成员的工作业绩、工作态度、团队合作等方面进行评估。 2、项目考核采用主要采用定量的原则，个人考核主要采用定性的原则。 3适用范围 本制度适用于软件开发团队所有员工。 4绩效考核 1、项目考核，项目考核分为二级考核体制，即项目考核和项目成员考核。 （1）、项目考核：项目正式立项后，由项目经理拟定《项目目标任务单》（附件1），确定项目组在该项目中项目进度、项目质量、客户满意度和技术资料汇总目标，由项目经理和项目负责人签字确认。 相应项目按照需求分析、软件设计、程序编码、软件测试、运行维护五个阶段依据《项目进度考核表》（附件2）、《项目质量考核表》（附件3）、《项目客户满意度考核表》（附件4）和《项目技术资料汇总考核表》（附件5），对项目开发情况进行评分。 （2）、项目成员考核：项目负责人接到项目后，依据项目任务单，分配任务到本组相关员工。在该项目完结后，由成员直属上司依据《项目个人工作业绩考核表》（附件6），综合项目考核得分采取强制分布，对员工项目个人业绩进行评分。 （3）、年底进行个人年度绩效考核，综合《项目个人工作业绩考核表》（附件6）及《工作态度考核表》（附件7）、《工作能力考核表》（附件8）综合评分，由项目经理填写《年度绩效考核表》（附件9）。 5项目考核内容和各阶段考核所占权重 1、项目考核内容分为项目进度、项目质量、客户满意度和技术资料汇总四个方面，其
软件测试标准 前言 前一版的《软件测试标准》，在测试工作中发挥了很好的指导作用。本次修改在原标准基础上，提出了新的测试理念、工作方法、组织方式，使之更贴近实际工作，真正起到纲领的作用。 一、软件测试 1、软件测试的目的 软件测试是指为了度量和提高被测试对象的质量、对测试对象进行工程设计、使用和维护的与软件开发过程并发的生命周期过程。软件测试的目的为：验证软件产品的实现状态以及实现质量。 2、软件测试相关概念 2.1白盒测试 指基于程序结构的测试，测试目标是检查程序内部逻辑结构和逻辑路径，是代码级的测试。 2．2黑盒测试 基于程序功能的测试，根据输入输出的关系推断程序功能的正确性。 2．3测试用例 测试方案，包括数据输入和相应的期望输出。依据测试用例来执行具体操作。 2．4预防性测试 其原理为：只要测试在生命周期中进行得足够早，就能够提高待测软件的质量。 2．5测试风险分析 其目的为：确定测试对象、测试的优先级、测试的深度。 2.6软件测试模型 公司目前采用V模型，实现测试与软件开发的同步进行。
2.7等价类划分 将测试对象按某种约定划分为有限个组成部分，提高测试的有效性。 2.8边界值分析 分析测试对象的所有边界值及边界附近的临界值。 二、测试工作流程 需求分析审核需求分析，编写验收测试部分用例 实地调研重点收集客户实际业务资料、操作习惯，并与需求分析作出对比 概要设计审核概要设计，从用户角度提出问题 编写集成测试用例 详细设计 审核详细设计报告，与需求分析、概要设计进行比对编写单元测试用例编写用户手册总体框架单元测试阶段提出测试计划 审核测试用例 执行测试 测试总结 集成测试阶段验收测试阶段 补充测试用例资料归档 修改测试 审核修改计划程序员提供修改清单编写测试用例执行测试 测试总结 复测测试报告复测测试用例复测 三、开发—测试流程
软件研发部绩效考核方案 为加强对软件研发部门员工的技术能力、所做贡献的客观准确评价，以项目实效为导向，建立良性的技术晋升激励机制，特制订本绩效考核方案，本方案适用于软件研发部软件工程师、软件测试工程师、研发助理及质量工程师人员，具体如下： 一、岗位工资结构及绩效考核基数： 薪酬分配方式：岗位工资制。岗位工资结构：基本工资（月薪标准的50%）+岗位工资（月薪标准的30%）+绩效工资（月薪标准的20%）+交通补贴+伙食补贴+奖励考核+加班费+其他福利补贴。 绩效考核方案以绩效工资即月薪标准的20%作为考核基数，考核周期为每月进行一次考核，每月根据考核评估的总分值核算绩效工资，绩效工资核算根据考核总分值进行上下浮动， 对应绩效考核总分值兑现为月度绩效工资为： 二、绩效考核指标、考评标准、权重 将所有岗位的绩效考核指标内容分为工作业绩、工作态度、工作能力三部分，分别占有相应权重。
（二）工作态度考核关键指标（100分，权重15%）
（三）工作能力考核关键指标（100分，权重15%） （四）对项目开发和部门相关工作作出特殊贡献的给予加分的项目
对于项目开发和部门相关工作作出特殊贡献的给予加分的由部门负责人和分管副总进行评定，给予加分的需对加分项目和贡献情况进行说明，加分不得超过20分。 关键绩效考核指标总分值=工作业绩考核关键指标评分*70%+工作态度考核关键指标评分*15%+工作能力考核关键指标评分*15%+对项目开发和部门相关工作作出特殊贡献的加分。 二、其他工作指标考核内容 1、部门日常工作要求的事项完成情况考评：对其上级领导安排的工作和本岗位工作职责范围内的工作、工作态度等根据完成的时间和质量要求、工作态度好坏进行考核评定，非常优秀的可给予20-100元奖励，非常差的给予20-100元考核，此项奖励考核由部门负责人和分管副总进行评定，所有奖励考核均由分管副总审核。 2、部门所要求参与的会议/活动/培训等的参与次数及学习成果考评：公司和部门安排的会议/活动/培训要求相关人员必须参加的无特殊情况而无故不参加的给予20-50元考核，对于培训后组织的定期和不定期的培训考试，考试成绩不及格者按每次考核20-50元考核，对于以上考核属于个人特殊情况需减免考核的报请减免请示部门负责人和分管副总进行审批。 3、为了提高开发效率，积极鼓励提供好的建议，产品思路或方式方法，对于采纳的建议，如根据其执行方案对产品架构及公司发展起到明显改进效应的，将给予一定的奖励，奖励金额由分管副总和总经理进行确定。 4、产品研发项目奖励：根据产品研发项目计划，在计划进度内按质按量完成研发项目的，经测试验收合格的给予研发团队500-5000元奖励，奖励分配由该项目负责人和分管副总按照项目小组成员的贡献进行分配。 5、由公司制度对应的考核项目对其进行的奖励和考核，奖罚金额由制度所对应的管理部门依据制度条款进行确定。 6、员工个人对于部门和公司管理、产品、安装、销售等提出建议、提升、创新变革措施等/为公司生产经营做出突出贡献的，公司予以认可采纳的给予员工200-2000元奖励；同时给公司造成重大影响或损失的给予50-1000元考核，奖罚金额由总经理进行审定后确定，各部门和个人可进行奖励申请报批。 7、公司评定的优秀员工奖励：按照公司相关评定标准和奖励额度政策和通知执行。 8、其他需奖励和考核的项目：其他需进行奖励和考核的项目由奖励考核人进行提请，报由部门负责人、分管副总、总经理进行审批后确定。 三、关于绩效考核结果的反馈、申诉、处理和绩效面谈
软件测试规 1目的 确保软件产品质量，使产品能够顺利交付和通过验收的一项重要措施。 2适用围 适用于项目开发过程中的单元测试、集成测试、系统测试、业务测试、验收测试以及一些专项测试。 3职责 ?项目测试负责人组织编制《测试计划》、《测试方案》，指导和督促测试人员完成各阶段的测试工作。 ?项目组测试人员按照《测试计划》、《测试方案》完成所承担的测试任务，并按要求填写《问题报告及维护记录》。 ?测试经理依照确认规程和准则对工作产品进行确认，提出对确认规程和准则的修改意见 ?项目负责人组织测试环境的建立。 ?项目经理审核负责控制整个项目的时间和质量。 ?研发人员确认修改测试人员提交的bug。 4工作流程 4.1 测试依据 详细设计是模块测试的依据。因此设计人员应向测试人员提供《系统需求规格书名书》、《详细设计》、《概要设计》等有关资料。测试人员必须认真阅读，真正弄懂系统需求和详细设计。 4.2 制订《测试方案》 在测试之前，由项目负责人根据《测试计划》的要求，组织人员编制相应的《测试方案》，《测试方案》应包括以下容：
?测试目的； ?所需人员及相应培训要求； ?测试环境、工具和测试软件； ?测试用例、测试数据和预期的结果。 4.3 单元测试 项目开发实现过程中，每个程序单元（程序单元的划分视具体开发工具而定，一般定为函数或子程序级）编码调试通过后，要及时进行单元测试。 单元测试由单元开发者自己进行，使用白盒测试方法，根据程序单元的控制流程，争取达到分支覆盖。对于交互式运行的产品，不便于进行自动测试的，可以采用功能测试的方法进行。 单元测试针对程序模块，从程序的部结构出发设计测试用例。多个模块可以独立进行单元测试。 ?单元测试容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试等； ?单元测试组织原则一遍根据开发进度安排对已开发完成的单一模块进行测试； ?单元测试停止标准：完成了所有规定单元的测试，单元测试中发现的bug已经得到修改。 4.4 集成测试 编码开发完成，项目组部应进行组装测试。 集成测试由项目负责人组织策划（编写测试计划、测试用例）并实施。集成测试着重对各功能模块之间的接口进行测试，验证各功能模块是否能协调工作、参数传递及功能调用是否正常。测试采用交叉方法，即个人开发的软件应由其他的项目组成员进行测试。 集成测试过程应填写《问题报告及维护记录》，测试结果应形成《测试报告》。 4.5 系统测试 在项目开发完成之后，应对整个系统软件和硬件进行系统测试。对性能、可靠性、健壮性、压力承受力等方面分别进行评价，以验证系统是否满足
软件实施团队绩效考核程序 为了确保团队以及个人的目标与公司整体目标的一致性，为了激励并影响员工实现公司目标，特制定本程序。目的是： 1.影响员工的决策、行为和公司发展目标保持一致； 2.更加妥善的处理内部团队间的协同； 3.统计的运营成果和员工业绩数据。 本程序的核心是由“业绩指标”、“技能考评”、“工作评价”、“工作量统计”、“成本控制”共5类控制项组成，根据不同的绩效角度定义不同的受控项，具体如下： 第一章绩效角度 1.薪酬调整 从工作能力及工作完成情况的角度评估员工是否能够胜任该项工作，“薪酬调整”是对评估结果的执行体现。 考核周期：12个月。 考核指标：“业绩指标”、“技能考评”、“工作评价” 具体操作 部门根据年初公司软件业务的经营目标，结合往年的历史数据，测算出今年的“业绩指标”数，报公司总裁室审批。审批通过后，部门内部讨论个人“业绩指标”，个人“业绩指标”确定后参考“技能考评”与“工作评价”的评定结果确定个人的薪酬等级，报公司总裁室批准后执行。具体详见《薪等表》。 2.绩效工资 从工作效率、工作态度的角度评估员工是否在有效的执行公司的市场策略，“绩效工资”是对评估结果的执行体现。 考核周期：3个月。
考核指标：“业绩指标”、“技能考评”、“工作评价”、“工作量统计”、“成本控制” 具体操作 员工工资的30%为“绩效工资”；（注：“基本工资”为员工工资的70%） 普通员工的应发“绩效工资”的计算公式为： “绩效工资”*“工作量统计”*部门“业绩指标” 项目经理的应发“绩效工资”的计算公式为： “绩效工资”*“工作量统计”*“成本控制”*部门“业绩指标” 部门经理的应发“绩效工资”的计算公式为： “绩效工资”*“成本控制”*部门“业绩指标” 3.绩效奖金 从工作效益的角度评估员工是否在有执行公司的市场策略的同时为公司创造了收益（包括：经济效益和社会效益），“绩效奖金”是对评估结果的执行体现。 考核周期：12个月。 考核指标：根据不同的岗位类型制定具体的考核指标及其对应的权重系数，具体如下： 岗位岗位系数受控项权重系数 分管副总经理年薪考核业绩指标50%成本控制30%工作评价20% 部门经理15%业绩指标50%成本控制30%工作评价20% 项目经理30%业绩指标50%工作评价20%技能考评10%成本控制20% 工程师45%业绩指标50%工作评价30%技能考评20%
软件公司研发人员绩效考核制度 1 总则 1.1绩效考核的目的是通过对既定考核指标的评定，发现和评价员工在考核周期内的工作中存在的成绩与不足，督促员工积极进步，实现员工与企业共同发展的目标。 1.2以客观事实为依据。 1.3以考核制度规定的内容、程序与方法为准绳。 1.4考核力求公平、公正。 1.5此制度适用于公司研发人员。 2 绩效考核的职责与权限 2.1 考核部门的职责与权限 2.1.1 人力资源部是考核工作的组织者和指导者，负责制定有关绩效考核的原则、方针和政策；拟订考核制度和考核工作计划；组织和协调各部门的考核工作；设计符合研发岗位特点的考核办法。 2.1.2 各适用部门是绩效考核办法的执行者。 2.1.3直接上司是其下级的主要考核者；考核者针对员工绩效考绩表所列内容对被考核者逐项评定，考核结束后，考核者必须让被考核人了解到工作中取得的成绩与存在的不足。 2.1.4 下级对上司的考核拥有申诉权，如个人认为考评结果不公平，可向公司人力资源部部反映 2.2考核者与被考核者的职责与权限。 2.2.1考核者代表公司，按照既定的统一的评定标准，公平、公正地考评下级。考核者要准确地把握考核规则和考核尺度，杜绝主观因素的影响。 2.2.2被考核者应明确自己的工作职责和考评的评判标准，对自己的工作有一个客观的评价，并有向公司综合部申述的权利。 3 绩效考核内容 研发人员绩效考核内容分为工作任务、工作质量、工作效率、工作态度、规章制度、奖励机制和惩罚措施七部分，按照不同工作岗位设置不同的考核指标，并作为评判标准。 4绩效考核细则 4.1 公司的绩效考核采用月考核制，员工应于每月3日前提交个人当月月工作计划，并以此
软件开发团队绩效考核制度
湖南XX科技发展有限公司 目录 1目的 (1) 2方法和原则 (1) 3适用范围 (1) 4绩效考核 (1) 5项目考核内容和各阶段考核所占权重 (2) 6项目目标调整 (3) 7项目考核内容 (3) 7.1、项目进度考核 (3) 7.2、项目质量考核 (4) 7.3、项目客户满意度考核 (4) 7.4、技术资料汇总考核 (5)
9项目成员考核 (5) 10考核中的沟通与绩效考核 (6)
1目的 为更好地完善公司项目管理和软件团队内部管理机制，保证项目的按期、高效、高质完成，促进团队和员工自身的发展，特制订本制度。 2方法和原则 1、绩效考核采用项目考核和个人考核相结合的方法，以项目考核为主，个人考核为辅。 （1）、项目考核是指以项目为单位，在项目过程中，对项目所涉及的团队的阶段工作 成果进行评估；在项目完结后，对参与项目的人员进行绩效考核。 （2）、个人考核是指以团队为单位，项目负责人对其项目成员的工作业绩、工作态度、团队合作等方面进行评估。 2、项目考核采用主要采用定量的原则，个人考核主要采用定性的原则。 3适用范围 本制度适用于软件开发团队所有员工。 4绩效考核 1、项目考核，项目考核分为二级考核体制，即项目考核和项目成员考核。 （1）、项目考核：项目正式立项后，由项目经理拟定《项目目标任务单》（附件1），确定项目组在该项目中项目进度、项目质量、客户满意度和技术资料汇总目标，由 项目经理和项目负责人签字确认。 相应项目按照需求分析、软件设计、程序编码、软件测试、运行维护五个阶段依据《项 目进度考核表》（附件2）、《项目质量考核表》（附件3）、《项目客户满意度考核表》（附件4）和《项目技术资料汇总考核表》（附件5），对项目开发情况进行评分。 （2）、项目成员考核：项目负责人接到项目后，依据项目任务单，分配任务到本组相 关员工。在该项目完结后，由成员直属上司依据《项目个人工作业绩考核表》（附件6），综
精品word文档值得下载值得拥有 软件公司研发人员绩效考核制度 1总则 1.1绩效考核的目的是通过对既定考核指标的评定，发现和评价员工在考核周期内的工作中存在的成绩与不足，督促员工积极进步，实现员工与企业共同发展的目标。 1.2以客观事实为依据。 1.3以考核制度规定的内容、程序与方法为准绳。 1.4考核力求公平、公正。 1.5此制度适用于公司研发人员。 2绩效考核的职责与权限 2.1考核部门的职责与权限 2.1.1人力资源部是考核工作的组织者和指导者，负责制定有关绩效考核的原则、方针和政策；拟订考核制度和考核工作计划；组织和协调各部门的考核工作；设计符合研发岗位特点的考核办法。 2.1.2各适用部门是绩效考核办法的执行者。 2.1.3直接上司是其下级的主要考核者；考核者针对员工绩效考绩表所列内容对被考核者逐项评定，考核结束后，考核者必须让被考核人了解到工作中取得的成绩与存在的不足。 2.1.4下级对上司的考核拥有申诉权，如个人认为考评结果不公平，可向公司人力资源部部反映2.2考核者与被考核者的职责与权限。 2.2.1考核者代表公司，按照既定的统一的评定标准，公平、公正地考评下级。考核者要准确地把握考核规则和考核尺度，杜绝主观因素的影响。 2.2.2被考核者应明确自己的工作职责和考评的评判标准，对自己的工作有一个客观的评价，并有向公司综合部申述的权利。 3绩效考核内容 研发人员绩效考核内容分为工作任务、工作质量、工作效率、工作态度、规章制度、奖励机制和惩罚措施七部分，按照不同工作岗位设置不同的考核指标，并作为评判标准。 4绩效考核细则
4.1公司的绩效考核采用月考核制，员工应于每月3日前提交个人当月月工作计划，并以此作为本月考核中工作任务的依据。（见附件1） 4.2每月3日前，员工对上月工作完成自评并将绩效考核表提交至部门负责人处；每月7日前各部门负责人将评分后的绩效考核表反馈到综合部，并进行当月绩效面谈与沟通。 4.3绩效考核办法 4.3.1绩效考核采取个人考核与部门考核相挂钩的原则，即个人最终考核得分=个人分数x部门系数x公司绩效系数。 4.3.2被考核者的个人分数实行个人先进行自我评定，再由考核者评定得出的原则，以考核者得出分数为准。 4.3.3部门考核系数依据部门人员主动加班工作时长进行判定。研发各部门的考核周期员工平均主动加班时长进行评比，一个考核周期内，部门员工主动加班时间平均值最大的部门，当月考核系数为1.1;部门员工主动加班时间平均值最小的部门，当月考核系数为0.9，居中部门的考核系数为1.0。 4.3.4公司绩效系数分为1.0、0.8、0.6和0四个等级。即绩效工资比例分为100%、80%、60% 和0四个执行等级，依据不同得分等级进行分别处理。 4.3.5员工考勤的规定 a）员工一个月内出现迟到、早退累计达2（含2次）次以上，月考核时不得评为“优秀” 等级；迟到、早退累计达4次（含4次）以上，月考核时不得评为“良好”及以上等级；迟 到、早退累计达6次（含6次）以上，绩效比例按照“较差”等级执行；迟到、早退累计达8次（含8次）以上，绩效比例按照“差”等级执行。 b）员工一个月内请事假累计在1天（含1天）以上不满2天，月考核时不得评为“优 秀”等级，请事假累计在2天（含2天）以上不满3天，月考核时不得评为“良好”及以上等级；请事假累计在3天（含3天）以上不满5天，绩效比例按照“较差”等级执行；请事假累计在5天（含5天）以上，绩效比例按照“差”等级执行。 c）员工请病假，可依据病假证明（包括县级以上医院开具的请假单、在社区医院就医 的证明等），按照实际天数计算绩效比例。员工在一个月内出现病假3天（不含3天）以上不满7天（含7天）的，月考核时不得评为“优秀”等级；病假在7天（不含7天）以上的，月考核时不得评为“合格”及以上等级。 d）员工出现旷工情况，取消当月绩效工资。 4.4绩效工资和考评结果挂钩。
软件测试标准规范 1目的 为了确保软件产品质量，使产品能够顺利交付和通过验收，特编写本文档，以作参考 2适用范围 本文档适用于项目开发过程中的单元测试、集成测试、系统测试、业务测试、验收测试以及一些专项测试。 3职责 ?项目测试负责人组织编制《测试计划》、《测试方案》，指导和督促测试人员完成各阶段的测试工作。 ?项目组测试人员按照《测试计划》、《测试方案》完成所承担的测试任务，并按要求填写《问题报告及维护 记录》。 ?测试经理依照确认规程和准则对工作产品进行确认，提出对确认规程和准则的修改意见 ?项目负责人组织测试环境的建立。 ?项目经理审核负责控制整个项目的时间和质量。 ?研发人员确认修改测试人员提交的bug。 4工作流程 4.1测试依据 详细设计是模块测试的依据。因此设计人员应向测试人员提供《系统需求规格书名书》、《详细设计》、《概要设计》等有关资料。测试人员必须认真阅读，真正弄懂系统需求和详细设计。 4.2制订《测试方案》
在测试之前，由项目负责人根据《测试计划》的要求，组织人员编制相应的《测试方案》，《测试方案》应包括以下内容： ?测试目的； ?所需人员及相应培训要求； ?测试环境、工具和测试软件； ?测试用例、测试数据和预期的结果。 4.3单元测试 项目开发实现过程中，每个程序单元（程序单元的划分视具体开发工具而定，一般定为函数或子程序级）编码调试通过后，要及时进行单元测试。 单元测试由单元开发者自己进行，使用白盒测试方法，根据程序单元的控制流程，争取达到分支覆盖。对于交互式运行的产品，不便于进行自动测试的，可以采用功能测试的方法进行。 单元测试针对程序模块，从程序的内部结构出发设计测试用例。多个模块可以独立进行单元测试。 ?单元测试内容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试等； ?单元测试组织原则一遍根据开发进度安排对已开发完成的单一模块进行测试； ?单元测试停止标准：完成了所有规定单元的测试，单元测试中发现的bug已经得到修改。 4.4集成测试 编码开发完成，项目组内部应进行组装测试。 集成测试由项目负责人组织策划（编写测试计划、测试用例）并实施。集成测试着重对各功能模块之间的接口进行测试，验证各功能模块是否能协调工作、参数传递及功能调用是否正常。测试采用交叉方法，即个人开发的软件应由其他的项目组成员进行测试。
软件研发部员工绩效考核（草案） 一、总则 本试行草案适用于软件研发部的员工绩效考核。本草案的制定旨在确定员工的考核指标，合理的体现绩效，并将绩效与薪酬、分级、晋升、培训等相挂钩，以此带动员工的积极性。 另，QA在项目过程中检查结果也将作为考核数据的重要来源。综合各种措施，保证绩效考核的公平、公正、合理。 本草案将在实践过程中持续改进。 二、员工考核指标 员工考核指标的确立依据以下原则： （1）指标设立体现公司发展战略、部门职责与要求、岗位特点； （2）关键绩效指标（KPI）可量化； （3）指标项宜精不宜多； （4）评分过程中予以全面考核，达到均衡。 根据以上原则，对需求分析、系统设计、程序员、美术设计、客服专员五种岗位的设计了考核关键KPI指标，详见附表。其中，针对组长的考核将结合其岗位考核与业务组工作考核两个方面，各占50%比重。 三、考核方式 考核周期 为实现绩效工资与考核结果相挂钩，将按当前的考核周期即月度进行考核。 考核形式与内容
取消员工互评，KPI指标评价得到的结果即最终的考核结果，考核的KPI 指标，详见附表。 普通员工的考核内容包括工作量、工作质量、工作效率、工作难度、工作态度和信息安全共六个方面。 业务组长的绩效通过对全组工作绩效考核和自身岗位的绩效考核综合体现（各占50%），全组工作绩效考核内容包括业务组工作量、工作质量、工作效率、工作难度、组内建设、各种报告、团队协作，共七方面进行考核。 考核职责 员工考核采用部门经理与组长共同考核的方式进行。鉴于组长对于员工的工作情况更为了解，由组长对员工进行考核。如遇组员借调到其他项目组，那么业务组长需参考项目负责人的建议，然后对该员工进行考核。 业务组长的考核由部门经理负责。 在实际的考核工作中，按以下方式进行考核： 工作量 工作质量 工作效率 工作难度 工作态度 信息安全 全组工作绩效 工作量 工作质量 工作效率
软件项目研发人员绩效考核激励方案 (草稿) 第一条方案设计 1. 公司基本现状及当前面临的主要问题目前，公司面临的主要问题包括： 1) 软件项目开发要求不断增加，项目组不断增加，项目协调工作剧增 2) 维护工作和项目开发工作难以界定，项目计划难以准确制订 3) 原有的年终绩效考核已不再适应目前的开发任务要求，员工工作热情低落 4) 由于一人可能在多个项目中承担责任，项目中矛盾剧增 由此，公司管理层希望能通过改善绩效考核体系解决或缓解企业在软件开发中出现的问题。 2. 基于项目考核的公司研发人员绩效考核方案 根据公司项目开发的实际情况，以项目考核代替部门考核更适应公司现状，并易以实施制定项目考核方案。 第二条项目团队整体考核方案 对于项目总奖金及项目团队各层面奖金总额，采用如下计算方案： 项目总奖金=P*B*项目合同成本 项目管理层奖金=R*项目总奖金 项目成员奖金总额=(1-R)*项目总奖金 项目成员个人奖金=S*项目成员奖金总额 在本方案中，B=(1~10)%, R=(1~50)%公司决策层将根据项目规模，项目难度等因素确定B 的具体取值。 有关PS的计算方案如下， 1.项目团队考核实施根据公司实际情况，项目团队考核具体方案如下所述：考核目标：为了更好地强化研发项目管理，对已经立项的研发项目按照预定的项目考核节点对项目整体完成情况进行考核，从而实现对整个项目团队的考核。 项目团队绩效综合考核P=W1*P1+W2*P2+W3*P3 为了促进项目管理水平的提高，尤其是促进项目计划的准确性，方案对工时考核系数P1和项目总进度考系数P3分员设置了最高值1.5, 1.2;另一方面，从研发和测试部门间均衡性出发，对项目完成质量系数设置最高值2。 上表中各系数权重值为（0~1），并保证如下等式: W1+W2+W3=1 2.考核频率
软件测试完成标准 目录 1.简介 (2) 1.1目的 (2) 1.2范围 (2) 1.3文档结构 (2) 1.4词汇表 (2) 2.软件测试完成标准 (3) 2.1软件测试暂停、完成标准 (3) 2.2单元测试停止标准 (3) 2.3集成测试停止标准 (3) 2.4确认测试停止标准 (3) 2.5系统测试停止标准 (4) 2.6安装测试停止标准 (4) 2.8验收测试停止标准 (4) 2.9缺陷修复率标准 (5) 2.10覆盖率标准 (5) 2.11缺陷等级分类 (5)
1.简介 1.1目的 本文档的目的是为软件单元测试、集成测试、确认测试、系统测试、安装测试、验收测试提供停止标准。 1.2范围 本文档适用于虹信软件股份有限公司所有项目及产品的测试活动。 1.3文档结构 第一部分： 简介，介绍软件停止标准的目的，本标准的适用范围，以及在本文档中使用的词汇的解释。 第二部分： 描述软件单元测试、集成测试、确认测试、系统测试、安装测试、验收测试停止标准。 第三部分： 列出本标准使用的参考文献。 第四部分： 附录 1.4词汇表 缺陷（Defect）：缺陷是对软件产品预期属性的偏离现象。 覆盖率（Coverage rate）：语句覆盖率、测试用例执行覆盖率，测试需求覆盖率等的总称。
2. 软件测试完成标准 2.1 软件测试暂停、完成标准 1)软件系统在进行单元、集成、确认、系统、安装、验收测试时，发现紧急错误 大于等于严重级别错误暂停测试返回开发。 2)软件系统经过单元、集成、确认、系统、安装、验收测试，分别达到单元、集 成、确认、系统、安装、验收测试停止标准。 3)软件系统通过验收测试，并已得出验收测试结论。 4)软件项目需暂停以进行调整时，测试应随之暂停，并备份暂停点数据。 5)软件项目在其开发生命周期内出现重大估算，进度偏差，需暂停或终止时，测 试应随之暂停或终止，并备份暂停或终止点数据。 2.2 单元测试完成标准 1)按照单元测试计划完成了所有规定单元的测试 2)达到了测试计划中关于单元测试所规定的覆盖率的要求 3)软件单元功能与设计一致 4)在单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准 2.3 集成测试完成标准 1)按照集成构件计划及增量集成策略完成了整个系统的集成测试 2)达到了测试计划中关于集成测试所规定的覆盖率的要求 3)被测试的集成工作版本每千行代码必须发现至少2个错误（不含优化级别错误） 4)集成工作版本满足设计定义的各项功能、性能要求 5)在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准 2.4 功能测试完成标准 1)功能测试用例设计已经通过评审 2)按照功能测试计划完成了功能测试 3)达到了功能测试计划中关于功能测试所规定的覆盖率的要求 4)系统达到详细设计定义的各项功能，性能
目标： 为了增强部门测试工程师考核的合理性、科学性，特制定本准则，根据本准则来完成对部门所有测试工程师的考核 目前部门测试团队共有11人，进行多个项目执行的软件测试工作，同时承担着部门大量的随机测试任务、性能测试任务、自动化测试任务 在每一项考核中我们都增加了考核的权数，每个文档、用例、Bug的提交都需要与权数相乘以后才是最终的得分，所有的得分相加将是测试工程师的最终得分 指标： 1、提交测试相关文档的质量 当前部门软件测试过程主要体现测试计划、测试用例、测试报告（会有多个）几个文档，故而对文档的考核将主要依据这几个文档来完成，对文档的质量的考核将在加分、扣分中阐述，文档的质量不满足要求会出现被扣分的情况，但是扣分最多只能扣除本文档带来积分（一般一个文档1分） 文档的考核权数为1 文档总分= 所有文档的总数×0.5 2、测试设计的质量 当前在部门测试过程中，测试设计的工作比重已经逐步增多，从而带来了大量的测试设计工作，测试设计的好坏将直接决定着部门测试水平的高下；我们的测试设计分为测试项和测试用例，由于当前测试管理平台还有待改进，测试用例设计文档中对测试项和测试用例没有严格的区别，故而很难定义、分解两者，目前按照统一的标准来考核 测试设计的考核权数为0.1 测试用例总分= 所有测试用例的总数×0.1 3、Bug的提交情况 对测试中发现的Bug进行分类和定义的目的，是为测试工程师的评价提供量化依据，为Bug的有效性提供参考。在考核过程中，所有的Bug统计都基于项目组确认是Bug的前提下，项目组不认定是Bug的不记入有效Bug中、同时不记入考核积分。 前提保证：目前所有的Bug每个月都会统一汇总公布，故而减少了非正常原因被拒绝的Bug数量，提高了项目经理、BA工程师对Bug的处理准确性 ? 一级Bug（系统崩溃）
绩效考核方案 为加强部门员工的技术能力、所做贡献的客观准确评价，以项目实效为导向，建立良 性的技术晋升激励机制，特制订本绩效考核方案，本方案具体如下： 一、绩效标准： 公司提取项目利润值的 5-15% 作为项目组绩效奖励，项目组成员个人所占比例由组长分 配，当项目组无法协调分配比例的时候由公司合算比例，并拥有最终解释权。 考核周期按照项目周期考核，根据考核评估的总分值核算绩效工资，绩效工资核算根 据考核总分值进行上下浮动，对应绩效考核总分值兑现为月度绩效工资为： 积分总值121 分及以 101-120 分91-100 分71-90 分70 分及以下区间上 小组对应绩 利润值 *15%利润值 *12%利润值 *10%利润值 *7%利润值 *5%效结果兑现 二、绩效考核指标、考评标准、权重 将所有岗位的绩效考核指标内容分为工作业绩、工作态度、工作能力三部分。项目组初始 得分为 100 分，根据评估加减确定最终得分。 （一）工作业绩考核关键指标（权重70% ） 人员类型关键业绩指标考核目标值 实际开发周期比计划周期提前及延后 新产品开发周期 进度延迟1-10% ，减 2 分； 进度延迟11-20% ，减 5分； （月度计算） 进度延迟21-50% ，减 10 分； 进度延迟51% 及以上，减 20分 如提前完成工作，做相同比例加分 项目小组 质量测试，依据普通、严重、致命Bug 计分代码质量 普通 bug ，减 1 分 / 个 严重 bug ，减 2 分 / 个 致命 bug ，减 5 分 / 个 代码编写、注释，凌乱低劣，减1-5 分 代码编写标准 代码编写、注释，符合标准，加1-5 分设计的可生产性根据设计图的可生产性加1-5分 策划对产品需求收集、分析、整理、标注的程 产品需求分析收集 度，视情况加减1-5 分权重20% 20% 10% 10% 10%
软件测试基本流程与规范 1目标 制定完整且具体的测试路线和流程，为快速、高效和高质量的软件测试提供基础流程框架。 最终目标是实现软件测试规范化，标准化。 2测试流程说明
3测试需求分析 测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用。用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。而且被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。所以我现在的理解是测试需求是一个比较大的概念，它是在整个测试计划文档中体现出来的，不是类似的一个用例或者其他. ·测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客观依据； ·测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的设计测试用例； ·测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖； 3.1测试方法与规范 3.1.1测试方法 随着软件技术发展，项目类型越来越多样化。根据项目类型应选用针对性强的测试方法，合适的测试方法可以让我们事半功倍。以下是针对目前项目工程可以参考的测试方法： ?β测试（beta测试）--非程序员、测试人员 β测试，英文是Beta testing。又称Beta测试，用户验收测试（UAT）。 β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。 当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。?α测试（Alpha测试）--非程序员、测试人员 α测试，英文是Alpha testing。又称Alpha测试. Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。 在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。?兼容性测试 --测试人员 兼容性测试是指测试软件是否可以成功移植到指定的硬件或者软件环境中，例如在B/S项目中各个不同浏览器之间的测试。 ?用户界面测试-UI测试--测试人员 用户界面测试，英文是User interface testing。又称UI测试。 用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。
软件研发部门绩效考核制度 有很多的公司都有软件研发部门，但是很多的人力资源管理者不知道怎么对软件研发部门实行绩效考核。下面为您精心推荐了软件研发部门绩效考核规定，希望对您有所帮助。 一、目的 (一)激发开发人员工作积极性，提高工作效率与工作质量，确保项目能按时、按量、按质完成。 (二)加强开发人员对个人绩效管理，改善工作，提高组织的绩效; (三)帮助开发人员客观的认识自我，发掘潜力，提高能力; (四)建立人员激励和调整机制，为奖惩、晋升、加薪、员工培训以及调岗、降薪、辞退等人事决策提供依据。 二、考核对象软件开发部全体人员 三、考核原则 (一)公开的原则：考核过程公开化、制度化; (二)客观性原则：用事实、数据说话; (三)反馈的原则：在考核结束后，考核结果必须反馈给被考核人，同时听取被考核人对考核结果的意见，对考核结果存在的问题做出合理解释或及时修正; 四、考核组织 (一)总经理：绩效考核方案、结果的审核、审批、组织及实施。
(二)部门经理：负责部门开发人员的绩效考评，反馈方案运行中存在的问题，并提出改善建议。 (三)被考核员工：按照绩效要求完成本职工作、达成目标、提升自我。定期与部门经理沟通目标达成进度，配合部门负责人进行绩效面谈，并不断进行绩效改进和提升。反馈方案运行中存在的问题，并提出改善建议 (四)行政人事部：负责绩效考核方案的拟写、修订、绩效考核的组织与实施。 四、考核周期根据开发人员的项目周期进行考核。(注：开发人员负责的项目不同，周期可不同) 五、考核内容及方法 (一)工作进度考核对软件开发的进展情况进行度量，主要考察时间进度及工作量，衡量开发人员每个开发阶段是否按时、按量完成。 1、对于每个阶段工作过程中，所花费的天数，通过填写的“项目开发计划与完成进度表”进一步核实。“项目开发计划与完成进度表”每个阶段都要书写并发行政人事部备案，以便工作跟进、核对。每阶段结束向直接上级汇报并接受考核。 2、对开发人员的过程考核数据是：项目所负责的阶段的计划完成时间和实际需要时间。 3、时间差率=(本阶段实际需要时间-本阶段预计完成时间)/本阶段预计完成时间;(以天为单位);最终的结果为N个阶段的平均值。注：提前完成的可作为加分项，酌情加分(需讨论) 4、评分标准