使用LoadRunner不容易解决的问题(2)

　　场景是把虚拟用户和交易数按一定规则组织起来去模拟真实世界的业务行为。这其实是把单个用户的行为复制，连接。场景的组织通常和真实世界的业务规则有很大关系。

　　做个如下可能并不恰当的比喻：

　　脚本像演员，场景就像表演的舞台，而测试工程师是导演，多少个演员，怎么在舞台上演出，都由导演说了算，而剧情又不能离谱，脱离现实，否则就要砸锅了。注意，导演的职责不光是确保演出能顺利结束，而且还要同时观察和收集观众的反馈信息，以确认这次演出是否成功。

　　同样的也是，性能测试人员不光是看场景是否得到顺利的执行，同时还要收集各个server的反馈信息，以确认软件系统的性能表现是否正常。

　　在真实世界中的用户业务规则要转换到可操作的性能指标是需要分析和计算的。当然这通常是市场需求分析人员干的活，但我觉得测试人员应该在做性能测试时，对这些指标进行理解，知道为什么要这样做。有时有的性能指标并不清楚和准确，还需要测试人员来分析。比如一个性能指标：要求软件系统支持每分钟700用户的登陆行为。这对于测试人员来说，其实是一个不确切的性能需求。这指的是瞬时并发用户700，在一分钟的响应时间要求下登陆系统?还是在一分钟内陆续有700个用户登入软件系统即可?这两种场景其实对软件系统的压力是不同的，第一种显然大，第二种要小一些。甚至有的性能需求就是支持50000注册用户，这种需求就更需要分析了，还要引入一些业务发生概率算法模型来做。这已经不是性能测试人员的职责了，但由于目前有不少软件公司流程不规范，或者有流程没执行，这些工作都要测试人员来做了，不过也好，正好是锻炼的机会。

　　四.分析结果数据，找到软件系统性能瓶颈

　　上面说了，做了那么多，就是为了本步骤-寻找软件系统性能瓶颈。

　　个人认为寻找性能瓶颈是一个非常有挑战性的工作，毛主席曾经说过：一个优秀的指战员就是能够根据已有的客观形势，制定作战计划，然后在作战过程中，发现计划与执行不符的地方，分析，然后调整作战计划，缩小计划和战势的误差。简明一句：就是一个理论和实践结合的过程，一个人的主观思想和客观现实的结合过程(注明：本人是毛主席老人家的忠实fans)。

　　在性能测试中，测试方案就是我们的作战计划，执行性能测试就是我们的作战战场。在性能测试中，可能会发现种种意想不到的问题。当然一个经验足够丰富的性能测试专家可能会在测试之前就能考虑全面，使测试方案吻合测试执行实际情况，并一举找出性能瓶颈。我sunshinelius不是专家水平，当然就要匆忙应对和分析性能测试中出现的问题，并有可能会修改测试方案，增加必要的test case，删除没用的test case。总之，性能测试是一个不断修改测试方案，反复执行test case的过程，直至越来越逼近性能瓶颈。在此过程中，需要了解很多的知识，知识了解得越多，就越接近软件系统运行的真相，也就能找出性能瓶颈了。

　　比如：loadrunner要是调用程序员的程序，服务器资源占用情况可能是追查瓶颈的一个线索，但如果是标准中间件，那就没那么简单了，比如oracle数据库的某项参数设得不对，照样会造成数据库瓶颈，应用程序调用数据库的API写法不对，比如未使用软解析变量，也有可能导致数据库瓶颈。这些瓶颈都不会反映在cpu，内存使用量上等指标上的。

　　对于这种情况，一方面需要对中间件有一定的了解，知道哪些参数有什么作用，怎么可调的，另外还可能使用中间件的专有监测工具，来分析。lr的性能计数器是不够用的。

　　个人体会，查找瓶颈的难易程度，由易到难

　　服务器硬件瓶颈-〉网络瓶颈-〉应用瓶颈-〉服务器操作系统瓶颈(参数配置)-〉中间件瓶颈(参数配置，数据库，web服务器等)

　　记忆比较深刻的一次，用lr做了两天性能测试，指标上不去，后来使用oracle数据库的图形化性能检测工具才发现某个表的查询处理时间超长，原来索引创建得不合理，把表的索引改了之后，性能稍有提高，但还是上不去。再次排查，发现应用中有一个sql语句写得有问题，长而且耗时，改了之后，测试指标还是上不去

　　经过至少四轮的排查，才大功告成，最后一个除掉的瓶颈是操作系统问题(开始没有想到它，后来看系统消息，才发现已经有错误报出)

　　五.我再说两句

　　每个系统的性能测试都是一个全新的挑战!

原文转自：http://www.ltesting.net