职业经验 [思寒] 测试职业发展简谈

seveniruby · 发布于 2016年12月28日 · 最后由 itsgoodtobebad 回复于 2017年07月31日 · 最后更新自管理员 seveniruby · 16034 次阅读
本帖已被设为精华帖!

应有些同学的要求我简单总结下吧. 最近很忙, 一直没顾得上写太多文章. 而且这个话题太大我一直没敢随便写怕误人子弟. 陆陆续续的写了这么多, 就先发出来给大家参考吧.

关于我的背景

以下结论不能适用于所有的行业, 所以我只能从我的个人角度来总结我认为的行业发展. 所有的分析都是围绕着我的行业背景设定的
我的主要工作背景

  • [入行] 中软资源外包测试工程师
  • [成长] 阿里巴巴测试工程师 百度高级测试工程师
  • [探索] 独立测试咨询师 Testin产品总监 OneAPM测试架构师
  • [沉淀] 雪球测试开发工程师

近十年的工作经验. 2007年至今. 早年对自己定过一个要求. 不做管理. 所以这些年一直在一线做业务测试和测试技术改进.
以下内容都是我的亲身经历和感触, 有些不一定对. 请仅作参考.

特别声明

  • 互联网公司QA和测试不分家了. 所以我提的QA或者测试等词语都表示互联网公司的QA部门.
  • 具体数字是不严谨经过模糊化的. 仅供参考.
  • 只针对互联网行业

测试行业发展背景

微软引领的大测试时代

中国最早的对IT工程的启蒙和测试定位的探索大多来自于微软. 当年的大背景是微软故意放任windows的盗版, 并积极的输出他自身的IT生态技术栈到中国. 中国从政府到民间几乎全部使用了windows. 中国有大量的微软认证的VP等各种专家.
微软和他的附属生态带给中国的测试行业影响简单总结下就是

  • 强调工程的严谨性. CMMI一统天下. 无数中国公司为了通过这个认证费尽脑汁. 大部分公司通过它也不是为了自己的规范, 而是为了能拿到政府或者国外机构的外包业务.
  • 测试和研发的比例. 因为都是客户端产品. 如果交付出去出现质量问题是很难解决的. 所以测试被放在一个非常重要的位置上. 测试与研发比一度是1:2
  • 外包公司发展迅猛. 短短的几年. 中软, 东软, 软通动力, 博彦等公司迅猛的发展起来.
  • 51testing作为作为中国最早的测试社区门户迅速发展起来
  • 测试技术的启蒙和发展. 主要是自动化为主. 在十年前的年代, 听一些前辈说, 有公司做性能测试, 就是有个人用哨子吹下, 然后一屋子的人就开始一起点. 所以QTP和LoadRunner出现后就迅速占领了市场.

互联网时代的测试发展

互联网世界开始爆发
测试行业的主要变化是

  • CMMI逐渐被互联网公司忽略. 国内崛起的公司有自己的业务, 他们不屑于不实用的认证. 开启自己独特的野蛮发展的节奏. 这也就是那些外企工作的白领有优越感的一个原因.
  • 测试技术大发展. 不再是简单的自动化了.开始进入了细化. 比如单元测试, 代码动静态测试, 接口测试, 持续集成, 各种端的自动化测试. 大家也不再迷信UI自动化, 分层自动化, 持续集成, 测试既服务等理念开始流行.
  • 测试工程师技术型转变. 以前的测试工程师就是点点点, 不会要求技术的. 现在BAT等一线公司已经全部推行技术笔试了. 可以说不懂开发基础已经难以发展了. 点点点测试工程师已经退化到只能用于用户端的功能校验工作了.
  • 测试研发比从1:2下降到了1:3 1:5

移动互联网+创业浪潮时代的测试发展

移动互联网爆发, 技术栈和云计算也发展迅猛, 这让小公司的生产力发生了飞跃. 从而催生了一场席卷全球的创业浪潮. 这股浪潮起源于硅谷, 并迅速通过"copy to china"模式烧到了中国. 另外一个是中国大环境的变化, 导致了外资企业生存困难, 很多优秀的企业都从中国撤离.

这期间的测试行业发生了如下的变化

  • 服务于国内企业的测试工程师开始增多. 外包测试工程师, 外企工作白领测试工程师都被外企撤离影响到了, 开始逐渐转到国内公司. 外企工作的优越感逐渐丧失, 国内的工程师开始崛起.
  • 敏捷理念盛行. SCRUM和XP理念被迅速的普及. Scrum迎合了产品管理的需求, XP迎合了工程化发展的需求. 各自发展都很迅猛, 然后逐渐衍生了更深入的CI CD和devops等模式.
  • 测试研发比. 下降到1:8甚至更低. 其实BAT都向往google的1:10. 只是国内目前做不到.
  • 大质量部模式被打散. 为了提高运作效率. QA或者测试工程师团队被逐渐分拆到各个具体业务部门. 大质量部模式消失意味着测试工程师的发展开始遭遇天花板. 很多人还没能体会到这个模式带来的巨大影响.
  • 测试技术发展. 测试平台得到了很大的发展. 研发工程师, 技术型测试工程师也开始逐渐发挥价值. 比如新型的全链路压测, 全链路追, 测试监控, 各种接口测试和mock平台, 各种云测和专项测试平台. 独立的测试服务公司也开始层出不穷.

大数据和智能时代

人类已经进入DT时代. 大数据, 机器学习, 深度学习, 图形渲染等技术栈已经成熟了. 随之而来会形成新的生产力并落地.
这个阶段大家刚开始感受到. 我暂时不做评论.

行业发展总结

之所以列举过去的变化其实是为了想告诉大家, 不要认为目前的模式就是行业的现状. 目前各家公司仍然是处于不同的理念和不同的历史阶段中.
没有绝对的对错. 只有适合与否.

这些变化都是围绕着几条核心的主线发展的

业务发展

业务发展带来了对质量和速度的追求. 这是整个行业发展的主线.
业务发展的需求影响到了产品研发和测试. 它和资本一样是贪婪的, 无时无刻不在追求着突破瓶颈. 追求更快更好的发展.
它决定着很多公司的生死和很多行业工程师的前途. 研发, 产品, QA都是要为业务服务的.

技术发展.

技术是生产力的重要组成部分, 技术的发展是加速度的. 每次质变都会带来一些重大的变更. 技术的成熟度决定了测试行业的成就能做多大.
作为测试工程师要善于利用当前的技术栈打造符合当前需求的解决方案.

管理发展.

公司主体在追求简单高效的管理上是永不止步的. 技术和工具的每前进一步, 就意味着组织沟通的能力在增强.
管理这个方向会逐渐的扁平化. 高层管理会越来越少. 一线管理会越来越多.
作为测试行业比较尴尬的一点是大质量部模式模式的消失, 让测试行业的发展开始遭遇天花板.
如果hold不住研发和产品, 测试行业发展的人是没法往上很好的晋升的

测试职业发展

薪酬数据参考

我根据人才的基本属性并用实际的例子总结, 按照8年跨度. 总结了行业的一些典型人才的现状.
为了保密, 我模糊了相关数据. 与真实情况会有偏差.

角色 技术能力 管理能力 业务能力 运气与选择 总收益
某司工程师A 一般 一般 一般 没有股票或者股票很少 总收益150w左右
某司工程师B 一般 一般 优秀 因为早期拿到了期权 总收益在300w以上
某司工程师C 优秀 一般 一般 多次跳槽, BAT待过两家, 因为变动股票少工资高 总收益在300w左右
某司工程师D 优秀 优秀 一般 多次跳槽, BAT待过两家, 在黄金期拿到了股票, 工资高 总收益在500w左右
某司工程师E 一般 一般 优秀 常年待在BAT某家公司, 黄金期拿到较多股票 总收益在1000w
某司工程师E 一般 优秀 优秀 常年待在BAT某家公司, 黄金期拿到较多股票 总收益在3000w
某司工程师F 一般 一般 无核心业务, 常年待在某外包公司 没股票涨薪有限 总收益在150w左右

我手里也有更多的数据, 我也一直想搞个决策树模型, 但是一直没完整的做出来. 这次就先简单列举这几个典型的案例吧.

