性能测试工作不尴尬，但是性能测试岗位很尴尬。
从我这里的讲述中，希望你也能看到其他测试工作的影子，希望你对 “点点点” 不再迷茫不再抑郁。

自己水平有限，望大家多多批评。

性能测试的工作内容

这方面的资料很多了，我也不是权威，说不全的。
大致流程：

• 和需求提出方沟通要测什么，测试的目的等，是否真正需要性能测试。讨论测试的方案是否可行，比如一个页面图片是不是可以过滤掉，单压一个接口是不是就可以了。
• 确定测试的环境，测试的人都是谁，测试的时间，同时谁来准备测试数据。
• 根据测试工具如 Jmeter 或者 LoadRunner 等等确定写脚本，调通脚本。
• 执行脚本即压测，同时观察压测的现象。压测中要自己掌握控制压测的时间和量，时间短了不行，量过大过小都不行。
• 分析压测的现象，自己能分析最好，自己分析不了就找别人分析，现象是否达标。
• 如果不达标，要定位性能瓶颈问题，这是最考验技术功力的。
• 将性能瓶颈问题的修复做回归测试。一般或者是改代码或者是改环境配置。
• 发送测试报告。

最有含金量的部分

• 第一无疑是分析压测现象和性能调优，包括环境调优。
• 第二是讨论沟通需求，不过往往实操中这一步都很水，主要是因为测试没啥话语权。
• 第三是写脚本和准备数据和准备环境（如果有）。
• 第四是执行脚本时配置的并发数等参数及其含义。

性能测试报告

实操中，测试报告往往是很水的一个环节。两种情况讨论：

• 系统性能不好还在修改中，这时候不用发测试报告，还没改好呢发什么报告浪费大家时间。
• 系统性能好了才需要发送测试报告，性能都好了啊，其实解释一下数据就行了。

那么对测试报告的核心要求很简单，就是：界面精美权威高大上。

里面的折线图重要吗？已经不重要啦，调优的时候真的重要，但出报告的这个时候这些指标我们已经不头疼不 care 了。
里面的数据结果集重要吗？重要，所以要醒目。

所以对测试报告，最重要的就是数据结果集展示，就那么两行结束，其他都是辅助，来证明测试报告的高大上，来证明性能测试工作的难度和工作量。
所以懂行的无论谁最关心的应该是调优，那些仅仅关心测试报告形式内容的甚至穷追不舍的一般都很 low。

前期性能测试需求的沟通

网上去搜这个，肯定是一堆要点并且要有数据计算，比如全天的用户量是多少，用户的活跃时间在哪里，高峰用户量是多少，二八法则等等。
实际上这些都是很理想化的东西，真正压测起来肯定会变成：性能越高越好。
这个也是好理解的，谁都想要最好的，同时最后越过最优性能才知道系统瓶颈在哪里才能调优。
所以，懂行的无论谁最关心的应该是极限压力测试，容量测试仅仅是附属品，任何仅仅纠结于容量测试的一般都很 low。

同时测试地位的局限，面对一些明显是不合理的高要求根本没有反驳的余地，答应就是了，等着现实打脸就好了。
其实也没啥讨论计算的地方，总结一下，前期的需求沟通，往往就是知道要测什么了，告诉开发预期不要太高，就这样。

例如，我曾经遇到前端每传入一批新参数就要在数据库中创建新表，就这种奇葩的架构方案还要高性能，我也是答应而已，坐等现实啪啪打脸。

性能调优的一般内容

性能调优的技术栈

简单说说性能测试的核心，性能调优包括环境调优。这里不教你怎么调优，而是聊聊调优的技术树。
以 Java 为例，看看调优要掌握什么：

• 底层 Linux。
• 基本硬件知识，SSD 和磁盘，CPU 和内存知识。
• 虚拟化技术。
• 网络协议，网络基础。
• 关系型数据库，NoSQL，队列，文件服务器。
• JVM，即 Java 语言的特性。
• 线程和进程
• 系统架构知识
• 语言算法
• 公司业务

看到这一堆，你发现了什么？

• 我根本就没提测试工具的使用！神圣的 Jmeter LoadRunner Locust 等等这些哪去了？
• 和开发的技术要求基本一样，甚至包括部分运维的技术树，甚至超过开发的技术宽度。

说实话，某些开发的 Jmeter 用的比测试还 666666，难不成技术树里我还得写上 IDEA/Eclipse 吗？一个工具而已。

一个性能测试没有性能调优能力会怎么样

简单暴力的就是没地位，这种技术水平的地位甚至都不如 Jmeter 一个软件。

