测试开发人员的职能
其实也是质量保障。无非就是保障的手段更加的技术化。
上文我们也说过，测试的时间周期在很多时候是整个项目时间周期缩短时首当其冲的栖牲品，测试的时间往往是不够的，物以稀为贵，也就是说测试的时间是相当宝贵的，如果能加快测试的速度，降低用例回归的成本。
将以前的选择性测试（测一些重点功能）变成全面的回归测试+重点功能的人工干预，那么项目的质星可能会比纯人工测试要好。
所以一些自动化的加快回归速度，降低每次回归成本（比如100个自动化用例，如果回归100次，那么每次回归的成本相对来说还是很低的)，那么是可以一定程度上解决时间不够的问题的。
测试开发同学质量保障的手段可能不如手工测试同学那么直接，测试开发同学一般是通过提高试效率来帮助产品改进质量。
以前在同一个时间周期，手工测试可以回归100个用例，现在测试开发的同学可以让这个时间周期内回归到的用例数达到1000个，效率提升了1O倍，由于效率提升而节约的时间就可以投入到其他的质量保障手段中去，比如code review之类的，质量保障的方式更加的立体化，更加的有层次感。
总之测试开发同学的关键字是效率。
手工测试如何转测试开发？
其实很简单，当然过程会比较痛苦，那就是提升效率。
尽可能的把费时费事的试工作用机器或用一些更加有效率的方式去实现。
比如性能测试，如果没有自动化的加压工具，性能测试很可能是一群人在三更半夜统一思想听统一号令一起点网页的工作。性能工具极大的提升了性能测试压力发生的效率，降低了成本和难度。这就是测试开发很好的切入点。
手工测试同学可以这样的慢慢培养自己的测试开发意识，潜移默化的完成转变
找到可以进行效率提升的点。比如每次测试之前都要手工的去系统里创建一些测试数据，这些工作是不是可以用自动化的方式去做呢？
学会一门编程语言。学会跟计算机交流，让计算机去做那些需要重复反复去做的事情：
学会使用一些测试工具。比如selenium一学会操控网页，比如postman-一学会测试一些restful的接口等等；
根据业务的需求，自己开发一些测试工具或平台。比如公司需要统一的压力发生平台，能不能试着用jmete的集群模式去搭建一个呢？
因此我们可以看出手工测试转测试开发的过程是一个思想转变和技术提升的过程。
我是不是应该苦练测试开发技能，然后换一份专职的讽测试开发工作？
我的建议是不要总是想着换工作，争取可以把自己的手工测试职位变成是测试开发职位，把学会的技术技能运用到目前的工作中去。
其实你目前的工作并不缺少测试开发的场景，你只是缺少发现这些场景的意识。所以尽量把自己学到的技术应用到现在的工作中，而不是想着去换一份专职的测试开发工作。
