一个大型集中项目的性能测试实例

一个大型集中项目的性能测试实例（上）

从20xx年8月底至20xx年 10月中，本人在北方L省的一个全省集中的交换网管项目中负责该项目的试历时1个半月多，投入了3.6人月，占总的项目测试投入的 17%。性能测试共进行了三轮，测试实现了预发现影响性能的2级缺陷5个，三级缺陷8个，其中有一个缺陷导致了架构的部分变更。缺 陷修改完成后，整了60%，告警入库效率提升了20%，应用的修改也使得系统具有了更强的稳定性。从测试的结果来说，本次效果，在测试过程中，本人也有一些心得和体会，因此，通过这篇文章记录本次性能测试的过程，希望能和各加深入的交流。

1. 背景

本人参与的项目是一个全省大集中的交换网管项目，该项目使用的所有服务器(数据库服务器、应用服务器器、WEB服务器) 均部署在省中心机房，所有的数据采集和处理都在省中心完成，地市通过反拉终端通过WE中心的服务器。考虑全省的需要，在整个系 统上线后，总的用户数应该在1500左右。

图1是本项目的结构示意图。

在我们这个系统之前，L省的交换网管采用的是本地网管理方式，也就是每个地市都有自己的本地网网管系据仅仅是定期的报表。 采用分散的本地网网管形式，每个本地网系统仅需要支持少量本地用户的访问，因此在性也没有进行过性能方面的测试。

我们为L省提供的新的解决方案是全省大集中的统一交换网管，一方面所有的用户都通过统一的平台对系面，系统通过已有的 DCN网络对分布在地市的网元进行采集。考虑到用户数据访问地集中、集中带来的数据访老系统上，省中心只能通过地市定期的上报报表 获知地市运行情况，但在新系统中，省中心要求可以随时从任对网元采集的统一，新系统需要承受的压力要远远大于老系统现有压力的叠 加。因此，十分有必要根据目前的次较为全面的性能测试。

我们的系统采用Oracle数据库，IBM MQ消息平台，采用的开发工具包括VS.NET、Perl、HP aCC和H统由6个Unix应用模块、8个PC应用模块和三个WEB项目构成。

本次性能测试进入的条件是项目代码已经基本完成并经过集成测试，1、2级遗留BUG数为0，3级遗留 说明：对于这样一个集中式的系统，DCN网络性能其实也应该是一个被重点考虑的对象，但根据L省以前DCN网络足够支撑当前应用的运行，也就是说，在性能测试过程中不需要考虑由于DCN网络原因造成的数据况。

2. 测试计划

在初步确定了性能测试的要点后，我们就可以依据更具体的要求来制定性能测试计划了，一般来说，性能良好的沟通，测试目 标、终止准则、策略、测试资源配备都需要和客户经过沟通才能最终确定下来。实际操作式会议，会议形成的结论要用会议纪要的方式确定 下来，对最终确定的测试计划需要客户的签字认可。

一份测试计划至少需要包括测试对象、测试目标、测试策略、测试终止准则、测试环境与测试工具、测试资个方面的内容，本文不打算罗列出项目测试计划中的所有内容，只就主要问题进行说明。

测试对象自然是本集中交换网管系统的性能;

测试目标在上文已经提到，需要和用户沟通，得到用户的认可。制定合理的测试目标并不容易，尤其是受限于现单靠文档描述很 难制定出合理的测试目标，在本项目的测试中，我们结合了文档描述、用户要求和个人经验，终确定了测试目标。

根据项目要求，我们对测试总体目标定义为“验证系统的总体处理能力”，对于系统的扩展性，不作为本次测试的出系统能否达到设计性能、系统性能瓶颈所在。其中，“系统能够达到设计性能”是本次测试的最关注内容。 “系统能够满足设计性能”的目标达成需要明确定义性能应该达到的指标。鉴于该部分的工作比较重要，以下性能指标确定过程详细给出(当然，下文的例子中并没有包含全部的数据)，希望能给需要的同仁一点帮助。 需求和设计阶段确定的性能相关指标是性能测试需要确定的性能指标的首要来源，对我们的这个系统而言，标有三个：

