软件测试工程师的核心竞争力是什么？

亦凉 2022-02-22 01:13 294阅读 0赞

> 借这篇文章，我们来谈谈功能测试、测试开发、性能测试工程师等的核心竞争力。

在开始这篇文章之前，先问问自己，在软件测试这个行业，你的核心竞争力是什么？你有想过这个问题吗？若想过，你的答案是什么？有想明白吗？

或者，你还在迷茫？

在茹炳晟的极客时间专栏《软件测试52讲》有这样一个问题：“在日常工作中，我们很少会听到开发工程师谈论自己的核心竞争力，往往都是测试工程师更关注这个问题。这是不是从某个侧面反映出测试工程师的核心竞争力不够清晰或者是随着互联网时代的到来而发生了很大变化？”

有用户留言说：“开发很少讨论核心竞争力，是因为开发的学习路线和发展路线比较清晰，而测试，大家都是在迷茫中摸着石头过河。”

也有用户说：“如果是开发转测试，去做测试开发，可能更清楚自己的路线和规划；但如果从功能测试入门，很容易迷茫，因为入门很容易。”

**以下内容来自于2018年11月23日晚19:30的直播整理。嘉宾是有着16年测试经验的茹炳晟，前eBay中国研发中心测试基础架构技术主管，极客时间**《软件测试52讲》**专栏作者。**

![\\"\\"][a81a50c07acd97be01adad1b6dd5d704.png]

# **功能测试、测试开发、性能测试工程师等核心竞争力** #

茹炳晟：这是一个非常典型的问题，因为现在我们看到一个很基础的现象：

*  **功能测试工程师想去做自动化测试，他觉得写自动化测试是价值，他能从中学到新的内容；**
 *  **自动化测试工程师想干吗呢？他觉得我自动化能力已经掌握了，我想更多地了解一些业务，了解这个产品的使用知识。**

其实，他们都在追求自己所当前的一个角色下所没有的能力与内容。

这是好事，也是坏事，为什么？

作为一个工程师，你想清楚自己是在哪个阶段上，你想往另一个方面去发展的话，那么你一定需要在另一个方面去做额外的努力。那么这个做努力的过程中，从知识积累的角度来讲，它一定是从深度再到广度。

那这个深度怎么来？那就是在你所有深耕的领域里，你应该去发挥你专家的作用。**那么我们回到三类工程师，测试开发工程师，业务的功能测试工程师，以及性能测试工程师。**

**1、功能测试工程师。**非常简单，他的核心价值是对产品的理解，对需求的理解，对产品使用的理解，以及在这些产品实现背后的一些实现逻辑。但，这类工程师本质上是有个短板的，这个短板来自于他的知识面会被局限。也就是说，你在这个领域，你是有价值的，但是一旦你离开了这个领域，你怎么能够把你这些专业知识能够很好得带出去，这其实是值得这类工程师深思的一个问题；

**2、对于第二类工程师，我们称之为测试开发。**测试开发工程师是现在非常热门的一个职业，可以说，所有的测试工程师基本上都想往那个方面去发展。为什么？因为在这个时代，你说一个工程师，一个软件方面的工程师，一个工程技术人员，如果他没有掌握开发的技能，没有代码的技能，他不能称之为一个优秀的工程师。那么在这种情况下，我们会去想测试开发的价值，无论从工程效能的角度来讲也好，还是从具体的这种工具链上，测试开发的确带来了很多帮助。有人说，这个职业工资高。工资高，说明企业愿意出这个工资给你，一定是认可你能够带来更高的价值。

做测试开发也会遇到一个很现实的问题，如果你想做测试开发，你第一个要解决的是你的开发技能，因为有很多半路出家或者非计算机专业的，信息类专业的，他对计算机领域的知识，或者说一些基本的编程语言知识是相对薄弱的，那么在这种情况下，他要去转成测试开发的话，他需要很大的开发工作积累。而且开发工作的积累，单靠你一些语言的学习并不能真解决很核心的问题。为什么这么说？因为你学的是书本上的东西，而真正的开发，一定来自于那些工程实践，你只有做过真正的工程实践，你对这个语言的理解，你心里才是有底气的。

那么更进一步的来讲，我想问大家一个问题，测试开发工程师到底是测试重要还是开发重要？如果有两个优秀的候选人A、B都去面试测试开发的岗位，A是测试的背景很强，开发相对薄弱，那B是开发相对很强，但是测试薄弱，那你怎么来选人？

