带来一份测试大佬的独白，或许一开始我们这些普通人就输了

一、前言

看到行业的前辈都分享一些过往的经历来指导我们这些测试人员，我很尊敬我们的行业前辈，没有他们在前面铺路，如今我们这帮年轻的测试人估计还在碰壁或摸着石头过河，结合前辈们的经验，作为年轻的测试人也有自己的一些职场，技术以及行业交际的一些总结经验

最近有些时间，我也写写我做为一名 90 后测试人的一些经历和看法吧

还是先简单介绍一下自己，本人 15 年本科毕业，毕业后两年在公司的创新团队任测试负责人，不过由于个人发展的原因，就和第一家公司说 88 啦

二、情怀

我对软件测试这个方向早有情怀，早在自己大三的时候，就基本确定之后是做软件测试工程师，那时候上软件工程的课程，对软件质量保证，软件体系以及工程管理那块特别上心

老师讲完白盒测试的方法和黑盒测试的方法后就自己拿自己写过的代码开刀，渐渐发现自己对软件测试产生了兴趣

虽然也由于自己的代码功底可能比较水，加上强迫症喜欢找茬的性格，感觉就是两情相悦，后面自己去学一些性能和自动化测试的入门技术，还记得我的第一个自动化工具是按键精灵

记得是 11 年天猫双 11 来临之际的抢红包，我就是用按键精灵抢了足足 55 块的红包，结果天猫第二年就搞了一只到处跑的猫就没再抢了

那时候就体会到自动化对效率的提高的重要性，所以后面不管实习，还是后面找工作也好，清一色软件测试工程师，后面也就到了走进社会的第一家公司，开始软件测试的人生道路

三、懵懂

软件测试，可能至今为止，很多人还是认为就是找 bug，不过估计这个现象现在应该有所改善了吧

可能是本身对软件测试有所理解，所以工作的态度和方式也有所不同，刚来到公司的时候，其实还真的挺懵懂的

来到一个创新团队，产品是新产品，也意味着业务也是新的，当时我是做 ios 端的手工测试，就是点点点，当时我还对 ios 的操作系统不熟，所以一开始的时候也遇到很多坑

比如把当时唯一一台 ios7 的设备升级了，大家都知道苹果系统升级的坑，环境的多样性没了

我能理解当时的老大他也是想我能多接触自己之前没接触过的地方，一开始我也很刻苦，做移动端的测试，也做 web 端的测试，甚至后面桌面端的测试和后台的测试也做了，基本上把我们产品各个端都玩了一轮

但是总是点点点，效率真的很低，产品和团队都是新的，什么自动化等等都没有，所以当时懵懂的我也意识到我可能可以为团队带来一些改变，百废待兴，也意味着满地都是机会

四、清晰

有了上面的意识，我明白我自己要做什么，机会是有，但没准备不行

好，我自己比较向往做自动化测试，那就学自动化，一开始也是乱学一通，之前用按键精灵也可录制回放，其实也是自动化的一种，但太低级了，我要进步，要学更高级的技术

后面就自己上 testerhome，上推酷等技术网站搜贴自学 selenium，同时由于自己的产品里面有移动端，那时候看大家都是用 appium，那就学最常用的就好

那时我还没学 python，但是学自动化的时候我刻意用 python 来写自动化脚本，这种并行学习的效果非常高效，不仅让我学习到自动化测试的技术，同时也可以学习新的语言

从那时候开始，基本上每天下班回家之后就盯着电脑学习，写脚本，学语言，坚持了一个月之后，把最常用的一些模式都学了，像 page object，关键字驱动，数据驱动等，后面想起总是有人说测试框架，测试工具等

有一天晚上自己就刻意搜了一下测试框架这个词，大家猜一下第一个弹出来的是什么，估计有看过我之前写的帖子的朋友就一下子知道了，就是以关键字驱动、易学易用著称的 RobotFramework（后文简称 RF）