1、 “能在一小时完成话务报告的采集，在5分钟内完成报表的生成”;

2、 “具有600网元的告警和话务处理能力”; 软件开发网

3、 “告警要求在5秒内呈现”;

在设计文档中，对于告警处理能力有更详细的指标定义：

1、 “能处理平均每秒200次的告警”;

2、 “能处理峰值为每秒600次的告警”;

针对这两份文档中的描述，我们至少可以确定我们需要针对以下两种情况进行测试： 软件开发网

1、 针对600个网元话务报告的采集和处理进行测试，采集过程要求在一小时完成;报表生成需要在5分

2、 针对600个网元的告警处理能力进行测试，在告警产生的均值为200次/秒，峰值产生为600次/秒呈现的时间间隔不超过5秒;

软件开发网

粗看起来，这两个指标的定义已经很详细了，但仔细考究，其实这样的描述还是远远不够的，例如，对第一时间产生一次数据) 必须要指明，因为5分钟的话务周期和1小时的话务周期在处理速度上是有很大差别的;对在多少呈现告警客户端的条件下，因为多个告警客 户端和单个告警客户端在性能上肯定会有不同。

除了从文档中获取的指标外，直接从用户处获取的指标也很重要，例如，在可客户的沟通中就发现，客户对时间也非常关注，但在需求中并未提到该需求，当然，通过和客户直接沟通获取的指标必须经过变更控制，在文正式纳入测试目标。

还有一个指标的来源就是个人经验了，作为一门实践性的学科，个人经验在测试中发挥的作用也是不能忽视实现，在测试指标中增加“300用户并发时MQ服务器的MQ派生进程数不得超过200个”等。

根据经验补充的为6个。

软件开发网 本次测试最终确定的需要验证的性能指标为14个，其中从文档中直接映射的为6个，从客户获得并经过变

测试策略描述对整个测试采取的方法，本次测试的测试策略规定，测试最少为2轮，每轮测试应该执行所在一轮测试过程中程序 需要保持“锁定”，不允许进行修改，每轮测试结束后需要形成测试结果记录文档;所有的能称为本测试结束，测试结束后需要提供完整的测 试报告，记录整个测试过程和中间结果。

测试终止准则确定测试终止的原则，对本次测试，我们定义了每轮的终止准则“所有测试用例至少执行一次止准则“所有待验证指标都达到”。

测试环境与测试工具确定本测试需要使用的测试工具和定义需要使用的测试环境，这部分的内容非常重要，阶段需要尽可能地考虑 到各种可能的情况，设备资源限制的情况等，否则，在测试执行时才发现环境不完整就的测试工具，测试设计阶段也应该进行详细的规划， 采用商用工具还是自己开发工具?到底需要哪些工具才能划可以让你尽早安排相关人员的配合(例如，需要找开发人员协调开发测试工 具)，反之，把希望寄托在“我有X试工具据说很好用”就一定会导致测试的失败。

早规划工作安排。

3. 测试用例与测试数据 测试资源配置描述执行本测试需要的人员和时间资源，一方面可以作为工作量的评估与项目经理和客户进行沟通

确定了测试计划后，就可以针对测试计划中确定的需要测试的指标设计测试用例了。同样，设计的测试用例并得到客户的认可。一 般来说，客户比较关注的“这个测试用例怎么能说明系统达到了性能指标?”和“我怎么检需要通过会议或是其他方式与客户尽可能地沟 通，在本项目的测试中，我们在第一轮测试中就出现了因为与客其实在测试用例执行之前，我们已经和客户进行了测试用例的确认，但在执 行过程中，用户表示希望能看到更们只能重新修改了部分测试工具和测试环境，导致测试执行未能按计划完成。第一轮测试完成后，我们就 再次详细的审核，包括每个用例的详细输入、输出，以及如何验证输出。 软件开发网

从已确定的测试指标产生测试用例没有单一的法则，这个就是测试设计员(Test Designer)的基本功了，在 关于测试用例的书写格式在51cmm和其他很多网站上都有讨论，我个人的感觉是不必要太多拘泥于测试要测试用例描述清楚了测试步骤、输入、预期输 用例编号XXXX_NFT_PT_XX用例对应功能点

