毕业两年做到测试经理的经历总结
一、前言 近看到行业的前辈都分享一些过往的经历来指导我们这些测试人员，我很尊敬我们的行业前辈，没有他们在前面铺路，如今我们这帮年轻的测试人估计还在碰壁或摸着石头过河，结合前辈们的经验，作为年轻的测试人也有自己的一些职场，技术以及行业交际的一些总结经验，有些时间，我也写写我做为一名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自然也修得畅快，我们回归的时候也舒服，一举多得
