对测试转开发的一些想法
首先需要引两个外链：
http://blog.csdn.net/haozhugogo/article/details/68961125
http://www.cnblogs.com/pentest/archive/2010/09/12/1824238.html
为了防止外链以后失效，我在此把原文内容复制下来，如果原作者觉得侵权，我会第一时间删除
外链1:
>其实我这两天，重新审视了一下我的内心，我想从一个测试转开发的真实动机到底是什么？那绝对不是因为我爱开发技术爱的痴狂，虽然我确实适合做技术。 根本原因就是，我受够了做一个功能测试。 功能测试对一个人的成长没有任何帮助。 产品经理去了解业务，设计系统流程，然后与开发讨论实现的问题，然后开发把它实现了，然后丢给我测，超尴尬的： 首先，我并不了解业务。产品经理在设计产品时从来不与测试讨论这样行不行的通，好不好实现，更不会带我去找需求方沟通。我只是对“开发做出来的产品”比较熟。最了解业务的，还不如说是那个在产品设计初期就与产品经理频繁沟通的开发。 然后，觉得自己地位很低。功能测试人人都可以做，并没有什么门槛。但是产品经理不去做，开发们更不会去做，我猜他们心里也觉得，这是没什么技术含量的活，并不想浪费自己的时间，这种事情都交给测试来做。 于是，开发们总是对我说“这个我又改了一下，你再测测”，我觉得我就是个按照别人的吩咐点鼠标的。 最后，作为这种存在感到很羞耻。没有很精通业务，也没有一技之长。。。 并不觉得自己很有价值，反而是觉得自己可有可无。 不赞成那些给测试洗脑的言论，什么点鼠标积累业务了呀，什么给产品提意见，什么做为最产品链最末端提出用户体验，是的，我们可以这么做，但这并不是我们独有的职责和独有的能力，任何人都可以这么做。 所以，我想转开发，只是想从这种无比厌恶的状态中逃离出来。 虽然结果没转成，但我仍然要说一句：我讨厌开发再告诉我让我把什么什么再测一下。外链2:
>进入测试行业将满六年，从手工测试开始，到现在几乎涉及了测试的所有方面。从我的经验过程，接触不同的测试方法上基本上是走了两条线。 Manual Test -> UI Automation -> API Automation -> Driver Test Reliability Test (including stress) -> Security Test -> Performance Test 当然还有什么Localization, Accessibility, Code Coverage等等，但不算很主要的测试方法。还有Code Review, Debugging 这些和开发共享的技术方法。 04年测试对我来说几乎是一个全新的领域，因此这几年集中精力在测试技术的学习和体会上，由于已经精通了以上大部分的测试方法，因此也在考虑下一步的发展。基本上来说，能认可我这些测试技术，和接受我对测试理解的地方并不多，可能是非常非常少。 因此也在试探性的探索测试转开发的难度有多大。基本上来说，测试想转开发的话，越早转越容易，级别越低转越容易，与你的背景越match越容易。这里我说几点经验体会。 工作时间短，级别低，别人对你的expectation就比较低，可能跟新毕业生差不太多，所以容易。 工作时间长，级别低，别人就会怀疑你的能力，因为你在测试的工作都没什么成绩，因此可能性很小。 工作时间长，级别高，也会很难。因为你要是同级转到开发的话，你很难证明你具备同级开发的水平。而且，你既然已经有工作经验了，他们就会看你的工作经验对他们是不是有用。 虽然很多人跟我说过，自动化也是编程序，转开发比较smooth。我以前就不是很认可，因为测试编程比较简单，quality也比较低。现在发现确实人家要求要有实际产品的coding经验，而只是自动化的经验看上去不够。 如果你的工作经历和技术背景跟开发的职位很match的话，会有比较大的希望。这也是为什么很多人是同组转，甚至很多人是因为测试项目的开发人员离开了而得到的机会。从我目前的短短三个月的从业经历看，【外链1】的内容简直就是直逼我的灵魂深处，虽然观点比较偏激，但是扪心自问自己确实不能再赞同。我现在跟导师一起两人扛起接近20个开发的产品测试任务，平时的任务绝大多数都是手工业务测试，想了解产品逻辑基本上只有两种手段，要么是仔细阅读产品的说明文档，要么是直接找开发了解技术细节。然而，一般写文档的开发也不会多上心，只会以一个外部的角度来描述功能，功能实现的细节只会粗略提及，也不可能老缠着别人问问题，因为别人也要忙。结果就是，一来靠产品文档无法学习到核心，二来跟开发暂时不太熟也不能总是骚扰人家，所以一直担心自己的测试其实只是流于表面，无法深入到核心，视野狭隘，特别是现在还是新人阶段，大多数任务还是点鼠标的web页面测试，一些简单的接口和性能测试和最最无聊的兼容测试，根本没有感觉到自己有实质性的成长，无论从技术上看还是视野上看。
另外，由于测试人力的严重不足，很多本来应该有机会写代码做自动化做CI的机会也被手工测试给吞没了，如果想为测试工作编写代码，多数只能压榨自己的业余时间，但是自己业余时间又想多学一些开发的知识，又是非常纠结。
昨天跟一个隔壁大项目组的，毕业出来工作刚满一年的女同事聊天，虽然得知她一来到这边测试也还是点鼠标的web页面测试，后来经验多了就慢慢转到后台，慢慢承担起技术含量更高的后台测试，而她所在的项目组负责的是公司内部全网部署的一个涵盖分布式认证系统、IDC单点登陆系统、主机安全防护、安全大数据审计、控制系统、鉴权框架等功能集成的大产品集（不明觉厉）。她在跟我聊天的过程中让我意识到我目前非常致命的缺点就是测试不往深入思考，心态不端正，眼高手低。后来我自己想了一下，也确实是这样，自己来到公司做测试，其实只是把测试当作是职业跳板，为的是有朝一日可以从事自己梦寐以求的开发工作。而大概两个到三个星期前，我的导师又跟我聊过职业生涯，让我明白我要是想做开发就得赶紧做出行动，不然测试从业了两到三年后，拿着简历出去外面，发生的可能就是【外链2】的情况，因为那时候自己也不会是应届生身份了，社会对你的要求是你来到就要立马上手干活创造价值，而不是还得在你身上投资培养，如果要投资培养企业肯定会挑毕业生来培养，因为毕业生还是一张白纸，他们学习欲望强，学习能力强，工作主动性也高，企业很多时候甚至可以向他们灌输特定知识来掌握毕业生的发展方向（我觉得这也是我目前身为一名新人的唯一优势了）。
那么，目前我的困境，总结起来就是这个：
从事着自己不是真正想从事方向，但又不可能任性地不干就不干，一方面需要花时间在目前岗位上做出成绩来，一方面又要兼顾自己以后的发展方向挤时间学习。
这真不是一个好调和的问题。继续在当前岗位上工作，想要做出成绩得压榨自己的业余学习时间，不然的话成绩平平无奇，整个人的激情就这样被磨光，然后就变成了混日子的人，我讨厌那样的自己。就目前来看，如【链接1】所说，我确实是感觉到自己这个测试人员是一个可有可无的存在：说什么好听的用户体验，对不起，测试的是内部产品，不对外面向社会，用户体验优先级十分低；说什么积累业务经验，对不起，业务总是千变万化的，你熟悉的只是一套业务逻辑，换种业务不还是得重新学习？本身这个说法就站不住脚；说什么拿开发的代码过来白盒测试，对不起，这是内部安全部门的产品，代码多数属于机密，测试人员特别还是新人是不可能接触核心代码的，而且本来就缺人力测试更加没有时间来放在代码白盒测试中去。到最后不想干了，跳槽了，拿着简历出去没人接受你这样的人做开发，很大概率还是只能继续从事测试……It's such a fucking disaster!
吐了这么多苦水，也得有个解决办法才能解决目前的问题啊，一番反省思考后，根据下面几个前提条件：
- 不能直接撒手毁约离职
- 不能让自己沦为每天执行任务丝毫没有激情的工作机器
- 不能让自己的发展方向越走越窄最后困在测试这条路上
- 不能在测试不做出成绩
我得出的解决方案如下： >* 不能继续眼高手底下去，要承认自己是看不起测试的，也看不起在测试岗的开发工作（比如CI，监控，自动化等），但是必须要去接受，有自己的技术偏好是正常的，但不吃葡萄就说葡萄酸绝对是错误的，自己应该在测试岗上继续探索更多的可能性才有资格再来下结论。 >* 分配好业余时间，是牺牲业余学习时间来出工作成果重要，还是保持对自己感兴趣的方向持续耕耘重要？目前我觉得还是应该把更多时间放在工作上，因为如果工作上出成绩，上头对自己信任了，会放手让自己去尝试其他可能性，长远来看会更好；而工作成绩平平，就算开发学得也不差，简历上还是很难让其他企业接受自己来做开发。 >* 如果想减少业务测试的工作占比，应该更主动地去承担关于自动化、CI、监控等代码编写工作，并且要做好，做不好就不要接！我一直认为一个代码难产的测试不会是一个好测试！
望自己谨记教训。