其实我那天晚上还看了 Cucumber 等其他测试框架，那我为什么会选择学 RF，如果我是只为自己学技术的话，我啥都可以学，但是我的出发点就是想为团队带来点改变的，我们当时的测试团队，除了老大之外几乎没有一个人会敲代码，如果要是以后上自动化的时候大家一起玩的话直接敲代码的学习成本就高了

互联网时代要快，有些事是等不起的

RF 对于一个不会敲代码的人来说其实也很容易驾驭，那好，就选它了，后面就专门学习 RF 和 python 相关的技术，包括 jenkins

每天和我老大保持沟通，让他知道我的学习情况，同时我也经常盯着我老大做事，看到他在某些方面需要支持，自己当时能力所及的，我会第一个跳出来说让我来或者是我帮忙，像有一次老大开始尝试做性能测试，他写了一个 loadrunner 的脚本，跑了我们项目的第一次性能测试

由于自己的好奇心，我就向我老大请求性能测试就让我做，虽然以前接触过 loadrunner，但是也结合业务结合场景来做性能测试的话还真没接触过，我就帮请教我老大怎么做性能测试，自己又在网上搜贴看看一些具体的场景设计和 loadrunner 工具的具体使用

从那次之后，我们产品的性能测试就我包办了，看起来事情多了，但这是很重要的经验，经验也是要看机会拿的，错过了，或许其他成员会抢去，那我就失去了做性能测试的机会，能力也就不能得到提高，所以渐渐地也得到老大的信任和团队部分成员的认可，自己的能力和对工作的动力也渐渐提高，就这种状态持续到 16 年初

五、进击

16 年过完年回来，我们的产品已经开始趋于稳定，是时候做自动化测试了，由于有前面的积累和沟通，我们老大向我们总监推荐了我包办我们产品的自动化测试，包括移动端，web 端，桌面端以及后台

当时我收到这个任务的时候也是比较慌的，毕竟之前完全没有实战经验，这次也没人带，而且我还要带上 2个测试的同事一起做这个项目，当时自己的工作经验还不满一年，真的是慌到不行

但后面冷静下来之后思考，这可是个活生生的机会啊，自己之前积累起来的知识和技术，不就是等现在这个机会吗，为什么不试试呢，成功了，那团队真的让我带来改变了，失败，对我来说也是很重要的经验，不做白不做，狠下心来做

后来我就把以前的一些想法一步步着手实现，将 robotframework+jenkins+ 支撑库的方案投入到我们项目做自动化测试，也就是有了我在 testerhome 的第一篇帖子RF+Jenkins 测试框架实践

在将方案投入项目之前，我还专门给测试团队的成员开了一次针对框架的也是我在公司的第一次培训，为何会说起培训，可能也是培训，让我意识到培训的分享者会比接受者收获的更多

我就是从第一次培训当中理解到什么叫做解决方案，也总结出后面我在测试团队经常说的一句：不要为了用工具而学工具，要为了实现一套解决方案来解决问题而学工具

是的，我为什么要学 RF，它能快点应用到项目，同时也解决了测试团队上手的问题，为什么要学 jenkins，就是为了能把一套持续集成的流程串通起来，支撑产品的快速迭代，我就是为了解决问题来学工具的

也就是从那次开始，我的技术和职场道路开始走上进击的道路，后面秉持着为了解决问题来学工具的心，也做了后面的一些技术方案来解决产品项目中测试的一些需求和问题

后面也陆陆续续地帮团队解决一些沟通和协调的问题，像带实习生，前后端沟通，力所能及，即可为之，自己的主动性和执行力也被锻炼起来，反正什么都试试，年轻人，多学一些没亏

六、升华

天道酬勤，机会都是留给有准备的人的。

16 年 7月份，我老大提离职了，产品总监第一时间就是让我接手，慌张的心又开始跳动，我才工作参加一年，就要做测试老大呢？

我能不能做到，团队中还有比我更有经验的小伙伴，为何是我？或许我真的是有备而来的，还是那句，有机会干嘛不试，跳动的心沉静下来，好，我来，就是那时刻，我开始担任团队的测试老大

可以说我是个小白老大，之前一点管理经验都没有，不过以前在大学当学生干部的时候或多或少还是有一些作用的