站在我个人的角度来讲，或者站在我个人的经验来讲，我是觉得测试要比开发来的重要，为什么？因为从整个行业来讲，你不缺的永远是优秀的开发人员。但是能够站在测试的角度，能够提炼测试的需求，并且把测试当中的一些难点，或者一些能够提高工程效能的点进行提炼，并把它做成工具，这种测试人才是很稀缺的。

我在我的《软件测试52讲》专栏里提到过很多方法，像我们做的Test  Data  Service、测试服务、测试执行服务，这些东西本质上并不是很难，它比业务系统的开发来的简单，而且它的可用性，包括它各种各样的要求也都要比传统的市场上面向终端用户的要求来的低。但是这类软件的核心价值就在于你能想到去做这个事情，并且能很准确地打到这个点，并把这件事情做出来。完整作出这件事情，会很大程度上去提高你的开发、测试以及整个DevOps整个生命周期。这种情况下，这类人的核心价值应该更多的是在测试，开发只是辅助的，**所以说测试开发工程师的核心价值，是对测试的生态的理解，以及对工具需求的提炼，以及把这些提炼出来的需求以最简单的方式最容易落地的方式来做实现。**

**第三类，性能测试工程师。**我为什么只讲性能不讲安全？因为性能和安全是从一个能力的核心竞争力来讲，他们很像，他们属于专才。这类人的知识是需要经过很长时间才能积累起来，而不是一蹴而就，也不是通过一个简单培训就能够把这类人培养起来。这种人，他看到的业务场景越多，看到过的问题越多，他能很快地根据这个问题的现象，去决定进一步做怎么样的测试，或者去拿哪些指标。有了这些指标之后，他可以快速缩小问题的范围。

这种能力来自于哪里？这种能力很大一部分都来自于实践工作经验，你在工作经验中看到过这个问题，你才能去解决这个问题，你才会这方面会有想法。性能测试工程师就像医生，他去给病人看病的时候，医生会让病人去验血，会拿到一个验血报告，验血报告上面说有大量不同血液的指标，但是一个血液指标拿到很容易吗？现代化的仪器就能帮你拿到了，那么性能测试指标能拿到吗？也非常简单，监控工具可以帮你拿到各种各样的监控数据，这是很容易帮你拿到的，但是拿到的这些数据意味着什么？你能通过这些数据里面，看出什么问题来吗？

有经验的人通过这些数据看到左右问题的本质，或者是这个问题的方向，进一步应该往哪个方向去看这个问题，但是没有经验的人，这对数据来讲，就是一堆数据，它不能解决问题，所以说测试工程师，性能测试工程师，很大一部分来自于经验的积累，一定是通过很长时间的去培养，总结出来的。

![\\"\\"][83be5740296ea04773a8a8f95cc25154.png]

# 为什么会讲到“软件测试开发者的核心竞争力” #

茹炳晟：这是个非常有意思的话题，就像我们经常说的“团队中的价值问题”，你经常看到测试人员自己在想，我们的价值在哪里、是什么？但我们很少看到软件的开发人员或者架构师，或者运维团队去问这样一个问题，要去找自己的价值。这是因为测试人员对这个价值本身是不太确定的，那么这个价值本身不确定，就会带来的一系列的问题。

> **你在整个快速发展的互联网时代，整个IT的发展时代里，你如何定位自己？你怎么样能够成为一个优秀的工程师？怎么样成为一个不被时代所淘汰的，并且能够紧跟时代步伐的这样一个工程师？这样的一个工程师你的核心竞争力又在哪里？**

记得刚一开始从事软件的时候，有些大学的本科，或者研究生毕业，他们去面试工作的时候就会发现，面试下来的是代码能力可能不是太好，这种情况下公司会问你愿不愿意去做测试？但随着现在这个时代的变革，现在的软件测试工程师，他的知识面，以及他需要掌握的内容已经远远超过了之前，可以说他的知识面是远远超过开发的，比如在一些技术的面上，以及对产品的理解上。

那么这种情况下，我们再去提一个优秀的软件测试工程师的核心价值，我们可以很自信地说，测试工程师是一个不可被替代的，并且是一个专业细分化的领域。像早年的时候，我们谈到测试，就是软件测试，没有细分市场，但现在你去谈测试，测试现在的领域太多了，除了传统意义上的，基于业务领域的测试，然后还有测试开发。

