反正我已经按广告举报了

大佬好，今年 30，但已经明确自己不是做开发的料，安安心心测试，天花板测试总监吧。也许未来会偏项目管理也说不定，但肯定不具备转研发的条件。
1.技术上简单的 CRUD 和自动化接口框架搭建，各种工具杂七杂八有接触和些许实践，最多也就是个初中级测开，理业务开发差距还是不小。
2.兴趣上对代码不反感，有用的时候就去研究，但平时缺少自驱学习，自己能明白自己的短处，也是种自知之明吧

“更多是综合考虑,考虑顺序如下:
行业 > 公司 > 潜力 > 工作内容 > 工作时间 > 薪资” 我同意楼上观点，这几点里少了直系领导和对接团队因素，直系领导和团队要跟你对着来或三观完全不合，以上几点除非好到爆自己能忍，也干不长，没有发挥和发展空间。

主要是以前在初学阶段，深知踏踏实实点亮一个点，需要耗费大量时间。刚毕业前 3 年就是靠业余时间堆起来的，现在如果只有碎片化时间晚上求发展，能做到调研和保持行业敏感度，落地和深挖交给更擅长技术这条路或精力更充沛的同事去做，我指的躺平是这个意思（技术贡献突出的，领导客观公正情况下，年度绩效也会有差别）。论开荒，我是开不过以前的自己了。
另外，晚上求发展上，也从纯技术在向综合方面拓宽，只有真正工作遇到阻碍或未来肉眼可见的阻碍，才会毕其功于一役地去大量投时间搞

嗯嗯，我指的是在蛮干上躺平了，但保持对行业的敏感性上，还是会见缝插针的学习，今年在拿证 。

问个不地道的问题，白天求生存，晚上求发展，我理解一定程度上就牺牲了陪家人的时间？这也是我现在对技术上的好奇实践没有以前那么 “蛮干” 的原因，遇到工作需要或可见的需要才会去主动学，不加班更多时间是陪家里神兽瞎玩，我清楚论应用层技术学习，我大概率学不赢年轻人，干脆躺平 陪家人

“基于此，我们将中台发布分成了独立发布，关联发布和全回归发布，对于独立发布主要适用于技改类型，和上层业务无关的中台自身业务等；关联发布就是某个上层业务向中台提出的需求，不会涉及到其他业务；全回归发布，就是通过评估确定上层业务都需要回归的改动。这三种类型的发布形式，在需求和排期阶段就定下了基调” --- 俺们也一样

toB 业务也有对性能要求较高的时候，比如我这边是做视频智能安防的，
业务层来说，一个大省下面 100 多万用户，每个用户就是组织机构树下的叶子节点，父节点之间还有错综复杂的级联关系，哪怕是一个管理员用户上去做个查询或搜索类操作，性能压力不小，早期查询超时是家常便饭。压力不一定来自并发或高频，有可能来自业务特性决定的复杂数据结构或数据量。
能力层来说，如果某片地区出现停电或网络抖动，导致这一片十几万设备同时掉线离线，能力层网关或服务器就要面对每秒几万~十几万的请求压过来，时间虽短，但不做任何性能保护的策略，能力层网关很可能触发限流 or 服务器被降级。

我咋感觉自己直接从初学阶段到了理智阶段呢，可能是工作经历和一些其它受限原因吧

七年混混飘过

让产品团队过来挖点靠谱的测试过去当产品，产品领导乐意，你的这个问题也能得到中期解决

有趣，抽空实践下

大佬是考了高项，还是 PMP 呀

我们这种经历，肯定在 7~10 年同行里有一定占比，正常。现在我身边同事有离职的，有的会私下问下我的建议。

以前部署一次 40 分钟。。。是单个模块服务器部署流程太复杂 or 不是分布式微服务架构，一个功能提测，全量部署一遍？我们现在几十个模块，测试环境服务器接近上百台，但版本是迭代小跑，每次最多涉及 10 个左右的模块，就是手工 one by one 也就不到 10 分钟搞定，所以好奇贵司部署一次 40 分钟是什么情况

自动化有两种，基于 KPI 和 基于提高测试效率。
1.如果是基于 KPI，我们就做冲击 KPI 的事情，有没有用不要紧，领导喜欢，年底绩效给好，晋升加薪给好，愿意给人给时间，别说做没用的自动化，加入开发队伍做满全覆盖的单元测试都行。毕竟你没法改变领导的想法，就算想改变，你也得先照着领导意思做出数据来证明，KPI 考核的自动化对实际测试提效或质量建设没啥鸟用。

2.如果基于提高测试效率，情况就比较复杂了，要因地制宜找出合适自己团队的框架、用例结构、试行制度，不断迭代，没个半年到 1 年，你也试不出来目前自己辛苦做出来的自动化流程到底对自己团队有多少帮助，所以有经验的测试准确调研可行性的概率更高，没有经验的测试走弯路做无用功的概率更高。但，不能否认做自动化本身的意义和作用，楼上已经有大佬回帖举例说明。

是认真的

7 年 6 家公司的老油条，建议出去看看。我 7 年时间在 6 家公司待过，目前东家刚好工作 3 年，你应该能想象我前 5 家的跳槽频率，好处是如鱼饮水冷暖自知，坏处是跳槽太频繁，再看机会时大厂 HR 会犹豫（虽然不出意外我也不打算继续折腾）。当然，我不主张像我跳槽那么频繁，但趁着 30 岁之前，多经历两三家公司（除非遇到你心中的那个好雇主）不是坏事。

请问 Mac 环境能安装吗？安全这块搞得很碎片，也想有个这样的通关来串联夯实基础

就我个人理解来看，预发布环境如果不能将真实用户实际产生的数据与流量引入并完成动作，那么预发布约等于额外的一套测试环境。我更看好实际线上环境的灰度发布，但后端服务的灰度发布太难太复杂，一直困扰着我、同组测试小伙伴、以及测试 TL，目前暂时无解（我们是微服务分布式部署）。

额，可能不只是懒，是对接口到功能的这层映射理解有限。。。

个人觉得，都能写出这个 json 的使用者，他就不能自己手工排下 case 的执行顺序到某个任务中吗？自动化脚本或代码负责自动跑任务。如果纯粹练下编码思维和手感，倒也不错

直接针对提供出去的 API 接口做接口测试不香吗？

个人愚见，如果你是从外部网络调用，会不会跟你的并发数本身有关？
举个例子，一次 http 请求处理耗时 200ms（外部网络请求等其它原因），每秒并发 50，理论数据 TPS 最大 250 左右。同样条件下，你将并发线程数开到每秒 100，服务器和执行机抗住的前提下，TPS 理论上能达到 500。可能跟你加不加 service mesh 没关系，TPS 大也是需要并发数达到一定程度才起得来。
只是个人推测，之前一次压测的时候遇到过类似估算问题。如果你是纯局域网或内网压测，可以忽略我上面说的