软件测试人员绩效评估的分析、设计与实现毕业论文

上海交通大学本科毕业论文

软件测试人员绩效评估的分析、设计与实现

软件测试人员绩效评估的分析、设计与实现

摘要

软件测试在软件项目中的重要地位显而易见，然而在国内，软件测试业起步晚，不受重视，面对国内软件测试行业的窘况，测试人员的水平不高，高级测试工程师更是紧缺，软件测试人员的水平更是很难提高。而在项目中，测试人员考核其实是个提高测试人员水平、体现项目质量有效和直观的方法。但是这个考核往往又成为项目经理和测试经理的一个难题。怎样评估测试人员的工作？怎样定义测试质量的差别？

那么我所希望研究的就是如何去评价一个测试人员的工作绩效，如何去量化一个测试人员。通过量化的数值从而能更加好、更加正确地评价一个测试人员，从而反映出每个测试人员的不足，以此来推动测试人员的发展，来提高测试人员的水平。

此论文的主要亮点在于，对生活中的事例进行了抽象，对抽象出来的考核参数通过加权的方式合理地对测试人员的绩效进行量化。其特点如下：

1.通过现实生活中的事例抽象出测试人员绩效考评的参数。

2.根据参数对测试人员的影响进行加权式的量化。

3.简单有效地进行一个测试人员的考评。

关键词：软件测试；测试人员考核；工作效率指标；工作质量指标

ABSTRACT

It is obvious that the software testing system is of great significance in the software project. But in China, little importance is laid on it as its coming and development in our country is lagging. In this unpromising situation, the low level of technology of testers is inevitable and High-level tester engineers are even scarcer, which makes the software tester's skill level difficult to enhance. In one project, the tester’s appraise is an effective and direct-viewing method in the enhancement of a tester’s skill and manifesting the quality of the project. But this inspection often becomes a difficult problem of project managers and tester managers.

The research I do is relevant to how to appraise and quantize the achievement of the tester’s work. Using these marks after quantizing, it will be better to promote the development of a tester and enhance the skill level of a tester.

The point of this study is abstracting the cases in life, and weighing the parameters of the marks which had been quantized of the achievement of the tester’s work. The points are as follows:

1. Abstract the case in life, and choose the parameter about the tester’s work

2. Weighting the parameter according to the affect of tester.

3. Easy and efficient to appraise the tester.

Key Words: software test；tester’s appraise；norm of work efficiency；norm of work quality

软件测试人员绩效量化系统的分析、设计与实现

目录

第1章项目概述 (3)

1.1 背景介绍 (3)

1.1.1 软件测试背景介绍 (3)

1.1.2 软件测试在中国的形势 (5)

1.1.3 软件测试人员技术背景介绍 (5)

1.2 设计理念的由来 (6)

1.2.1 CMM简单介绍 (6)

1.2.2 CMM与软件测试 (7)

1.3 预期产品的特点介绍 (7)

1.4 小结 (7)

第2章需求分析 (9)

2.1 存在的问题分析 (9)

2.2 可行性研究 (9)

2.3 对应工具的选取 (9)

2.4 小结 (10)

第3章软件设计与实现 (11)

3.1 概要设计 (11)

3.1.1 程序结构图及说明 (11)

3.1.2 数据流图及说明 (12)

3.1.3 技术指标量化的分析 (12)

3.1.4 具体的量化指标 (14)

3.2 详细设计 (17)

3.2.1 界面的布局 (17)

3.2.2 系统框架分析 (18)

3.2.3 数据库的分析 (19)

3.3 小结 (19)

第4章系统实现与测试 (20)

4.1 系统搭建 (20)

4.2 遇到的问题与改进方法 (22)

4.3 小结 (23)

第5章论文总结 (24)

5.1 产品的价值 (24)

5.2 产品不足 (24)

5.3 对产品拓宽应用的想法 (24)

结束语 (25)

参考文献 (26)

致谢 (27)

附录 (28)

第1章项目概述

1.1背景介绍

1.1.1软件测试背景介绍

软件测试，一个不陌生的词，相信大家在近些年来对于它的关注也是越来越多，越来越重。在介绍它的背景之前，先来说下它的学术上的定义吧！

