已收到，感谢组织

压力机的并发数 并不等于 服务器处理的并发数，这是两个概念。因为服务器的处理能力首先会取决于 Nginx 的分发能力（如果有的话，或者其它类似的中间件），所以对于中间件的配置，我们会最大线程数、等待线程数等等。

TPS+ 响应时间已经足够表达了服务器的处理能力了。因为服务器并不关心压力是怎么产生的。它只负责处理。

一般情况下，在做性能测试时，都不会去强调并发的概念。因为现实的场景中，除了秒杀、整点开抢等几类特殊的场景外。都不会进行狭义上的并发测试。与实际的业务场景不符。我们更多的会采用 TPS，响应时间之类的指标来衡量性能。

“登录接口能够承受秒级 1000 并发” 这个性能需求本身就有问题。秒级 1000 并发，也就意味着 TPS 达到 1000（如果是这么理解的话）。那么线程数是多少并不是固定的。因为还要考虑到响应时间。

如果按上面的理解，TPS 要求达到 1000，假设响应时间为 0.5，那就是要 500 的请求量（TPS = Vu/Time，这里暂不考虑网络传输的时间，实际情况会更复杂），至于这 500 的请求量，是通过 50 线程的并发，还是 100 线程的并发，并不重要。因为对于服务器而言，关心的单位时间内到达服务器的请求数，至于这些请求是由多少线程发起的，并不太关心。

不要纠结并发数，TPS 结合响应时间，才是性能的真实指标

如果是数据总量大，那就分页处理就好了。
如果是单条数据的数据量大，那就评估下这个接口返回的数据是否是必要的，是否可以拆分。
这个和性能没什么关系，主要还是设计层面的问题

需求实例化了解下？带着具体的用户场景去交流，可能会更好些。而且要注意下，提前和别人预约好时间。别人的时间也是时间。

我有 1000 多积分了，好快

不为业务服务的技术都是耍流氓。不懂业务的测开不是好测开。测开很重要的一个工作职责是发现和解决测试过程中的痛点，有可能是工具，有可能是业务，还有可有是其它。

还是需要的啊，随着业务代码的加入，性能肯定会有一些损耗，以最终业务场景下的性能测试为准。框架级的性能测试主要是验证框架本身的性能够用，否则到业务代码引入后，发现是框架的性能问题，改起来就很麻烦了。

当时没想到过，还是懂的少

当然啦，对于一些技术选型，基础底层框架的性能验证，和业务无关。

对的，这个其实很重要，经过你测试的版本，如果团队都能够比较放心，也是种很好的价值体现。

嗯，有更新了，可以直接看第二版的

说下自己的理解，对于测试这份工作而言，我们的产出有几下内容：

1. 一个思维：就是你的测试思维，针对每个版本或者迭代，结合自己的经验和能力，设计出高效的测试用例，体现你测试的专业性，而不是别人眼中的 “点点点”。

2. 一份报告：一份合格的测试报告，说明测试范围及并给出测试结论，如果有风险，应提出自己的风险和意见，让团队共同意识到风险，并共同寻求解决方案。

3. 一点责任：做为测试人，经过自己测试过的内容，应该承当一份责任，能够保证产品的基本质量。如果线上出现问题，应该有责任和能力去解决并加以改进，不能把问题都归结为团队质量意识不强。

4.体现专业：你应该让团队意识到，测试，你是专业的，你拥有测试思维，能够通过自动化或者其它手段解决测试过程中遇到的测试问题，能够推动团队逐渐形成质量意识。

至于测试团队规模，13 楼已经说的很多啦，可以参考。至于题主提到的 “如果我是公司的创始人，我会把测试部门干掉，把这些测试管理者干掉。” 我只能说，庆幸你不是创始人。

敏捷团队中需要写的是回归测试用例，当前迭代的内容可以通过 AC 或者自动化脚本的方式跟进，但是回归测试的用例还是需要适当补充

说下我的做法：

1. 记录每个接口上次正常运行的结果（主要是入参和出参的数据结构）
2. 定期自动回放接口，对比返回的结果，如果报错或者返回的数据结构不对应，则告警；
3. 更新测试用例 以上步骤做成接口测试平台中的一个功能点。对于新增的接口，如果没有提测，可以不需要关注。

参考我司的几点做法：

1. 聚焦：每次用例评审不超过 1 小时，只评审核心内容及测试设计思路，不对具体的每条用例展开评审，实际上这个意义确实不大，只要测试思路没什么问题，大体上也不会有偏差；

2. 事先准备：事先和研发及产品沟通，让他们提前阅读文档。在评审的时候，不需要拉上所有的人，只需要相关人员即可

