|
|
|
性能测试包括可靠性测试、功能／特性测试、吞吐量测试、衰减测试、容量规划测试、响应时间测试、可接受性测试和网络瓶颈测试等。
|
|
|
|
|
|
可靠性测试是使被测网络在较长时间内（通常是24～72小时）经受较大负载，通过监视网络中发生的错误和出现的故障，验证在高强度环境中网络系统的存活能力，也就是它的可靠性。可靠性测试可作为接受性测试的一部分，在产品评估测试中可作为比较测试或作为产品升级进行的衰减测试的一部分。采用的负载模式很重要，越贴近真实负载模式越好。可靠性测试中使用网络分析仪监控网络运行，捕获网络错误。
|
|
|
|
通常在较长时间段内和持续负载下，不同网络具有不同级别的存活度。如果测试时间足够长、负载足够大，所有可靠性测试最终都会失败。
|
|
|
|
|
|
◆计划：作为产品评估测试的一部分，比较不同产品或建立要求规范。
|
|
|
|
|
|
◆组建：作为可接受性测试的一部分，在网络运行前进行，核实系统是否达到要求。
|
|
|
|
|
|
特性测试核实的是单个命令和应用程序功能，通常用较小的负载完成，关注的是用户界面、应用程序的操作以及用户与计算机之间的互操作。特性测试通常由开发人员在他们的工作台上完成，或是在一个小型网络环境下由测试人员完成。
|
|
|
|
功能测试是面向网络的，核实的是应用程序的多用户特征和在重负载下后台功能是否能正确地执行，关注的是当多个用户正在运行应用程序时，网络和文件系统或数据库服务器之间的交互。功能测试要求网络的配置和负载非常接近于运行环境下的模式。该测试可以在运行网络或独立网络实验室里完成。它只应用于网络生命周期中的以下3个阶段。
|
|
|
|
◆开发：用于核实在期望的运行模式下，在多用户环境里，应用程序的运行性能是否达到要求。
|
|
|
|
◆组建：在应用程序安装前完成，可独立进行，也可作为接受性测试的一部分，用于核实在期望的运行模式下，应用程序的运行性能是否达到要求。
|
|
|
|
◆运行：该阶段测试是在应用程序运行后进行的，如果在运行系统中遇到了问题，该阶段测试用于核实应用程序是否如最初应用时那样工作。
|
|
|
|
|
|
吞吐量测试和应用程序的响应时间测试相似，但检测的是每秒钟传输数据的字节数和数据报文数，而不是响应时间。它用于检测服务器、磁盘子系统、适配卡／驱动连接、网桥、路由器、集线器、交换器和通信连接。吞吐量测试用于测量网络性能、找到网络瓶颈，以及比较不同产品的性能。
|
|
|
|
吞吐量测试不使用程序脚本，它借助某些软件对网络服务器执行文件输入／输出操作来产生流量，或通过某些软件在网络上发送专门的数据报文或帧。该测试应用于网络生命周期的以下几个阶段。
|
|
|
|
◆计划：用于比较网络产品，为模拟网络节点提供运行特征和要求规范。
|
|
|
|
◆开发：用于核实网络组件以及整个网络是否达到规范要求的水平。
|
|
|
|
◆组建：可独立进行或作为可接受性测试的一部分，在网络组件或整个网络正式运行之前核实它们是否满足规范的要求。
|
|
|
|
|
|
衰减测试是将硬件或软件的新版本与当前版本在性能、可靠性和功能等方面进行比较，同时验证产品升级对网络的性能不会有不良影响。衰减测试混杂了很多为完成其他测试任务要进行的测试。衰减测试的关键是要保证被测组件应是运行网络中最关键或最脆弱的组件。
|
|
|
|
衰减测试不强调升级版的新特性。新特性测试在衰减测试之前作为功能／特征测试的一部分就已完成。尽管新产品应该解决了当前版本中的错误，但它们也经常存在一些以前没有出现过的错误，如果这些错误发生在产品的关键部分，将会引起严重问题。衰减测试不需要测试产品的所有特性，但网络用户正常运行所依靠的关键功能必须在测试之列。
|
|
|
|
|
|
◆开发：用于核实产品升级版是否能满足性能、互操作性和可靠性的要求。
|
|
|
|
◆升级：在采用升级版本之前用该项测试来比较升级版和当前版，看升级版是否和当前版一样满足性能、互操作性和可靠性的要求。
|
|
|
|
|
|
容量规划测试用于检测当前网络中是否存在多余的容量空间。当网络承受的总负载超过网络总容量时，网络的性能或吞吐量就有可能下降，所以在网络负载接近这一临界点（网络的最大容量）前，就要根据负载增长的幅度扩充网络资源。
|
|
|
|
进行该项测试要逐渐增加网络负载，直到网络的运行性能、可接受的水平或吞吐量不断下降，达不到设计所要求的水平为止。网络运行负载和网络最大吞吐量之间的差额就是现有系统的冗余量。
|
|
|
|
|
|
◆计划：用于估计实施该系统所需要的资源，也可用于成本分析和制定预算。
|
|
|
|
◆开发：检测系统要求的资源是否满足特定的响应时间和吞吐量的要求。
|
|
|
|
◆升级：当系统响应时间或吞吐量下降时，重新选取网络组件。
|
|
|
|
|
|
响应时间测试用于检测系统完成一系列任务所需的时间，本项测试是用户最关心的。对于表示层，如微软的Windows，该测试是指在不同桌面之间切换或装载新负载所需的时间。在不同负载即不同实际或模拟用户的数目下运行这一实验，可对每个被测试的应用程序生成一个负载—响应时间曲线。
|
|
|
|
在应用程序测试中，可执行一系列典型网络动作的命令，如打开、读、写、查找和关闭文件，这些命令提供了最好的负载模拟。例如，对每个进行测试的工作站，检测它在几秒内能完成这些命令。
|
|
|
|
|
|
◆计划：使用模拟应用程序进行，检测规范要求的各项网络服务。
|
|
|
|
|
|
◆组建：在接受和组建之前，核实规范要求下的网络服务是否已经被实现。
|
|
|
|
◆运行：检测网络服务的基准和变化，这可能是针对系统质量的最好测试。
|
|
|
|
响应时间测试应该包括对系统可靠性的检测。常见的可靠性问题，如在路由器或服务器中大量丢失数据报文或由于网络组件故障引发大量坏数据报文，将严重影响网络的响应时间，因此在整个测试期间都应用网络分析仪监视系统错误。
|
|
|
|
|
|
可接受性测试是在系统正式实施前的"试运行"。它是一个非常有效的方法，可确保新系统能提供良好而稳定的性能。和衰减测试一样，可接受性测试中也包含多项测试，如响应时间测试、稳定性测试和功能／特性测试。
|
|
|
|
可接受性测试应用于许多领域，但在安装或升级网络前应进行的网络可接受性测试则经常被忽略，而事实上，可接受性测试能为网络购买者在经济和技术上提供有力的保证和参考。
|
|
|
|
可接受性测试可以仅在新增加的部件上完成，将已存在的负载加上新增程序或新增组件可能产生的负载作为测试使用的负载。
|
|
|
|
|
|
◆开发：在开发阶段前定期执行，用来核实要求的标准是否可行。
|
|
|
|
◆组建：在网络投入运行之前应用，用来核实系统是否满足所有要求。
|
|
|
|
|
|
通过网络瓶颈测试可以找到导致系统性能下降的瓶颈。测试中需要测试和计算系统的最大吞吐量，然后再在单个网络组件上进行该项测试，明确各组件的最大吞吐量。通过计算单个组件的最大吞吐量和系统最大吞吐量之间的差额，就能发现系统瓶颈的位置以及哪些组件有多余的容量。
|
|
|
|
系统瓶颈在不同的测试案例中出现的位置可能有所变化。例如，一个客户业务应用程序测试可能表明服务器是系统的瓶颈，而对一个电子邮件系统的测试则可能表明广域网连接才是网络的限制因素。如果可以在测试的环境中重现引起问题的负载，那么这样的测试结果对解决问题将有很大帮助。
|
|
|
|
|
|
◆组建：可以作为容量计划的一部分，用于帮助相关人员明确影响网络性能和响应时间的瓶颈位置。
|
|
|
|
◆运行：作为故障检测的一部分，帮助相关人员找出影响网络性能或引起系统问题的网络瓶颈。
|
|
|