测试开发里面又分为两个大的分类：

1.  **一类是专门做测试基础架构，做平台，做工具开发的；**
2.  **还有一类是专门去这些平台去做测试用例的，自动化测试用例开发的。**

这种情况下，又是两类不同的工程师，那么他所Deliver的价值也是完全同的，那么更进一步，我们还会看到有很多所谓的安全测试工程师、性能测试工程师，这一类都是一些垂直领域的。在每个垂直领域上，大家都有自己非常专业的领域，而且有非常专业精神的知识，尤其是对于像那种性能测试工程师，他知识面的积累不管从广度，还是从深度来讲，都需要很强的系统架构师层面的支持，他才能够成为一个比较优秀的工程师。

当时在专栏里写《软件测试工程师的核心竞争力是什么？》这篇文章，我就是想让大家走出迷茫期。因为我相信，很多测试人是很迷茫的。因为在整个IT行业的快速发展下，会出现很多的中小型企业，这些中小型企业处在一个快速去堆功能的阶段，他对于软件的测试及对软件的质量本身，并不会有太多的投入。刚开始，他是想把整个功能堆起来，在这种团队里面会有测试，但测试的地位，或者他所扮演的角色、价值通常不会很高，因为他通常是从功能做出来的，在后面去把这个东西快速地测一把。**那么这种角色多了之后，或者做了大量重复工作之后，他会对自己的职业发展产生很大的迷茫，不清楚我所做的这些重复性的劳动的意义何在？以及我的价值，我的将来在哪？**

我想通过这样一篇文章告诉大家，测试领域有很多东西是值得的做，如果你觉得重复做事情，非常烦琐，那其实就是你的一个机会。也就是说，有很多东西都不称心，比如工具不称手，流程不称手，或者说你的工作大量重复，那就意味着，从测试的角度，从自动化的角度，从工具的优化，从测试基础架构的建设，你有很多东西可以去做。

去考虑把你身边天天碰到的这些重复性劳动，用一个简单的脚本，或者做一个简单的工具去做优化，这就是你的一些价值。这种价值，一方面是来源于你对整个知识体系的理解，你的想法，你的思想方式，以及你的行动。那么在这个过程中，你就体现了你作为一个测试人员的价值。随着你做的这种工具越来越多，随着你做的知识面越来越广后，你会发现，你能做的事情就会更多。

当你很肯定，很自信地确认自己所做的东西是有很大的应用场景的，解决很多问题的时候，你不会再回过头去想，我今天所做的工作的Value在哪里？我的价值在哪里？

# **当测试人想往高处走时，是追求测试的深度，还是测试广度？** #

这也是一个非常好的问题。  
因为早年的时候，我们学习新的技术，或者我们学习一些新的方法，学习资料的资源是比较有限的，我们只能认准一本书，认准一个学习资料慢慢去啃。但现在，整个互联网的技术发展突飞猛进，一天一个样，发展的速度真的实在是太快了，而且信息本身的体量，数据量都是成指数级的爆炸，在这种情况下，测试工程师就会比较迷茫，到底是把一件事情做精了，还是应该更广泛地去掌握更多的知识。就像现在的测试工程师，如果你不懂系统的架构知识，如果你不懂容器知识，你是很难成为一个优秀的互联网时代测试工程师。

**那你是怎么去做权衡、去做取舍？因为大家的时间、精力总是有限的。从我个人的经历来讲，一定是从深度再到广度。**

我所讲的“深度入手”并不是说，你一定要把某一个点做得非常深，而是不要轻易放过！你在工作当中，如果接触到了一个技术，或者接触到了一种架构设计，或者接触到了一些算法，你千万不要把它轻易放过，你不是得过且过，我测了就测了，我知道了就知道了，你一定要刨根问底。比如说你碰到一个缓存问题，不是说解决这个缓存问题就OK了，你测试完就OK了，你需要把这个缓冲问题的来龙去脉，以及它的发展，以及整个缓存的基本原理，都搞清楚。

碰到一个击破一个，碰到一个击破一个。

如果你能坚持以这种方式来对待技术本身的话，你很快会发现，你每个接触过的技术都会变得比较深入。随着你的项目接触的越来越多，做到的事情越来越多之后，你很快就会发现，你有了深度的同时你就有了广度。

