今天與業務測試的小夥伴聊到如何從業務測試轉到測試研發的一員，分享給大家共同討論。具體聊天內容如下：
小夥伴說：你們測試研發團隊用的什麼技術棧呢？
我說：我們後端用的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精通，可能你對於這些內部的學習，更容易上手，更有收穫。
小夥伴：謝謝啊，謝謝你給的建議，我感覺我有了一些方向。