性能测试工作不尴尬，但是性能测试岗位很尴尬。
从我这里的讲述中，希望你也能看到其他测试工作的影子，希望你对“点点点”不再迷茫不再抑郁。
自己水平有限，望大家多多批评。
性能测试的工作内容
这方面的资料很多了，我也不是权威，说不全的。
大致流程：
- 和需求提出方沟通要测什么，测试的目的等，是否真正需要性能测试。讨论测试的方案是否可行，比如一个页面图片是不是可以过滤掉，单压一个接口是不是就可以了。
- 确定测试的环境，测试的人都是谁，测试的时间，同时谁来准备测试数据。
- 根据测试工具如Jmeter或者LoadRunner等等确定写脚本，调通脚本。
- 执行脚本即压测，同时观察压测的现象。压测中要自己掌握控制压测的时间和量，时间短了不行，量过大过小都不行。
- 分析压测的现象，自己能分析最好，自己分析不了就找别人分析，现象是否达标。
- 如果不达标，要定位性能瓶颈问题，这是最考验技术功力的。
- 将性能瓶颈问题的修复做回归测试。一般或者是改代码或者是改环境配置。
- 发送测试报告。
最有含金量的部分
- 第一无疑是分析压测现象和性能调优，包括环境调优。
- 第二是讨论沟通需求，不过往往实操中这一步都很水，主要是因为测试没啥话语权。
- 第三是写脚本和准备数据和准备环境（如果有）。
- 第四是执行脚本时配置的并发数等参数及其含义。
性能测试报告
实操中，测试报告往往是很水的一个环节。两种情况讨论：
- 系统性能不好还在修改中，这时候不用发测试报告，还没改好呢发什么报告浪费大家时间。
- 系统性能好了才需要发送测试报告，性能都好了啊，其实解释一下数据就行了。
那么对测试报告的核心要求很简单，就是：界面精美权威高大上。
里面的折线图重要吗？已经不重要啦，调优的时候真的重要，但出报告的这个时候这些指标我们已经不头疼不care了。
里面的数据结果集重要吗？重要，所以要醒目。
所以对测试报告，最重要的就是数据结果集展示，就那么两行结束，其他都是辅助，来证明测试报告的高大上，来证明性能测试工作的难度和工作量。
所以懂行的无论谁最关心的应该是调优，那些仅仅关心测试报告形式内容的甚至穷追不舍的一般都很low。
前期性能测试需求的沟通
网上去搜这个，肯定是一堆要点并且要有数据计算，比如全天的用户量是多少，用户的活跃时间在哪里，高峰用户量是多少，二八法则等等。
实际上这些都是很理想化的东西，真正压测起来肯定会变成：性能越高越好。
这个也是好理解的，谁都想要最好的，同时最后越过最优性能才知道系统瓶颈在哪里才能调优。
所以，懂行的无论谁最关心的应该是极限压力测试，容量测试仅仅是附属品，任何仅仅纠结于容量测试的一般都很low。
同时测试地位的局限，面对一些明显是不合理的高要求根本没有反驳的余地，答应就是了，等着现实打脸就好了。
其实也没啥讨论计算的地方，总结一下，前期的需求沟通，往往就是知道要测什么了，告诉开发预期不要太高，就这样。
例如，我曾经遇到前端每传入一批新参数就要在数据库中创建新表，就这种奇葩的架构方案还要高性能，我也是答应而已，坐等现实啪啪打脸。
性能调优的一般内容
性能调优的技术栈
简单说说性能测试的核心，性能调优包括环境调优。这里不教你怎么调优，而是聊聊调优的技术树。
以Java为例，看看调优要掌握什么：
- 底层Linux。
- 基本硬件知识，SSD和磁盘，CPU和内存知识。
- 虚拟化技术。
- 网络协议，网络基础。
- 关系型数据库，NoSQL，队列，文件服务器。
- JVM，即Java语言的特性。
- 线程和进程
- 系统架构知识
- 语言算法
- 公司业务
看到这一堆，你发现了什么？
- 我根本就没提测试工具的使用！神圣的Jmeter LoadRunner Locust等等这些哪去了？
- 和开发的技术要求基本一样，甚至包括部分运维的技术树，甚至超过开发的技术宽度。
说实话，某些开发的Jmeter用的比测试还666666，难不成技术树里我还得写上IDEA/Eclipse吗？一个工具而已。
一个性能测试没有性能调优能力会怎么样
简单暴力的就是没地位，这种技术水平的地位甚至都不如Jmeter一个软件。
- 出了问题背锅肯定有你。
- 得了荣誉大头肯定没你。
- 平时交流diss的就是你。
- 要点儿资源特别费劲。
- 学习的态度吧，人家开发忙起来了根本顾不上你。
聊聊测试和开发的关系
以性能测试，性能调优为起点，从工作重合度这个角度聊聊测试和开发的关系。
测试说俗了，就是给开发擦屁股的。
这里思考下如何擦的都满意，那块给你擦，为什么给你擦（捂脸）。
开发不屑于做的
开发根本瞧不上的，就是这活如果开发自己干了人家是觉得浪费时间的。
典型的是“点点点”这种工作，还有各种外包测试同学干的活。
当然“点点点”这种工作也能点出门道，这后面提，这里领会精神。
开发能做但是没时间做的
性能测试，部分自动化测试工作属于此类。
这也说明了，如果你性能优化水平很low，那开发本来没时间做的让你给整成不得不做了，能给你好脸色吗？
一些简单的自动集成，自动化部署环境，自动化接口测试等，人家开发自己能做只不过交给你了而已。
开发不一定能做好的
测试开发，部分自动化测试，测试架构师。
测试开发各种工具平台，开发真不了解需求啊，而开发能力大家又是平手，那他真没把握抢测试开发的饭碗。
自动化测试用例代码虽然一般，但是用例真心复杂，思维还是要有的，并且很可能存在语言不同，一般做不了。
能督促开发工作的
质量专员，安全测试，白盒测试。
开发之前我就告诉你这么做有质量风险，你这种架构不安全，得改的这类的。
白盒测试如代码覆盖率的测试，不是说随便发个报告就可以了，而是真的看到代码的缺点。
不过质量专员很虚，这里不做深入探讨。
安全测试我还不够了解，感觉也稍微虚。
总结
最值钱的其实就是后两种，越是开发做不了的越值钱。
测试工作如何值钱
全方位的测试用例设计
千万不要小瞧测试用例的设计，一个登录页面的测试用例设计甚至能写出来上百种（举例而已领会精神）。
而用例设计需要考虑的包括但不限于：
- 安全测试用例
- 性能压力测试用例
- 兼容性测试用例
- 弱环境测试用例
- 特殊功能性测试用例
这需要测试人员对架构，业务，性能，安全，浏览器/手机客户端等等要有一个充足的了解。
就算不充足，至少有些方面要有比开发了解。
简单来说，你要测出开发想不到的地方，“点点点”也会值钱。
技术能力强
粗暴的理解，就是，无论什么时刻，怼开发不带怂的。
就说性能调优吧，你能直接找出性能瓶颈，甚至以此diss开发水平，指导开发的修改方式，我觉得就不简单了。
开发对待技术的优势往往是深度，测试往往是广度。这个不展开讨论了，大家应该有共识。
当然这个需要长时间的积累，技术无止境。
沟通能力强
不多解释了，测试比开发更需要沟通能力。
业务
你要知道了解开发也掌握不到的业务，比如开发只知其一不知其二的这类。
当然业务很虚，我马上解释为什么。
对测试来说，业务为什么很虚
并非针对所有的行业，也并非针对所有的测试人。这里只谈谈一般情况。
开发流程
一个正常的开发流程，需求的路径从上到下有：
- 需求提出方
- 产品经理
- 开发
- 测试
很简单就能看到，测试存在于业务的底层。
谈谈测试比开发懂业务的可能性
是可能的。
但是想一下，需求是产品经理给开发和测试的，你怼开发，开发说是产品让这么干的，然后你怼产品？
有了业务矛盾，开发会听测试的还是产品的？
谈谈测试比产品懂业务的可能性
- 需求本身就是产品自己提的
人家自己创造出来的业务，被你测试给生生怼回去了，可能吗？
- 需求是来自需求方提的，产品设计的
你测试和需求方沟通过了？你要怼，可能吗？
业务会因跳槽而抛弃
不解释了，太虚。
聊回性能测试的尴尬
- 性能测试是开发有能力做但是没时间做的。
- 性能测试几乎不涉及业务。
就这两点，除非性能测试人有特别高超的技术能力，其余都不会受内部重视。
同时性能测试工作时间是高度集中和高度碎片化的，往往这个岗位在公司内是作为兼职。
最后
性能测试要求高但是往往不值钱，希望大家据我的思考能得到一二。
希望各位对性能测试工作有个认识，同时也能理解什么样的测试岗位才有可能值钱。
希望各位“点点点”不再轻易迷茫抑郁。
同时，薪水和岗位是匹配的，技术能力不能完全决定薪水高低。
这里也是粗浅的分析思考，技术不能万能的，但没有技术是玩不转的。
需要软件测试资料的小伙伴，可以来加群：747981058。群内会有不定期的发放免费的资料链接，这些资料都是从各个技术网站搜集、整理出来的，如果你有好的学习资料可以私聊发我，我会注明出处之后分享给大家。