说的都堆，测开重点是开，如果做的是测，建议换公司
前提是自己真的能开发，过面试关

测试开发有哪些好玩的技术落地，业务不同，感觉技术局限性太大，而且左移右移抢了运维和开发的活，老板为啥要让你干

确实是很尴尬，我目前也差不多这个状况，工具开发全部是利用自己的业余时间。
平时尽量去挖掘目前测试上的一些痛点，搞一个能够确实提升测试效率的工具，这样也许会让领导看得见测开的成果。
不过，可以换个角度想想，搞工具算是为自己以后跳槽加分。

我就是这样的，虽然是小公司的测试，但是我写了工具后效率确实大大提升了，每天能省下大量时间学习。

一阵一阵地，切忌浮躁。业务不会一直都忙的，而你的工具不能脱离业务存在，就当是一个熟悉业务，了解需求的过程吧。

开发还 CRUD 呢

我入职当前公司已经快 5 年时间了， 头 4 年其实都是一边做业务测试， 一边开发工具和写自动化测试的。 这种情况避免不了吧， 对于大部分团队来说还没奢侈到专门能养一批只开发工具不做测试的专职人员。 所以很多人包括我自己都会遇到楼主这种情况， 业务太忙，没有多少时间来做自动化测试和工具开发。

所以我建议楼主跟我当时一样， 就集中加班一段时间， 把自动化测试补上， 这段时间虽然你会很痛苦， 很累。 但是如果熬过去了， 你的自动化测试能节省你很多的时间了。 那么你就进入了良性循环了， 可以有更多的时间去做技术相关的东西， 同时技术相关的东西又给你带来更多的效率提升节省更多的时间。 这样你就越来越有时间去做测试开发的东西。 其实我当时就是这样的。 当然如果你极其的忙，天天忙业务都要加班到很晚，周末也加班，根本没得休息时间。。。。。那当我没说吧。。。。那就没什么办法。。。

我想问下各位大佬对测开工具的定位是什么？ 1.仅仅自己能用到的代码，2. 可以提供给开发一起操作的的 web 平台 3.或者其他什么的？？

其实更想知道是不是整个互联网测试行业都在从提质向提效转变，把效率作为测试开发的 kpi，质量比重低一些，牺牲部分质量提高效率

总监说了，测试就是测试，工具开发找个做开发的，比你做的还快，不要跟开发比开发。什么测开，干好本职测试工作，只是有代码基础的测试他又认为能力更强些。
很多时候，上面也是相互矛盾。

有能力有决心，早跳早解脱。当然一般来说应该更累。
做初级测试基本不用动啥脑子，初级开发稍微多动一丢丢。

我也想知道

孙总一开始做的自动化是只能自己用还是其他业务测试也能用？

其实有些公司招测开,是想要他能过来直接落地新工具的 而不是让你在他的公司在慢慢写 公司想的是你已经在别的公司实践过了 然后直接带入新公司

目前市场普遍称测开，实际上就是以前的高级测试嘛

只是变换名称更有吸引力，实际上主要还是业务，甚至一版版你永远做不完，没有多少时间开发

市场上不做业务的开发工具的还是挺少的职位，建议如果有决心不做业务就要在面试的时候问好工作情况，如果有业务测试就不去，只不过这样就难找了

你们根本不懂领导的想法 我们公司包括别的很多公司招测开 要 3 年测开经验的 都是想直接捡现成快速落地 所以初级测开在公司眼里其实没太大价值

一开始做自动化就自己的小组用， 只减轻我们自己的压力。 我那段时间忙的要死，哪有闲心去管其他团队的 QA。 这玩意就是别一开始就胃口那么大， 上来就要整合所有团队的。 先把自己的问题解决了再说。

其实就是这样的， 而且自动化本身被发明出来的时候，更多的主要就为了提升效率节省时间的， 我的理念是只有解放了 QA 的时间， QA 才能去思考更多的提升质量的手段。

每天业务测试量贼多，做工具又得加班做，想做工具不给排期

想问下楼主，你的业务测试量和团队里其他没有测开 title 的相比，是一样的吗？如果是，那感觉你领导没把你当测开来用，如果不是，说明领导其实已经在尽自己所能给你时间了。

不过业务测开这个混合名称，个人理解其实和高级测试差不多，重心还是在业务测试，所以才加上业务两个字。这类岗位一般定位是用好工具提高效率，自己要开发或者二次开发的工作量应该并不多，而且也不会对开发工具有太高要求。

1.工具开发和业务测试并行应该是很多公司常见的工作状态，除非有专门的工时养你们
2.前两年做工具平台是 5 5 开发，目前这两年能 9 1 开就不错了，学会自我调节时间，再非饱和时，投入工具开发
3.要么学会接受，要么走~ ，越往上事务越来越不单一，单线工具是不可能的 业务测试 ，旧工具运维，运营，新工具平台开发 ，培训 等~
4.工具开发，建议由小到大 ，一开始人员不够，工时不够，盘子开的太大，成效输出太慢，领到认可度就容易降低，先产出 mvp 版本等，报告诉述成效，推广等，上级认为，这时可以去协商工时，可以由 9 1 8 2 开，调整为 4 6 5 5
5.工具服务于项目，从项目中来，到项目中去，在项目中落地，也就有成就感，更多动力持续下去。

