网通系统压力测试方案微软（中国）有限公司编建日期2002年4月9日编制人冯江、谢华芳版本控制目录一、概述 (4)1.1项目背景和测试目的 (4)1.2被测系统介绍 (4)1.3测试可接收条件 (5)二、测试需求 (5)三、测试方法 (5)3.1测试方法 (5)3.2测试案例 (9)3.3测试流程 (9)3.4数据文件准备 (9)3.5测试脚本说明 (10)四、测试环境 (10)4.1网络拓扑图 (10)4.2环境配置 (10)五、测试实施 (11)5.1试资源与进度 (11)5.2 测试机构和人员职责 (12)六、试存储管理规范 (13)6.1存储内容、地点、命名规则 (13)6.2存储目录结构 (14)6.3备份 (14)附录1：Env_Check_list (15)附录2：测试工具原理 (16)一、概述1.1 项目背景和测试目的为了保障网通即将建设的综合营帐系统能够顺利实施，网通希望在项目正式实施前了解未来系统是否可以使用目前已经选用的技术进行搭建，即了解项目技术的可行性。
另外，网通还希望了解使用不同技术实现的差异。
1.2 被测系统介绍本次被测系统是针对网通项目的一个前期实验系统。
系统逻辑结构图如下：图1、系统逻辑结构图整个系统分为三个主要部分，主要功能包括：1.系统A系统A是整个系统的数据入口，可以将客户请求传给Biztalk或者直接传给系统B。
系统A可以通过两种方法接收客户请求传给系统。
一种通过Tuexdo(A)接收用户请求，另一种可以直接通过WebLogic(A)接收用户请求。
talkBiztalk是整个系统的中心，负责连接系统A和B，主要目的是同步处理系统消息。
另外，由于测试需要，Biztalk本身可以接收用户请求（Http）。
3.系统B可以看作系统的服务端。
接收Biztalk的请求，并返回结果。
1.3 测试可接收条件1、每次测试交易成功率在90%以上2、用户每个请求的响应时间低于2秒每次测试，以上条件必须同时满足，方视为本次测试通过。
二、测试需求本次测试的需求包括：1、Biztalk系统的处理能力2、整个系统能够支持多少用户同时访问3、不同技术间实现的差异三、测试方法3.1 测试方法测试过程采用自动测试工具进行。
目前暂时决定使用Mercury Interactive公司的测试产品：LoadRunner。
1、测试Biztalk系统的处理能力：图2、测试Biztalk系统的处理能力模拟多个Web类型的虚拟用户，同时向Biztalk系统发送HTTP请求，之后记录每个虚拟用户的响应时间。
2、整个系统能够支持多少用户同时访问方法一：模拟多个Web类型的虚拟用户，同时向WebLogic(A)发送HTTP请求，之后记录每个虚拟用户的响应时间。
图3、测试整个系统能够支持多少用户同时访问（方法一）方法二：模拟多个Tuxedo类型的虚拟用户（即模拟Tuxedo客户端），同时向Tuxedo(A)的服务发送Tuxedo请求，之后记录每个虚拟用户的响应时间。
图4、测试整个系统能够支持多少用户同时访问（方法二）3、不同技术间实现的差异方法一：模拟多个Tuxedo类型的虚拟用户（即模拟Tuxedo客户端），同时向Tuxedo(A)的服务发送Tuxedo请求，并且Tuxedo（A）发送的请求，不经过Biztalk系统，之后记录每个虚拟用户的响应时间。
图5、测试不同技术间实现的差异（方法一）方法二：模拟多个Web类型的虚拟用户，同时向WebLogic(A)的发送HTTP请求，并且WebLogic（A）发送的请求，不经过Biztalk系统，之后记录每个虚拟用户的响应时间。
图6、测试不同技术间实现的差异（方法二）3.2 测试案例3.3测试流程正式测试过程如下：1、确认被测环境正常（Env_Check_list）2、确认测试环境设置（Env_Check_list）3、开始测试4、存储测试结果5、系统调试6、应用调试7、环境维护3.4数据文件准备3.5测试脚本说明四、测试环境4.1网络拓扑图图7、测试网络拓扑图4.2环境配置五、测试实施5.1试资源与进度5.2 测试机构和人员职责图8、测试组织结构图六、试存储管理规范6.1存储内容、地点、命名规则●存储内容：a)测试脚本b)测试场景c)测试结果d)相关文档e)数据文件●存储地点：运行控制台的主机硬盘上，存储结构见下面图9。
●命名规则：a)测试脚本LTscr_App_[SubApp_]version说明：LTscr：Load Test ScriptApp：业务名称SubApp：子业务名称（[ ]可选）V ersion：脚本的版本号b)测试场景LTsce_App_[SubApp_]ConCurrUser_Iteration说明：LTsce：Load Test ScenarioApp：业务名称SubApp：子业务名称（[ ]可选）ConCurrUser：并发用户数Iteration：每个用户循环次数c)测试结果LTres_ App_[SubApp_]ConCurrUser_Iteration _time说明：LTres：Load Test ResultApp：业务名称SubApp：子业务名称（[ ]可选）ConCurrUser：并发用户数Iteration：每个用户循环次数Time：第几次测试6.2存储目录结构图9、测试存储结构图说明：Script：存储测试脚本Scenario：存储测试场景Result：存储测试结果Document：存储相关文档DataFile：存储数据文件6.3备份测试结果每天在测试结束后备份一次，将“D:\LoadTest”目录，全部备份到磁带机或“\\AnyPC\C:\ LoadTest_bak”附录1：Env_Check_list 日期：2002年___月___日___时___分测试结果名称：____________________测试监督签字：________________________附录2：测试工具原理Mercury Interactive 公司的客户机/服务器系统的压力测试工具LoadRunner，其工作原理为：通过一个中心控制点，在一个或几个主机上同时模拟成百上千的实际用户的操作，从而生成一致的、可测量的及可重复的系统负载，并记录特定交易操作的响应时间。
概要地说：首先录制应用程序的操作过程，测试工具会自动生成可执行的脚本，该脚本运行起来，从服务器端看，就如同一个实际的用户在进行操作，我们称为虚拟用户。
然后，通过中心控制点（Controller）设置测试场景，控制许多个虚拟用户在多台Agent机器上同时运行，监控运行状态，收集响应时间等性能数据。
●使用虚拟用户（Vuser）替代实际用户每个模拟的用户即为一个虚拟用户，其实就是一个运行的测试脚本。
LoadRunner在PC上主要有两种Vuser：非图形用户界面的虚拟用户（Non-GUI Vuser）和图形用户界面虚拟用户（GUI Vuser）。
Non-GUI Vuser是直接通过API调用和Web/Application/DB服务器进行交互的，它的脚本是直接向服务器提交请求的类C语言程序。
多个Non-GUI Vuser 可运行于一台主机上。
Vuser可通过Virtual User Generator来录制生成，在录制脚本中可以标明某一活动（transaction）的开始和结束点，用于具体度量这一活动的响应时间及性能，还可以在某一操作之前定义集结点（rendezvous），用于测试这一操作的多用户并发。
GUI Vuser模拟实际用户运行应用程序进行操作的情况，它的脚本记录了客户机上所有的界面操作。
GUI Vuser可通过Mercury Interactive 公司的功能测试工具WinRunner来录制生成。
由于本次压力测试的目的是检验服务器对压力的承载能力，因此建议通过在一台主机上运行多个Non-GUI Vuser来模拟多用户的活动进行压力测试。
●测试脚本的参数化测试脚本反映的是录制时输入的数据的情况。
但由于录制操作可能引起原输入数据状态的变化，因此要修改测试脚本中的输入数据及与其相关的数据；而且为了更准确地模拟真实系统的运作，输入的数据及与其相关的数据就必须参数化，并且为该参数建立一个包含所有数据的参数文件。
这样当模拟多用户进行压力测试时，就可控制每个虚拟用户使用参数文件中的不同数据。
通过中心控制点（Controller）管理虚拟用户在中心控制点，定制测试场景，即将要在测试会话中发生的事件。
定制包括模拟的用户个数、模拟用户所在的主机、模拟用户的动作等。
在中心控制点控制场景的运行，管理所有虚拟用户的活动，监控虚拟用户的状态，也可以无人照料地运行。
场景执行完后，可通过Controller的性能分析图形和报表对结果数据进行分析。
代理程序必须安装在参与测试的每一台主机上，当场景开始运行，代理程序负责Controller与主机之间的通讯。
使用自动生成的图表和报表分析测试结果在每个测试场景运行完后，Controller自动收集服务器、网络及客户端的性能数据，并以图形和报表的形式显示。
其中包括服务器响应Vuser以及transaction 提交的请求和任务的时间；在运行期间的基于活动Vuser数目的transaction性能时间；服务器磁盘I/O、CPU使用情况，网络延迟等数据。
测试方法及步骤1、建立虚拟用户（生成测试脚本）在LoadRunner的Virtual User Generator中录制测试脚本，建立虚拟用户，一般一个业务操作录制成一个测试脚本，步骤如下：1)根据应用软件的体系结构、中间件、数据库或客户端与服务器之间的协议，选择对应的虚拟用户类型，如：WEB、Oracle、Tuxedo、WinSocket等等；2)指定要录制的可执行程序，开始录制；3)在Vuser init section中记录登录应用系统的过程；4)在Actions section中记录功能操作过程，适当加入事务（transaction）的开始与结束点（事务也可在脚本生成后，直接在脚本中加入）。
当需要记录压力测试过程中某一操作的响应时间时，则在执行这一操作前定义事务的开始点，并给这一事务命名，在操作结束后定义该事务的结束点；5)在Vuser end section中记录退出系统的过程；6)回放测试脚本，检验测试脚本执行的正确性（有可能要恢复录制以前的数据状态，或进行必要的参数化）。
2、试脚本的参数化测试脚本反映的是录制时输入的数据的情况，但为了更准确地模拟真实系统的运作，如模拟不同用户的登录，不同用户查询股票行情，不同用户在做不同的股票交易等情况，有些输入的数据必须参数化，并且为该参数建立一个包含所有可能的数据的参数文件。