原文作者不知是谁，感觉写的不错，供以后参考：
通常，客户/服务器软件测试发生在三个不同的层次：
1.个体的客户端应用以“分离的”模式被测试——不考虑服务器和底层网络的运行；
2.客户端软件和关联的服务器端应用被一起测试，但网络运行不被明显的考虑；
3.完整的C/S体系结构，包括网络运行和性能，被测试。
下面的测试方法是C/S应用中经常用到的：
应用功能测试客户端应用被独立地执行，以揭示在其运行中的错误。
服务器测试——测试服务器的协调和数据管理功能，也考虑服务器性能（整体反映时间和数据吞吐量）。
数据库测试——测试服务器存储的数据的精确性和完整性，检查客户端应用提交的事务，以保证数据被正确地存储、更新和检索。
事务测试——创建一系列的测试以保证每类事务被按照需求处理。测试着重于处理的正确性，也关注性能问题。
网络通信测试——这些测试验证网络节点间的通信正常地发生，并且消息传递、事务和相关的网络交通无错的发生。
C/S结构与B/S结构的特点分析
为了区别于传统的C/S模式，才特意将其称为B/S模式。认识到这些结构的特征，对于系统的选型而言是很关键的。
1、系统的性能
在系统的性能方面，B/S占有优势的是其异地浏览和信息采集的灵活性。任何时间、任何地点、任何系统，只要可以使用浏览器上网，就可以使用B/S系统的终端。
不过，采用B/S结构，客户端只能完成浏览、查询、数据输入等简单功能，绝大部分工作由服务器承担，这使得服务器的负担很重。采用C/S结构时，客户端和服务器端都能够处理任务，这虽然对客户机的要求较高，但因此可以减轻服务器的压力。而且，由于客户端使用浏览器，使得网上发布的信息必须是以HTML格式为主，其它格式文件多半是以附件的形式存放。而HTML格式文件（也就是Web页面）不便于编辑修改，给文件管理带来了许多不便。
2、系统的开发
C/S结构是建立在中间件产品基础之上的，要求应用开发者自己去处理事务管理、消息队列、数据的复制和同步、通信安全等系统级的问题。这对应用开发者提出了较高的要求，而且迫使应用开发者投入很多精力来解决应用程序以外的问题。这使得应用程序的维护、移植和互操作变得复杂。如果客户端是在不同的操作系统上，C/S结构的软件需要开发不同版本的客户端软件。但是，与B/S结构相比，C/S技术发展历史更为“悠久”。从技术成熟度及软件设计、开发人员的掌握水平来看，C/S技术应是更成熟、更可靠的。
3、系统的升级维护
C/S系统的各部分模块中有一部分改变，就要关联到其它模块的变动，使系统升级成本比较大。B/S与C/S处理模式相比，则大大简化了客户端，只要客户端机器能上网就可以。对于B/S而言，开发、维护等几乎所有工作也都集中在服务器端，当企业对网络应用进行升级时，只需更新服务器端的软件就可以，这减轻了异地用户系统维护与升级的成本。如果客户端的软件系统升级比较频繁，那么B/S架构的产品优势明显――所有的升级操作只需要针对服务器进行，这对那些点多面广的应用是很有价值的，例如一些招聘网站就需要采用B/S模式，客户端分散，且应用简单，只需要进行简单的浏览和少量信息的录入。
4、C/S模式的优点和缺点
★ C/S模式的优点
●由于客户端实现与服务器的直接相连，没有中间环节，因此响应速度快。
●操作界面漂亮、形式多样，可以充分满足客户自身的个性化要求。
● C/S结构的管理信息系统具有较强的事务处理能力，能实现复杂的业务流程。
★ C/S模式的缺点
●需要专门的客户端安装程序，分布功能弱，针对点多面广且不具备网络条件的用户群体，不能够实现快速部署安装和配置。
●兼容性差，对于不同的开发工具，具有较大的局限性。若采用不同工具，需要重新改写程序。
●开发成本较高，需要具有一定专业水准的技术人员才能完成。
5、B/S模式的优点和缺点
★ B/S模式的优点
●具有分布性特点，可以随时随地进行查询、浏览等业务处理。
●业务扩展简单方便，通过增加网页即可增加服务器功能。
●维护简单方便，只需要改变网页，即可实现所有用户的同步更新。
●开发简单，共享性强。
★ B/S模式的缺点
●个性化特点明显降低，无法实现具有个性化的功能要求。
●操作是以鼠标为最基本的操作方式，无法满足快速操作的要求。
●页面动态刷新，响应速度明显降低。
●无法实现分页显示，给数据库访问造成较大的压力。
●功能弱化，难以实现传统模式下的特殊功能要求。
近年来，随着软硬件技术发展和人们意识的提高，Web应用得到广泛的普及，一方面在互联网浪潮的推动下，基于互联网的信息共享和电子商务不断发展，像新浪、搜狐、8848等大型网站不断涌现出来，另一方面随着Java、CGI等网络技术的成熟，基于B/S结构的大型软件逐渐显示出巨大的优势。同时，也就产生了一个焦点问题，什么样的服务器能够满足不同用户的需求，怎么能够保证Web服务器能够长期稳定地运行，为了满足这样的需求Web测试也就同样变得十分重要。
当前Web测试主要通过Web测试工具加上良好的测试案例完成的，我们认为主要有以下两种测试类型：基准测试、非基准测试
基准测试：主要指测试工具已经提供了标准的测试案例库，包括静态测试案例（HTM、JPG）、动态测试案例（CGI）和SSL测试案例等。这类测试工具分为测试案例库、控制台程序、客户端程序三个部分。它的原理是，Web服务器开启特定的Web服务程序，并且运行上述测试案例，由控制台程序控制各个客户端按照一定的脚本访问顺序遍历Web服务器的各个测试案例，每个请求完成后，各个客户端向控制台报告访问的结构，当一个测试集完成后由控制台将所有的信息综合统计，测试过程中控制台还需要采用SNMP协议对服务器进行实时监控，综合两个方面的因素可以反映出Web服务器在不同压力情况下的综合性能。
在测试过程中，主要影响测试结果的因素有网络环境、客户端性能。目前无论IA架构服务器还是SUN、HP、IBM的UNIX服务器性能都越来越优越，有可能出现在100MB网络下不能够提供足够的网络压力，有可能网络首先出现瓶颈，这样就需要扩展到1000MB网络环境或使用多个网段对服务器提供足够的压力，而稳定的客户端对于测试来说也是十分重要的，因为客户端如果出现性能下降，就会造成系统崩溃或者不能提供稳定的测试压力从而导致测试结果出现偏差；一台客户端到底能够稳定运行多少数量的连接是根据不同的硬件配置和操作系统决定的，因此对客户端的硬件资源进行监控是保证客户端可以稳定运行的必要手段。
由于这类测试工具使用的是工具开发商提供的测试案例集，虽然也具有一定的权威性，但是目前再完美的测试案例集也不能涵盖所有的Web应用情况，所以也不能够完全体现出Web服务器完整的性能，因此该类测试工具更加适合IT媒体对Web类服务器软硬件的横向对比测试，在测试对象和环境大体统一的情况下，可以比较出各个测试对象的性能差异。而对于有实际应用背景的Web服务器进行测试，使用这样的测试工具就不适合了，我们在以后的测试漫谈中会继续介绍。
1. CS/CSS系统架构的基本概念
1.1系统架构定义
虽然B/S结构、J2EE架构愈来愈成为流行模式，但基于传统的C /S结构的应用程序还广泛地应用于各种行业。尤其是金融行业中的商业银行柜面－核心帐务系统等。一方面由于传统商业银行一般都有大量的字符终端等需要复用的设备，一方面也是因为他们存在大量密集的对实时性要求很高的高柜业务，使用传统的基于C/S结构或者C/S/S结构的应用效率更有保证。
C/S结构即CLIENT/SERVER结构。传统的C/S结构一般分为两层：客户端和服务器端。该结构的基本工作原理是，客户程序向数据服务器发送SQL请求，服务器返回数据和结果。客户端负责实现用户接口功能，同时封装了部分应用逻辑。服务器端的数据库服务器主要提供数据存储功能，也通过触发器和存储过程提供部分应用逻辑。
C/S/S结构即客户/应用服务器/数据库服务器三层结构，中间增加了应用服务器，通常实现应用逻辑，是连接客户与数据库服务器的桥梁。它响应用户发来的请求执行某种业务任务，并与数据库服务器打交道，技术实现上通常选用中间件产品，如BEA公司的TUXEDO和IBM公司的CICS等。（事实上J2EE架构的应用也属于这种三层或多层结构，这里不包括。）
三层或多层C/S结构与两层C/S结构相比，它的优势主要表现在：安全性加强、效率提高、易于维护、可伸缩性、可共享性、开放性好等。
1.2系统架构示意图
1.3 CS/CSS系统架构中性能测试的特点
1.3.1 CS/CSS系统架构的性能影响因素
由于CS/CSS系统的以下特性，测试工程师对一个CS/CSS系统实施性能测试具有很大的难度：
l整个系统的各个部分使用多种操作系统，性能上有差别；
l整个系统架构的各个环节上使用多种数据库，同样在性能上有差别；
l应用是多个，分属多个种类，分布在不同设备上，包括自行开发的应用、第三方的应用；
l系统中的设备、组件通过不同协议进行连接、通讯；
l系统的内部接口多，性能瓶颈多；而系统的整体性能往往取决于最差的部分；需要分别测试和联合测试
l系统的性能指标不光同应用系统架构有关，还和具体行业应用的业务模式有关；
l采用此架构的行业应用往往是一个7×24小时系统；
l采用此架构的行业应用可能高柜业务多，这样会影响对性能度量项的选取和转换；
l各个环节基本上以交换数据报文的方式通信，其格式经常会比较复杂。
因此这样的系统对于对测试工程师的知识的深度和广度都是一个考验。对于这样的系统，到底如何使用什么样的测试策略、如何分析测试需求、如何选取性能度量项的转换计算模型、如何确定测试内容和轮次、如何设计性能测试案例等等以及规划和实施性能测试中的其它诸多问题，都需要遵循一个系统的方法来解决。
1.3.2 CS/CSS系统架构中性能测试的基本策略
1.确定好测试工作范围
首先可以分析压力测试中最容易出现瓶颈的地方，从而有目的地调整测试策略或测试环境，使压力测试结果真实地反映出软件的性能。例如，服务器的硬件限制、数据库的访问性能设置等常常会成为制约软件性能的重要因素，但这些因素显然不是用户最关心的，我们在测试之前就要通过一些设置把这些因素的影响调至最低。
另外，用户更关心整个系统中哪个环节的性能情况也会影响工作范围。如有的环节是全新系统，而有的环节已经是成熟系统只是稍有改动，这样可能全新系统的局部性能测试就需要系统和全面一些。
2.分析好客户的性能测试需求
客户是已经明确提出了性能指标，还是只提供了用户使用方式和历史交易流量数据，需要我们自己进行性能基准的计算？性能测试的目的是验证系统性能还是想确定目标系统的理想配置？是否还要使用测试结果预测在不同机型的处理能力？是否要求在性能测试各个轮次中安排性能调优过程等等问题都需要有针对性的解答。
3.要作好性能测试的计划和方案
测试计划和方案中要注意测试需求分析阶段提出的问题的解决。
4.确定的测试通过准则、性能测试的计划、结果要获得客户的认可
要和客户确认，系统的性能指标达标的标准是什么；对于性能测试中各个部分和步骤的计划和结果，甚至是性能测试过程，都要根据其重要程度，决定是否需要客户进行确认和签字。获得客户的认可是最重要的。
1.3.3 CS/CSS系统中性能测量与性能探测
u性能测量
1.在性能测试开始前必须认真规划性能测量：
软件性能测量技术范围很广。可以包括日志、事件计数、事件持续时间、采样等性能测量技术。
l确定性能测量的策略：我们要测试什么？
l规划性能测试中使用什么样的测量工具。
2.测量的代表性
l测量结果要能够反映出影响性能的重要因素：工作量负载、软件和计算机系统环境。
3.测量的可重复性
l能够控制工作量负载、软件和计算机系统环境，从而能够重复测试过程。
u性能探测技术
在进行性能测量时，可以使用标准的商用工具进行，但是往往标准工具提供的数据不能满足要求。性能探测就是在程序的关键点插入代码探针来测量软件的执行特性。从而达到以下的目标：
–性能数据获取更方便
–数据的详细程度提高
–数据收集方式更加可控
依据
–数据收集方式更加可控
依据SPE（软件性能工程）的建议，软件探测需求应该作为软件体系结构的组成部分。在设计软件时设计软件探针。
所以在规划项目中的性能测试过程中，要建议进行软件设计时考虑岛性能探测需求，为性能测试中更好的进行性能测量做好准备。
1.3.4 CS/CSS系统下性能测试的类型
广义的性能测试包括许多类型。如：
• Scalability/load testing (规模化/压力测试)
通过在被测系统上不断增加压力，直到性能指标例如响应时间超过预定指标或者某种资源已经达到饱和状态。这种测试可以找到系统的处理极限，为系统调优提供数据。
• Performance testing (性能测试)
通过模拟生产运行的业务压力量和使用场景组合测试系统的性能是否满足生产性能要求。如以实际投产结构测试，求出最大的吞吐量与最佳回应时间以保证上线的平稳，安全等
• Configuration testing(配置测试)
通过测试找到系统各项资源的最优分配原则。
• Concurrency testing（并发测试）
测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。
• Stress testing（极限测试）
测试系统在一定饱和状态下，例如CPU、内存在饱和使用饱和情况下，系统能够处理的会话能力，以及系统是否会出现错误。
• Volume testing（容量测试）
测试系统能够处理的最大会话能力。
• Reliability testing（可靠性测试）
通过给系统加载一定的业务压力（例如资源在70-90%的使用率）的情况下，运行一段时间。
• Failover testing（失败测试）
对于有冗余备份和负载均衡的系统，通过这样的测试来检验如果系统局部发生故障用户是否能够继续使用系统，用户将受到多大的影响。
在CS/CSS系统下实际的性能测试中，需要根据具体情况进行性能测试类型的选取和组合。
1.3.5 CS/CSS系统下性能测试的组成部分
通常在一个CS/CSS系统中，分为用户界面层、服务逻辑层和数据服务层等几个层次，分别对应着客户、应用服务器、数据库服务器。如在金融行业应用中，客户端承载着柜面业务，部署在网点（包括字符柜员或图形柜员），还包括部署在自助设备上面的自助业务等；应用服务器上面主要是起到路由功能、业务处理功能、和渠道整合的作用；而核心业务处理系统包括交易平台、业务逻辑、核心处理、数据处理等。
由于业务逻辑分布在不同的环节，导致系统的内部接口多，性能瓶颈多，而系统的整体性能往往取决于最差的部分。所以对于整个系统的整体性能的测试可能需要针对各个环节分别做好各自的内部性能测试。
如下面的一个CS/CSS系统金融行业应用的例子：
图1-3 cs/css金融行业应用
为了测试整个系统的性能，需要预先针对各个组成部分进行内部性能测试，如后台主机的压力测试、sna gateway的压力测试、大前置系统的压力测试、前端系统的压力测试、外系统接入的压力测试等等。
在本别进行的内部压力测试中，为了排除系统其它部分的影响，均需要隔离各自的部分，驱动和桩都使用软件测试工具或自行编制程序来代替。在每个部分的内部压力测试中，又均可以根据具体情况使用上一节说明的各种性能测试类型进行性能测量。
2.CS/CSS系统架构中的性能测试的度量项计算模型
2.1定义度量标准项
进行性能测试的模型分析时，首先要确定关键性能目标。它应该是通过与客户沟通获得的，这些目标应该是解决客户关注的性能问题，也就是说，客户的性能测试需求体现为关键性能目标。性能目标应该是明确的、可度量的。例如：支持2000个并发用户；连续运行30天不停机等。
在明确了关键性能目标和性能测试的通过/失败准则后，需要定义如何度量关键性能目标和性能测试的通过/失败准则。度量的标准项会影响测试方法和测试工具的选择。举例来说，如果要度量100个用户并发的响应时间，就必须明确要度量以下哪一个标准项：
l每个并发用户的响应时间
l在有99个用户已经接入的情况下，第100个用户的响应时间
l两个指标都要度量
2.2性能基准及测试强度估算
实际上，关键性能目标并不总是很容易明确的。客户往往只有一些历史数据和业务增长的一些预期比例等等。但是这些数据对于我们也是很有用的，它们可以作为我们设计和测试使用的性能基准。
对于性能测试，在设计时就要首先提出设计的性能基准。所谓性能基准，就是要思考：多少人使用这个系统？使用时最大的用户数是多少？用户高峰期使用时间间隔多少，在多大数量级别上系统响应时间分别是什么？数据增长量有多大？数据增长到什么数量级和时间长短对硬件而言难于承受？网络实现条件是什么？在处理时CPU和内存增长如何控制？种种这些，然后设计时根据性能基准有条件的在编码实现和硬件配置方面进行优化，测试只不过验证系统是否达到预期设计目标。
但是现在的情况却往往是：设计出来后要求性能测试，测试什么然后是什么，好比考试没有标准答案却要求大家及格一样。或者是，客户虽然已经明确的提出了关键性能指标，但是设计的时候没有考虑，依赖于性能测试给出实际性能数据，然后再对比优化。性能测试在基于性能基准上，特别是基于经过计算和转换得到的关键性能目标，才能得出预期结果。这一点，需要测试工程师向设计人员反复灌输这种观念，否则，性能测试研究包括工具研究总是停留在讨论阶段。不要在编码完成以后才考虑优化问题，如果等项目实施了，优化还没有完成，就很难保证客户满意。
没有目标的设计，如同城市间的交通问题一样，我们抱怨建设者们缺乏远见，而软件设计人员同样缺乏想象力。
对于性能基准向关键性能目标的转化，用以下例子来说明。
有200个用户使用客户端软件进行业务处理（并发度至少要达到200并发），每年通过软件进行处理的总业务量为：2000万笔业务/年。
测试强度估算时采用如下假设前提：
◇全年的业务量集中在10个月完成，每个月20个工作日，每个工作日8个小时；
◇采用80—20原理，每个工作日中80%的业务在20%的时间内完成，即每天80%的业务在1.6小时内完成；
测试压力的估算结果：
去年全年处理业务约2000万笔，其中15%的业务处理每笔业务需对应用服务器提交3次请求；70%的业务处理每笔业务需对应用服务器提交2次请求；其余15%的业务每笔业务向应用服务器提交1次请求。根据以往统计结果，每年的业务增量为15%，考虑到今后三年业务发展的需要，测试需按现有业务量的2倍进行。
每年总的请求数量为：（2000*15%*3+2000*70%*2+2000*15%*1）*2=8000万次/年。
每天的请求数量为：8000/200=40万次/天。
每秒的请求数量为：（400000*80%）/（8*20%*3600）=55.6次/秒。
正常情况下，应用服务器处理请求的能力至少应达到：56次/秒。
或者，忽略提交的请求数，以业务交易数为准，定义每秒钟的交易数，及“吞吐量”。
如果再考虑未来几年的交易量的增加（每年增长15％），则可以归纳为：
•吞吐量：(T4*80%) /(1.6*3600)
– T4 = T0 * (1 + 15%) ^ 4
– T0：当前日均交易量2000万
– T4：未来4年日均交易量
另外，有时关键性能指标的确定和具体应用相关。如金融行业应用中的核心业务系统中会有日结、月结等批处理，往往使用一次批处理小于多少小时来表征性能指标。
2.3度量标准项和可采集的测量数据项转换
只有使用明确的可采集到的数据才能真正反映系统的性能状况。例如：
l每秒钟运行成功的交易数量
l单一客户端的响应时间(使用时间戳的差值，发出请求的时间和收到回应的时间)
l CPU的占用率
l网络流量占用率
l内存的占用率
l硬盘使用率
2.4压力的分解
对于一个由很多环节组成的复杂系统来说，如果想要模拟实际环境进行整体的联合性能测试的话，就需要针对整体压力进行各个层次的分解。
如：下图是一个实际系统进行的联合性能测试。后台主机系统最多的吞吐量是480笔/秒。。由于通信网关和主机在此环境中是1对1的关系，所以通信网关的压力要达到480笔/秒。而一个通信网关对应着三个前置机，所以每个前置机要达到160笔/秒送达主机的吞吐量，才可能使整个系统满负荷运转。考虑到其它层次类推。由于主机以外还存在其它服务系统，所以在前置机的压力上面加了一个“X”代表其它服务系统要求的压力。当某个层次的设备短缺，无法实际上达到其分解下来的压力时，往往需要使用软件手段，在上一层次上直接加压力解决。
图1-3联合性能测试实例
3.CS/CSS系统架构中的性能测试的规划与实施要点
3.1测试计划中的人力资源计划
由于性能测试时软件测试领域比较复杂的类型，所以性能测试计划中人力资源的计划也比较重要。要充分考虑到测试组织、测试程序的编写、测试设计、实现和执行、测试报告等等各种工作任务的人力资源需求情况。
一般情况下，一个工程类项目的性能测试工作由如下角色和职责：
测试分析师：负责分析测试策略、编写测试计划、制订测试方案、组织测试；
测试工程师：测试例设计、实现；环境协调；对测试结果进行分析，编写测试总结报告。
测试员（通常也可测试工程师兼任）：测试执行；对测试过程进行记录，收集、整理测试记录数据。
软件工程师（有时由测试工程师兼任）：负责编写、调试客户端测试软件和模拟软件；数据库管理系统的安装、ofs配置及系统的预埋数据准备。
系统工程师（有时由测试工程师兼任）：负责测试用的硬件维护及操作系统安装、配置。
上级测试负责人：负责对测试计划及测试总结报告进行批准。
客户：必要时可参加测试，并提出具体的测试要求；可要求暂停测试；重要测试结论要签字认可。
3.2为项目选择适合的测试工具
在性能测试过程中，一定要有适合的测试工具支持。
性能测试所使用的测试工具包括：
•负载模拟类工具
•性能测量类工具
•系统级测量工具：CPU、内存使用率统计
•统计类：响应时间、吞吐
•剖析类：代码级测量工具，例如统计函数调用次数
对于测试工具，每个具体项目的需求是有差异的，不存在通用解决方案。而且，工具的引入需要时间、资金和人力的投入。
测试工具的选择需要考虑性能测试中被测系统的需要，以及测试工具需要完成的功能。一般情况下的选择方案包括：
u真实生产系统
u商用压力测试工具
u定制压力测试工具
第一种选择限于资源以及准确性等因素在压力测试中一般不采用，这里不再讨论。对于后两种选择的取舍主要考虑的因素包括：
n是否能够满足压力测试中作为模拟程序、负载模拟的需要
n是否能够提供详细，准确的性能测量数据
n测试工具在成本的限制因素，包括时间和金钱
n测试组对测试工具的掌握程度
有很多很好的自动化的性能测试工具。如：MI的Loadrunner、MI的Astra LoadTest、Empirix的E-load、Rational TeamTest等等。其中又以MI的Loadrunner最为著名和常用。
有时在性能测试过程中也会采用自编的或定制的压力测试工具的方案，主要基于如下的原因：
首先、由于被测系统本身的特点，满足模拟程序需要的商用测试工具难以寻觅，即便是有靠近这方面需求的测试工具，考虑到费用以及培训时间的因素，也会增加测试过程的风险。
其次，有时由于相关技术的成熟，选择定制压力测试工具的方案无论在设计，实现，还是在测试工具的掌握上都不存在不可控的风险；并且在测试过程中随时满足测试需要的及时性方面，定制的测试工具也有无可比拟的优势。
最后、考虑到将来前置系统的产品化，对该系统进一步测试的需要会持续很久，定制的测试工具可以更好，更完善地满足这种需求。同时，对于与对象系统采用同样系统架构的项目都可以借鉴此定制测试工具的思想，快速地建立新的测试工具。
3.3测试准备工作
性能测试的准备工作，可以包括测试数据的准备、测试工具准备、测试环境准备、试执行等部分。
3.3.1.测试数据的准备
对于行业应用，尤其是金融行业应用，测试数据的准备中最重要的就是交易的选取。交易的选取有如下原则：
内部压力测试：尽量选取几个最消耗系统资源的交易，并覆盖所有的交易形态（如会话式、批量式、异步式之类），这样才有可能最大限度的检查出该部分的性能瓶颈；
整体联合压力测试：由于一般整体联合压力测试需要完全模拟实际生产情况，所以交易的抽样选取相对比较复杂。通常需要进行当前交易量的收集和预测性能测试交易量，更重要的是确定交易发送比例的分布。
如一个实际金融项目的交易发送比例的分布：
表1-1金融交易发关比例分布
交易代码
原始比例
发送比例
交易代码1
0.49%
16.90%
交易代码2
0.05%
1.72%
交易代码3
0.01%
0.34%
交易代码4
1.00%
34.48%
交易代码5
0.98%
33.79%
交易代码6
0.37%
12.76%
先选取实际原始发送比例中前50位的交易。然后将其所有比例数相加（一定小于1），做为新的基数，分别于各个交易的原始比例相除，即可得到使用工具模拟发送的比例。
此外，主要实际交易数据的获得通常要从数据库中使用脚本提取出来；还有可能需要自己利用某些规则自造一些数据。
3.3.2.测试工具的准备
通常，要为测试工具的编制和学习使用预留充足的时间。对于商用的测试工具，通常需要进行脚本的录制和修改，场景的设定工作；对于自编工具，要有设计、编码过程。而且，它还通常有其自己的配置文件和使用的数据文件，需要进行配置或数据格式转换。
3.3.3.测试环境准备
这里需要注意的问题是，可能在后台（充当桩的）数据库中需要生成预埋测试数据，要保证其足够且可重复生成或容易清理。
另外测试环境准备好了以后，每次执行前的检查环境过程也是非常重要的，可以避免大量的无用功。
4.性能测试报告
4.1测试结构数据的整理和分析
u测试报告文档的撰写
1． 测试中应该生成的测试文件
测试记录（测试负责人和参与测试的人员签字）；
测试总结报告。
2． 测试总结报告中一般必须包含的内容
被测试软件名称、测试项、测试环境；
被测试软件的压力测试结论：响应时间、最大/最小并发数、失败的次数、正常连续运行的最长/最短时间，并发数与失败的关系等
总之必须包含预先定义的关键性能指标的数据、变化曲线分析和结论。
5. CS/CSS系统架构下性能测试中需要注意的问题
5.1注意中间件的license、数据库的用户数等影响因素
有时候测试结果没有达到预期并不一定是被测对象的问题，可能是中间件的license不足或者是使用的数据库系统的并发用户数的限制导致，有时还因为配置项有问题等，需要综合分析。
5.2数据聚集问题
性能测试中选用的数据应该在差异上进行分散，与实际生产数据的随即差异分布相似，充分测试系统在不同数据下的状态。如果使用较单一的数据进行测试，一方面可能使系统的局部功能没有被使用，导致性能测试数据不可靠；另外，如果系统对于同样的数据处理有优化处理功能，也导致性能测试数据不可靠。
C/S架构性能测试
很多人关心LR在C/S架构上如何实施性能测试，我想根本原因在于两个方面，一是很多时候脚本无法录制，即LR无法成功调用被测的应用程序，二是测试脚本即使录制下来，可读性不强，往往不能运行通过，调试时无从下手，像音视频、电子地图类的测试差不多也是这个问题。
根据我以往的项目经验，LR是可以做到的，因为它提供了Windows Sockets协议，解决方案实施起来简单但需要足够的细心以及一定的判断力、想象力，可参考如下步骤进行：
1、通过抓包工具捕捉客户端与服务器之间的所有通讯。
关键点：IP过滤，端口过滤，报文类型过滤
目的：弄清楚业务操作过程中，客户端向服务器提交的请求原型，以及服务器对我们请求所做的正确响应
2、将过滤后的报文整理成测试脚本。
关键点：Socket的建立与关闭，send buf的整理，receive buf的整理
目的：将抓包获得的报文转成LR测试脚本（提示：选取合适的抓包工具，使得报文能被保存成文档格式；开发小工具，通过报文中的各个关键字抽取报文中Data Area中的部分作为buf区的内容，根据IP字段，端口号等特征完成lrs_send,lrs_receive语句的填写。这部分看上去挺难，但只要对报文做好分析，把握规律，编程的事随便拉个开发都可以轻松搞定）
3、调试脚本
关键点：定位错误，添加校验点
目的：使脚本真正可以拿来进行压力测试
这是最难的一个环节，耐心、细心、判断力都体现在此处。每个人处理问题的方式的不同，我只能提供自己的一点经验。
将脚本RUN-TIME SETTINGS中的扩展日志全部打上钩，并且将脚本拿到controller中单用户执行，注意设置好日志路径。
脚本出错后，用EDIT PLUS或其他的文本工具打开log,找到出错行，然后向上逐一对比服务器返回的数据与录制过程中抓包获得的报文。
在这里，我用了一个小技巧，生成buf内容时，使buf的编号与该buf在抓包获得的报文中编号保持一致，比较起来很方便。
如果服务器返回的buf与抓包时的原始数据一致，自然表示该步骤回放成功，如果不一样，则需要具体情况具体对待。就我的经验来说，往往是因为数据唯一性问题或者是关联的问题造成某一步骤返回的BUF为0或-1，从而导致最终脚本失败。
找到第一个出错的地方后，参数化，关联等手段都可以用上了，这里可能需要重复两次抓包过程，先行比较自己发送的报文是否有区别。
总体思路便是如此，写了一堆，也不知道对大家是否有帮助，对于此类问题，网络上的协助很难派上用场，事情还是要在现场才有可能得到解决啊。本来有意将这东西工具化，甚至产品化，但几个项目实施下来发现变数较多，特别是最后一个环节，完全依赖于测试工程师的自身能力，只好就此作罢。