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

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

我们的 case 大多数都没加入数据驱动， 也就是你说的参数化。 因为现在业内的单元测试框架中对于并发的支持，最细粒度也是方法级别的，同一个方法中的不同参数是串行的，没办法并行。 一般情况下这是没问题的，并发模式不需要细粒度这种程度， 但是我们的 case 比较特殊，都是大数据和机器学习的训练算子， 一个 case 跑上几十分钟都是有可能的。 所以要是用数据驱动的话，那一组参数都是串行跑就没办法接受了。 所以我只能是放弃数据驱动， 拆成多个方法来提升并发能力了。 这个是我们项目的特殊情况。 对于你说的参数化，我们其实是直接用了 testng 的 dataprovider 来写的小工具完成的。

其实如果你用的是 pytest 那么 pytest 的 parameters 也是可以完成你说的参数化的， java 的 junit 和 testng 也都有对应的数据驱动功能， 你直接用就好了。

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

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

实际上， 其实我现在一部分工作就是做运维开发。 但是讲道理论天花板和工资， 妥妥的正经八本的企业的后端开发最强， 可以一路做到 CTO 的程度。

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

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

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

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

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

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

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

我们的业务没有录制回放的需求， 所以没太研究， 你能分享一下么？ PS: 创建这个期望的代码能贴一下么

还有这个坑呢。 我还没碰见

应该是配置错了吧，我这是可以路由的

是这个 mock server 直接具备的功能，不用二次开发， 它启动的时候可以设置 proxy 模式， 填写真实服务的 ip 地址和端口号。 我 go 的代码只是把 mock server 注入到了我们 k8s 集群里了，只做了这一个事而已。

看你的描述我觉得它的能力是符合你的需求的。 不过你们是什么场景需要这个能力的？

都行，看场景需要

你搜标题就行了吧

emmmmm .... 怎么说呢， 因为是存在很多复杂场景的接口测试的， 它不是能用简单的方式解决的。 也许你面对的场景就是发一个请求然后验证返回的 response 就行了。 但是很多人面对的场景比这个复杂多了。 比如我们这里的接口会调用 k8s 去动态的起一个 job 或者 service。 这个光验证返回的 json 是不行的， 我们需要调用 client 去访问 k8s 查询这个 job 或者 service 是不是正常的运行了。 同理还有各种其他的中间件需要查询验证。 所以 postman 怎么能搞这个呢？

好机会~~ 我觉得可以去。 大数据学好了可以进大厂拿一个不错的职级。 现在懂大数据的测试人员还是满少的。

既然点进来了就不能当没看见~~ 来吧~~ 我来承受第一波火力 前几天还有人说我现在算是网红了

就感觉前景挺好的呗， 现在企业都是数据量越来越大， 随着 AI 的落地，大数据技术也越来越重要。 不过一般的互联网公司还是没有这种岗位的。 现在看在测试领域里还是小众一点

后面还有 UI 自动化里常用的设计模式， 你也可以看看

其实~~ 在线上压测是正常的~~ 别说线上压测了~~ 我连直接拉线上环境的机房的电闸这种事都干过

你可以翻翻我以前写的 UI 自自动化军规和设计模式

其实最好你搜索控件的时候，用 id， name 或者 className 这种一看就知道是什么的方式定位。 但如果你们研发根本不写 id， name 这些属性的话， 那就只能用注释了. 或者你写个简单易懂的变量名