测试人员的日常 （我太难了吧，我的测试工作一天到头都是加班。）

我太难了吧，我的测试工作一天到头都是加班。

我太难了！

为什么你们都是6点下班的？

为什么你们的工作可以那么轻松？

为什么你们还有午休？

为什么你们能赶上六点的下班公交车？

为什么你们下班之后还能逛街，去吃饭，去玩？

为什么你们的工作经历我一个标点符号都不信啊？

测试工作的日常

9：00挣扎着起床，颈椎病和肩周炎越来越严重了，早上都是疼醒的。女友已经上班走了，起床洗漱，做公交倒地铁，再倒公交倒公司。

10:00把在地铁口买的煎饼吃完，抠会儿手机，今天的任务给组员安排一下。然后组长开“立会”，汇报昨天工作进度、今日工作计划，部门之间工作协调。

11:00查看系统，验收bug，催开发，和产品对接，应聘面试者。

12:00吃饭，侃大山，逛逛论坛，睡半个小时。13:30缓一缓，没睡醒，然后重复上午的工作，…

18:00查看进度，然后追踪一下，最后看加班多久（不加班是不可能的，领导还没走，意思也得意思一下）

情况一：18:30没啥事，意思一下回家，每个月能有那么几次可以回来这么早吧

19:30吃饭，和女友一起逛B站，追剧

22:00女友已经睡下了，自己开始学习，自动化、测开…

00:00钻进被窝搂着女友睡觉

情况二：19:00下午的活没干完，吃饭完干一会儿

21:00活干完了，磨蹭到22:00打车回去可以报销

22:00打车回家，学习一会，洗漱搂着女友睡觉

情况三：项目上线，直接到第二天早上8:30保洁阿姨已经打扫完卫生了，送水的也来过了，开发已经在桌子和沙发上睡了三四个小时了，测试的全部都是红着眼，白着脸，对着手机不停的点点点。最后再回归测试一下，项目上线，大家又活过来了。

9：00下班，碰到了早上来上班的同事…今夜，我们都是有文化的人！

工作强度大么？

绝对不小，至少平均强度肯定不小，这点不管是大城市还是小城市，对于项目的迭代我倒是觉得没有太大差距；只是大公司和小公司可能不太一样罢了，大公司流程相对规范一些，小公司流程上可能没那么完善；那么最忙的时候是什么呢？一般情况就是发版（在排期正常的情况下），再细一点，比如电商公司的大促日，各种活动日，紧急发版；以我的经验，那时候做客户端的迭代，发版前几天是最忙的时候，要做兼容测试，改bug，要回归等等，有时候还要做性能，时间安排的非常重要的。而在项目初期，其实也经常在写自动化或者是写用例，所以你很难说会有空闲的时候。不过话说回来，我还是觉得这和大环境，或者说大的文化相关；外企其实就是循规蹈矩，所以也是分具体情况来看的。所以要去BAT这样的公司，一定要先做好心理准备。

加班严重么？

这个上面已经有案例了，其实做服务端的测试还稍微好一些，因为我待过的组，如果是做服务端的测试，发版的限制没客户端那么强；但纯客户端的限制就不太一样了。说白了，加班多不多一个是企业文化，KPI的要求；还有一个就是需求。需求多了，时间没变，你必然加班，真不想加班，真的要好好了解清楚想去的地方，不要一股子迷糊劲儿就进去了，然后没做几天就想着走。需不需要用到自己的电脑（笔记本）？分情况，我第一家公司从来用的都是公司电脑，多数情况也是公司电脑；除非就是像远程办公，VPN的紧急支持这样的情况。我曾经也有过，走在路上，突然要紧急拉数据，直接连了热点，VPN开始大马路干活，一点都不夸张。

所以具体还是看需求，看公司要求吧，不过总体来说，有个笔记本确实会稍微方便一点点，开会啊，上线啊，都还是有点用处的。

沟通很重要