做 leader 的第一件事，调整团队的测试工作方式，实现所谓的端到端测试（这是我理解的端到端，可能和其他朋友不一样）

就是一个人负责一个端的所有方面的测试工作，比如自动化，性能，专项，甚至是测试工具的开发

果然这效果还是每明显的，一个月过去，产品端的质量真的有所提高，同时团队成员针对端的能力也提高起来，这是因为以前大家做的事情都太乱了，还不如先专注做好一个方向，再做其他的，所以就想到了用端到端的方式

在这期间，我们把 web 端，ios 端和 android端的自动化测试推了起来，每一端基本都是独立一人完成的，就这过程，团队的成员熟悉了怎么用 RF 的框架

后面我还强调大家要学原理，还分析过 RF的执行原理和分层结构，这样大家不仅能力提升了，产品的自动化测试也得到推进，巩固了测试的环节

显然，持续一段时间，产品的质量能得到提升，尤其是 web 端，以前季度 bug 数会上 100 多的，后面就 50多，而且以前每个版本测试周期为一周，后面 2 到 3 天就行了，这都是效率的提高，成员得到升华，质量得到保证，这是测试工作的最优状态

第二件事，其实以前做的都只能叫做产品测试

还没到达产品质量保证的高度，项目发展到一定程度，有些事情还是要管起来的，一开始是什么情况，测试团队是在研发提包给我们的时候，我们才知道要测什么，这是不对的，版本管理无任何秩序，什么时候上线什么版都不清楚，比如上线和发版的定义都区分不了

于是，我联合测试团队的成员和产品经理，研发等开始制定产品的质量流程，像需求评审、用例评审流程，这看起来有点不像互联网敏捷团队的模式，但我们是以一种轻便地方式来实现，产品主大局，产品需求一般是阐述大概要做什么，但很容易会漏掉细节，谁补

测试人员，不是总说测试比产品经理更了解业务吗，所以用例评审的时候我们就可以体现细节的问题，用例编写和研发实现的周期调整为同期

测试左移，用例编写完成后用例评审，我们也不是说一条条用例地看，对于敏捷，快速迭代，这不是个好办法，那用什么，xmind 是个好工具，产品经理能用来列需求，测试也就能用来列测试关注点，测试关注点覆盖产品需求路径，同时提出产品需求未描述清楚的地方，并且通过易用性，功能性，可靠性等一些方法也提出关注的细节，这样既能补全需求，也能前提告之研发哪里有坑，同时也巩固测试的一个关注点和范围，一举多得

可能这说成用例评审有点怪，叫测试关注点评审更好，随便，为解决问题而设计实行适当的方案或流程就好，与此同时，那为产品作版本灰度上线方案，设计灰度的范围以及要关注的功能

同时版本上线之后，做好和客服的对接，做好线上问题收集和整理，还有很多，像版本号管理，提测规范，上线流程等，虽然作为测试负责人，但在产品质量保证的范围下，事无巨细，从需求到研发到测试到上线运营，每一块都需要保证

第三件事，缺陷管理

每个测试人员提 bug 的方法方式都不一样，甚至 bug描述方式都不一致，研发经常和我吐槽，提 bug 连个图都没有，测试环境没有，甚至没有测试账号，然后我们研发环境又没重现，那要怎么修 bug

还有的是，客户经常反馈的 bug 范围和我们测试发现 bug 的范围相差深远

说明两点：1、测试重点没有贴近客户，我们所认为的重点模块不是客户的常用模块

2、我们提 bug 的质量没有保证，加大了沟通成本，这个也是要解决的问题

怎么做，我们先把产品的各个端的功能模块分类好，作为 bug 的功能分类标签，明确模块优先级，制定 bug 优先级权重，同时标明好无效 bug 和线上 bug作为测试人员的把控质量的一个评价指标

