关于性能测试，我觉得现在很多情况下，很多人误解了它存在的意义。

　　刚才和kernzhang聊天，说到性能测试调优的问题。

　　性能测试来说，调优，我想是很重要的一块。

　　而如果在现有架构的基础上调优。

　　只能说是牺牲这个得到那个。

　　不可能兼而得之。

　　于是我写了一段自己对性能测试的理解，记录下来：

　　有一个误区是，很多人把性能测试看成是找到系统性能Bug的途径，而对性能测试来说，我认为找到应用程序或者数据库等的Bug，是性能测试中不得已而为之的一部分。

　　我们做测试知道，测试什么，应该有一个预期的结果。而在实际性能测试的过程中，写场景或者用例的时候，很多时候我发现很多人都没有考虑这一点。换句话说，有很多人并不知道预期是什么。

　　从而让找Bug成了性能测试的一项重要的工作。

　　拿一个简单的比方来说：我希某个应用在现有的硬件和架构下达到，每秒处理1000笔业务。而我们测试中发现，只能处理500笔。那么哪里消耗了时间。我们找到了后，发现是某个语句的循环消耗了不应该消耗的时间。

　　那么这个问题，是我们性能测试找到的。但是这是我们的目的吗?我认为，这只是性能测试的一个份量比较小的目的。

　　那我再从配置测试上来说，如果排除代码的效率(此效率应该是性能的一部分，不过应该在前期的白盒测试中去做)。我们能做的是把现有的配置，搞清楚，然后用消耗其中的一种资源，而得到其他资源的充分利用，或者响应时间的提升。即，我们已经没有办法把性能提高到特别好的层次上了。因为架构和硬件已经决定了。

　　而有时我们做稳定性测试的时候，发现有些应用在长时间的压力下出现了各种各样的问题。比如连接没有释放。这样的问题又回到了上面的找BUG的说法上。所以配置测试是调优的很重要的部分。

　　比如，我们可能会增加JVM或者连接数来达到比较好的性能，

　　而让系统充分利用硬件的多余资源。


　　再说一下群集的测试。

　　我们知道，群集的测试和只有一个web application server和一个DB server的两层应用、或者是再加一个中间件的三层应用不同。在这里，我们还要考虑的是当其中的一个结点down掉的时候，其他结点是不是能够快速的接管服务并提供正确的服务。我们知道有些群集应用，用内存镜像来做的，这个的问题是，可能在内存中出现的问题，会同步到其他的结点上，从而所有的结点都会有问题。

　　当然也有厂商提供了更好的群集方案和硬件配置。我们做这样的测试和一般的性能测试不同的是，模拟某个结点出现问题，而其他结点要多久才能接管服务。是不是在用户感觉不到的情况下，已经接管了?这里我们要监控的东西更多了。要分析的东西也更多了。
我要说的做性能测试希望做到的，是让整个应用在现有的配置和架构下，达到好的效率，以提供优的服务。而不要把性能测试理解到其他的用途上去。

　　先写这些吧，可能有些散乱或者不对的地方，请指正。