软件测试就是在软件交付用户使用或投入运行前，对软件需求规格说明、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。换句话说，软件测试就是为了发现错误而执行程序的过程。

基于对定义的了解，下面介绍与软件测试相关的一些内容：

软件测试的阶段

一般我们所说的软件测试都分两个阶段。第一个阶段，在编写出每一个模块之后就对它做的必要的测试，即我们称作为的单元测试。一般来说，编码和单元测试是属于软件生命周期中的同一个阶段的。而在结束这个阶段后对软件系统还要进行一系列的各种综合测试，如集成测试、系统测试、回归测试、性能测试和配置测试等，这就是软件生命周期的另一个独立阶段，即综合测试阶段。

软件测试的目的

从一般的意义上说，其实软件测试的最终目的也就是为了避免软件中的各种错误的发生，确保应用用户在使用程序时能够正常高效的运行。这也是体现软件测试价值的所在。其次还有一些人们通常忽视的目的，那就是，利用好的测试用例、成功的测试用例来发现至今未发现的错误。最关键一点，也是一直以来都被测试人员忽视的问题，就是发现问题的同时，还要尽自己可能来帮助开发人员分析问题，排除一些不利于开发解决问题的因素，尽可能的详细描述来重现错误的方法。这些都是测试的目的。

软件测试的原则

软件测试的原则应该就是尽早和不断地进行软件测试，因为实践证明单元测试可以尽早发现问题，这样就可以尽量减少后期测试工作的工作量与错误量，同时也可以确保系统不会的因为发现错误过晚而导致项目的延期，或者因为重大缺陷问题而导致复工。然而这一点却是通常的开发人员所忽视的地方，往往我们会

认为，测试是后期测试人员应该负责的，因此造成后期测试人员总能发现一些低级的错误。

充分注意测试中的群集现象。对于这点，起初我并不怎么理解，但经验表明，测试后程序残存的错误数目确实与该程序中已发现的错误数目或检错率成正比。所以，应该对错误群集的程序段进行重点测试。

最后，应当对每一个测试结果做全面的检查。妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

软件测试的对象

传统的软件测试仅是对软件的功能测试。其实，软件测试并不单纯等同于程序测试。软件测试应该贯穿整个软件定义与开发整个期间。因此需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应该是软件测试（评审）的对象。在对需求理解与表达的正确性、设计与表达的正确性、实现的正确性以及运行的正确性的验证中，任何一个环节发生了问题都可能在软件测试中表现出来。 软件测试的重要性

我们知道软件测试一直以来都在整个软件生命周期中所占据重要的地位，但是在传统的瀑布模型中，软件测试仅仅安排在运行与维护阶段之前，虽然这样的方法是软件产品交付用户使用之前保证软件质量的重要手段，但是由于受到传统模型本身的限制，软件测试的地位的重要性一直以来都没很好的发挥。近年来，软件工程界趋向于一种新的观点，即认为软件生命周期每一阶段中都应包含测试，也就是如上面提及的第4点，测试的对象更加全面。采取这样做的方式的目的是可以做到检验本阶段的成果是否接近该阶段的预期目标，同时可以确保尽早的发现各阶段中的错误的存在，并且加以修正。因为以往的事实告诉我们如果不在早期阶段就进行测试，错误往往会延时扩散，并且常常会导致最后成品测试的巨大困难。

其实，大量软件项目的观察结果表明，软件项目的成功与否在很大程度上依赖于软件测试的成功，软件测试做得好的项目不光质量好，而且可以提前或按时完成，其成本也相对较低；抓软件测试和软件质量，并不意味着增加项目成本，反而可以降低项目成本。此外，软件测试有着在软件项目中举足轻重的地位与意义。

1.1.2软件测试在中国的形势

通过上面对软件测试的背景的介绍，我们可以大致了解了软件测试其在整个软件开发中的重要地位。因为软件测试贯穿着整个软件的开发，软件测试的好与坏，也直接影响着软件本身的好坏，同时也对软件的效益挂上了钩。所以，软件测试越来越受到了人们的重视。

不过目前与国际先进软件企业相比，中国软件企业的差距在哪里？一个重要而又明显的差距就是软件测试和软件测试人才。主要存在以下几个方面的问题：1.认识问题：普遍存在重开发、轻测试的现象，将测试放在从属被动的地位。

