來源：Jerry Gao
來淘寶測試部三年了，也就是意味著我進入測試行業也快到六年的時間了。或多或少也有自己的一些感悟，而且不同階段的感悟會一樣。自己在淘寶的每一年的紀念日的時候都會寫篇個人總結來慰問下自己。
關於這次在淘三年的內容，我自己也是思索了好久，不知道要寫什麼，測試感悟的、測試技術的、測試方法的各個方面都想寫，又都不想寫。
都想寫的理由就是本身測試行業就是個比較工程和系統性的行業，自然有自己的一些領域知識，說太少了，怕有些人真的以為測試就是點點滑鼠而已。
都不想寫的理由就是怕說太多了，就複雜了，就更讓人摸不著頭腦了；而且很多觀點和事情不是說說就能明白的，只有自己親身經歷了才有深刻的體會。也所謂 如人飲水，冷暖自知。
最後還是決定好好回顧下這幾年的測試想法，因為這幾年測試行業發生了很大的變化，不僅僅是敏捷測試、新測試技術、開發自測等等，都會影響我自己個人在測試行業的發展和能力的提升。真的怕自己走過彎路，所以需要不停的反省自己，這個能力是不是必須的、這個技術是不是應該需要了解的等等。
介於北京的崔啟亮的建議，還是確定了自己的部分寫作思路，也大致分成幾個部分吧。
遇到的困難以及解決辦法
第一個三年：
在06年畢業後的測試三年中，遇到了一些基礎困難，幸好自己在觀察和學習的同時，很快就能解決這些問題。 由於之前寫過一個blog介紹了部分問題，大家可以參考下：http://blog.sina.com.cn/s/blog_6cf812be0100ngbw.html
但是這邊我還想發表下自己的觀點，是針對於黑盒測試方法來說的。 記得幾天前討論是否需要QA的時候，段念 寫個一篇blog來說明 一個正常的工程師 都能在一個下午學會和理解大部分的黑盒測試方法。 對此觀點，我是不敢苟同的，這就討論到這些黑盒測試方法的深度的問題了。
（0）學會和理解測試方法的使用步驟是很簡單的，但是真正的在專案需求中應用起來可不是一朝一夕的。這就好比給你一張撲克一樣，高手就能拿它殺人，一般的人能做到什麼程度呢。 這個也很像有些人能發現你不能發現的bug一樣。至於原因有很多，具體看在淘兩年的blog。
（1）談談我自己的感想吧，我自己在工作前兩年也是認為這個黑盒測試方法一下午就可以學會的，找幾個例子試著使用下，感覺自己掌握到這些黑盒測試方法，但是後來我看過很多這些測試方法的背景以及應用的注意點後。我發現自己真的是瞭解了一些皮毛，沒有深入的瞭解。對於個專案需求，如何快速且完整的應用這些黑盒測試方法設計出不多不少的測試用例，這個需要的經驗的積累，也就是你測試價值的核心體現。
（2）去年在成都MPD時，很多學員說自己都說自己是工作2-3年的人，已經遇到瓶頸了，感覺測試很單調和無味。我給的建議其實很簡單，那就是真正的理解和掌握所有的黑盒測試方法。怎麼來驗證呢，我自己就是這樣：給你一個白板，你能把所有測試方法的5W2H(What、Why、When、Where、Who、How、How Much)都能非常清晰明瞭的演講出來，記住是不需要參考ppt或其他資料的情況下。
就像火影裡面的鳴人一樣，他只會螺旋丸這個核心的攻擊忍術，但是在擴充套件其他忍術之前，他會把這個忍術的深度發揮到機制，從而研究出威力更強的超大螺旋丸、超大玉螺旋丸、風遁螺旋丸等等。
在淘寶的這幾年也越到了很多的困惑，而且隨著年齡的成長，考慮的問題就會越來越猶豫，需要權衡利益的去提升自己和學習。主要考慮的就是測試的深度和廣度問題。自己畢竟在測試行業待了那麼長時間了，周圍其他測試同仁的發展、國外測試行業的發展、自身利益和環境的影響等等，這些都會影響自己對某些測試問題存在個人極端的想法。
個人認為了解一個人測試的水平，需要考慮其測試行業中的深度和廣度的知識。
測試的廣度：主要就是測試相關型別的瞭解。具體包括如下：需求分析、測試流程、測試管理、開發流程、開發技術、測試模型、基礎測試方法和測試技術、功能測試、效能測試、自動化測試（頁面自動化、API）、安全測試、可靠性測試、易用性測試、穩定性測試，探索式測試（ET）、基於風險的測試（RBT）、相容性測試等等。
測試的深度：也就是對廣度說到的某一項你瞭解到的深度。當然這個深度，每個人都有自己的定位和看法，關鍵還是看自己是如何來對待的，這邊我說下自己對自動化測試的深度的看法吧。
基礎：瞭解簡單的測試指令碼/程式碼的編寫，瞭解不完整的測試框架架構。
進階一：快速編寫測試指令碼/程式碼，解決部分程式碼編寫的問題，瞭解完整的測試框架架構。
進階二：理解和了解自動化測試設計，自動化測試在專案中的融入和實施策略問題，瞭解其他類似的測試工具，並能做出正確的判斷。
進階三：快速編寫合理的測試指令碼/程式碼（體現在測試設計和測試資料設計上），指導他人編寫可維護性的測試指令碼，深入瞭解測試框架的實現細節和開發技術。
高階：整體上來解決自動化測試效率和價值的問題，找到測試框架的問題或困難，並能解決它，或提出有效的建議，深入瞭解其他類似測試框架或工具，並瞭解其功能技術細節。提升測試框架的應用性和實效性和效率。
就我個人而言，我一直也在擴大自己的測試廣度，也在提升自己的測試深度。在淘寶的這幾年，淘寶測試部的發展非常的快速，自己也從中學到了很多，我也慶幸自己在來淘寶之前就把某些的深度問題給解決了，從而可以提高自己其他的廣度。
一開始來淘寶，就選擇 自動化測試這個廣度，並在頁面自動化測試和API介面測試方向 提升自己的深度（這是個長期的過程）。另外也選擇了相容性測試這個 廣度，不過這個進展筆記緩慢。接著根據自己的方向和優勢，選擇了 探索式測試 這個廣度，從而在這個領域學習到了更多的知識，從而影響其他廣度的選擇。接著不停的提升自己在需求分析、測試流程、測試模型、效能測試方面的深度，也會接觸安全測試這個廣度等。 最近選擇了 前端測試和無線測試領域，這也是擴大自己的廣度，不斷的學習和了解該領域的測試特點和工具。
給大家的建議是根據公司測試技術的發展策略，有針對性的選擇某幾個測試廣度，然後在其上提升自己的深度。你的測試能力就是 你的廣度 * 你的深度。
不管我去擴大其他的測試廣度，有幾個測試領域我是必須要求自己，也強烈建議其他測試同仁需要達到的較高深度的。也就是我自己一直深信的測試理念，我是一個測試工程師，你可以說我level不高，考慮不到高層想要的東西。但是我是會追求自己所相信的，那就是測試設計能力：也就是不同測試型別的測試方法的應用能力。不僅僅是有這個能力，而是 更快、更準、更狠的 測試設計。
個人測試感悟
0. 時刻牢記自己的狀態和目標
你需要確定你目前所在的廣度有哪些，和深度是怎麼樣的。根據自己的特點和測試信念和公司情況，選擇深度和廣度，然後指定計劃和目標，執行下去。這個可以整體上解決 你的瓶頸問題。
1. 開發和測試是亦敵亦友的關係
以前一個測試同仁說過，沒有和開發吵過架的測試不是一個好測試。我雖然不是很認可，但是他還是有一定的道理，本身開發和測試的立場和思維邏輯就不一樣，短時間較難改變，那這裡就需要表現測試的價值。但是測試需要開發的幫助才能更好的理解設計和程式碼，才能更好的設計用例，才能更好的保證質量，才能更好的提升自己的技能。這是個平衡，測試和開發走的太近不好，走的太遠也不好。不要說開發和測試共享質量、共同承擔責任啥的，目前國內是這樣，以後可能會不一樣。
2. 測試需求分析時多問為什麼
需求評審和需求分析，對應大多數測試同仁來說是個不易提高的地方，也是很難傳承經驗的地方，這裡還是需要去學習一些需求分析方法，總體上就是建議你凡是多問問什麼、為啥會這樣、還有沒有更好的。
3. 驗證bug時多看看code change
記得在華為和微軟Onsite測試的時候，就討論過了很多次，我還是很喜歡在驗證bug時看code change。看不懂的地方直接問開發，不斷的提升自己在程式碼方面的經驗和敏感度，那段時間真的很快樂。後來我還會參與bug fix，這些都是多看code change的後期提升，讓自己更加有價值，不僅僅能發現bug，還能fix bug。
4. 持續優化你的測試設計
不管是專案還是產品，你只要是負責人，一定要保證該產品或專案的測試設計是最新狀態，並且在不同的資訊輸入期間都有新版本的測試設計產出，特別是測試執行後期，那些未通過測試用例發現bug的用例，一定要保證測試設計的時效性和完整性和最新性。
5. 沒事多看看其他人提的bug
線下bug場景和線上故障的場景都是非常好的案例，不是單純的由某個黑盒測試方法能發現的，所以我們需要關注這些場景案例，總結起來，並轉換為自己所用。這個經驗積累不是那麼容易看出來，而且經驗也不是那麼容易show出來，但是不要低估它，關鍵時刻就靠他了。
6. 控制自動化和它的價值
這裡讓大家理解自動化測試的價值和目的是沒有任何問題，關鍵是控制它。根據自己產品的特點要找到一個平衡點，不要盲目的自動化。一定要控制手工測試用例、自動化測試用例的比例（UI級別、API級別的）。不要讓它成為你的累贅，不要讓你每次的指令碼排查成為慣例現象。
7. 堅持自己選擇的測試信念
之前很早就提到過test school,建議每個人根據自己的個人信仰和特點來選擇某個test school。因為一旦你選擇是某個school的人物，你就會學習這個school的很多測試理念和測試想法，堅信它們並在自己的團隊中應用起來。我個人就是屬於context-driven school。
8. 使用者體驗和程式碼完美性是王道
很多人都應該說過測試人員測試就是應該站在使用者角度去思考問題，多去考慮使用者體驗，的確這是個能幫助測試人員研究使用者和提升易用性測試的一個途徑，另外可以多看看使用者提供的反饋意見，完善自己的測試思路和需求分析思路。另外一點就是，我們很多bug開發都會說使用者不會這麼去做，幾乎不可能的，所以這個bug是invalid的。我們不僅僅是考慮使用者應該做什麼，我們還要考慮使用者不應該做什麼，有可能做什麼，能夠做什麼。這些都是不一樣的，多從程式碼健壯性和容錯性考慮程式碼的完美性。
9. 享受測試帶來的一切
不管你是畢業就從事測試工作，還是先幹開發再轉測試，不管你做測試的原因和動機是什麼，個人建議你只要還在測試行業，試著去發現測試的美，不要人云亦云，也不要固步自封。測試會讓你開心、會讓你單調、會讓你憤怒、會讓你痛苦、會讓你瘋狂、會讓你無味。不要擔心自己會不會失業或沒有價值，不管怎樣，提升自己的廣度和深度，逐步的享受測試帶來的一切。
測試的發展趨勢和職業發展
看這幾年，國內的測試發展還是不錯的。不過相比較國外來說，我還是比較悲觀的，測試和開發一樣還是至少落後於國外10年。我們這幾年在不停的學習和實踐自動化測試、探索式測試、敏捷測試、基於模型的測試等等。很多國外走過的彎路，國內的我們還是在走，這似乎就是歷史的輪轉。
個人認為測試的多元化發展還是一個主要的方向，也就是測試本身所提供的價值。測試手段的多樣性和深度是必須要經過的環節。個人認為沒有一到兩種測試方法、技術、手段能夠解決被測產品的所有測試任務，我們需要不斷的從不同角度去測試，去工具SUT，最近流行的分層測試、敏捷測試其實都是基於這個認可。對於持續整合，個人認為只要自動化測試不消失，事實上他的價值還是不錯的，也應該不會出現這個情況，那持續整合就還是基礎的測試底層框架搭建。只是這個持續整合的作用，我們現在還只用到了不到五成，接下來大家應該會在這方面有所突破，不過這方面還是有難度的，且不好考核。
另外個就是提升開發自測，提升開發自測的質量對測試來說，實在是太重要了，但是不意味著測試可以掉以輕心。目前的開發自測狀況是開發人員發現20%的bug後，到時間了，開始提測。測試這邊發現70%的bug，到時間了，該上線了。那麼開發自測的目標就是開發人員發現60%的bug，fix後，提測。測試這邊發現35%的bug，fix後上線。表面上看總體上只多發現了5%的bug，而測試發現bug也減少了，但是從開發整體進度和專案進度上來說，可是個非常大的進步，絕對的快速釋出了，測試人力成本也會減少較多。
由於答應了某位測試同仁，這裡大致說下探索式測試的發展。個人是在09年底開始瞭解ET，目前淘寶在ET方面並沒有大範圍的展開，還是在某些測試組、某些專案實施了不同形式的ET方式（部分專案是Freestyle形式，部分是ET輔助或bug bash的，主要是我這邊來把控的，我個人時間有限，你懂的），至於結果，仁者見仁智者見智。大家也可以我個人其他的blog裡面看到，至於工具使用的是Freemind和Session tester。個人認為ET應該是未來測試發展的某個重要的方向，幾乎可以和自動化測試齊步，特別在ROI上，自動化測試肯定會低於ET的，但是事物都有兩面性，ET必然有它不完整、不成熟的階段，這個階段需要大家一起去完善，一起去堅持自己的測試信念。
關於職業發展，我是想走技術的，但是我自己也迷茫了很多次，做到什麼樣的程度呢，我的測試廣度和深度到底要達到什麼樣的程度呢？公司需要我這個測試廣度嗎？公司需要我這個測試廣度下面的這個深度嗎？是不是還需要再深入一點呢？我心裡有很多這樣的迷惘。比如開發技術就是一個矛盾點，這個深度真的不是那麼容易把握的，大家都知道了解開發知識、懂開發知識對做好測試是有益的，但是到底應該懂得啥程度呢，能帶來多大的好處呢，啥情況下呢，開發自己都痛苦的學來學去，測試真的一定要跟著後面嗎？這個精力我是否應該多瞭解下相容性測試呢？是不是應該多瞭解下RBT呢？我心裡確實有很多的矛盾，很多次我都不知道怎麼過來的。不過我還是有自己的決定，我會盡量地去尋找自己的平衡，時刻的去review自己的狀態，自己的這個測試廣度達到了什麼樣的深度了，是不是可以暫停下，去提升下其他測試廣度的深度了。
想走管理的，就是測試管理了，多考慮一線測試工程師的生活，他們是如何進行測試的，他們遇到什麼問題，解決問題才是王道，解決他們的痛苦，提升他們的效率，讓大家快速的幹完，可以去做些自己感興趣的事情。另外就是多考慮下國外的測試新技術，有些不一定現在有用，以後呢，做些儲備是必要的，就像軍隊一樣，平時沒事做，關鍵還要用的，特別是特種部隊了，各方面要求都很高，做這些儲備更需要管理層的覺悟和想法了。
想走技術的路線，就是盡最大的努力提升開發技術，另外就是多擴充套件自己的測試廣度吧，爭取在幾個核心的測試廣度上達到最深的深度，成為真正的測試專家。
另外就是可以考慮走產品經理或其他路線的，比如SQA等。另外提一下，我也喜歡叫tester，不喜歡被叫QA。
廢話說的有點多，期望對大家有幫助，大家有任何不同的觀點，歡迎提出。