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

zyanycall · November 21, 2018 · Last by 一只徐怪瘦 replied at October 18, 2019 · 5237 hits

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

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

性能测试的工作内容

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

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

最有含金量的部分

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

性能测试报告

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

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

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

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

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

前期性能测试需求的沟通

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

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

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

性能调优的一般内容

性能调优的技术栈

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

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

看到这一堆,你发现了什么?

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

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

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

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

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

聊聊测试和开发的关系

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

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

开发不屑于做的

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

开发能做但是没时间做的

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

开发不一定能做好的

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

能督促开发工作的

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

总结

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

测试工作如何值钱

全方位的测试用例设计

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

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

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

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

技术能力强

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

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

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

沟通能力强

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

业务

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

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

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

开发流程

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

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

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

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

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

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

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

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

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

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

业务会因跳槽而抛弃

不解释了,太虚。

聊回性能测试的尴尬

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

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

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

最后

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

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

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

共收到 38 条回复 时间 点赞

兄弟讲的是真的真实啊

基本都赞同,之前参与过几个大型压测项目,真正能参与性能调优的性能工程师少之又少,多数都是不停加硬件…

雪怪 回复

有支持的就没白写啊!感谢。

支持一下/

无论什么时刻,怼开发不带怂的@楼主

业务要看行业的,有些行业测试还真是对业务懂,只是没转产品而已。
不过性能测试还是要和开发一起做一起讨论,单方面闷头做效果是不好

国文 回复

希望能举出业务上,测试大于等于产品的行业例子,我也学习一下。

zyanycall 回复

比如我们的广告平台,测试可能做了十几年了,你可以查下doubleclick产品

国文 回复

确实,我有点儿不严谨了,一般在一行做了十几年的测试……肯定是业务精熟了。

zyanycall 回复

测试在了解全局业务上会比开发稍微有点优势,他能识别业务关联性,可以弥补单个设计中的遗漏,所以我们鼓励测试在各种评审会议中提问题

zyanycall 回复

其实也不一定是干的时间长了就比产品懂业务。 也是分产品类型的,有些技术性特别强的产品,国内的大部分PM就是hold不住。 比如我们产品是机器学习平台。 我最近天天怼产品,光PRD我打回去多少次了。 没有办法, 这种产品大部分逻辑都在底层,让人家想的特别明白也是难为人家

点点点 点的明白 有系统性的 有自己套路的 也少有😆

孙高飞 回复

😂 😂 😂
其实是你太强势了,产品相对弱小了,哈哈。

zyanycall 回复

因为我比他们懂,所以我才强势。 我面对我们研发架构师老大的时候,我是很乖的。

孙高飞 回复

👍 👍 👍

那么测试的立足之地在哪里,技术不如开发,业务不如产品,环境不如运维

红客联盟 回复

楼主在文章里面说了一句:开发对待技术的优势往往是深度,测试往往是广度。

大概在我想来就是测试能考虑到的方面更多。然后你需要作为一个中间人来协调各方,大概这就是立足点吧。 (小声bb)

红客联盟 回复

做好自己才是真的,这样比都要下岗了,需要一个全能的就行了

红客联盟 回复

测试的立足之处早有权威定论,就是测试这个岗位是必要的,软件工程离不开测试过程。
可能你想说的是如何能立足之稳,这在我的文中有说明,这里不复述了。
我可没说过技术不如开发,环境不如运维。

我觉得吧,测试是技术岗,但是测试的技术门槛是相对偏低的,情商比重其实比技术重很多。
性能测试,测试性能偏低,但是最有价值的工作,性能优化是算法和开发做的。
技术是有深度和层次的,是需要大量积累和不断迭代的。

深刻暴露了测试现状。测试做的越久,就越像开发。

说得情真意切,思绪万千

谢谢分享

大实话,点赞 。

写的挺对,确实符合大多数性能测试工程师
如果一定要有价值且不尴尬的话,那就是测试自己至少具备性能调优能力

初级中级开发,80%的都不怎么会全面的性能调优,所以你会了,开发会对你另眼相看。
在测试过程中的沟通交流中,你就会获得一点话语权。

zyanycall 回复

话说要强化性能调优的能力,怎么上道?

说的还是有道理的,大多数的性能测试工程师只停留在LR、Jmeter的使用上,一遇到性能瓶颈就叫开发,能做到精准瓶颈定位的都算不错了,那种能进行性能调优的少的可怜。而且性能调优涉及的领域(linux、数据库、JVM等)很广,能具备某一领域的调优已经不易了

t-bug 回复