职业上升的关键因素

  • 技术能力决定了你的薪资增长加速度. 在月薪1w到3w中间. 技术能力助力会较多.
  • 管理能力决定了你的薪资阶层. 月薪2w-5w是管理层基本薪资. 后面的要靠公司的股票和奖金
  • 业务能力决定了你的地位和长期回报. 对业务的把控决定你在团队的影响力和重视度. 也关联期权和股票的数量.
  • 运气和选择决定了你的人生轨迹. 选择的好就能获得最大回报.
  • 股票或者期权回报是超过工资的. 选择一家靠谱的可持久的公司很重要.

作为个人发展, 我的建议是扎实的提升你的技能, 培养好你的人脉和软实力. 至于运气和选择不用焦虑, 如果你有能力, 自然会有高人拉拢你.
比如之前就经常有朋友联系我, 说是XX公司要发期权了, XX公司要上市了, 跟我们一起干吧. 人品好, 技术好, 大家都会喜欢与你为伍的.

职场建议

切莫在不该有的年龄追求权利
这会断送你的整个前程. 在一些面试场合, 如果面试官问你愿不愿意做管理, 如果你回答是, 那么面试基本就挂了.
一定要确认面试你的人是不是真的希望你走管理路线. 大多只是测试你是不是真的是个实干家.
过早参与管理工作也会导致个人技能发展的不健全. 这会为以后带来隐患.
过于追求权力必然也会引发办公室政治和各种利益斗争. 所以请谨慎面对这个毒苹果.

在薪资和工作机会之间做合理的权衡
每家公司都有自己的薪资体系. 你要参考这个数据来合理的确定自己的薪资, 不要有幻想. 不要觉得别人因为某次成功的忽悠拿到多就懊恼.
一个优秀而扎实的工作经历会让你受益一生, 会为你的简历增光不少. 对于这种机会降薪也值得去.
一个合理的节奏是1-2年主要是积累能力. 能糊口即可. 2-5年可以适当的跳槽追求更好的待遇或者更闪光的工作履历. 五年以上就是物色好的机会一飞冲天了.
如果跳槽太多, 一些大公司也会非常的在意, 会影响你的面试. 比如工作经验不到一年或者两年就跳槽的人, 很容易被BAT认为轻浮.

测试行业的发展

表面"衰落"的测试行业

鉴于过去的大形势变化, 不懂技术的测试工程师会逐渐被淘汰出局. 一波测试工程师的失业潮是在所难免的.

虽然早期我也呼吁身边的人赶紧脱离落后的业务体系, 脱离落后的测试技能, 但是看到很多人越来越生活艰难, 也是挺心痛的.
包括测试工程师的需求越来越少, 招聘职位也越来越少, 典型的新崛起的巨无霸公司比如facebook早期都没有QA.
甚至前几年一度有QA团队是否值得存在的争论. 表面看起来是测试行业衰落了.

有趣的是大家讨论QA团队是否值得存在的初衷, 是为了更好的保证质量. 这还是挺耐人寻味的.
绝大多数的公司, 都是非常支持QA部门的存在的, 问题在于QA团队的存在的价值到底是大还是小.
过去陈旧的测试体系, 落后的测试人员能力, 冗长的测试流程是被整个IT行业诟病的一个关键.
当研发的生产力在逐渐的提升, 运维的部署在逐渐的自动化, QA所带来的价值和耗费的成本就越来越不能忽视了. 甚至成为了一个项目的最大的成本.
这是任何一家公司都无法忽视的问题. 早年阿里巴巴的高管曾经集体去硅谷拜访新崛起的巨无霸, 得到的结论就是他们的流程和执行力比国内强很多. 甚至facebook早年都没有QA就成长为大公司了.
所以阿里就迅速推动了流程的裁剪. 这部分包括裁撤SQA, 裁撤需求分析师, 裁撤项目经理, 削减QA名额. 进入产品, 研发, 测试三足鼎立的最简模式.
QA会不会被撤掉也取决于这个部门的价值. 所以不要想当然的觉得"存在即合理", 现在部分的公司已经在试验"无QA"的模式了. 互联网唯一不变的就是变化

比如一个典型的例子, 在搜索, 推荐, 机器学习等方向的算法测试是很重要的领域, 是需要专业的测试工程师参与的. 这个行业能容纳很多的测试团队.
但是测试行业这些年就没形成对这个领域的正确测试方法, 结果最后丢失了这个市场. 现在都是研发自己保证了. 因为找不到合格的测试工程师去保证这个业务.

同样在性能测试领域也是如此, 随着性能测试平台, 全链路压测, 性能监控, AB Test, 云压测这类技术和服务的出现, 性能测试工程师的需求也会缩小.
越来越多公司里的性能测试都已经变成研发主导了. 丢失了这块的业务, 性能测试QA的需求量自然会受影响.

一定要记住, 业务空间决定QA的生存空间, 这是所有行业都通行的道理.
如果你不能满足业务需求, 就会被淘汰出局, 要么选择退守防御要么选择勇于接受挑战

那测试行业的未来是什么样的那, 很多人会担心. 不过我还是整体乐观的.
因为我喜欢整个行业, 这些年也一直在进行不断的思辨. 说下我的看法

测试从业人员的规模

从业人员规模跟生产力负相关, 跟业务规模正相关. 以后能有多大取决于技术和业务规模的双重因素.

首先是大环境因素, 随着各种行业的互联网化, IT行业在扩大, 外卖, 美甲, 甚至是无人机汽车航天产业都将成为科技公司.
研发的队伍会扩大, QA的队伍自然也会整体扩大. 前提是QA自己要跟得上时代.

其次是随着生产力提升自然就不会需要这么多人的. 哪个行业都这样, 测试行业并不特殊.
就跟汽车行业一样. 早年堆人, 然后堆工具, 堆技术, 上机器人, 改进流程.
行业技术改进, 测试技术改进, 测试工具和测试服务的改进, 都会一定程度提高了测试效率, 减少了成本. 这种改进会导致QA的团队更精炼高效.
人数多意味着大家的价值跟富士康工厂里的工人一样廉价. 追求高附加值才是正确的路. 这对公司和测试团队都是双赢的.

第三个因素是行业地位. devops的流行是推动了研发和运维的密切合作. 一旦这个阶段完成, 产品的生产部署会非常的流畅.
随之而来的就是问题会越来越早的暴露, 大家对质量会更加的重视. 到时候就会进入一个新的时代, DevQA.
运维逐渐会管道化, Dev和QA会成为新的主角. 只是到时候能撑大局的不一定是现在的软件测试工程师了 会是新时代的测试工程师.

测试行业会越来越专业. 人才, 技术, 工具, 开源平台, 服务会越来越多. 越来越完善. 术业有专攻, 专业化分工仍然是大趋势.
技术层面上也会有创新. 以前的测试只能留下测试用例和业务知识文档 没有什么连续性积累.
随着接口测试, 质量监控, 覆盖率分析, 业务建模等技术的突破, QA也会形成自己稳定可积累的业务数据, 并逐渐形成自己的平台和业务.
业务空间+技术门槛的双重因素是我坚信QA部门能长期存在的一个核心因素.

迎接测试行业的变化

测试行业的管理会逐渐扁平化

几乎大部分的互联网公司都在分拆业务和QA团队从而提高执行力. 所以管理上百人的总监职位会越来越少, 而管理百人以下的总监会越来越多. 不排除少量的巨无霸仍然没有改变. 或者有些烧钱的初创公司倒行逆施. 其中这些测试管理者会遇到一些新的挑战, 比如更高层是研发出身居多. 不懂研发体系几乎没有发展空间了. 测试管理体系失去了上层建筑, 对未来的影响还是深远的. 会有阵痛, 但是结果肯定会是好的

测试技术人才需求增多

原因是多方面的.
大公司因为分拆的问题. 不再有统一的测试技术支撑部门, 所以分拆之后的每个团队都需要组建对应的职能团队, 对测试技术人员的需求反而会增多.
中小型公司也苛求质量保证效果, 不止是要好, 而且要求更快, 也需要大量的技术人才. 这几年通过各种招聘网站的招聘job的描述也能看得出来.

外包测试的灾难和新生

原来做欧美日韩外包业务的公司会因为国内互联网的发展逐渐式微, 他们需要转型做国内.
但是国内对外包业务也大多排斥, 而且外包业务在效率沟通管理上都有诸多弊端. 其自身也无法承载对测试工程师的培养和长期发展. 所以这几年会有大量的外包测试工程师转型.
这方面需要有新的优秀的外包服务公司.能做到有自己的测试服务, 测试技术和高级的测试研究工程师才行.
比如东软也开始做自己的各种云测平台之类的, 就是一种为了迎合新时代的变更.

