性能测试用例

性能测试用例 从2004年8月底至2004年10月中，本人在北方L省的一个全省集中的交换网管项目中负责该项目的性能测试工作。该性能测试历时1个半月多，投入了3.6人月，占总的项目测试投入的17,。性能测试共进行了三轮，测试实现了预期的目标，测试过程中共发现影响性能的2级缺陷5个，三级缺陷8个，其中有一个缺陷导致了架构的部分变更。缺陷修改完成后，整个系统的采集效率提升了60,，告警入库效率提升了20,，应用的修改也使得系统具有了更强的稳定性。从测试的结果来说，本次测试取得了比较满意的效果，在测试过程中，本人也有一些心得和体会，因此，通过这篇文章记录本次性能测试的过程，希望能和各位同仁进行性能测试的更加深入的交流。 1. 背景 本人参与的项目是一个全省大集中的交换网管项目，该项目使用的所有服务器(数据库服务器、应用服务器、采集服务器、认证服务器、WEB服务器)均部署在省中心机房，所有的数据采集和处理都在省中心完成，地市通过反拉终端通过WEB和Socket方式访问省中心的服务器。考虑全省的需要，在整个系统上线后，总的用户数应该在1500左右。 图1是本项目的结构示意图。 在我们这个系统之前，L省的交换网管采用的是本地网管理方式，也就是每个地市都有自己的本地网网管系统，对省中心提供的数据仅仅是定期的报表。采用分散的本地网网管形式，每个本地网系统仅需要支持少量本地用户的访问，因此在性能方面没有过多的考虑，也没有进行过性能方面的测试。 我们为L省提供的新的解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 是全省大集中的统一交换网管，一方面所有的用户都通过统一的平台对系统数据进行访问，另一方面，系统通过已有的DCN网络对分布在地市的网元进行采集。考虑到用户数据访问地集中、集中带来的数据访问需求的增加(在以前的老系统上，省中心只能通过地市定期的上报报表获知地市运行情况，但在新系统中，省中心要求可以随时从任一位置获取系统数据)、对网元采集的统一，新系统需要承受的压力要远远大于老系统现有压力的叠加。因此，十分有必要根据目前的情况，对整个系统进行一次较为全面的性能测试。 我们的系统采用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网络足够支撑当前应用的运行，也就是说，在性能测试过程中不需要考虑由于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个”等。 本次测试最终确定的需要验证的性能指标为14个，其中从文档中直接映射的为6个，从客户获得并经过变更控制认可的为2个，根据经验补充的为6个。 测试策略描述对整个测试采取的方法，本次测试的测试策略规定，测试最少为2轮，每轮测试应该执行所有的测试用例至少一次，在一轮测试过程中程序需要保持“锁定”，不允许进行修改，每轮测试结束后需要形成测试结果记录文档;所有的待验证指标都达到后才能称为本测试结束，测试结束后需要提供完整的测试报告，记录整个测试过程和中间结果。 测试终止准则确定测试终止的原则，对本次测试，我们定义了每轮的终止准则“所有测试用例至少执行一次”，定义了整个测试的终止准则“所有待验证指标都达到”。 测试环境与测试工具确定本测试需要使用的测试工具和定义需要使用的测试环境，这部分的内容非常重要，对于测试环境，在计划阶段需要尽可能地考虑到各种可能的情况，设备资源限制的情况等，否则，在测试执行时才发现环境不完整就很被动了;对于需要使用的测试工具，测试设计阶段也应该进行详细的规划，采用商用工具还是自己开发工具,到底需要哪些工具才能满足测试的需要,好的规划可以让你尽早安排相关人员的配合(例如，需要找开发人员协调开发测试工具)，反之，把希望寄托在“我有XX测试工具”或是“XX测试工具据说很好用”就一定会导致测试的失败。 测试资源配置描述执行本测试需要的人员和时间资源，一方面可以作为工作量的评估与项目经理和客户进行沟通，另一方面，也可以尽早规划工作安排。 3. 测试用例与测试数据 确定了测试计划后，就可以针对测试计划中确定的需要测试的指标设计测试用例了。同样，设计的测试用例也需要向客户解释清楚并得到客户的认可。一般来说，客户比较关注的“这个测试用例怎么能说明系统达到了性能指标,”和“我怎么检验你的测试结果,”，因此需要通过会议或是其他方式与客户尽可能地沟通，在本项目的测试中，我们在第一轮测试中就出现了因为与客户沟通不够出现的问题，其实在测试用例执行之前，我们已经和客户进行了测试用例的确认，但在执行过程中，用户表示希望能看到更详细的中间结果，导致我们只能重新修改了部分测试工具和测试环境，导致测试执行未能按计划完成。第一轮测试完成后，我们就再次和用户对测试用例进行了详细的审核，包括每个用例的详细输入、输出，以及如何验证输出。 从已确定的测试指标产生测试用例没有单一的法则，这个就是测试设计员(Test Designer)的基本功了，在这里不进行描述。 关于测试用例的书写格式在51cmm和其他很多网站上都有讨论，我个人的感觉是不必要太多拘泥于测试用例的书写方式，一般只要测试用例描述清楚了测试步骤、输入、预期输 用例编号 XXXX_NFT_PT_XX 用例对应功能点 从本测试用例中可以看到，测试用例已经详细定义了用例执行的先决条件、测试输入和输出，以很直观的方式给出了测试用例的各个要素。 设计测试用例的过程中，同时需要关注的是测试数据的产生和维护。 在上一个测试用例的例子中，“特定告警的详细内容”就是一个被选择的测试数据，如何选择具体的测试数据需要根据测试的具体需求而定，没有统一的法则。但在设计测试用例时，一定要明确每个用例的数据需求并将这种需求综合起来，并形成对测试环境的测试数据的维护策略，以便在测试用例执行时能顺利进行。 一般而言，我们可以考虑初始测试数据的需求、考虑测试用例之间的依赖关系、记录每个用例对数据的要求，然后最终确定需要哪些测试数据和如何维护测 试数据。 4. 测试环境与测试工具 制定了合理的测试计划、设计了满足需要的测试用例之后，我们就可以开始着手准备测试环境和考虑如何在测试中运用测试工具了。 4.1. 测试环境 测试环境的部署和维护是一件需要详细策划的事情，部署了合理的测试环境是测试达到目标效果的前提条件。一般来说，在考虑部署和维护测试环境时，需要考虑以下内容: 测试网络环境 性能测试一般都是在一个网络中进行，可能是一个单独的局域网，也可能是和生产环境相同的网络，不管实际的情况如何，我们都必须评估网络状况是否会对我们的测试产生影响，也就是说，要保证网络环境能够较好地模拟实际网络环境(包括网络状况、负载等)。当然，在我们的本次测试中，由于网络状况对我们的测试结果没有什么影响，我们的测试是在一个接近生产环境的100M局域网中进行。 初始数据的准备 在执行测试之前，我们需要准备足够支撑测试进行的初始数据，对本测试来说，初始数据包括静态数据、程序运行时必须的配置数据、配置文件、用户帐号信息等，建议将这部分数据按照不同的数据来源分别列出形成CheckList，这样可以避免在测试过程中出现数据准备不充分的情况。 本测试中我使用的CheckList示例如表1所示: 表1 本测试中使用的测试环境CheckList 除了测试环境CheckList外，还需要准备一份更详细的文档，详细记录每一个环境项目的实际数据，这样的一份文档一方面可以便于对数据的审查;另一方面，在测试过程中即使人员发生变动，新参与的成员也能很快熟悉整个测试环境。 测试数据的可恢复性 说到测试数据，就不能不提测试数据的可恢复性。在一次测试过程中，一个用例一般都需要被多次执行，但在多次执行同一个用例时，就必须保证每次执行用例时的环境一致，因此在准备好数据，执行用例之前，必须要计划好测试完成后怎样将整个测试环境中的数据恢复，在本次测试中，我们采用的是为每个测试准备一个“回滚”脚本，该脚本用来恢复数据至测试用例执行之前。 测试环境的时间同步 在性能测试中，尤其需要注意的是测试环境的时间同步问题。性能测试关注 的是系统的总体性能表现，这些性能表现又需要通过各个模块的响应时间来体现，在本次测试中，我们在应用程序中增加了部分测试代码，测试代码通过记录关键操作的时间来完成性能指标的记录。 基于以上的要求，整个测试环境中各台计算机的时间同步就非常重要了，如果时间不同步的话，就会造成测试结果的不准确，尤其在本次测试中，部分测试指标要求到秒级，因此，我们必须要对整个环境进行一个精确的时间同步。 本测试的测试环境包括7台HP小型机、两台WEB服务器、一台Windows域服务器和15台加入域的PC机，在时间同步方案上，我们以一台小型机为主时间服务器，采用Windows域服务器作为Windows机器的时间服务器(域内的客户机可以实现与域服务器的自动的时间同步)，利用NTP 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 在Unix主机和Windows域服务器之间进行时间同步，之所以采用NTP协议，主要是因为NTP是在Internet和Unix系统上被广泛采用的协议，在Windows平台上，也有基于NTP协议的开源软件(NetTime)可以使用。 4.2. 测试工具 测试工具的评估和选择是测试开始之前必须进行的工作。在机械工业出版社出版的《软件测试自动化,引入，实施和管理》书中对测试工具的评估选择、应用有详细的描述，个人觉得这本书对于测试工具应用部分的说明非常不错，强烈推荐这本书给对这部分感兴趣的朋友。 本测试没有使用商业测试软件，主要原因在于以下几点: 1、 测试时间资源:本测试安排的时间比较紧迫，没有足够的时间用商业测试工具进行录制脚本、脚本调试维护等一系列的工作; 2、 测试工具的学习曲线:商业测试工具的应用需要一个学习曲线，整个测试团队中只有一名成员具有足够的技能，这是限制商业测试工具应用的极大障碍; 3、 费用:商业测试工具的授权费用是不能不考虑的，在我们这样一个项目中(客户端数量较大)，商业测试工具的授权费很高，在 合同 劳动合同范本免费下载装修合同范本免费下载租赁合同免费下载房屋买卖合同下载劳务合同范本下载 中没有包含这部分费用的情况下，由项目自身承担这部分费用，显然是不可能的; 4、 灵活性:测试实施过程中可能需要修改测试脚本，考虑到1、2的原因，可能通过Perl等脚本语言编写的脚本更能满足灵活性的要求。 最终在本项目中，我们采用了自行开发的测试适用本项目的测试工具，这些测试工具中的部分具有可重用性，部分是本项目专用的测试工具，实现测试工具的最终投入为2.4人月，其中可被重用的工具投入为1.4人月，不能重用的测试工具开发投入为1人月，从测试效果来说，这个投入是绝对值得的。 关于本测试中使用的自行开发的测试工具在本文中不准备进行详细描述，需要说明的内容包括如下几点: 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用来对初步处理后的测试结果进行分析，Excel工具能导入具有一定格式的文本文件，并能根据数据生成各种统计图形，在本测试中是主要的测试数据分析工具。当然，某些特殊的测试结果可能需要自行开发部分工具进行数据提取和处理。 测试报告至少应该包括以下几部分的内容: 1、 测试环境描述; 2、 测试准备工作描述:在这部分中需要详细说明测试方案，因为测试报告是要与用户讨论，经用户签字认可的，因此，在报告中详细列出测试前的准备工作，包括测试方案、测试数据准备以及测试中记录的数据、测试工具和脚本部署等，个人的感觉是这部分具体根据用户的要求吧，在本测试中，用户要求我们写的非常详细; 3、 测试范围及内容:对本次测试能覆盖的范围进行说明;特别是要说明不包括在本次测试中的内容，以防以后有人说出“不是测试过了吗,怎么还有XXXX问题”这样的话:) 4、 测试结论:测试结论这部分需要详细说明本测试的结论，包括测试用例执行情况统计、测试是否通过、测试中发现问题的处理方式和方法; 除此之外，还可以在测试报告中包括建议与计划，用来说明该测试的后续工作安排和计划;将测试用例的执行情况和每轮测试执行的详细记录作为附件附加到测试报告中。 NMS 性能测试方案 (一) 产品名称Product name 密级Confidentiality level XXX NMS 内部公开 产品版本Product version Total 17 pages 共17页 XXX XXX NMS 性能测试方案 Prepared by 拟制 XXX Date 日期 2009-10-10 Reviewed by 评审人 TSEG成员、SE、测试经理 Date 日期 Approved by 批准 Date 日期 Authorized by 签发 Date 日期 XXX Technologies Co., Ltd. All rights reserved 版权所有 侵权必究 (TST01T04 V2.0/ IPD-PTM V2.0 / for internal use only) (TST01T04 V2.0/ IPD-PTM V2.0 / 仅供内部使用) 修订记录 日期 修订版本 描述 作者 2009-10-10 1.00 初稿完成 XXX 目 录 5 1 概述 1.1 被测对象概述 5 1.2 测试方案概述 6 1.2.1 写作目的 6 1.2.2 设计思路 6 2 测试需求 6 3 测试环境 7 3.1 网络拓扑图 7 3.2 软/硬件环境 7 4 测试设计 8 4.1 测试对象分析 8 4.2 测试设计策略分析 9 4.2.1 测试重点和用例设计原则 9 4.2.2 测试难点和解决方法 10 4.2.3 测试相关因素影响分析和对应策略 10 4.3 详细测试方法 11 4.3.1 反应时间的性能测试 15 4.3.2 CPU/Memory的性能测试 17 4.3.3 负载的性能测试(压力测试) 18 4.3.4 可靠性测试 19 4.3.5 网络性能测试 20 4.4 自动化测试设计 20 4.5 测试规程设计 20 4.6 测试组网分析 20 4.7 测试工具 21 4.8 其它需求 21 5 附录 21 XXX NMS 性能测试方案 关键词:性能测试 摘 要:本文档描述了XXX NMS 网管性能测试方案，阅读对象为性能测试用例设计人员和执行人员。 缩略语清单: Abbreviations缩略语 Full spelling 英文全名 Chinese explanation 中文解释 XXX Integrated Network Management System 综合网络管理系统 NMS Network Management System 网络管理系统 ATCA Advanced Telecommunications Computing Architecture 高级电信计算架构 参考资料清单: 参考资料清单 名称 作者 编号 发布日期 查阅地点或渠道 出版单位 《XXX 性能基线(V0.1)》 系统组 001 2009-8-8 基线库 NMS 性能测试方案 (二) 1 概述 1.1 被测对象概述 XXX终端管理系统(以下简称XXX)定位于业务管理系统，主要管理帐号、密码、VLAN(Virtual Local Area Network)、IP等。系统提供了整套管理WLAN(Wireless Local Area Network)设备的解决方案，实现对AC(AP Controller)、非轻量级AP(Access Point)的管理。 XXX采用CWMP(CPE WAN Management Protocol)协议与终端交互，可实现设备自动发现、初始自动配置、新业务自动发放、远程故障诊断、终端搜索等功能。 1.2 测试方案概述 1.2.1 写作目的 本文档是用于XXX NMS的性能测试，主要从测试环境，测试工具，测试策略，测试具体的执行方法等事先计划和设计，并提供性能测试的详细说明，包括详细的预置测试环境、性能测试范围和内容、测试过程数据的采集和测试结果分析方法。 1.2.2 设计思路 前提条件:1、网管管理的终端数目不超过网管服务器硬件的最大管理容量:500000个，同时交互的终端不超过5000个(5万的1%);2、网管客户端的数 目不超过300个;3、同时操作网管的客户端不超过150个;4、网管服务器和设备之间带外的带宽不小于2M;5、网管服务器和设备之间带内的带宽,等效节点数×0.5K;6、每个网管客户端和服务器之间的带宽不小于64K;7、网管客户端、服务器采用标配(即配置手册中定义的配置)。 性能测试主要包括被测系统的各项性能指标,反应时间的性能测试,CPU/Memory 的性能测试,负载的性能测试(压力测试),可靠性测试。 测试过程数据采集的对象主要是操作响应时间和系统资源消耗记录，以及为了定 )。注意性能测试过程并不关注功能问题，除位问题而采集的其他数据(DB I/O 非功能问题阻碍了性能测试的顺利进行。 2 测试需求 《XXX 性能基线(V0.1)》， 《XXX 产品描述》， NMS 性能测试方案 (三) 3 测试环境 3.1 网络拓扑图 3.2 软/硬件环境 服务器端: XXX 服务器典型硬件配置: 项目 配置 CPU Xeon双核Woodcrest 1.6GHz以上 内存 2 × 1GB 硬盘 146GB以上 XXX 服务器典型软件配置(基于WINDOWS平台): 项目 配置 操作系统 Windows 2003 Server SP1或SP2(简体中文版) 数据库 MS SQL Server 2000 SP3或SP4(简体中文版) 应用软件 XXX 服务器应用软件、Apache、FileZilla和Tomcat XXX 服务器典型软件配置(基于Solaris平台): 项目 配置 操作系统 Solaris10 数据库 Sybase 15.0.3 应用软件XXX 服务器应用软件、Apache、FileZilla和Tomcat 客户端: XXX客户端典型硬件配置: 项目 配置 CPU P4 2.8G或以上 内存 512MB 硬盘 80GB XXX客户端典型软件配置: 项目 配置 操作系统 Windows XP Professional SP2(简体中文版) 应用软件 XXX客户端软件 NMS 性能测试方案 (四) 4 测试设计 4.1 测试对象分析 在充分了解客户和市场需求的基础上，通过完善和成熟的系统设计，XXX系统具 备了优越并且丰富的功能特性:自动初始化配置，新业务自动发放，远程诊断， 远程升级，业务统计，AC、非轻量级AP统一管理，OSS快速集成等。因此XXX 主要的管理能力如下: 支持10万个终端设备, 支持同时运行250个升级/配置计划, 支持32级终端分组嵌套, , 支持创建32个厂商并对其进行管理 每个厂商下支持创建64个设备类型, 每个设备类型下支持创建128个版本 , 基于XXX系统支持的性能基线值，包括自动配置服务器性能、应用服务器性能和 文件服务器性能。XXX系统性能指标如下表所示。 性能指标 项目 指标 自动配置服务器性能 事件并发处理能力:1000(次) 应用服务器性能 每个应用服务器最大客户端连接数量:1024(个) (CPU占用率最高达到85%，内存消耗最大为1.93G) 文件服务器性能 最大支持同时连接数量:1024(个) (CPU占用率最高达70%，内存消耗最大为100M) 因此此次系统性能测试的主要检测内容: 1( 系统典型应用的反应时间 2( 客户端/服务器的CPU/Memory的使用情况 3( 服务器的响应速度 4( 系统支持的最优负载数量 5( 网络指标 6( 系统可靠性测试 NMS 性能测试方案 (五) 4.2 测试设计策略分析 4.2.1 测试重点和用例设计原则 网管管理能力是网管的整体处理能力，所以在测试用例(测试项目)的设计上需要包括典型的网管操作，包括:AC的管理，CPE的管理。这里需要考虑两部分内容: 参考性能基线:《XXX性能基线(V0.1).XLS》， 参考产品规格说明书:《XXX产品规格说明书》， 除了上面的测试内容外重点还需要考虑基于场景进行验证: 批量注册设备场景:需要在原有数据基础上添加新的设备包括配置不同的业务数据。， 多用户应用场景:多用户同时访问网管对终端操作的应用。 4.2.2 测试难点和解决方法 性能测试的难点在于对问题的界定以及定位。 1、网管性能受环境的影响比较大，性能问题必须是在环境稳定正常情况下能达到性能基线要求的，如果是由于环境问题导致的不能达到性能基线要求的问题，不能作为性能问题对待。这就要求在性能测试过程中必须同时关注操作系统和网络的状况，保证测试在操作系统或者网络不出现异常的情况下进行。 2、性能问题不像功能问题，可以确定操作错误的“点”进而修改这个问题点就能解决问题。性能问题更多的是某个程序段占用了比较多的时间，而这个信息是不能由测试人员能获取的，甚至开发人员也无法通过调试来获取这个信息(调试过程中，程序的执行时间会被改变)，因此网管必须提供在操作过程中记录详细的日志功能，否则性能问题定位将是一个艰难的过程。 可以从下面角度评估: NMS 性能测试方案 (六) 操作结果:操作成功，数据能够实时刷新，操作失败能够友好提示。 ， 操作性能:操作响应时间满足性能基线要求。 ， 进程运行情况:相应节点上进程不出现core、死锁、超时、无响应、返回提示信息异常等情况，在进程处理出现瓶颈的情况下调整业务发放速度以便发现更多产品的性能瓶颈问题。 系统资源消耗:系统资源消耗不出现持久的居高不下，持续增长的情况。， 4.2.3 测试相关因素影响分析和对应策略 由于实验室没有实际的背景数据，很多数据实际上是模拟的。某些情况下模拟数据可以替代真实数据，但是模拟数据具有一定的局限性，必须区分哪些地方可以采取模拟数据哪些地方必须采取真实数据。 1、对模拟设备的操作与对真实设备的操作在时间上肯定是不同的，但是对于查询来说，我们允许这个差异的存在并且认为不影响测试结果，因为查询操作只是取得数据，实际主机并不需要做其他的响应，与模拟设备需要的时间相差比较小;而对于配置操作来说，这个差异就不能接受，因为实际主机需要做一些额外的响应操作，所需要的时间与模拟设备相差比较大。因此除了使用模拟客户端外，还 是需要有若干真实主机。模拟主机的数据只作为背景数据，测试配置操作时，需要在真实主机上测试。 2、LoadRunner运行在几台机器上，模拟设备与网管之间的带宽无法限制。对于需 要限制网管与设备之间的带宽的地方，需要采用真实设备。 NMS 性能测试方案 (七) 4.3 详细测试方法 背景数据: 低容量配置------ TR069管理 PC服务器配置 06110653 PC服务器-HP DL380G5-2*Xeon四核5405 2.0G或以上-8G(4*2G)-5*146G SFF SAS-DVD-2*集成千兆网卡-集成E200阵列卡(128M)-无磁带机-无显示器-机架式-无OS-英文资料-3Y5*8-100V~240V AC-2*1000W(1+1)-无键鼠 PC server,HP DL380G5,2*Xeon 4Core5405 2.0G or above,8G(4*2G),5*146G SFF SAS,No FDD,DVD,2*Integrated 1000M NIC,E200 ArrayCard(128M),No DAT72,No Monitor,Rack Model,No OS,En.Doc,3Y5*8,100V~240V AC,2*1000W(1+1),without Mouse&KB 物理资源数量 1、 1 AP = 1等效节点 2、 支持2000等效节点数 业务资源数量 1、 2000*30=6万 (TR069管理) 1、 50客户端 客户端数 背景流量 1、 网管上同时进行北向接口业务发放操作:100条/s 2、 告警上报:1000条/s《峰值30S告警接收处理能力(告警/每秒)》 1、 性能统计任务:10万(待定) 静态数据 2、 当前告警: 10万(待定) 3、 当前事件: 10万(待定) 4、 历史告警数量:10 万(待定) 5、 日志存储数量: 10万(待定) 低容量配置------ SNMP管理 PC服务器配置 06110653 PC服务器-HP DL380G5-2*Xeon四核5405 2.0G或以上-8G(4*2G)-5*146G SFF SAS-DVD-2*集成千兆网卡-集成E200阵列卡(128M)-无磁带机-无显示器-机架式-无OS-英文资料-3Y5*8-100V~240V AC-2*1000W(1+1)-无键鼠 PC server,HP DL380G5,2*Xeon 4Core5405 2.0G or above,8G(4*2G),5*146G SFF SAS,No FDD,DVD,2*Integrated 1000M NIC,E200 ArrayCard(128M),No DAT72,No Monitor,Rack Model,No OS,En.Doc,3Y5*8,100V~240V AC,2*1000W(1+1),without Mouse&KB 物理资源数量 1、 1 AP = 1等效节点 2、 支持2000等效节点数 3、 1 AC (1个AC可管理2000个AP) 业务资源数量 1、 255 个AP域 (SNMP管理) 2、 1000个负载均衡 (SNMP管理) 客户端数 1、 50客户端 背景流量 1、 网管上同时进行北向接口业务发放操作:100条/s 2、 告警上报:1000条/s《峰值30S告警接收处理能力(告警/每秒)》 静态数据 1、 性能统计任务:10万(待定) 2、 当前告警: 10万(待定) 3、 当前事件: 10万(待定) 4、 历史告警数量:10 万(待定) 5、 日志存储数量: 10万(待定) NMS 性能测试方案 (八) 注:以下各项测试都是在上述背景数据下进行的测试。 4.3.1 反应时间的性能测试 系统典型应用: 处理点或事件 期望的反应时间 实际反映时间平均值(至少3次) 启动U2560 Server 10min 登录客户端 45s 平台告警处理能力(告警/每秒) 250条/s 查询历史告警(记录数<=10000) 3s 记录数<=100000) 10s 查询历史告警(10000< 查询历史告警(记录数>=100000) 30s 查询操作日志(记录数<=10000) 3s 查询操作日志(10000<记录数<=100000) 10s 查询操作日志(记录数>100000) 30s 关闭网管server 1min 关闭网管客户端 3s 告警显示速度 5s 峰值30S告警接收处理能力(告警/每秒) 1000条/s 北向命令处理能力 100条/s 告警定位到列表 2s 设备资源和状态统计 1s 设备资源报表 <30s 设备资源数据定时轮询 2s/台 AC管理: 处理点或事件 期望的反应时间 实际反映时间平均值(至少3次) 查询AC模板信息 1s 查询AC模板的详细信息 1s 增加AC模板 2s 删除AC模板 1s 修改AC模板 1s 同步AC模板 10条/s 删除AC上的模板 1s 增加AP、radio、STA等逻辑资源 2s 删除AP、radio、STA等逻辑资源 1s 配置AP、radio、STA等逻辑资源 2s 同步AP、radio、STA等逻辑资源 10条/s CPE管理: 处理点或事件 期望的反应时间 实际反映时间平均值(至少3次) 单个终端进行在线配置 1s 批量终端进行配置 (绑定模板) 4000台/hr 单个终端升级在线升级 < 10mins 批量终端进行升级 2000台/hr 单个终端进行诊断 2s 1s 查询模板信息 查询模板的详细信息 1s 增加模板 2s 1s 删除模板 修改模板 1s 测试结果分析: NMS 性能测试方案 (九) 4.3.2 CPU/Memory的性能测试 该阶段测试主要是测试系统在设计的性能标准情况的运行情况。 测试条件包括:1.客户端的情况，2.应用服务器的情况，3.数据库服务器的情况 测试步骤:准备使用300个虚拟用户和300个虚拟IP地址，设置Ramp up中为每隔30秒启动20个用户，Duration中为运行1个小时，Ramp Down中为每隔30秒停止20个用户，Scenario Start Time设置为 1 分钟。配合500个用户注册，50个用户呼叫的情况。 测试结果分析:通过系统中的性能监视器，观察CPU/Memory在此测试中的变化，是否符合规定的性能指标。 4.3.3 负载的性能测试(压力测试) 该阶段主要是要找出系统的瓶颈点和系统能支持的最大用户数目。 测试步骤:准备先使用600个虚拟用户和600个虚拟地址。设置Ramp up中为每隔30秒启动20个用户，Duration中为运行1个小时，Ramp Down中为每隔30秒停止20个用户，Scenario Start Time设置为 1 分钟。 AC管理:(包括增加AC模板/删除AC模板/修改AC模板/同步AC模板/删除AC 上的模板/查询AC模板信息;增加/删除/配置/同步AP、radio、STA等逻辑资源) 输入动作 输出响应时间 能否正常运行 10个用户操作 30个用户操作 50个用户操作 80个用户操作 100个用户操作 150个用户操作 。。。 测试结果分析: CPE管理:(包括单个终端进行在线配置/批量终端进行配置/单个终端升级在线升级/批量终端进行升级/单个终端进行诊断/查询模板信息/查询模板的详细信息/增加模板/删除模板/修改模板) 输入动作 输出响应时间 能否正常运行 10个用户操作 30个用户操作 50个用户操作 80个用户操作 100个用户操作 150个用户操作 。。。 NMS 性能测试方案 (十) 4.3.4 可靠性测试 可靠性测试是指被测系统在规定的长时间不停的执行相关的操作，看是否出现异常情况。执行的相关任务包括: 安全管理 企业安全管理考核细则加油站安全管理机构环境和安全管理程序安全管理考核细则外来器械及植入物管理 /告警管理 /终端管理 /业务管理 /计划管理工作 /报表管理 /系统管理。 测试步骤:该阶段测试主要是测试系统在300个用户的情况下长时间运行的性能情况。准备使用300个虚拟用户和300个虚拟IP地址，设置Ramp up中为每隔10秒启动2个用户，Duration中为运行72个小时，Ramp Down中为每隔30秒停止5个用户，Scenario Start Time设置为 5 分钟。 任务具体描述: 连续运行时间: 建议72小时 故障发生的时刻: 故障具体描述: 统计分析: 任务XXX无故障运行的平均时间 (cpu小时) 任务XXX无故障运行的最小时间 (cpu小时) 任务XXX无故障运行的最大时间 (cpu小时) 4.3.5 网络环境指标 网络环境指标是指被测试系统在当时测试的网络环境状况是怎样的，常包括:网 络流量，每秒采样数，网络延迟等。 4.4 自动化测试设计 无 4.5 测试规程设计 无 4.6 测试组网分析 组网参考如下，可根据实际情况进行调整: IAD:Integrated Access Device，综合接入设备 DSLAM:Digital Subscriber Line Access Multiplexer，数字用户线接入复用 器 BRAS:Broadband Remote Access Server，宽带接入服务器 Home Gateway，家庭网关 HGW: 4.7 测试工具 1(MI(Mercury Interactive )公司的LoadRunner 2(性能监视器 (Microsoft windowsxp 自带) 4.8 其它需求 无 5 附录 无