没有充分认识到，其实软件项目的开发完成的好坏，不仅取决于开发人员，更取决于测试人员。

2.从业人员：目前国内的大多数测试人员整体水平都不是很高，有的是从别的

行业，经过某某学校的培训进入这个行业的，有的是半路出嫁，这多多少少影响着测试行业的发展。

3.管理问题：多数存在随意化、简单化，没有建立有效的、规范的测试管理体

系。

4.工具问题：现在国内的公司，大多都缺少自动化工具的支持，一般未采用软

件测试管理系统。

5.培训问题：国内测试的培训越来越多，但有哪些是把真正提高从业人员的水

平做为首要任务的，更多的可能在“钱”字上。

一些统计数据表明，在国内，多数软件企业在软件测试方面上的投入一般都在5%以下，而国际著名企业的软件测试则在整个软件项目中所占的比例为40% 以上，占整个项目费用的50%以上，软件测试人员与开发人员的人数也比例大于1:2 ，反观国内，测试人员所占比例很小，通常都处于从属与被动的地位。所以，我想中国的软件工业要想健康的发展，必须正视上面的几个问题和努力缩小这些问题上的差距。

1.1.3软件测试人员技术背景介绍

前面我们已经提到过了，中国软件企业的差距中软件测试人才也是个比较严重的问题。正如有标题写道：“国内软件测试业之怪现状-重赏之下无勇夫”。

一些相关报道表明，国内一些知名软件出口企业组织的招聘会上出现了“粥

多僧少”的怪现状。来自中星微电子、用友、金山、书生公司等很多企业的代表在面对前来应聘的近千名专业人才发出了感慨：“找软件人才，难！找优秀的难上加难！！”据招聘会负责人陈先生介绍，本次参与招聘企业将主要对软件测试工程师、J2EE高级软件开发工程师、JAVA开发工程师等岗位展开招聘；由于测试工程师等人才及其紧缺，大多企业都比较急，甚至有些企业像金山、联信永益等就直接打出“急聘”字眼招揽英才。

1.2设计理念的由来

前些阶段，公司内部培训CMM，借此机会自己也在网上查阅了许多相关的内容，公司内部整顿，提高软件项目管理，软件开发，于是结合了测试的相关内容，学习了下CMM如何更好的运用到测试环节中。此次论文选题，理所当然的就想到这个与自己工作密不可分的内容。一来对论文分析研究上着手比较简单，二来研究成果也有助于工作上的需求。

其实，当从一个测试员转变为管理员的我深刻体会到，对于一个测试人员绩效的量化的困难，但同时也了解其在国内测试行业中的意义的重大，因为在中国这个测试不受重视的大背景下，目前的软件测试人才紧缺，已成为中国软件企业的当务之急。对于测试人员又如此高的需求情况下，对于一个测试人员的绩效量化有非常重大的意义。为此下定决心，将此论文研究到底。

1.2.1 CMM简单介绍

CMM（软件能力成熟度模型：Capability Maturity Model For Software）是由美国卡内基梅隆大学的软件工程研究所（SEI：Software Engineering Institute）受美国国防部委托研究制定并在美国，随后在全世界推广实施的一种软件评估标准，主要用于软件开发过程和软件开发能力的评估和改进。

SEI 给CMM 下的定义是：对于软件组织在定义，实现，度量，控制和改善其软件过程的进程中各个发展阶段的描述。这个模型便于确定软件组织的现有过程能力和查找出软件质量及过程改进方面的最关键的问题，从而为选择过程改进战略提供指南。

CMM把软件开发过程的成熟度由低到高分为五级，即初始级、可重复级、已定义级、已管理级和优化级。随着CMM等级的提高，逐步降低了软件开发风险，缩短了开发时间，降低了软件开发的人力物力成本，降低了灾难性的错误发

生率，提高了质量。

1.2.2 CMM与软件测试

之前我们也提及到，在国内，大部分组织对评价和测试的定义都相对狭义的，他们忽视了测试在整个项目的重要地位。很多公司甚至直到编码已经开始时才指定或安排测试人员，并且，他们将测试的范围仅仅限定于功能测试，也许偶尔做一下性能测试。但是在CMM中再次强调，评价与测试是对软件开发过程中产生的各种系统规格和模型进行的验证活动，不仅仅是一种基于机器的对代码执行、确认的活动。

