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

《一个大型集中项目的性能测试实例》由会员分享，可在线阅读，更多相关《一个大型集中项目的性能测试实例（8页珍藏版）》请在金锄头文库上搜索。

1、一个大型集中项目的性能测试实例一个大型集中项目的性能测试实例（上）从 2004 年 8 月底至 2004 年 10 月中，本人在北方 L 省的一个全省集中的交换网管项目中负责该项目的性能测试工作。该性能测试历时 1 个半月多，投入了 3.6 人月，占总的项目测试投入的 17%。性能测试共进行了三轮，测试实现了预期的目标，测试过程中共发现影响性能的 2 级缺陷 5 个，三级缺陷 8 个，其中有一个缺陷导致了架构的部分变更。缺 陷修改完成后，整个系统的采集效率提升了 60%，告警入库效率提升了 20%，应用的修改也使得系统具有了更强的稳定性。从测试的结果来说，本次测试取得了 比较满意的效果，在测试

2、过程中，本人也有一些心得和体会，因此，通过这篇文章记录本次性能测试的过程，希望能和各位同仁进行性能测试的更加深入的交流。 1. 背景 本人参与的项目是一个全省大集中的交换网管项目，该项目使用的所有服务器(数据库服务器、应用服务器、采集服务器、认证服务器、WEB 服务器) 均部署在省中心机房，所有的数据采集和处理都在省中心完成，地市通过反拉终端通过 WEB 和 Socket 方式访问省中心的服务器。考虑全省的需要，在整个系 统上线后，总的用户数应该在 1500 左右。 图 1 是本项目的结构示意图。 在我们这个系统之前，L 省的交换网管采用的是本地网管理方式，也就是每个地市都有自己的本地网网管系

3、统，对省中心提供的数据仅仅是定期的报表。 采用分散的本地网网管形式，每个本地网系统仅需要支持少量本地用户的访问，因此在性能方面没有过多的考虑，也没有进行过性能方面的测试。 我们为 L 省提供的新的解决方案是全省大集中的统一交换网管，一方面所有的用户都通过统一的平台对系统数据进行访问，另一方面，系统通过已有的 DCN 网络对分布在地市的网元进行采集。考虑到用户数据访问地集中、集中带来的数据访问需求的增加(在以前的老系统上，省中心只能通过地市定期的上报报表 获知地市运行情况，但在新系统中，省中心要求可以随时从任一位置获取系统数据)、对网元采集的统一，新系统需要承受的压力要远远大于老系统现有压力的叠

4、 加。因此，十分有必要根据目前的情况，对整个系统进行一次较为全面的性能测试。 我们的系统采用 Oracle 数据库，IBM MQ 消息平台，采用的开发工具包括 VS.NET、Perl、HP aCC 和 HP Temip 平台。整个系统由 6 个 Unix 应用模块、8 个 PC 应用模块和三个 WEB 项目构成。 本次性能测试进入的条件是项目代码已经基本完成并经过集成测试，1、2 级遗留 BUG 数为 0，3 级遗留 BUG 数不超过 5 个。 说明：对于这样一个集中式的系统，DCN 网络性能其实也应该是一个被重点考虑的对象，但根据 L 省以前类似项目经验，目前的DCN 网络足够支撑当前应用的

5、运行，也就是说，在性能测试过程中不需要考虑由于 DCN 网络原因造成的数据丢失和应用程序异常的情况。 2. 测试计划 在初步确定了性能测试的要点后，我们就可以依据更具体的要求来制定性能测试计划了，一般来说，性能测试计划需要与客户进行良好的沟通，测试目 标、终止准则、策略、测试资源配备都需要和客户经过沟通才能最终确定下来。实际操作中，建议至少召开一次正式会议，会议形成的结论要用会议纪要的方式确定 下来，对最终确定的测试计划需要客户的签字认可。 一份测试计划至少需要包括测试对象、测试目标、测试策略、测试终止准则、测试环境与测试工具、测试资源配置(人员与时间)几个方面的内容，本文不打算罗列出项目测试

