绩效考核是一个团队的管理比较重要的一个方法和手段。合理适度公平的绩效考核对于团队的良好发展有着积极的影响作用。每个行业的团队考核和管理都会因为行业的特殊性以及公司的制度而有着很多的不同。也对于软件测试这个行业来说，也有着很多的区别。

  从业四年多来，经过了日企，美企两大不同风格的公司的具体实践，对于测试团队的绩效考核，有些自己一些浅薄的认识。写在这里，留给自己深思，也希望给过路的同行一点启发。

一，绩效考核的一些片面的做法。

  日企和美企从很大程度上来讲，属于两种不同思想的碰撞，在各自的绩效考核上也各有一些在实践过程中，让人觉得不甚妥当的地方。在这里列举出来。

1.过分的强调了bug数量在绩效考核中的作用。

  诚然，把发现bug的数量和质量作为一项重要的对测试人员的绩效考核标准是没有错误的，而且如果同时伴随着必要的奖励机制，会在一定程度上刺激测试人员对于寻找bug的热情。

  但是，这个作用不可以过分的被强调。因为在实际的测试过程中，每个测试人员承担的测试模块的情况都是有区别的。比如有些人承担新开发的功能模块的测试，而有些人承担的则是旧有继承的模块的测试。bug的检出率对于新增模块来说自然要多于稳定的旧有模块。

  还有，如果对bug的作用过分强调，也会使得测试人员在承担测试任务的时候挑肥拣瘦，都争着抢着去测试那些容易出问题的功能，在很大程度上会打乱测试计划和测试进度的正常进行。

一些国内的企业，包括我曾经工作过的日企，在实际的绩效考核过程中就过分的看重了bug的比重。“过犹不及”这句古语在现代的企业管理和项目管理中也发挥着它的作用。

2．只看测试用例的数量和客户对于测试的反馈而忽略了bug在绩效中的作用。

  这一点在美企体现的是比较深刻的。对于很多在欧美外企工作的测试人员来说，工作量没有日企卡的那么严格，也不需要像测试leader整日的汇报动向。在既定的时间内完成测试需求的分析-测试用例的设计-测试的评审-测试的执行以及后期测试的结果汇报就可以了。如果当前测试的版本发布之后，没有其他的不良反馈，就算顺利的完成了测试任务。而也正因为这种文化的存在，在欧美企业的绩效考核中，测试case的设计质量和完成的多少以及客户的反馈成为重中之重。

  这个根据应该说在很多程度上是有隐患的。可能根据这个release版本所重点关注的问题，测试员没有测试出相关的问题。但是却找到了其他的一些问题。因为绩效考核不在于考核测试人员对于bug的发现量，而且在一个跟本身release版本无关的问题上纠缠会造成一些额外的麻烦，比如说开发人员不予修改，比如说提交延迟，比如说及时你额外测试了，付出了，却没有任何的后续效果。。很多测试人员在长久的这种状态影响下，就如猫在火中取栗被烫伤了爪子一样，逐渐的把目光从全局放回了局部。及时bug就在脚边，甚至跘了自己一跤，也会因为这种影响，视为无物。那么长此以往，从这样的开发，测试团队中流出的产品的质量，可想而知。

3．对于测试人员发现的问题没有有效的评审机制。

  测试人员要及早的连续的测试，要在发现问题后及早的报告。这是每一个从业人员都耳熟能详的原则。很多测试团队也在绩效考评中侧重于对测试人员发现bug量的考察。但是在实际的考评执行中，因为没有有效的bug评审机制，所以对于问题的质量的度量缺乏一定的衡量标准。

  发现测试系统设计方面的缺陷和能引起测试系统出现异常的bug的意义要远远大于发现几个图形界面的小bug。所以，实际的测试中，要根据bug的严重程度和意义来给与合理的考评。

4．不重视测试人员的综合能力.

  在很多测试团队中，绩效考评一般只限于两点，第一，测试用例的考察，包括书写的效率和质量；第二，测试缺陷量的考察。而对于其他，涉及很少。

  测试团队的巩固和成长是一个长期的实践活动。对于测试人员的技能，素质以及其他相关的培养也是必要的。所以，在一个测试团队的绩效考核，也是需要针对综合的能力进行全面的考察。比如说，测试人员对于相关领域技能的学习能力，对于所学知识的分享能力，对于技术难题的攻克能力，外语能力，沟通能力等等。都应该是考察的一方面的内容。

二，绩效考核的几点建议。

1．综合素质的考察

1）考察测试人员的职业操守，对于公司规章制度的一些遵守（如果需要）

2）考核测试人员的工作态度（是否认真，积极，努力）

3）考察测试人员的学习能力（对于边缘技术的学习能力，对于较难课题的学习和攻克能力）

