此篇随笔，非技术性内容，都是自己关于工作、学习以及职业规划里的一些思考和迷茫的地方吧，一直计划着写出来，但总被一些琐事烦扰，凡人都有的困扰啊。。。
about工作
作为一个软件测试工程师，好歹也算IT圈子的一员，虽然现在互联网行业已经趋于大众，接地气了（圈外人还是觉得很神秘的样子）；工作的内容，无非就是需求、用例、缺陷、
文档&报告、上线这几点了，详细说的话，大概可以分为以下这些内容：
需求：需求评审、分析测试点等；
用例：设计测试用例、用例评审、执行、补充更新等；
缺陷：发现BUG、定位BUG、提交BUG、追踪及协助开发解决BUG、验证BUG、通过关闭等；
文档&报告：测试计划、测试方案、缺陷报告、版本迭代报告、测试报告、上线发布报告等；
上线：即我们俗称的发布、发生产等，由内部试用到用户使用的一个动作，过程；
以上几点，都是互相影响互相依存的，具体原因下面说。。。
日常工作中，接触的同事，也就是产品（业务）、程序员（开发）、运维、DBA（数据库管理员）、项目经理等人；当然，一个项目从无到有，从立项到上线，其中牵扯到各种扯皮、
推诿、困扰、沟通等等问题（其中滋味，经历过就觉得像是打了一场艰难的战斗似的），下面就每个点详细说说我个人的一些感悟。。。
1、需求
从一些测试交流群以及同行那里获取到很多有趣的信息，比如需求描述不清晰，需求变更快，没有需求没有原型图等等很多看起来很不可思议的事情，甚至没有需求评审等环节，
当然，这些这样那样的问题存在，跟公司文化、部门开发模式、领导者的想法、同事个人因素等等都有关系；但作为一个测试，或者说作为一个尽职的员工，抱着解决问题的心态，
总是没错的，抱怨解决不了问题，积极沟通，熟悉了解需求，才能更好的去设计用例，分析可能存在的问题点，“在其位，谋其职”，不断提升自己的经验，沟通交流的方式，
才是正确的方式。
推荐书籍：《Google软件测试之道》
2、用例
说到测试用例，可以说是最基本也是最难得一点，如何灵活运用用例设计方法，分析功能点，尽量做到覆盖，描述简洁清晰直观，很重要，但用例的功能点，模块分支，又是来源于
需求，说到这里，问题来了，很多时候，我们没有足够的时间去设计、编写测试用例，只能凭借个人经验和误打误撞去进行测试了。原因呢，很多，需求变更导致的开发时间延期，
上线时间不变，临时情况，公司流程，管理，以及对测试的重视程度，都有影响，这往往也是测试人员的痛点；因为用例设计时间不够，覆盖率不高，导致的生产问题，但测试，
往往是第一个背黑锅的，好吧，说到这里，这是个槽点，每每听到同行说起又出问题了，又损失多少，是谁的责任，让人无语（此刻，我建的IT群某个家伙说他们生产又出问题了，
听着很纠结）；解决这个问题，个人感觉是个任重道远的事情，国内大环境，除了少部分大型互联网公司，其他中小型企业，对测试，重视度还有待提高，当然，测试人员技能，
经验，良莠不齐，也是一个问题，说到这里，体现出一个东西的重要性了，那就是流程（当然，我本人虽然一直在努力和其他测试同事推进公司IT部门的测试流程规范，但并不是流程
的崇拜迷信者，不过无规矩不成方圆，流程，就相当于一个大体的方向）。所以，工作中总有各种问题，保持心态，解决问题，才是我们应该一直拥有的态度。
推荐书籍：《探索性软件测试》
3、缺陷（BUG）
说到BUG，这是个很头疼但不得不面对的问题，没有完美的产品，即使这个软件应用经过了多轮仔细全面的测试，软件测试岗位，本身就是为了去主动地发现，暴露BUG，怎样
发现BUG，这个一方面取决于测试人员的个人经验，用例的覆盖程度，流程上的完整，各方面的规范，个人技术能力（定位BUG，以及BUG的等级，优先级，是否是BUG或者是否需要
优化）等等方面；关于BUG具体的定义以及概念性质的东西，这里就不一一赘述了，有兴趣的可以去看看我之前的博客，在基础知识分类里面。
推荐书籍：《Google软件测试之道》
4、文档&报告
文档的内容，包含很多，需求文档，测试计划，测试方案，测试用例（一种输出形式，也可以用BUG管理工具或其他方式代替），接口文档，表结构设计文档，测试报告，上线报告，
用户手册等，听起来很多，但实际上，这些东西，都是很有必要的，因为它规范了流程，清楚明确的定义了职责，内容，结果，当然，具体的编写模板什么，百度一下，你就知道。
说起百度，想起一个梗，百分之80的问题百度都能解决，百度解决不了，FQ，如果还不行，自己想办法吧（写到这里，莫名想笑，想起很多的伸手党，鄙视ing）；当然，文档除了
指导工作进行，还有一层含义，给老板，领导看。。。这个问题，源来已久，貌似是人类的共性，吐槽三分钟。。。
5、上线（发生产）
这个呢，可以说是检验我们的开发测试结果的一个标准，一切以使用结果来说明，用户的态度，决定了我们的能力和薪资；当然，我个人觉得，由测试来进行打包发布，还是比较
靠谱一点，当然，是由技术经验比较丰富的人来执行。不过，为了预防我们遗漏的缺陷，可以选择分批发布，有一个名词，灰度发布（这个名词，还是前不久听IT群里Nero大佬说的，
当时觉得不明觉厉，百度后，发现我们正在或者未来都将采取这种形式来发布生产，这是一种预防机制和风险预备方案）。
灰度发布：灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，
那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。 来源：百度百科
总结：
说了很多，总结出来，无非就几点：流程、管理、环境、技术经验、沟通、灵活运用，以及解决问题的态度和出发点；解决问题的态度，很重要！！！
about学习
学习这件事呢，完全看个人追求吧，个人职业规划，兴趣爱好等等很多莫名因素，说说我自己的学习过程和一些方法，认知吧。。。
我大概是从15年11月份开始主动学习的，动机呢，很简单，一次莫名的被鄙视而已，由于当时本人技术太渣，so，开始自学充电，直到现在，给我提升很大，各方面。
学习，真的是一件很容易上瘾的事情！！！
我个人觉得，IT本来就是一个技术行业，而且从第一次工业革命至今，技术更新换代速度越来越快，现在这个时代，是一个不断变幻的大时代，特别是互联网这种相对来说比较
前沿的行业；而且，从个人提升不被淘汰，跳槽加薪的资本，面试的底气，以及个人思维（看书学习，使得我现在遇到问题的思考方式，逻辑，以及很多甚至生活中的方方面面，
都有很明显的影响），工作上的游刃有余，学习提升，都很重要。而且，IT行业，技术这东西，虽然分类很多很细，但这正如木桶理论一样，一门技术的熟悉程度，决定了木桶的下限，
而要在众多竞争者中脱颖而出，最高的那一块，最为重要。下面说说我目前已经学习过的技能以及短期内的学习目标吧。。。
协议：《图解http》、《图解TCP/IP协议》、《HTTP权威指南》，这三本书，都已经细细阅读过并做了学习笔记，工作中也不断的在实践理解中；
数据库：《mysql必知必会》、《oracle、PL/SQL必知必会》已经细细阅读完，正在整理学习笔记，对工作的提升也很大；《数据库系统基础教程》正在阅读学习中；
编程：《python基础教程第二版》结合一些线上教程，视频，正在不断学习中，当然，python也是下半年主要的学习目标；
性能测试：基础的理论算是掌握的差不多，工具呢，jmeter用的也还算凑合，loadrunner恕我智商太低，没怎么用过，也不会用（其实工具精通一个就好，其他的熟练使用也是
很好的），也在实际工作中进行了一些性能测试，踩了很多坑，当然，经验也累积了一些，性能测试，也是主要的短期内的发展方向；
理论性书籍：《软件测试的艺术》、《软件测试的经验和教训》、《Google软件测试之道》、《从菜鸟到测试架构师》已看完，受益良多，下一本书是《探索性软件测试》；
其他书籍：《正则表达式必知必会》正在学习中。。。
总结：关于学习，目前就这些，未来视具体情况而定；只有很努力，才能看上去毫不费力。。。
about职业规划
这个，比较难说，毕竟计划比不上变化，不过短期内，应该是测试开发的目标，稍微长远点，测试架构，抑或大数据，数据分析师，这个是我比较向往的，当然，一切都一步步去实现。
毕竟已经从事软件测试工作，而且，我个人对互联网行业比较喜欢，以后，也是从事互联网相关行业，人无远虑必有近忧，不断盘复，不断调整目标，相信，所想终会得到！！！
最后呢，说些什么呢，生活源于工作但高于工作，努力工作，好好生活，注意身体。。。
转载请注明出处，商用请征得作者本人同意，谢谢！！！