• 出了问题背锅肯定有你。
• 得了荣誉大头肯定没你。
• 平时交流 diss 的就是你。
• 要点儿资源特别费劲。
• 学习的态度吧，人家开发忙起来了根本顾不上你。

聊聊测试和开发的关系

以性能测试，性能调优为起点，从工作重合度这个角度聊聊测试和开发的关系。

测试说俗了，就是给开发擦屁股的。
这里思考下如何擦的都满意，那块给你擦，为什么给你擦（捂脸）。

开发不屑于做的

开发根本瞧不上的，就是这活如果开发自己干了人家是觉得浪费时间的。
典型的是 “点点点” 这种工作，还有各种外包测试同学干的活。
当然 “点点点” 这种工作也能点出门道，这后面提，这里领会精神。

开发能做但是没时间做的

性能测试，部分自动化测试工作属于此类。
这也说明了，如果你性能优化水平很 low，那开发本来没时间做的让你给整成不得不做了，能给你好脸色吗？
一些简单的自动集成，自动化部署环境，自动化接口测试等，人家开发自己能做只不过交给你了而已。

开发不一定能做好的

测试开发，部分自动化测试，测试架构师。
测试开发各种工具平台，开发真不了解需求啊，而开发能力大家又是平手，那他真没把握抢测试开发的饭碗。
自动化测试用例代码虽然一般，但是用例真心复杂，思维还是要有的，并且很可能存在语言不同，一般做不了。

能督促开发工作的

质量专员，安全测试，白盒测试。
开发之前我就告诉你这么做有质量风险，你这种架构不安全，得改的这类的。
白盒测试如代码覆盖率的测试，不是说随便发个报告就可以了，而是真的看到代码的缺点。
不过质量专员很虚，这里不做深入探讨。
安全测试我还不够了解，感觉也稍微虚。

总结

最值钱的其实就是后两种，越是开发做不了的越值钱。

测试工作如何值钱

全方位的测试用例设计

千万不要小瞧测试用例的设计，一个登录页面的测试用例设计甚至能写出来上百种（举例而已领会精神）。
而用例设计需要考虑的包括但不限于：

• 安全测试用例
• 性能压力测试用例
• 兼容性测试用例
• 弱环境测试用例
• 特殊功能性测试用例

这需要测试人员对架构，业务，性能，安全，浏览器/手机客户端等等要有一个充足的了解。
就算不充足，至少有些方面要有比开发了解。

简单来说，你要测出开发想不到的地方，“点点点” 也会值钱。

技术能力强

粗暴的理解，就是，无论什么时刻，怼开发不带怂的。

就说性能调优吧，你能直接找出性能瓶颈，甚至以此 diss 开发水平，指导开发的修改方式，我觉得就不简单了。

开发对待技术的优势往往是深度，测试往往是广度。这个不展开讨论了，大家应该有共识。
当然这个需要长时间的积累，技术无止境。

沟通能力强

不多解释了，测试比开发更需要沟通能力。

业务

你要知道了解开发也掌握不到的业务，比如开发只知其一不知其二的这类。
当然业务很虚，我马上解释为什么。

对测试来说，业务为什么很虚

并非针对所有的行业，也并非针对所有的测试人。这里只谈谈一般情况。

开发流程

一个正常的开发流程，需求的路径从上到下有：

• 需求提出方
• 产品经理
• 开发
• 测试

很简单就能看到，测试存在于业务的底层。

谈谈测试比开发懂业务的可能性

是可能的。
但是想一下，需求是产品经理给开发和测试的，你怼开发，开发说是产品让这么干的，然后你怼产品？
有了业务矛盾，开发会听测试的还是产品的？

谈谈测试比产品懂业务的可能性

• 需求本身就是产品自己提的

人家自己创造出来的业务，被你测试给生生怼回去了，可能吗？

• 需求是来自需求方提的，产品设计的

你测试和需求方沟通过了？你要怼，可能吗？

业务会因跳槽而抛弃

不解释了，太虚。

聊回性能测试的尴尬

• 性能测试是开发有能力做但是没时间做的。
• 性能测试几乎不涉及业务。

就这两点，除非性能测试人有特别高超的技术能力，其余都不会受内部重视。

同时性能测试工作时间是高度集中和高度碎片化的，往往这个岗位在公司内是作为兼职。

最后

性能测试要求高但是往往不值钱，希望大家据我的思考能得到一二。

希望各位对性能测试工作有个认识，同时也能理解什么样的测试岗位才有可能值钱。
希望各位 “点点点” 不再轻易迷茫抑郁。

同时，薪水和岗位是匹配的，技术能力不能完全决定薪水高低。
这里也是粗浅的分析思考，技术不能万能的，但没有技术是玩不转的。