压力测试是在一种需要反常数量、频率或资源的方式下,执行可重复的负载测试,以检查程序对异常情况的抵抗能力,找出性能瓶颈。从本质上来说,测试者是想要破坏程序,难怪在进行压力测试时常常问自己:“我们能够将系统折腾到什么程度而又不会出错?”这种系统折腾,是对异常情况的检测。异常情况主要指的是峰值(瞬间使用高峰)、大量数据的处理能力、长时间运行等情况。压力测试总是迫使系统在异常的资源配置下运行,例如以下几种情况。

  ● 当中断的正常频率为每秒1~2小时,运行每秒产生10个中断的测试用例。

  ● 定量地增长数据输入率,检查对数据处理的反应能力。

  ● 运行需要大存储空间(或其他资源)的测试用例。

  ● 运行可能导致虚存操作系统崩溃或大量数据对磁盘进行存取操作的测试用例等。

  1.测试压力估算

  根据产品说明书的设计要求或以往版本的实际运行经验对测试压力进行估算,给出合理的估算结果。例如,单台服务器实际使用时一般只有100个并发用户,但在某一时间段的用户峰值可达到500个。那么事先预测要求的压力值为500个用户的1.5~2倍。而且要考虑到每个用户的实际操作所产生的事务处理和数据量。如果产品说明书已说明大设计容量,则大设计容量为大压力值。

  2.测试环境准备

  测试环境准备包括硬件环境(服务器、客户机等)、网络环境(网络通信协议、带宽等)、测试程序(能正确模拟客户端的操作)、数据准备等。

  分析压力测试中系统容易出现瓶颈的地方,从而有目的地调整测试策略或测试环境,使压力测试结果真实地反映出软件的性能。例如,服务器的硬件限制、数据库的访问性能设置等常常会成为制约软件性能的重要因素,但这些因素显然不是用户关心的,在测试之前要通过一些设置把这些因素的影响调至低。

  ● 压力稳定性测试:在选定的压力值下,持续运行24小时以上进行稳定性测试。客户端通常由测试工具模拟真实用户不停地进行各种操作。监视服务器和真实客户端的必要性能指标。通过压力测试的标准使各项性能指标在指定范围内无内存泄漏、无系统崩溃、无功能性故障等。

  ● 破坏性加压测试:在压力稳定性测试中可能会出现一些问题,如系统性能明显降低,但仅从以上的测试中很难暴露出真实的原因。通过不断加压的破坏性手段,往往能快速造成系统的崩溃或让问题明显地暴露出来。

  3.问题的分析

  在压力测试中通常采用的是黑盒测试方法,测试人员很难对出现的问题进行准确的定位。报告中只有现象会造成调试修改的困难,而开发人员又没有相应的环境和时间去重现问题,所以适当的分析和详细的记录是十分重要的。

  ● 查看服务器上的进程及相应的日志文件可能立刻找到问题的关键(如某个进程的崩溃)。的程序员会给程序加上保护、跟踪机制及错误处理机制,备份日志文件以供参考。

  ● 查看监视系统性能的日志文件,找出问题出现的关键时间。此时的联机用户数量、系统状态等也是很有价值的参考材料。

  ● 检查测试运行参数,进行适当调整重新测试,看看是否能够再现问题。

  ● 对问题进行分解,屏蔽某些因素或功能,试着重现问题。例如客户端与服务器有三种连接方式:TCP、HTTP、HTTPS,则只保留HTTP或TCP连接方式,如问题仍然存在,也许代理服务器或网关等造成的,把MS代理换成SQULID代理再次检验。

  4.累积效应

  有些测试人员在压力测试中喜欢让整个系统重启(如服务器reboot),以确保后续的测试能在一个“干净”的环境中进行。这样确实有利于问题的分析,但不是一个好的习惯,因为这样往往会忽略掉累积效应,使得一些缺陷无法被发现。有些问题的表现并不明显,但日积月累会造成严重问题,特别是服务器端的压力测试。例如某进程每次调用时申请占用的内存在运行完毕时并没有完全释放,平常的测试中无法发现,但终可能导致系统的崩溃。