用例编号 XXXX_NFT_PT_XX 用例对应功能点 用例类型 性能 用例优先级 用例简要描述 XXXXXXX 依赖用例 用例创建人 用例执行时间 用例执行先决条件

1． 使用一台采集服务器作测试用；

2． 已通过模拟程序产生每秒300条告警的告警数据；

3． 所有告警产生和呈现时间记录在本地日志文件中。 检测方法

1． 由网元模拟程序产生特定告警（T1）；

2． 告警被上层应用呈现的时间由上层应用记录（T2）；

3． 计算T2－T1，结果小于5秒； 修改记录 〔修改人〕 （修改时间） （修改内容） 用例描述 步骤 操作 输户启动主界面，进入告警监控界面 2 产生一个特定告警（便于识别），发送至系统 XXXX（特定告警的详细内间记录在文件XXXX中 3 在告警监控界面上查看特定告警 观察到特定告警出现的时间（记录在文件XXXX中

相差不超过5秒 测试结果描述：

测试结论：从本测试用例中可以看到，测试用例已经详细定义了用例执行的先决条件、测试输入和输出，以很直例的各个要素。

设计测试用例的过程中，同时需要关注的是测试数据的产生和维护。

在上一个测试用例的例子中，“特定告警的详细内容”就是一个被选择的测试数据，如何选择具体的测试数据求而定，没有统一的法则。但在设计测试用例时，一定要明确每个用例的数据需求并将这种需求综合起来，并形据的维护 策略，以便在测试用例执行时能顺利进行。

一般而言，我们可以考虑初始测试数据的需求、考虑测试用例之间的依赖关系、记录每个用例对数据的要求些测试数据和如何维护测试数据。

【小结】

本文记录了一个对大型集中项目的性能测试过程，对于性能测试过程中的测试目标选择、测试用 例的设计进行了较为详细的讨论，后续的“下”篇中将重点描述测试环境准备、测试工具应用、测试实施、测试报告方面的程中的一些问题进行了讨论，希望各位同仁不吝指正。

一个大型集中项目的性能测试实例（下）

4. 测试环境与测试工具

制定了合理的测试计划、设计了满足需要的测试用例之后，我们就可以开始着手准备测试环境和考虑如何在

4.1. 测试环境

测试环境的部署和维护是一件需要详细策划的事情，部署了合理的测试环境是测试达到目标效果的前提条件署和维护测试环境时，需要考虑以下内容：

测试网络环境

