尴尬的性能测试岗位——顺便聊聊 “点点点”

性能测试工作不尴尬，但是性能测试岗位很尴尬。

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

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

性能测试的工作内容

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

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

最有含金量的部分

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

性能测试报告

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

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

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

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

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

前期性能测试需求的沟通

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

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

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

性能调优的一般内容

性能调优的技术栈

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

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

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

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

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

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

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

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

聊聊测试和开发的关系

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

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

开发不屑于做的

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

开发能做但是没时间做的

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

开发不一定能做好的

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

能督促开发工作的

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

总结

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

测试工作如何值钱

全方位的测试用例设计

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

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

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

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

技术能力强

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

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

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

沟通能力强

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

业务

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

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

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

开发流程

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

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

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

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

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

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

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

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

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

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

业务会因跳槽而抛弃

不解释了，太虚。

聊回性能测试的尴尬

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

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

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

最后

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

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

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

需要软件测试资料的小伙伴，可以来加群：747981058。群内会有不定期的发放免费的资料链接，这些资料都是从各个技术网站搜集、整理出来的，如果你有好的学习资料可以私聊发我，我会注明出处之后分享给大家。