沟通的日常是最多的，和产品运营了解需求，发现bug之后与开发沟通；和联调方讲解需求，和架构师学习各种技术等等，离不开沟通。而沟通之后，就是沉浸在自己的世界中了，写用例，验证功能和bug，研究框架。其实就是大循环里面的小循环，大循环就是大的需求版本迭代，小循环就是我上面讲的这几点，多数测试都离不开这几点，所以真说不枯燥，我觉得时间久了，会有点厌倦的，所以测试的方向挺重要的，做app，做性能，做自动化工具还是怎么样，一定要好好想清楚。

那么测试工程师每天都在做什么呢？主要的工作分为4大部分

业务测试、专项测试、效能提升和质量监控第一，业务测试有的同学可能还不清楚什么是业务，业务说白了，就是你们公司或项目组为了达成商业目标而所做的事。

业务是由销售、运营、产品、设计、开发和测试共同完成的。比方说你们的项目组主要负责搜索功能，那么，你在里面的角色就是这个搜索功能的迭代测试。

那么，如何进行业务测试呢？首先，需要参加需求评审和技术评审，熟悉和明确产品需求。其次，针对需求文档和技术文档进行测试用例的编写，编写完测试用例之后，还需要进行测试用例评审。接下来，研发工程师会进行产品的开发，等开发完毕并开发自测通过后，会把代码提测到你这边。此时，你要做的就是把代码部署到测试环境中，并开始进行冒烟测试。

冒烟测试就是把产品功能的主流程走一遍，看是不是能满足提测标准。假如没有满足提测标准，有权把提测打回，让开发自测充分后再提交测试。假如已经满足提测标准，就可以开始按照你编写的测试用例，逐项进行测试。这个阶段就是测试的重头戏，主旋律一般就是发现bug，提交bug，开发解决bug之后，测试再验证bug是否修复。

测试完毕之后，需要让产品进行产品验收和体验。验收通过后，方可进行上线。上线完毕之后，还需要在生产环境下，进行回归测试，等回归测试没问题之后，才宣告功能正式交付。接下来，又是进行下一个功能迭代的测试。

专项测试专项测试，顾名思义，主要是诸如：数据测试、性能测试、自动化测试等特殊的测试。
主要是对业务测试的一个补充。没有绝对完美无缺的系统，单靠业务测试，是无法保证产品或代码质量得到更多提升的。比方说，自动化测试可以模拟重复1000次点击操作，但是这个要是让手工去做，不得把测试工程师逼疯喽。专项测试可以发现一些手工业务测试发现不到的bug。但是专项测试不可能完全替代业务测试。

业务测试具有主观能动性，可以站在用户的角度去体验一个功能的好坏以及产品是否美观。但是专项测试并不能做到这点。

效能提升现在的互联网公司，产品迭代周期很短，一个功能可能1-2天之内就得上线。假如说企业不追求效率的提升的话，就无法快速占据市场。我们测试工作也一样，更应该注重效能提升。效能提升主要可以从CI/CD、Bug管理、测试环境维护、流程管理与优化去考虑。有能力的测试团队，可以考虑开发出适合自己团队的测试平台，集结所有优秀的测试工具，方便测试工程师提升测试效率。
近几年，DevOps也是火了一阵，DevOps就是开发运维一体化，可以把整个产品的生产过程，形成一套流水线的规范，这样也可以很大程度上提升产品的交付效率。

质量监控不论如何，质量都是测试的脸面，为了保证质量，我们不能只局限于在测试阶段去发现bug，我们应该也要对产品交付之后的进行质量监控。比方说：移动端app，正式发版之前，都会有灰度测试阶段，在这个阶段，已经有部分用户可以率先体验到我们的新功能，我们需要进行app的crash监控。所谓crash就是app的崩溃，crash会对用户体验造成相当大影响，监控crash可以有效的把crash扼杀在正式发版之前。其他的监控还有服务器状态监控、用户反馈监控、埋点数据监控等等。

最后|资源分享

给大家看一个宝典吧，不管是面试还是日常的知识积累，是我几年下来的一点点知识储备，下面这些是我的收集和整理的资料，对于开始学习【软件测试】或是技能进阶的朋友来说，绝对是最全面的教程仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你

关注【程序媛木子】微信公众号测试资源将免费获取，技术交流群（644956177）群里有技术大佬的各种技术交流和经验分享。