如何考核性能测试

xkmj

1、综合素质的考察　　1）考察测试人员的职业操守，对于公司规章制度的一些遵守（如果需要）
　　2）考核测试人员的工作态度（是否认真，积极，努力）
　　3）考察测试人员的学习能力（对于边缘技术的学习能力，对于较难课题的学习和攻克能力）
　　2、测试成果的考察
　　1）考察测试人员的对于测试需求的理解
　　2）考察测试人员对于测试用例的设计（检查点的覆盖，业务的熟悉和掌握，测试用例的书写效率和质量）
　　3）考察测试人员的bug的检出率（bug的质量<严重程度，该bug的功能性影响>，确认，发行bug的工作是否到位，bug report书写的质量
　　4）和相关人员的沟通。包括和相关开发人员，其他人员的工作中的交流情况。
　　3、测试培训成功的考察
　　1）对于既定的测试小组的培训的学习情况。
　　2）对于给出的技能点的培训任务的担当和完成情况。

xkmj

在项目中，测试人员考核往往成为项目经理和测试经理的一个难题，项目组测试人员考核主要包括工作效率和工作质量两大块，工作效率用于考察活动，而工作质量用于考察产出物质量。按照传统测试周期，测试过程分为：测试计划、测试设计和测试执行三个方面进行。测试计划属于测试经理的范畴，测试人员主要是测试设计和测试执行，测试经理的考核可包含在测试人员的考核内，当然，这部分考核也可以纳入项目组中进行。考核指标如下：

　　一、测试设计

　　1、工作效率相关指标

（1）文档产出率：这项指标值主要为测试用例文档页数除于编写文档的有效时间获得。用于考察测试人员测试用例文档的生产率大小。

　　公式：∑测试用例文档页数（页） / ∑编写测试用例文档有效时间（小时）

　　参考指标：根据项目汇总得出平均在 1.14 页 / 小时左右，高于此值为优，低于此值为差。

　　（2）用例产出率：这项指标值主要为上述指标值的补充，用于考察测试人员测试用例产出率大小。测试文档页数可能包含的冗余信息较多，因此要查看文档中测试用例的多少。方法是测试用例文档中测试用例编号总和数除于编写文档的有效时间。

　　公式：∑测试用例数（个） / ∑编写测试用例文档有效时间（小时）

　　参考指标：平均 4.21 个用例 / 小时

　　2、工作质量相关指标

　　（1）需求覆盖率：计算测试用例总数之和除于与之一一对应的功能点数之和，主要查看是否有功能点遗漏测试的情况。

　　公式：∑测试用例数（个） / ∑功能点（个）

　　参考指标： 100 ％。如果连功能指标都不能满足 100 ％覆盖，起码说明测试不充分。这个指标收集起来相当困难，如果存在需求跟踪矩阵或者测试管理工具能把用例与需求一一对应就容易得多。

　　（2）文档质量：测试用例进行评审和同行评审发现的缺陷数，或者将此缺陷数除于文档页数算出比率。此指标考察测试人员文档编写的质量如何。

　　公式：∑缺陷数（评审和同行评审）（个）

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

　　参考指标：由于评审是发现的缺陷数是不固定的，因此，这个指标没有可供参考的数值。如果缺陷数大小不能直接用于比较就使用缺陷 / 页方式进行横向对比。

　　（3）文档有效率：使用测试用例文档进行测试时发现的系统测试缺陷数除于此文档页数。用于考察文档是由有效的指导了测试工作。

　　公式：∑缺陷数（系统测试）（个） / ∑测试用例文档页数（页）

　　参考指标：平均 2.18 个缺陷 / 页

　　注意：如果存在测试人员在测试时创建新文档用于辅助测试时应包含这一部分。

　　（4）用例有效率：使用测试用例发现的全部缺陷除于测试用例数总和。这一指标是上一指标的补充指标，用于考察用例质量是否较高

　　公式：∑缺陷数（系统测试）（个） / ∑测试用例数（个）

　　参考指标：平均 0.59 个缺陷 / 用例，也就是说，每执行两个用例才得到 1 个缺陷，各工程有所不同，可以自己实践一下。

xkmj

