性能测试这件事儿该怎么聊？

性能测试释义<来自百度>

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
负载测试和压力测试都属于性能测试，两者可以结合进行。通过负测试，确定在各种工作负载下系统的性能，
目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者
不能接受的性能点，来获得系统能提供的最大服务级别的测试。

性能测试，需要做什么

从事测试工作已经有好些年头了，早在2012年的时候就开始接触性能测试工具loadrunner，
也知道测试还有这么一件事儿叫性能测试，从此一个人开始抱着书、不停地反复练习使用工具，
同时还查阅其他资料，慢慢的脑子里便堆积许多有关于性能的理论，而且比较乱还无法整理，
这个源头主要来自于心中所学无用武之地的困惑；无法得到有效印证，你知道这是一件多么无助的事情吗？
工作至今，据不完全有效统计：真正意义上做过的性能测试一双手都能数清，那为什么很多用人单位都有这个招聘需求呢？
行业里头也是趋之若鹜！或许是想起有用的时候能用得上吧，不至无人可用于做性能测试！

• 前面说过因无人带领自己做性能测试，无法证明自己所学的性能测试行为是否正确，那么其中就有一次机会去到公司总部，跟着龙哥学习了一把，从而侧面的印证自己所学的东西基本正确<不仅是对工具的正确使用及场景设计>，也算是一次答疑解惑，直到N年后，我仍然会请教龙哥性能测试方面的问题。
• 记得在G市工作的5年里大约做过4-5场性能测试，每次都是持续一周或者更久，其他那种小场次的基本是随便跑跑，再写个性能测试报告用于项目验收；而真正的性能测试都是一次测试技术的提升，虽然中间可能需要无数次去查阅资料，且无数次结果验证，也确实提升了自己！

记一次在G市某次性能测试到达客户现场，那可是大家伙，机房面积目测占地200平，在到达现场之前，根据业务方场景描述，
已经提前在公司开发好脚本并且设计好场景，到现场只要替换参数就可以愉快的跑起来了；到这个过程是愉快的；
但是在结果分析的时候，就需要考验个人能力的时候了，非常不巧的是，那时我还是个菜鸟，不懂如何专业分析且令人信服；
只能大致对压测结果进行简单描述，例如：多少用户并发，在某刻出现了请求错误，并且平均响应时间大于期望值等等，
然后开发就一股脑的优化代码<不知道有没有调整jvm参数、sql建立索引>，调整Weblogic连接池配置等；
又是一轮压测，结果仍旧差强人意，开发的同学一度怀疑是我脚本设计的问题，无奈的我只能先向总部申请资源；
龙哥来了，是我强力后盾，最后的结果龙哥告诉我：你要自信，相信自己的脚本开发、场景设计是没问题的！
开发有时候也不见得懂性能测试是怎么回事，也无法给出一个合理的优化建议，最后这场性能测试经验也变得草草收尾。

• 那么在性能测试中，测试人员都干了什么呢？其实大多数还是严格按照通用的性能测试流程执行的：

第一：性能需求分析
    一则来源于<性能需求规格说明书>，现在一般都见不到这种有明确性能需求的文档了；
    当然，也不能完全依照这个需求来做，还是需要具体业务具体分析:
    a>要分析性能测试指标<期望值>的合理性,例如：要求多个接口请求的响应时间达到一个接口的响应时间？
      10个接口和1个接口在相同并发用户的前提下响应时间一样，excuse me！?
    b>一般来说，存在并发性能问题的地方，一定是核心业务，所以要有针对性的选择性能压测目标;
    c>如果有意外呢？那就是程序设计问题，某个其他非核心业务也会引起性能问题。
    二则就需要团队协作，通过线上监控线上数据反映并分析出核心业务场景的性能指标；

第二：脚本开发<这里就要与性能测试环境搭建、性能测试数据的准备工作同时进行>
    你可以在其他环境调试脚本、但是最终的性能压测环境一定要独立于测试环境<一般的公司都是不提供这个条件的>
    最好的性能测试环境从配置和数据量来估算，建议是等比缩放，尽管可能得到的也只是一个理论值；
    开发性能测试脚本的依据来源于性能测试用例，等同于我们的功能测试用例。
    
