前阵子看了某某测试论坛里有篇文章名字叫《测试牛人的十年工作感慨》，但看完后发现他总结的那几点应该不区分职业，所以名字可以叫开发牛人的xx年工作感慨，也可以叫运营牛人的....
作为一个在测试这行做了7年的老人，其实入行时是非常迷茫的，通常情况下计算机专业的同学大部分会选择开发，而非计算机行业的同学选择测试主要都是门槛较低。入门后往往一直停留在鼠标点点页面的阶段，做了几年后去大公司找工作都是偏技术的一线测试，要求很高，所以越干越迷茫，偏业务的往往也做的无法自拔。
于是乎各种培训机构应运而生，需求摆在那，很多测试人员技术太弱，工作中在日常工作无法凸显亮点所以借此提高....
我的测试工作其实也是这样过来的，但是就职业而言，测试重要程度的确不如开发。开发是负责具体实现的，而测试只是负责发现bug的，产品运营通常都兼职做测试，那为什么还需要专职测试呢？我认为专职测试的优势就是在于专业。业务测试的确是最最最需要的，一般业务线的测试人员日常工作的70%都是功能测试，但是不懂技术的功能测试往往发现的问题都是有限的。
我曾经效力过一家互联网巨头，他们研发部门的老大非常执着于业务，几乎每天都让手下人加班加点赶产品提来的功能，而很少重视技术。导致后续需要依赖大量的测试人员靠堆积工作量来保证产品质量，我真的觉得非常可笑。难道测试人员就是猴子吗？需要天天重复地做回归测试吗？
不少研发同学都觉得技术和业务本身就是矛与盾，很难达到中间的平衡点。我觉得这个想法本身就是错误的，作为产品的需求方要有长远考虑，考虑整个产品的发展方向，而让技术实现的同学有个大致的概念，有个总体的框架支持到后续扩展，这样测试同学也不用天天疲于奔命，而不是想到啥就是啥，这样大家都太被动，开发要敢于对产品说No，测试要敢于对开发说No，这样才能做到过程改进。回到测试上说，测试也需要将注意力从功能测试转移到自动化、性能、安全等偏技术专业的领域上，而避免去做一只可怜的“猴子”。
说到技术环节了，肯定有不少测试同学肯定要泼冷水，什么什么工具没接触过；什么什么开发框架不熟悉，天天忙着测试变更哪有时间学。其实这些只是自己的借口，对于测试同学来说技术真的还不像大家想象的那么难，我几大测试领域都有涉猎，平时也是靠不断积累不断摸索不断试验出来的经验与技能。我对jmeter比较熟悉，但是往往刚接触jmeter的人都觉得他很难，比LR难。而我在接触下来反而觉得Jmeter很简单，因为当你研究到一定深度，反而觉得是信手捏来。就学习手段我反而觉得自己学习要比报培训班强不少，因为除了掌握的扎实外还能省钱，当然实在说自己没时间和学习能力差的同学可以报个班走走捷径。
热爱学习的同学反而可以往细研究，培养兴趣。比如UI自动化领域可以先从熟悉selenium学起，当能够通过自己编写的代码让功能一步步运行起来，反而会有一种成就感。然后逐步再各个分支击破。比如执行自动化如果提高效率----grid2分布式执行框架。如果hub要部署到linux上是否考虑做成服务或者自启动的，是否写个shell脚本去优化把配置和脚本剥离，是否写个守护进程去保证hub稳定运行，诸如此类不断追问为什么和怎么做，通常自己知识的深度也会越来越深。
然后聊聊带新人的话题，我个人是非常乐于帮助新人答疑解惑的。因为往往在辅导新人成长的同时，也是给自己上课的过程，可以让自己不够扎实的基本功得到提升。
下面再聊下测试发展，测试这个职业通常情况下更像一个多面手，所以不可能做到面面俱到，在学习过程中可以接触到技术的各个领域。一些经验丰富的同学，如果你偏业务测试的可以转向产品，而偏技术的测试可以考虑转向测试开发，而在各自的喜爱的领域下能开花结果。伴随着个人技术的提升和业界对于敏捷的需要，测试这个领域也会不断发送改变，从单纯的业务测试逐渐向技术型过度，最后成为专家，所以大家如果在测试这条道路上持续走下去必须要考虑技术方面的提升。
扯到技术提升不得不分享下我的学习方法：
多参与一些公开课：公开课往往是某一方面的专家给你介绍一些比较粗的知识点，你知道了这些知识点就可以有很多扩散性学习的点，并且能从讲师身上分享到不少经验
多参与一些技术群/社区/线下沙龙：可以结实一些牛人，从牛人身上了解业界的发展方向，从而使自己不要太落伍
多总结问题：EverNote是一个比较强大的笔记软件，遗憾的是索引不够强大，但你完全可以把掌握或者学来的知识点进行梳理记录在笔记里
多上网查找答案，自力更生：既然你选择了IT行业就要不断自我解决问题，而不是像读书那样。问题的答案我比较倾向于官网和stackoverflow.com找寻答案，因为那里的答案最准确，而且最全
希望每个测试人员，不管是才入门的还是老鸟，都能招到自己的归属感和满足感，这样才能将这个职业发扬光大。
