以外行人的眼光谈压力测试[2]

         以外行人的眼光谈压力测试[2]   软件测试工具

　　分析压力测试结果

　　这步同样是压力测试中很难的一步，在这一步需要做出的根据压力测试的结果分析出系统的具体表现情况，判定系统是否能够满足压力指标。

　　以loadrunner产生的分析结果图而言，通常需要分析以下图：

　　1、Total Transactions per Second

　　这张图中显示了系统在进行压力测试过程的TPS的变化情况，从这张图中我们可以看到系统的TPS的情况，通常来讲，随着用户数的增加，TPS应该是呈一定比率的增长的，等增长到一定程度后会达到瓶颈，甚至开始下降，这也是TPS的瓶颈值了，这张图可以帮助我们评估系统的TPS是否符合要求。

　　另外，在这张图中，我们可以看到系统从什么时候开始出现出错的transactions，从而判断出错率是否在可接受的范围。

　　2、Transaction Response Time Under Load

　　这张图非常的重要，借助这张图我们可以分析随着用户数增加的情况下，系统的劣化状况，最佳状况当然是一条直线，但这基本是不可能的，毕竟资源是有限的，需要判断的是劣化的程度是否为可接受范畴。

　　另外就是需要关注数据中90%的用户的响应时间的状况，如果少量用户响应慢是可接受的话，那么有可能在之上指标不达标的情况下仍然满足了压力指标。

　　3、Unix Resources    软件测试

　　这张系统load图自然是非常的重要，借助这张图大致可以判断系统随着用户数的增长消耗的资源的变化情况，这对于调优以及容量规划而言是很重要的，但还是得取决于应用本身。

　　loadrunner还提供了其他方面很多的图，可以根据考评的要求来自行进行分析。

　　寻找瓶颈并进行调优以达到目标

　　这步不属于压力测试范畴，但还是在这里稍微讲讲，毕竟压力测试结束后如果系统没达标的话就必须进行这步了。寻找瓶颈，这自然是非常难的事了，通常系统达不到要求的状况都会是随着用户的增长，响应时间劣化的过于厉害，在这样的情况下首先得观察系统硬件资源的变化情况，如果是硬件资源耗尽的话，需要查查为什么资源被耗尽，假设最后判断确实需要耗费这么多的硬件资源的话，也许需要考虑增加硬件资源或是水平扩展，否则的话可能需要从软件层面相应的优化系统了，这样的话可以进入下一步了。

　　如果不是硬件资源的限制的话，得在系统中从头到尾设置时间跟踪filter，从而判断响应时间劣化的原因，看看是系统中哪些步骤造成的，这个是细致活了，有可能要查非常久。

　　其实这里说的还是相当的简单了，在寻找瓶颈的过程中是个非常繁琐的过程，需要不断的尝试，硬件的增加、OS的调优、jvm的调优以及软件系统本身的调优等等，这些很多时候需要的是经验，因此某知名人士曾经说过如何寻找瓶颈和调优，其中依靠的一点就是直觉。

　　当然，在寻找瓶颈的过程中，可以借助os的工具、java的工具(例如gc打印、jprofiler等)来进行查找。

　　(ps: 不过感觉很多情况下都是应用本身造成的性能瓶颈，在写程序时稍不注意用错一个数据结构都有可能会导致比较大的问题，所以我现在查找瓶颈的时候更多的还是先从软件本身下手，只是软件性能要做到提升通常来付出较大的代价，这个时候需要权衡)

　　调优基本上要求对硬件、OS、JDK、数据库甚至软件的实现方式等都要有非常深入的理解，至少要能做到判断出瓶颈因素，然后找相应领域的专家来解决，因此要求是非常高的。

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