第三：这里插播一条：优化脚本
    这里引申出一个问题，我们老是在汇报工作的时候说自己完善、优化脚本，那么我们到底对脚本做了什么？
    难道不应该是在开发脚本的时候考虑进去的吗？
    a>优化脚本也是一个不断调试的过程，例如需要参数化、删减一些不必要的接口请求<尤其是录制的脚本>，
    b>再有就是需要还原真实的用户场景，达到一定效果<响应超时、服务器崩溃>，需要适当设置思考时间、线程数等；
    c>这样做的目的是:最大限度的排除在压测过程中由于脚本本身导致的性能问题，不要让脚本及不合理的场景设计成为你的性能瓶颈！

第四：设计执行场景及资源监控
    这个工作就显得颇为复杂，因为我们对性能测试结果分析，并不一定要完全的等执行完脚本，出了结果再进行分析，
    而是在执行过程中就要进行一定的分析，例如：实时监控系统资源就能发现许多性能问题；
    同时还需要监控到应用服务，通过系统健康状态反馈排查应用问题；这里不得不提的是对linux系统的熟悉，
    尤其是linux监控系统命令的操作，切记不要过份依赖监控平台。

第五：来吧，结果出来了，我们开始重头戏
    插句话：一切不以性能测试结果分析为导向的性能测试都是耍流氓！
    近段时间正在做性能测试，有时候也为了更好的完成这次性能测试工作，也查找了许多资料，看过许多书；
    通过测试活动过程进行验证，定位出系统、应用瓶颈等性能问题；其中不乏一些关于性能测试的相关书籍；
    这里需要给一些想要做性能测试的同学建议：买书入门可以，但是不要寄希望于书籍，它是不会告诉你如何才能成长为高级性能测试工程师的！
    《零成本实现性能测试--基于某工具》、《精通软件性能实战--某工具》等等，前面%80的章节都是关于如何使用工具的；
    不可否认的是：熟练的使用工具是能设计出更符合真实性能的业务场景，工欲善其事必先利其器，这句话总归是不会错；

第六：这时候，我们要回顾这个性能测试过程
    前面我没说流程中的《性能测试方案》《性能测试类型》《如何设计性能测试用例》《如何编写性能测试报告》
    《如何进行性能调优》等等事件，给自己圆个谎：
    你知道一本书为什么讲不清性能测试吗？
    你知道线上培训的课程除了收费的<性能测试课程>都不深入讲解性能测试吗？
    你知道为什么网上有很多材料都没有完全讲明白性能调优吗？
    答案就是套路，流程是套路、方案设计是套路，结果分析还是套路，只看是谁在使用套路。

只要玩得深，套路得人心

看吧，我们为了匆匆应付一场性能测试，就要反复查阅资料，不断充实自己；然后时间一过就又回到起点；
毕竟我们不是在一个专职的性能测试岗，就像写代码，隔一段时间不写，很多api都会忘得干干净净，甚至连理论都不记得。

• 性能测试中最严重的套路就是性能结果分析，为什么呢？

分析图表，什么样的性能数据反映出当前的系统性能结果，通过找拐点、合并资源图、分析数据等套路，得出的结果仍旧是套路；
当然不是说套路不对，恰恰相反，会给我们节省很多精力，更加快速的定位性能瓶颈；当然也会存在超出套路以外的情况，就是意外！

• 性能测试的基础就是理论知识的储备<拒绝纸上谈兵>

性能测试类型
性能测试指标
性能测试工具
性能测试文档

• 做性能测试，要有两个自信！！！

第一要坚信：我们设计的脚本及执行场景是正确的！<这也是为甚在做性能测试的时候，需要有性能测试方案及性能测试用例的评审>
第二要坚信：我们分析的性能测试结果是正确的！<因为同样的环境下，任谁来执行，得出的结果都是一样的，除非是找到真正影响性能的根源>

最后说一下性能测试这个团队

• 如果不是专职专岗的性能测试工程师团队，一个人是做不到整场的性能调优，所以更多时候做性能测试是一个团队的事情，有测试、开发、运维、DBA、项目经理、业务方等；
• 所以要清楚自己的定位，我们在性能测试过程中发挥什么作用

基本技能：性能测试流程都会走<按套路来>
入门初级一点只需要通过执行得到结果并描述产出性能测试报告；
再往上就需要懂得套路去分析得到性能瓶颈并给出调优建议；
若是能力出众，权限放开都可以一个人完成整个过程都不带停歇的。

• 说再多一点，无论你看了多少书或视频，都不如亲自动手实战一遍来得实惠！<性能测试>本身就是一个不断积累的过程，共勉！