没太看懂楼主的问题核心是什么，最近也在整理接口平台，浅说下我对平台管理的理解。
接口测试分单接口和多接口，用例也如此；单接口用例可以接口为主体进行管理，无需多言；支持多角度实现的多接口用例就没有什么最优解了，核心就是以用例为主体，将涉及接口如何更恰当的加入到用例之中，各类方法的区别无外乎用例的生成方式，用例与接口的关联方式，多接口间的传值方式，执行顺序的控制方式等等。
楼主所说的 “把接口和用例干脆都放在一起” 其实更适用单接口，后者当然更适合多接口测试。页面操作来表述一个多用例的生成可以是如此的：在一个用例主体上依次添加流程接口，两接口间提供前置处理 (参数获取、参数生成等)、后置处理 (提取、断言、判断等) 等功能，还需提供全局参数类功能用于参数流转，除上述核心外还可定制化添加异步执行、异步监控、间隔控制等。在管理结构上可以做项目管理、接口管理 (单接口)、用例管理 (多接口)，报告跟随用例。

前段时间也看到帖子事情了，感觉就是人这一辈子会怎样从来都是自己事，总有人自己都不知道怎么活，却想要趋同所有人；活着就挺累了，还要去扯哪些大概率与己无关的事情

你踏踏实实的做好每一件事，过好每一天就好了
人人都向往更优秀的人（或者更有钱），可是人人都难以控制自己成为那样的人，努力本身就是反人性的，躺平和前进只是选择的区别，无上下之分。
焦虑是正常的，在这个没有最卷只有更卷，是人都会写代码的时代，你现在确实可以说是一无所有。你现在的状态是所有人都有过的经历，想的太多做得太少，看的太多撸的太少，说的不多写的太少，陷入各种对比下的自我否定。我的建议就是你说的这句话，先做好一件事再说，想的少点看的少点做得多点，无论是 jmeter 和 python 都有足够的性价比让你深入，俩者只是选择的区别，无先后之分！
加油！

为什么你这个没有右侧功能框

我觉得要改改标题，改为 “三十多的年轻人能有存款吗”

楼上的不准瞎说大实话！
其实这个不分大小公司区别，更多的是看公司内对待此类工作的认识区别，有的公司考虑到测试对产品的认识会比较全面，所以会由测试来首位对接线上发来的问题，分析后或解决或向后 (开发) 传递，这是为了确定是否为已知问题以更快解决，但是这类工作占比最多不会超过 3 成。
对测试也就是对你而言，如果如我所言，那没什么问题，而且你还可以统计分析下线上问题，定期做下内部分享，又是一笔绩效入手，也可提升自身测试思考能力。如长久以来你此类工作占比过高，要么是你在公司内的定位是类实施运维岗，要么你确实被搁置了，可以先尝试与领导沟通，表达下此类工作占比过高性价比较低的情况，向上推动下，还是不行的话就翻翻 boss 吧

出来写答案啦

破局很难，山东就这样，boss 上能翻到 20+ 的就是 OD，木有别的了，如果职业发展上破局，你可以选中面下架构之类的高级岗位，不然想回来就面对吧

把寒冷传给每个人

首先这里不是面试点，如果你所言不虚的话，你的经历已经超越了 8 成的人，再接再厉即可。暂时的广度已经差不多了，可以深度发展下现有技术

首先这句话不在于目标，而在与共享和交接；不在标准之类的，而在用例文档存在与否对产品和团队的不同影响。
如你后面所言，一份恰当适用的用例对成熟的团队在工作交接等方面是很有效的方式

只是开玩笑。我这就去学习下；
请问只是用例管理版本管理的功能吗，类似 tapd 之类的？执行是手动修改用例状态，不是脚本啥的吧？

开放捐赠通道吧，聊表寸心

自己不看就没意义啦？如果意义就在给自己看的话，你是选择用脑图记录还是写繁杂的 excel？
我想所有同行在最开始做的时候都会被灌输过写用例的各种注意点，比如写清楚操作步骤、写清楚具体的期望结果、写清楚操作中要输入的具体值、写清楚场景必要的前置条件、还有最普遍的一句质量要求：
你写出来的用例要让没接触过这个系统的新人小白都能够去执行！
所以在我的理解中，用例更多的是作为某些时间的共享物或者说是参照物；一篇完善全面的用例文档可以持久性的作为其功能的入手点，堪称技术人员的帮助文档

这评论区打广告的过分了啊，还这么长！
槽点过多，就挑着说。
用例不是写给自己看的，更多的是在非己方测试时作为交接文档使用的，而且详细的用例文档还可以作为回溯依据和新人学习使用，想建立成体系的测试团队和流程，详细文档产出是必要的；
用例确实谈不上深度，更多的是经验之谈的全面与否，如果你认为新增功能一个期望比对数据库数据一个期望正确查询出该数据的深度是不一致的，那就有深度吧

已收藏，多谢分享

必然啊，能远程，谁愿意在一线用好几千租房子用好几万买房子啊

面试一句话：简历使劲吹，面试针对性准备

1.UI 自动化去触发点赞按钮
2.接口自动化去触发点赞接口
3.sql 自动去批量执行点赞
4.手动点赞 1w 下
5.数据库直接改成 9999
6.等等...

直接就文件 + 参数化就行，没必要想多么复杂

我知道老哥，我开始也以为是 qps，可是确定后说就是 TPS 前置。。。我当时第一想法也是，拿着结果做前置？？

已阅

#1 说的对
我的建议是直接全部覆盖沥青，解决现有和后续可能出现的板砖问题，全方位提高产品质量

是的，吞吐量定时器 +Throughput Shaping Timer，可是并不理想，而且 Throughput Shaping Timer 是作用于 RPS。
场景就是对 TPS 的要求，一开始我也想当然的和普遍的请求压力联系在了一起，可是了解后确定就是 TPS 的前置

看了下官方文档，关于吞吐量定时器内吞吐量参数的解释是：
Throughput we want the timer to try to generate(我们希望计时器尝试生成的吞吐量。).
只是给个期望值，而且还注明了一些影响因素：
Of course the throughput will be lower if the server is not capable of handling it, or if other timers or time-consuming test elements prevent it.(当然，如果服务器无法处理它，或者如果其他计时器或耗时的测试元素阻止它，吞吐量将会降低。)