求意見，軟體研發轉行測試研發，職業目標：測試架構師？

01-13

研究生畢業，性別女，從事軟體核心技術研發工作兩年四個月了，可使從去年十月份開始，突然產生了一個想法，在GIS行業，我好想永遠成為不了一個優秀的工程師，即使再幹上七年，也可能就是一個普普通通的程序員，不能獨擋一面，也成為不了一個牛人，只能算是比上不足比下有餘，三維GIS這一塊的水太深，技術難度也太高，無休無止的技術攻關讓我感到恐懼，這讓我很痛苦，也讓我對自己的逃避行為感到羞愧。
沒有人甘心平庸，我也特別不甘心以後只能成為一個默默無聞的程序員，別人提起自己時，沒有什麼擅長和值得驕傲的地方，考慮了很久，綜合了很多同學和朋友的意見，決定轉行做測試研發。
根據國內軟體的現狀，我對這個方向的發展還是很看好的，所以自己報了周末培訓班，學習性能測試，自動化測試，同時也在自學linux以及shell，但是感覺現在很多大企業招聘測試的要求都好複雜，都要求有測試經驗的，求各位前輩指點一下，我的選擇對不對？以及該如何增強自己的競爭力？

個人在自己的微信公眾號上分享過一篇測試架構師的成長經歷，這裡轉到這裡大家看看。原文如下：

先說說筆者的初始條件（應該很多人看了都會有更多的自信吧）：一個普通本科學校，雖然是科班出身，但是除了大學的課程設計以及其他需要寫代碼的功課外，基本上沒有去主動寫過代碼，更別說去研究linux內核等等高大上的事情了，反正基礎是很差的（你別問我大學都幹嘛去了，我也不知道，反正兼職，泡妞，打球，遊戲，圖書館，考研等全都干過，就是沒有去專研過代碼），所以，畢業後程序猿的工作自然是找不到合適的，然後軟體測試的門檻想對低一點，就進入了這個行業（本來當初是打算先進入這個行業好好學習了，去轉開發崗位的，結果一直干到現在）；

下面說說筆者這5年來的成長曆程吧，為了顯得更加有層次點，每年分成一篇吧（實際上界限沒有那麼明顯）

第一篇：打醬油篇

因為剛進入公司，對測試和業務都不了解，結果就被安排到一個大的項目裡面負責2-3個小模塊的測試工作，說是負責這些模塊的測試工作，實際上，用例都是別人寫好的，自己只需要去執行用例就可以了（當然，培訓還是有的），標準就是保證這些用例執行後沒有質量問題，其實就是沒有執行漏測就可以了。

剛開始還是懷著一顆敬畏的心去做的，但是2個月新鮮勁過了後馬上就開始迷茫了，尼瑪這工作也太無聊了吧，而且毫無技術含量而言。難道這就是我後面一直要做的事情？不過雖然不爽，但是因為項目比較緊，所以還是調整了下心態堅持將整個項目按照這樣的方式弄完了，整個過程持續了6-7個月的時間。結果居然因為項目表現比較好拿到了優秀的考核結果，原因是自己負責的模塊質量比較穩定，並且過程中發散測試的時候發現了幾個嚴重的bug，這更加讓我不知所措，但是自己知道不能夠在這樣下去了。

沒有辦法，找老大聊了下，得到的大概信息就是，現在項目比較緊，只能優先去保證項目，至於改進，後面慢慢再做；因為，這樣對於自己的成長肯定是沒有幫助的（至少當時是這麼認為的），於是，選擇了走人（當然，提前找到了另外一家，也就是現在這家公司）。

因為兩家公司的業務完全是不同領域，並且以前的測試流程跟當前也有很大的區別，所以，基本上又是從頭學起，做的也是測試執行的工作，這個過程差不多又持續了半年左右，但是跟以前有點不一樣的是，開始能夠接觸自動化以及一些新的測試方法了（這個後面會講到），整體來說，雖然後面半年也是做的測試執行工作，但是至少自己看到了希望（因為組內已經有這方面很厲害的人物了），也大概清楚了自己應該想哪些方向去努力（選擇比努力更重要這句話還是挺有道理的）；但是第1年自己基本屬於打醬油篇，因為自己在測試這塊領域還是剛剛入門。

第二篇：自動化篇

