性能测试需求分析及用例.docx

性能测试需求提取

复习了一些常见的理论概念后，我们开始性能测试需求的提取。这个过程是非常重要的，往往测试失败，就是因为在这个过程中不知道如何得到确切的性能指标，而导致测试无法正常开展。性能测试需求提取一般的流程如图5-1所示。

图5-1性能测试需求提取流程

分析提取指标

在用户需求规格说明书中，会给出系统的功能、界面与性能的要求。规范的需求规格说明书都会给出明确的性能指标，比如单位时间内访问量要达到多少、业务响应时间不超过多少、业务成功率不低于多少、硬件资源耗用要在一个合理的范围中，这些指标都会以可量化的数据进行说明。如果，实际项目并没有这些正规的文档时，项目经理部署测试任务给测试组长时，一般就会说明是否要对项目的哪些业务模块进行性能测试，以及测试的要求是什么的。最麻烦的就是项目经理或者客户要求给出一个测试部门认为可以的数据，这样非常难做的。可是“甲方”往往都是提要求的，“乙方”只能“无条件”接受！

对于正规的项目，用户需求规格说明书中一般会给出类似表5-1的性能测试要求：

测试项

测试项

响应时间

业务成功率

并发数

CPU 使用率

内存使用率

用户登录

=3秒

98%

20

75%

75%

表5-1需求规格说明书中的性能要求

表5-1给出的指标非常明确，在测试过程中，我们只需收集用户登录模块的响应时间、

登录成功率、并发数、CPU使用率、内存使用率的数据，然后与表5-1的指标进行比较即可，通过的，就认为达到了客户要求的性能，未达到就分析原因，并给出测试报告及解决建议。

大多数是没有明确的需求，需要我们自己根据各种资料、使用各种方法去采集测试指标。以OA系统为例，假设《FIXOA系统需求规格说明书》中并未指明系统的性能测试要求，需要测试工程师自己分析被测系统及采集性能衡量指标。

分析OA系统的结构，所有功能中仅有考勤模块可能是被测系统最终用户经常使用的业务点，那么我们的重点应该在放在该模块上。一般我们可以从下面三个方面来确定性能测试点：

第一、用户常用的功能。常用的功能一旦性能无法满足，比如登录功能，从输入用户名与密码点击登录按钮到显示成功登录信息，花了5分钟，这样的速度是人无法忍受的。而对于用户不常用的，比如年度报表汇总功能，三个季度甚至是一年才使用，等个10分钟也是正常的，这些是跟用户的主观感受相关的，得根据实际情况区分。

第二、 系统业务逻辑复杂，数据流转频繁的功能。这些地方最终用户可能看不到、用不到，但在系统是个关键点，没有它其他功能就不能正常工作，即使用户未提出做性能测试，作为测试部门也应该对这些地方进行性能测试，以保证他们能够正常工作。

第三、

与外部系统的接口处。有时候本系统需要使用其他系统的组件。我做过的一个项目，B/S结构的企业信息管理系统，其用户管理模块中的用户数据就是使用早期C/S结构的ERP系统。前一个使用Oracle数据，后一个是用Sybase数据，设定了每三个小时更新一下用户信息，以保证两个系统用户信息是一致的。这样的功能，也是应该做测试的，特别是涉及到多系统的。

综合考虑，与考勤模块相关的是登录模块，因为登录是考勤的前置条件，所以在实际的测试中不仅要测试考勤的，还应该考察登录模块的性能表现，尽管这不是用户要求的。

OA系统是一个面向广大企业用户的办公自动化系统。根据大多数公司的作息安排，早上九点基本是公司的上班时间。那么根据实际业务分析，早上8:40到9:10可能是OA系统登录的高峰期。因为很多人集中在这个时候达到公司进行考勤业务操作。这个时候，就可以确定系统测试的一个时间段了。接下来，需要调查一般会有多少人使用OA系统，这个数据比较难，应该公司的规模不一样，人数也就不一样。既然是面向公众，那么就可以由开发工程师给出一个参考值，比如开发工程师说可以支持2000人同时使用，那么我们就将使用系

统的人数定为2000人。既然说是2000人同时使用，我们可以理解为2000人在8:40到9:10

这30分钟的时间里都要完成登录、考勤操作，并且不能有失败的业务。也就是说业务的成

功率要求在100%。这样一来，到目前为止，得到了下面几个数据：1、OA系统使用高峰期为30分钟；

2、并发使用人数为2000；

3、登录、考勤成功率100%。

接着分析，在满足功能的同时，还需要考虑操作的响应时间。很多公司都有迟到处罚制度，我原来的公司迟到一分钟扣五块钱，有的公司甚至更狠。所以，如果应为页面反映慢而导致迟到，会“冤死”一批人，这样的问题绝对不能出现。那么响应时间为多少算正常呢？说实话，这样的问题本身就是有问题的，何谓快，何谓慢？都是主观判断，你心急的时候觉得它慢，不急的