压力负载测试的经验

压力负载测试的一些经验之谈

　　接触LR有些时间了，也做过几个大型政府OA的测试，一直有一些想法想法和大家交流。

　　LR做压力负载是一个很少的工具，目前在世界上的市场份额也是最多的，大约在70%左右，次之的是QA_load。

　　压力负载测试最重要的是环境的配置，一定要模拟真实的环境，否则得出的结果会和真实情况有很大的出入。

　　比如数据库查询时，库里的数据一定要多，也就是所说的大数据量测试。

　　环境配置根据不同的系统存在很大差异，但是也有一定的规律可循，或者说一般也有一些通用的原则：

　　1、并发用户数一般是在线用户数的2%~3%，需要注意的是使用用户数、在线用户数和并发用户数的却别；

　　2、事务响应时间：3秒之内（非常好）、3-5秒（一般）、5-8秒（免强接受）、8秒以内（用户不能接受），一般都遵循3、5、8原则；

　　3、每秒事务数：80%的事务在20%的时间内完成（一年安160天算，一天8小时算），一般遵循80-20原则；

　　4、服务器在受压情况下，cpu最佳占用率为60%~80%，多了cpu受不了，少了资源浪费；

　　5、服务器在不受压情况下，内存占用率最佳为25%，多了影响服务器性能；

　　压力负载测试中也需要注意：

　　1、注意区别内存泄露和动态内存分配问题；

　　2、注意压力端和服务器端的网络流量，一般来说目前的网络不会是系统的瓶颈，但是也需要注意；

　　3、单机的压力用户数不要过多，否则会影响测试结果，最好不要超过300；

　　4、分不同的组来运行不同的事务脚本，应真实的模拟系统情况；

　　1）动态内存分配和内存泄漏为什么要提出来区别？我觉得这两个不容易混淆。

　　2）目前对于内网来说确实象你说的那样，但是有很多性能测试涉及到公网，所以这个还是要分开来对待

　　另外系统性能的标准，我也发现很多新手问这个，你给的规格不错。不过还是要结合实际的情况分析，比如需求中有明确提到的。

　　内存泄露是指内存申请后没有释放，倒是内存占用量不断增加，最后导致系统崩溃。

　　动态内存分配存在问题，一般指系统随访问量（或者其他）上升，系统地内存消耗量也上升，而且系统没有限定内存的申请量（或者使用量）（一般来说都要做限定），最后导致系统内存不足而崩溃。

　　我之所以强调其区别，是因为用LR做压力测试所表现的症状很相见，都是服务器无响应。

　　我个人认为，一般的，如果LR加压后半小时内内存还没有释放干净，可怀疑是内存泄露。

　　当然，一切都不决定，很多都要联系系统来分析。

　　做压力负载测试时，我也是分不清楚内存泄露和动态内存分配，特别是linux操作系统，根据观察，linux启动后，不进行什么操作，内存也是在不断减少的，这都是动态内存分配的原因，所以在做压力负载测试时，我不知道内存减少是因为内存泄露还是动态内存分配，这两者的表现都是系统内存在不断减少。

　　我看是否有内存泄漏的时候是这样做的：记录大并发开始前和结束后的差值，然后再记录不做压力的时候相同时间内的内存差值，两者作对比，如果很大的话就认为有内存泄漏。不知道这样对不对？

　　事务响应时间,每秒事务数指的一个用户数还是虚拟用户总数呢

　　2、8原则是不错，5秒是操作忍受的临界点也好；

　　只是“并发用户数一般是在线用户数的2%~3%”，是如何有此根据的？

　　状态 离线  每秒事务数是根据实际情况统计出来的，然后再确定压力测试的方法和虚拟用户数，比如一天有多少人订飞机票，然后除以时间，得出每秒事务数。

　　至于并发用户数一般是在线用户数的2%~3%，这也只是一个经验之谈，实际情况要实际分析。这个数据是信息产业部的软件评测中心的人告诉我的。我在实际测试中也是按这个来测试的。

　　个人认为这个经验公式要根据不同的业务来定制。

　　在向系统加压过程中，如果系统的内存没有泄露，那么当压力一定时，内存的使用率应该大致维持在一定的范围内。如果内存有泄露，那么随着时间的增加，内存使用应该越来越高；当然比如一次操作内存泄露不大，那么就需要运行大量的时间才能看出来。所以个人认为，应该把检查内存泄露放在单元测试中进行，而不在进行性能测试的过程中去检查这点。

　　以前在作嵌入式开发中，检查内存的方式是：执行一次操作（或者流程）前，检查系统的内存数，执行一次操作后，再次检查系统的内存数，如果没有内存泄露，那么两次的内存数是相同的，如果有泄露，还可以知道泄露多少个字节。当然可以这么做前提是该系统提供了类似的一些命令。