如何做好测试开发？| 破解测试人技术成长常见的 3 种错误思维！
【摘要】 本文为第四范式质量部工程效能负责人，霍格沃兹测试学社特邀嘉宾山治老师关于测试开发工程师技能成长的精彩分享。进阶学习文末加群。前言大家好，我是山治老师，目前在第四范式质量部中负责工程效能方向的工作。我在这家公司有 4 年多的时间了，刚来的时候整个质量部加上我也只有2个人。基本上我是看着质量部一点点成长起来的。而在去年年末的时候，经历了 4 年时间发展的质量部也是终于正式成立工程效能部，我也彻底...
本文为第四范式质量部工程效能负责人，霍格沃兹测试学社特邀嘉宾山治老师关于测试开发工程师技能成长的精彩分享。进阶学习文末加群。
前言
大家好，我是山治老师，目前在第四范式质量部中负责工程效能方向的工作。我在这家公司有 4 年多的时间了，刚来的时候整个质量部加上我也只有2个人。基本上我是看着质量部一点点成长起来的。而在去年年末的时候，经历了 4 年时间发展的质量部也是终于正式成立工程效能部，我也彻底告别了业务团队，作为工程效能的负责人开始了新的工作。
而回顾 4 年前质量部刚成立的时候，我们做出了一个大胆的决定，那就是从一开始就以测试开发的标准来进行招聘工作，即便是业务测试人员也要有自己构建自动化测试和开发测试工具的能力，最终组建一个全员测试开发的技术团队。这也是为什么4年来我们在技术上的实践好像上了高速公路一样。而我个人也拒绝了管理岗的位置，选择在工程效能团队继续在技术领域深耕。
所以今天这个关于一些类似职业发展的分享呢，可能会跟其他人都不一样。其他来分享职业经验的人呢，可能已经走到了一个比较高的位置上了，分享的内容也是从很全面很综合的能力上表述的。而我没有选择做管理岗，所以虽然我是公司第 28 号员工，但是到现在我的 Title 也只是质量部的一个测试开发工程师。
今天分享的内容也主要是聚焦在技术能力这一个点上开展，不去划分什么能力模型、技能体系，就单纯的从我们怎么去做好一个技术岗位上说起。我个人觉得这也一个比较好的角度，因为我们大多数人还都是普通的员工的。我这已经逼近 35 岁大坎的一线技术人员今天就来分享一下我这10来年的一些经验，希望能对大家有帮助。
做加法
首先我们讨论一个很普遍的问题，当我们进入测试这个行业的时候，我们该怎么做？
现在比较主流的声音是我们要深耕一个领域，在一个领域内成为专家。这句话是对的，但它有一个前提， 就是你已经在这个行业里摸爬滚打到了一定的程度了，你确信自己擅长什么，自己想做什么。
而初出茅庐的人往往面对的是一种很迷茫的状态，这个时候你什么都没见识过，在这种状态下你怎么能确定你未来要伴随你一生的职业规划是什么呢？
所以这里我可能会提出一个不太一样的声音。那就是刚进入这个行业的时候，可以不用急于去专研某个领域。白岩松老师曾说过在 30 岁之前要玩命地做加法，要去尝试，因为你不知道自己有多少种可能，你也不知道命运将会给你怎样的机缘，不试试你怎么知道呢？
同时这也是我对技术的态度，多去尝试不同的技术，不同的解决方案，你会发现不一样的天空。4 年多前一次很偶然间的想法，我想试试最近不少人在谈论的 Docker，就是这么一次很突然的想法，造就了质量部后面大量的 Docker 和 K8S 的实践，也造就了我后面一直以容器生态为核心向外扩展的技术栈，所以不去试试，你可能都不知道一门技术能给你带来多大的改变。
我一直认为最可怕的不是我们学不会一样东西，而是我们跟本不知道这样东西能做什么或者根本不知道这样东西的存在。在这个行业里，很少出现靠个人努力学不会的东西，只要你肯砸时间耐心的去学，总有学会的一天。
但是如果你墨守成规，本着现有的东西已经能满足业务需要的心态而把自己与其他技术屏蔽掉。这样不论新的技术有多好，能提高多少效率，你都不知道了，那你又何谈进步呢。所以，不要把自己限制在一个小的圈子里，因为这个小圈子没办法养活你一辈子，技术永远在更新在淘汰，永远都有更好的方案出现。所以多尝试，不是一件坏事。
做减法
刚才说的是给自己做加法，尝试更多的新的可能性。但是到了一定的程度后，要学会给自己做减法。
30 岁，是你在做了一系列加法和四处乱跑之后，要做一次减法的重要时间，不然就晚了。
为什么要做减法？因为你不是所有的都适合，也不是适合你的所有的事你都该去做。八条线栓着你，你能跑多远？这 8 条线可能还会互相牵制。
我在之前面临了一个选择，我到底该做什么。尤其是当时从产品上我再推进数据治理方案，业务上我带着一条业务测试团队，而技术上我当时也正在跟 K8S 较劲的正起劲。所以当领导来找我问我要不要转管理岗的时候，我陷入了沉默。我给了自己一周的时间来思考，我自己问自己，我可以做很多东西，可以做技术，可以做产品，也可以做管理以及其他一切好玩的东西。但是最后我对自己说不，我发现自己只能做技术，也最该做技术。而我能拥有今天的一切，都是因为那时做的减法。
当然做减法不是只剩下一个技能其他的都减掉。
我们说的深耕也是在一个领域内的深耕而不是在一个技能上的深耕，这中间是有很大的差别的。不少人都很喜欢走极端，你说要深耕，要做专家，那好，我就奔着一样技术使劲，除了这门技术其他的我都不管了。 这就是一个极端，这就好比独孤九剑，独孤九剑专破天下武功。有破刀式，破剑式，破气式，破掌式等一共 9 式，每一式又有诸多变化，比如破刀式里分为单刀、双刀、柳叶刀、鬼头刀、大砍刀、斩马刀种种刀法。如果你只学了破刀式里的单刀，就算你练的再怎么出神入化，对敌的时候人家拿一斩马刀出来，你怎么破？
所以其实我挺不愿意回答社区里总有人提问到底是 Java 好还是 Python 好的问题，说的好像我们只学一门语言就可以了一样。你 Python 用的再好，当你面对容器领域的工具开发的时候你敢不用 Golang 么？你 Java 使的再溜，当你要写一个 Web 的时候你能不用 JS 么？
我们要知道对于一个好的测试开发来说，同时掌握几门语言和技术是完全是必要的。因为你面对的是各种不同的场景，这不是一招鲜都解决的。
所以，我要强调**我们要解决的是这个领域内尽可能多的问题，而不是只解决一个问题中的各种细节。**解决不同的问题可能会用到不同的语言不同的技术，这很正常。
不要陷入一个极端的状态我要做专家，我要把所有精力都放在一样事情上， 然后专到一个特别细节的东西上去了。我见过有同学就冲着一个接口测试使劲，一做就是几年，你一问就说我接口测试做的特别好，我开发了什么什么框架，什么什么平台。但是你接口测试做的再好，它也只是接口测试。它也只是这个领域内庞大的测试体系中的一环。
所以一个领域和一个技能的差别我们需要明白，如果你只专注一个细节，那就只能偏安一偶做个执行者，因为你撑不起这个团队，你能解决的只是这个团队要面对的形形色色的问题中的一个。如果你想走的更远，就去关注你所在领域里更多的问题。
几种不好的思维
走技术路线当中最不好的几种思维：
-
第 1 种是：当你所拥有的技能已经完全能满足当前工作需要的时候，是即便你学了更多更深的知识也在当前工作中用不到的时候，那种突如其来自满或者是不安。
这是两种截然不同的结果。但怎么处理好这两种情绪是很重要的。
自满是因为觉得一切尽在掌握，他在当前工作里所有的技术问题他都能解决，可能会让他错误的认为他能解决这个领域里所有的问题，或者错误的认为这个领域里就只有这么多问题了。处于这种情绪下的人会自然而然的停止自己的脚步，但是你要知道既然你选择了技术路线那么你的脚步就是不能停的，技术永远在不停的更新换代，停下脚步后，吃上几年老本可能就要被淘汰了。
而不安是因为他意识到自己的脚步已经停下来了以及停下脚步带来的后果，所以这个时候他不安，因为他没什么办法，当前的工作已经没办法驱使他前进了。
自满和恐慌是几乎每个技术人都要经历的，有些人是先自满后面慢慢恐慌，有些有经验经过几次这种状态的人可能是直接跳到了恐慌。比如我现在每年都有几段时间会陷入不安，通常就发生在要推进的方案都落地并稳定了以后，这时候我就会想我接下来该做什么。
所以这时候我们要好好的思考一下，给自己的工作带来一些变化。可以是内部申请调整一下业务线，我们换另一条业务或岗位去寻求一些突破，因为不同的业务有不同的问题，也许在另外一条业务上你又能折腾一段不短的时间并让你在自己的领域里增加更多的竞争力，又或者我们引进一个全新的测试类型或工具平台来给自己带来新的挑战与机遇。
18 年的时候，我曾经陷入过这种状态，当时我大概彷徨了有半个月的时间，我一直在思考在纠结下一步要去做什么。最后我决定引入混沌工程这种我们以前没有的测试类型，在当时我们是没有能力做这件事的，因为那会的时候 chaos-blade 和 chaos-mesh 都还没有开源。所以从技术角度上来讲这是一个很大的挑战，因为我们面临的是 K8S 场景下的故障注入和监控。这带来的结果是我必须从以前在业务层使用 K8S 往下发展，甚至要去研究 K8S 的源码然后向其中注入不同的故障。
我也曾经调整过业务线，就在 2 个月前我还申请去另外一条我没接触的产品线去趟坑，我们的 UI 自动化已经从 Selenium 到 Selenide，单机到分布式的演进，积累了快 3000 条测试用例，可以说已经是很成熟了，但是在这新条业务线上我开始实践 Cypress 这种使用前端技术栈来做 UI 自动化的框架。 我希望 Cypress 能为我们带来一些新的变化，一些好的变化。
所以其实总结一个字就是变，我们需要经常的变化。产品在变，技术在变，我们自己也要变。变则活，困能死。很多公司每年都会做各种组织架构的调整，也是为了能让变化带来一些新的东西来。如果不变化，面临的可能就是不进则退的记过。
当然变的过程一定是挑战的，是痛苦的，因为你要不停的学新的东西，但我们要知道走技术路线一定是不舒服的，如果你走的太舒服，那么用不了几年，你再去找工作的时候，你可能就不会很舒服了。
-
第 2 种比较不好的思维是：对追新技术的质疑。
不少人在想技术更新的太快，现在去学这些技术有什么用，用不了多久就会有新的技术出现。所以他就不去学习新的技术了，他相信自己把基础学好了，比如把把计算机原理，算法和数据结构学好了就可以了。
我发现真的有不少人这么想，这两年业界比较强调学习能力，认为快速的学习能力才是最重要的，我记得去年还是前年有人提出来测试界的全栈其实就是快速的学习能力。而不少人坚信只要把这些基础学的扎实了，他碰到什么都能立马学会，因为这些是一切的基础。
我不太清楚为什么他们会认为在不去真正的战场上真刀真枪的走一遭就能练出一身的本事。这个所谓的学习能力到底是怎么来的。要知道学习能力从来都不是自己憋出来的，学习能力是你自己一步一步，一个坑一个坑趟出来的经验。
对于大多数人来说，学习能力其实就是一种经验。是一种你在面对一个新技术的时候，你发现你以前用过的一个东西也有这种场景，所以你立刻就能反应出来几种解决方案，然后看这个新技术是用哪个方案解决这个场景的。所以你能立刻明白这个新技术的设计原理，使用方式，而不是冥思苦想。所以你比其他人学的都快，对于大多数人来说，这种经验才是学习能力。而不是一些人盲目迷信的基础知识。
比如大数据领域技术的更新换代也是很快的，最早的时候我们还在用 MapReduce 去撸代码，后面有了一系列很快速的更新换代，当初 Spark 的出现是一个里程碑，但是这两年 Flink 出现后大有一种 Flink 要取代 Spark 的架势，尤其是 Flink 的流式是做了变革性的设计。
但这并不妨碍 Spark 使用者用一种较为轻松的状态去学习 Flink，因为他们都是解决相同的场景的技术，Flink 再怎么创新也是在这个领域里，它要解决的也是这个领域的问题。所以它本身解决问题的方式很多是没有变的。比如 partition 的设计是类似的，shuffle， checkpoint 这些在分布式计算领域都是这样的解法。你知道了 Spark 的这些东西是怎么设计的后就能很快的反应过来 Flink 是怎么设计的以及为什么这么设计的。
Streaming 是大数据领域很经典的场景， 不管是 Spark Streaming 还是 Flink Streaming 去对接比如 Kafka 这种场景的时候，要解决的事也是一样的，你在 Spark 和 Kafka 的场景里要解决精准一次性语义的问题，那你在 Flink 和 Kafka 里也一样要解决的。你也一样是要用相应的包去打开 Kafka Producer 的幂等和事务。所以对于一个 Spark 使用者和非 Spark 使用者，他们谁的学习能力强，不是一目了然么。
当然这个例子可能大家不太熟悉， 我说一个大家熟悉的。
之前我去调研 Cypress 作为新的 UI 自动化框架的时候，我几乎是在一个下午的时间里，就了解了它的一个大概的样子。当天我写了一篇文章，叫《在你使用 Cypress 前你要知道的》。里面是我在使用 Cypress 的一些忧虑和对应的解决方法。尤其是在 Cypress 的分布式执行的弱点以及基于 JS 语言带来的一些局限性。
而我之所以能在一个下午就了解到这些东西，是因为我已经用 Selenide 在 UI 自动化上做到了一个很复杂的程度了并且也对 JS 这门语言也比较熟悉。在去看 Cypress 之前，我心里就有一些问号，比如 Cypress 是怎么处理分布式执行的，Cypress 怎么与中间件，比如数据库，Kafka，hdfs 等打交道来辅助 UI 自动化测试的，又比如 Cypress 这种跟 Pytest 一样很多功能是靠插件来补充的机制，那么各个插件之间是否会有冲突？因为我再用 pytest 的时候就发现了插件之间的互相冲突。
再比如 JS 这种语言由是依靠 eventloop 来处理异步操作的，它的同步和异步代码的处理从来都是 JS 里面的一个比较重要的问题， 而 Cypress 的文档里清清楚楚的写着，Cypress 的 command 都是一种类 promise 的设计，全是异步执行。那么在我们写 case 的时候我们的流程控制会不会出问题。 而后面在我去在项目中实践 Cypress 的时候刚才说的问题确实都遇到了坑。
我在有了之前的这些经验的时候，带着这些问题去翻看 Cypress 的文档，学习的速度就会很快，因为你不需要别人再跟你解释 Cypress 的这些设计是为了什么，很多东西你都能够心领神会。
所以其实我们在学习一门技术的时候，最宝贵的东西其实不是这门技术本身，而是使用这门技术要解决的那个场景，以及解决这个场景使用的方式。所以我建议不管我们去使用哪门技术来解决你的问题，不要只学 API，而要多去学习和思考它背后的一些东西。
而学习能力就是解决问题的经验，是这些经验让你面对新东西的时候，进展的更快。
-
第 3 种比较不好的思维是，眼前工作上用不到的东西我不用去学习。
这也是一种常见的想法。但是首先你的业务是不会停下脚步的，它也会从简单走到复杂。我们是需要为了未来要面临的问题而储备一些技能的，我后面也会讲到，机会是给有准备的人的，我们还是要尽量避免书到用时方恨少的情况的。
再一个有些时候没去了解一些东西的时候，你真不知道它有多有用，也许它对你现在的工作有一个很大的优化的作用，但你不知道。这也我说在做加法的时候强调过的。我一直都建议多去学习研发会用到的技术，它不仅仅在做工具开发的时候提供帮助，很多时候他能让你测试的更好。因为你更懂你的产品架构是怎么样的。
还是拿 Kafka 举个例子， 非常多的公司都会引入 Kafka 作为消息中间件或者作为流式数据的中间件。 如果你认真学习过 Kafka 的话，就会知道它有一个经典的精准一次性语义问题。在生产者 push 消息的时候， 如何保证消息不丢的同时，还不能重复。不丢好解决，参数多设置几次重试，但是消息不重复就很难，因为你有重试机制就会有可能会出现一个消息重复的推送到 broker 上。
你在任何一本 Kafka 的书籍里都能找到一大段篇幅在讲他是如何通过设置幂等性参数和事务性参数来解决这个问题的。这是一段不算简单的配置，它需要 producer，broker 和 consumer 都做一定的参数设置和代码结构的变化。不注意的话挺容易出错的。我们就曾经出现过在 Flink streaming 的场景中，这个流是从 Kafka 到 Kafka。
也就是用 Flink 从一个 Kafka 中读取数据，然后做清洗，处理，再发送到另外一个 Kafka 上。这是一个很常见的流式场景。在这个场景里我们就遇到过由于 Flink 与 Kafka 的精准一次性语义没有设置对而导致的消息重复发送问题， 这个是我们在针对 Flink 和 Kafka 做专门的故障注入的时候发现的。 实际上消息的不丢失，不会重复记录，不会重复消费是一个需要好好设计的测试场景。
而一般如果没有好好的学过 Kafka，或者没有好好研究过消息中间件的话，是很难能想出针对性的测试用例的。就算是我告诉你我这里有故障注入工具，你不了解 Flink 和 Kafka，你都不知道要往哪里注入故障，以及注入什么样的故障。
外面总会有人说甚至连我们自己都说，客观条件上研发其实是最适合测试工作的，因为是他们自己开发系统，没有人比他们更熟悉自己开发的东西了。测试一个东西的前提是一定得对他熟悉。所以如果你想测的更全面，更深入，那你就应该去学习研发领域里那些足够深，足够底层的东西。
如果你一直都在表面那层业务上折腾，那是永远没办法突破自己的瓶颈的。所以不要觉得你现在工作上用不到就不去学，你不去学的话当然就用不上。所以引申一个东西就是：技术是什么，不是说只有开发了什么什么工具和平台才是技术，技术是你解决问题的能力。在刚才我说的场景里，就算一个人他一行代码没写，故障都是拿工具手动注入的，但他知道怎么测试这个场景并执行了测试，我就觉得他是有技术的。
广度是深度的附属品
可能我一直都在表达一种不太一样的声音。基本大多数人都会告诉你要做专家，这句话是没错的，但是这个专是有一个度的，不能专的太窄，你专的越窄，你的路就越窄。
能力越大责任越大，你能力大，就应该去负责更多更高维度的事。这时有人可能会说我们不是要一直专注于深度么，怎么听上去好像你要让我们往广度发展。这里我要表达一个观点就是我一直认为广度是深度的附属品，有深度的人在广度上一般都不会差。
我们说的深度的是深入这个领域里解决这个领域里足够多足够深的问题，而在解决一个又一个的问题的时候，我们就会接触各种各样的技术。我给大家举个我自己的例子。熟悉我的人都知道我很多的精力都在容器化的路上折腾，我们的整个产品架构，测试环境，测试服务等在容器化的路上历经了 4 年的演进。从一开始的单机裸 Docker 运行，到现在的 K8S 集群调度，我们所精进的不仅仅是容器技术本身。容器这个领域会面临很多问题。我来列一下。
-
要解决所有模块的编译-> 镜像制作-> 推送-> 部署-> 测试。
我们需要一条完整的 Pipeline 来完成这项工作，并且由于任务非常多我们需要负载均衡和高可用的解决方案，所以开始使用 Jenkins Pipeline 与 K8S 整合的方式。而这是我第一次学习 Jenkins Pipeline。深度上，我在 K8S 与 Jenkins 集成上学习到了 K8S 各种知识，广度上，在 K8S 与 Jenkins 通信上学习到了数字证书，RBAC 等。并且我学习了 Jenkins 上的各种玩法，尤其是 Pipeline。
-
部署是一件非常复杂的事。
就算已经生成了镜像但是各种配置管理，启动顺序，K8S 模板生成，资源用量等问题都很难让测试人员执行部署操作。 为了解决一键部署的问题我们做了很多事情。 专门开发了部署工具。 并且从深度上我们使用了更多的 K8S 的特性，但是广度上部署脚本使用 Python 以及对应的 K8S client 和 cli 框架。这是我第一次用 Python。
-
大几十个模块部署在 K8S 上，几乎所有测试服务，自动化任务，浏览器集群等都运行在 K8S 上。
我们在各种测试中都需要一套行之有效的监控方案。 所以开始使用基于普罗米修斯的容器监控方案。 深度上我了解了 K8S 监控的整个方案和原理，而且这是第一次了解 K8S operator，也是为我之后编写自己的 K8S operator 做了知识储备。 广度上通过普罗米修斯我不仅做了容器监控， 我们后续上面做了黑盒监控，物理机监控，进程监控，自定义 exporter 等各种实践。 算是各种监控场景几乎被我们玩了个遍。
-
产品运行在 K8S 上， 利用了很多 K8S 的特性，比如负载均衡和高可用的方案。
要验证研发使用的这些方案的效果。需要一个完善的混沌工程来进行测试。 而当时是没有一个开源的能在 K8S 上使用的故障注入工具的。所以我们自己去研究 K8S 和容器的特性，开发了自己的故障注入工具以及全自动化的测试方案。深度上为了编写故障注入工具，我开始学习 K8S 的 client-go， 开始编写自己的 K8S operator，开始研究 K8S 源码。这是开启我 K8S 相关开发的转折点，是我再 K8S 学习上的重要事件。
而广度上，第一次学习 Golang，而在 case 中对将测试数据上报到普罗米修斯的 pushgateway 最后计算出可用性，为了在这过程中监控是否有内存泄漏和 fd 泄露我又自己编写了普罗米修斯的 exporter。这也补充了我们在普罗米修斯监控方案上的最后一个使用场景。
而为了注入故障，我又学习了一些 Linux 相关的东西 ，比如 namespace，iptables，tc 等等。
-
我们还面临一个问题就是上述所有操作都是分散的命令行， Jenkins job 等。
为了给业务线一个良好的使用方式。需要一个 Web 服务来解决，所以 JS，TypeScript，Angular 学起来。
上面是我列出来的一些主要的问题， 在解决这些问题的过程中，可以看出来我的主线还是容器领域的应用，一开始是产品的编译，部署这种常规的 K8S 应用，到后面解决 K8S 周边的类似监控场景，使用 K8S 开源的 client 定制 exporter，定制运维工具。在到后面研究 K8S 源码，自己开发 K8S 的 operator 往容器中注入故障。这一切还是围绕着 K8S 一步一步的深入 K8S 的各类场景中。
而在这一系列过程中，我们为了更好的解决问题而学习应用了 Python，Golang，JS，TypeScript 4 种语言（如果算上其中编写测试用例的语言的话，那就还得算上 Java），涉及前端，后端， CI，监控等各种技能。
所以我说广度是深度的附属品，因为只要在这个领域里解决足够多的问题，你必然就要面对形形色色各种不同的技术。
放弃偏见和强烈的个人偏好
我这里还想表达一个很重的观点就是在技术上尽量的不要带个人的喜好憎恶。带着强烈的个人喜好的工作方式其实是很危险的。
我见过不少人强烈的对技术有非常大的偏好，比如我见过只喜欢 Go 语言的，只喜欢 Python 的，他们非常不喜欢其它的语言，我也见过只喜欢做接口测试强烈排斥 UI 自动化的。或者只喜欢写服务端的强烈排斥写前端的。
这些个人偏好足以让一个未来会很优秀的人被毁掉，因为，**这个时代没有限制他，他的能力也没有限制他，但是他的意识完完全全地限制了他**。他把自己的技术栈封闭起来，自己封闭了自己的视野。偏见和不开放，对一个人的限制是真正有毁灭性的。主动让自己成为一个瞎子和聋子，主动把自己的能力阉割掉，这是一件很令人痛心的事。要知道当你放弃一门语言或者一门测试类型的时候，你放弃的是其对应的一整个的生态。
要记住技术是不分三六九等的，他们只是解决问题的工具。就算很多人觉得这个技术再简单再 low，但是遇到相应的场景的时候，你还就只能用它。同样在技术人眼里，问题也不应该分三六九等的，不管是简单的还是困难的，最终你都是要去解决的。比如你不能觉得 UI 自动化 low，就不去做它，因为做好 UI 自动化是大部分团队要面对的问题，你需要为你的团队负责。如果你的目标是能在技术上成为这个团队的领导者，那我希望大家能放弃各种偏见和优越感。
如果陷入了这种带有偏见状态，那你一样撑不起一个团队。因为你这个人都已经在搞闭关锁国了，你怎么能在技术上去引领一个团队的发展呢。你怎么能解决这个团队遇到的不同的问题呢，就像我刚才拿我自己举的例子。
解决这一系列的问题涉及了多种语言及其技术栈，而这种需要多种技术栈配合解决的问题，才正是我们工作中总会遇到的。可能大家会说你不用一个去做这些事啊，去指派会这些其他技术的人一起工作不就好了。 但是我想说的是哪来的那么多人让你指挥呢，你在做事情的时候，尤其是刚开始做这些事的时候，哪来那么多资源投入进来呢。
做测试开发这个职位，其实大多时候我都是习惯靠自己的。当然说到这里也可能会有人说我刚才举的例子中，感觉我干的好多事情不是 QA 应该做的，应该是 DevOps 或者研发做的。这也是一种限制自己的行为，你把自己限制在自己认为的 QA 的职责边界中，放弃了去接触新的技术和解决更复杂的问题的机会。
而我认为技术的深度往往取决于你平日里解决的问题的复杂程度。只有经历过足够复杂的场景，才能锻炼出足够专业的能力。
机会是留给有准备的人的
可能有些同学会说我遇不到复杂的场景，或者能锻炼技术的工作岗位轮不到我。
这是一个很现实的问题，当你的技能不够好的时候，相应的工作岗位或者机会可能是不会选中你的，这也是为什么我们要在平时就去主动学习的原因。当你的技能不足以胜任你心仪的工作岗位的时候，你就要努力的让自己的水平无限的接近那个岗位的要求。这样机会来的时候你才能抓的住。
就如在我们这里是 QA 先搞了 K8S，推行了测试环境上 K8S 集群的实践，而没有把这个任务交给 DevOps，直到现在我们这的 K8S 集群都是我们自己搭建自己维护，每个项目的一整条持续集成的 Pipeline 包括从环境部署到最后的质量看板的负责人都是 QA。那当初为什么没有交给 devops， 也很简单，因为当时公司规模小根本没成立专门的 DevOps 团队。打从以前就是 QA 跑来主动承担了研发和测试环境的搭建和维护。而这个没有人来做的现状就是机会。
但是在这个机会的背后，在我去找 boss 要接下来 K8S 这个活的背后。是我已经私下学习了 K8S 整整 3 个月并且我自己拿 K8S 重新搭建一套测试环境。所以这个机会来的时候，我才能抓的住，否则的话，一个对 K8S 一点都不了解的人跑去请命要揽下这个任务，那可能就是个笑话了。机会永远是给有准备的人的，不想努力的去准备，还想让机会像天上掉馅饼一下砸中你，那是做梦。
我听过好多人说我没有环境锻炼技术，只要给我个机会我能怎么样怎么样的。或者说只要给我个机会我一定好好努力学习工作等等等等。但是我都一直特别想说一句，凭什么呢。凭什么这个机会就要给一个什么都不会的人呢？我们为什么不招一个有经验的或者起码是自学过懂一点的呢。
所以有些时候，我们真的要改变一下思维方式，不是有了机会才去努力， 而是努力了才能有机会。先尽人事，才能听天命。
永远要留给自己学习的时间
说到学习就要聊一下我们总会说到的问题，就是很多人忙到了没时间学习的程度，他们一直都在加班。 这个问题也很现实。 但是没办法，我们一定要想尽办法留给自己学习的时间，减少一点娱乐活动，少打一点游戏，多留给自己一点时间学习和思考。这也是为什么我每到一个项目，可能第一件事就是开始想怎么做自动化。
一个项目比较好的状态是：
投入自动化项目\-\- 节省人力成本 \-\- 有更多的时间去投入到技术项目来 \-\- 节省更多的人力成本 \-\- 有更多的时间去做别的事情，良性循环。
而比较差的状态是：
自动化投入不够--项目加班--加班太多没时间做自动化--继续加班，恶性循环。
恶性循环也称技术債。你越是把自动化项目往后拖延，你的技术債就越多，因为产品是不会停下来的，它会一直向前走。会有越来越多的功能被开发出来需要被测试。你越是往后拖延，你就越没有时间去做你想做的事情。
所以要从一开始就想尽办法去挤时间去把自动化项目建设起来， 即便是多加加班。
亲自去做
最后我想分享的一个经验就要多去自己感受，如果要开发一个测试工具，或者要在业务线推广一个自动化测试类型。不要只去听业务线上的人说什么，最好要亲自去业务去做跟一轮项目。因为这世上是没有什么感同身受的，我习惯亲自去感受业务线上的痛点，而不是听其他人描述。沟通的再怎么顺畅都会有信息的缺失。
所以自己去测试这个任务，自己去开发这个工具，自己去使用这个工具。才能得到好的结果。
好了今天就讲到这里，希望这些经验对大家有用。
获取更多内容：
https://qrcode.testing-studio.com/f?from=hwyun&url=https://ceshiren.com/t/topic/16586
【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）