浅谈性能指标的定义

浅谈性能指标的定义

本文通过对目前性能指标相关的一些问题的分析，总结了合理的性能指标需求所必须具备的五个基本特征，可以作为测试参加产品前期需求评审时的一个参考，在此基础上，进一步探讨了确定合理的性能指标需求的建议思路。另外，本文主要关注软件系统的性能指标问题，不涉及系统可靠性方面的讨论。

一、             性能指标现状分析

目前性能测试中，性能指标的问题普遍困扰着测试人员。这类问题的原因是多方面的：

1）  有些产品在需求中根本就没有提及性能指标需求，导致性能测试中没有测试结束的准则，不能判断性能测试的结果是否合理，最终开发人员和测试人员在对系统进行评价时陷入没完没了的争执之中。

2）  系统设计人员理论和经验的不足，导致需求中的性能指标定得不合理。主要表现在：定的性能指标不具有代表性，不能用于衡量系统的真实性能；性能指标不具有可测试性，难于通过性能测试进行验证并获得数据；性能指标不实用，无法作为后续配置计算的根据；还有其他一些问题等等。

3）  测试人员在理论和经验上也存在不足，无法在前期介入、参加需求评审时，对性能指标需求提出中肯的意见，有效控制性能指标需求的合理性。相比于系统设计人员，测试人员的介入时间较晚、介入程度不深，在前期对系统的理解不够透彻，面对系统设计人员给出的性能指标需求，往往感觉不合理，但难于提出建设性的建议。

凡此种种，为后续的性能测试工作中出现的各种问题种下了根源，是性能测试工作一直徘徊不前的重要原因。

下面我们将进一步的探讨什么是合理的性能指标需求，并提出确定合理的性能指标的建议思路。

二、             性能指标要求

首先，我们先来探讨一下合理的性能指标需求需要具备哪些基本特征，由此而建立一些基本的共识，在此基础上我们才能探讨如何去达到这些要求，并最终寻找解决这些问题的办法。

合理的性能指标应该具备如下基本特征：

1、  需求性

性能指标是设计出来的，不是测试出来的。这是我们始终需要强调的第一原则。性能指标应该来源于需求，性能测试工作作为验证和确认的一种手段，其最主要的目的就是验证产品的性能是否达到了需求中的要求。那种在产品需求中不确定性能需求、或者在产品需求中随便确定性能需求，而留待测试人员最终给出性能指标的想法，是极端错误和不负责任的，它使后续的性能测试工作陷入目的不明确、评价标准不明确、结束准则不明确等状态，使性能测试在方案设计、执行、评估等环节都失去了基础，因此最终的测试质量无法得到有效保证。在这种情况下，性能测试可能做了大量的重复工作，却不能得到客观、全面的系统性能评价，性能测试报告也得不到大家的认同。

当性能需求包含在产品设计规格中后，我们就需要考察这些性能需求的合理性。

2、  代表性

产品设计规格中确定的性能指标应该具有代表性，能够用于衡量系统的真实性能。这要求确定性能指标时需要从系统的使用者的角度出发，分析系统使用者的主要行为与使用要求，综合、概括出性能指标项，并根据标准规范、系统使用要求、竞争对手的系统性能、用户的容忍程度等，给定合理的性能指标值。

例如在彩铃Portal中，如果我们使用WEB中常用的每秒点击率作为性能指标，就很难用于衡量彩铃Portal的真实性能。彩铃Portal提供的主要是用户登录、浏览、下载、设置彩铃等功能，对彩铃Portal的性能而言，真正有代表性的是单位时间内能完成上述功能的次数、完成这些功能的响应时延、以及同时在操作这些功能的在线用户数等指标，这些才能真正刻画彩铃Portal的系统性能。而每秒点击率过于微观，只能代表彩铃Portal中WEB服务请求处理部分的性能，不能代表包含后台逻辑处理、数据库处理在内的整个系统的性能；只能代表单次WEB请求处理的性能，不能代表包含一序列请求的某一功能的处理性能。

3、  可测性

产品设计规格中的性能需求还必须具备可测试性，也就是说，要便于通过性能测试工作来验证产品是否达到了性能需求。

性能需求的可测试性包含两方面的内容，一方面是要求产品设计本身要具备可观察、可控制的特性，使我们在性能测试中，能够观察、收集到系统的一些关键资源占用数据和关键指标，以便做出合理评价，并且能够控制系统的一些行为，使系统性能测试能够得到顺利的开展。这些都是典型的产品可测试性的范畴，我们不再深入的讨论，我们再来看另一方面的内容。另一方面就是要求系统能够具备按计划及时开展性能测试的条件，不要出现本系统的性能指标需要倚赖于其他系统才能测试的情况。举个例子来说，假如我们开发一个新的智能网平台，指定了一项性能指标为“在IBM P630上能够支持100CAPS的PPS呼叫”，这就会出现一个问题，当我们的新平台开发完后，可能会没有配套的新平台下的PPS业务，我们就无法及时的测试新平台的性能，性能测试计划到时就会无法实施，所以这样的性能指标需求可测试性就不好。

