小吴:
未来依旧充满挑战。
计算机专业出身的我,在17年秋招的时候,需要做一个选择。这是离开校园对人生做出的第一个选择,“是做开发?”“是做产品?”“是做其他的?”。当时这个选择困扰了我很久,我是一个期望接触更多业务形态,扩展自己的视野和见解的人。
偶然,我发现了这个测试/测试开发岗位,还记得当时看着各个测试开发的经验贴,想到本科做课程设计,一看到同学的输出bug就能定位到问题原因的那个自己,觉得自己有独特的天赋,而且我向往那个测试需要有着独特的“大局观”。
这,不就是自己期待的岗位吗?
决定了自己的方向,放弃了之前所有投递的开发岗位,开启了我测试开发的求职之路。
17年9月,搜狗选择了我,17年10月,我选择了搜狗。
18年1月,毕业后1周,我入职了。
入职后,我的leader考虑到我的兴趣(瞎猜测),结合我自己对岗位没有明确的认识,带领我的“小师傅”给我了一个自动化的项目,Python+unittest+Jenkins+SVN,做了一个对线上接口的自动化监控。每天报告里面看到自己补充的200+个接口的运行结果,工作的成就感、热情也从此而来。这是我的自动化入门。
我入职的这天,还有一个巧合:我们项目正式发布1.0版本,是项目的线上诞生日。一个只在校园中做过小系统的测试开发新手,对整个项目的把控是迷茫的,我不知道从何入手,不知道我能做什么。
这时候leader和“小师傅”安排我从客户端入手,跟着组内的同学开始做客户端需求。这时候我遇到了我的第一个大挑战: “这里有bug,但是原因是什么呢?”这个问题应该是所有测试同学入门都会面临的问题:如何定位bug/问题。
组内的同学一步步帮助了我,我学会了如何定位问题出现在客户端,还是前端,还是服务端。随着逐步的业务理解深入、测试深入,我还学会了如何定位问题所在的代码行,甚至有几次因为开发同学没时间修改,自己直接上手改代码。
之后,我又遇到了陆陆续续的小问题,设计测试用例的熟练度不足,功能-子功能-检查点-影响因素的结构始终不会归纳,写用例的时间预估永远不足;
测试过程中,用例执行逐条执行,不会合并执行,浪费时间;
组内、项目工作不会协调,工时不够用;
无法频繁切换任务……无论如何,工作时间都不够自己完成任务,就咨询组内同学、自己学习GTD(Getting Things Done),逐步学会了合理安排任务、动脑执行任务,管理自己的工作时间。
我工作半年后遇到了一个大挑战。因为各种原因,我需要几乎是独立完成一个新产品线1.0的前端、后端测试。印象十分深刻,这个版本的测试持续了近3个月。项目过程中,我遇到了测试数据构造、删除时执行SQL脚本效率低下的问题,依赖我最擅长的桌面开发能力。
3天的时间用Java+Swing“撸出了”我们测试小组的第一个工具,这个工具至今都是频繁使用,给组内同学的测试效率带来极大提升。这一次经历,让我学会了使用技术手段改进/提升测试保证质量的效率。
项目测试完毕后,这还只是一个阶段。它还要依托公司的另一个业务跟我们配合,跨团队协作的项目,中间结点的问题频繁发生。因为节点路径又多又长,经常阻塞最下游的我们进行测试。当时这个问题,我努力定位到了最可能发生问题的两个节点,同步给项目组,同步给整个链路的各个合作团队。所有团队的人在一起,此时已经有了问题定位的大概节点,便快速解决了问题。
之后的我在“开发”层面遇到了新的问题,团队19年年度的目标定在测试质量左移,其中一部分依托于我需要做的主流程自动化。
19年,我对测试开发这个岗位有了更深刻的认识:测试开发的职责是测试,目标是质量,技术是手段。这一年自己写了几十个脚本,根据项目&组内中暴露的问题改进了多个流程,定位了近百个各类问题并推进解决。这一年,获得了项目组各团队的专业度认可、也获得了的荣誉。
20年,开头就注定了这是有挑战的一年。“小师傅”从我们项目离开了,团队交到了我的手里。
深刻记得产品leader、开发leader、我的leader在我刚接手小组说的很多话、给我的指导;“质量、效率、深入”这三个词会铭刻在我未来测试开发职业的道路上。从此,多了一份对组内成员的责任,多了一份对项目整体测试质量的责任,多了一份协调推进的责任,多了一些测试开发体系化的想法和概念。
那时候,我感觉好像体会到了测试/测试开发的“大局观”。
| 下面是我整理的2022年最全的软件测试工程师学习知识架构体系图 |








事业总有大起大落,人总会遇到挫折,只要你不怕跌倒你一定会开创出自己的一片天地来,记得还有我在你身边鼓励你!祝你心想事成!
生活是条难走的路,高低不平,坎坎坷坷,有喜悦也有忧伤,交替着向前演绎。人就是在这样的环境中走向成熟,但不能逆来顺受,磨掉生活的梭角,要勇于奋进,知难而上,面对生活,面对人生之爱。
机会,需要我们去寻找。让我们鼓起勇气,运用智慧,把握我们生命的每一分钟,创造出一个更加精彩的人生。