可以确保周更。。。

理论上是认可这类测试分层的，从研发的角度上来看，确实我们应该多投入时间在单测上，优势很明显，颗粒度小，验证快速快，方便定位。但是在实际的实践过程中，Unit 测试推广不开个人认为有以下几个原因：

1. 成本问题。虽然现在有比较好用的单测框架，但如果真的要产生实际价值，还是需要大量的代码编写，比如 Mock 其它服务，比如数据准备等，而且开发人员的时间和精力有限（现状如此），让测试人员来写 Unit，就更不靠谱了。

2. Uint 无法完整的描述业务价值，它更多的是验证工程实践是否有问题，但很难从业务价值上做出评估。

所以，现在更多的团队选择接口测试这种粒度来快速验证。因为他的粒度相对也比较小，能够做到快速执行，快速反馈，对于代码的定位也是比较快的。而且，好的接口一定是为了实现某些具体的业务价值。所以可以更好的去评估代码与业务价值的关系。

测试策略的选择，还是会受很多现实因素的制约。也是一个不段在做动态平衡的过程。

这不就是回归测试的典型场景么？

回归测试：每天来回走一遍，看看哪里的砖有晃动；

自动化测试：骑个车（轮子宽一点的那种），碾压过去，提高效率，

埋点测试：路上等距离安装摄像头，然后在监控室里观察

用户反馈：人家都投诉了，你还不知道哪块砖有问题？做好安抚，快速修复。

业务需求：有没有一种可能，从业务的角度上看，确实有可能是故意设计的这么脆弱的，否则怎么签二期合同。（别对号入座哈），很多时候有些奇葩的需求都是服务于某些特定的场景，只是测试不知道而以。

简单地把线上 BUG 分成三个等级，便于分析。
简单易现的问题：如果是比较简单就复现的问题，那作为测试人员就要反思下为什么了，这个锅跑不了，还是要有对自己的工作负责的态度。如何避免这类问题的出现呢？有几个小办法：

注重测试策略的设计（好多人都忘记这件事了，后面会专门谈谈测试策略的问题），对于每个迭代（版本）的测试重点和测试方法做一次梳理。
测试用例设计更全面些，多考虑一些业务场景，更多的确认手段，而不仅仅只停留在页面的操作上。
测试用例评审，避免自己陷入测试盲区，让产品和研发一起来确认场景覆盖是否充足。
认真执行测试用例，这点很简单，但是很重要。因为人都会情绪低潮，在某些情况下，心存侥幸，可能用例直接就 Pass 了。
特定场景或者数据才会出现的问题：这种情况，遇到一次，就完善一次用例（如果能自动化，就最好了），同时思考为什么只有这种情况才会出现，类似的还是不同环境配置引起的问题。这类问题需要注意平时的积累，形成自己的经验，这类 “锅”，可以团队一起背，但要给出改进方案，不能多次在同一个地方跌倒。

深层次的偶发问题：这类问题其实是提升团队技术能力很好的试验场，集中力量解决掉就是了，更能激发技术宅男们的热情。这类问题，一般情况下做好线上监控，能及时预警，比客户更早或者不能落后太多发现，就可以的，让团队有缓冲解决问题的时间就好（准备好相关的话术，安抚客户也是 OK 的）。
你看，这么一分，是不是心理负担就少很多了，有些 “锅” 也不是什么坏事。不是么。

你的质量观在哪里‍
最后，再聊聊测试人自己的质量观。每个人走上测试这条路的理由五花八门，也导致了大家对质量这件事本身的看法也有很大的不同。

看法一：把测试这个职业定义为仅仅是保证系统不出重大事故，一点就蹦的情况出现，其它交给开发，出现 BUG 就是开发能力不足。因为他们对测试的理解就出现了偏差，所以遇到比较复杂的，难以测到的问题，就放弃努力，给自己找借口。比如自己薪资就那么点，因为能力有限啊，发现不了还能怎么办？比如你行你来测试啊？谁家软件还没有个 BUG 呢。凡此种种，肯定不会觉得自己应该背这个锅的。

看法二：从自己手中出去的产品，要有最低的质量保证，如果出现问题，及时反思，寻找解决办法，什么 “Bug 藏得太深”、“测试环境无法复现” 等理由都不是借口，总结经验教训，努力提升自己。真正把测试当做职业来对待，一定会想到办法解决或者规避此类问题的再次发生。在做好自己的同时，给团队带来正面影响，逐渐影响到其他人。

看法三：通过更好的实践方式，提前预防问题的发生。单测、静态分析、自动化测试，还有现在比较流行的混沌测试，都会帮助我们及早的发现问题。在适当的机会引入敏捷理念，通过自己的能力和实践，协助团队内建质量，培养全员质量意识。

参考：https://testerhome.com/topics/32230

我们说的好像不是一个事。。题主问的是测试工程师这个角色，而不是这个角色中的高中低级别。

高级测试人员的能力强肯定对项目上帮助大，这个没有什么疑问。

这个没有什么必然的联系的。测试工程师在团队中的地位取决于你能给团队创造什么价值，能给研发过程带来什么帮助。地位都是自己争取来的，而不是 title 带来的。

不能说测试人员的 “地位” 高，质量就会好，毕竟测试人员也不产出质量啊。更多的时候，测试人员只能保障产品质量的下限，然后通过质量内建等一些方法来逐步提升这个下限。

关于如何提升测试人员的地位，可以参考：https://testerhome.com/topics/32121

关于第二个问题，不是地位越高，而是能力越强（不管是代码能力，还是横向拉通、解决问题的能力），那么质量保障水平就会越高。现在各类大会上提出的新观点，新技术都在验证这个结论。

没太理解为什么只能用 UI 来准备数据，UI 调的不还是接口么？不太清楚有啥特殊的地方。

另外按题主的说法，可以尝试把这两部分解耦，数据准备和接口测试分开来处理。如楼上恒捷大大说的那种处理方式。

至于是引用工具，还是写代码，就看团队的整体能力啦。

不能仅仅对着操作写用例。试着从这个需求的实现价值开始，想想为什么会有这个需求，用户在什么场景下会用，后台是如何实现的等等方向去思考。

https://testerhome.com/topics/33655 这里有具体的场景和案例，可以参考下。

优秀~~下载啦，好好学习

https://testerhome.com/topics/32826 可以参考下这篇文章，测试还是有很多不同的阶段可以提升的。

那我那篇还能参与这个活动么

还有这种群哇

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

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

能够协调资源，把事办好，就 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，节点带宽是多少，视频有多大

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