4、  可用性

系统的性能指标还必须具备良好的可用性，也即是说，系统的下游环节的使用者能够根据该系统的性能指标，对本环节的设计方案的性能做出合理的估计，从而保证设计的合理性。

举例来说，平台的下一级用户是业务，那么，平台所提供的性能指标，应该能够供业务设计人员作为依据，再根据业务的复杂度，来估计业务的性能表现，从而提出业务产品的性能指标需求。同样，业务产品的下一级用户是运营商，业务产品所提供的性能指标，应该能够做为配置计算的依据，使运营商能够合理的设计自己的业务提供网络。

5、  完整性

系统的性能指标需求还必须足够完整，不能过于片面。概括来说，完整的性能指标需求必须包含如下要素：系统的服务提供能力要求、系统的服务提供质量要求、系统的软硬件配置条件。

系统的服务提供能力通常包含：容量、单位时间内处理的请求数、同时在线用户数。性能需求中，应该从这些方面给定具体的服务提供能力要求。

系统的服务提供能力通常都是基于一定的服务质量要求的，性能需求中需要包括服务提供质量的要求，服务提供质量通常包含：响应率、正确率、响应延时。

在不同的软硬件配置下，系统会具有不同的服务提供能力和服务提供质量。因此，我们在指定系统性能指标值时，应该限定此时的系统软硬件配置条件。

只有同时具备以上三个要素的性能需求，才是完整的，其中，服务提供能力和服务提供质量可以根据服务的类型再细分，针对不同的服务类型提出不同的要求。

需求性、代表性、可测性、可用性、完整性是合理的产品性能需求所需要具备的基本特征，测试人员在参加产品前期的需求评审时，可以从这五个基本特征的要求对产品的性能需求提出自己的意见和建议，从而有效控制产品性能需求的合理性，为后续的性能测试工作的顺利开展奠定必要的基础。

这部分内容也可以增加到测试参与产品前期工作的CHECKLIST中去，起到指导和限定的作用。

三、             性能指标的确定思路

前面我们分析了合理的性能指标应该具备的五个基本特征，可以作为测试参加产品前期需求评审的一个参考标准，进一步地，我们需要探讨一下怎么样才能得到合理的性能指标需求。

确定性能指标需求过程应该包含两个阶段，首先是如何确定需要哪些性能指标项，其次是确定这些性能指标项应该取什么值。

下面我们将为这两个阶段提供一些参考思路。

1、  指标项的确定

前面我们在性能指标的完善性要求中，已经提到了性能指标应包含服务提供能力和服务提供质量这两方面的内容，并且这两方面的内容还需要根据服务类型进一步细分。因此，我们可以按照如下的思路来确定产品的性能指标项：

1）  列出系统所提供的所有服务功能

2）  分析各功能的可能使用频度，选取使用频度高的功能

3）  分析各功能的可能并发度，选择并发度高的功能

4）  综合使用频度高和并发度高的功能，作为我们需要考虑的服务类型

5）  针对我们选定的每种服务类型，从容量、单位时间处理的请求数、同时在线用户数这三个角度分析，考虑是否需要选取其中的一些角度作为性能指标项

6）  针对我们选定的每种服务类型，从响应率、正确率、响应时延这三个角度分析，考虑是否需要选取其中的一些角度作为性能指标项

7）  从国际标准、国标、运营商的设备规范中提取相关的性能指标项

8）  将以上结果综合成最终的性能指标项

2、  指标值的确定

在确定了性能指标项后，接下来要确定这些性能指标项具体应该取多大的值才合适，这个过程可以按照如下思路来确定：

1）  从国际标准、国标、运营商的设备规范中提取相关性能指标项的取值，如果各标准中要求不一致的，原则上选取要求严格的取值

2）  分析竞争对手目前的性能指标数据，考虑本产品的市场定位，参考竞争对手的性能指标确定本产品的相关的性能指标值

3）  对于缺乏以上数据来源的性能指标项，需要根据对用户的容忍程度、用户习惯等方面的分析，确定性能指标中服务提供质量方面的要求值

4）  对于缺乏以上数据来源的性能指标项，需要根据对用户规模、用户偏好等方面的分析，确定性能指标中服务提供能力方面的要求值

5）  对系统配置进行分档，确定不同档次下，系统的不同软硬件配置级别。

6）  在上述基础上，确定系统不同档次的性能指标值

经过上述过程所获得的性能指标需求，在代表性、可用性、完整性方面都会相对完善一些，再补充考虑可测性方面的要求，进一步完善就可以得到我们的产品性能指标需求。

今天的文章浅谈性能指标的定义分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。