1、了解测试需求：日均20万首页访问量测试，测试指标响应时间、系统资源使用率
2、系统的实际功能表现、系统体系结构
功能：一个jsp页面，包括for循环及一个bmp图片；
系统体系结构：Tomcat+JDK+JSP,无数据库；
相关服务器配置：被测服务器硬件配置：内存2G；软件配置：OS WINXPSP3，IE6.0
Tomcat配置：    <Connector port="8081"               maxHttpHeaderSize="8192"
               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
               enableLookups="false" redirectPort="8443" acceptCount="100"
               connectionTimeout="20000" disableUploadTimeout="true" />
tomcat内存（JVM）：初始化内存100，最大可用内存为500，连接所耗内存2k

为Tomcat分配更多的内存，如果是使用的catalina.sh或Catalina.bat启动的Tomcat，则可在这两个文件中添加“SET CATALINA_OPTS= -Xms300m –Xmx300m”

将相关信息，如操作系统、软件配置（tomcat、数据库、中间件等等处于系统体系结构中的所有软件）都列举出来，然后进行数据分析，确定是否需要开展性能测试。

另外可以与客户、工程运维、开发人员进行沟通，获取系统历史性能表现（针对系统已经上线的情况）

掌握上述问题的详细情况，性能测试人员需要整理信息，并在测试方案中体现。

1、分析测试需求、确定测试点

日均20万PV，考虑到访问不是均等的，采用2/8原则（前提是没有任何历史数据提供参考，也无法从其他途径获取详细需求），20万*80%的业务量在24小时*20%的时间内完成=16万访问量需在4.8小时内完成。
测试对象是系统的首页，所以测试点确定为系统首页，最终的测试需求为：

在4.8小时内完成16万的首页访问业务。

2、提取测试指标

根据初步需求，系统要求获取响应时间与系统资源利用率
响应时间：由于客户没有明确提出响应时间的参考标准，根据通用的测试经验值（2，5，8，10），我们采用2秒的响应时间，尽量贴切用户体验。所以，响应时间参考值为：2秒

系统资源利用率：由于没有提出明确指标，故按照常规测试方法，我们监控CPU及内存的使用率表现即可。按照经验值，CPU、内存的利用率不超过70%（windows）；

3、建立业务模型
a、弄清楚系统体系结构并画出系统组网图、网路拓扑图、业务流程图；
b、分析清楚系统中的约束条件，一一列出并注上使用什么技术方法来解决
比如：ip限制（一个ip只能做一次）可采用IP欺骗功能；数据有唯一性要求的（注册的用户名、添加的订单号等等）可使用参数化解决；数据之间是有关联性的（后面的业务操作可能需要前面业务的数据）可使用关联方法解决；想要判断业务逻辑的（判断是否登录成功）可用文本检查点+if语句进行处理；需要实现大并发量的模拟（比如100个绝对并发）使用集合点与think_time配合处理；无法使用action划分的动作（一次请求有多个响应的情况）可使用事务点解决；
c、根据业务量流程图进行action划分，先划分好再设计脚本
d、准备好测试数据：详细写出测试数据制造过程。

尽量考虑全面了，不要有遗漏

4、设计测试方案、脚本测试用例、场景用例
a、测试方案，按照模版填写，并将建模阶段所有产出物进行细化确定。
b、脚本用例设计：模拟用户登录系统，打开首页，待页面展示完毕即可
约束条件：无
测试数据：无
操作步骤：输入url地址：http://localhost:8081/test/test.jsp
期望结果：被访问页面（首页）在2秒内正常显示完毕，CPU使用率不超过70%，内存使用率不超过70%
c、场景用例：
测试目标是：4.8小时完成16万访问量，可以设计两种场景：
1、场景开始时就加载所有（所有是多少？）并发；（可以考察系统支持绝对并发情况）
start 所有vuser，选中第一个选项（simultaneously），持续运行阶段（duration）设置“run for 4.8个小时”，stop vuser方式选中第一个（simultaneously）立刻停止所有vuser。

2、采用逐步加压，持续运行，逐步减压的测试策略（相对来说系统有所缓冲，更真实模拟业务情况。）
可以事先在提取测试指标阶段计算出大概的并发数：
计算并发数的方法是：
a、确定业务量：16万（使用2/8原则后的业务量）
b、确定时间段：4.8小时（使用2/8原则后的时间段）
c、确定单用户单次执行所消耗的时间：利用loadrunner并设置事务点考察做一次业务所消耗的时间（0.4134秒）
d、4.8*3600/0.4134=一个用户在4.8小时内可以模拟访问多少次=大约为41800次，现有16万业务共需多少人模拟？16万/41800大约等于4个人，也就是说大概需要4个并发来模拟。