其实测试就像建造摩天大厦，在砌第一块砖之前就应该将评价和测试集成到了整个开发过程之中。而不是等到摩天大厦建成后才发现大厦内存在这样与那样的问题。而目前，多数的软件项目所使用的软件评价和测试方法是一直等到大楼已经建成才进行测试，那时测试的工作也仅仅是能保证基本的功能可以工作而已。

在CMM中所要表达的意思就是进一步将评价和测试的部分思想进行融合，用一个特殊的评价技术来代替，其问题的关键就是在你的项目生命周期中的每一个交付产品都必须被测试。交付的产品应当包括需求规格说明书，设计规格说明书、数据转换规格和数据转换代码、数据库设计说明书、培训资料、硬件/软件安装规格、用户手册和应用程序代码等等。

总之，每个阶段的每个交付产品必须通过正式的、训练有素的技术来对适当的属性进行评价和测试。这个在CMM中再次提及的问题，显示着软件测试正在该改革。

1.3预期产品的特点介绍

软件测试本身及其行业在中国的近况有了一个大致的了解。面对国内软件测试行业的窘况，测试人员水平的不高，高级测试工程师更加是紧缺，我所研究的就是如何来评价一个测试人员的工作绩效，如何去量化一个测试人员，从而能更加好、更加正确的评价，推动测试人员。其主要亮点如下：

1.通过对现实生活中的事例，抽象出测试人员绩效考评的参数。

2.根据参数对于测试人员的影响，进行加权式的量化。

3.简单有效的进行一个测试人员的考评。

1.4小结

通过简单的背景介绍，大致了解了软件测试在软件项目中的重要地位，然而在国内，软件测试业起步晚，不受重视的情况下，软件测试人员的水平也无法提高，目前国内软件测试人才紧缺。再通过结合CMM的相关知识，由此引出了我的论文的课题：软件测试人员技术指标量化的分析、设计与实现。论文的主要亮点在于，对生活的中的事例进行了抽象，对抽象出来的考评参数通过加权的方式合理的给测试人员的绩效量化。

第2章需求分析

2.1存在的问题分析

问题1：量化方法难度大

大家都知道，凡是量化都是需要一个过程，都是需要不断的摸索，而且考量的参数与其考量的定义，都是需要有严格的规范，并且需要合理。所以我想我所能完成的，仅适合于部分的量化，而且是和我本身的工作所紧密联合的量化。

问题2：可供参考资料少

由于前面也提及到，在中国，测试并不是很发达的大背景下，关于其各相关方面的理论都不是很充分。所以目前来说量化还处于大家都在摸索的阶段，当然也有前辈已经定义了一些量化的方法，但是都是比较简单而且不全面的，网上的相关信息也少之又少，这对我的研究带来了不小的困难。

问题3：量化的参考数据的选取

由于之前也说到，量化是非常困难的事，对于要考量的参数的选取也是非常困难的事情。因为有些的数据是无法量化的，而有些数据的量化又存在不合理性，如何选取合理的参考的数据来进行量化，也是个不小困难。

问题4：开发周期短

由于此次论文的时限比较紧张，一定会对软件的开发增加了一点的困难。所以在选取工具时，尽量应该选择比较容易的开发工具。

2.2可行性研究

对于一个人的工作质量，如何去量化它，如何尽量减少主观的因素去判断一个测试员的测试质量。我想这就是我要完成的此次的论文的主题。也就是说关键在于这个量化的方法。参考了网上它人的一些方法，再结合自己工作中的经验，大致的方法应该可以得到。通过选取的一些比较能反映问题的参数，再通过适当的合理的加权处理，来有效的准确的反映一个测试人员的技术水平与工作质量。相信通过研究，做到这点应该还是可以。

2.3对应工具的选取

受到自己本身所学习的语言限制，所以能使用的工具不多，考虑到时间的紧张，所以决定选择https://www.wendangku.net/doc/3012300666.html,，一来开发的界面形软件非常方便，二来自己也比较熟悉。这样就能为开发

