在严格的商业生产系统里算，在社区应该没问题，毕竟专门来黑社区也想不到能有什么利益到手

这里面存在业务特色，我们是 sdk 业务，公司内部不同业务接入我们的 sdk。
我们的课题是，在一个业务的宿主 app（如抖音）上回归了一次之后，其他的宿主 app 还要不要再做回归。

这里面涉及一个宿主通过什么方式去接入 sdk，并且要明确一种方式来盘点 sdk 接入差异而产生的宿主层面的差异。

再往细里说就只能口头解释了，不然长篇大论。

csv 只是一种文本格式，简单说就是 value1,value2,value3,value4 等通过逗号去隔开不同数据的文本格式，人眼上有可读性，格式简单也方便统一改，网上搜一下就可以了。python 本身也有内置的 csv 文件解析类可以 import。

今年 10 月起在搞大家最不看好的精准测试 ，不过比较有业务特色，和标准方案有一些差异

那是不是可以理解为设置这个线程数过大了，实际上系统发不了这么多线程数。回到帖子的问题，是不是已经解决了？

【jmeter 创建 10000 个线程，应该不是并发请求的吧。是循环发送请求的吗？】最好把配置截图发上来看看，我用 jmeter 很少，可能是我自己混淆了一些概念。

1. 如果 table 里新增的字段本身有默认值，而且你的自动化也和新增字段没关系，那你在构造数据库数据库时就可以直接 INSERT INTO table_name (column1, column2, column3, ...) VALUES (value1, value2, value3, ...); 来达到指定字段插入值的目的；
2. 如果 table 里新增的字段本身还没有默认值，而且沟通后这个字段不能赋默认值，那就没有办法。因为你已经和 table 完全耦合绑死，table 一改你就得跟着改测试数据。你最多能做的就是把你的测试数据写成例如 csv 这种比较好处理的格式，到时改数据直接用 vscode 或者任何编辑器做正则全局搜索替换字符去批量更改数据；或者更高级一点你提前封装诸如 sed 命令或者任何批量修改你测试数据的脚本来提高你该数据的效率

直接看你的被测服务是不是真的接了符合预期的请求量，先排除这么乱来的线程数是不是真的能发；确认了是有，再来考虑这里的问题

没看懂问题，怎么听怎么不合理。

为什么数据库增加字段还能影响你的自动化用例？自动化里面做什么逻辑？

莫非你的意思是，你这个接口自动化里需要去创建一个 table ？

哈哈哈，我司对待后端研发上线出问题，第一要求就是二话不说先回滚代码

不查白不查，公司给免费怎么不去看看。甲状腺结节良性居多啦，不方

你的说是有道理，认同

也不是这么解读，极少有人是一路顺风的，看用什么心态面对问题，以及潜在可能发生的问题你会提前做什么规避。

现在很多父母搞鸡娃，我喜欢偶尔鸡一下自己，自己的负面情绪更少，能量更高，目的也更单纯，或许可以理解为乐观吧。

至于别人怎么看我，我其实无所屌谓（这不是说脏话，最近我们组内很流行这句话 ），当我是卷王或其他啥并不会对我造成影响。

非常赞同 12 楼。

与其感慨路难行，不如马上出发。不要所有错归结为世界的错行业的错，还是从自身能改变的地方做实际行动。

既然大家都在骂，为何总有后人源源不断的挤进来，而不是大家都选择离开这个行业？
既然讨厌做外包，为什么还是硬着头皮去做自己讨厌的事情？
既然想过的更舒服一点，为什么不自己做老板搞点小生意过过日子？

还是得先拷问一下自己

我一直认为，现在大家都说的【卷】，换成十年前的话术来形容，就是【勤奋刻苦】，是一种值得赞扬的品质。当然有些人确实在做职位内耗的行为，不过在以前也同样有，现在之所以突出，就是因为行情不好开始洗牌，有些人在裸泳怕被看见，就得尽快使用一些手段来遮羞，坚持不了多久。

这样哦，那可能就看心态了。

如果时间充裕，想自己找点事情提升技能，那学习新东西是很好的，技多不压身，多学一些能活跃思维；

如果是处境窘迫，想要寻求突破，那明确好方向和目标，保证自己的精力能聚焦起来投入，是更优的方式；

楼主应该是第一种，我觉得挺好。

