•分析测试需求

•确定测试负载

•确定用例细节

录制测试脚本

 在编辑脚本时，要注意几点：

•录制基本的虚拟用户脚本

•优化脚本（设置Run-Time属性；参数化；设置事务集合点；脚本回放等）

•配置Run-Time属性

•在单机模式运行测试脚本

•将虚拟用户脚本合并到测试场景中

——》

执行测试

  在执行测试场景时，要注意几点：

•运行一个完整的测试场景

•控制虚拟用户组

•控制独立的虚拟用户

•手工从集合点释放虚拟用户

•手工向一个执行的场景增加虚拟用户

在监控测试场景时，要注意几点：

•开始监控器

•打开在线监控器图表

•服务器资源监控

•设置监控器属性

——》

分析测试结果

因为分析测试结果部分涉及的东西比较多，所以这里先暂时只给出个例子。

估计性能测试总工作量：

因为在编写材料时，有同事提出比较关心性能测试的工作量，所以我将这个例子项目的性能测试工作量进行了统计。

某移动知识管理系统在系统初验前，项目总工作量是49.06人月，测试总工作量是8.644人月（即186人日），测试占项目总工作量的17.62%。其中，性能测试占测试总工作量的14.3%，与前面介绍的性能测试估算比例9%相比大出很多。这是因为参与这个项目的测试组没有性能测试经验，并且这个项目性能需求比较多，客户对系统性能要求比较高。单单到客户处进行性能测试，就不下10次，这还需要包括前期的实施准备工作。因为移动的机房和我们测试客户机不在同一个地方，所以，每次进行性能测试之前，都需要很多人的协助。所以，从工具学习、到脚本问题处理、沟通、测试执行上，这个项目都花了不少时间。后面另一个项目因为有了前面项目的经验积累，整个性能测试工作的工作量占整个项目性能测试工作量的8.2%。

下面我使用该项目的一个性能测试点对脚本的录制这块介绍。

场景介绍：
[-o!mC)L0培训考试在线考试，要求能够实现500个人同时在线考试。
*[&Gi:l8Lb!E9O0关键点：ITPUB个人空间j l)Y9]v],Kf
每个人登陆系统后，不能再次登陆系统
4? I+AD+@|R0500人同时提交试卷时，并发性要求很大
E#dXnD0

因为没有系统，先大致给大家描述一下界面。

由于录制脚本是整个性能测试的一个基础，所以，这里先主要讲脚本的录制。

假设：并发性最大的情况是考试时间到时，系统自动提交试卷的这一时刻。

这里主要强调几点：

1.参数化的几个注意点：

1)空格问题

2)参数设置方式

3)16进制的参数化（多用几个用户录制脚本，对比脚本不同的地方）

——》

二、测试经验

1.应该尽早的进行性能测试，不建议上线后做性能测试
6D5B)u Z X s0tfx02.我们不可能对所有的系统功能都进行性能测试。
n7{^5f*v _EcM(N0在测试设计时需要结合当时的实际系统，先分析软件可能存在的瓶颈，此时可依据80/20原则（帕雷托原则）分析，再依此制定性能测试的方案：ITPUB个人空间E:[7QY2p;M q
1）对系统资源的利用；
T$B.})qj02）数据大量传输；ITPUB个人空间yo v"Tx$u\N
3）数据转换（获取其它库表中数据转换为XML格式，或二进制）；
0^dO9VU2VOB04）使用的频度（分析用户习惯）