节约不少的时间。

Visual Studio .NET 是一套完整的开发工具，它集成了Visual Basic .NET、Visual C++ .NET、Visual C# .NET 和 Visual J# .NET，能生成ASP Web 应用程序、XML Web services、桌面应用程序和移动应用程序等。并且这些语言全都使用相同的集成开发环境 (IDE)，该环境允许它们共享工具并有助于创建混合语言解决方案。其他相关特点就不再叙述。

2.4小结

本章内容，通过初步的分析，了解到了此篇论文研究中存在的难点与困难，对应的也在可行性研究中分析了这些难点与困难的初步解决方案。在选取工具时，选择了自己擅长的，并且在开发窗口界面软件时，最为方便的工具https://www.wendangku.net/doc/3012300666.html,。

第3章软件设计与实现

3.1概要设计

3.1.1程序结构图及说明

程序初步设计为，一个主窗体，其余窗体都为子窗体。如图1所示：

图1 程序结构图

在这个结构当中，M为主结构模块，负责子窗体的一些控制。S1，S2，S3分别为3子个结构模块。S1为输入模块，数据的输入都在这个模块中进行操作。S2为数据查询模块，数据最后的查询都在这个模块中进行操作。S3辅助模块，这里将进行一些辅助的操作，如登入对话框等。

S1数据输入模块，其分成多个子的数据输入小模块。每个模块分别为一类数据组对象。最后由S1统一的将数据传入数据库中。

S2数据查询模块，这里负责查询数据登入后的一些查询。以及在数据库的中的信息都在这里显示。

S3辅助模块，软件登入时的对话框，以及一些确定用的功能，暂时安排这个模块中。

在以上的模块设计中，模块数未定，需要在数据流程研究后再进一步确定。经过上面的分析，大致可以确定程序分成2个功能模块，数据的输入与数据的显示。再结合一些其他模块统一成一个完整的项目。

3.1.2数据流图及说明

一个基于计算机的信息处理系统由数据流和一系列的转换构成，这些转换见输入数据流变换为输出数据流。数据流图就是用来刻画数据流和转换信息系统建模技术的。

在我所研究的课题中，输入数据的外部实体就是每个测试人员的一些考评指标。输出的数据就是每个测试人员的用数值表示的绩效。通过量化来把测试人员的工作或者说是技术水平以加权形式的量化。进一步细化可以看见当管理者通过输入每个测试人员的参数数据时，经过软件的转化，对应的输出的就是每个测试人员的绩效的量化后的值。

3.1.3技术指标量化的分析

上节中分析了程序的整体结构图与数据流图，就如数据图中间的转化，这个过程就是我所要研究的测试人员绩效的量化。对于量化，在之前的需求分析中已经提到过其关键的难点在于参数的选取，选择一个作为评判测试人员在工作中的质量的参数能够有效的评价这个测试人员的工作的质量，结合所有的这种参数再通过加权的方式来整体的量化，最终得出一个测试人员的量化绩效。那么先来看看在以往测试人员的工作绩效评价都存在着一定的误区，如：

1、提交的问题单数量多与少并不能直接判断测试人员的好坏

因为这种做法明显缺乏全面性。Bug的数量只是评估测试质量的一个方面，但是光从数量上来评判一个测试人员的好与坏显然是不全面的，因为对整个项目而言，我们更需要的是整个测试的实际测试质量。这就需要考察问题单的质量、测试的难度、缺陷单的级别等一系列的问题。

2、对测试人员发现的问题的价值没有进行评估

如果说，测试人员发现的缺陷没有其本身价值的评估，势必会造成一些负面影响。因为，发现1个系统架构设计方面存在的缺陷和隐患，要远远超过发现几个普通界面的显示问题要有价值的多。因此，在对测试人员进行评价时，必须区分不同问题的重要性和价值。

3、对测试文档的质量不够重视

其实测试文档的质量虽然不是主要的因素，但是往往却是一个优秀测试人员的测试水平的反映，因为只有对系统进行了充分的、深入测试的测试人员才能写出高质量测试报告。同样，也只有懂得写好测试文档才能给测试带来更多效益的测试人员才是优秀的测试人员。文档的质量的好坏，影响着测试人员个人与整个测试团队的发展。

