在回答这个问题之前我们先回答其他一些问题。
　　测试人员的职能是什么？
　　我认为是质量保障。一个测试人员，无论你是手工点来点去，还是用自动化进行一些模拟操作，他们的核心职能都是相同的，那是保证项目或产品的质量。如果你能保证你负责的模块缺陷数少，并且基本没有什么问题会遗留到生产环境或用户环境的话，那么你是一个的测试人员。至于你用什么方式去达到这个结果的，手工还是自动化，这些都不太重要。关键的问题是，你需要在规定的时间内保障项目／产品质量。
　　规定的时间内往往是加班的罪魁祸首，一般来说如果项目工期比较紧急的话，项目的管理者大多会砍掉测试的时间以便项目能够及时交付。所以很多时候测试人员没有足够的时间去进行完全的反复的测试，只能凭借直觉和经验来重点验证新功能或核心功能，而一些不太重要的功能可能在回归时被忽略。在有限的时间内，有经验的测试人员会优先选择测试变化的功能，也是代码发生了增改的功能；另外还有一些测试人员选择对团队中能力较弱的开发人员开发的功能进行重点测试(好吧，我以前是这样，牛人写的代码往往缺陷不多，那些能力平平的人做的功能往往缺陷买一送一，惊喜不断，甚至出现改一个bug送几个bug的情况)，从长远上看，这种策略对项目质量是有帮助的。
　　如果你能在保证产品质量的前提下捞到一些闲暇的时间，那么你可以去研究自动化测试，接口自动化测试，app专项测试和性能专项测试。对于一般的测试人员来说，这些技能是加分项，能让你在找工作的时候给人很好的第一印象，以及获得不错的议价能力。
　　总而言之质量管理能力觉得你薪资的下限，其他测试技术相关能力觉得你薪资的上限。
　　测试开发人员的职能是什么？
　　其实也是质量保障。无非是保障的手段更加的技术化。
　　上文我们也说过，测试的时间周期在很多时候是整个项目时间周期缩短时首当其冲的牺牲品，测试的时间往往是不够的，物以稀为贵，也是说测试的时间是相当宝贵的，如果能加快测试的速度，降低用例回归的成本，将以前的选择性测试（测一些重点功能）变成全面的回归测试+重点功能的人工干预，那么项目的质量可能会比纯人工测试要好。
　　所以一些自动化的加快回归速度，降低每次回归成本（比如100个自动化用例，如果回归100次，那么每次回归的成本相对来说还是很低的），那么是可以一定程度上解决时间不够的问题的。
　　测试开发同学质量保障的手段可能不如手工测试同学那么直接，测试开发同学一般是通过提高测试效率来帮助产品改进质量。以前在同一个时间周期，手工测试可以回归100个用例，现在测试开发的同学可以让这个时间周期内回归到的用例数达到1000个，效率提升了10倍，由于效率提升而节约的时间可以投入到其他的质量保障手段中去，比如code review之类的，质量保障的方式更加的立体化，更加的有层次感。
　　总之测试开发同学的关键字是效率。
　　手工测试如何转测试开发？
　　回到正题。
　　其实很简单，当然过程会比较痛苦，那是提升效率。
　　尽可能的把费时费事的测试工作用机器或用一些更加有效率的方式去实现。
　　比如性能测试，如果没有自动化的加压工具，性能测试很可能是一群人在三更半夜统一思想听统一号令一起点网页的工作。性能工具极大的提升了性能测试压力发生的效率，降低了成本和难度。这是测试开发很好的切入点。
　　手工测试同学可以这样的慢慢培养自己的测试开发意识，潜移默化的完成转变
　　找到可以进行效率提升的点。比如每次测试之前都要手工的去系统里创建一些测试数据，这些工作是不是可以用自动化的方式去做呢？
　　学会一门编程语言。学会跟计算机交流，让计算机去做那些需要重复反复去做的事情；
　　学会使用一些测试工具。比如selenium——学会操控网页，比如postman——学会测试一些restful的接口等等；
　　根据业务的需求，自己开发一些测试工具或平台。比如公司需要统一的压力发生平台，能不能试着用jmeter的集群模式去搭建一个呢？
　　因此我们可以看出手工测试转测试开发的过程是一个思想转变和技术提升的过程。
　　我是不是应该苦练测试开发技能，然后换一份专职的测试开发工作？
　　我的建议是不要总是想着换工作，争取可以把自己的手工测试职位变成是测试开发职位，把学会的技术技能运用到目前的工作中去。
　　其实你目前的工作并不缺少测试开发的场景，你只是缺少发现这些场景的意识。
　　分享一个我朋友的故事，好吧，其实是我自己的故事。
　　2009年的秋天，我在某外包公司做手工测试，外包公司的流程管理很严格，手工回归的工作很多，而且也很辛苦。那时候是ibm的测试人员写测试用例，我们回归，我们写另一个模块的测试用例，让ibm的测试人员回归。1个项目有2个公司的外包测试团队参与，是那时候的常态。
　　很凑巧，那时候我们公司有一些qtp的授权，反正也没人会，我在工作之余（一般是白天，晚上要验bug，白天开发改bug）勤学苦练，好不容易把qtp学会了一些，然后用录制和加检查点的方式搞定了一个小系统的回归测试。这样开发白天改bug，我们晚上用机器去回归，现在想想那时候回归很挫，还要有人盯着，防止qtp自己跑崩溃，但这还是比自己点来点去看着要爽。
　　后来我们有很多的项目都使用qtp进行回归，我也成了专职的qtp自动化测试人员，那时候还没有测试开发这一说，不过现在看来我应该是一条腿迈进了测试开发的大门。
　　所以尽量把自己学到的技术应用到现在的工作中，而不是想着去换一份专职的测试开发工作。
　　这个故事后来的发展是：我涨薪了，涨了一倍，跟开发的薪水一样。
　　当然这是个正面的例子，转型失败的例子也很有多，无非是能力加运气，缺一不可。