都是接口自动化

有一些大前置，会执行很多 SQL。包括每个案例里面的前置也会有很多数据准备，缓存同步等。这些方面共同影响了整体的时间和执行单个案例的时间

是后面才转到现在的项目的，来的时候存量案例就有约 1w 多的案例。真不是钓鱼…

目前看，对案例进行分层执行是比较简单快速的办法。但是同时也会有个疑问，假设我每次时间比较有限，执行的大多都是 P0、P1 的案例，但是某次可能 P3 级的案例发现了问题。那是否最终还是需要全量执行呢？

以下是个人的一点理解，
首先得看你压测的目的是什么，如果是为了测试下单流程的性能，那应该先考虑的是这个下单场景相关的接口。
其次在这个下单场景中，接口肯定是有调用顺序的，这里应该存在前后依赖。比如下单前需要先登录或者获取库存等。
对于你说的页面中相互独立的接口，我理解是否是类似于前端调用获取数据字典此类的接口？ 如果你的性能目标是为了压测核心场景，那么可以考虑按照场景顺序来。
另外前端抓包获取的顺序和各个接口调用顺序可以不同，比如前端需要获取一些字段的信息再下单，那么这里就存在顺序。但是如果直接调用后台接口，则可以直接在入参中传入而无需考虑顺序问题。

感谢! 非常有用的方法。我试着根据这两种方法再去整理一波。

太简单确实可能因为自己平时太过熟悉了，所以觉得没什么价值。但是其实自己也有小组或者部门的一些表彰和肯定，也都是领导推荐的。所以可能也确实有一些在老板看来是有亮点的东西

感谢大佬!!!
很认同这个观点，自己也是站在面试官的角度来评价自己过去的工作，整体情况就是简单不复杂，替代性很强，所以才会有这个困惑。

还有一个问题就是，思考自己的工作，其实更偏向于质量保障，做好质量把控和交付。长期陷于手工业务和自动化覆盖率的 KPI 上。对于这种岗位来说，这种日常工作值得说吗？

了解。技术上就是有点自我贬低，觉得太简单了上不了台面…

哈哈哈，谢谢。确实之前的简历跟这个写的差不多，但是就是觉得给面试官来看，会有一种"就这" 的感觉。这些事情应该也都是大家平时都在做的，而且自己也没有深入一些去做，所以还是挺难办的

是的，只是大多数面试官问的并非是个人项目，而是第三方的东西。彼此双方大多只是使用者的角度，至少不可能清楚背后的技术逻辑，这是比较难的。比如微信抢红包，我觉得要是能说出红包金额计算是什么时候算的 之类的问题，那应该会让人眼前一亮