举个例子：以前我们总是觉得我们的沟通模块很重要，一般一个版本可以在沟通模块测出 25 个 bug，然后协同模块才 5 个 bug，结果上线之后客户反馈的问题或建议全是协同模块，沟通模块没几个，就是证明，客户目前多数是用协同模块，但我们却把工作量放在沟通模块，那就不太对了，所以结合线上 bug的数据作为一个测试重点的一个标准

同时还有就是我们平时在当前版本结束之后，对功能模块所对应的 bug数进行分析统计，做好缺陷趋势分析和风险预估，那下一个版本的测试范围和重点就出来的，这个是提高效率的方法，同时我们统一了 bug的模板，每个人的格式都是一致的，研发看起来舒服，bug自然也修得畅快，我们回归的时候也舒服，一举多得

还有很多很多，我作为测试负责人之后，的确是做到了为团队带来了一些改变，这也是我本来努力的方向，后面在团队里面坚持每月至少一分享的习惯

厉害的时候，一个星期 4次，但是我们都不是瞎培训瞎学，脱离业务的技术方案都是炫技，华而不实，我们培训都是为了解决当前工作上遇到的问题的，都是学最能解决问题的技术方案，而且我一直很崇尚圆桌型的培训，虽然有主讲人，但每位小伙伴在培训之前都或多或少去了解培训主题涉及的内容，之后培训的时候大家一起提出不同的看法和见解，经过自己思考的接受学习也是有效，大家共同进步

这有什么效果呢，说点实在的，前文提到本来测试团队几乎没人会敲代码，后面 16 年底 17 年初，都已经会独立写一个测试框架和 app 专项测试工具了，而且这过程中还不断引入像 anyproxy、docker，locust 等一些技术方案到团队

也说起分享培训，我自己也是活跃在各大测试技术群里面，以前也是到处问人，到现在到处帮助别人解决问题，还是回到分享者才是培训的最大收益者，自己不懂的，还会刻意去搜贴结合自己的经验得出解决办法，空余的时间也会去参加一些测试沙龙，和其他同行保持交流，了解行业的发展动态，自然而然，接触的知识和人也多了，渐渐地学会了洞悉技术发展方向，能够迅速地了解和学习适应时代的技术，这也是作为一个测试人员的嗅觉，懂得变，学会如何进步

七、沉淀

质量保证分为 3 大块:产品质量保证，交付质量保证，运营质量保证

只有这三大块做好，产品的价值实现才会得以保证，但是有多少人是理解这三块是要做什么的，所以我就说有部分测试人员对自己的要求不高，测试的价值是可以再提升的，看看上面的三块，就知道测试人员的重要性，但又有多少人做到

我在年初的时候面试了很多测试人员，其中还面试了几位工作超过 10 年的前辈，这里不是抹黑，的确有一个现象
我面试那位前辈，工作 10 年，之前也是测试负责人，自己是偏向自动化测试的

好，我问他怎么做移动端的自动化测试,他也是知道用 appium+ 语言这个方式去做，我问他是怎么设计一个自动化测试方案去解决自动化的问题的，就一直和我说工具，我问他有用什么设计模式去提高代码的可维护性和执行效率的时候，不懂

好，我问 appium是怎么和手机通讯来执行自动化测试的，也不懂，其实都没问题，最后让我直接否决掉的原因是，我问他是怎么管理测试环境的，他说测试环境是研发和运维搭的，测试不懂得搭，算了，我聊不下去了

我问原理，是因为作为测试负责人，也是一个带人的角色，你自己都不了解清楚的东西，在团队里面实现，团队的成员也不会了解清楚的，估计解决问题的程度也不高，感觉就是在项目里面用用而已，而且连最基本的测试环境都给研发或运维做，那测试做什么，怪不得别人说测试低端的

东西不仅要学会，还要学精，上面的情况违背了力所能及即可为的原则，而且都不仅是能及，是基本要求。

第二记得应该是工作 4、5年的，问测试策略和测试计划的区别和作用，和我说没做过测试计划和测试策略

还有个更离谱的，简历里面写着自己会性能测试场景设计，面试的时候给个案例给他做，写不出来，什么是业务场景设计，什么是数值预估和瓶颈分析都不太清楚，我直接问他做过多大的并发：50 人，我马上跪了