性能测试一般都是在一个网络中进行，可能是一个单独的局域网，也可能是和生产环境相同的网络，不管实必须评估网络状况是否 会对我们的测试产生影响，也就是说，要保证网络环境能够较好地模拟实际网络环境(包当然，在我们的本次测试中，由于网络状况对我们 的测试结果没有什么影响，我们的测试是在一个接近生产环行。

初始数据的准备

在执行测试之前，我们需要准备足够支撑测试进行的初始数据，对本测试来说，初始数据包括静态数据、程据、配置文件、用户帐 号信息等，建议将这部分数据按照不同的数据来源分别列出形成CheckList，这样可以据准备不充分的情况。

本测试中我使用的CheckList示例如表1所示：

表1 本测试中使用的测试环境CheckList

序号 测试环境项目 来源 责任人 预计完成时间 是否已部署 1 数据库静态数据 配置项 XXXX XXXXX元配置数据 测试用例 XXXX XXXXXXX 是 3 WEB用户信息 测试用例 XXXX XXXXXXX 是 4 Unix用户帐

XXXXXXX 否 5 模拟发送的话务数据 测试用例 XXXX XXXXXXX 否 ……

…… …… …… …… …… 10 网元话务报告发送模拟程序 测试用例 XXXX XXXXXXX 是 …… …… …… …… ……CheckList外，还需要准备一份更详细的文档，详细记录每一个环境项目的实际数据，这样的一份文档一方面另一方面，在测试过程中即使人员发生变动，新参与的成员也能很快熟悉整个测试环境。

测试数据的可恢复性

说到测试数据，就不能不提测试数据的可恢复性。在一次测试过程中，一个用例一般都需要被多次执行，但时，就必须保证每次执 行用例时的环境一致，因此在准备好数据，执行用例之前，必须要计划好测试完成后怎据恢复，在本次测试中，我们采用的是为每个测试准 备一个“回滚”脚本，该脚本用来恢复数据至测试用例执行 测试环境的时间同步

在性能测试中，尤其需要注意的是测试环境的时间同步问题。性能测试关注的是系统的总体性能表现，这个模块的响应时间来体现，在本次测试中，我们在应用程序中增加了部分测试代码，测试代码通过记录关键操作的记录。

基于以上的要求，整个测试环境中各台计算机的时间同步就非常重要了，如果时间不同步的话，就会造成测在本次测试中，部分测试指标要求到秒级，因此，我们必须要对整个环境进行一个精确的时间同步。

本测试的测试环境包括7台HP小型机、两台WEB服务器、一台Windows域服务器和15台加入域的PC我们以一台小 型机为主时间服务器，采用Windows域服务器作为Windows机器的时间服务器(域内的客户机自动的时间同步)，利用NTP协 议在Unix主机和Windows域服务器之间进行时间同步，之所以采用NTP协在Internet和Unix系统上被广泛采用的 协议，在Windows平台上，也有基于NTP协议的开源软件(NetT

4.2. 测试工具

测试工具的评估和选择是测试开始之前必须进行的工作。在机械工业出版社出版的《软件测试自动化-引入试工具的评估选择、应用有详细的描述，个人觉得这本书对于测试工具应用部分的说明非常不错，强烈推荐这本朋友。 软件开发网

本测试没有使用商业测试软件，主要原因在于以下几点：

软件开发网

1、 测试时间资源：本测试安排的时间比较紧迫，没有足够的时间用商业测试工具进行录制脚本、脚本调

2、 测试工具的学习曲线：商业测试工具的应用需要一个学习曲线，整个测试团队中只有一名成员具有足测试工具应用的极大障碍;

3、 费用：商业测试工具的授权费用是不能不考虑的，在我们这样一个项目中(客户端数量较大)，商业测合同中没有包含这部分费用的情况下，由项目自身承担这部分费用，显然是不可能的;

4、 灵活性：测试实施过程中可能需要修改测试脚本，考虑到1、2的原因，可能通过Perl等脚本语言编的要求。

软件开发网

最终在本项目中，我们采用了自行开发的测试适用本项目的测试工具，这些测试工具中的部分具有可重用性测试工具，实现测试工 具的最终投入为2.4人月，其中可被重用的工具投入为1.4人月，不能重用的测试工具测试效果来说，这个投入是绝对值得的。 软件开发网

关于本测试中使用的自行开发的测试工具在本文中不准备进行详细描述，需要说明的内容包括如下几点：

1、 测试工具的需求需要根据测试需求来确定：在本项目中，主要是通过测试用例来确定，根据用例描述具。例如，在本文的上篇中作为例子的 测试用例，从该用例的“已通过模拟程序产生每秒300条告警的告警数确需要一个能产生每秒300条告警数据的模拟程序，从“所有告 警产生和呈现时间记录在本地日志文件中”描述程序还必须能够记录告警产生时间。当然，对测试工具的需求确定还必须结合其他用户的需 求。在本测试中，被实现为一个可以根据用户给定的文本文件发送告警数据的工具，通过参数可以指定工具发送告警的间隔以及是式发送;

2、 测试工具的实现语言需要根据实际情况确定：测试工具的实现语言主要看项目成员对语言的熟悉程度中修改测试工具。如果预计到在测试中 需要修改测试工具，建议采用脚本语言来实现测试工具，例如在该测试是采用C 语言实现的，部分测试工具是采用Perl实现的;

3、 测试工具本身也是配置项的一部分：测试工具也需要纳入配置管理的范围，一方面，测试工具的发布置管理流程实现;另一方面，测试工具的开发过程必须符合项目的开发过程。为避免测试工具在使用中带来混乱，

4、 测试工具的开发需要从实际角度出发：千万不要尝试在一个项目中开发出一个强大和完善的测试工具际出发，能满足实际测试需求的测试工 具就是好的测试工具。如果真的觉得有需要对测试工具进一步完善以利成后再专门作为一个项目来专门完善测试相关的测试工具。

我们在把测试工具和测试环境同时包含在这一章中，最主要的原因是因为部署后的测试工具也属于测试环境部署和维护也是测试环境部署和维护的一部分。

上面已经提到，测试工具本身也是配置项的一部分，测试工具的发布需要按照项目的配置管理流程实现，因环境上的部署需要按照 配置管理流程来管理，同时，这也是测试环境部署和维护的一部分。在本测试中，要求发布版本，对测试工具的变更需要进行记录并纳入配 置项变更管理，唯一不同的是这个配置项的变更的发起人测试负责人。

5. 测试实施

测试计划、测试用例、测试环境都完成之后，就可以开始对测试进行实施了。测试实施在整个测试过程中并有了详细的测试用例之后，其实测试实施是一件“照葫芦画瓢”的简单工作。

软件开发网

本章主要探讨性能测试实施过程中需要记录的信息(这部分内容其实应该是在测试计划和测试用例中确定，性，我把这部分内容安排在本章)。

本测试实施记录的内容包括如下：

Unix主机

CPU使用率;

内存使用状况;

Disk I/O;

数据库服务器

Cache命中

Long Transaction

索引使用情况

数据库进程CPU使用状况

数据库内存使用状况

数据库连接数量

应用服务器 软件开发网

MQ的主要进程内存使用状况

MQ的进程数量

软件开发网

TEMIP主要进程内存使用状况

WEB服务器

进程的CPU和内存使用状况

Cache命中

平均响应时间等

对这些内容的记录需要通过操作系统提供的性能观测工具或是应用自身提供的性能观测工具：

1、 在Unix环境中，可以用top、vmstat、iostat程序观察需要记录的内容，更好的方法是自己写一个输出信息一同存入本 地日志文件。在本测试中，我们用Perl和Unix的Shell脚本实现了对输出信息的抽取和件可以方便地被Excel等程序进行处 理;

2、 对于数据库环境，可以用Oracle自带的性能监测工具或是第三方软件(如TOAD等)观察性能并存成

3、 对WEB服务器，可以用WEB Server自带的性能监测工具监测其性能。

6. 测试结果分析与测试报告

通过测试实施取得了数据之后，最后一步就是对测试结果进行分析了。对测试结果进行分析我个人认为是比要对结果进行分析，首先需要非常明确获取的每个数据的意义，然后根据数据测试目标，对数据进行详尽分析，明测试目标。 软件开发网

本项目中使用的测试结果分析工具包括Excel、UltraEdit、vi和数据库查询工具等，vi和UltraEdit用来记录了测试结果的文本文件，数据库查询工具用来从数据库中获取测试结果，Excel用来对初步处理后的测试结具能导入具有一 定格式的文本文件，并能根据数据生成各种统计图形，在本测试中是主要的测试数据分析工具结果可能需要自行开发部分工具进行数据提取 和处理。

软件开发网

测试报告至少应该包括以下几部分的内容：

1、 测试环境描述;

2、 测试准备工作描述：在这部分中需要详细说明测试方案，因为测试报告是要与用户讨论，经用户签字详细列出测试前的准备工作，包括测试 方案、测试数据准备以及测试中记录的数据、测试工具和脚本部署等，根据用户的要求吧，在本测试中，用户要求我们写的非常详细;

3、 测试范围及内容：对本次测试能覆盖的范围进行说明;特别是要说明不包括在本次测试中的内容，以防过了吗?怎么还有XXXX问题”这样的话：)

软件开发网

4、 测试结论：测试结论这部分需要详细说明本测试的结论，包括测试用例执行情况统计、测试是否通过

方式和方法;

除此之外，还可以在测试报告中包括建议与计划，用来说明该测试的后续工作安排和计划;将测试用例的执详细记录作为附件附加到测试报告中。