对于广度我也有一些建议，我在我的测试专栏里有一篇文章，“作为一个测试工程师，我们尽可能应该去掌握的知识点有哪些？”。比如说如果你没有互相网基础架构的知识，你想做测试是很难的，或者说你不知道自己不知道，那么会让自己陷入一个很被动的局面。

对于这种软件，我还提到了，我们还应该去学容器、云这类知识。你要刻意去做这种广度上的学习，因为这类知识在整个体系下已经用的越来越多了，你所在的开发环境，你已经逃不过Docker了，已经逃不过容器了，你所有的应用都在云端了，你怎么样通过云端，你如果对AWS不熟悉，对PCF不熟悉，你怎么样来去部署你的测试环境？怎么样来部署你的开发环境？怎么样将你的测试执行环境，测试基础架构建在云端？

我个人的建议是通过一些额外的方式，通过自学习的手段，去做一些有意的积累。**极客时间就提供了这样一个很好的平台，对于一些热门的技术都有特定的专栏。虽然我是极客时间专栏的作者，但我自己也订阅了很多极客时间的课程，因为有文字且配有音频，就可以利用很多碎片化的时间来学习。比如说我坐地铁的时候，我就会用这段时间来听一个5分钟到15分钟的音频，比你刷微博、朋友圈收获的更多。**

# 测试想去转测试开发，他需要积累哪些经验？ #

一个普通的测试人员，可能更多想转型为测试开发工程师。那需要什么知识点呐？

我觉得技术的路是没有捷径可以走的，如果你想转成测试开发，**那就意味着你要有开发的基础，这种情况下，你做得第一件事情是掌握一门语言。**不要多，只掌握一门语言就行。这意味着你是真正地掌握，从骨子里掌握这门语言，而不是简单写个Hello  World。而是你要掌握编程语言很核心的东西，并且你能够通过编程来做一些实际的项目。

**从个人发展角度来讲，我更倾向于学Java。**因为Java的面更广，Python虽然好，它更多的还是在测试领域里面。当你一旦跳出这个测试圈子，你想做更多的事情，Java语言还是会来的更好。这是我的一个建议，从开发的基础职能入手，去实践去编程。专栏告诉你的是一个方向，是一些思想方法，以及整个生态，以及工具体系的分析，而不是我手把手教你一个工具。手把手教你一个工具是没有价值的，因为学一个工具最好的路径去看官方文档，官方文档一定是最新的，而且最全面的。

# 测试用例的力度怎么去把控？ #

我们如果要把这个问题谈清楚，就要看它是一个GUI的测试，还是一个API的测试。不同的测试用例的力度把控差别是非常大的，而且产品的不同阶段、不同规模，还有项目的性质，对于测试力度的把控也是会有巨大差别。

举个简单例子，如果是一个长期的产品，自动化会进行长期维护的，那么一定要做可复用很高的力度，并且这些可复用的脚本可以被尽可能的多测试用例去使用。但如果是一次性的项目，或者能够短期项目性的产品，做完之后也就不维护了，但是你想做一些基础的自动化，这个时候你就压根就不需要去考虑自动化的力度，你只要用最快的自动化方式给测试用例实现了，那就可以。这种情况下我们就不用谈力度。

用例的力度没有说一定对，或者一定错，而一定是基于上下文去找到最适合自己的东西。对于用例的力度，

那为什么别人能够针对某一类测试系统，或者某一类东西给出比较好的测试解决方案呐？或者说是测试的策略？那是因为感觉。经过长期积累，别人形成了对这种技术本身的一种感觉，在无形的情况下，形成一些有形有价值的东西，帮助你快速且准确地给出方案。这就比较重要了。

最后说一下，我的《软件测试52讲》专栏已经完结了，共62篇文章，码写了26万3948个字。通过一系列行业最佳实践案例的讲解，为大家呈现一幅包括GUI/API自动化测试、测试数据平台、测试基础架构建设、性能/压力测试、代码级测试、测试新技术和大型网站架构等在内的软件测试技术全景视图。

[a81a50c07acd97be01adad1b6dd5d704.png]: /images/20220222/d9bff9fc1f28445bada8a0ec7070ec3c.png
[83be5740296ea04773a8a8f95cc25154.png]: /images/20220222/7fddcc1d80fd40c69c2830d27a28a9da.png