本文主要是介绍性能测试新手常犯错误总结（一）：找不到测试点，不知为何而测，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
有过一些性能测试经验的人很容易进入此状态，他们已经熟悉了性能测试的基本流程，能够比较熟练的使用测试工具开展工作。我大概从事性能测试一年左右时遇到了这个问题，那时我觉得性能测试的过程没有太多挑战，遇到的每一个系统，仿佛都可以用同样的流程完成。半天时间填写测试方案，一天时间来准备测试环境，一天时间准备测试脚本，一到两天来完成各种测试用例（基准测试、日常压力测试、峰值压力测试、绝对并发测试、稳定性测试等），然后就是调优、问题复测和完成测试报告。在我看来，性能测试好像变成了用一些工具去执行一个个固定的用例。
这样的工作持续了一段时间后，我感到有些不对劲，一定是哪里出了问题。性能测试难道真的这么简单，简单到把任何一个系统套入标准的流程中就可以了？于是我开始思考测试的意义，为什么要进行性能测试？是因为性能测试可以提供关于瓶颈、缺陷、效率等等我们认为有价值的信息。那仅仅通过一个工具，或者是一个固定的流程，就可以发现不同系统的这些信息么？这显然是不可能的。
我开始尝试尽量深入的去理解被测系统，这个系统的目的是什么，用户是如何使用系统的，用户对哪些业务的性能比较敏感，系统的一些关键业务实现逻辑是怎么样的，从设计实现的角度来看哪些业务的性能可能存在隐患。这些很少是技术层面上的问题，需要做的只是思考，再深入思考。慢慢的我有了些收获，开始了解为什么要测这个系统，针对这个特定的系统哪些内容是最重要的，为了获得需要的信息我需要从哪几个方面进行测试，为了实现我的想法又需要哪几种方法或者工具。（现在我的性能测试过程中，用于理解被测系统、理解用户、整理测试思路的时间投入大大增加了。你呢，投入了多大比例？）
要做好这些其实很难，每一个被测系统对我来说，仿佛就变成了一个新的挑战。但是逐渐的我发现自己思考问题更全面了、可以更快的抓住系统的重点、找到更重要的BUG、对系统的实际性能有了更准确的评估。这里提一个简单的问题，如何确保你的测试结果和生产环境的性能表现是一致的，也就是说测试结果能够真正的反应实际的性能，而不仅仅是代表了你选取的几个测试场景的性能。话说起来比较绕，但是请认真想一想，你有多大的把握呢？
上面只是写了一些个人的感想，我觉得如果在“思想”上没有办法上到一个新的台阶，你的性能测试生涯可能也就达到“瓶颈”了。如何突破这个瓶颈，那就需要努力改变自身，多思考多学习，最核心的能力。一定会有一些人认为性能测试的重点在于“技术”上，于是他们不断的记住各种调优配置参数，以为自己掌握了性能的精髓，仿佛什么系统到了他们手上，只要改几个参数就会出现奇迹。我也经历了这个阶段，也有过几次自以为挺高明的调优经历，也为自己会各种中间件数据库的配置调优而有些小得意。
但现在想想，那还真是一个比较低的层次，思想上抓不住重点、看不全大局，技术上其实也只是一点皮毛。面对这类人，只要问几个为什么就会让他们无法回答，为什么要调优？为什么要调这个参数？如何证明这次调整的效果？
将上文简单的总结成几点，希望能给性能测试新手提供一丁点的帮助吧：
1、性能测试的难点在于对被测系统的理解，在于对测试点的分析。为了实现测试的思想，可以有多种方法，手段永远只是辅助的，只有思想才是根本的。工具（如LR）更不等于性能测试，不要以为会用LR就懂了性能测试，那只是最低级的测试执行。也不要以为会调几个参数就懂了性能测试，那同样是个比较低的层次。
2、调优等技术不是性能测试的主要目的，好的性能也不是调出来的。测试人员一定要明白自己存在的价值所在，所谓的“技术”只是为了达成自己测试目的的一些手段，同开发人员、DBA相比，你在这些技术上永远是外行。
3、不要照着文档模板，填入测试方案。每一个系统都是不同的，要真正的认识到这一点，为每个系统设计出有针对性的测试方案。思考你每一步工作的意义和目的。
4、如何证明测试结果的有效性，其实是个很难的问题，值得花费时间去认真思考。这个过程涉及到一些很重要的内容，如用户模型的建立，后续会有专门的文章。
5、性能测试是一个需要不断改进的过程，每一次只需尽量的做到更好，多做一点点以前没有想到的东西。经过不断的积累，你会发现自己对性能测试有了更深的认识。
这篇关于性能测试新手常犯错误总结（一）：找不到测试点，不知为何而测的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
