90后聊聊工作和职业规划

此篇随笔，非技术性内容，都是自己关于工作、学习以及职业规划里的一些思考和迷茫的地方吧，一直计划着写出来，但总被一些琐事烦扰，凡人都有的困扰啊。。。

about工作

作为一个软件测试工程师，好歹也算IT圈子的一员，虽然现在互联网行业已经趋于大众，接地气了（圈外人还是觉得很神秘的样子）；工作的内容，无非就是需求、用例、缺陷、

文档&报告、上线这几点了，详细说的话，大概可以分为以下这些内容：

需求：需求评审、分析测试点等；

用例：设计测试用例、用例评审、执行、补充更新等；

缺陷：发现BUG、定位BUG、提交BUG、追踪及协助开发解决BUG、验证BUG、通过关闭等；

文档&报告：测试计划、测试方案、缺陷报告、版本迭代报告、测试报告、上线发布报告等； 

上线：即我们俗称的发布、发生产等，由内部试用到用户使用的一个动作，过程；

以上几点，都是互相影响互相依存的，具体原因下面说。。。

日常工作中，接触的同事，也就是产品（业务）、程序员（开发）、运维、DBA（数据库管理员）、项目经理等人；当然，一个项目从无到有，从立项到上线，其中牵扯到各种扯皮、推诿、困扰、沟通等等问题（其中滋味，经历过就觉得像是打了一场艰难的战斗似的），下面就每个点详细说说我个人的一些感悟。。。

1、需求

从一些测试交流群以及同行那里获取到很多有趣的信息，比如需求描述不清晰，需求变更快，没有需求没有原型图等等很多看起来很不可思议的事情，甚至没有需求评审等环节，当然，这些这样那样的问题存在，跟公司文化、部门开发模式、领导者的想法、同事个人因素等等都有关系；但作为一个测试，或者说作为一个尽职的员工，抱着解决问题的心态，总是没错的，抱怨解决不了问题，积极沟通，熟悉了解需求，才能更好的去设计用例，分析可能存在的问题点，“在其位，谋其职”，不断提升自己的经验，沟通交流的方式才是正确的方式。

2、用例

说到测试用例，可以说是最基本也是最难得一点，如何灵活运用用例设计方法，分析功能点，尽量做到覆盖，描述简洁清晰直观，很重要，但用例的功能点，模块分支，又是来源于需求，说到这里，问题来了，很多时候，我们没有足够的时间去设计、编写测试用例，只能凭借个人经验和误打误撞去进行测试了。原因呢，很多，需求变更导致的开发时间延期，上线时间不变，临时情况，公司流程，管理，以及对测试的重视程度，都有影响，这往往也是测试人员的痛点；因为用例设计时间不够，覆盖率不高，导致的生产问题，但测试，往往是第一个背黑锅的，好吧，说到这里，这是个槽点，每每听到同行说起又出问题了，又损失多少，是谁的责任，让人无语（此刻，我建的IT群某个家伙说他们生产又出问题了听着很纠结）；解决这个问题，个人感觉是个任重道远的事情，国内大环境，除了少部分大型互联网公司，其他中小型企业，对测试，重视度还有待提高，当然，测试人员技能，经验，良莠不齐，也是一个问题，说到这里，体现出一个东西的重要性了，那就是流程（当然，我本人虽然一直在努力和其他测试同事推进公司IT部门的测试流程规范，但并不是流程的崇拜迷信者，不过无规矩不成方圆，流程，就相当于一个大体的方向）。所以，工作中总有各种问题，保持心态，解决问题，才是我们应该一直拥有的态度。

3、缺陷（BUG）

说到BUG，这是个很头疼但不得不面对的问题，没有完美的产品，即使这个软件应用经过了多轮仔细全面的测试，软件测试岗位，本身就是为了去主动地发现，暴露BUG，怎样

发现BUG，这个一方面取决于测试人员的个人经验，用例的覆盖程度，流程上的完整，各方面的规范，个人技术能力（定位BUG，以及BUG的等级，优先级，是否是BUG或者是否需要优化）等等方面；关于BUG具体的定义以及概念性质的东西，这里就不一一赘述了，有兴趣的可以去看看我之前的博客，在基础知识分类里面。

4、文档&报告

文档的内容，包含很多，需求文档，测试计划，测试方案，测试用例（一种输出形式，也可以用BUG管理工具或其他方式代替），接口文档，表结构设计文档，测试报告，上线报告，用户手册等，听起来很多，但实际上，这些东西，都是很有必要的，因为它规范了流程，清楚明确的定义了职责，内容，结果，当然，具体的编写模板什么，百度一下，你就知道。

说起百度，想起一个梗，百分之80的问题百度都能解决，百度解决不了，FQ，如果还不行，自己想办法吧（写到这里，莫名想笑，想起很多的伸手党，鄙视ing）；当然，文档除了指导工作进行，还有一层含义，给老板，领导看。。。这个问题，源来已久，貌似是人类的共性，吐槽三分钟。。。

5、上线（发生产）

这个呢，可以说是检验我们的开发测试结果的一个标准，一切以使用结果来说明，用户的态度，决定了我们的能力和薪资；当然，我个人觉得，由测试来进行打包发布，还是比较靠谱一点，当然，是由技术经验比较丰富的人来执行。不过，为了预防我们遗漏的缺陷，可以选择分批发布，有一个名词，灰度发布（这个名词，还是前不久听IT群里Nero大佬说的，当时觉得不明觉厉，百度后，发现我们正在或者未来都将采取这种形式来发布生产，这是一种预防机制和风险预备方案）。

灰度发布：灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

说了很多，总结出来，无非就几点：流程、管理、环境、技术经验、沟通、灵活运用，以及解决问题的态度和出发点；解决问题的态度，很重要！！！

最后：下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取