这种水平不需要优化简历啦，只是没多少企业接得住的问题

时局艰难，基本没面试 ，应该是简历还有问题

挖草，这还要优化？

都这么强吗

看起来好强

可能的原因是在调用 test_login_case() 函数时不小心传递了一个额外的参数。请检查函数调用并确保只传递了一个参数

这不得提一提 神雕师兄了 可以和神雕大佬交流一下

主要分为两个部分，第一部分：技术难度大，第二步：运营的方式。如果方向不对，1.很难出成果;2.研发和测试会排斥

嗯，我们目前计划的也是这套方案，但是团队中没有人实际搞过这块，感觉挑战比较大，有没有落地的经验可以学习一下。

流量录制回放的难度取决于你的方案，主要是与技术栈有关。如果使用 java，目前大多数公司，使用在阿里巴巴基于 jvm-sandbox-repeater 二开。

是技术 1 号位在推动，推广的阻力应该不是问题，主要问题是现在基础建设这块是空白，项目刚立项，组建团队阶段，想了解一下，7 人专职测开，大概需要多久落地，过程中可能会遇到的难点有哪些

全链路压测，最好是自上而下的确定，最好是 CTO 牵头，纯测试、测开负责，吃力不吐好。

那个公司，这么大气，投入 7 个人

根据你的描述，盘 1 下你。

• 1、年龄偏大【硬伤，年龄偏大不是问题，问题是你年龄这么大还在做一线搬砖的活】
• 2、业务熟练【算不上加分项，5 年了，再笨的人技术也能熟练】
• 3、业绩还不错【没出线上事故并不能说明你做的好，也有可能是你负责的业务简单、测试复杂度不高所致。换句话说，线上不出问题是底线，你目前没有突破底线，但也没有把项目做出花来让大家眼前一亮。】
• 4、同事关系融洽【说明情商、性格还行】
• 5、技术太差【你一名点工，公司帮你做技术转型，希望每一位工地搬砖的人，在未来都有机会转成技术工人。这对于老点工来说是一个机会，但有些人是机缘巧合报了计算机系、有的人是走错门进了 IT 领域、有的人是掏了培训费做的测试工程师，什么样的人都有，但都有一个共同点：技术真学不会。】
• 6、无法交付 KPI【公司对每位测试工程师布置了任务考核，但你完不成】

再引申几个问题：
其实大到我们整个社会、国家，都在进行转型，不光是测试行业。以前我们可以去电子厂打工，造成一个改革开放经济腾飞的时代，现在还有几个工厂是真正赚钱的？如果不从低端往上走，做的永远是点点点的杂活。

• 1、能不能不做手工测试工程师，你其他技能在这些年学扎实了，依然可以转产品、管理，实在不行转 PMO 也可以。
• 2、万一以后基础点工的工作都不存在了（开发标准化拖拽生成或是 AI 流水线自动生成，Bug 几乎没有），自动化测试也都 AI 自动生成了，你能干啥？
• 3、整个社会都觉得卷，不光是 IT 行业，你若不抓破头想点出路，只会让自己的路越走越窄。

综上所述，能苟你就苟着，短期内不被裁就待着。
弱是不幸被裁，你换一家公司基本上也还是这个局面，甚至更差。
既然年龄已经这么大了，在当下实际层面应该不断做高自己的护城河，技术方面现在逐渐都是硬实力了，就好比别人的炮楼是水泥钢筋，你还是个茅草屋，看似都能住人，但经不起大风大浪。

目前基建基本为 0，是新成立的研发中心，大概 50-80 人产研规模

你这回答是 gpt 本人吧

看公司基建

落地流量录制回放和全链路压测平台的实施需要的人力资源数量会因不同的项目和实施方案而异，这取决于许多因素，如实施的规模、复杂性和持续时间等。然而，通常情况下，至少需要拥有以下几种角色的专业人员：

项目经理：负责整个项目的规划、组织和管理，确保项目按时、按预算和按要求完成。

测试架构师：负责设计测试方案、确定测试指标和数据、开发测试脚本和执行测试，确保测试的有效性和完整性。

开发工程师：负责实现和维护全链路压测平台和流量录制回放功能，确保系统的稳定性和可靠性。

运维工程师：负责部署和维护全链路压测平台和流量录制回放功能的运行环境，确保系统的可用性和安全性。

需要注意的是，以上只是一个大致的人力资源需求清单，实际情况会因项目的具体要求和实施方案而有所不同。

我完全不用考虑这种问题，因为公司的开发质量实在太低

是不是项目本身也没有大的迭代了

可能是这个岗位在这个公司确实饱和了，这落在其他岗位也是一样。不是还有那种砍一整条业务线，公司还觉得更好的吗？

很多公司，仅对敏捷开发流程中 “变更快”，“迭代快” 了解，往往忽视敏捷开发需要靠自动化测试辅助和流程管控；
实际项目过程中：
产品经理：需求写的简单，能用一句话概括，就用一句话；
开发工程师：需求评审听着迷迷糊糊，大概知道相关功能，但是开发是否能实现，还需要看开发时间和技术，到了提交测试时，缺乏自测和对业务了解，开发仅看需求中一句话内容，低级问题频繁出现；每提交一个问题，恨不得给测试提供一个版本测试，偶尔一天提供两个版本；
测试工程师：由于需求变更快，往往不会编写测试用例，可能会写功能测试逻辑图，拿到测试版本，提交个上百个问题，还担心遗留问题，反反复复回归测试，想避免修复 BUG 或者合并代码时，之前功能旧功能产生问题。
理想中敏捷开发：
产品经理：会将需求内容，分解到每一个详细的任务（WBS），让开发明确需求；
开发工程师：根据实际需求，了解其中的业务需求和标准，进行开发；提交代码到代码库时，会有开发工程师走读代码，合并到代码库时，会自动触发代码质量检测工具或者代码覆盖率检测工具，检测代码质量；以上没问题时，再提供测试版本给到测试，并提供代码修改记录；
测试工程师：拿到测试版本，先跑自动化测试，比如 UI 自动化测试，接口自动化测试等，同时进行业务功能测试；提交问题点到开发工程师环节修改；如果测试完成后，发布测试报告；软件版本发布到上线后，再次在正式服进行重要功能回归测试。

这样说就没意思了，QA 说质量好是怎么体现的，QA 自己说的，还是用户没反馈？用户没反馈，不代表没 bug，使用人数多，可能靠的是推广，也不代表没 bug，那怎么确定质量好？

质量保证是个大话题，确实不只有测试一个手段，其他环节做好了，测试也可以没有，但是这个公司大概率其他环节也不怎么样。。