4、对测试人员的综合能力不够重视

其实任何工作首先最为重要的一点就是责任心。所以，必须考察测试人员的责任心，如果一个测试人员工作不符责任，随意敷衍，即使提交的Bug数量上很多，也不能证明他测试的质量高。其次，还需要看测试人员其他的方方面面，如工作积极性，沟通能力等。如果一个测试人员处理不好这些基本的工作能力，那也不能评判其是个优秀的测试员。

所以，我将评价的参数大致分为：Bug寻找能力，文档写作能力，综合素质，技术能力这四类，因为从我自己的经历来说，一个好的测试员所必须拥有的或者说一定要具备的能力基本都在这四类中所包括了。这里Bug寻找能力我重新定义为缺陷单相关，也就是说一切关于缺陷的指标参数我都将统和在这里。文档写作能力是包括一些诸如，日报，Bug票，Report等的描述能力。技术能力则是指编写测试用例，执行测试用例，使用自动测试工具等的一些能力。而最后的综合素质则是指测试人员平时的工作态度，钻研精神，动手能力等的一些工作种的基本表现。大致的参数都归纳在这四项技术指标中。下面来逐步选取每项指标中具体的参数。

缺陷单：其实大家都知道，评价一个测试人员技术水平的好坏，最关键的最基本的就是他查找Bug的能力，虽然Bug的数量不能代表一切，但目前来说，这

是唯一一个能体现一个测试人员水平的重要指标之一。所以我想，Bug的数量首先应该作为参数。其次，再考虑Bug的质量，由于Bug本身就具有严重性的差别，有些Bug导致机器死机，重起等，有些只是画面显示不妥等，根据这种重要性的不同的区别，可以将Bug分成S，A，B，C四等，同时也是衡量一个bug的质量的一个重要因素，好的bug应该是极端严重的，对系统造成极大危害的。所以，高质量的Bug越多，体现一个测试人员的水平也就越高，自然其所占的分值也应该也是越高。在之前也说过要充分注意测试中的群集现象，所以若回归测试中依然能发现高错误率模块的问题，同样也是体现测试人员水平的高低。

文档：也就是测试相关文档的质量。测试文档的质量往往是测试人员的测试水平的反映，只有对系统进行了充分的、深入测试的测试人员才能写出高质量测试报告，说明测试的全面性和测试过程的质量。在这里我们可以选取的参数有“缺陷描述”，“测试报告质量”。缺陷描述在整个测试环节中是一个非常重要的步骤，当一个测试人员发现Bug是他的职责，但是对于一个好的测试人员，缺陷描述的水平则是不可缺少的。因为好的描述，在测试与开发无法当面沟通时，能够方便开发人员了解测试人员发现的问题何在，便于更加快的处理，解决问题。但是如果描述不够清晰明白，只有给开发增加不必要的负担，浪费时间与精力。同样的，测试报告质量也应该规范详细，这样做的好处是有助于以后的归纳总结，同样更有助于在其他或者以后的项目中的运用。

技能：测试技能水平。评价一个测试人员的好坏，其技术水平肯定也是重要的指标。测试用例设计水平，测试工具掌握使用水平，测试结果分析判断水平。这种技术水平的指标，客观上可以从测试用例的设计数量上来做为评判，主观也可以从实际的测试用例的难度上来评判。对于工具的掌握同样也是一个重要的考评指标，当然前提是是否需要运用到测试工具。一个好的测试人员，一定要会测试工具，这样才能更加有效的提高测试质量与测试数量。

综合能力：测试技能以外的综合能力。其实考察一个测试人员，不仅仅要从上面提到的这些指标去衡量，要做到量化的合理性，应该还要考虑到测试人员的实际工作态度，团队协作，沟通等许多的主观因素，因为这些是职业的基本所在。但由于考虑到是主观的因素，所以我想比重不应该很大。

3.1.4具体的量化指标

上面大致分析了四个指标所涉及的一些参数。下面将具体对每个指标进行分析，做具体的量化。

缺陷单30（50）分

提交缺陷总数6(10) 参数值：T 基本考核指标

总缺陷是反映一个测试员最基本的考核指标。以6分为基本分。按照提

