---

前言

执着于手动的功能测试：不想写代码

我就是为了不写代码才做的测试，结果你告诉我测试也要写代码。
不想写代码的测试不是好司机。研发过程中的角色界限越来越模糊，手动的功能测试所占的比例越来越低，我们有更高效的自动化测试来辅助回归和缺陷预防。不管是自动化测试的实现，还是编写或评审单元测试，亦或是快速识别定位线上问题，都需要测试人员有一定的代码能力。

手动的功能测试人员（有些小伙伴戏称之为 “在前端界面上点点点”）面对这种复杂的测试需求将无法快速响应，失去竞争力。

迷信自动化测试：沉迷细节无法自拔

美妙人生的关键在于你能迷上什么东西。
技术这件事，真的很容易让人投入热情，造成一种我在努力拓深知识深度的错觉。曾几何时，我也迷恋各种测试工具的使用和选型对比，时常沉溺其中无法自拔，随便调试一下半天就过去了。

看着机器跑代码总比手动执行用例要爽得多，有种人机合一的掌控感。然而，随着对质量的理解逐步加深，我也在反思，像这种把有限的生命投入到无限的技术细节中去的行为，到底价值几何。现下可以确定的是，技术只是手段而非目的，技术只是过程而非结论，技术只是工具而非方法。为了技术而技术的行为，无外乎是另一种麻醉自己的精神鸦片罢了。

只关注当下技术：不关注新技术

一叶障目，不见泰山。功利性学习无可厚非，毕竟任何学习都是为了服务于具体场景，需要解决具体的问题。

但在环境复杂多变、竞争激烈的当下，掌握单一技能的生存空间会越来越狭窄。具体到测试工作上，我们只关注眼下用到的技术是不够的，还应关注新兴技术和业界最佳实践；甚至只关注测试还是不够的，更应该着眼于端到端的流程：需求如何产生，如何被实现，如何被用户使用，如何持续作用于业务价值等等。

忽略策略和计划：不规划直接上手测

废话少说，做就是了，代表了相当一部分同学的想法。什么策略啊计划啊，那些东西过于虚无飘渺，产生什么价值呢？那不是我们考虑的事情，我们只管测试就好了。

这让我想到之前在项目上重建工作流的痛苦和阻力。策略层面的内容，如果一开始没有想清楚就贸然动手做，后面带来的修改成本是巨大的，返工的工作量甚至会大于原始的开发量。

二八原则用在策略上再恰当不过：之前是想5%做95%恨不能007，之后能不能想50%做50%，甚至想80%做20%？为什么做的精力投入会越来越少呢，因为我们想清楚了，剩下的就是检查点和按部就班的执行了。

执着于找Bug：忽略缺陷预防

在一些质量工作场景下，缺陷的数量是用来衡量测试人员绩效的一个重要指标。但这很容易造成一个误区，片面的追求缺陷数量，而忽略了缺陷预防。在这种度量背景下，测试的目标是破坏软件，缺陷越多越能体现测试的价值，因此测试会绞尽脑汁多提Bug。而开发的目标是实现功能，Bug越多说明实现效率越低。这种追求数量的度量方式很容易引发团队的割裂、针对重大线上问题的追责、质量工作重点的偏离等现象，这是我们不愿意看到的。

进一步说，不同的缺陷之间本身也没有可比性，我们不能说一个重大缺陷等于若干个普通缺陷，因此缺陷数量的绝对值累计是不具备统计意义的。我们应该把更多的精力放到如何预防缺陷产生上面去，关注缺陷预防才能更有效的避免全量测试和频频救火的困境。

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

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

其实你现在在哪里，并不是那么重要。只要你有一颗永远向上的心，你终究会找到那个属于你自己的方向！加油！

你要尽全力保护你的梦想，那些嘲笑你梦想的人，他们必定会失败，他们想把你变成和他们一样的人。你要坚信，只要心中有梦想，你就会与众不同。

你不能决定太阳几点升起，但可以决定自己几点起床。你不能控制生命的长度，但可以增加生命的宽度。别嫉妒别人的成功，在你看不见的时候，他们流下了你想象不到的汗水。与其羡慕，不如奋斗！