今天与业务测试的小伙伴聊到如何从业务测试转到测试研发的一员，分享给大家共同讨论。具体聊天内容如下：

小伙伴说：你们测试研发团队用的什么技术栈呢？

我说：我们后端用的java，前端用的vue

小伙伴说：哎，我之前就是想加入测试研发团队的，这下感觉没有希望了。我学习的python。

我说：其实，这个没关系的，语言之间本来差别也不大。虽然我们测试研发团队的技术栈只需要java语言的。但是，在业务测试团队里，你仍然可以利用自己掌握的python，做很多技术和工具上的输出啊。

小伙伴还是觉得不能进入目前我们团队的测试研发感觉有点遗憾，又接着说到：
据我了解，测试研发团队的很多小伙伴都是从业务开发转过来的，你也是吗？

我说：恩恩，很多的小伙伴是从业务研发转过来的。不过，我不是，我也是从业务测试转到测试研发的。我之前是在北京那边做测试经理的，主要负责的就是业务测试。后来，转到阿里就直接做的测试研发的职位。

小伙伴说：那你怎么转过来的呢？大概要学习多久才能转过来呢？需要专门学开发两年以上吗？… 能给点建议吗？

我说：
第一阶段：我之前在做业务测试的时候，我会把我负责的所有项目的业务代码都看一遍的，就这样差不多一年多的样子吧，我就基本掌握了java语言了，而且还掌握了很多开发的设计和思想。目前我们公司业务的开发代码其实就是java，你完全可以在业务测试的过程中，通过熟悉业务代码的途径掌握起来java的。
第二阶段：我大概能理解开发写的业务代码后。我在做业务测试的过程中，当我发现了一些业务的BUG后，我会去用代码对比，看一下开发修改这个问题是怎么修改代码的。并且，有意的记录下这些问题和解决办法。这样，就形成我个人的一份常见问题和解决方案的表单。
第三阶段：随着我代码能力的提升，我开始对业务代码进行review的流程推广，自己在review业务代码的过程，把发现的问题和开发进行确认，并给开发提出相应的解决办法。在提交的bug里，也会把bug标记为白盒bug，并在修复意见里给出修改的解决办法。这样，开发的同学和领导都能看到和关注到我个人的代码能力。
第四阶段：阅读代码的能力基本没问题了，后来，我就开发动手写一些辅助业务测试的小工具，一方面巩固自己的代码能力，还能对业务测试有一些帮助。并且，做这些事也很有成就感，也能提升自己的价值。

小伙伴说：谢谢你的建议。还有一个问题我也想问你一下，就是我在做业务测试的时候，感觉自己什么都测试到了，但是上线仍然心里很慌，没有底。这个有什么办法吗？

我说：我们都是做测试的，所以大家应该心里都清楚，项目里的bug不可能被完全测试出来，有bug也是很正常的。不过呢，我们怎么能让测试的项目，尽可能少的漏测，尽可能的提升自己对项目的信心？
这个其实也不是太难，这么说吧，所有bug的源头，可以说都要归结于代码上。那么，如果我们对代码、代码可能存在的bug都很了解的话，那么，我们自然会对项目有足够的信心。比如：为什么开发会对自己的代码这么自信，当我们测试出来bug的时候，开发基本上第一反应都是，怎么可能？我的代码怎么可能有bug？！
其实，这个信心就是建立在开发对自己代码了解的基础上。当然，最终bug也确实是bug，开发也会修改这个bug。那么，我们要怎么建立对项目的信心呢？！方法其实是一样的，业务测试也要对自己测试的代码有足够的了解，足够的信心。那么，心里自然也不会慌了。
如果能达到这个点，那么：开发自测（开发）+代码review(测试)+业务测试（测试），按这个流程下来，开发和业务测试都对代码足够自信，而且业务测试场景全覆盖，我可以保证，基本上不会出什么问题，即使出了问题，我们也可以把这些问题作为经验，以后避免此类问题。

最后，小伙伴说：那么，如果我想学习java或者vue这些技术，能给点意见吗？

我说：如果你要自学的话，尽量不要买系列的图书，比如：xx入门、xx熟练、xx精通，这样的话，可能会浪费掉你过多的学习时间，对于一些较深入的技术，可能理解和学习起来对于熟练工都挺吃力。我建议你只需要买本入门就可以了。然后把入门的教程学习完后，掌握了基本的知识后，那么，你就可以开始动手去写了，从我的经验来说的话，写是学习的最好路径。在写的过程中，当你发现你的问题、你的不足，你百度搜索解决办法的过程中，其实，你找到并掌握的解决办法就是熟练或精通的技能。当你写到几十万行代码的量级，当然，前提不是ctrl+c、ctrl+v。那么，此时你其实可能已经达到熟练或精通的程度了。这时候，你再去看xx熟练、xx精通，可能你对于这些内部的学习，更容易上手，更有收获。

小伙伴：谢谢啊，谢谢你给的建议，我感觉我有了一些方向。