→ 模块缺陷率：这个指标主要是根据一个单独测试模块的缺陷数除于模块本身功能点数得出来的。假使一个模块是单独测试的话，很容易可以和其他模块进行指标横向对比，参照对应的测试人员，得出所测试模块的缺陷数，可以考察测试人员测试水平，也为开发考核提供数据。

　　公式：∑缺陷数（系统测试（个） / 功能点（个）

　　∑缺陷数（系统测试（个） / 子功能点（个）

　　参考指标 平均 3.74 个缺陷 / 功能点 1 个缺陷 / 子功能点

　　注意：有些功能点没有子功能点，计算子功能点时要进行说明。

　　→ 遗漏缺陷率：发布后的线上故障，现阶段测试相关的故障主要都是因为测试遗漏，有遗漏说明我们的测试还是效率不高，可以改进。

　　公式：∑遗漏缺陷数 / (∑遗漏缺陷数 + ∑遗漏版本发现缺陷数)

　　→ Bug发现的时间点，bug曲线的收敛性，理想的效率高的模式应该是前多后少，慢慢收敛的，如果前期bug非常少，后期却发现大量bug，那我们的前期效率有问题。

　　→ 缺陷定位和可读性： 可读性内容包括Bug描述的规范性，分、良好、普通与不合格，描述是否清晰，问题定位的附件是否完备等。如果一个测试人员只会通过页面将现象表达出来，而无法定位这种现象是有什么引起的，或者无法定位该缺陷到底错在何处，那么可以判定测试人员只是做了简单的表面测试，并没有对所发现问题进行分析定位。

　　● 对技术组(性能自动化和环境)测试人员效率的度量：

　　→ 自动化测试的引入和使用是否合理，不是每个项目都适合做自动化的，自动化并不能保证效率的提高，用5个小时开发的自动化脚本来替代3个小时的手工测试并不合算，自动化测试需要评审，按照项目的大小不同，必要的情况下才引入自动化测试。

　　→ 自动化测试，特别是性能测试结束之后，我们要分析部分测试结果，测试结果的分析水平，也可以作为衡量测试效率的一个指标。

　　● 对测试项目负责人的效率的度量：

　　→ 测试是否提早介入项目，例如FRD阶段介入，越早介入，越有利于测试，使测试人员更加熟悉整个项目，使问题早暴露，提高整体效率。

　　→ 开发提交测试的时候，标准是否合理，把关是否严格，如果开发的质量不行，坚决要退回，不然会影响测试的效率和进度。

　　→ 测试计划阶段，评价测试计划的合理性，包括任务细化，细化的程度是否合理，任务顺序，资源安排，任务分配合理，风险预估等等。

　　→ 项目结束后，评价项目进行阶段中负责人的跟进情况，特殊情况处理，风险触发之后的处理，资源协调，信息收集，共享，沟通，配合等等。

　　● 测试管理。

　　→ 计划质量：测试计划的评审缺陷数或比率，可以与其他同类型项目或数据库平均指标进行对比。

　　∑缺陷数（评审和同行评审）（个） / ∑测试计划文档页数（页）

　　→ 成本质量：成本度量主要放在工作量这块。因为无论涉及工资还是奖金，都要和工作量挂上关系。成本质量主要是对测试活动的计划工作量总和比上实际的工作量数值总和。对测试人员考核的进度偏离已经考虑了进度因素，而工作量涉及的是成本因素。

　　公式：∑测试活动计划工作量（估算人日） / ∑测试活动的实际工作量（人日）

　　参考指标：原则上不能偏离计划的 ± 15 ％～ ± 20 ％。实际上，这个指标是对成本的一种度量。对于一个大的项目来说，估算值往往差距非常大，阶段统计时可能有± 500 ％！！这时调整计划是很必要的，在终阶段取考虑计算平均估算值。一个测试经理必须对完成任务的成本进行有效控制。这两项指标是相对容易量化的部分，而需要添加其他量化指标需要综合考虑由项目经理和测试部部门经理给出标准，例如管理用时比率（整个项目测试期间管理时间占整个项目测试总时间）、系统整体缺陷数与其他同类型项目或数据库平均指标进行对比等等。

　　● 考核具体方法：

　　→ 将各项指标进行汇总分析，得出总和表格，根据测试人员各项指标大小进行排行榜制作，如列出 1 、 2 、3、4 名。

　　→ 确定阶段涉及的权重。例如将测试设计和测试执行权重各为 50 ％。其中，工作效率占 40 ％（即占所在阶段 20 ％），工作质量占 60 ％（即占所在阶段 30 ％）。

　　→ 确定每类指标的分值，然后每类指标达到平均标准给 100 ％，达不到或者超过根据 80 ％ ~120 ％比率给分。

　　→ 将比分统计出来后进行综合评定，必要的话增加一些调整系数。

　　→ 好将定性分析纳入进来，采用问卷调查和项目经理评分制度给出定性指标分数，建议这部分权重不要超过 10 ％～ 15 ％以保证测试考核的可度量性。

　　→ 当所有考核分数给出之后，提醒一点的是，既然做了考核，必须公开这些结果，而且考核具有导向型，不要让考核误导了对质量工作的追求才是重要的。