性能曲线分析的一点技巧

fairyox · 发表于 2012-6-27 09:11:58

大多数软件测试人员在性能测试入门的时候最头疼的事不是软件性能需求调研和使用各种复杂的性能测试工具，而是面对被监控出来的一堆性能测试曲线却不知从何下手开始分析。笔者前一段时间在做性能测试的时候遇到了一些诡异的情况，在考虑如何从错综复杂的曲线中找到瓶颈的蛛丝马迹的过程中有了一点点感悟，拿出来和大家分享。其中深入的理解我们所监控的所有性能指标自不必说，做任何性能曲线分析的前提都是要理解这些性能指标的含义，网上一搜一大堆我就不再废话了。说说指标分析入门时可以遵循的两个步骤。

性能测试中所监控的所有性能指标可以分为两类，分别是现象指标和原因指标。这就是要做的第一件事，根据实际情况将现象指标和原因指标分离。

现象指标是指通过指标可以看出软件的性能是否有瓶颈，也就是它表现出一种现象，告诉测试人员正常或者不正常，这种指标通常的特点是和软件本身的表现相关较大，具体说来就是用户能够直接感受到的那些指标，最典型的就是TPS、正确率、响应时间和his per second这类指标。通常一个软件的性能是否符合需求最先要通过他们的表现进行评价。

原因指标是指它本身只能从侧面来衡量一个软件是否达到性能指标，有时候甚至不能够用来明确的衡量一个软件的性能是否符合需求，在业界使用一些经验来确定这些指标的阀值以达到在性能测试时存在一个通过标准的目的。大多数的硬件指标都符合这一特点。比如CPU，它的高低本身是不能够衡量一个软件的性能表现的。就算CPU达到90%，只要TPS够高，响应时间够快，用户是感受不到软件的性能有缺陷的，这就像一个软件在运行过程中产生了一个异常，但在界面上来看该做的事情都做了，对用户来说是感受不到软件已经有问题了。业界通常给CPU一个阀值来衡量在性能测试过程中该指标是否通过的标准，一般在70%到85%之间（通常更偏向于70%）。而这个阀值并不能说明用户对软件性能的感受，它能够说明的是软件的瓶颈很可能是计算，如果未来用户对软件性能的需求提高，那计算就会成为阻碍用户体验的短板，所以优化软件要从软件计算复杂度的角度来思考。

这两类指标并没有严格的划分，在性能瓶颈分析的过程中，很可能原因指标会作为现象指标，分析这个指标为什么不正常。其实这通常也可以说是深一层的瓶颈分析。还是上面提到的CPU，当发现软件的瓶颈来自于计算的时候，又如何确认是哪里的计算过于复杂或者有死循环等问题导致了CPU过高呢？这个时候CPU就变成了现象指标，需要找到导致它过高的原因指标，当然这一层有时候是找不到的，因为原因并不一定非要是哪一个指标能够表达出来的。

有一点需要声明的是，虽说原因指标能够指出系统瓶颈的所在，或者排除一些系统瓶颈的所在，但并不是优化一定要在原因指标上入手。比如减少不必要的请求，优化业务流程或者把业务流程分解（《测试之美》中有相关案例）都是优化的方法。这也说明软件性能的优化未必一定要从代码或者数据库入手，有时候全盘考虑可能会有新的突破口。

上面所说的是两种指标的划分，初期可能会稍微有点困难，但可以根据他们的特点进行分析，对于新手来说只要明白了指标的含义，在根据实际测试情况分清楚并不是一件很困难的事情。在分出了现象指标和原因指标后，就可以进行第二步，系统瓶颈分析。

如果有足够的经验，第六感就可以告诉性能测试人员瓶颈在哪里，这不需要解释，所有的性能测试人员都深有感触。对于经验尚浅的性能测试人员可以采用一个笨方法，就是拿现象指标的曲线和所有监控到的原因指标的曲线进行对比，找到和它的趋势相同的或者相悖的，然后在被找到的曲线中进行对比分析。能够确定的是，除非是巧合（在性能测试中趋势相似或相悖又没有关系的巧合几乎没有），不然所找到的所有原因曲线必然与系统瓶颈直接或间接的相关，在很大程度上缩小了需要分析的范围。

至于在所过滤出的曲线中如何再进行分析，那就要看悟性了，至少目前笔者还没有想到可以遵循的规律或者易于掌握的方法。