先开发点把自己解脱出来的工具。一来就为别人开发，吃力不讨好。

核心问题是工作越来越杂，如果职位没有提升，眼界没有提升。
随着年龄增长，技术没积累，人脉没积累。怎么办？
工作不一定就会带来成长，可以成长的工作是相对较少的。大部分情况下，都只是一个人力罢了。

我觉得我们团队的现状算是比较贴近大部分的情况了： 公司小团队也小， 所以没有资本养专职的测开，都得花一部分时间跟业务。 所以我们的做法大家可以借鉴一下， 我们也就是在 16 年的时候吧， 其实根本就没想测开不测开的事， 也没想着开发什么高大上的工具平台。 我们开发的所有工具， 写的自动化代码， 都只有一个目的就是解放我们 QA 的时间， 因为我们那时候就 2 个半 QA 在干活，解决效率问题是第一优先的。 所以我其实当时好大的精力就是在积累 case， 一个 case 一个 case 的写， 功能全回归测试从一周时间缩短到 3 天再到 1 天。 当然我估时的时候肯定不是按一天估的， 我会估个 2，3 天的留做 buff， 如果自动化出了问题 (环境,代码) 那么有 buff 去解决, 如果没出问题那么我就多了 2 天时间做自己要开发的工具。 自动化越给力我自己的时间就越多，然后我才能去开发别的东西。

所以建议大家一开始别纠结测试开发这个 title， 先以解放自己的人力为目的去行动。 不要嫌弃写 UI 自动化，接口自动化 low，因为你不做好这些基础的，你就没时间去做那些高大上的。 连我自己在那 2，3 年时间里的一半精力都在写 UI 自动化这种大家都觉得 low 的东西，甚至今年有一段时间我也在写。 所以心态放平和一些， 先做对自己最有用的再去想其他。

一半认同一般不认同。

成长更多的是靠自己，利用好机会，每个工作也是可以带来成长的。会给你主动带来成长机会的领导或公司并不多，所以更多还是要靠自己主动。

脱离了业务的测试开发也没有用的

我现在就干的运维开发的活,比较尴尬的是,干的没有专业的好 ,勉强混着吧,能混下来也不错

个人觉得，测开的目标在于：
1：不求人。我见过不少程序，自己写的代码不够严谨，也不是什么牛人，但就是鄙视测试。一旦涉及到指令或者与测试相关工具，就要先说一下这个可以测试做啊。然后业务测试（小公司真的测试全部时间几乎压在业务测试，而且上面流程很乱，底层测试压力很大）要么没时间做，要么会做的也要查一下多费一点时间，最后当然是程序做了，然后就以为功劳在他身上了，似乎他帮测试搞定了什么东西一样。我自己私下做工具，也不告诉人，有需要用的，拿出来用，不求人，也有说话权了。没有给大家用的到的，那自己留着用，也许工具还可以留到下一家公司一起用呢。
2：偷懒摸鱼。一般都是按照正常业务测试去估算测试时间，然后工具提效，缩短的时间用来偷懒。逛论坛 testerhome 等，看到不错的技术和思路也试试，或者有新的工具想法也搞搞。
3：厚积薄发。当你 docker、k8s 各种能吹也能拿出一点东西（比如做过之后写一些笔记啥的），或者其他（性能测试、安全测试）能够做出一些东西的时候，你已经不会输给那些天天写逻辑代码的程序猿了（当然主程咋不敢比）。这个时候你会发现，项目对你的依赖程度，已经不低于那些普通的码农了。

至于时间问题，我想说，孙总说的对，进入良性循环，是很关键的点。一旦达成，你会慢慢拥有时间的。
至偏向开发的测开，我觉得是有危险的。公司的一切都是服务于业务，需要你拿出工作成绩。业务测试最能积攒基础成绩了，它能保证你活下去。偏向开发的测开，在大部分小公司，容易陷入死角，不被重用。

测试开发，重点是测，公司招你也是为了测，测试是目的，开发是手段，测开就是利用开发的产品来做测试，关键是你开发的产品能达到人工的效果，提高效率，而不是把自己当一个开发用。

测试开发本就有测试的职能，核心价值仍是保障软件质量。在重复性工作中寻找高效的手段，不断提升质量，提高效率。

大佬感觉你抢了运维开发的活，以后可以干运维开发了

运维开发比测试开发好玩把，技术栈也差不多

我的版本：

工资又不涨啊，工作内容对个人又没有帮助啊。我都起的比鸡早，干的比牛还多了，上下班的地铁上还不让我刷会儿剧看会儿小说么。到家了洗个澡就该躺着睡觉了啊。都怪公司不给我专门的时间来学习我不懂的东西，就一直迭代迭代。迭代个锤锤儿，每个鬼用。我的大好光阴与大好前途就这么被浪费了。哎，还是跳槽吧。我屮艸芔茻，一坑更比一坑深。

别人的版本：

问：为什么比我优秀的人，还比我更努力？
答：心向光明，才能求得光明