開始去涉及自動化應該大部分是自己主動去做的，那個時候因為團隊開始去嘗試做自動化，所以鼓勵大家多去思考如何通過自動化去提高自己的工作效率，但是因為項目實際上也壓的很緊，所以老大採取了這樣的兩個方法：1、加班去完成任務 2、每個人將最基本的功能梳理出來做成自動化；並且內部給大家灌輸了一堆這樣做的好處；不管是不是真的，效果還是很明顯的。大家像打了雞血一樣（這點只能說跟對老大還是很重要的），每個人去花時間學習腳本（最開始用qtp，後來用pythen，ruby等）以及嘗試去做自動化。經過3個月後，雖然自動化的很多東西都不規範和穩定，但是我們總算是取得了一定的效果，就是總共完成了200個左右的bvt用例，而且最重要的是大家的自動化開發能力提升還是比較快的（至少對於我這個門外漢來說，呵呵）；

後來，將這塊的效果展示出去後，上面也比較認可，於是開始給我們一些人力和時間去投入做這塊的工作，這樣就正式開始了整個自動化的持續投入和產出，筆者也有幸正式成為自動化開發小組的一員（50%左右的時間去做自動化的開發工作），這個過程差不多持續了10個月左右的時間，直到自己開始去嘗試新的方向；雖然說1年左右的時間對於寫代碼還沒有掌握的很深，但是筆者認為已經能夠完全勝任該工作了;更重要的是，自己的思想也發生了很大的變化（過程中看了很多測試人員的職業發展相關的文章）；

第三篇：測試分析篇

到這裡，個人認為自己的思想轉變最大的一點就是：作為一個測試人員，我們的目的是什麼？怎樣將我們的價值最大化？而不是僅僅去想如何去提高自己的技術；另外就是感觸比較深的就是解決問題的能力比技術本身更重要（當然，好的技術能夠更快的解決問題）；後來偶爾跟老大溝通，如何去更好的去提高產品的質量？老大也正在想這個問題，於是開始去涉及測試分析相關的工作了（個人覺得主動性應該是一個好的測試人員很重要的技能）。

這個時候開始，工作重點開始轉向產品的業務和整體框架學習，模塊的測試用例設計評審，參與整個項目的測試重點和難點的分析，過程中對開發的bug改動分析，協助開發去排查和定位問題，過程中測試質量分析等等。在這些過程中，筆者才真正感覺到，一個測試工程師要做好還真的是很不容易，需要非常好的分析和歸納抽象能力，這樣才能將一些共性的地方提煉出來，形成一些比較通用的方法。

過程中一些具體的方法，筆者就不詳述了，畢竟每個人都有自己的方法，但是很重要一點就是要能夠沉住氣，並且真的願意持續做下去。筆者經過一年的時間，就產出了一份從幾個維度來評估產品質量的方法以及一份探索性測試的方法（要想在這塊有進步，產出是一份很重要的評估標準）。

第四篇：技術改進篇

當然，這裡並不是說測試分析的工作就沒有開始做了（識別當前項目的測試重點和難點的工作始終貫穿著我的整個工作，而技術改進的來源也是基於整個分析的過程）。

完成整個產品的業務邏輯分析後，再加上從網上看到的一些基於代碼的測試經驗，就開始思考，如何將測試從黒盒向灰盒以及白盒的方向去擴展，從而能夠更早期多發現問題，而不是等到開發提交測試後再去覆蓋測試。這裡主要做了兩個主要的改進；

1、分層測試：因為產品的一個模塊特點是基於apache＋php＋mysql的模型，所以比較適合分層的方式，將底層資料庫介面操作提取出來，直接通過構造數據的方式來覆蓋到；而php層則開始引入介面測試（其實已經類似單元測試了），過程中不斷的跟開發進行溝通和確認，開發每完成一個模塊後，我們馬上就能覆蓋到，至於UI的，因為成本太高，而且測試起來相對比較簡單，就直接計劃等全部完成轉系統後再覆蓋測試。這種方式確實大大的提升了整個模塊的質量，轉系統測試後基本沒有發現下層的bug。

2、完成了一份問題的排查和定位文檔，這樣能夠讓測試人員直接根據裡面的文檔就能定位到問題的大概原因，大大減少了開發自己排查問題的時間，得到了開發的一致認可，通過一段時間的積累後，也大大提高了測試人員對於代碼的理解能力。

第五篇：測試模式探索篇

通過前面的幾步，整個測試團隊應該相比最開始的純黒盒測試有了很大的進步，但是感覺測試的工作還是落後開發的工作，於是，期望能夠找到一種新的測試模式（應該說整個開發模式），讓測試的工作能夠更好的跟開發融合在一起。

過程中看了google測試之道裡面的SET的工作，以及測試驅動開發等等一些新的模式，因為一些歷史原因（比如：開發的思維轉變），整個嘗試過程還是相對緩慢的，當前主要是搭建了一套持續集成到環境，然後集成了一些自動化的用例，這樣可以快速的反饋當前質量。