已经计算出并发数，开始设计第二种场景
这里策略是：
每隔10分钟增加1个vuser（strat处设置为每隔10分钟增加一个），当所有vuser都上去后，持续运行4.8小时（duration设置为4小时48分钟），每隔10分钟减少1个vuser（stop处设置为每隔10分钟减少一个）

场景设计完成后与脚本用例设计思路一起放在测试方案中，提交相关人员评审，没有问题后可待机实施性能测试工作。

脚本设计与开发

1、脚本设计（按照脚本测试用例来）
录制、手动编写，能够录制尽量录制，减少难度
录制脚本流程：
a、确定协议；b/s结构常用的协议是web(http/html)，c/s结构常用socket协议，如果不知道可以问开发同事，也可以使用抓包工具自行分析，loadrunner在9.5版本后提供了协议探测功能，我们可以自己探测。
b、确定action；已经在建模过程中确定了。只需要在loadrunner中事先添加好（create action按钮）；
c、确定浏览器、杀毒软件、防火墙的设置；卸载不相干的浏览器插件，将浏览器中的“内容”中的自动完成清除掉，杀毒软件、防火墙最好关闭掉
d、开启应用程序；启动被测服务，对于j2ee架构的，最好先运行一下，
e、准备好测试数据；录制脚本过程中所使用的测试数据要事先准备好；
f、录制脚本：

1、注释：可以不用
2、集合点：使用（view_homepage）
3、事务点：使用，统计打开首页的时间，添加cookie时间放在action中统计，
4、参数化：不使用，没有需要做参数化的点；
5、关联：不使用，没有需要使用关联的点；
6、文本检查点：不使用；
7、思考时间：不需要，输入url回车后无需思考时间
8、常用编程方法：不使用，未涉及到

优化做完后回放调试脚本，没有问题就开始其他的脚本设计，当所有脚本设计完成后，可利用配置管理工具进行脚本管理（比如cvs，vss），

如果手写代码：需要掌握客户端与服务器端的具体响应方式及内容，然后详细分析，最好由开发人员来处理。涉及到加密的信息传输，可能需要解密的函数。

场景设计与执行

场景设计分为7个步骤，可将这些步骤列出来，一一处理：
并发数重新确定
为什么需要重新确定并发数，在指标提取阶段所估算出来的并发数，反推计算业务时有比较大的误差，原因是小数被进一位了。在实际测试过程中，估算出的并发数所消耗的数据量往往大于预先的估计，所以调整数据量（如果使用unique类型，block设置非常关键，设置不当可能会导致测试运行失败）

设计场景计划
按场景计划（场景执行策略针对所有脚本生效，无法单独定制）
按组计划（针对单个脚本进行场景执行策略的设置）
初始化设置：第三个选项（在每个vuser运行前初始化他，好处是节省系统资源）

开始vuser设置（两个选项，当需要场景开始后立刻加载所遇vuser的话，就使用simultaneously，如果使用逐步增加的方式，则使用第二个选项）

持续运行设置（两个选项，当需要vuser执行完成后就停止的话，选中第一个，如果模拟持续运行的情况，可使用第二个，当设置了持续运行时间后，run time setting的run logic中的迭代次数是不生效的。）

stop设置
与start类似，如果希望脚本运行完成后就可以，则选第一个选项，否则选第二个。

设置运行时设置
run logic需要注意的是与场景计划中的duration设置关系，如果duration中选的是第一个，那么run logic是生效的，如果是第二个，则不生效
log设置：场景运行中设置日志启用，但仅在发生错误的时候发生日志，在脚本调试阶段，选择日志启用，一直发生日志，并选择扩展日志与参数替换。
think time：尽量的模拟真实用户的行为习惯，启用思考时间，方法是as recorded，思考时间的修改可在代码中直接修改，也可以自定义变量去随机修改。rand函数

miscellaneous：勾中continue on error，当发生错误的时候继续执行，原因是在测试过程中错误可能是服务器无法正确处理引起的。测试是不能立刻停止的。在脚本调试阶段，不勾，发生立刻停止并调试

其他选项默认不做设置。

设置集合点
在脚本中没有设置集合点的话，则在场景中的集合点设置功能按钮是灰色不可用的。
集合点的策略通常情况下不做改动。

设置其他的选项（结果目录与负载生成器）
结果目录存放场景运行结果，在结果分析中有用，可用于结果比较
负载生成器：当测试机器的系统资源成为瓶颈的话，可以使用该方法将压力分发出去，让代理机模拟压力的产生，而controller负责收集测试数据并做分析。如需使用该功能，则需启动loadrunner agent，

设置IP欺骗功能
当系统对ip有限制的话，可使用该功能，通常情况不用，动态分配的ip是不能使用ip欺骗，需将ip设置静态的。

设置数据监控（application manage）

可以利用loadrunner自带的监控功能，也可以根据实际需要选择恰当的测试监控工具，主要用来相关的系统资源使用情况。