3. 持续反馈：测试用例并不是一成不变的，哪怕是评审完。不能让测试用例成为一个借口（很多测试人员经常对其它人说为会不在评审的时候提出来，这种做法很不推荐，别人只是帮你 check，而不是让他来替你思考）

4. 给出行动项：需要修改的内容，及时修改并反馈，让大家有参与感，同时表示感谢。

5. 要注意测试用例的颗粒度，在评审时，不需要逐条过，评审测试思路即可。本质上测试用例也是一个测试思维可视化的过程，除非你们的测试团队特别年轻（哪怕真的都是刚入行的人，也不应该在评审时去逐条过，那是测试主管应该做的事，不要拉上整个团队）

6. 关于评审能给团队带来什么，个人的理解是这是又一次三方对齐需求理解的机会。可以保证大家对同一个需求的理解是一致的，避免更多可能出现的返工浪费。

可以的啊，没什么大问题。有机会一起多交流

上面大佬关于测开都回答的差不多了。我补充点关于测试开发本身的发展路线思考，详见：https://testerhome.com/topics/30771

给你点建议，仅供参考：

1. 夯实自己的代码能力。这个是高阶测试的必备技能。不仅仅限于能写简单的代码。至少要能够通过代码解决一些测试过程中的实际痛点和实际问题。能看懂常用测试框架的源码。

2. 性能专项是一个可以全面发展自己技能树的专项，但是要做好也很难。现在的框架都比较成熟了。能优化的东西无非就是使用的规范性。想要做出成绩（不能只会写脚本，至少要能定位问题并给出合理的解释），需要第 1 点的能力。

3. 安全其实是另一个领域的东西，和测试本身关系并不大，需要的更多的是心理学和社会工程学。用工具扫扫的都不能算是安全测试。

4. 自动化专项是当下最好出成绩的专项。不管是接口还是 UI，都有大量的成熟平台，不建议自己从 0 开始做，但可以看看别人的源码怎么写。在工作中以落地为主。

5. 做为测试人员，要培养好自己的测试思维，能够从业务而不是技术角度理解和处理问题，技术是你解决问题的工具，而不是你赖以生存的能力，否则要个开发不香么。

6. 综上。希望能帮助到你。最终下决定的还是靠你自己。行动起来才是最重要的。

嗯，在快节奏的迭代周期中，测试用例设计会包含相关的测试策略。但是个人感觉会有点滞后。一般在迭代计划会上确认迭代内容后，做为测试主力，就应该去整体考虑下风险和测试验点，提前做好规划，看看是否需要其它人的协助。也不需要每个迭代都去做。想先再做。

就是实践过，然后和很多同行沟通过，才感觉大家现在都在卷接口平台，但对于测试分层每层应该做什么都不太清楚。才写的这篇。改天把我们团队的实例拿出来说说

嗯，性能测试包含的内容很多，篇幅有限，没有具体展开讲，有机会单独一篇出来聊聊。
比如 APP 的性能，比如前端页面性能，比如全链路压测，都可以聊的。

其实呢，主要还是看你的需求是什么。如果是开发环境，每次都重构一次也不是什么大问题，容器化的构建时间基本上都是秒级的，又不是不可以接受。如果是测试环境，为了保障测试环境的稳定性，手动触发可能会更稳妥些。

因为这里面还会涉及到一个问题，就是你那些服务代码的提交频率是什么样的。如果说几个服务的提交频率都差不多，你做这个 Diff 就没什么意义。如果提交频率差异很大，人为判断下，不是更快么。

以解决问题为目标。不一定非得用技术手段去解决

拆成不同的任务去构建就好了呀。在不同的 Dockerfile 里配置不同服务的打包命令。例如一个 Dockerfile 只负责构建一个服务，然后对应不同的 Jenkins 的 JOB 就好了。如果需要全局构建，那就再建一个 JOB 统一调用一次就好。

专职的测试人员会逐渐减少。测试的职能会被分布到每个人身 。团队为质量共同负责，在质量内建的道路上越走越远。现在的测试人员，要么有能力为质量内建做一些底层能力的打通，例如各类自动化测试、专项测试等。要么为业务方多思考，构建更合理的测试策略，做好测试设计的工作，让团队都能为质量做一些贡献。
核心的测试还是会比较吃香的。其实开发也有类似的问题。现在低代码初见端倪，未来需要的可能更多的是架构级别的开发，而底层的研发也面临着分流的危险。
汽车发明后，马车的相关岗位也逐渐消失，但那些原来岗位上的人，还是会找到其它的出路。做为测试人，又何尝不可以呢。多观察多学习，大不了换个岗位。