以后我会发帖子简单说说,主要是想讲讲方法论。
因为调优的例子网上多了去了,但是能从例子中总结出自己东西的能有几个人?很多人也根本看不出门道。
方法论是一些基本的东西,抛砖引玉吧。

看了楼上一堆 突然觉自己可能不是渣渣中的渣渣,只是个渣渣而已,偷乐一下
"""
聊回性能测试的尴尬
性能测试是开发有能力做但是没时间做的。
性能测试几乎不涉及业务。
"""
emmm。对于这一点,好想是刚好是相反的。在公司一年时间里,从自动化转变到了性能,虽然一开始我是抗拒 的,毕竟对于系统配置什么的都是小白,但是拒绝无效
在后面系统资源分析,建议,略知的时候,老大时常在我耳边的一句话就是:一定要深入!要多考虑一下有哪些场景,不熟悉的可以多个***(系统测试)讨论讨论。

再有,关于话语权,比如机器升级,时常会听到开发或者开发leader说:“**, 你觉得我们应该怎样”
emmm,只怪自己太渣,对于一些资源消耗和限制的 不太明了,说话一直是“建议”

然后现在自我认知:性能测试也真的要懂业务!思维也一定要广
了解了业务,我才知道哪些方面需要重点测试,哪些地方需要专项测一下,哪些资源需要重点关注~

梦梦GO 回复

感谢能把你的思考写到评论中来,感谢。
我主要是思考几个问题来的,分享一下:

  1. 如果完全不懂业务能不能做性能测试? 答案是可能的,虽然不是说所有的性能测试都不要业务吧,但是完全不懂业务是可以做性能测试的,因为存在接口的性能压测,因为就算页面录制脚本的操作可以由功能测试或者开发代为执行。
  2. 如果完全不懂系统架构能不能做性能测试? 答案是可能的,就算系统是个黑盒,我也能做性能测试,并且根据折线图做一下基本的判断,如果给我服务器被压测机的系统监控指标或者日志记录,或者就给我服务器登录密码,我真的可以告诉你它性能有没有问题,问题出在哪。 我认为这是性能测试的基本功。

工作岗位的胜任力是一门科学,你的胜任力中很关键的一部分是业务,那就要把业务搞熟悉。

楼主说的大实话 总结就是工作的不可替代性 就值钱了

传说中有银行的业务测试,比开发牛逼。因为复杂的业务流只有她最熟悉...

Author only

可能你的心中早有决定,只不过希望我再给你确认一下了。
手机的性能测试也是需要了解代码的,虽然你非科班出身,但是高通不累,相信3-5年后,在你高强度自学下,你可以成为这方面的专家。专家之后,管理岗位是自然而然的,即使高通不行,HOVM应该也有你的一席之地,甚至互联网大厂也不是不可能。管理岗位是自然而然的,而你不能合理过渡到管理职能,只能有一个原因是你的能力还不够。
华为是老本行,996,但是由于你是科班出身,不用高强度自学即可以快速上手工作。如果你的学业成绩扎实,工作勤快,情商高,相信可以快速过渡到职场人,快速拥有工作上的成就感,在华为立足,成为奋斗者,管理岗也是自然而然的。
还有一些常识:

  1. 想赚钱,就会辛苦。不辛苦,还要多赚钱,那是你没看到人家的辛苦,或者家里有矿。
  2. 职场上,英雄不问出处。985211有用,但没有决定性的作用。

至于要去哪里入职,可以看看这两者的行业前景,先确定行业,再确定地方。具体可以问问老师,学长。

Author only

关于辛苦,简单说说我的理解吧。
辛苦一般是几方面,时间上的和心理上的和身体上的。
IT行业,时间上和身体上的劳累就不多说了,其实最核心的就是心理上的辛苦。
像华为这种高强度公司,或者阿里,头条这种,很多时候不是你自己不够努力,而是身边人比你更优秀,就把你比下去了,这种心理的劳累,高强度思考的劳累,高强度学习的节奏,不是985的出身是很难很难跟上的(除了985就要证明自己高强的学习能力),去了也是被淘汰。
再者辛苦也是有周期的,一般的IT工作,高强度的学习3-5年后,会进入一个平稳期或者过渡期或者是红利期,这段时间可以稍稍平稳,按照自己的节奏来工作学习,会比刚入职的时候舒服不少。不过阿里,头条,华为这种公司,不会让你轻易闲着,能力越强责任越大,占用你的时间越多。
至于你说的兼顾家庭,这个因人而异,一句话吧,贫贱夫妻百事哀,很多很多时候,家庭琐事多,烦,是因为穷导致的(扎心抱歉)。

Author only
需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up