压力测试的目的

目的是在软件投入使用以前或软件负载达到极限以前，通过执行可重复的负载测试，了解系统可靠性、性能瓶颈等，以提高软件系统的可靠性、稳定性，减少系统的宕机时间和因此带来的损失。

在最近的一次测试中定义了测试的目的是：需要了解AUT(被测应用程序)一般能够承受的压力，同时能够承受的用户访问量(容量)，最多支持有多少用户同时访问某个功能。在AUT中选择了用户最常用的五个功能作为本次测试的内容，包括登录。大概的需求就是这样。

接下来AUT的登录说一说怎么用LoadRunner和Jmeter来实现场景的设置达到测试的目的。(注：对服务器的检测不是本次测试的重点，本次测试主要收集并发访问用户数和发生错误用户数)。 首先是对脚本的要求：

1、录制脚本(注意所有的脚本都应录制到Action中)，自定义事务，事务从提交用户名和口令的脚本之前开始

2、在定义事务开始的脚本前加入集合点

3、在脚本中加入检查点，以登录成功的页面出现登录用户的ID即可

4、参数化登录用户的身份

其次是对场景设置的要求：

1、因为事先我们不知道将有多少用户访问是临界点，所以在测试过程中需要多次改变用户数来确定

2、建议修改运行时设置，优化对服务器的访问[Page]

3、计划的设置，每x时间后加载10用户(根据总用户数设置)，完全加载后持续运行不超过5分钟(根据需要设置)

4、集合策略，当运行中的用户数100%达到集合点时释放

5、注意事项，需要注意几个时间：1)服务器响应超时时间2)登录事务迭代一次所使用的时间3)集合点等待超时时间4)计划中设置的间隔时间。在我的测试中事务运行一次的时间不超过30秒，通过修改脚本使它的运行时间达到一分钟左右， 服务器响应超时时间、结合点等待超时时间、计划中设置的间隔时间都设置为了2分钟。

这样场景开始运行后运行用户数呈阶梯增长，另外在每个上升点新增的用户都会随原来已经运行的用户并发访问服务器。

通过多次的运行和对测试结果中正在运行用户数与错误用户的对比，然后根据定义可接受错误率就可得到该功能的最大并发访问的用户数。

以上测试中排除了对网络、客户端等的要求。在实际测试中首先要保证这些资源是足够的。

使用Jmeter也能够达到上述描述的场景的测试，并且更加的便捷。 利用现代的设计技术和正式的技术复审可以减少代码中存在的初始错误，但是错误总是存在的，如果开发者找不到错误，那么，客户就会找到它们。越来越多的软件组织认识到软件测试是软件质量保证的重要元素之一，很多软件开发组织将30%—40%甚至更多的项目资源用在测试上，软件测试技术和软件测试策略受到了高度的重视和广泛的应用。

本文不想就软件测试技术和软件测试策略作深入的理论分析，而是列举一个在软件系统测试阶段进行的软件压力测试实例，希望能通过这个实例与从事软件测试相关工作的朋友进行交流。

首先介绍一下实例中软件的项目背景，该软件是一个典型的三层C/S架构的MIS系统(客户端/应用服务器/数据库管)，中间层是业务逻辑层，应用服务器处理所有的业务逻辑，但应用服务器本身不提供负载均衡的能力，而是利用开发工具提供的ORB(对象请求代理)软件保证多个应用服务器间的负载均衡。本次测试的目的是：进行单个应用服务器的软件压力测试，找出单个应用服务器能够支持的最大客户端数。测试压力估算的依据是：假定在实际环中，用户只启用一个应用服务器进行所有的业务处理。方法是：按照正常业务压力估算值的1~10倍进行测试，考察应用服务器的运行情况。