6、计划中的所有内容，只就主要问题进行说明。 测试对象自然是本集中交换网管系统的性能; 测试目标在上文已经提到，需要和用户沟通，得到用户的认可。制定合理的测试目标并不容易，尤其是受限于现有项目文档的详细程序，单靠文档描述很 难制定出合理的测试目标，在本项目的测试中，我们结合了文档描述、用户要求和个人经验，经过和用户的讨论，才最终确定了测试目标。根据项目要求，我们对测试总体目标定义为“验证系统的总体处理能力”，对于系统的扩展性，不作为本次测试的目标。测试结论要求给出系统能否达到设计性能、系统性能瓶颈所在。其中，“系统能够达到设计性能”是本次测试的最关注内容。 “系统能够满足设计性能”的目标达成需要明

7、确定义性能应该达到的指标。鉴于该部分的工作比较重要，以下将本次测试中的应达到性能指标确定过程详细给出(当然，下文的例子中并没有包含全部的数据)，希望能给需要的同仁一点帮助。 需求和设计阶段确定的性能相关指标是性能测试需要确定的性能指标的首要来源，对我们的这个系统而言，在需求文档中确定的指标有三个： 1、 “能在一小时完成话务报告的采集，在 5 分钟内完成报表的生成”; 2、 “具有 600 网元的告警和话务处理能力 ”; 软件开发网 3、 “告警要求在 5 秒内呈现”; 在设计文档中，对于告警处理能力有更详细的指标定义： 1、 “能处理平均每秒 200 次的告警”; 2、 “能处理峰值为每秒

8、600 次的告警”; 针对这两份文档中的描述，我们至少可以确定我们需要针对以下两种情况进行测试： 软件开发网 1、 针对 600 个网元话务报告的采集和处理进行测试，采集过程要求在一小时完成;报表生成需要在 5 分钟内完成 ; 2、 针对 600 个网元的告警处理能力进行测试，在告警产生的均值为 200 次/秒，峰值产生为 600 次/秒的情况下，告警从产生到呈现的时间间隔不超过 5 秒; 软件开发网粗看起来，这两个指标的定义已经很详细了，但仔细考究，其实这样的描述还是远远不够的，例如，对第一个指标，话务周期(多长时间产生一次数据) 必须要指明，因为 5 分钟的话务周期和 1 小时的话务周期在

9、处理速度上是有很大差别的; 对第二个指标，必须说明在多少呈现告警客户端的条件下，因为多个告警客 户端和单个告警客户端在性能上肯定会有不同。 除了从文档中获取的指标外，直接从用户处获取的指标也很重要，例如，在可客户的沟通中就发现，客户对于实时性能数据的呈现时间也非常关注，但在需求中并未提到该需求，当然，通过和客户直接沟通获取的指标必须经过变更控制，在文档中变更体现后才能被正式纳入测试目标。 还有一个指标的来源就是个人经验了，作为一门实践性的学科，个人经验在测试中发挥的作用也是不能忽视的，例如，根据系统的实现，在测试指标中增加“300 用户并发时 MQ 服务器的 MQ 派生进程数不得超过 200

10、个”等。 本次测试最终确定的需要验证的性能指标为 14 个，其中从文档中直接映射的为 6 个，从客户获得并经过变更控制认可的为 2 个，根据经验补充的为 6 个。 软件开发网测试策略描述对整个测试采取的方法，本次测试的测试策略规定，测试最少为 2 轮，每轮测试应该执行所有的测试用例至少一次，在一轮测试过程中程序 需要保持“锁定”，不允许进行修改，每轮测试结束后需要形成测试结果记录文档;所有的待验证指标都达到后才能称为本测试结束，测试结束后需要提供完整的测 试报告，记录整个测试过程和中间结果。 测试终止准则确定测试终止的原则，对本次测试，我们定义了每轮的终止准则“所有测试用例至少执行一次”，定义

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