2．测试成果的考察

1）考察测试人员的对于测试需求的理解

2）考察测试人员对于测试用例的设计（检查点的覆盖，业务的熟悉和掌握，测试用例的书写效率和质量）

3）考察测试人员的bug的检出率（bug的质量<严重程度，该bug的功能性影响>，确认，发行bug的工作是否到位，bug report书写的质量

3）和相关人员的沟通。包括和相关开发人员，其他人员的工作中的交流情况。

3．测试培训成功的考察

1）对于既定的测试小组的培训的学习情况。

2）对于给出的技能点的培训任务的担当和完成情况。

  总结：

注意点：对于测试人员的绩效考评，要全面，公平。数据说话。也就是说，不能因为个人的亲疏远近关系而放宽或者严苛的对相关人员进行考核。不能因为个人的主观印象而要采取能拿出服众的数据给与合理的考评。

  对于被考核者的评价要客观，通过考核，要让他们了解考核的意义以及对于测试人员本身使命的认知。对于被考核者的主观情绪，要把握好，并且适度的单独给与疏导，让其能够更加有效的投入到新的测试工作当中。

测试的几个原则

1. 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。
2. 测试用例应由测试输入数据和对应的预期输出结果这两部分组成。
3. 程序员应避免检查自己的程序。
4. 在设计测试用例时，应包括合理的输入条件和不合理的输入条件。
软件测试的原则
5. 充分注意测试中的群集现象。
经验表明，测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。
6. 严格执行测试计划，排除测试的随意性。
7. 应当对每一个测试结果做全面检查。
8. 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

关于bug

测试的原则---Good Enough

　　对于相对复杂的产品或系统来说，zero-bug是一种理想，good-enough是我们的原则。

　　Good-enough原则就是一种权衡投入/产出比的原则：不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现。我们的操作困难在于：如何界定什么样的测试是不充分的，什么样的测试是过分的。目前状况唯一可用的答案是：制定最低测试通过标准和测试内容，然后具体问题具体分析。

测试的规律----木桶原理和80-20原则

（1）木桶原理

　　在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说，测试是提高产品质量的必要条件，也是提高产品质量最直接、最快捷的手段，但决不是一种根本手段。反过来说，如果将提高产品质量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。

（2）Bug的80-20原则。

　　实践证明。80%的bug往往隐含在20%的软件区域。所以一旦在某处发现了bug，多找找周围。这也是有经验的测试员的一种方式。

   一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。

推荐给：刚刚入门的新人

推荐语：这是一篇关于测试员角色定位的文章，希望可以给刚入门的人，入门不就感到有些迷茫的人一些启示。

其实我们从小学，到大学，学到的哲理，格言不下亿万句，在人生的某个时刻能真正对你有用的那一句才算真的有用。这篇文章，当初也给了我极大的启发。特推荐至此。

声明：来自testage的《测试员》第一期（节选）

   很多刚进入门的同仁开始慢慢对做测试流露出迷茫的眼神，问其原因，很简单，做测试学不到东西，整天就鼠标点点，键盘敲敲，很难学到真正的东西。

听了之后不由得露出理解的笑容，想当年我也是从这样的境遇走过来的。刚进入公司的时候就让做测试，经历了同样的鼠标点点，键盘敲敲的经历。然而正是这样的一些成长经历让我在平淡中明白了很多道理，并且慢慢从因为工作而做测试转化为因为兴趣爱好而继续做测试工作。

    做测试不仅仅是表面看到的这种敲敲点点现象的延续，还有更深层次的内涵，只

是我们很多人还没到达这个境界而已，所以看起来很枯燥。

    刚开始做测试的朋友很多都在做黑盒测试，而黑盒测试往往对代码编写能力要求不是很高，这样给刚入门的人就造成了一个测试人员不需要太多知识的误解。

    然而，做测试往往需要很广泛的知识。不仅仅只是专业上的，而且要了解很多开发人员不了解的东西，在一个系统里面开发人员可以只了解客户需求，而我们的测试人员需要了解整个全局的东西。呵呵，感觉有点统筹全局的成就感。不过有时候相对于开发人员来说也的确是这样的。开发人员可以不用太多了解用户的需求，而我们却需要能够准确捕获用户的观点，对很多细节需要非常注意。

    往往很多人在初入测试行业的时候非常热衷于测试工具的学习以及使用，其实这并不是一个很系统的认知。知识的学习也是分阶段的。测试这两个字很表面来看很简单，只是给程序挑错误，找出bug 来，但是在整个软件开发过程中我们该如何把测试跟开发结合起来有效地进行都需要经过实践来证明。而这些不是工具所能完成的。我们对整个测试流程方面的东西需要了解得很多很多，而工具只是需要了解的其中一部分而且是比较小的一部分知识而已。

    你所了解的不仅仅只是测试的表面，你需要了解测试的流程，你需要了解如何用一个好的测试计划来规划我们的测试时间、测试范围（有些公司把测试范围的设计归纳在测试需求里面，但是很多公司都是在测试计划里面），需要了解如何用一个好的测试用例来覆盖整个测试范围之内的测试实施。了解如何保证所测试出来的bug 是开发人员的问题而不是因为自己了解不够导致出现的问题。Bug 分析报告之内如何总结问题都是我们需要注意到的知识。对自己的测试时间也需要进行详细规划，尽量多地考虑进去各种可能。这样才可以尽量减少相关的风险。