不懂开发的测试工程师已经是新时代的文盲

第一个是工作上已经没有太大的晋升空间. 第二个是也很难跳槽. 最好的结果是凭借多年的经验转管理.
我跟行业的很多测试经理交流过, 大部分工作超过6年的人, 在测试执行上会倦怠, 在测试技术的改进上已经无法入门, 还不如招实习生.
相对来说, 有技术基础的人在工作8年以上仍然会保持自己的学习热情.

所以未来测试团队的架构基本会是多数业务测试工程师+少数测试专家+测试经理的管理模式.
以前不识字的是文盲, 后来是不识英文的是文盲, 在继各国呼吁加强对IT技术的重视后, 新时代的文盲就已经快是不懂开发的人了.
testerhome社区的成立的初衷就是希望唤醒整个行业对测试技术的重视.

测试行业的门槛增加

以前处于发展期, 行业对人才的苛求是第一位的. 现在随着大公司发展稳定, 招人已经稳定了.

他们基本只在211院校校招. 社招也看学历. 初创公司多是融资烧钱为主, 在学历上和阅历上也是看的很高. 能够不拘一格降人才的公司会越来越少.
我之前推荐了不少同学去其他优秀的公司, 其中有一部分同学就是技术不错, 但是学历未过关. 所以希望大家技能和学历上能够好好的重视这个问题.
除了学历门槛, 如上一条所说技术门槛也存在. 所以加油吧, 少年

测试行业的薪资在提高

测试行业经过自身的净化洗涤会有新生. 典型的变化就是薪资从以前的3k-15k的范围, 整体提升到1w-3w之间.
技术含量的提升, 责任的提升必然会带来整体的回报. 现在只要技术好, 学历没问题. 工作3年拿个两三万的月薪是很平常的.

研发工程师进入测试领域

这些年整个行业对测试行业的发展非常不满意, 通俗点讲, 大家都觉得测试很Low, 但是又不能没有.
研发提交项目给测试的心情就跟以前过年要去火车站排队买票一样. 要申请测试资源, 给测试讲解业务和实现, 遇到比较low的或者新入职的, 连搭建环境都不会还得手把手教.
研发只是修改一行代码, QA或者测试那边就炸锅了.各种流程足以让研发头发都能掉好几根.
作为参考对比, 再思考下运维. 当年部署个环境跟提交测试很像. 要申请运维的介入, 要申请机器资源, 然后提交部署文档, 还要明确基础环境, 依赖库等各种细节的版本号.
遇到本地行发布环境不行之类的问题还得跟运维撕逼. 当年运维行业还流行着一句, "人"才是最关键的发布保证者.
而现在随着持续交付和devops的流行. 发布都已经做到"丝般柔滑"了, 一键发布,自由选择灰度,平时的发布甚至都不需要运维参与.
尝试了新模式的甜头后, 对测试行业的弊端已经很难忍受了.
所以在优秀的测试工程师和架构师难找的情况下, 已经有越来越多的公司选择直接用研发工程师来顶了.
他们的追求很简单. 单测->接口测试->基础的冒烟测试, 能够做到自动化就可以了. 如果能像运维那样做成测试即服务就更完美了.

总结

我一直坚信, QA的价值是非常的大, 测试行业在经过这次调整后也会发展的很好. 至于说未来能有多辉煌,就要看大家的努力了.

测试职业发展建议

测试行业和其他行业的发展没有本质的区别. 这些年都已经规范化了. 一般的公司都会有两条路线发展.
一个是P或者T简称的技术路线, 一个是M的管理路线.
每个方向都有很大的发展空间, 级别也是很多, 年薪也是从20w到100w以上都有. 稍大的公司大都是并行发展的.
小公司可能就只有管理路线可走了. 所以做技术的同学, 最好是在大公司发展, 去小公司就要适当调整自己工作重心.

测试技能发展

首先技能和技术只是过程, 业务的质量才是目标.

一个合格的优秀的测试工程师, 应该是能做到如下几点

  • 懂业务. 能扎实的保证业务质量. 不排斥用脑力和体力去保证质量.
  • 懂技术. 能够做深入的自动化或者分析工作. 能够利用工具和技术解决问题
  • 懂架构. 能够跟研发和产品进行正常的交流, 保证产品需求和实现都没问题. 能带团队走上更好的发展.

不看好测试开发工程师. 开发一款测试工具, 设计一个更好的测试框架, 发明一种更先进的测试手段. 这是个人成长带来的自然成果, 但不是目标.
很多人会觉得测试开发是有前途, 其实也不是. 只是他碰巧赶上了测试行业的技术转型期的需要.
我记得百度的时候, 好多负责单测工具, 单测框架的维护团队, 经常凌晨两三点还在修复bug. 但是几年过去, 这些人的努力大多没有很好的回报.
这是因为他们做的事情脱离业务目标太远. 一旦完成目标, 他们也容易被"管道化", 成为边缘角色.
这个行业除了极少数技术的狂热爱好者, 能够找到自己在行业的技术地位外, 大多数人都应该去追随业务的发展. 业务才是测试的根基.
测试行业和以前的战国时代一样, 成为一个统帅团队叱咤风云的将军, 还是成为一个打造兵器满怀工匠精神的铁匠, 都是值得尊敬的.
在冷兵器时代排兵布阵管理就是王道, 在热兵器时代下技术和科技是重要力量.
这个需要看每个人的爱好和追求. 明确自己的发展方向和爱好就可以.

技术路线我的建议是

  • 多读书. 能系统的了解很多东西.
  • 多看别人的代码. 他山之石可以攻玉.别人的开源代码里面藏着很多的经验和智慧. 要善于学习.
  • 早期多造轮子. 这是一种不断演习的强化锻炼. 可以强化自己的技能.
  • 多承担开源维护工作. 尽可能的参与开源社区的维护工作. 跟这些人的协作你能学习到很多有用的实践知识. 能够强化自己的沟通协调和架构设计的能力.
  • 多泡论坛交流. 闭门造车, 敝帚自珍,固步自封都是没什么成长的. 跟这些保守的人交流你也学不到太多.
  • 打怪升级.从部门里一件件的改进做起, 实现把技术转化为生产力.

测试管理发展

以前纯做团队管理的人估计是很难适应互联网行业的变化了. 可能要面临着诸多的挑战. 需要加强自身的能力建设.

早年做了管理的同学现在有些其实也都开始后悔了. 弄的高不成低不就.
现象就是总监升不上去. 经理级别没亮点也不能升级别. 业务发展一般, 团队也没变化, 跳槽最怕遇到笔试或者技术测验.
真正能做好测试管理的精英还是蛮少的. 如果踏入这个行业, 应该多关心如下的事情

  • 能帮你做事的人才和团队, 没有给力的队伍是做不好的.
  • 混圈子. 结识更高级别的CXO. 这是将来的发展需要的.
  • 多读书, 多学前人的管理和沟通经验, 跟得上行业发展的步伐.
  • 修身养性. 魅力 气场, 名望, 实力, 人品是取信于人的关键.

管理相对技术在大公司向上发展是比较难的. 一般跳槽到初创公司是最容易变现的.
比如一个BAT的测试经理, 月薪不过是2w多的样子. 跳槽到创业公司做测试管理. 月薪就到3w-5w了.
甚至能力上去, 直接跳槽过去当高管和CTO的也不少.

因为我不做管理, 这方面我就不班门弄斧了.

备注

以上只是侃侃而谈, 没有什么深度, 请不要传播到testerhome之外的任何地方.
我们社区的同学自己看看参考就好, 不要让外面的人知道, 也避免让我陷入无谓的口舌之争.
因为帖子过长, 原来提到的一些技术话题, 我先暂时剥离出去了, 以后再写独立的技术篇.

另外别喊我大神, 我也是小弟. 一直在一线工作. 大家喊多了会导致我被人误解成沽名钓誉害我被喷的.
根据你的年龄, 喊我思寒, 思寒哥, 思寒叔都行吧. 我1984年的, 刚到被人喊叔就泪奔的年纪

如果你支持社区, 就加下这个社区的公众号和微信号吧.

TesterHome个人号, 年底的分红会通过此帐号发给社区所有人. 这是第三年的红包.
未在社区个人资料里留个人微信号或者未加个人号的同学可能就收不到这一万多的分红了.

TesterHome微信公众号

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 162 条回复
10510

我先坐个沙发

4481

在测试这一行,走得越久越感觉技术的重要性,不再是当初的多少年转管理,而是你到了那个层次,自然会有机会。