简单说说我在以前测试团队中，如何进行测试度量工作的。在之前的测试度量这块，我主要从3部分开展工作。

一个是缺陷数据的统计分析，第二个是工作量的统计分析，第三个是测试工作量的估算。

首先简单介绍一下缺陷的统计分析。这块基本大家都或多或少都会做一些。我主要是从缺陷严重性、优先级、模块缺陷的分布、缺陷的收敛情况、缺陷的修复情况进行统计，并根据统计结果，进行一定的分析。一般来说，缺陷的分布是有一些规律的，如果明显不符合这个规律，那么就表示系统或项目组存在一定问题。例如说，某个模块功能一般，并不复杂，但是却发现了比较多的缺陷，这可以反映该模块开发人员开发质量有问题，假如该开发人员平常工作质量都不错，那么或许该开发人员生活中存在碰到了问题或者有其他原因。我之前碰到过一个开发人员因为感情原因，导致那一段时间开发出来的程序缺陷非常多，后面pm和他谈心后，程序质量又恢复正常了。

其次是工作量的统计分析。在工作量这块，我主要进行5部分的工作。

1)     日常工作量的记录，这个由团队成员自己编写。在填写工作记录时，需要为每个工作记录选择相应的任务类型，并且工作任务持续时间最长不超过4小时

2)     每星期统计本周团队成员在各个项目中的投入情况。不仅让自己了清楚，也让上司了解测试部对于项目的支持情况。ITPUB个人空间 S7f-IrT;z5o
在上面的例子里，测试团队在项目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月将投入新启动的项目。

3)     每半个月统计整个团队的工作分配情况（但是数据是每周都填写的）统计每个人在各个项目的工作量分配情况。这个和上面那个统计表的侧重点不一样，上面这个统计表侧重在部门整体，现在这个表侧重于个体。

4)     定期（如每周或半个月）将团队成员在项目中的工作量投入情况记录到项目工作量投入表中。这个表格主要用于统计具体每个项目的测试工作投入情况，及作为后续测试工作量估算的原始数据。

5)     在项目到达一个阶段后，将项目测试收集的数据进行汇总、统计。收集的数据除项目基本信息外，还包括工作量、测试投入成本、项目规模、项目总成本、项目总工作量。主要分析测试在项目中的投入情况、成本情况、各个测试任务的分配情况等。

最后，根据对几个项目的工作量、成本以及测试任务占项目总测试投入的比例分析后，我得到了原先测试团队测试工作量估算的简易公式。我可以根据这个简易的公式进行测试的估算，方便测试计划中关于工作量估算部分的编写，避免在估算工作量时缺乏依据。估算内容主要包括：测试总人力成本占项目总人力成本的比例及各项测试任务的工作量分配比例。

（注：这是在类似测试操作员的角**况下进行的估算）

测试总人力成本＝20%×项目总人力成本

在整个测试过程中产生的各项测试任务的测试工作量分配如下：

测试任务
比例

熟悉系统需求
5.0%

测试计划
3.5%

测试需求
7.5%

测试用例
15.0%

测试执行
39%－41%

测试报告
4.0%

测试管理
6.8%

沟通、会议、
4.0%

测试环境搭建
2%－2.5%

性能测试
9.0%

验收测试
4.0%


使用这个表格对进行测试的项目的测试工作量等进行估算后，根据项目实际情况进行调整。例如，如果项目测试人员对性能测试不熟悉的话，那么“性能测试”这块的工作量需要加大；如果项目需求不明确，测试人员和项目组成员未合作过，那么，项目的测试需求、熟悉系统需求、沟通的工作量将酌情增加。

xkmj

表空间误删除解决办法,能装载数据库(进入nomount状态)
sqlplus /nolog
connect / as sysdba
startup nomount
alter database mount;

1. alter database create datafile '/oradata2/XXX.dbf';
2. set autorecovery on;
3. recover datafile '/oradata2/perftemp.dbf';
4. alter database datafile '/oradata2/XXX.dbf' online;

alter database open;
即可恢复误删除导致的数据库实例无法打开的问题，前提是日志文件没被删除。redo01.log

msnshow

这个量化太有难度了