我觉得现在很多情况下，很多人误解了它存在的意义。
刚才和kernzhang聊天，说到性能测试调优的问题。
性能测试来说，调优，我想是很重要的一块。
而如果在现有架构的基础上调优。
只能说是牺牲这个得到那个。
不可能兼而得之。
于是我写了一段自己对性能测试的理解，记录下来：
有一个误区是，很多人把性能测试看成是找到系统性能BUG的途径，而对性能测试来说，我认为找到应用程序或者数据库等的BUG，是性能测试中不得已而为之的一部分。
我们做测试知道，测试什么，应该有一个预期的结果。而在实际性能测试的过程中，写场景或者用例的时候，很多时候我发现很多人都没有考虑这一点。换句话说，有很多人并不知道预期是什么。
从而让找BUG成了性能测试的一项重要的工作。
拿一个简单的比方来说：我希某个应用在现有的硬件和架构下达到，每秒处理1000笔业务。而我们测试中发现，只能处理500笔。那么哪里消耗了时间。我们找到了最后，发现是某个语句的循环消耗了不应该消耗的时间。
那么这个问题，是我们性能测试找到的。但是这是我们的目的吗？我认为，这只是性能测试的一个份量比较小的目的。
那我再从配置测试上来说，如果排除代码的效率（此效率应该是性能的一部分，不过应该在前期的白盒测试中去做）。我们能做的就是把现有的配置，搞清楚，然后用消耗其中的一种资源，而得到其他资源的充分利用，或者响应时间的提升。即，我们已经没有办法把性能提高到特别好的层次上了。因为架构和硬件已经决定了。
而有时我们做稳定性测试的时候，发现有些应用在长时间的压力下出现了各种各样的问题。比如连接没有释放。这样的问题又回到了上面的找BUG的说法上。所以配置测试是调优的很重要的部分。
比如，我们可能会增加JVM或者连接数来达到比较好的性能，
而让系统充分利用硬件的多余资源。
再说一下群集的测试。
我们知道，群集的测试和只有一个web application server和一个DB server的两层应用、或者是再加一个中间件的三层应用不同。在这里，我们还要考虑的是当其中的一个结点down掉的时候，其他结点是不是能够快速的接管服务并提供正确的服务。我们知道有些群集应用，用内存镜像来做的，这个的问题是，可能在内存中出现的问题，会同步到其他的结点上，从而所有的结点都会有问题。
当然也有厂商提供了更好的群集方案和硬件配置。我们做这样的测试和一般的性能测试不同的是，模拟某个结点出现问题，而其他结点要多久才能接管服务。是不是在用户感觉不到的情况下，已经接管了？这里我们要监控的东西就更多了。要分析的东西也就更多了。
我要说的做性能测试希望做到的，就是让整个应用在现有的配置和架构下，达到最好的效率，以提供最优的服务。而不要把性能测试理解到其他的用途上去。
先写这些吧，可能有些散乱或者不对的地方，请指正。
