一个项目的性能测试实例
一个项目的性能测试实例
　　从2004年8月底至2004年10月中，本人在北方L省的一个全省集中的交换网管项目中负责该项目的性能测试工作。该性能测试历时1个半月多，投入了3.6人月，占总的项目测试投入的17％。性能测试共进行了三轮，测试实现了预期的目标，测试过程中共发现影响性能的2级缺陷5个，三级缺陷8个，其中有一个缺陷导致了架构的部分变更。缺陷修改完成后，整个系统的采集效率提升了60％，告警入库效率提升了20％，应用的修改也使得系统具有了更强的稳定性。从测试的结果来说，本次测试取得了比较满意的效果，在测试过程中，本人也有一些心得和体会，因此，通过这篇文章记录本次性能测试的过程，希望能和各位同仁进行性能测试的更加深入的交流。　　　1. 背景
　　本人参与的项目是一个全省大集中的交换网管项目，该项目使用的所有服务器（数据库服务器、应用服务器、采集服务器、认证服务器、WEB服务器）均部署在省中心机房，所有的数据采集和处理都在省中心完成，地市通过反拉终端通过WEB和Socket方式访问省中心的服务器。考虑全省的需要，在整个系统上线后，总的用户数应该在1500左右。　　　图1是本项目的结构示意图。　
　　在我们这个系统之前，L省的交换网管采用的是本地网管理方式，也就是每个地市都有自己的本地网网管系统，对省中心提供的数据仅仅是定期的报表。采用分散的本地网网管形式，每个本地网系统仅需要支持少量本地用户的访问，因此在性能方面没有过多的考虑，也没有进行过性能方面的测试。　　　我们为L省提供的新的解决方案是全省大集中的统一交换网管，一方面所有的用户都通过统一的平台对系统数据进行访问，另一方面，系统通过已有的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
用例对应功能点
用例优先级
用例简要描述
用例依赖关系
用例依赖用例
用例创建人
用例执行时间
用例执行先决条件
1． 使用一台采集服务器作测试用；2． 已通过模拟程序产生每秒300条告警的告警数据；3． 所有告警产生和呈现时间记录在本地日志文件中。
1． 由网元模拟程序产生特定告警（T1）；2． 告警被上层应用呈现的时间由上层应用记录（T2）；3． 计算T2－T1，结果小于5秒；
〔修改人〕
（修改时间）
（修改内容）
用户启动主界面，进入告警监控界面
产生一个特定告警（便于识别），发送至系统
XXXX（特定告警的详细内容）
特定告警的发送时间记录在文件XXXX中
在告警监控界面上查看特定告警
观察到特定告警出现的时间（记录在文件XXXX中）和告警实际发生时间相差不超过5秒
测试结果描述：
测试时间：
测试结论：
　　从本测试用例中可以看到，测试用例已经详细定义了用例执行的先决条件、测试输入和输出，以很直观的方式给出了测试用例的各个要素。　　　设计测试用例的过程中，同时需要关注的是测试数据的产生和维护。　　　在上一个测试用例的例子中，“特定告警的详细内容”就是一个被选择的测试数据，如何选择具体的测试数据需要根据测试的具体需求而定，没有统一的法则。但在设计测试用例时，一定要明确每个用例的数据需求并将这种需求综合起来，并形成对测试环境的测试数据的维护策略，以便在测试用例执行时能顺利进行。　　　一般而言，我们可以考虑初始测试数据的需求、考虑测试用例之间的依赖关系、记录每个用例对数据的要求，然后最终确定需要哪些测试数据和如何维护测试数据。　　　4. 测试环境与测试工具　　　制定了合理的测试计划、设计了满足需要的测试用例之后，我们就可以开始着手准备测试环境和考虑如何在测试中运用测试工具了。　　　4.1. 测试环境　　　测试环境的部署和维护是一件需要详细策划的事情，部署了合理的测试环境是测试达到目标效果的前提条件。一般来说，在考虑部署和维护测试环境时，需要考虑以下内容：　　　测试网络环境　　　性能测试一般都是在一个网络中进行，可能是一个单独的局域网，也可能是和生产环境相同的网络，不管实际的情况如何，我们都必须评估网络状况是否会对我们的测试产生影响，也就是说，要保证网络环境能够较好地模拟实际网络环境（包括网络状况、负载等）。当然，在我们的本次测试中，由于网络状况对我们的测试结果没有什么影响，我们的测试是在一个接近生产环境的100M局域网中进行。　
　　初始数据的准备　　　在执行测试之前，我们需要准备足够支撑测试进行的初始数据，对本测试来说，初始数据包括静态数据、程序运行时必须的配置数据、配置文件、用户帐号信息等，建议将这部分数据按照不同的数据来源分别列出形成CheckList，这样可以避免在测试过程中出现数据准备不充分的情况。　　　本测试中我使用的CheckList示例如表1所示：　　　表1 本测试中使用的测试环境CheckList.　
测试环境项目
预计完成时间
是否已部署
数据库静态数据
数据库中的网元配置数据
WEB用户信息
Unix用户帐号信息
模拟发送的话务数据
网元话务报告发送模拟程序
　　除了测试环境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、 测试结论：测试结论这部分需要详细说明本测试的结论，包括测试用例执行情况统计、测试是否通过、测试中发现问题的处理方式和方法；　　　除此之外，还可以在测试报告中包括建议与计划，用来说明该测试的后续工作安排和计划；将测试用例的执行情况和每轮测试执行的详细记录作为附件附加到测试报告中。　
&&&主编推荐
H3C认证Java认证Oracle认证
基础英语软考英语项目管理英语职场英语
.NETPowerBuilderWeb开发游戏开发Perl
二级模拟试题一级模拟试题一级考试经验四级考试资料
软件测试软件外包系统分析与建模敏捷开发
法律法规历年试题软考英语网络管理员系统架构设计师信息系统监理师
高级通信工程师考试大纲设备环境综合能力
路由技术网络存储无线网络网络设备
CPMP考试prince2认证项目范围管理项目配置管理项目管理案例项目经理项目干系人管理
职称考试题目
招生信息考研政治
网络安全安全设置工具使用手机安全
生物识别传感器物联网传输层物联网前沿技术物联网案例分析
Java核心技术J2ME教程
Linux系统管理Linux编程Linux安全AIX教程
Windows系统管理Windows教程Windows网络管理Windows故障
数据库开发Sybase数据库Informix数据库
&&&&&&&&&&&&&&&
希赛网 版权所有 & &&发表给力评论！看新闻，说两句。
ctrl+enter快捷提交
发表给力评论！看新闻，说两句。
ctrl+enter快捷提交
发表给力评论！看新闻，说两句。
ctrl+enter快捷提交
48小时点击排行
$ViewControl.热点推荐_Vs2$[转载]理解性能/性能测试/如何获取“有效的”性能需求--
2．理解性能
如何评价性能的优劣: 用户视角 vs 系统视角
对于最终用户(End-User)来说，评价系统的性能好坏只有一个字——“快”。最终用户并不需要关心系统当前的状态——即使系统这时正在处理着成千上万的请求，对于用户来说，由他所发出的这个请求是他唯一需要关心的，系统对用户请求的响应速度决定了用户对系统性能的评价。&
而对于系统的运营商和开发商来说，期望的是能够让尽可能多的用户在任意时刻都拥有最好的体验，这就要确保系统能够在同一时间内处理更多的用户请求。系统的负载（并发用户数）与吞吐量（每秒事务数）、响应时间以及资源利用率（包括软硬件资源）之间存在着一个“此消彼长”的关系。因此，从系统的运营商和开发商的角度来看，所谓的“性能”是一个整体的概念，是系统的负载与吞吐量、可接受的响应时间以及资源利用率之间的平衡。
换句话说，“好的性能”意味着更大的最佳并发用户数（The Optimum
Number of Concurrent Users）和 最大并发用户数（The Maximum Number
of Concurrent Users）。
另外，从系统的视角来看，所需要关注的还包括三个与“性能”有关的属性：可靠性（Reliability），可伸缩性（Scalability）和
可恢复性（Recoverability。
一个请求的响应时间是由几部分时间组成的，包括:
C1：用户请求发出前在客户端需要完成的预处理所需要的时间；
C2：客户端收到服务器返回的响应后，对数据进行处理并呈现所需要的时间；
A1：Web/App Server 对请求进行处理所需要的时间；
A2：DB Server 对请求进行处理所需的时间；
A3：Web/App Server 对 DB Server
返回的结果进行处理所需的时间；
N1：请求由客户端发出并达到Web/App Server
所需要的时间；
N2：如果需要进行数据库相关的操作，由Web/App Server
将请求发送至DB Server 所需要的时间；
N3：DB Server 完成处理并将结果返回Web/App Server
所需的时间；
N4：Web/App Server
完成处理并将结果返回给客户端所需的时间；
从用户的角度来看，响应时间＝(C1+C2)+(A1+A2+A3)+(N1+N2+N3+N4)；但是从系统的角度来看，响应时间只包括(A1+A2+A3)+(N1+N2+N3+N4)。
在理解了响应时间的组成之后，可以帮助我们通过对响应时间的分析来更好的识别和定位系统的性能瓶颈。
吞吐量 vs. 吞吐量
在不同的测试工具中，对于吞吐量(Throughput)会有不同的解释。例如，在LoadRunner中，这个指标是以字节数为单位来衡量网络吞吐量的，而在中则是以事务数/秒为单位来衡量系统的响应能力的。不过在大多数英文的性能测试方面的书籍或资料中，吞吐量的定义使用的是后者。
并发用户数 ≠ 每秒请求数
这是两个容易让初学者混淆的概念。
简单说，当你在性能测试工具或者脚本中设置了100并发用户数后，并不能期望着一定会有每秒100个请求发给服务器。事实上，对于一个虚拟用户来说，每秒发出多少请求只跟服务器返回响应的速度有关。如果虚拟用户在0.5秒内就收到了响应，那么它会立即发出第二个请求；而如果要一直等待3秒才能得到响应，它将会一直等到收到响应后才发出第二个请求。也就是说，并发用户数的设置只是保证服务器在任一时刻都有100个请求需要处理，而并不一定是保证每秒中发送100个请求给服务器。
所以，只有当响应时间恰好是1秒时，并发用户数才会等于每秒请求数；否则，每秒请求数可能大于并发用户数或小于并发用户数。
3．性能测试
提到性能测试，相信大家可以在网上找到很多种不同的定义、解释以及分类方法。不过归根结底，在大多数情况下，我们所要做的性能测试的目的是“观察系统在一个给定的环境和场景中的性能表现是否与预期目标一致，评判系统是否存在性能缺陷，并根据测试结果识别性能瓶颈，改善系统性能”。
我们不可能将一辆设计载重为0.75吨的皮卡改装成载重15吨的大型卡车，如果你面对的正是这样的问题，那么恐怕你只能重做一辆，而且客户不会为你之前那辆付钱。对于一个已经完成的应用系统来说也是如此。
如果我们在系统结构确定之前就能够了解到系统的将要面对的压力，用户的使用习惯和使用频度，我们就可以更早也更有效的提前解决或预防可能发生的性能缺陷，也将会极大的减少后期返工和反复调优所带来的工作量。如果我们预期到系统的容量将会不断的增长，我们还可以给出相应的解决方案来低成本的解决这类问题，就像上面那辆皮卡，也许你可以有办法把20辆皮卡捆在一起，或者把15吨的东西分由20辆来运。
分析设计阶段
系统性能的优化并不是要等待整个系统全部集成后才能开始的，早在分析设计阶段，我们就可以开始考虑系统的技术架构和数据库部分的优化。
数据库通常位于整个系统的最底层，如果直到系统上线前才发现因为数据库设计不合理而导致性能极差，通常使用任何一种方法来优化都已经于事无补了。要避免这类问题，最常见的做法是在数据库结构确定后，通过工具或脚本向数据库中注入大量的数据，并模拟各种业务的数据库操作。根据对数据库性能的观察和分析，对数据库表结构和索引进行调整以优化数据库性能。
在系统的技术架构方面，要明白先进的技术并不是解决问题的唯一方法，过于强调技术的作用反而会将你带入歧途。例如：某些业务虽然经常面临着巨大的压力，并且业务本身的复杂性决定了通过算法的优化来提高系统的性能收效甚微。但是我们知道用户对于该业务的实时性要求并不高，并且返回结果对于不同用户来说是相同的。那么我们完全可以考虑将每次请求都动态生成返回结果的方式改为每次用户请求都返回一个定期更新的静态页面。
另外，所谓“先进技术”通常都会在带来某一方面改进的同时带来另一方面的问题，未经试验就盲目的在系统中加入各种流行元素未必是最好的选择。例如ORM可以提供一些方便，但是它生成的SQL是未经优化的，有时甚至比人工编写的SQL效率更低。
最后，要知道不同厂家的设备性能是不同的，而且不同的硬件设备搭载不同的操作系统、数据库、中间件以及应用服务器，表现出来的性能也是不同的。如果有足够的资源，应当考虑提前进行软硬件平台的对比选型；如果没有足够的资源，可以考虑通过一些专业的组织或网站来获取或购买相关的评估报告。
一片树叶在哪里最难被发现？——当这片树叶落在一堆树叶里面的时候。
如果你只是在系统测试完成后才开始性能测试，那么即使发现系统存在性能缺陷，并且已经有了几个可供怀疑的对象，但是当一段因为使用了不当的算法而导致执行效率很低的代码藏身于一个庞大的系统中时，找出它是非常困难的。避免这种情况出现的方法是尽早开始核心业务代码的性能测试，重点集中在对算法和实现方法的优化上。
另外，及早开始的测试也可以帮你更容易找到内存泄漏的问题。
产品终于交到我们手上了，搭建测试环境，设计测试场景，执行测试，找到系统的最佳并发用户数和最大并发用户数，将系统进行分类，评判系统的性能表现是否满足需求中定义的目标——如果有需求的话
如果发现系统的性能表现与预期目标相去甚远，则需要根据执行测试过程中收集到的数据来分析和识别性能瓶颈，优化系统性能。
在这个阶段还有很多值得我们深入思考和讨论的东西，在本系列后续的文章中，我们将会更多的关注这一部分的内容。
维护阶段通常遇到的问题是需要在实验室中模拟客户环境，重现在客户那里发现的缺陷并修复缺陷。相比功能缺陷，性能缺陷与某一具体环境和场景的关联更加密切，所以在测试前需要检查生产环境中各服务器的资源利用率、系统访问日志、应用服务器的日志、数据库的日志。如果客户使用了专门的系统来监测各个服务器的软硬件资源使用情况的话，检查该系统是否记录下了软硬件资源的异常或者警告。
与性能测试相关的其他测试
可靠性测试（Reliability
Testing）&&&
对于一个运营商级的系统来说，能够保证提供7×24的连续稳定的服务是非常重要的。当然，你可以通过一些“高可用性（High
Availability）”技术方案来增强系统的可靠性，但是对于系统本身的可靠性测试是不能被忽略的。
常用的测试方法是使用一定的负载长时间向服务器加压，并观察随着加压时间的延长，响应时间、吞吐量以及资源利用率的变化。要注意的是，所使用的负载应当是系统的最佳并并发用户数，而不是最大并发用户数。
可伸缩性测试（Scalability Testing）
对于一个系统来说，在一个给定的环境下，它的最佳并发用户数和最大并发用户数是客观存在的，但是系统所面临的压力却有可能随上线时间的延长而增大。例如，一个在线购物站点，注册用户数量不断增多，访问站点查询商品信息和购买商品的人也不断的增多，我们应该用一种什么样的方案，在不影响系统继续为用户提供服务的前提下来实现系统的扩容？
一种常用的方案是使用负载均衡（Load
Balance）和集群（Cluster）技术。但是在我们为客户提供这种方案之前，需要先自己进行测试，保证该技术的有效性——我们是否真的可以通过简单的增加服务器数据和修改某些参数配置，就能够使得系统的容量得到线性的增长？
可恢复性测试（Recoverability Testing）
&虽然我们已经可以准确的估算出系统上线后将要面对的压力，并且可以保证系统的最佳并发用户数和最大并发用户数是足以应对这些压力的，但是这个世界上总是有些事情上我们所无法预料到的——例如9.11事件发生后，AOL的网站访问量在短时间内增长到了平时的数十倍。
我们无法保证系统可以在任何情况下都能为用户正确无误的提供服务，但是我们需要确保当意外过去后，系统可以恢复到正常的状态，并继续后来的用户提供服务——就像从未发生过任何事情一样。
如果要实现“可恢复性测试”，我们可以借助于测试工具或脚本来逐渐的增大并发用户数，直至并发用户数已经超过了系统所能承受的最大并发用户数，并导致软硬件资源利用率饱和，响应时间无限延长，大量的请求因为超过响应时间要求或无法获得响应而失败；之后，我们逐渐的减少并发用户数，并观察资源利用率、响应时间、吞吐量以及交易成功率的变化是否与预期目标一致。&
当然，这一切的前提是在系统负载达到峰值前，Server一直在顽强的挣扎着而没有down掉。
性能测试，并非网络应用专属
软件的性能和性能测试都是伴随着网络应用的兴起而逐渐被重视起来的，但是软件性能和性能测试却并非网络应用的专属名词，因为单机版的应用同样需要考虑性能问题。下面举几个简单的例子来方便大家的理解：
1.当使用Word来编辑一个500多页，并包含了丰富图表、图片和各种格式、样式信息的文档时，是否每次对大段的文字或表格的修改、删除或重新排版，都要等待系统花几秒钟的时间进行处理？
2.当在Excel中使用嵌套的统计和数学函数对几万行记录进行统计分析时，是否每次都要两三分钟才能看到结果？
3.杀毒软件是否每次都要花费两个小时才能完成一次对所有的分区的扫描？
4.是否每次在手机的通讯簿中根据姓名搜索某个人的联系方式都要三四秒钟才有响应？
如果大家有兴趣，也可以通过Google搜索到更多的有关单机应用性能测试的资料。
4．如何获取“有效的”性能需求
一个实际的例子
为了便于大家的理解，我们先来看一个性能需求的例子，让大家有一个感性的认识，本文后面的讨论也会再次提到这个例子。
这是一个证券行业系统中某个业务的“实际需求”——实际上是我根据通过网络搜集到的数据杜撰出来的，不过看起来像是真实的
&&&&&&&&
系统总容量达到日委托6000万笔，成交9000万笔
&&&&&&&&
系统处理速度每秒7300笔，峰值处理能力达到每秒10000笔
&&&&&&&&
实际股东帐号数3000万
这个例子中已经包括几个明确的需求：
&&&&&&&&
最佳并发用户数需求：每秒7300笔
&&&&&&&&
最大并发用户数需求：峰值处理能力达到每秒10000笔
&&&&&&&&
基础数据容量：实际股东帐号数3000万
&&&&&&&&
业务数据容量：日委托6000万笔，成交9000万笔——可以根据这个推算出每周、每月、每年系统容量的增长模型
什么是“有效的”性能需求？
要想获得有效的性能需求，就要先了解什么样的需求是“有效的”。有效的性能需求应该符合以下三个条件。
1.明确的数字，而不是模糊的语句。
结合上面的例子来看，相信这个应该不难理解。但是有的时候有了数字未必就不模糊。例如常见的一种需求是“系统需要支持5000用户”，或者“最大在线用户数为8000”。这些有数字的需求仍然不够明确，因为还需要考虑区分系统中不同业务模块的负载，以及区分在线用户和并发用户的区别。
2.有凭有据，合理，有实际意义。
通常来说，性能需求要么由客户提出，要么由开发方提出。对于第一种情况，要保证需求是合理的，有现实意义的，不能由着客户使劲往高处说，要让客户明白性能是有成本的。对于第二种情况，性能需求不能简单的来源于项目组成员、PM或者测试工程师的估计或者猜测，要保证性能需求的提出是有根据的，所使用的数据和计算公式是有出处的——本文后面的部分会介绍获得可用的数据和计算公式的方法。
3.相关人员达成一致。
这一点非常关键。如果相关人不能对性能需求达成一致，可能测了也白测——特别是在客户没有提出明确的性能需求而由开发方提出时。这里要注意“相关人员”的识别，通常项目型的项目的需要与客户方的项目经理或负责人进行确认，产品型的项目需要与直属领导或者市场部进行确认。如果实在不知道该找谁确认，那就把这个责任交给你的直属领导；如果你就是领导了，那这领导也白当了
如何获得有效的性能需求
上面提到了“有效的”性能需求的一个例子和三个条件，下面来我们将看到有哪些途径可以帮助我们获得相关的数据——这些方法我在实际的工作中都用过，并且已经被证实是可行的。这几种方法由易到难排列如下：
1.客户方提出
这是最理想的一种方式，通常电信、金融、保险、证券以及一些其他运营商级系统的客户——特别是国外的客户都会提出比较明确的性能需求。
2.根据历史数据来分析
根据客户以往的业务情况来分析客户的业务量以及每年、每月、每周、每天的峰值业务量。如果客户有旧的系统，可以根据已有系统的访问日志，数据库记录，业务报表来分析。要特别注意的是，不同行业、不同应用、不同的业务是有各自的特点的。例如，购物网站在平时的负载主要集中在晚上，但是节假日时访问量和交易量会是平时的数倍；而地铁的售票系统面临的高峰除了周末，还有周一到周五的一早一晚上下班时间。
3.参考历史项目的数据
如果该产品已有其他客户使用，并且规模类似的，可以参考其他客户的需求。例如在线购物网站，或者超市管理系统，各行业的进销存系统。
4.参考其他同行类似项目的数据
如果本企业没有做过类似的项目，那么可以参考其他同行企业的公布出来的数据——通常在企业公布的新闻或者成功解决方案中会提到，包括系统容量，系统所能承受的负载以及系统响应能力等。
5.参考其他类似行业应用的数据
如果无法找打其他同行的数据，也可以参考类似的应用的需求。例如做IPTV或者DVB计费系统的测试，可以参考电信计费系统的需求——虽然不能完全照搬数据，但是可以通过其他行业成熟的需求来了解需要测试的项目有哪些，应该考虑到的情况有哪些种。
6.参考新闻或其他资料中的数据
最后的一招，特别是对于一些当前比较引人关注的行业，涉及到所谓的“政绩”的行业，通常可以通过各种新闻媒体找到一些可供参考的数据，但是需要耐心的寻找。例如我们在IPTV和DVB系统的测试中，可以根据新闻中公布的各省、各市，以及国外各大运营商的用户发展情况和用户使用习惯来估算系统容量和系统各个模块的并发量。
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。}