30岁的测试人？软件测试“内卷“？“我“该如何冲出破圈...

---

前言

1、软件测试的内卷是怎样的？

在谈起测试圈的内卷之前，我们必须先搞清楚我们常说的内卷是什么。

内卷，网络流行词，本意是指人类社会在一个发展阶段达到某种确定的形式后，停滞不前或无法转化为另一种高级模式的现象。当社会资源无法满足所有人的需求时，人们通过竞争来获取更多资源。

在测试圈，随着基于敏捷甚至是Devops的架构，作为这些架构重要内容的自动化成为了热门，而测试行业也进入了推广自动化的“军备竞赛”。

近些年来，不管是作为测试工程师，还是敏捷QA，甚至是其他角色，恐怕都对于自动化测试的汹涌之势都有所耳闻，而从公司角度，在诸多公司中，自动化测试借着敏捷转型的要求也都几乎成为了测试工作的标配。

各大公司对于测试的招聘要求也纷纷升级成为自动化测试，彷佛只要有了自动化测试，一切问题就迎刃而解。事实真的是这样吗？

有一个“电影院困境”，很形象地说明了“内卷”的表现和身处其中的人们的感受：一个电影院里正在播放电影，观众席中黑压压地坐满了观众，这时，前面有人为了看得更清楚，站起来看电影，于是后面的人为了不被挡住，于是也站了起来……终于电影院里所有人都站着看完了电影。而本来他们是可以很舒服地看完这部电影的。

在这个环境下，每个人都付出了极高的时间成本和精力，但是获得的收益却十分有限。

同样的，在测试领域中，按照测试分层测试金字塔进行组合的架构遭到了一定的冲击和破坏。

由内卷化而形成的行业内“纳什均衡”所带来的35岁现象等等，成为附着在这个行业上的伤痕和毒瘤。这个问题以后专门会提到，这次只谈一下测试技术本身的内卷。

测试技术本身的内卷

敏捷测试中，有一个分层测试策略，一般来测试分为三个层次，分别是UI层、Service层以及Unit层。

UI层是负责界面展示和用户交互的那一层，也是测试工程师最常接触到的部分，大量的测试是在这一层完成的，也是涉及方面最广的测试层。

Service层提供接口和服务，UI层可以从Service层获取数据，也可以通过Service层将数据保存于数据库或其他存储空间里。

Unit层的测试对象是函数或方法；Service层的测试对象是模块和接口；UI层的主要测试对象是展示和交互。

这是一个非常完整且工作效率极高的分层机制，它将不同功能和类别的内容进行了归类化，使得针对每一层的测试，都有相应的手段和途径进行相应的测试。

这是基于敏捷框架或者模型下，测试作为适应模型的基础进行的改变。针对不同层级，测试工程师用不同侧重点的测试工具或测试方法，来进行搭配组合，获得最高效和最全覆盖的测试。

当前，自动化测试成为了一个热点，所有的测试工作都开始向自动化转型，而本身只是测试工作一个重要组成部分的自动化测试，瞬间仿佛成为了测试工作升级更新转型的唯一内容，而其简单高效的衡量方式，也使得自动化测试成为了KPI和OKR的青睐对象。

最明显的是，按照自动化测试金字塔理论，大量的基础工作是在单元测试阶段进行的，而接口测试是基于单元测试完成，然后最终通过UI测试进行界面化的验证。这个三角形是自动化测试的策略结构。

1）单元测试

单元测试要求在开发中对每个功能模块（函数、类方法）进行测试，如检测其中某一项功能是否按预期要求正常运行。单元测试中通常采用白盒测试，主要对代码内部逻辑结构进行测试。

2）接口测试

接口测试要求对数据传输、数据库性能等进行测试，从而保证数据传输以及处理的完整性。接口功能的完整运作对整个项目功能扩展、升级与维护有着重要的作用，接口测试通常使用黑盒测试和白盒测试相结合的方式进行。

3）UI测试

UI测试以用户体验为主，软件的所有功能都是通过这一层展示给用户的，因此UI测试的工作也很重要。

单元测试由于大量涉及白盒测试，更基础的方面则是由人员进行代码走查或代码review来完成，而Service则是部分采用人工进行，而UI界面以最终的用户体验为主，因此在UI测试中并不是100%地使用自动化测试。

其中需要人工操作来确定UI界面的易用程度。由此可见，这样的金字塔策略，依然不能完全舍弃手动测试在整个测试工作中的重要作用。

3、测试员如何在内卷中走出来？

测试工程师不得不花费大量的精力，进行自动化测试的改造和框架搭建，而这样的“大干快上”又忽略了自动化测试本身的一些要求。

例如：需求相对稳定，有充足的用例库，交付时间允许项目进行自动化改造等等。造成的一大结果就是，行业中大量的测试工程师变成了以写测试代码为主要工作的工作人员，甚至在职业认知上，将自己有意无意地同开发人员进行了混淆。

这样的结果对于测试行业和测试工程师的职业生涯有着重大影响：

首先，手工测试作为整个测试行业的基础，地位和重要性被大大弱化，很多测试人员的基本能力被大大削弱，而后期的很多能力提升和拓展，都是需要从基于手工测试的分析和操作开始的。

其次，很多测试项目并不适宜进行自动化改造，削足适履的最终结果就是对项目的测试效率等有了极大的限制，本末倒置。

最后，当所有的测试聚焦在自动化上时，会陷入对于技术栈本身的更新和迭代。对于代码能力的提升，显然是一个相对更容易出成果的路径。这样无法将焦点集中在业务本身，这对于测试人员本身能力的发展是极为不利的。

在测试工作中，原本起到规范和框架作用的敏捷架构，就不可避免地受到内卷的影响。

其中对于测试质量和测试覆盖率具有极强规范和限制能力的测试用例，会被大大弱化，大量的测试工程师会主动或被动地向测试开发工程师转型，由原本聚焦在基于业务的测试用例等方面。

转向对于自动化测试架构与脚本的打磨和迭代。当聚焦点从业务移开时，测试工作本身的压舱石——质量，就会不可避免地受到影响。

另外，测试工程师的职业要求，在多方面都有体现，但这样的内卷会使得整个行业的从业人员将注意力向代码能力集中，从而陷入盲目追求代码能力，而不重视测试能力提升基础的怪圈里。

当形成这样的恶性循环之后，测试圈的发展会受到极大冲击，而对于圈中的测试工程师来说，测试技能和测试理念的更新会受到极大的干扰。

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

在生活中，我们难免会遭遇各种困难和挫折，但请你相信：所有的困苦和艰辛都是为了塑造更好的你，所以请勇敢地迎接挑战，让它们成为你前行的力量！

有时候我们会感到迷茫和无助，但请记住：只要有坚定的信念和不懈的努力，总会有一条通往光明的道路等待着你！

每一次跌倒都是成长的机会，每一次失败都是通往成功的踏脚石。不要怕犯错误，也不要担心被嘲笑，因为这些都将是你前进的动力源泉！