看公司基建

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

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

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

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

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

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

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

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

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

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

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

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

老板是怎么发现完全没有影响的，只是因为没有用户反馈 BUG 吗？
像 1 楼说的，如果公司开发提测质量好，到底怎么判断提测质量好，靠开发自己说，还是只要用户不反馈，就是质量好？
有没可能是用户懒得反馈，直接就不用了。
确实，如果使用的人越来越少，那么发现 BUG，并且还反馈 BUG 的情况就会减少。

我看过某个剧情，最后公司，半年后倒闭了

楼上的，我知道你是谁了。。

老板：要不做一下探索性测试吧，把你开了？

如果公司的开发提测质量很好，那确实不用测试也没什么大问题。

说的这么没有价值吗？

这么不值钱吗？

也就是仅楼主可见，但是系统不知道谁是楼主，导致匿名贴的仅楼主可见实际上谁都不可见。这个是逻辑上的错误

实际赚钱没

嗯，方面问下贵司测试人员的组织架构么。感觉这几个项目都是你一个人弄的，如果真的，实在佩服。超过大多 5 年的测试老鸟了

这个可以，牛逼

这个朋友，不会是你吧

很好啊，技术的归技术管，业务归业务管。想做技术就卷到技术部门去呗。

建议匿名贴就不要仅楼主可见了

这个技术部门有点像技术中台部门，我目前所在厂的每个事业部都有这么个部门，主要负责各类流水线和软件公版、测试开发等活，但是业务部门也会配相应的开发，对接公版需求和落地业务等。

很多大公司都是这样的，有一个底盘支撑团队，负责各种中间件，或者研发流水线 cicd 之类通用工具的开发
业务部门只要会用各种底盘团队的工具写业务代码就行了

这行就是如此，转码的人第一个想的就是测试，涌入进来的大量低质人员，造成这个职业的话语权低，运维好歹这些年卷出来了云原生、devops。而测试呢，只卷出一堆又一堆的 ppt 大师，那也别怪大环境不好，第一个干掉的就是测试了。