大公司有测开 title 的和普通测试啥区别？感觉都做业务功能？不是说功能测试都外包了？

怎么说，如果一家公司的给你机会做工具，就会给你时间。如果一家公司只是让你做工具，没给时间。那就是白嫖你的。不过换种方式想，不管什么原因你没有走，那就好好做一下工具。然后等待时机跳一跳就会更好了。

第一点真实

不是所有的都外包了

并不是所有功能测试都外包，而且很多时候大公司的非外包测试 title 都变成测试开发了，但并不一定全都是做我们通常理解的开发工具的测试开发工作，也有一部分实际主要是做功能测试的，只是都会有代码能力要求，不是纯功能。

小团队没有钱养专职人员，所以我干的活比较杂， 测试和 devops 的活我都干， 除了搞运维开发的东西以外，其实测试工具什么的我也搞了一大堆。

孙总能不能列举一两个测试工具啊？没有工具时手工怎么做的？用工具后怎么做的？

就比如混沌工程的工具~~ 以前没开发出来之前是手动注入故障， 就是用 k8s 的命令行去杀 pod 或者登陆到容器里面用 iptables 和 tc 命令与模拟断网和延迟的故障。 验证故障影响也是注入故障的同时手动去跑 case，这种就只能测试几个主要的场景。 后面开发工具了以后都是几十个模块的故障注入和累计 1 百多轮测试全自动化搞了。

你这就是个测试，不是测开

听完更不明白了。这是在做测试工具还是在做自动化测试啊？呵呵

怎么想你都随意吧

高飞大佬觉得运维开发怎么样呢

我觉得挺好的啊， 我有一部分工作搞这个

以前我跟你想法一样。但是发现当你用自动化节省了业务测试时间后，你会有更多的业务要接。。

不是每个公司都是业务有限的。有些公司业务的量非常大，看到你能力在增长，能接住现在的盘子，就给你更大的业务盘子。还是在做业务。。

我个人认为,现在去做 UI 自动化的平台是浪费自己的生命, 这种东西 testing 等公司已经有成熟产品了,如果公司舍不得买又非要你去做,建议换公司.....

我上面其实提到过的。 原来要 5 天的测试时间， 加入了自动化变成只需要 2 天了， 那你就按 3 天或者 4 天估时。 让大家知道你的自动化有成果就可以了， 你别这么实在的真可丁可卯的估时。 要知道10 分能耐用 8 分， 能耐一下子都用尽了你以后怎么办？

我们现在有个产品线 UI 自动化已经 2000 多了， 以前手动测试需要跑一周， 有了 UI 自动化后现在一天时间跑完。 你觉得是做 UI 自动化浪费生命还是不做浪费生命呢？

量是有了，质呢，也就是效果呢？自动化覆盖到的功能点出了问题有没有检测出来？

现在 2000 多，还有多少等着自动化？目前自动化覆盖率多少？

检测出来了啊， 凡是被自动化覆盖过的场景， 人工都不在去重新运行了

新版本新需求来了的话，就去写新的 case， 没有新需求或者新需求不适合自动化就放那。 自动化覆盖率你指的是哪种统计方式？

假设用例总量是 1000，其中 800 个可以自动化 (任务)，200 个只适合手工，自动化掉了 160 个，那么自动化覆盖率是 16%(160/1000)，自动化任务完成进度是 20%(160/800)。

那我们这个业务线自动化覆盖率在 95% 左右， 刚才刚问了一下测试 leader，他的回复是基本都覆盖了， 但是考虑到实际的情况可能不会那么理想，所以我觉得 95% 这个数字比较合理。

看来你对你们的自动化测试比较有信心，希望这不是盲目的乐观和自信

已经过了有信心的阶段，而是到了已经大范围落地并取得了很好的效果的阶段。每个团队都有自己拿手的特长， 在没有了解前不要随意的否定。 在某些公司 UI 自动化没做起来不代表其他地方 UI 自动化也做不起来。 你可以分享一下你们那边 UI 自动化遇到的困难，我们讨论一下是否是某些产品形态或者团队迭代方式不太适合 UI 自动化， 一起总结一下经验。 UI 自动化这个技术发明出来到现在已经 10 多年了，selenium 官方团队到现在也一直迭代更新，就说明他是有使用空间的， 我们别把同行都当傻子，如果 UI 自动化真那么不堪同行们还会傻乎乎的一直在上面使劲么， 老板们会真的人傻钱多的往里投钱么。 官方团队还会坚持开发 10 几年么。

我明确的告诉你，可以测出来问题。

解放了自己和同事，然后发现自己和其他同事上班划水的更厉害了肿么办

飞佬，你们 UI 自动化测试覆盖度那么高，接口自动化还做吗？

也做 ，但比较少。 只有部分产品线有接口自动化。 接口自动化这玩意要看产品形态和研发模式的。 不是什么情况都无脑做接口自动化的。 如果你们各个模块没有解耦和拆分清楚， 没有独立的迭代周期， 也没有持续集成， 这时候就跑去搞接口自动化， 那无异于作死。。

自己和同事有时间划水了那不是好事么。。。。。。