需要提前說明下的是到目前爲止，筆者還沒有達到一個合格的測試架構師的標準，但是應該是已經走在這條路上了，所以想通過自己的成長經歷給其他想朝這個方向發展的同學有點啓發，同時也期望能夠拋磚引玉；
先說說筆者的初始條件（應該很多人看了都會有更多的自信吧）：一個普通本科學校，雖然是科班出身，但是除了大學的課程設計以及其他需要寫代碼的功課外，基本上沒有去主動寫過代碼，更別說去研究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、技術的廣度：測試架構師需要掌握很多方面的技術，這樣碰到新的問題時，纔會有更好的解決思路
其他歡迎大家補充...
當然，筆者距離上面的目標還是有很大的差距，但是總算是看到目標和希望了，願廣大同胞們也能夠得到一些啓發。
PS：該文章來源微信公衆號：軟件測試人生 ，大家可以直接通過掃描下面的二維碼來關注該公衆號，瞭解更多關於軟件測試相關的信息