9943

板凳

8907

沙发没了,就蹲着看完,给个赞!!!

7606

啥也不说了,先点个赞

5512

我这里也是直接招开发来做自动化、接口、平台等测试工作。

96

测试水太深了,而我还在岸边徘徊😔

—— 来自TesterHome官方 安卓客户端

1064

老司机懂得就是多,坐等下篇

9楼 已删除
96

一个连面向对象是什么的测试,通过《演员的修养》,成功进入世界500强某东管理层,目前正在研习《溜须深入思考v2.0》。

7956

希望更多关于测试行业介绍的文章

4112

先点个赞,期待下篇

11362

期待下一篇

4845

现在就是一脸迷茫,不知道下一步怎么走

8649

坐等下篇。

—— 来自TesterHome官方 安卓客户端

4863

先点赞,期待下一篇。

4821

赞一个 等下篇

Ee76af

老司机带路

5927

看前辈自传的心态开始阅读,到最后文风俨然国内测试的浪潮之巅

1109

又该学习了.

2606

对自己要学什么, 如何发展,太有指导性了!

104

#19楼 @morgen 陆陆续续的写的. 很乱. 将就着看吧. 这是我写帖子以来最不满意的一个. @safe 催了很久. 索性就先开放出来.

2113

深度好文,学习了,感谢~!

9584

微软引领的大测试时代中:比如一度是两个测试对一个开发, 甚至是一个开发对两个测试 ,感觉哪里不对😅 ,还没看完,先谢谢思寒大神

5837

已赞,等下篇

D38bdc

写的真心好 看起来目前还算是一个优秀的测试工程师 自夸一下 then 然后是怎么加深技术的发展 接下来怎么走 看了这篇文章还是收获挺多了 期待下篇~~

Db42eb

思寒现在不是在美团么

8610

这个话题确实很大,里面很多观点和方法都想深入了解一下,呵呵

9584

先说一个问题,移动互联网+创业大潮:从而催生了异常席卷全球的创业浪潮.😅
大概整个行业里面只有测试工程师会认为自动化测试是鸡肋. 这句话我很认同,我也感觉目前所在公司自动化很鸡肋,业务变化太快,动不动就新增系统,不断的挖坑填坑,自动化做不起来,可能是因为在小公司
少数技术入门了但是根底不扎实的人会误导并传递错误的信号. 总感觉是在说我这种😂
已经入行五年,但是目前在技术方面基本为0,不知道还能不能赶上时代的步伐,感谢思寒大神,等有时间我在多读两遍,期待下篇

104

#30楼 @safe 现在的自动化策略需要调整 比如推分层自动化, 这块有几个方向.
第一个是用自动化保证回归. 尝试用分层自动化避免用最后的UI自动化.
第二个是不断的调整架构, 找出更多的稳定的接口层去保证. 比如app本身其实也能分成MVC架构的.
第三个等别人出更好的实践. 比如测试左移. 在研发开发的时候, 就能识别出自动化的流程. 测试团队资源多放到业务测试和探索性测试上.

这块是行业埋的坑, 小公司的确难搞. 所以不用自动化也是对的.
包括google自己也在努力的推出新的测试框架也是为了大家能够更好的用自动化. 需不需要采用需要看具体的形式.

104
seveniruby · #32 · 2016年12月28日 作者

#28楼 @mads 是的. 因为刚入职所以不想挂这个title引人误解. 这些理念是之前形成的.

104
seveniruby · #33 · 2016年12月28日 作者

#25楼 @safe 打字打的快, 错别字太多了, 思维也秀逗了.

7606

#30楼 @safe
#31楼 @seveniruby
我感觉自动化做不起来跟公司大小好像没有决定性的联系。我见过一些公司,包括我现在的公司,虽然公司小,QA人数少,例如我们只有4个QA。但自动化依然有声有色的。应该是跟业务种类,公司的重视程度和QA人的技术水平有关系更大

3341

深深的危机感袭来。。。

2606

#34楼 @ycwdaaaa 跟开发水平关系也很大, bug多, 整天都沉溺在 bug 中了.

7606

#36楼 @michael_wang 我们bug也多,但很多跟我们没啥关系。提测准入标准是跑过自动化测试。 测试失败了开发自己去修了。不需要我们QA管

104

#34楼 @ycwdaaaa @safe 跟业务形态和技术架构有关. 如果产品能做好分层. 比如包括app自身都能清晰的分出mvc结构. 那自动化是可以的. 再一个是以各种电商活动为主的app, 活动几乎一周一变, 也的确做不起来. 但是回归测试自动化是肯定能做起来的. 需要推动研发提升可测性, 推动分层自动化. 和一些专项测试的自动化.

大部分人容易在错误的基础上做自动化, 古人也说过"勿在浮沙筑高台", 架构的可测性和技术选型很关键. 不然就会失败.

7606

#38楼 @seveniruby 恩 ,对的,所以我说跟业务种类相关么。 不管产品架构如何,回归自动化这种一般都是搞的出来的。分层自动化在UI层和接口层也不难搞。 专项测试方面我不太清楚移动端怎么定义的。如果意思是更深入的测试,找出bug的原因等。那么是需要了解产品架构的。想自动化就需要能够操控各个组件fake一些状况。例如我们公司用etcd作为服务发现和负载均衡。那测试的时候就自己去etcd上hack一些操作。或者故意kill掉摸个某块的核心进程等等。不知道理解的对不对。 总的来讲,感觉只要不是产品业务上因素的制衡。总是能找到办法去自动化的。

3331

老司机开车啦😙

1706

最近一直在问自己一个问题,自己还会测试么,看了之后真心觉得不会做测试了。。。或者说是以前的测试思维已经远远落伍了。期待下篇~

2606

#37楼 @ycwdaaaa 新的需求也能写出自动化脚本来跑吗?

11866

第一次留言,感谢老司机的文章。我个人觉得把技术基础打牢,测开和新型测试工程师互转的空间很大。技术的学习提升,个人感觉还是从代码开始比较好点,虽然学习成本大,但对底层原理的理解会更深。

10026

啥也不说了,先点个赞👍👍

9584

#34楼 @ycwdaaaa 我们公司很多都是市场主导技术部,而且很多发展方向都在摸索,很多时候都是boss决定需求,拍板发版时间,然后产品开发测试各种疲于奔命😂 自动化做出来以后可能用完一次就废弃了,完全没有价值,很多时候我们自己都无所适从,现在慢慢在转变,希望后面会稳定点

9584

#31楼 @seveniruby 我们公司之前也推过接口自动化,但是由于业务变更太频繁,接口参数也跟着变更,然后是数据库,推行了一段时间,成本太高,疲于应付新需求功能测试,完全推不起来,最后废弃了
感谢你的建议,近期打算先把代码捡起来,然后慢慢尝试下各种类型的自动化,慢慢找自己的路

104
seveniruby · #47 · 2016年12月28日 作者

#46楼 @safe 这个事情有点像设计模式和架构要解决的问题。变化是主旋律,架构,设计模式,版本管理做了这么多的改进其实就是为了分离变化和固定的东西,让变化更快更容易维护,让不变的东西更稳固可复用。这个问题不仅是app端存在,接口存在,甚至单元测试也存在。这种对变化的抱怨很多年前在代码层面就有人吐槽了,也有了很完善的解决方案。以你们的接口为例,你们需要分离做可测性提升,构建两层接口体系,对基础接口做自动化回归,对不断变化的新接口做人工测试,或者借助类似自动生成用例的工具做快速的接口测试用例编写。这样才能构建基础稳定的质量防护网。底层稳定了变化就可控,业务压力就会下来。现在测试的一个痛点就是没有积累性,对产品反复测试很多次就因为一行代码变更还得大部分回归,这是不合理的,也跟不上业务发展的需求,ui自动化也是错的。没有可测性提升和分层的自动化保证,这种痛苦就无法终结。

10945

首先 思寒写的还是那么的务实,没有太多的空头大道理,赞一个。

:性能指标度量和监控
第一层的同学在使用ps netstat vmstat top nmon等工具.
第二层的同学在使用ganglia zabbix等工具做监控
第三层的同学在使用profile工具. 比如VisualVM JConsole ByteMan BTrace AOP
第四层的同学在使用trace工具. 比如systemtap dtrace perf等.