是的，场景构造细分也是一个缩小范围定位的过程。如果有等价场景的历史基线数据供对比（如线上同场景的性能数据），其实参考性也足够了，就是明确有问题。

如果 20% 差距不符预期，那大概是有那种随着请求量堆积越来越慢的性能问题类型；排查一下锁、缓存、SQL 耗时、线程这些经常带坑的地方

想帮助你，但是没看懂你在问什么。

建议补充以下信息：

1. 你要压什么，或者说你目标是啥
2. 你怎么压的，用什么工具，大概什么思路
3. 谁和谁的差距大于 10%
4. 你自己的分析过程和具体想问什么问题（“落地经验” 太笼统）

帮助楼主分析一下。

公司一：自研小公司

• 优：能快速接触到整个项目上下游全面的质量保障，短时间提供一个人的综合能力
• 劣：公司不一定稳定，项目的生命周期可能很短，这个大环境下项目解散的风险变大
• 随机成分：能跟到好老板的概率更小，遇到政治斗争的概率也会更大，你是正式员工就容易关乎到切身利益

公司二：大厂外包

• 优：能接触到平均水平更高的人，了解大厂完善规范的流程和工具平台，知道什么能做什么不能做；如果外包表现好，是明确会重点倾斜的，能力越强给的事情就越多
• 劣：外包绝大多数都只搞业务测试，职能会被限制主，很多东西都没有权限（不过大多数都能申请，研发的代码看情况也是大概率能给的）
• 随机成分：有些团队如果缺正式，外包是的确有机会做编码工作的（比如我在的业务团队就有，甚至还培养外包怎么写）

如果一个外包机会足够好，你也确实想争取表现，大厂还是可以的，而且在一个大厂里做过外包也很容易跳到其他大厂；如果小公司机会不错，也明确团队老板水平不错，那建议优先考虑自研小公司。做外包有 30 岁风险，但不是 100% 的有风险，主要看人，如果去到就按部就班搞搞测试，去哪里都一样。

不太清楚是说原生 app 还是类似快应用那类东西。我的观点是不如学 android 开发，被某个平台限制了发展方向似乎没必要。

正常交流不用过于客气。

如果你的初衷是在回归测试中节省工作量，这个背景不至于要去做一个平台，可以先搭一个接口自动化框架用起来就是第一步了。至于项目中哪些功能适合做自动化，就只能 case by case 去探讨，无法离开项目实际情况，外人不好给予帮助。

这头裁员送大礼包，那头腾讯网易使劲招，无缝连接还白拿几个月，很爽

1. 分析 bug 表现是服务端还是客户端问题，缩小排查范围
2. 回忆自己的操作路径，和研发讨论，让研发在可疑的关键路径上留日志，以免未来偶现但是又没现场
3. 留个历史 bug 坐记录，尽量保存更多信息，以免未来复现之后又是从零开始理解
4. 随时开代理抓包，留下所有的接口交互数据，以免不时之需

这种节奏已经持续 3 年了吧，目前身体健康，这个月刚体检，最新结果是有无害甲状腺结节，还有个今年 1 月得了新冠后的肺结节。后面肺结节还需要半年定期复检。

其实我不算很卷，我晚下班是因为我去公司健身房锻炼了（健身时长超 10 年），练完回来 10 点出头再简单干点事情，习惯了

这种裁员又不是只裁测试，是产品线级别的裁员，不用瞎紧张，动不动就焦虑测试没有未来

反问你一个问题，如果项目已经比较稳定，还是否需要测试？需要搞自动化？

如果你的答案为 “是”，就给出一个为什么要做自动化的理由，如果给不出来的话就别做，没有目标的做=自嗨。从你的回复上，给到我的感觉是，识别不到实际业务问题，没有目标，为了自动化而自动化（希望是我理解错了）。

如果这个问题仅仅从个人成长视角问，电商项目属于流程链路长的项目，猜测业务领域应该很需要解决测试数据构造的问题吧；另外自动化要重点建设监控报警，尤其是资金问题（看体量吧，大厂里面很强调电商资损）；从通用自动化角度考虑，用例管理、接口自动化、数据统计等，很多常见功能，都能做但是你做不完，先选哪个做就看团队缺什么。

至于问【如何构思设计并实现】，太庞大了。我的观点是，先去找电商项目里面有什么质量问题是人工不好解决，找到问题再去考虑设计技术方案。如果都没有问题，那这些测试还留着干什么