几乎没有人拥有我刚才所说的嗅觉，举个最简单，当初那么火的 docker，我面试的所有应聘者居然没人知道是什么来的，就那么一段时间，我患上了面试恐惧症，简称 “面瘫”

怎么做测试都不太清楚，不用谈产品质量保证，更不用说三大质量保证，别人总说测试入门低，在团队地位不高，我一开始也不太信

因为我们测试组在团队里面还是很有发声权的，因为我们抓紧质量，那些还是在点点点的，总认为自己找过多少 bug 很牛，学过多少工具很牛，到头来就导致认为测试很低端

话也说回来，我在面别人的过程中通过交流也学了很多知识和经验，同时我有个面试习惯，我会专门挑应聘者的问题来给他们提供一些建议和看法，就算后面面试失败了，我起码也不会让你白来一趟

更狠的是，我举办过一场特色培训，我让我们测试团队的成员做面试官来面试我，面到我说不出话为止，面试别人其实对自己来说也是个总结的过程，你在问别人之前起码你要了解清楚你要问的东西的原理，那才会踏实，那就是一个提高的好办法

所以我就让我们团队的小伙伴面我了，果然有效，她们当时还准备得挺充足的，我有几个时刻就差点说不话来，哈哈，我当时也感觉到大家已经明显进步很多了

时代变了，仅仅是找 bug 牛已经不够了，所以后面每天一句：不要为了用工具学工具，要为了解决问题而学

还有要做质量保证，不仅仅是测试，bug是要预防，不是找，这让我更加巩固上文所提到的一些看法，也是在这段时间，我也不断地再深化提升自己，把之前去年做过的技术方案通过理解原理和结合业务，优化了几个技术方案并在团队里面使用

能解决问题，为团队带来好的改变，自然也会收到回报，除了能力的提升，地位的提升也会有的，今年 3 月我也被提拔为资深工程师级别，这些都是要靠积累的，要做上面的事情，我基本上每天只睡 6 小时，每天都在想尽一切办法怎么才能解决问题，提升质量，提高效率。天道酬勤

八、最后说几句

人往高处走，自身的发展也很重要，也由于个人发展和家庭的原因，很快和当初的公司说 88 了

来公司两年，让我从一个测试新人蜕变，很感谢现在的团队和公司给我那么多机会和条件，让我得以发展起来

同时也通过分享我过往的经历，希望对测试新人们有一些小帮助，同时也欢迎前辈们继续给我还有我们这一辈测试新人指导，我们一起创造测试界的光明和未来

一个成功的团队少不了这三种角色

第一:把控方向的人，一般是产品负责人，团队的生死几乎就看他了

第二:团队第一生产力，一般就是架构师，技术最牛的那位，有方向，有策略，还要看能不能实现

第三:据说外国对他有个称号叫 master，他懂技术，懂业务，懂流程，根本就是一名全栈人员，他了解团队的优势和劣势，从而能在制定产品策略，技术方案以及生产过程提出建议和改进方法加以保证，给团队发展保驾护航，他是团队的消防员和安保员，测试人员的最终发展方向应该就是这个团队第三人了

个人看法，大家一起加油，谢谢

最后： 可以在公众号：伤心的辣条 ！ 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

不要孤军奋战，最好是能抱团取暖，相互成就一起成长，群众效应的效果是非常强大的，大家一起学习，一起打卡，会更有学习动力，也更能坚持下去。你可以加入我们的测试技术交流扣扣群：914172719（里面有各种软件测试资源和技术讨论）

喜欢软件测试的小伙伴们，如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！

---

好文推荐

转行面试，跳槽面试，软件测试人员都必须知道的这几种面试技巧！

面试经：一线城市搬砖！又面软件测试岗，5000就知足了…

面试官：工作三年，还来面初级测试？恐怕你的软件测试工程师的头衔要加双引号…

什么样的人适合从事软件测试工作？

那个准点下班的人，比我先升职了…

测试岗反复跳槽，跳着跳着就跳没了…