内卷时代，普通测试员的铁饭碗究竟是什么？

lsekfe

内卷，是现在热度非常高的一个词汇，随着热度不断攀升，隐隐到了“万物皆可卷”的程度。究其来源，内卷这个词的出现，是伴随着996的讨论开始的。
　　很不幸，996、福报这些词的重灾区和源头就是计算机/互联网行业，那么作为行业中一个非常重要的分支，测试圈的情况怎么样呢？

　　软件测试圈的内卷是怎样的？
　　在谈起测试圈的内卷之前，我们必须先搞清楚常说的内卷是什么。
　　内卷，网络流行词，本意是指人类社会在一个发展阶段达到某种确定的形式后，停滞不前或无法转化为另一种高级模式的现象。当社会资源无法满足所有人的需求时，人们通过竞争来获取更多资源。
　　后经网络流传，用来指代非理性的内部竞争或“被自愿”竞争，现在指同行间竞相付出更多努力以争夺有限资源，从而导致个体“收益努力比”下降的现象，可以看作是努力的“通货膨胀”。
　　在测试圈，随着基于敏捷甚至是Devops的架构，作为这些架构重要内容的自动化成为了热门，而测试行业也进入了推广自动化的“军备竞赛”。
　　近些年来，不管是作为测试工程师，还是敏捷QA，甚至是其他角色，恐怕都对于自动化测试的汹涌之势有所耳闻。
　　而从公司角度，在诸多公司中，自动化测试借着敏捷转型的要求，也几乎成为了测试工作的标配。
　　各大公司对于测试的招聘要求也纷纷升级成为自动化测试，彷佛只要有了自动化测试，一切问题就迎刃而解。
　　事实真的是这样吗？
　　有一个“电影院困境”，很形象地说明了“内卷”的表现和身处其中的人们的感受：
　　一个电影院里正在播放电影，观众席中黑压压地坐满了观众，这时，前面有人为了看得更清楚，站起来看电影，于是后面的人为了不被挡住，于是也站了起来……
　　终于，电影院里所有人都站着看完了电影，而本来他们是可以很舒服地看完这部电影的。
　　在这个环境下，每个人都付出了极高的时间成本和精力，但是获得的收益却十分有限。
　　同样的，在测试领域中，按照测试分层测试金字塔进行组合的架构遭到了一定的冲击和破坏。
　　由内卷化而形成的行业内“纳什均衡”所带来的35岁现象等等，成为附着在这个行业上的伤痕和毒瘤。

　　测试技术本身的内卷
　　敏捷测试中，有一个分层测试策略，一般来说测试分为三个层次，分别是UI层、Service层以及Unit层。具体结构如下图：

　　UI层是负责界面展示和用户交互的那一层，也是测试工程师最常接触到的部分，大量的测试是在这一层完成的，也是涉及方面最广的测试层。
　　Service层提供接口和服务，UI层可以从Service层获取数据，也可以通过Service层将数据保存于数据库或其他存储空间里。
　　Unit层的测试对象是函数或方法，Service层的测试对象是模块和接口，UI层的主要测试对象是展示和交互。
　　这是一个非常完整且工作效率极高的分层机制，它将不同功能和类别的内容进行了归类化，使得针对每一层，都有相应的手段和途径进行相应的测试。
　　这是基于敏捷框架或者模型下，测试作为适应模型的基础进行的改变。针对不同层级，测试工程师用不同侧重点的测试工具或方法，来进行搭配组合，获得最高效和最全覆盖的测试。
　　当前，自动化测试成为了一个热点，所有的测试工作都开始向自动化转型，而本身只是测试工作一个重要组成部分的自动化测试，仿佛成为了测试工作升级更新转型的唯一内容，而其简单高效的衡量方式，也使得自动化测试成为了KPI和OKR的青睐对象。
　　最明显的是，按照自动化测试金字塔理论，大量的基础工作是在单元测试阶段进行的，而接口测试是基于单元测试完成，然后最终通过UI测试进行界面化的验证，这个三角形是自动化测试的策略结构。

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

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

