哪写的 24 岁呀？

我也推广过，发现自己研发的，也不是推不动吧，而是后面自己也不愿意推动了
本身开发自己就需要接口的文档平台，比如 RAP，YAPI 等。这类平台本身就支持一些接口测试，mock 之类的，开发在上面改，测试也在上面改，双方的工作成果是加成的，不需要平台切换，很方便。
自研平台本身的功能，并没有业内知名的强大。比如 YAPI，Postman 就很强大，Jmeter 更是全家桶。
出去面试，自研平台的使用，不是加分项，相反可能是减分项。自研平台的使用，对薪资的提高很弱，难有动力。
接口测试是测试同事少有的能接触代码的机会，这个也要剥夺，不太仁义。
知名平台也相对美观，更容易接受。
例子：httprunnerManager 已经停止维护，接近 1000 star 的都停止维护了？不知道是什么原因吧，但这是个风向标。

如果是我，我会直接推广 Jmeter，YAPI，真的不太需要自研平台。
那么我一定要搞自研的 API 自动化平台呢？？
我是有一些想法，但没有证实或者动力，总的来说，还是投入和产出比太弱。靠一个人来做，时间会很长。
就比如我把 Allure2 测试报告结合到 API 自动化测试报告中来了（类似 Yapi 生成的报告是 Allure2 的，希望能懂），形式上是个创新吧，但是这个功能我写了差不多一个月。（有时间就写写那种）

那么测开要做什么呢？
我认为测开还是要和测试同事们站在一起，什么东西是测试同事高频使用的，就要提高这些高频使用的效率，给这些添砖加瓦。
要让测试同事们的工作可度量，接着持续改进，让度量更科学，提高效率。
测开不是要让大家的工作越来越忙，而是要让大家越来越闲，把多余的时间，放到提高个人的幸福感上来，生活上的，或者技术上的，或者工作上的。这是我个人的愿景，谁特别忙，我都会想办法让他/她闲下来。可能是因为我是搞过性能调优的 。
其他工具上，直接用开源就好。除非开源解决不了问题，那也是给开源写插件来搞定（如 dubbo sampler 多棒👍）。如果再搞不定，才要自研。

2020 年来了，都 5.2.1 版本了

站会是项目管理的一部分。核心宗旨是让每一个人都真心参与到项目中来，了解目前的项目状态，及时调整修复自己的工作计划，群策群力，把项目的风险降低。所以站会不要求每个人都发言，也不要求固定的主持人。站会也不要求问题的长短，有兴趣的人都可以参加到问题讨论中来。甚至站会也不要求时间，解决问题为准。甚至联络感情插科打诨我也不觉得是问题，能真正让所有人参与到项目中，为项目进度出谋划策，就行。甚至以游戏的形式开站会都行（业内应该有这么做的）。
站会不仅仅是 3 个问题 “昨天完成了什么”，“今天要做什么”，“明天干什么”，每个人撸一遍。
站会要开。
但是效果不好的站会，就不要浪费时间，不用开。这是两个事情。

写的不错。
就是焦虑是技术，但是看的书和技术貌似没啥关系。

2020，如果能完成自己的目标，就买个 Tesla，奖励自己。
膜拜大佬。

当初面试了四五家公司，只有一家公司可以提供相符的薪资。
预计未来还会比较忙的。

收到邮件了，问题我还没有复现（工作 ing）。
希望把问题提到 issue 上去，这样比较方便追踪（gmail 国内上稍微费劲）。
初步的直觉的判断，我觉得不太可能，因为纯粹是源生的 Jmeter 来驱动运行的，不太应该。但是你提到了吞吐率控制器，可能另有玄机。

虽然没看代码，但是技术栈就很不错，赞。

444104595@qq.com
qq:97891996

就用 Jmeter（+ant+jenkins）吧，水桶工具。

https 的能支持吗？

我正在写自己的测试平台，但我之前没接触过 yapi，然后今天看到 yapi 的时候，我都惊呆了，难道我真的造了个轮子吗
后面仔细看了下，还好还好，我的平台还好有自己的特色啊（比如集成了 Allure2 的测试报告吧，这需要我自己在代码中定制它，并不是直接使用 testNg 的集成之类的，而是相当于重新实现了一个集成依赖。当然这不是炫技，而是 Allure2 确实在测试报告领域，是未来，是趋势）。
yapi 是一个成功的产品，很多经验值得借鉴呀（导入导出不说了，主要是 wiki（稍微单薄）和每个接口的备注，公共的环境配置，还有楼主写的这一段和 Jenkins 集成的方式，整体的格式和提示消息都非常棒）。
yapi 也有一些不太好的地方，我就不说了。
yapi 也有一些接口测试常用的，却没有支持的，我也就不说了，毕竟是我自己平台的特性……
yapi 很成功，值得学习。

年薪百万是测试负责人。好好看看职业描述吧。下面的小兵（高级工具人高潜）不是这个价位的。

大佬没提到管理技能，是疏漏了吗？
我认为轮岗有利有弊吧，能详细分析一下轮岗这件事吗？我有点儿好奇。

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

确实，我测开也是兼职。

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

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

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

先说说你投简历没音信吧：

