主要是在手忙脚乱了一阵子，倒没什么影响很大的 BUG。

感谢楼主。第一次被设为精华贴，小激动下。

关于选平台，其实不着急的，先想想下面几个问题。现在缺的不是平台，而是选择的能力。

1.1 团队的现状是什么？
如果当前团队已经有了部分接口测试的工作在开展，只是没有形成标准化、持续化，那么尽可能就以现有的工具为底层基础，进行开发，培养用户习惯的成本是很高的，别人也不一定乐意，还涉及到迁移成本的问题。如果当前团队还没进行过多的接口测试，那么就可以慎重的进行技术选型

1.2 团队的资源有哪些？
这里指的资源其实就是研发能力，会有几个人一起研发，还是你自己一个人？大家擅长的开发语言是什么？是否有能力做前端页面？是否有时间投入（很多时候并不一定会给工时）。对于开发语言而言，不需要纠结是 Java 还是 Python，擅长哪个就用哪个。能和开发团队保持一致最好，不能也关系不大（如果你真的熟悉了一款语言，那么转换到其它语言上也不是什么难事。笔者从 C 切换到 Java，再到现在的 Python，适应过程并不会太长）

1.3 为什么要选它？
在确定完开发语言之后，就可以对应的去做选型了，各语言都有大量的开源框架可以使用（Java 的 JunitTest，TestNg 等，Python 的 Pytest，HttpRunner 等），本质上没有太大的区别，只要你选的框架文档齐全，还在持续更新，问题就不大。没人维护的框架不要选（特别要注意 GIT 上那些 Demo 类的框架，很容易误导人）

看到两篇我最近发的文章。。。

历史文章可以投稿么
https://testerhome.com/topics/30937

单从测试的角度来说，广度优先，尽可能对自己公司常用的组件都有基础的了解。大至上能和开发对等交流。

代码能力的深度问题，这个人感觉专注于一项即可，比如你提到的后端，去深入了解 spring boot 的原理、尝试去写一些复杂点的功能，去解决测试过程的一些小痛点，提升效率。虽然对于测试用例设计的影响可能会小点，但不要把自己限制在测试设计上呀，做为测试人员，能够解决真实的测试痛点，也是非常有价值的呀。

这里面的平衡主要取决于自己的职业规划，是更多的偏向业务，解决业务层的问题（更好的测试策略、更高效的测试用例覆盖等），还是偏向技术，能通过技术影响整体测试效率（解决痛点、横向拉通、平台建设等），都是可取的。

可以的，整理个系列出来，常见中间件的测试方法，很好的主意，谢谢。

并不能完全保证，不管是正交表，还是 pairwise 算法，都是基于统计学的基本理论，进而进一步提炼出来 的。更多的是用来表达在可接受的成本内的最优解。它是经过严谨的数据推算和证明过的（嗯，我也不知道是怎么证明的，一般人也看不懂，我们关心结果就好）。
比起全排列组合，肯定会有遗漏，但这个遗漏从概率学上来说，是可以被接受的。

感谢支持~

可参考 ：https://testerhome.com/topics/30771

入门级：

熟悉几款常用的测试框架，如接口测试用到的 Junit，Pytest 等，性能测试用到的 Jmeter，Locust 等，基于 UI 的 Selenium，Airtest 等

进一步的，能够针对这些框架，结合团队的具体业务需求，进行简单的二次开发，例如改改报告格式，增加点输出和特定函数等

从团队建设的角度看，这类技能一般会让测试团队内的谁对代码兴趣并能持之以恒的学习，就可以让他去尝试做这类工作。

提升级：

了解不同框架的特性，能够结合不同项目的实际情况，做具体的选型（例如，团队如果普遍代码能力较差，用 Jmeter 做接口也不是不可以接受。如果被测试系统用的是 JAVA 框架，引入 Junit 要比 Pytest 合适的多）

能够对框架进行重构，以便更好的使用或者更符合业务需求。能够把这些框架集成到其它平台，让其它平台能够快速调用并执行测试用例。

能够洞察测试活动中的真实痛点，并给出解决方案。当你具备了这个能力，才能胜任一个测试开发应该有的责任，否则和开发的区别并不大，又或者只是一个有一定代码能力的测试人员。对团队的重要性并没有那么大。

进阶级：

能够从全局观察测试活动，发现团队存在的共性问题，并提出自己的解决方案并加以落地。

从效能的角度提升团队的测试质量和效率。个人认为，这个是高阶测试开发的核心竞争力。这个时候，测试开发应该关注的是如何提升整个测试团队的效能，同时能够打通研发侧，协助开发一起提升研发效能。

需要向业内优秀的团队学习最新的技术实践，现在新的测试技术层出不穷，迭代速度也很快。不能固步自封，只满足于现状。要关注业内技术的发展，但不要盲目的引入到团队中，因为很多时候，你的团队并不具备相对应的能力。

500 肯定不算呀，500 是 HTTP 状态码，需要和业务码区分开来的

提下个人的看法：

1. 服务端是否应该把程序的内部错误直接暴露出来。这个各有优缺点。好处就是可以比较直观的看到引发问题的根本原因是什么，方便快速定位问题，而不需要去后台查看日志。缺点就是会有安全隐患，容易被定向验证。

2. 一般的处理方式是和前端约定好业务 code，比如 20000 表示业务成功、50001 表示用户名为空之类的，前端根据业务状态码来给出相对应的提示。这样既方便后端定位问题，前端暴露给用户的提示信息也会更友好些，一定不能把异常信息直接在页面上展示出来，太难看了。接口返回不应该只有一个 Http 状态码的。

3. 至于接口的异常类处理，这个每个团队都有自己的做法，这里就不做评价啦。

4.接口提测准入，这个个人不是很建议，我们还是要和开发达成共识。研发中有一条提倡的规则叫 约定大于配置 ，对团队其实也适用。

如果你是做测试的，请尊重测试这个职业。能力有限，谁干测试？？测试怎么你了？如果没有能力，你也不太可能在测试领域混的太好。

如果你不是做测试的。那请你不要用自己的揣测来评价一个职业。

做为一个 10+ 年的测试从业者，期待你的回复

已收到，感谢组织

压力机的并发数 并不等于 服务器处理的并发数，这是两个概念。因为服务器的处理能力首先会取决于 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 楼已经说的很多啦，可以参考。至于题主提到的 “如果我是公司的创始人，我会把测试部门干掉，把这些测试管理者干掉。” 我只能说，庆幸你不是创始人。