　　UI测试
　　UI测试以用户体验为主，软件的所有功能都是通过这一层展示给用户的，因此UI测试的工作也很重要。
　　单元测试由于大量涉及白盒测试，更基础的方面则是由人员进行代码走查或代码review来完成，而Service则是部分采用人工进行。
　　而UI界面以最终的用户体验为主，因此在UI测试中并不是100%的使用自动化测试，其中需要人工操作来确定UI界面的易用程度。
　　由此可见，这样的金字塔策略，依然不能完全舍弃手动测试在整个测试工作中的重要作用。
　　需要注意的是，很多鼓吹测试全面自动化的管理人员，甚至没有细细区分这两个图例的差异，就简单地将二者合一，将自动化测试策略和分层测试策略进行了混淆。
　　在开发人员陷入针对框架和前端机制无休止地更新追求下，内卷也逐渐向测试圈进行扩展，但是和开发中单纯求新求快的情况又略有不同。
　　当决策层的好大喜功和自动化测试的特点结合起来的时候，简单粗暴地大干快上成了唯一的选择，于是，测试技术的内卷就这样轰轰烈烈地开始了。

　　测试员如何在内卷中走出来？
　　测试工程师不得不花费大量的精力，进行自动化测试的改造和框架搭建，而这样的“大干快上”又忽略了自动化测试本身的一些要求。
　　例如：需求相对稳定、有充足的用例库、交付时间允许项目进行自动化改造等等。
　　造成的一大结果就是，行业中大量的测试工程师变成了以写测试代码为主要工作的工作人员，甚至在职业认知上，将自己有意无意同开发人员进行了混淆。
　　这样的结果对于测试行业和测试工程师的职业生涯有着重大影响：
　　首先，手工测试作为整个测试行业的基础，地位和重要性被大大弱化。很多测试人员的基本能力被大大削弱，而后期的很多能力提升和拓展，都是需要从基于手工测试的分析和操作开始的。
　　其次，很多测试项目并不适宜进行自动化改造。削足适履的最终结果就是对项目的测试效率等有了极大的限制，本末倒置。
　　最后，当所有的测试聚焦在自动化上时，会陷入对于技术栈本身的更新和迭代。
　　代码能力的提升，显然是一个相对更容易出成果的路径。这样无法将焦点集中在业务本身，这对于测试人员本身能力的发展是极为不利的。
　　在测试工作中，原本起到规范和框架作用的敏捷架构，就不可避免地受到内卷的影响。
　　其中对于测试质量和测试覆盖率具有极强规范和限制能力的测试用例，会被大大弱化，大量的测试工程师会主动或被动地向测试开发工程师转型。
　　原本聚焦在基于业务的测试用例等方面，转向对于自动化测试架构与脚本的打磨和迭代。当聚焦点从业务移开时，测试工作本身的压舱石——质量，就会不可避免地受到影响。
　　另外，测试工程师的职业要求，在多方面都有体现。但这样的内卷会使得整个行业的从业人员将注意力向代码能力集中，从而陷入盲目追求代码能力，而不重视测试能力提升基础的怪圈里。
　　当形成这样的恶性循环之后，测试圈的发展会受到极大冲击，而对于圈中的测试工程师来说，测试技能和测试理念的更新会受到极大的干扰。
　　不忘初心，方得始终。在技术浪潮不断更新迭代的今天，测试工程师也应该做到“不忘初心”，所谓形而上者谓之“道”，在意识方面，始终将业务需求作为工作的基准，把握住质量核心，需求基准。
　　形而下者谓之“器”，不管是手工测试，还是自动化测试，抑或是探索性测试，都是要基于“道”这个初心，围绕着测试工作服务。
　　只有这样，测试工程师才能在测试圈不断内生或外压的内卷中，走出属于自己的职业道路。
　　IT工作固然是辛苦的，软件测试当然也不例外。 每天执行用例、跟踪Bug，还要与开发、产品同学争吵PK，与人斗其乐无穷~
　　但正是因为这些默默的付出，才让一场本该在用户面前发生的灾难，提前在自己面前发生了，是否有一种救世主的感觉？
　　我们拯救了用户，也拯救了这一软件，避免了她被抛弃、卸载的命运。既然选择了测试这一行，那不如不忘初心，好好坚持下去~

lyp1314

很赞