这段我个人存在不同的看法:
ps、top、nmon等是作为资源监控工具,而ganglia、zabbix等更多偏向于运维方面的服务器监控(灵敏度差个人不觉得适合用于性能测试监控)。
profile类型工具用于针对应用程序自身或者JVM等监控,perf、sysmatap等用于系统自身的监控以及调优。
这些工具更多应在排查定位问题时根据情况使用,而不会随着性能测试工程师的技能水平提升而取代。

981500

看到思寒的文章,深有体会,我经历外企,测试开发占比2:1,到传统企业,独立测试部门,瀑布流开发方式,只有业务没有代码的测试,到现在互联网企业做测试开发,只能说世界变化很快,要积极拥抱变化

—— 来自TesterHome官方 安卓客户端

104
seveniruby · #50 · 2016年12月28日 作者

#48楼 @r455678 多谢提建议, 这块可以交流下. 我举个例子, 如果你的后台服务器有一百台, 你是没法去top或者用nmon的.
ganglia之类的系统是监控大量服务器的, 他的指标和绘图一般会延迟一分钟, 这在性能测试上是足够用的. 使用监控系统最大的好处是可以把qps和cpu mem的指标关联起来进行更好的对应分析. 比如gatling和jmeter都支持同步把结果发送给监控系统. 就是为了能更好的分析.

至于那几个层次, 你可以看下我一开始的注明.

我简单分了下层次. 层次没有高低 只是在满足第一层后人们会逐渐的开始探索更高的层次.

这是一个工程师成长的若干阶段, 不存在替代关系. 分别对应的是工具, 平台, 应用问题定位和平台问题定位几个方向.
多一层少一层, 甚至跨层成长的也很多.

12766

看后,压力山大,但对以后的职业规划也有了更具体地规划,谢谢思寒!!!

—— 来自TesterHome官方 安卓客户端

2549

感慨良多,欲言又止。。。期待下篇,感谢思寒!2017加油!

8666

感谢思寒让我看清了测试开发这个岗位,不过遗憾的是那些真正需要看清测试行业在发展与变化的测试工程师们却永远都可能看不到这篇文章,很多测试工程师都活在自己的世界里,每天点点点,没有自己的思想!

—— 来自TesterHome官方 安卓客户端

981500

#47楼 @seveniruby 这话太能理解了,我们这边固件团队,加个小功能,每次都要全面测试,一测就2个多星期,虽说固件影响面会比较大,但这样的测试效率太低

—— 来自TesterHome官方 安卓客户端

9584

#47楼 @seveniruby 感谢你的分析,你说的这些最近我也在思考,但是目前我的能力可能只能从业务方向去做部分的可测性提升,无法从接口等其他层面去把控,先学习下,再试着去摸索,最近由于工作变动,有更多自己的时间了,可以多去学学

110

文章实在太长了,应该拆分。

5890

怒赞 ,思寒老司机的车就是稳😄

96

很给力的文档,但是对部分表达方式并不赞同。比如 “ 分层 ”。 你这分层的概念很容易让人对号入座,尽管作者在阐述技术的深入层次,但有一个很重要的观点就是 现在的公司都是结果导向。白猫黑猫能抓住老鼠就是好猫,不能刻意的追求技术,而忽略测试本身的工作内容和公司赋予你的使命。
技术是测试工作非常重要的基础之一, 是之一。

104
seveniruby · #59 · 2016年12月29日 作者

#58楼 @luxiaofeng 有道理,这点我也愿意深入交流。猜到会有这种观点出现了。我的理解是这样的,黑猫和白猫能抓到老鼠的都是好猫,但是你如何解释同样都能做测试的人,为什么大部分企业会更希望要学历阅历和技术较好的人?算盘和计算器都能算账为什么现在所有的小餐馆都用计算器或者电脑自动结算?用asp也能开发网站为什么却找不到工作?

当你选择了一个落后的工作方式,工具或者技术栈的时候,不仅公司会被拖累,连自己的发展都会被波及。如果不能持续的改进自己,就会被行业淘汰。

我列举的技术,每超过一层对公司的收益都会越大,也能提升工作效率。每深入一层对质量的理解也会深入,还能看到更大的发展空间。当技术做不到做不到就降纬用低级生产力解决问题,当有更好的方案就要及时升纬提升效率。

还有一点是这些年大家老是对立技术和业务,其实在一定的层次上业务和技术是有个非常有价值的结合点的,在这个结合点上能够非常完善的区分出代码的变更对业务变更的影响范围,能通过技术的方法判定基础功能的正确性。这一层在覆盖率的下一层。做到这点我们就能对业务建模,积累业务数据形成QA稳固的业务。这样才能让最后的手工测试压力降下来。

类似的技术和思维方式还包括全链路的压测,流量对比等专项手段,也能在很短的时间保证系统的质量,这样产出的产品质量会好很多,留给qa最后的质量保证压力就会小很多。

最后公司赋予你的使命你忽略了一点,除了让质量更好也要让质量保证的效率足够快。

11712

怒赞,膜拜~

104
seveniruby · #61 · 2016年12月29日 作者

#56楼 @Lihuazhang 我把技术单独拆分出来吧。以免讨论太多歪楼

104
seveniruby · #62 · 2016年12月29日 作者

#55楼 @safe @hu_qingen 目前测试行业的现状不是我们自己造成, 相对于研发行业不断追求技术和架构的改进, 咱们测试行业对测试技术和测试架构的思考太少了. 目前受的累不过是前人不思进取埋的坑. 再不改进一旦业务发展平稳, 测试的地位和饭碗都不容易保住的.

在业务高速发展的时候, 企业会雇佣较多的人手做手工测试, 较少的人数做测试技术和架构改进, 一旦业务发展平稳, 首先被裁撤的是无法有自己业务和技术门槛的人. 手工测试的工程师群体首当其冲. 会裁撤大部分, 仍旧会保留少数的业务精英.

最近大佬们不是都在提互联网的下半场吗, 一般游戏结束大浪褪去, 就知道是谁在裸泳了.

21bdd1

看完,冒个泡。

喜欢这种务实、客观的观点文。
赞。

64楼 已删除
96

可以给自己加个精了

96

目前所呆公司QA部门正朝着测试开发方向走,领导现在已经不大谈测试质量了,只想着开发出工具或者平台。做好产品质量的回报不如做技术的回报大。似乎有点儿本末倒置

96

拜读大作,我是从传统行业转互联网,感触挺多的。形势逼迫你不断学习,进步

2441

“”早年对自己定过一个要求. 不做管理“”,很想知道是居于什么考虑呢?
我也是偏技术,但是发现不做管理有时很难把自己的设计和想法通过技术实现,而只能按照管理的想法去做事。好的想法固然很好,但是明知道不行,还得去做,有时很无奈

104
seveniruby · #69 · 2016年12月29日 作者

#66楼 @wixed 这也是典型的两大管理问题. 体力劳动为主的业务测试部门, 会倾向于多招人抬高和巩固自己的地位. 脑力劳动为主的部门, 会愿意多构造技术工具和平台创建自己的技术门槛和核心业务以树立起部门墙. 不能说一定是对还是错, 要看产出是不是足够有效, 足够大. 结果导向.

企业也不傻, 一般都是先找齐人手用低级的生产力快糙猛的拿到业务搭起来架子,然后再逐渐在"飞行中换引擎", 不断改进. 如果是纯做手工测试, 一般会出现平时很忙, 天天加班加点. 但是到了不忙的时候, 一半人就被裁撤了. 结果还是要忙起来. 业务是贪婪的, 他会不断的甩掉赘肉. 除非你运气好跳到什么垄断企业, 产品再差再慢也无人替代, 人再多再傻也有铁饭碗. 当然这就不是互联网行业了. 超出我的理解范围了.

96

#69楼 @seveniruby 大神说得对!确实就是结果导向。

104

#68楼 @fresh 我很多年前也遇到过, 不走管理的原因有多个.

  • 想多点时间去研究和做事. 做管理的变化是很多事情不能亲力亲为, 你的业绩取决于别人. 这样不仅会导致自己不能深入的做事打好基础, 还会导致陷入对外部不可控因素的依赖. 在早期我觉得自己上阵解决问题更快.
  • 预料到测试行业会整体做技术专项. 在五年前测试行业最大的瓶颈不是缺管理角色, 而是缺好的技术型测试工程师和架构师, 这个时候选择了去做管理无疑是进入一个一潭死水竞争激烈的红海. 测试架构师这个词语这几年很火, 其实是我七八年前自己创造的一个词语. 也不排除更早是有前人提过
  • 管理逐渐会扁平化, 做管理要晋升的话, 需要熬的. 如果我有车有房我会心平气和的等待机会. 但是没有的话 ,就得选择一条更快的路. 而且做管理不一定非要有管理的职位,在平常的角色上也能得到锻炼. title随时都是可以改的. 但是能力一旦错过最佳的锻炼机会, 就再也难弥补了. 所以我宁可累点.
  • 以前也是小黑客, 所以对技术更偏爱.
  • 一度因为追求管理, 心态有个不好的变化. 所以我也尽量避而远之.

