Java性能测试的四项原则【转】

软件性能测试的实质，是从哲学的角度看问题，找出其内在联系，因果关系，形式内容关系，重叠关系等等。假如这些关系我们在分析过程中理清了，那么性能测试问题就会变得迎刃而解。

实际项目中的性能测试才有意义

使得测试工作具有针对性，而且目标会更加明确。这个原则中有三个类别的基准可以指导开发人员度量性能测试的结果，但是每一种方法都有它的优点和劣势；

微观基准

可以理解为在某一个方法或某一个组件中进行的单元性能测试。基于微观基准的测试过程中，是不能含有额外的对性能产生影响的操作，测试时间不应该计算其它无关操作。总得说来，微观基准作用是有限的，在频繁调用的方法中使用微观基准的度量方法会帮助我们检测代码的性能，如果用在不会被频繁调用的方法中是不合适的，应当考虑其它方法。

宏观基准

当我们测量应用程序性能时，应当纵览整个系统，影响应用程序性能的原因可能是多方面的，不能片面的认为性能瓶颈只会在程序本身上。

折衷基准

相比微观基准和宏观基准，一个单独功能模块的性能测试，或者一系列特定操作的性能测试被称为折衷基准。

批量，吞吐量和响应时间的测量方法

批量执行所用时间的测量方法（耗时法）

这是种简单而快速有效的方法，通过测量完成特定任务所消耗的时间来测量整体性能。但是需要特别注意，假如所测试的应用程序中使用缓存数据技术来为了获得更好的性能表现时，多次循环使用该方法可能无法完全反应性能问题。那么可以尝试在初始状态开始时应用耗时法做一次性能的评估，然后当缓存建立后，再次尝试此方法。

吞吐量的测量方法

在一段时间内考察完成任务的数量的能力，被称为吞吐量测量方法。在测试客户服务器的应用程序时，吞吐量的测量意味着客户端发送请求到服务器是没有任何延迟的，当客户端接收到响应后，应当立即发出新的请求，直到最终结束，统计客户端完成任务的总数。这种相对理想的测试方法通常称之为“Zero-think-time”。可是通常情况下，客户端可能会有多个线程做同一件事情，吞吐量则意味着每秒钟内所有客户端的操作数，而不是测量的某一个时段内的所有操作总数。这种测量经常称为每秒事务/(TPS)，每秒请求 (RPS)，或每秒操作数 (OPS)。

响应时间的测量方法

这个很容易理解，不说了。

多变性

性能测试的第三个原则是理解测试结果如何随时间改变，即使每一次测试使用同样的数据，可能获得的结果也是不同的。

一些客观因素，比如后台运行的进程，网络的负载情况，这些都可能带来测试结果的不同，所以在测试过程中存在着一些随机性的因素。这就产生了一个问题： 当比较两次运行得到的测试结果时，它们之间的差异是由回归测试产生的，还是是随机变化而导致的呢？

我们不能简单的通过测量多次运行回归测试的平均结果来评判性能的差异。这时我们可以使用统计分析的方法，假设两种情况的平均值是一样的，然后通过概率来判断这样的假设是成立的。如果假设不成立，那么就说明有很高的概率证明平均数存在差异。