计划误解
性能测试经常认为应该放在项目开发最后阶段，即在项目推出之前，我们也许需要做一些微调保证一切顺利。这也是为什么性能测试被视为是性能问题的解决方案。但实际上，它应在性能优化的基础上去检测和预测问题。如果只在项目结尾考虑做性能测试，当遇到非常严重的问题，这会带来更多的成本。
所以，为了保持较低成本，最好在开发早期考虑性能。我们应该在整个开发周期间执行测试，在这些严重问题导致项目失去控制之前检测出。
只需要添加更多的硬件的误解
典型的看法是性能测试是不必要的，因为任何发现的问题都可以通过简单的添加更多的硬件来解决，例如额外的服务器，内存等，这种做法相当错误。如内存泄漏情况，假如增加更多的内存，可能保证服务器运行时长从原来的三个小时增加到五个小时，但这并没有解决问题。除了增加基础设施成本，这没有任何意义，减少长时间稳定运行的固定成本更加有效。
总之，添加硬件不是替代性能测试的好主意。相反，我们应该找到问题的根源，并找到一个真正的解决方案，而不是一个补丁。
测试环境误解
这里还有另外一个硬件错误断言，即我们可以在一个与实际生产环境不相同的环境下进行性能测试，比如，在windows上测试一个端程序，就假设该端程序安装在Linux下也能正常工作。但因为有许多环境因素会影响系统的性能，比如硬件组件、系统配置和同时运行的第三方应用，所以必须确保在一个与生产环境尽可能相同的环境下进行测试。
即使数据库是性能测试环境的一个重要方面，有人仍认为性能测试可以使用测试数据库，从而导致SQL查询问题可能被忽视。这样做的结果是，如果数据库存在成千上万条记录后，SQL语句响应时间在没有被优化的情况下必将带来严重的问题。
对比误解
使用一个与生成环境不同的性能测试环境进行性能测试，另一个环境依据该测试结果做出结论。绝不应该这样推断任何结果。比如，你不应该认为双倍的服务器就是双倍的运行速度，也不能认为简单的增加内存就能增加用户支持数。在通常情况下，有许多因素对整体性能产生影响。链条断裂的最薄弱环节，如果只提高其中两个或三个环节，剩余的部分仍将是瓶颈。简单来说，如果改善了影响性能的一些因素，那么瓶颈将转移到另外的因素上。唯一的办法是在测试性能时，确保一切都是正常运转的。
在另一个方向上去推测结论是无效的。假设一个应用场景，一千个用户能够在AS/400下完美运行。我们不能想当然的假设出支持10个用户运行的最小硬件配置，必须通过测试验证。
完全测试误解
认为性能测试将防止所有问题，这本身来说就是一个问题。关于性能测试，必须检测出将会产生最大负面影响的危险问题。基于时间和资源的限制，应该限制测试用例的数量（通常不超过15个），因为进行性能测试成本非常昂贵，它涵盖了所有功能，替代流程、数据等。
覆盖最可能出现也最有风险的情况。每当一个问题检测出，应该尝试应用解决方案到每一个可能会导致类似影响的系统组成部分。例如，如果发现测试的功能在数据库连接上管理不当，那么一旦找到解决方案，应将应用到每一个涉及连接的点上。解决方案通常是全局的，如线程池的配置大小，或JVM分配的内存。
另一种证明可靠有效的途径是，在生产条件下监控系统的性能以便性能测试。因在测试范围之外，我们能检测到任何可能出现的问题，以便及时纠正。记住，仅跑一个性能测试并不意味着你能清楚任何可能出现的问题，所以需要几种方法去确保最大化的降低风险。
相邻误解
倾向性的认为应用程序在其它情况下使用没有任何问题，那么我们自己使用时也不会引起任何问题。为什么要进行性能测试，当其它使用相同的产品也工作的很好?
当系统运行在一个给定的用户负载下，我们必须去调试它，调试平台，确保配置的各个部分正确，并考虑影响使用其它系统以及用户的其它因素。
过度自信误解
这里有个信条，认为系统问题只有在经常犯错和缺乏经验的程序员才会碰到，包括其它的一些事情。一些项目管理者认为他们的工程师非常有经验，不需要测试性能，特别是之前已经开发出的大规模系统也没有出现任何问题。
不应该忘记编程是一个复杂的活动，不管我们如何有经验，犯错误都是很常见的。更真实的情况是，开发的系统经常暴露出多并发问题（这是最常见到的情况），而且性能会被各种不同的变量所影响。在这种情况下，必须考虑环境、平台、虚拟机、共享资源、硬件故障等。
这些只是我作为一个专业软件测试员的职业生涯中碰到的误解。你能想到其它你不得不劝阻人们相信的误解？
本文翻译自Sofía Palamarchuk的《7 Performance Testing Fallacies Undermining Your Test Strategy》一文。