不做管理的缺点也很大.

  • 会错过获得最大回报的好机遇. 如果我5年前不离开阿里, 待遇和职位都会很不错.
  • 做技术岗位的薪资始终是低于管理岗位的. 大公司相对有成熟的技术和管理体, 不会有这个问题.
  • 如你所说如果遇到领导发出错误的决策的确会很痛苦, 不过我很幸运我的领导都很不错. 而且一些决策我也能跟他们协商

对于你的问题 ,我建议是沟通解决, 如果沟通不了. 你可以记录下自己的意见和看法, 让团队和领导知晓你的担心, 然后再跟团队和领导非常快速的"错"下去.

跟着团队一起错, 也是一种值得尊敬的心态. 况且对错不一定是绝对的. 有可能你的想法也是错的.
这种叫试错. 试错不仅是表明你愿意跟领导和团队一起成长, 也能尽快的验证可行性, 从而更早的止错.
我以前也知道一些事情做错了最后还拿奖的团队, 以及个人做错了领导也要强行颁奖挽回面子的事情. 😅
试错也是一种有担当的行为, 这也是不错的经历, 走过的弯路也是一种人生财富.

104
seveniruby · #72 · 2016年12月29日 作者

#70楼 @wixed 别喊我大神, 我也是小弟. 你喊多了会导致我被人误解成沽名钓誉害我被喷的. 根据你的年龄, 喊我思寒, 思寒哥, 思寒叔都行.

6493

值得反复阅读的好文

96

#72楼 @seveniruby OK,我叫思寒哥好了

9177

想要跟着你走入测试的一条明路,而不是歪门邪道

9d7519

思寒去的上海美团?继续做测试开发还是?

46

已经是大神了、接过吧:纯粹的、落地的、实践化的美

96

#59楼 @seveniruby 这就是问题的所在,我承认技术是必备的技术,但是不能忘记我们是测试工程师,能解决实际问题的才是工程师。不准确的理念容易误导一部分同行,甚至面试的时候 经常听过的问题是: 你会不会这个工具,用没用过XXX框架。反倒没人问我们为什么选择这个工具,测试过程中遇到哪些问题,最后如何解决的?
不得不说,国内工程师也是应试教育的产物

96

#59楼 @seveniruby 我是认同你的文章的,但是这个观点可能导致:很多人按照你的分层学完了,就觉得自己是大神了。但实际就是一个只会工具的技工而已。
我觉得我们除了推崇技术之外,更应该推广解决实际问题的理念,不要被工具牵着鼻子走。

104
seveniruby · #80 · 2016年12月29日 作者

#78楼 @luxiaofeng 按照你的逻辑, 以后大家是不是提一个工具的时候都要先说几万字用的理由. 我只是罗列公司内经常用到的一些工具, 让大家看到现状. 过几年可能一些工具也会被行业淘汰了. 这个没包含什么价值观和人生观. 说实话用过相关的工具, 想不懂都难. 对于新人来说就已经可以为公司做服务了. 至于有没有深入的理解, 这决定一个人能走多高, 那就是个人的事情了. 但是如果没接触过相关的技术栈, 连面试都进不去的.

面试官大多都是实用主义, 他们需要spring的人, 你说没用过java只懂asp, 他们不会问你为什么会选择asp, 只是把简历扔进垃圾桶.
只要你的确用过相关的技术栈, 他们才会开始问你的解决问题的思路. 没有这个基础就没有公共语言了.

C4b116

受教了,黄叔叔👏 👏 👏 👏

104

#79楼 @luxiaofeng 太虚的文章我不会写. 别人自称大神, 我也拦不住. 这个锅不要让我背啊. 😂
在我没写文章之前, 懂monkey adb appium, 会写if else的不少人都自称大神了.
如果早晚都要自称大神, 我宁愿那些人能按照我说的多学点. 知道的越多会越谦逊的.
我列举了这些工具其实也是增加了这群人装逼的成本. 其实也是好事吧.

工具和技术栈上就是解决问题理念的最成熟体现. 接触的工具越多, 越能深入理解解决问题的理念的. 量变会有质变.
本质上测试, 研发, 产品都是一定程度的技工. 既然同是技工, 为什么不选更好的工具那.
所以研发们从eclipse倒腾到IDEA, 从svn折腾到git. 看起来是工具升级成为高级技工了. 实际上是解决问题的理念更好了.
工具并不简单是一个物品和技术, 也深藏了很多解决问题的方法和模式.

2203

写的挺好,希望可以转载

104
seveniruby · #84 · 2016年12月29日 作者

#83楼 @zailushang 谢谢. 我只是分享给社区的同学, 辩论交流下. 没必要跟社区外的人陷入什么口舌之争. 还是不要转了.

2441

#71楼 @seveniruby 感谢这么详细的回答。确实如你所讲,技术岗位在薪资和决策力上都存在不足,所以最近在思考是否要转向管理岗位😂

6753

怒赞! 等下篇~

104
seveniruby · #87 · 2016年12月29日 作者

#85楼 @fresh 随心就好.

13972

持续关注中,期待下篇,特别想知道老司机对于各种网络培训、网络视频有什么 样的看法

96

不错不错!

981500

#62楼 @seveniruby 嗯。其实我对咱们测试挺伤心,上次开发问我,你看的懂开发代码?我挺无语的,可能他们之前接触的测试只是简单的点点点。我真是情何以堪;侧面来说,测试必须要看的懂开发代码,不求懂太多设计模式,但至少能从开发代码中找到功能实现逻辑,不然真不知道啥时候被淘汰了

—— 来自TesterHome官方 安卓客户端

104 seveniruby 将本帖设为了精华贴 12月30日 12:37
104
seveniruby · #92 · 2016年12月30日 作者

加精理由: 借着热度宣传下社区的微信号

214

已封神😙

50

💪 认真的看完了,字字玑珠,对我这样的新人很有帮助。

BTW:为什么大家在讨论自动化测试的时候,不自觉的就往UI自动化上靠呢?按照思寒的说法,自动化应该采取分层的办法,尽可能的往上游去推进,这不但要求测试人员有足够的技术基础,还需要在项目团队上有一定的要求,比如研发团队本身对自己的代码质量就有一定的要求,这样对测试人员的沟通技巧和执行力、推动力就有一定的要求。
自动化测试可涉及的方面从代码底层到最后的线上监控整个链路,有很多方面可以入手,测试人员本身的质素非常关键。
另外赞成 @ycwdaaaa 的说法,自动化做的好不好,其实和公司规模没太大关系。

3170

很赞的经验分享

1517

感谢叔的文章受益匪浅。感觉测试已经不是狭义上的确保产品质量。而是在有限时间内确保产品有更高的质量,同时长时间给予产品质量反馈来改善优化产品。技术能实现测试的测试策略和想法,同时也能扩展测试的广度和深度。但测试思维和业务能力也是必不可少的利器。然后,就会发现好多要学习的,不多说了,搬砖去了。PS:为什么没有赞赏入口?

104
seveniruby · #97 · 2016年12月30日 作者

#96楼 @xwgoss 你够了. 😂

96

期待下篇~

1065

这是因为他们做的事情脱离业务目标太远. 一旦完成目标, 他们也容易被"管道化", 成为边缘角色.
这个行业除了极少数技术的狂热爱好者, 能够找到自己在行业的技术地位外, 大多数人都应该去追随业务的发展. 业务才是测试的根基.

强烈共鸣,业务才是测试的根基,把这个观点明确出来真是造福刚入行测试三观还没形成的同行了。单纯的追求工具平台而忽视其对于业务的实际意义,真的是有点本末倒置。与其追求别人眼中的高大上,还不如利用很多已有的工具来实打实的提升测试效率,用已有的工具、平台,如果架构的好,设计的好,不管是成本还是对业务的质量保证意义应该比自己去开发工具平台都要好很多了,开发的不好还得改自己的bug不是?

10693

