为何测试困在内卷陷阱里？

本来老张约ckl和我做一次圆桌讨论，无奈疫情原因我参加不了，ckl和老张联合来了一场直播，对于直播的话题我们也想了下，相对于各类专项技术，不如聊一聊大家的现状以及可能突破的方向，关于测试为何困在内卷陷阱里，这个话题显然比较实际，事实上老张和ckl也聊的很充分，下面内容是一些核心总结点。

怎么卷：

• 比谁测试执行做得多/case多，一个case拆成多条。
• 比谁测的bug多，以及前端bug多还是后端bug多。
• 线上的bug逃逸率。
• 测试人员的平台开发能力。
• 效能度量大PK。
• 卷工时。

为什么陷入内卷陷阱：

• 测试门槛低，进入的同学很多，存量市场下筛选门槛变高。
• 行业的发展，包括技术和业务，很多测试同学并没有跟上，低维度的同学多了。
• 企业利润降低，需要降本增效。
• 能力与年纪不匹配，危机带来的求生欲。
• 大蛋糕给基层是最少的，基层最卷。

面对内卷应该做：

• 测试门槛的提高是好事情，可以更多的筛选一部分人
• 专注自己能力的提升，做大属于自己的蛋糕，自己的范围做精，辐射其他需求、研发环节，如产品实例化、产品验收，端到端拉通。
• 技术领域菜是原罪，注意下班后的学习时间分配，比如提升代码和测试思维能力，能够有与产品和开发同频对话的能力，并且能够验证需求方案或者技术方案的合理性。
• 如果你选择躺平，也要学会降低欲望。
• 关注新行业、如芯片、人工智能之类等在三五年可能存在机遇和空间，但普通人很难连续换赛道。
• 面向业务，稳住业务基本盘，深入理解业务，与产品、BA可以深入沟通，注重产出，通过你的测试方案设计，你的测试报告能够给团队质量保障的信心，最终技术的价值是通过业务交付来彰显的。

测试的发展方向：

• 敏捷理念，需求实例化，story拆解，运维发布，项目管理各流程吸取经验。
• 更多的测试前置（左移），单元测试，质量卡点。
• 专项测试、平台等能够落地，细化到能够多维度度量。
• 发现过程中的痛点并能够主导改进，如环境不稳定等，如自动化能力，去证明你对过程痛点的改进。

以上，两位大佬给出了现实的案例以及解决方案，从我个人而言，还有一个很重要的点是如何实践，也许大家能看到一些通往罗马的大道，但无奈的是很多人上不了路，说出了很多成长过程中朴素而又现实的痛点，比如

1.学习过程很枯燥，坚持不了。

学习是要有目的性的，很多人说还是为了升职加薪，这是每个人都希望看到的，但这是结果并不是内驱力，你需要细化阶段性的实现目的，比如我想做一个监控系统的报警，先去看看可以实现的技术能力有哪些，然后再去拆解学习目标，做到每一步骤的细化，通过目标去驱动过程，这样子肯定比你每次从字符串、列表开始学习，写最简单的demo来的有效得多，所以学习最重要的是找到阶段性价值目标。

2.我会写脚本但是领导不给机会。

在目前的存量市场下，靠公司给机会做专职自动化几乎不太可能了，在大厂里目前的自动化往往是业务测试人员靠相应的技术框架就自行完成了，至于一些小公司，没有时间可能也就不做自动化了，那为什么大厂可以做小厂会选择不做呢？这就是成本跟效率的问题，一般来说，小公司的业务测试同学框架驾驭能力还不成熟，可能会消耗大量的时间，所以基于这样的一个背景，你需要考虑的问题是你的自动化能力有没有到很成熟，而不是考虑谁给你机会的问题。当然也不是说专职自动化完全不存在，像基于UI或者接口类的专职自动化，目前银行外包还是存在的。

3.我技术能力很强，但还是很迷茫，不知道测试的核心竞争力到底是什么？

这是一部分高阶选手的困惑，能力比较好，但是总感觉自己没有核心竞争力，能解决公司的一些问题，但还是找不到核心价值的定位，论代码能力，又感觉很多开发可以代替自己，这些同学我认为技术够用了，但是对测试的认知有一些偏颇，如果你把单项能力去拆解，你会发现总有岗位能够替代开发，所以说测试真正的价值并不在于单项能力的pk而是体系化解决方案的输出，如果你在这个级别你应该能够深刻的理解质量内建，而质量内建是贯穿整个软件生命周期的，比如上述提到过的需求实例化，反讲，平台的落地、度量、复盘、改进等，你想一下整个流程的质量建设你有没有思考过？而这个流程是对测试执行，测试认知，测试技术的全面提升也是对沟通能力、协调能力、团队融合能力的考量。而这样一个角色对公司产研全流程的影响是巨大的，这样的护城河能力并不是其他角色能够轻易提到或者短期内能够替换的，这些是你需要真正思考的。

感谢两位讲师精彩分享