利用LoadRunner等自动化测试工具，可以在实验室环境中精确重现生产环境中任意可能出现的业务压力，全面搜集系统各个环节的性能数据，配合强大的数据分析工具帮助用户准确定位问题和系统瓶颈，使每次测试的成本大大降低，分析的能力和方便性也大大加强。

　　脚本制作是将所有的业务流程转入测试脚本，通常指的是虚拟用户脚本或虚拟用户。虚拟用户通过驱动一个真正的客户程序来模拟真实用户。利用测试脚本可以保证获得准确、适当、可重复的测试进程与测试结果。通过测试脚本的限定，我们可以排除测试过程中可能出现的干扰和意外，保证获得稳定的评价结果。

　　下面笔者以客户机/服务器系统应用中对服务器端进行性能测试为例，分析压力脚本制作技术需要考虑的一些问题。

　　首先，配置测试环境是测试实施的一个重要阶段，测试环境的适合与否会严重影响测试脚本制作的方便性、测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备以及打印机、扫描仪等辅助硬件设备所构成的环境； 软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。

　　在测试正式执行时，还需要准备业务测试数据，比如测试并发查询业务，那么要求对应的数据库和表中有相当的数据量，以及数据的种类应能覆盖全部业务。

　　接下来就是制作测试脚本了。制作脚本过程一般需要了解协议知识如socket通信、中间件通信等，注重分析录制的脚本变化，这些变化可能就是需要修改的地方，可据此分析生成参数化变量。通常需要设定一个思考时间控制虚拟用户与系统交互的速度，包括在测试执行期思考时间的耗费。根据不同的用户，设立不同的思考时间。另外，还需要使用IP 欺骗，通过给同一主机上产生的每个虚拟用户分配不同的IP 地址，来测试与IP 相关的那些部件的性能变化。

　　制作的脚本需要通过测试对其个别参数不断优化，才能满足测试所需的正确性和大压力要求。以下是几种脚本制作方法的比较。

　　1、根据应用的接口来编写测试脚本

　　这种方式具有的优点是脚本对交易的测试更接近实际使用场景，测试结果的验证可以根据交易调用的返回信息进行验证，准确性高。如果测试交易中有相互关联的交易，如交易的排队、撤销、冲正等，使用这种方式更容易实现。通常可以根据自己的应用订制一个测试框架，对应用业务的变化可以通过配置文件的改变来适应业务的变化，脚本的重用性好，可以对业务系统中复杂的交易进行深入的测试。

　　这种方式的缺点是需要测试团队中有编程经验丰富的测试人员，初期建立测试框架的工作量大，但从测试团队的组建来讲，建议要配备有一定编程经验的测试人员，这样可以结合工具的优势对应用进行深入的测试。

　　使用编程的方式编写测试脚本，具体方法是将交易调用的接口封装成可以被测试脚本调用的接口，每个交易一个测试脚本，调用相应的测试接口对服务器进行加压。

　　2、录制客户端交易过程的方法

　　这种方式具有脚本制作容易、基本不需要编程的优点，但缺点是受到前端应用处理方式的限制，如连接数、连接方式的限制等。这种方式很难对服务器形成大的压力，主要适合对客户端处理能力进行压力测试。

　　录制客户端交易过程的具体方法是使用脚本录制服务器登录待测试客户机，模拟人工方式产生交易，录制交易的实际执行过程，然后使用多个虚拟用户进行回放。

　　3、录制交易网络的数据包形成测试脚本

　　录制交易网络的数据包形成测试脚本的具体方法是，首先保证客户端和服务器端在一个广播的局域网上，然后使用加入录制器监听客户机和服务器之间的一次完整交易，解析socket通信内容并形成测试脚本，然后对测试脚本予以调整和优化。这种方式的优点是脚本制作容易，制作的脚本容易对服务器端产生很大的压力。但其缺点是回放问题多，主要表现在如下几个方面。

　　首先，脚本数据参数化困难。如果发送的报文可以重复发送，这种录制回放网络数据包的方式尚还可行，但一般实际业务每笔交易的报文数据都不同，录制的数据一般是以十六进制字节流或其他的编码方式，还原成业务数据的某些字段比较困难，需要对网络底层的数据格式和协议比较熟悉才可以对脚本进行参数化。

　　其次，加密机制的处理也比较困难。在C/S模式应用中，一般客户机和服务器间的通信使用专用加密方式处理通信数据。在这种情况下，交易加密字段的值更难以进行参数化，解决的办法通常是采用编程的方式调用业务的加密/解密函数，其过程是： 读取报文→解密→解析字段→参数化→加密→回写报文。

　　另外，不易验证测试结果。基于网络数据包的响应来验证交易的正确性非常困难，特别是某些交易需要客户端和服务器端有多次交互时更难以分析服务器端返回结果，不容易保证交易的正确性。

　　最后，录制环境和回放环境之间存在差异。一般采用Windows平台录制初始的脚本，但回放时可能因为种种原因需要使用其他操作系统平台如Uunix。在这种情况下会出现更大的问题，因为Unix字符集和Windows字符集不同， 例如Unix对回车换行字符的解释和Windows也不同。Unix把回车换行解释成一个字符，而Windows解释成两个字符。由于录制的工作在Windows 平台上完成，此测试脚本使用的是Windows字符集的解释方法，在Windows上回放时是十分平稳的。而将此脚本拿到Unix平台上时，如果交易的脚本中出现了特殊的字符序列组合，造成在Unix中无法正确识别，使交易执行错误率较高。