@seveniruby 没必要把之前提到的工具编辑掉啊,可以作为附录给人参考嘛,最多去掉第x层的说法,改成序号,再加1句“排列顺序不代表更难或更先进、各个工具都有自己的适用场景、将来可能过时、重要的是背后的思想”blahblahblah😀

难得有大公司的老司机出来提几个名词,对大家选型肯定有帮助的。真的一个不漏查过资料的人是不怕被“误导”的,有这个视野有对比要找到适合自己项目的花不了太多时间,倒是完全不知道有更好的才很可能在不合适的技术上浪费时间,“在屎上雕出花来”

都2016年了,很多童鞋不想一直做纯手工,但听说过的全是n年前的名词如QTP、loadrunner、winrunner之类……多数人这个阶段最需要的是知道去哪里找枪,不能一直拿小刀甚至空手,被人虐成渣

至于拿了枪会不会开,打不打得准,以后人人动力甲了会不会去找新装备,那都是活过今天之后的事了

7782

感谢前辈的分享文章,让我了解了一些关于测试行业的历史,现状、以及未来测试行业的发展;现在的我对测试这个职业有时候也会感到迷茫,也会常常去思考自己的职业发展...

185

黄老师新作,拜读啦:)大大的赞。

12218

测试行业经过自身的净化洗涤会有新生. 典型的变化就是薪资从以前的3k-15k的范围, 整体提升到1w-3w之间. 主要是房价也涨了很多倍,然后公司的业绩也增大了很多倍

104
seveniruby · #104 · 2017年01月04日 作者

#103楼 @cobbxia 你可以统计下除去测试开发工程师群体之后的薪资水平.

2019

深度好文,受教了

1898

😀😁 通读全篇,受益匪浅!感谢黄老师经验分享!

12218

#104楼 @seveniruby 不少大厂喜欢从小厂里面找开发,让他们做测试倒是真的。互联网企业测试技术发展和人员发展也是挺快的,未来人只会越来越贵。记得十年前狼厂主推自动化测试的时候,就由cto发表了一系列言论,意思是公司QA只会做手工测试,测试周期太长,以前招聘的门槛太低,要提高招聘门槛要提高测试待遇。公司业务的发展,也是有生老病死的过程,业务启动的时候做为一个demo可能就不需要测试,发展到一定程度用户激增的时候产品体验就很重要测试的价值也很明显,到了产品的稳定器,测试框架本身都固定,添添补补用例的事情,自然是谁可以做。专职测试投入。测试和产品一样存在生老病死的周期。测试这个事情本质上是怎么根据业务发展阶段,去针对性的制定质量保证的解决方案,选择用人去堆业务,还是选择自动化的层次用技术方式实现,都是具体测试策略,策略本身也依赖技术选型和技术工具,依赖于团队的技术实力。

1279

感觉测试行业的管理基本是打杂的,说起来是个管理,实际上并没有做真正跟管理有关的事情,但是技术又被耽搁了,因为杂事太多。而高层测试管理,老实说,管人的时候还行,千万不要开口聊技术聊业务,真心肉食者鄙。

11419

说得蛮多的,很多挺有道理的,但是测试重要还是开发重要这个问题总体上来看,当然是开发。而做测试开发的真是高不成低不就,门槛低的方面,没法接触具体业务流程,学不到业务相关知识,除非刚好参与一个大平台的开发,会有机会了解。门槛高的技术方面,又不好突破,比如我坐iOS的自动化,做UI工具的自动化,这些东西底层无非是调用接口,真正比较复杂的是构架和封装,然而学完这些又要学啥呢。出去跳槽的话,开发方面业务肯定要东,测试开发不懂,技术方面又要结合业务,测试开发不懂,所以测试开发真实坑,大坑,做测试开发的同学,如果是技术方面转过来的,尽量不要脱离之前方向,然后趁早别在测试开发待太久,不然会废,这是我的观点。

2985

写的非常棒,提到的两点表示非常赞同:
1、关于测试人员的技能之一,要懂架构. 能够跟研发和产品进行正常的交流, 保证产品需求和实现都没问题. 能带团队走上更好的发展,现在测试部门被打散,为了效率,测试被分到各业务线上,这个技能就显得非常重要,通过测试+其他附加属性,能然测试如虎添翼,将岗位价值最大化,达到最终带领整个项目的目的;

2、关于测试开发岗位的发展,具体做测试工具工作的岗位会开始衰落, 因为他们做的事情脱离业务目标太远. 一旦完成目标, 他们也容易被"管道化", 成为边缘角色。在一个公司的部门工作,一定要具体参与部门核心产品的工作,脱离业务就意味着个人发展的偏航。

3474

#23楼 @seveniruby 我一直不知道如何更好地发展测试,在我们公司 UI层,接口,集成等自动化测试都尝试过,但我没觉得这些测试策略给我的测试工作带来了多少便利,没给我找出多少bug。目前找bug主要还是手工点点,性能压测。想请问下像我这样的,该如何寻找出路?怎样找出更多的bug

2562

#111楼 @xiaoli
自动化测试的最主要目的不是找问题吧,主要是节省人力和保证系统稳定性

3474

#112楼 @carl 我想如何能找到更多的bug呢?我们现在99%的bug 就是手动点点点

104
seveniruby · #114 · 2017年01月10日 作者

#112楼 @carl @xiaoli 自动化测试目前的用途主要是用于回归测试. 发现bug他不胜任. 目前后端测试可以做到用自动化发现新需求的bug. 但是前端和移动端还是要靠手工测试来发现bug. 将来监控可能会代替一部分手工.

3474

问下有涉足 单元测试 和 安全性测试的不?单元测试的用例如何设计执行?安全性测试,我知道SQL注入,还有什么更好的测试方法不

3474

#114楼 @seveniruby 我们后端是没有UI界面的,那么该如何自动化测试呢

2562

#113楼 @xiaoli
这个比例太高了吧,我之前做移动端自动化测试,自动化发现问题比例在5%~10%之间一般。

104
seveniruby · #118 · 2017年01月10日 作者

#115楼 @xiaoli 你这是打算把我当保姆啊. 要自己研究探索. 你问的问题都有解决方案的.

14276

思寒大大,都在谈业务能力,那么什么才是测试应该具备的业务能力?

Ee76af

@seveniruby 不止是保姆啊

96

我就跟喜欢做跟业务有关的测试,甚至校验异常数据单纯做sql校验也可以,但是真的不喜欢整天存跟代码打交道,虽然我自己也接触过一段时间的代码,发现真的不适合;做管理吧又不喜欢整天乱七八糟的事情打扰到自己 也挺纠结了

96

文盲定义的很精辟

5062

叔(划掉)哥,测试需要掌握的技术主要有哪些方面?要深入到什么程度?有书单吗?

5864

老司机就是有墨水

96

最近一直都想来论坛看看每个人2016的经历和总结,以及对未来行业发展的讨论,今天看到你写了这么多感觉写的很实在,看后受益匪浅,我觉得测试还是把技术做好事关键,因为现在大多数公司要求普遍较高,动不动都是招聘测试开发的,即便不是测试开发你面试的时候也要考你编程的题,要不然你就没机会进入该公司了,至于更好的公司就更需要好的技术支撑,如果没有好的技术一直在小公司混感觉就看不到前景了

104
seveniruby · #126 · 2017年01月12日 作者

#125楼 @SkyFly_006 你这句话说的很实在, 这就是我为什么回复 #58楼 @luxiaofeng 黑猫和白猫理论不合适的原因. 笔试都过不去一切就免谈了.

12195

要学的东西很多,感觉这也是为什么踏上测试之路的原因,希望能够不断学习,技术带给人的愉悦感真心很赞,但是不会的挫败感也是非常的强烈,愿新的一年好好学习,不断进步,一小步也可以

7315

@seveniruby 你的文章写的很不错,值的深思。 文章中你提到了学历很重要,像我们这种学历一般,学校也一般的人来说,有什么提升的办法吗? 例如在职研究生是否也是被很多大公司认可的?

104
seveniruby · #129 · 2017年01月13日 作者

#128楼 @ivy520 我学历也一般. 能力同等重要的看学历. 学历弱点就只能靠能力来补充了. 除非是特殊情况, 比如一定要进名企国企什么的, 那学历还是要针对性的补充下.

96

#116楼 @xiaoli 后端说的应该是后端API测试,API自动化是可以做的

7315

@seveniruby get it . 非常感谢。

14276