交缺陷的总数与项目的总数的比来加权量化每个人的分值。设计参数

T=S+A+B+C+WT。4*T/AT取整。

提交非缺陷总数-5（0）参数值WT 减分指标

这里涉及到非缺陷问题会给开发带来工作的影响，并且为了提高测试人

员的水平，让测试人员意识到非缺陷会给开发增加缺陷处理负担，这里

提出了减分的量化。

设计参数（-5）*WT/AT取整

提交有效缺陷数9（15）参数值RT 基本考核指标

有效缺陷是反映一个测试人员技术水平的一个非常好的考核指标。以9

分为基本分。按照提交有效缺陷的总数与项目的总数的比来加权量化每

个人的分值。设计参数RT=S+A+B。6*RT/AT取整。

回归缺陷数0（+5）参数值CT 加分考核指标

由于测试过程中，总有这样那样的问题存在，造成缺陷的忽视，如果在

回归测试中能发现一些被忽视的问题，那应该值得加分。按照提交的回

归缺陷的总数与项目的总数的比来加权量化每个人的分值。设计参数

5*CT/AT取整。（里与非缺陷的-5起到平衡的作用）

严重缺陷所占比例9（15）参数值S 基本考核指标

严重缺陷会给系统带来不可估量的损失，所以当发现严重缺陷数量越多，越能反映这个测试人员的水平。设计参数6*S/AT取整。

提交分类缺陷数6（10）参数值S重大A较重B较小C一般基本考核指标这里为缺陷的提供不同的价值，因为缺陷本身的严重级别存在着不同的

价值。为此加权一些各级别的分值。以6分为基本分。底分+4S/（S+A+B+C）+3A/（S+A+B+C）+2B/（S+A+B+C）底分+1C/（S+A+B+C）

技能：6（10）分

设计执行用例数3（5）参数值T 基本考核指标

编写测试用例数可以从一个侧面反映一个测试人员的测试技能水平。

2*T/AT取整

用例难度0（+2）加分考核指标

测试用例的难度是一个加分的指标，可以区别编写测试用例的水平。

执行用例数3（5）参数值T 基本考核指标

执行测试用例数可以从一个侧面反映一个测试人员的测试技能水平。

2*T/AT取整

工具掌握能力0（+3）加分考核指标

现在自动化工具是测试的趋势，所以根据公司的需要，可以作为评判测

试人员水平的加分标准。

文档0（10）

缺陷描述0（5）

问题描述是否清晰，问题定位的附件是否完整，问题描述语言是否规范，都将是评判一个测试人员的缺陷描述的准则，一个好的测试人员，不仅

仅在发现缺陷上有能力，在缺陷的描述上一样需要有能力，因为只有准

确的描述才能帮助开发人员及早的解决问题。

测试报告的质量0（5）

报告描述是否清晰，报告定位的附件是否完整，报告描述语言是否规范，都将是评判一个测试人员的缺陷描述的准则，一个好的测试人员，同样

要能编写合格的测试报告。

综合素质3（20）

综合素质包含了许多方面，都是从主观因素去判断一个测试人员，可以分为：动手能力（2），创新能力（2），规章制度（2），工作态度（6），沟通能力（2），钻研能力（2），协作能力（2），自学能力（2）。个人觉得，作为一个测试人员，其工作态度尤其重要，因为工作本身有时会重复，疲劳，如果你没有充分的兴趣，良好的工作态度，是很难做好这份工作的。相比，其他的分值就略微偏低些。

通过以上的这些参数的选取，具体的量化，整体对一个测试人员做了全面的量化，通过四点概要的参数，再细分每一个内部的参数，比较客观的量化了一个测试人员的整体工作。

3.2详细设计

3.2.1界面的布局

整个量化的参数的选取，量化，都已经在上面的章节中分析完毕，下面就开始实施具体的软件设计。

通过之前的结构分析，将整个软件分为了4个模块。在界面的布局中，同样也分成4个窗体。窗体一如图，即为主窗体。实现其他模块的之间的调用。设计有MainMenu,等控件。

输入模块，如下图，当主窗口打开时，即打开输入窗体，其分为基本信息，技能，文档，缺陷单，综合素质，总评。等几个子输入模块。