12、需要的人员和时间资源，一方面可以作为工作量的评估与项目经理和客户进行沟通，另一方面，也可以尽早规划工作安排。 3. 测试用例与测试数据 确定了测试计划后，就可以针对测试计划中确定的需要测试的指标设计测试用例了。同样，设计的测试用例也需要向客户解释清楚并得到客户的认可。一 般来说，客户比较关注的“这个测试用例怎么能说明系统达到了性能指标?”和“我怎么检验你的测试结果 ?”，因此需要通过会议或是其他方式与客户尽可能地沟 通，在本项目的测试中，我们在第一轮测试中就出现了因为与客户沟通不够出现的问题，其实在测试用例执行之前，我们已经和客户进行了测试用例的确认，但在执 行过程中，用户表示希望能看到更详细

13、的中间结果，导致我们只能重新修改了部分测试工具和测试环境，导致测试执行未能按计划完成。第一轮测试完成后，我们就 再次和用户对测试用例进行了详细的审核，包括每个用例的详细输入、输出，以及如何验证输出。 软件开发网 从已确定的测试指标产生测试用例没有单一的法则，这个就是测试设计员(Test Designer)的基本功了，在这里不进行描述。 关于测试用例的书写格式在 51cmm 和其他很多网站上都有讨论，我个人的感觉是不必要太多拘泥于测试用例的书写方式，一般只要测试用例描述清楚了测试步骤、输入、预期输 用例编号 XXXX_NFT_PT_XX 用例对应功能点 用例编号 XXXX_NFT_PT_XX 用

14、例对应功能点 用例类型 性能 用例优先级 用例简要描述 XXXXXXX 用例依赖关系 无 用例依赖用例 用例创建人 用例执行时间 用例执行先决条件 1 使用一台采集服务器作测试用； 2 已通过模拟程序产生每秒 300 条告警的告警数据； 3 所有告警产生和呈现时间记录在本地日志文件中。 检测方法 1 由网元模拟程序产生特定告警（T1）； 2 告警被上层应用呈现的时间由上层应用记录（T2）； 3 计算 T2T1 ，结果小于 5 秒； 修改记录 修改人 （修改时间） （修改内容） 用例描述 步骤 操作 输入数据 预期输出 1 用户启动主界面，进入告警监控界面 2 产生一个特定告警（便于识别），发送

15、至系统 XXXX（特定告警的详细内容） 特定告警的发送时间记录在文件 XXXX 中 3 在告警监控界面上查看特定告警 观察到特定告警出现的时间（记录在文件 XXXX 中）和告警实际发生时间相差不超过 5 秒 测试结果描述： 测试结论：从本测试用例中可以看到，测试用例已经详细定义了用例执行的先决条件、测试输入和输出，以很直观的方式给出了测试用例的各个要素。 设计测试用例的过程中，同时需要关注的是测试数据的产生和维护。 在上一个测试用例的例子中，“特定告警的详细内容”就是一个被选择的测试数据，如何选择具体的测试数据需 要根据测试的具体需求而定，没有统一的法则。但在设计测试用例时，一定要明确每个用例

16、的数据需求并将这种需求综合起来，并形成对测试环境的测试数据的维护 策略，以便在测试用例执行时能顺利进行。 一般而言，我们可以考虑初始测试数据的需求、考虑测试用例之间的依赖关系、记录每个用例对数据的要求，然后最终确定需要哪些测试数据和如何维护测试数据。 【小结】 本文记录了一个对大型集中项目的性能测试过程，对于性能测试过程中的测试目标选择、测试用 例的设计、测试数据的产生和维护进行了较为详细的讨论，后续的“下”篇中将重点描述测试环境准备、测试工具应用、测试实施、测试报告方面的内容，并对性能 测试过程中的一些问题进行了讨论，希望各位同仁不吝指正。一个大型集中项目的性能测试实例（下）4. 测试环境与测试工具制定了合理的测试计划、设计了满足需要的测试用例之后，我们就可以开始着手准备测试环境和考虑如何在测试中运用测试工具了。4.1. 测试环境 测试环境的部署和维护是一件需要详细策划的事情，部署了合理的测试环境是测试达到目标效果的前提条件。一般来说，在考虑部署和维护测试环境时，需要考虑以下内容： 测试网络环境 性能测