1. 年龄偏大。
2. 年龄偏大没啥，看看公司如何，依你所述应该是个小公司，没啥名气，那么继续向下看。
3. 学历如何，是不是 985，211，大专是肯定不行的了，至少二本大学网上看吧。
4. 学历也不好，有没有好的作品，比如 github 等，博客等。
5. 业务相关性如何，比如你是一直在 P2P 领域的公司的测试（跳槽的特别多），要转到人工智能的公司去，那业务没啥相关性就要够呛了。
6. 薪资要求是多少，这和你技术水平有关系，如果啥都不是的，要的还多，或者要的薪资涨幅比较大（超过 5K），很难。
7. 有没有管理岗的述求，没有管理岗位，适不适合你。

可能看到这里，你的简历基本已经被 pass 了。（事实也是如此）
再说说你的专家性：
测试工作有两类专家：

1. 测开的专家，专门开发各种测开工具，给测试同事使用。
2. 测试的专家，所有测试同事遇到的测试问题，比如测试技术方案的问题，都要汇总到你这里，你要成为所有测试同事遇到的技术问题的终点。

软实力要求：

1. 测试的专家水分也不多，专家的 title 要得到开发的认可，就是所有和你接触的开发，对你的技术能力不能说不。
2. 所有测试同事的技能把关，到专家这个程度，其它同事的技术成长，技术水平你都要心里有数，你的评价关系其它人的绩效奖金。
3. 分享的能力，你的技术能不能广泛的传播出去，提升整个团队的技术门槛，甚至提升测试团队在整个公司，业内的技术影响力。
4. 面试的把关，是不是阿猫阿狗都能进入公司。
5. 管理能力，专家会带人了吧，P7 至少带的 P5，你需要带人来证明自己。（还有和各个领导的关系）
6. 学习能力。不详细说了，现在的校招小朋友的实力，都很恐怖。

再聊聊你的技术栈：
很弱。实在不想怼吧。我见过校招的实习生，虽然是开发的实习生，应该比你高深。
可能扎心了，举几个我问过的例子吧，如果你第一眼不用查百度，我收回我 “很弱” 的评价。
回表。物化视图，MVVC，双向绑定，偏向锁，内存页的抖动，线程的生命周期。（这些都是校招题）
不需要回答问题，如人饮水冷暖自知吧。

其实你的源码我看过……api_automation_test 的源码我也看过。
api_automation_test 不再维护了，我就多说几句好了……api_automation_test 的前端代码其实是比较烂的，同时我怀疑并不是一个人写的，更像是集大家之所长的作品，前端的风格我发现就有两种吧，具体表现是一会儿用 axios，一会儿换个界面就都是 ajax。相信你借鉴了也应该发现了。同时 api_automation_test 没有理解 vue 的组件化的思想，太多的前端代码都是重复的，怎么说呢，代码没有解耦。
你的代码我就不在这里评价了。说一下你提的二次开发吧。
在你这个平台上二次开发，我担心会不知不觉把 api_automation_test 已经实现的功能再自己实现了一遍。

有个 bug 吧，项目中我更新了用例，但是项目的最后更新时间竟然没变。
因为我看过原版的 automation_test 也是社区的开源项目吧，觉得你这个翻版的其实没超过原版的功能，或者还误删了几个原版很好的功能。
比如：

1. 同一个项目，不同的自动化测试用例，要复用同一个接口，原版是有接口选择界面的，或者选择到有的，或者新建接口。而你这里是只有新建接口，相当于抛弃了一个核心功能。
2. 分组功能被你删掉了。分组功能是一个很棒的左树右表的功能，是项目下的又一个层级。简单说吧，如果你要去掉分组功能，那么你都不用做一个项目列表，还要有一个什么 “回首页” 的按钮，直接左边项目名称树，右边自动化用例列表就可以了。原版的项目名称跳转超链接就是为了分组设计的，很明显你没 get 到。
3. 测试报告把 Echarts 图形也干掉了，但你也并没有拿出更好的方案。
4. 项目全景也干掉了。

当然你也增加了一下好的功能，可能主要是在断言的判断上吧。
我并不是说你这个平台不好，而是希望把原版的好的基础上再做优化，而不是直接把一些成熟的东西不知道为啥的就全抛弃掉。

postman 确实是个成功的产品。

这种思路很好，总的来说就是不要每次请求都要传数据，而是说 slave 先保存数据，测试结束之后走文件传输，例如 scp 把文件数据交给 master 整合。
其实这种方式我尝试过：

1. Jmeter 自带 diskstore 存储模式，就会将请求结果保存在本地文件。但是这种方式不行，文件保存路径是默认的在/tmp 下，文件名是随机的如 SerialisedSampleSender383066585222874452.ser 并没有地方能指定这个文件是哪个脚本文件的，这个文件名的前缀后缀是 Jmeter 定义的，但是中间的数字是 JDK 的方法 File.createTempFile("SerialisedSampleSender", ".ser"); 定义的。生成的 ser 文件，格式内容是 xml 的，文件比较大，同时默认是如果进程退出则文件删除，要不然也不会在 tmp 里，同时文件有分割，大概 113M 左右，就会被分割成一个子文件。
2. 如果是自己实现，slave 存储 jtl 或者 csv 文件，来传输给 master 再拼在一起，这种我试过，在某些字段如 99%，90% 这些，和 Jmeter 实时传输汇总的得到的测试报告不同，也就是说自己拼装的 和 Jmeter 源生的方式，得到的测试报告不一样，而 Jmeter 源生的测试报告业界更承认。 当然这种误差很小，不敏感的可以接受。

你这想的太多了，晋升的时候领导肯定都想到结局了，换句话说，领导早就放弃你了，你多虑了。
你可以继续待着，不过要改变工作方式，改变大家对你的印象（很难很难很难）。