流马测试平台吧，2c4g 就可以

那可不一定哦。定制化不单指对公司业务熟练，还要适配公司的基础建设，持续集成，测试人员的基础能力。当然业务适配也是一方面，但并不需要达到对某个业务很熟练，更多的是整体业务架构的适配。对业务熟练需要的是测试基建的使用者，开发者需要的是因地制宜的能力

个人看法，深入业务才最有可能失业。毕竟现在不是野蛮生长期了，热门业务各公司都抢着做。现在常规的业务领域大部分只有那么几家公司，你对该业务再熟练也没有可迁移性，最多不过是几家公司跳一跳。
在我看来，好找工作的无外乎几种：
一是有丰富的测试管理经验，有自己的一套管理思路和理念，很多小公司做大后都需要这种人才。
二是你在某些有门槛的业务领域有独到的见解和丰富的经验，最好这些业务领域是有技术门槛的，像社区里的一些大佬。
三是你在测试开发领域有丰富的技术和经验，我看社区里很多人说随便招个初级开发就能做，我不知掉这些人亲自下场做过没有，一套成熟的测试基础建设需要的压根不是开发技能，而是定制化的去解决实际问题，不做测试的开发连需要做什么都不知道，而且其技术广度也不是谁来都行的，这才是测试开发真正的价值。
当然无论哪种，我还没见到身边有四十岁往上的，好好挣几年钱，多关注生活，有多少人会在一个行业干一辈子。

19 年初苏州郊区买的大户型，装修花了小四十万。现在发现离苏州市区太远，很不方便。但是卖了的话，虽然房价略有涨幅，但只能覆盖利息，装修肯定全亏了。年初还想卖掉换房，现在彻底不想了，干脆留着以后养老。。

我应该就是楼上说的那种纯粹的测开，负责测试基建。需要什么做什么，包括不限于自动化测试平台、造数平台、代码覆盖率、流量回放、app 专项及云真机等等。你要说真的全部都有用吗，不见得。但要说完全自嗨，那有这些和没这些，区别还是很大的。
做这些需要的能力除了掌握前后端开发能力外，最重要的是设计能力，很多写过简单测试工具的人自以为写测试平台就是单纯的 crud，其实还是没摆脱写脚本的线性思维，甚至很多硬编码。测试平台也是一个产品，好的产品架构和技术架构在后期的 1 到 100 的扩展中是很重要的。另外，为了避免出现自嗨，做这些之前还是要贴合自家公司的业务以及技术现状，这也是为什么即便开源工具很多也不断有轮子出现，因为通用型工具真不见得适合当前公司或团队现状。
至于职业生涯问题，我觉得别考虑太多。既然决定走这条路，就做好 35 岁失业的准备，运气好点到四十岁。再者说，就算在互联网做别的，又有几个四十岁还有一线工作的。车到山前必有路，不干互联网难道活不下去了？
另外，纯粹的测开有一点好处就是不卷。因为不直接和业务打交道，我所待过的公司基本都是到点下班。干测试或者测开都只是谋生的一种手段而已，不要看的那么重要。

开源的一般都是通用型的，想完全符合预期是不现实的。要想完美符合自己的业务需求，一定是要二次开发的。

b 站大学上找一找

自荐一下流马测试平台吧，灵活度还是很高的，支持各种自定义

针对

引用文本：response 的取值表达式：{{number.$.jsonpath}}；response-headers 的取值表达式：{{number.h$.jsonpath}}

取值不一定是之前接口的响应内容，也有可能是请求内容。比如很常见的请求数据是随机数，但后续接口仍需要该数据进行后续业务

以前也是只做 Python 自动化，学 vue 大概一周，springboot 三天，编程思想都是通的。
这些框架其实把大部分能做的都给你做了，你只需要会用就行。你做测试平台开发不需要去了解那么多的底层逻辑，测试平台的难点在于设计和思想。
我的开源项目目前已经有很多企业团队在用，而我开始做这些事也不过近一两年。世上无难事，只要肯行动。

设计很不错，有的业务中这样确实可以提升效率，但接口长链路测试往往很复杂。举个最容易出现的例子，有些接口用上一个接口的返回数据并不是简单的填到字段里，还需要进行一些数据处理，如加密，转换，拼接等。最后还是需要用变量去提取和替换或者写前后置脚本来完成，而在实际业务中，这种情况往往很常见。

其实对于整个社会，本身就是在不断地两级分化。我最近也在不断思考这个问题，但其实这也是无法改变的事实。对我们普通人来说，天花板就在那里，五十万一年也好，一百万一年也罢，最终到手无外乎可以多出国旅游两圈。
互联网确实在不断下行，谁又能知道未来测试会是怎样呢。要么趁现在挣点钱好养老，要么干脆躺平。最怕的就是看着别人如何怎样然后焦虑，最后拖垮了身体，才是最得不偿失的。
对于更多传统行业，我们已经是幸运的了。至于想跳出这个，人脉资源、商业嗅觉、毅力精力还有运气机会缺一不可。

可是要钱啊。俺的平台 ui 测试功能不要钱，ms 有的我也都有。同时还可以自定义自然语言操作，还可以和接口混合执行等等

在我做的测试平台里，这种能力还是很容易实现的，接口和 UI 用例可以混着执行，数据也可以相互传递。当然循环执行步骤也是支持的。

路由懒加载也会提升很多，配合你的局部导入

其实路由懒加载加上开启 gzip 以及打包时取消 map 文件的话基本就能满足大部分优化了，效率提升可以好几倍了

跑完一条用例就回传一次结果不就好了吗

这个统计图表看着眼熟...

这个多少有点偏颇了，我倒是见过一些通用的，好不好用其次，但大部分场景还是能满足的，postman 也不是百分百满足所有的，而且人家都迭代这么多年了

听起来大概是这样，先解析接口，然后生成默认的规则，规则可以修改，然后生成多个接口请求去校验，同时在生成前需要配置断言规则。如下图已实现的功能，不过我是在测试平台实现的，工具可能没这么方便：

我没感觉哪儿难听，我也接受批评和质疑，但总要告诉我具体不行的地方，而不是光嘴说一句差得很，何况还不是第一次呢？

投屏确实不是那么流畅，不过我也不是做云真机服务的尚能接受。至于测试执行的话，目前还没接触过更好且更合适的底层驱动了，如果后续发现更优秀的技术也可以引入进来。

首先呢，这个平台的定位是帮助中小企业快速实现自动化。当然我不知道您所在的公司是什么规模，测试基建做到什么程度，所以高屋建瓴般说出差太远的评价。
不过该平台只是作为 devops 其中的一环，甚至只是提供自动化测试的能力，只要能集成进去就可以。如果我把项目管理、需求管理、测试管理等等这些东西一股脑的都做进来，那必然将是一个很臃肿的系统，成本也必然随之升高，参考一些平台就知道了，好不好用用过的都知道。至于其他测试基建相关的能力和技术，在企业内部都有做过，只是那种更需要量身定制才能发挥作用。
个人认为自动化测试平台就应该是个小而美的工具平台，而不是搞臃肿不堪的一站式，至少目前我是没见到好用的，反而我这个平台在现有用户群体里口碑还算可以，当然我这个平台目前易用性和交互体验也还有很多提升空间，我也在慢慢完善。
或者说如果我对大佬的差太远理解有误，也欢迎大佬举例说出一两个地方让我学习学习？

文档还在补充，web 测试和 app 测试使用方法差不多

补上演示平台的账号密码：demo/123456