还是说点吧,看了5遍,感觉就像是远处有盏指路明灯,无奈自己找不到现在的路。现在上班2个月了,公司不大,研发13测试就我一个,没人带,基本靠自己学,像很多刚毕业的大学生一样迷茫,不知道前方的路怎么走,看别人说测试要懂业务,于是开始学习公司业务,尝试融入流程,从需求开始,想融入研发,学习单元测试,看代码和练习数据库,按照我的性格,是既不愿意跟外人交往的,但是毕业后就尽量让自己去融入圈子,去多讲话,多交流,你说的闭门造车,见识短浅,也许因为年龄太小,也许因为资历太短,提出的意见,说过的话也基本是付之东流,我是极其不喜欢点点点的,我喜欢代码,但是面对看不懂的代码,我也是无计可施,开始学python,也只是能简单的写个小爬虫,最近在学unittest,论坛里看了不少帖子,也犹如观望大神一样,门童望而止步,做不到借鉴,更做不到建议,有朋友建议先学一年的功能测试,再慢慢转性能或者自动化方向,对于性能我也只是粗浅的了结吞吐量,延迟等,会使用一点ADB命令,会查看日志,简单的使用MAT分析,虽然目前的点点点可以满足公司的基本业务要求,但还是不满足,思寒老大,这两年我该怎么去打好自己的基础呢,我真得特别反感天天熬日子,但现在的我基本天天熬日子

104

#132楼 @B1ackcat 年后社区会加大教育投入. 开设更多的免费公开课, 教程和商业课程出来. 把BAT的知识总结梳理出来传授给更多人.

4817

@seveniruby 思寒哥😄 努力转型中,痛并满怀期望。。。
还是非常认可你的说法,坚决转技术路线,前一年多做了较多的业务,技术本来就不好,这下落的更多了😂 ,后面要多向各位技术大牛交流取经🙏

5223

小公司搜索测试,测试研发比1:15

—— 来自TesterHome官方 安卓客户端

13972

还会有下篇吗?

96

看收入,害羞的退了

11444

看完了,入行已有两年,已经感觉到瓶颈了,也想更深入的在这个行业发展,奈何自学能力不好,有时候挺迷茫的

96

#132楼 @B1ackcat 准备转测试行业,可以聊聊你最初怎么入手测试的吗?

3759 fir_im CI Weekly #12 | 微信小程序的自动化测试进阶 中提及了此贴 01月19日 10:57
7967

写得太好了

96

学习了,有见解。

96

受教了!

96

赞赞赞👍 👍 👍 👍 👍

13593

思寒哥,请教个问题啊。我是测试业务功能方面比较多的,去年这一年自动化这方面比较感兴趣,也自学了java写了一些自动化的脚本,但是编程水平较低写的自动化脚本也不是很好只是能用在简单的业务场景中,也没用什么高大上的框架(而且有的实现还是找开发帮的忙...)。看了你上面写的技术路线的建议还是有点迷茫,想去提高自己又有点无从下手,感觉只是看那些编程的书籍都是开发看的啊,对于我有点大海捞针的感觉啊 ,实际中能用到的点不会很多吧?(不知道这么说合适不合适..)。能不能在这里给推荐一些比较好偏向测试这方面的书或者视频什么的啊?对了还说件事,我年前换了家公司,来了这边目前负责的主要是IOS APP的测试,我之前没怎么接触过移动端的测试 而且上来没多久让我测播放器的SDK,我又不懂OC,当时真的是无从下手,别的同事是测pc端的业务的,问他们也没用,在网上查播放器SDK的测试方法也没看到什么有用的。最后开发给我写了一个调用SDK的demo,结果又回归功能测试去了。

104
seveniruby · #146 · 2017年01月23日 作者

#145楼 @yefnegjun 技术发展路线和参考资料, 我年后写吧.

13593

#146楼 @seveniruby 好的,辛苦了!发现这个社区以后对我的帮助确实挺大的。本来身边能答疑解惑的人就比较少,有一两个关系比较好的同事,但是我们水平都差不多。在这个社区问了几个问题都有兄弟帮忙解决了,期待你后面的文章。

14565

还是习惯叫seveniruby。。几年前就在各种论坛看见你了 还关注了- -

14604

#69楼 @seveniruby 看到你后面两句,感觉就是说的我的现状,我现在在Nokia做嵌入式软件测试,属于通信圈和IT刚刚沾点边,
我们组20人左右,只有我一个测试的,虽然我们这有CI的概念,但是大部分还是依靠手动或者我自己开发的(python脚本)半自动化的工具来做。最近刚刚有几个新手加入,但是年龄比我还大(我86),都有娃娃(女),平时生产力就是半个人,我们这因为外企嘛,CI的核心团队在国外,我这算是一个mini分部(全靠自己学习,总结,改进),我也尝试把自己的工作用各种框架或者更加自动化的东西优化下,但是没有一个给力的搭档,一个人干太不爽,其他新手还是维持着oprator的思维,一合作就变成我单方面的教,他们没有探索的内驱力就想吃现成的,这样挺没有意思的。并且外企的总部的人处处防着你学习他们的核心的部分,所以我们现在大部分工作还是处于手动的低端阶段。我总感觉我们这里做这个软件测试low出行业平均水平了,想过跳槽出去。老板给我说让我做Test Leader,做管理. 我却感觉是个深深的坑,因为本身自己技术能力就很有限,同时薪水就没给够,说这些大饼的东西是很无聊而且流氓的。最近想跳槽,为的是自己一颗做技术的心在这里无法发展应用,同时我发现外面的测试Job大多是WEB产品,或者大数据产品,看着都很不错,面了几个, 发现要求的技能很多,我短时间内不能fit. 现在深深地苦恼中,担忧未来的发展之路,同时我也在加班学习些东西。唉,入了通信测试这个坑,出来不容易啊

10406

看完很受启发,本来就是技术人员,不懂技术肯定会被时代抛弃,所以跪求技术篇,现在25岁,入行测试1.7年。现在努力,大不了大器晚成!

96

有帮助

96

注册第一次评论,看到这样的文章,三年半手工测试渣渣,都快落泪了,大神,请收下我的膝盖

40afac

新的一年新的迷茫,我还是先减个肥吧

40afac

#152楼 @pai_sen 实习+正式,我也是三年半手工测试渣渣,找工作被鄙视好多次了,不知道该好好学技术还是转个行呢

96

读完之后对测试行业的发展又有了新的认识!以前只知道是同路人,这才发现我们还是同龄人,很佩服你在这个行业的成就,也给自己在这个行业继续发展增强了信心,希望有机会可以共事!

10132

斯寒,我想听一下你对关键字驱动的理解(提问背景:数据驱动的UI自动化投入太大,想节省开发成本),在线求助

954157

加油~!大大的赞, 坐等下篇~

12148

受教,学习了。没人带,成长慢

13165

这篇文章得多读几遍,我也进测试五年了,总找不到前方的路在哪里

2c8322

同不看好测试开发工程师,
一直区分不出测试开发工程师和二线开发的区别。
做内部工具项目混吃等死。

96

感谢分享。向楼主多学习,感觉还得多看两遍包括评论。

96

值得学习,给个赞

96

可惜现在大家都不重视业务,觉得做业务测试没前途,只有做工具做平台才能晋升,老板也只看重这个。

833435

在一家类似国企的公司做了5年测试,因为公司效益不好,迫不得已出来重新寻找机会。才发现自己的技术和思维已经脱节。在后续的职业发展考虑是否该转管理而迷茫的时候,看到思寒的文章,顿时有如醍醐灌顶。想起当时很多朋友转市场时,只有自己坚持从事技术岗位的初心,感慨不已。舒适的生活会让自己停滞不前,重新拾起当年的java教材,坚持初心,与君同行。

—— 来自TesterHome官方 安卓客户端

Fd941d jesseChina 在外包公司做测试的一年 中提及了此贴 06月14日 19:03
2985

过一段时间又来看看,每次感受都不一样。。。

E39152

在一家类似国企的大公司温水煮了N年(N>=10),现在要重新开始定义自己的职业了。
以前每天都忙于加班,加班,加班,觉得自己把测试工作(也就是认真的点点点)做好,尽量多发现bug就足够了。
但是半年考核老大明确的说:你多发现几个bug,还不如弄一下别的东西,比如想办法让开发进行单元测试(我们的开发不单元测试的)。。。
我也觉得如果出来会混不走,幸好虽然年老,但仍然觉得自己还想学习,不怕学习。。。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册