没那么多前置条件。。现实是，只要有坑了，你能占到，那么经过一段时间的磨炼，其实就可以做到。

测试经理并不是特别高端或者需要专业性特别强的能力。

能够协调资源，把事办好，就 OK 了。

专业技能？3~5 年的测试经历足够了。

每种测试方法都会有自己的优势和局限性，不能因为上层的测试方法没做，就让上层的测试方法去兜底。电动车的例子不是很恰当哟。

接口测试的核心是验证交互的数据结构是否正确，保证数据能够端到端正常流转，满足业务的需求。在这里加入过多的数据层验证，其实是没有必要的。如果有涉及到数据层的操作（如数据初始化等），应该独立出来处理。

因为接口测试封装了相关的内部实现，仅仅从入参来验证出参，很多时候并不是直接查某个表就能够解决的，往往包含了很多的业务计算逻辑在内。 如果是简单的表查询，检查的意义也不大。

另外 ，关于验证码的问题，就不应该成为问题，一个万能码就可以解决了。完全没必要读库，而且这东西大概率也是放在 redis 上，不会入库的，因为有时效性，又没有什么业务价值。

分层测试的理念，就是每层干自己该干的事，做到更好的解耦，方便定位问题。

敏捷研发模式表示不背这个锅。。因为敏捷本身没有问题，有问题的是落地过程中，大家只关注了 “快”，而忽略了人。

“给到业务测试的时间，根本就不够” 可以尝试引入部分的自动化测试手段来提升效率，或者加入一些小工具。时间一直都是不够的。

“又加上开发不自测”，这事吧，做好测试准入条件的设置。敏捷中不也有 DOD 的理念么。

“经常背锅，挨骂，背低绩效” 这个没啥好说的，不同团队对质量的关注度不一样，所以可能的话，还是远离这类团队吧，因为三观不同，你做啥都是错的。

综上，换个环境吧，可能对你会更好些。测试人也需要有选择团队的能力。

建议是分开来写，因为关注的重点不一样。

所以每次不要拉太多人，没有必要。

感谢兔兔

理解，感谢回复

可参考：https://testerhome.com/topics/33655 写的比较全面了

感谢支持，可持续关注

@chenhengjie123 本篇是否可以申请加精

关于代码本身，需要关注的就是基础的应用，找个优秀的开源框架，慢慢去阅读和理解它的代码逻辑，远比自己乱写一些平台要好的多。然后根据团队的真实痛点，针对性的通过代码解决一些具体问题，在解决问题的过程中提升自己。
加油~

具体到团队中，对于测开的能力要求，我简单的划分为以下三类（欢迎拍砖）：

入门级：

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

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

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

提升级：

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

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

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

进阶级：

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

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

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

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

因为这只是个首页，所以不涉及复杂的后端业务逻辑处理。这类问题个人的经验是从架构层面去梳理，可能都不需要压测：

1. 是否对图片做了压缩处理，当前页面的总大小多少，服务器的带宽是多少，可以估算出是否能支持 10000 并发；
2. 是否做了静态分离，对于静态服务器是否有 CDN，如果有，策略是什么，有多少节点；
3. 视频是直接播放，还是需要手动点播放，是否有缓存部分到前端；
4. 视频是否走了 CDN，节点带宽是多少，视频有多大

以上，其实你弄清楚了，就可以估算出来了。静态资源的加载，一般不需要压测的，因为核心是带宽，不是服务器处理能力。

主要是在手忙脚乱了一阵子，倒没什么影响很大的 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+ 年的测试从业者，期待你的回复