當然，通過以上幾點離測試架構師的路還有很遠，但是整個成長計劃應該是比較清晰了，下面是個人覺得一個測試架構師應該要具備的能力，希望以此自勉；

1、需求分析能力：能夠從客戶到角度去理解需求，甚至能夠直接發現需求存在的問題，去影響PO，來更好的幫助產品成功；另外就是能夠將當前需求細化出來，並且通過細化的需求來思考可能在設計方面存在的問題，提前發現設計的缺陷

2、整個產品架構的理解能力：這個只有達到開發架構師級別，才能更好的去參與整個設計方案的討論，並且發現測試方案的一些缺陷。

3、測試分析能力：能根據產品的特點來分析通過怎樣的方法來更快的保證質量，從而來滿足上面對測試團隊不斷提高要求

4、技術人員培養能力：一個架構師應該說能夠通過自己的影響力來得到一群的技術追隨者，而對這些人的培養也是一個很重要的能力，這樣才能提高整個團隊的技術水平

5、技術規劃能力：技術是不斷的向前發展的，測試技術也不例外，所以，一個好的測試架構師應該要能夠識別後面的技術改進方向，以及一步一步的推進下去

6、技術的廣度：測試架構師需要掌握很多方面的技術，這樣碰到新的問題時，才會有更好的解決思路

謝邀請。首先我表示不明白，為什麼你根本還沒有活到未來就知道自己不行呢？那麼就算你知道你在GIS不行，你又是怎麼得出軟體測試發展很看好呢？難道僅僅是你朋友和你說的？那麼又為何你就願意相信別人說的然後採取去報培訓班這個行動呢？

我希望你先好好考慮這些，請你明白一點，我為人不是刻薄，而是客觀。什麼是客觀，從你給我的信息中，我只能覺得你對自己沒有信心，並且沒有主見罷了。

首先說一下關於自信這個問題，一個人有沒有自信是自己給的，而不是只是嘴上說有自信就有自信的，談到自己的技術，和同一個實驗室出來的同學比，我很自信，他們都沒有我做的深，也沒有我技術好，但是和我的同事比起來，我就又沒有自信了，不談他們工作的年數比我多，我只是單純的認為即使和他們工作相同的年數，我可能也就和他們差不多，要想從技術往上升，沒有七八年我辦不到，我同事辦到的也不會有幾個，我們現在的技術顧問，是在技術崗上幹了七八年之後才升上來的，實事求是的說，我做的不會比他更好，我做不到長時間的和一堆論文和新技術死磕。

我不是那種什麼事情都要撞到的頭破血流才會回頭的人，看到周圍一些同事（不是自己組的）工作七八年以後，最多也就是一個小組長，技術上對自己方向以外的也知之甚少。我本人不屬於笨人，但是也不是一個多聰明的人，我不往自己臉上貼金，我只是一個一般人。從他們身上看到了，我七八年以後的樣子，沒人說他們那樣不好，我只是不喜歡他們那種的工作。

我追求一種成就感和認同感，我個人認為這是一種人高於物質的本能追求。還有自家人知道自家事，我也不可能真的在幹個四五年，發現自己真不合適了，再想轉行，到那個時候也許我都沒有勇氣了。

還有報培訓班的事情，我沒有傻到認為這樣我就能成為架構師，否則我要多天真啊。師傅領進門，修行在個人，培訓班只是讓我對測試行業有一個認識而已，熟悉測試的一些工具和思維，以後能有多大的發展還要看自己。在任何一個行業能突圍出來都是少數人，在測試這一塊我不知道以後自己會不會突圍出來，但是如果現在我不努力去闖一下，以後我也就沒啥勇氣了。也許以後我干測試研發也就那樣了，但是也不會比現在更差。

路都是自己走出來的，誰都不能幫你把自己的路走完。我會聽取朋友的意見，但是絕不會人云亦云，畢竟誰都不能為我的未來買單。

還有測試發展前景的問題，雖然現在最多的就是功能測試，沒什麼技術含量。但是性能測試，安全測試都還是不錯的，考慮到國內軟體的「亞健康」問題，也許測試在以後發展不會特別好，但是也不會太差，而且它一直都被需要著。

其實說了這麼多，我其實是很喜歡測試的，我喜歡那種發現問題，分析問題，量化一個產品，去測試一個產品的極限，評估產品的風險的工作，而不是僅僅局限去開發一個產品中某一小塊功能的，最多和測試有些交流的工作。我想把測試當成我的一份事業來做，而不是僅僅是一份工作。

找自己愛的工作。

否則，找可替代性低的工作。

商品的品控技術的關注度是滯後於商品的生產技術的關注度，老闆眼裡的認識；別想太多，這就是國情；特別是傳統軟體行業；