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