其实这些问题真的在哪个论坛里都有，不过奇怪的也是，每次面试都会遇到，无论是自己面试还是给别人面试。。

PS:声明一下，这里的问题基本都不是原创的，答案呢，在软件测试“百家争鸣，百花齐放”的时代也是丰富多彩的。但是道理都差不多。仅作为参考，呵呵~~

什么是“软件测试”？

1。出自(IEEE, 1986; IEEE, 1990).

Software testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features ofthe software item

就是一个通过分析软件和需求之前差异，发现bug,对软件的功能进行评价的过程。

2。软件测试就是在受控制的条件下对系统或应用程序进行操作并评价操作的结果。

3。软件测试是为了发现错误而执行程序的过程。

这一种也是大多数文档和书籍进行的定义，其实和第一个定义没有什么区别。

什么是“测试案例”?

测试案例是一份文档，它描述了一个输入、反应、或者是与其相应的预期的响应，以便来判断应用软件的工作是否正常。测试案例应当包括测试标识、测试案例的名称、目标、测试条件/设置、输入数据要求、步骤、以及预期的结果。

如果时间不够，无法进行充分的测试怎么办?

使用风险分析，确定测试的重点。

由于很少有机会对一个应用软件进行所有可能的测试 (包括所有可能的事件组合、所有的相关性、或者一切可能出错的东西)，对大多数软件开发项目来说，利用风险分析是适当的。这需要判断技能、常识、感觉和经验。如果有正当理由，也可采用正式的方法。需要考虑下列因素：

ü  对于该项目的用途而言，哪种功能最重要?

ü  哪种功能对用户最明显?

ü  哪种功能对安全影响最大?

ü  哪种功能对用户最有用?

ü  对客户来说，该应用软件的哪个部分最重要?

ü  在开发过程中，该应用软件的哪个部分可以最先测试?

ü 哪一部分代码最复杂，容易导致出现错误?

ü 哪一部分的应用程序是在急迫或在惊恐的情况下开发出来的?

ü 哪一部分程序与过去项目中引起问题的部分相类似/有关?

ü 哪一部分程序与过去项目中需要大量维护的部分相类似/有关?

ü 需求和设计的那些部分不清楚或不容易读?

ü 开发人员认为在应用软件中哪些部分是高风险的?

ü 哪些问题能造成最差的发行?

ü 哪些问题最能引起用户抱怨?

ü 哪些测试可以容易地覆盖多种功能?

ü 哪些测试在覆盖高风险部分的测试时使用时间最少?

如果需求一直在变化怎么办?

这是一个常见的令人头疼的问题。

ü如果可能，尽早与承担该项目风险的人接触，以便了解需求会怎样改变，从而可以尽早地改变测试计划和策略。

ü 如果在对应用程序进行初始设计时多考虑一些适应性，那么以后在发生需求的改变时，就不需要再为改变做很多事情了。

ü 好的代码注释和好的文档有助于开发人员作出相应的改变。

ü只要有可能，就应使用快速原型 (rapid prototyping)，以帮助用户确认他们的需求，从而减少变更。

ü在项目的时间表中应当留出余量，以应付可能出现的变更。

ü尽量把新的需求纳入应用软件的“下一版”，而把原始需求作为“第一版”。

ü通过谈判，把易于实现的新的变更列入项目，而把难于实现的新需求列入该应用软件的以后的版本。

ü要确保让客户和管理人员了解变更对进度表的影响、所带来的风险、以及因变更所引起的大量资金消耗。

ü在应付改变时，应在为建立自动测试而作的努力和重新进行测试所做的努力之间取得平衡。

ü在设计自动测试剧本时，试图使其有一些灵活性。

ü在对应用软件进行自动测试时，要把注意力集中在看来不大会改变的部分。

ü对变更进行适当的风险分析，以减少回归测试的要求。

ü在设计测试案例时要有一定的灵活性。做到这一点并不容易，所以要降低测试案例的详细程度，或者只建立高级的通用型的测试计划。

ü 少注意详细的测试计划和测试案例，要把重点放在专门的测试 (ad hoc testing) 上。