前言

• 最近看到行業的前輩都分享一些過往的經歷來指導我們這些測試人員，我很尊敬我們的行業前輩，沒有他們在前面鋪路，如今我們這幫年輕的測試人估計還在碰壁或摸著石頭過河，結合前輩們的經驗，作為年輕的測試人也有自己的一些職場，技術以及行業交際的一些總結經驗，今天有些時間，我也寫寫我做為一名90後測試人的一些經歷和看法吧，還是先簡單介紹一下自己，本人15年本科畢業，還有一個月工作就滿兩年了，現在在公司的創新團隊任測試負責人，不過由於個人發展的原因，也很快要和現在的公司說88啦

二、情懷

• 我對軟件測試這個方向早有情懷，早在自己大三的時候，就基本確定之後是做軟件測試工程師，那時候上軟件工程的課程，對軟件質量保證，軟件體系以及工程管理那塊特別上心，老師講完白盒測試的方法和黑盒測試的方法後就自己拿自己寫過的代碼開刀，漸漸發現自己對軟件測試產生了興趣，雖然也由於自己的代碼功底可能比較水，加上強迫癥喜歡找茬的性格，感覺就是兩情相悅，後面自己去學一些性能和自動化測試的入門技術，還記得我的第一個自動化工具是按鍵精靈 ，記得是11年天貓雙11來臨之際的搶紅包，我就是用按鍵精靈搶了足足55塊的紅包，結果天貓第二年就搞了一只到處跑的貓就沒再搶了，那時候就體會到自動化對效率的提高的重要性，所以後面不管實習，還是後面找工作也好，清一色軟件測試工程師，後面也就到了現在的公司，也是走進社會的第一家公司，開始軟件測試的人生道路

三、懵懂

• 軟件測試，可能至今為止，很多人還是認為就是找bug，不過估計這個現象現在應該有所改善了吧，可能是本身對軟件測試有所理解，所以工作的態度和方式也有所不同，剛來到公司的時候，其實還真的挺懵懂的，來到一個創新團隊，產品是新產品，也意味著業務也是新的，當時我是做ios端的手工測試，就是點點點，當時我還對ios的操作系統不熟，所以一開始的時候也遇到很多坑，比如把當時唯一一臺ios7的設備升級了，大家都知道蘋果系統升級的坑，環境的多樣性沒了，我能理解當時的老大他也是想我能多接觸自己之前沒接觸過的地方，一開始我也很刻苦，做移動端的測試，也做web端的測試，甚至後面桌面端的測試和後臺的測試也做了，基本上把我們產品各個端都玩了一輪，但是總是點點點，效率真的很低，產品和團隊都是新的，什麽自動化等等都沒有，所以當時懵懂的我也意識到我可能可以為團隊帶來一些改變，百廢待興，也意味著滿地都是機會

四、清晰

• 有了上面的意識，我明白我自己要做什麽，機會是有，但沒準備不行，好，我自己比較向往做自動化測試，那就學自動化，一開始也是亂學一通，之前用按鍵精靈也可錄制回放，其實也是自動化的一種，但太低級了，我要進步，要學更高級的技術，後面就自己上testerhome，上推酷等技術網站搜貼自學selenium，同時由於自己的產品裏面有移動端，那時候看大家都是用appium，那就學最常用的就好，那時我還沒學python，但是學自動化的時候我刻意用python來寫自動化腳本，這種並行學習的效果非常高效，不僅讓我學習到自動化測試的技術，同時也可以學習新的語言，從那時候開始，基本上每天下班回家之後就盯著電腦學習，寫腳本，學語言，堅持了一個月之後，把最常用的一些模式都學了，像page object，關鍵字驅動，數據驅動等，後面想起總是有人說測試框架，測試工具等，有一天晚上自己就刻意搜了一下測試框架這個詞，大家猜一下第一個彈出來的是什麽，估計有看過我之前寫的帖子的朋友就一下子知道了，就是以關鍵字驅動、易學易用著稱的RobotFramework（後文簡稱RF），其實我那天晚上還看了Cucumber等其他測試框架，那我為什麽會選擇學RF，如果我是只為自己學技術的話，我啥都可以學，但是我的出發點就是想為團隊帶來點改變的，我們當時的測試團隊，除了老大之外幾乎沒有一個人會敲代碼，如果要是以後上自動化的時候大家一起玩的話直接敲代碼的學習成本就高了， 互聯網時代要快，有些事是等不起的，RF對於一個不會敲代碼的人來說其實也很容易駕馭，那好，就選它了，後面就專門學習RF和python相關的技術，包括jenkins，每天和我老大保持溝通，讓他知道我的學習情況，同時我也經常盯著我老大做事，看到他在某些方面需要支持，自己當時能力所及的，我會第一個跳出來說讓我來或者是我幫忙，像有一次老大開始嘗試做性能測試，他寫了一個loadrunner的腳本，跑了我們項目的第一次性能測試，由於自己的好奇心，我就向我老大請求性能測試就讓我做，雖然以前接觸過loadrunner，但是也結合業務結合場景來做性能測試的話還真沒接觸過，我就幫請教我老大怎麽做性能測試，自己又在網上搜貼看看一些具體的場景設計和loadrunner工具的具體使用，所以，從那次之後，我們產品的性能測試就我包辦了，看起來事情多了，但這是很重要的經驗，經驗也是要看機會拿的，錯過了，或許其他成員會搶去，那我就失去了做性能測試的機會，能力也就不能得到提高，所以漸漸地也得到老大的信任和團隊部分成員的認可，自己的能力和對工作的動力也漸漸提高，就這種狀態持續到16年初

五、進擊

• 16年過完年回來，我們的產品已經開始趨於穩定，是時候做自動化測試了，由於有前面的積累和溝通，我們老大向我們總監推薦了我包辦我們產品的自動化測試，包括移動端，web端，桌面端以及後臺，當時我收到這個任務的時候也是比較慌的，畢竟之前完全沒有實戰經驗，這次也沒人帶，而且我還要帶上2個測試的小夥伴一起做，我當時還工作不滿一年，心裏真的是慌到不行，但後面冷靜下來之後思考，這就是活生生的機會，之前自己積累的知識和技術，不就是為了今天嗎，為什麽不試試，成功了，那團隊真的讓我帶來改變了，失敗，對我來說也是很重要的經驗，不做白不做，狠下心來做，所以我就將之前的想法開始一步步實現了，我就將robotframework+jenkins+支撐庫的方案投入到我們項目做自動化測試，也就是有了我在testerhome的第一篇帖子RF+Jenkins測試框架實踐，在將方案投入項目之前，我還專門給測試團隊的成員開了一次針對框架的也是我在公司的第一次培訓，為何會說起培訓，可能也是培訓，讓我意識到培訓的分享者會比接受者收獲的更多，我就是從第一次培訓當中理解到什麽叫做解決方案，也總結出後面我在測試團隊經常說的一句：不要為了用工具而學工具，要為了實現一套解決方案來解決問題而學工具，是的，我為什麽要學RF，它能快點應用到項目，同時也解決了測試團隊上手的問題，為什麽要學jenkins，就是為了能把一套持續集成的流程串通起來，支撐產品的快速叠代，我就是為了解決問題來學工具的，也就是從那次開始，我的技術和職場道路開始走上進擊的道路，後面秉持著為了解決問題來學工具的心，也做了後面的一些技術方案來解決產品項目中測試的一些需求和問題，大家看我的帖子也可以了解到具體做了些什麽，後面也陸陸續續地幫團隊解決一些溝通和協調的問題，像帶實習生，前後端溝通，力所能及，即可為之，自己的主動性和執行力也被鍛煉起來，反正什麽都試試，年輕人，多學一些沒虧

六、升華

• 天道酬勤，機會都是留給有準備的人的。16年7月份，我老大提離職了，產品總監第一時間就是讓我接手，慌張的心又開始跳動，我才工作參加一年，就要做測試老大呢？我能不能做到，團隊中還有比我更有經驗的小夥伴，為何是我？或許我真的是有備而來的，還是那句，有機會幹嘛不試，跳動的心沈靜下來，好，我來，就是那時刻，我開始擔任團隊的測試老大
• 可以說我是個小白老大，之前一點管理經驗都沒有，不過以前在大學當學生幹部的時候或多或少還是有一些作用的，做leader的第一件事，調整團隊的測試工作方式，實現所謂的端到端測試（這是我理解的端到端，可能和其他朋友不一樣），就是一個人負責一個端的所有方面的測試工作，比如自動化，性能，專項，甚至是測試工具的開發，果然這效果還是每明顯的，一個月過去，產品端的質量真的有所提高，同時團隊成員針對端的能力也提高起來，這是因為以前大家做的事情都太亂了，還不如先專註做好一個方向，再做其他的，所以就想到了用端到端的方式，在這期間，我們把web端，ios端和android端的自動化測試推了起來，每一端基本都是獨立一人完成的，就這過程，團隊的成員熟悉了怎麽用RF的框架，後面我還強調大家要學原理，還分析過RF的執行原理和分層結構，這樣大家不僅能力提升了，產品的自動化測試也得到推進，鞏固了測試的環節，顯然，持續一段時間，產品的質量能得到提升，尤其是web端，以前季度bug數會上100多的，後面就50多，而且以前每個版本測試周期為一周，後面2到3天就行了，這都是效率的提高，成員得到升華，質量得到保證，這是測試工作的最優狀態
• 第二件事，其實以前做的都只能叫做產品測試，還沒到達產品質量保證的高度，項目發展到一定程度，有些事情還是要管起來的，一開始是什麽情況，測試團隊是在研發提包給我們的時候，我們才知道要測什麽，這是不對的，版本管理無任何秩序，什麽時候上線什麽版都不清楚，比如上線和發版的定義都區分不了，於是，我聯合測試團隊的成員和產品經理，研發等開始制定產品的質量流程，像需求評審、用例評審流程，這看起來有點不像互聯網敏捷團隊的模式，但我們是以一種輕便地方式來實現，產品主大局，產品需求一般是闡述大概要做什麽，但很容易會漏掉細節，誰補，測試人員，不是總說測試比產品經理更了解業務嗎，所以用例評審的時候我們就可以體現細節的問題，用例編寫和研發實現的周期調整為同期，測試左移，用例編寫完成後用例評審，我們也不是說一條條用例地看，對於敏捷，快速叠代，這不是個好辦法，那用什麽，xmind是個好工具，產品經理能用來列需求，測試也就能用來列測試關註點，測試關註點覆蓋產品需求路徑，同時提出產品需求未描述清楚的地方，並且通過易用性，功能性，可靠性等一些方法也提出關註的細節，這樣既能補全需求，也能前提告之研發哪裏有坑，同時也鞏固測試的一個關註點和範圍，一舉多得，可能這說成用例評審有點怪，叫測試關註點評審更好，隨便，為解決問題而設計實行適當的方案或流程就好，與此同時，那為產品作版本灰度上線方案，設計灰度的範圍以及要關註的功能，同時版本上線之後，做好和客服的對接，做好線上問題收集和整理，還有很多，像版本號管理，提測規範，上線流程等，雖然作為測試負責人，但在產品質量保證的範圍下，事無巨細，從需求到研發到測試到上線運營，每一塊都需要保證
• 第三件事，缺陷管理，每個測試人員提bug的方法方式都不一樣，甚至bug描述方式都不一致，研發經常和我吐槽，提bug連個圖都沒有，測試環境沒有，甚至沒有測試賬號，然後我們研發環境又沒重現，那要怎麽修bug，還有的是，客戶經常反饋的bug範圍和我們測試發現bug的範圍相差深遠，說明兩點：1、測試重點沒有貼近客戶，我們所認為的重點模塊不是客戶的常用模塊，2、我們提bug的質量沒有保證，加大了溝通成本，這個也是要解決的問題，怎麽做，我們先把產品的各個端的功能模塊分類好，作為bug的功能分類標簽，明確模塊優先級，制定bug優先級權重，同時標明好無效bug和線上bug作為測試人員的把控質量的一個評價指標，舉個例子：以前我們總是覺得我們的溝通模塊很重要，一般一個版本可以在溝通模塊測出25個bug，然後協同模塊才5個bug，結果上線之後客戶反饋的問題或建議全是協同模塊，溝通模塊沒幾個，就是證明，客戶目前多數是用協同模塊，但我們卻把工作量放在溝通模塊，那就不太對了，所以結合線上bug的數據作為一個測試重點的一個標準，同時還有就是我們平時在當前版本結束之後，對功能模塊所對應的bug數進行分析統計，做好缺陷趨勢分析和風險預估，那下一個版本的測試範圍和重點就出來的，這個是提高效率的方法，同時我們統一了bug的模板，每個人的格式都是一致的，研發看起來舒服，bug自然也修得暢快，我們回歸的時候也舒服，一舉多得
• 還有很多很多，我作為測試負責人之後，的確是做到了為團隊帶來了一些改變，這也是我本來努力的方向，後面在團隊裏面堅持每月至少一分享的習慣，厲害的時候，一個星期4次，但是我們都不是瞎培訓瞎學，脫離業務的技術方案都是炫技，華而不實，我們培訓都是為了解決當前工作上遇到的問題的，都是學最能解決問題的技術方案，而且我一直很崇尚圓桌型的培訓，雖然有主講人，但每位小夥伴在培訓之前都或多或少去了解培訓主題涉及的內容，之後培訓的時候大家一起提出不同的看法和見解，經過自己思考的接受學習也是有效，大家共同進步，這有什麽效果呢，說點實在的，前文提到本來測試團隊幾乎沒人會敲代碼，後面16年底17年初，都已經會獨立寫一個測試框架和app專項測試工具了，而且這過程中還不斷引入像anyproxy、docker，locust等一些技術方案到團隊，也說起分享培訓，我自己也是活躍在各大測試技術群裏面，以前也是到處問人，到現在到處幫助別人解決問題，還是回到分享者才是培訓的最大收益者，自己不懂的，還會刻意去搜貼結合自己的經驗得出解決辦法，空余的時間也會去參加一些測試沙龍，和其他同行保持交流，了解行業的發展動態，自然而然，接觸的知識和人也多了，漸漸地學會了洞悉技術發展方向，能夠迅速地了解和學習適應時代的技術，這也是作為一個測試人員的嗅覺，懂得變，學會如何進步

七、沈澱

• 質量保證分為3大塊，產品質量保證，交付質量保證，運營質量保證，只有這三大塊做好，產品的價值實現才會得以保證，但是有多少人是理解這三塊是要做什麽的，所以我就說有部分測試人員對自己的要求不高，測試的價值是可以再提升的，看看上面的三塊，就知道測試人員的重要性，但又有多少人做到
• 我在年初的時候面試了很多測試人員，其中還面試了幾位工作超過10年的前輩，這裏不是抹黑，的確有一個現象，我面試那位前輩，工作10年，之前也是測試負責人，自己是偏向自動化測試的，好，我問他怎麽做移動端的自動化測試，他也是知道用appium+語言這個方式去做，我問他是怎麽設計一個自動化測試方案去解決自動化的問題的，就一直和我說工具，我問他有用什麽設計模式去提高代碼的可維護性和執行效率的時候，不懂，好，我問appium是怎麽和手機通訊來執行自動化測試的，也不懂，其實都沒問題，最後讓我直接否決掉的原因是，我問他是怎麽管理測試環境的，他說測試環境是研發和運維搭的，測試不懂得搭，算了，我聊不下去了，我問原理，是因為作為測試負責人，也是一個帶人的角色，你自己都不了解清楚的東西，在團隊裏面實現，團隊的成員也不會了解清楚的，估計解決問題的程度也不高，感覺就是在項目裏面用用而已，而且連最基本的測試環境都給研發或運維做，那測試做什麽，怪不得別人說測試低端的，東西不僅要學會，還要學精，上面的情況違背了力所能及即可為的原則，而且都不僅是能及，是基本要求。
• 第二記得應該是工作4、5年的，問測試策略和測試計劃的區別和作用，和我說沒做過測試計劃和測試策略，還有個更離譜的，簡歷裏面寫著自己會性能測試場景設計，面試的時候給個案例給他做，寫不出來，什麽是業務場景設計，什麽是數值預估和瓶頸分析都不太清楚，我直接問他做過多大的並發：50人，我馬上跪了
• 幾乎沒有人擁有我剛才所說的嗅覺，最簡單，現在那麽火的docker，我面試的所有應聘者居然沒人知道是什麽來的，就那麽一段時間，我患上了面試恐懼癥，簡稱“面癱”，怎麽做測試都不太清楚，不用談產品質量保證，更不用說三大質量保證，別人總說測試入門低，在團隊地位不高，我一開始也不太信，因為我們測試組在團隊裏面還是很有發聲權的，因為我們抓緊質量，那些還是在點點點的，總認為自己找過多少bug很牛，學過多少工具很牛，到頭來就導致認為測試很低端，話也說回來，我在面別人的過程中通過交流也學了很多知識和經驗，同時我有個面試習慣，我會專門挑應聘者的問題來給他們提供一些建議和看法，就算後面面試失敗了，我起碼也不會讓你白來一趟，更狠的是，我舉辦過一場特色培訓，我讓我們測試團隊的成員做面試官來面試我，面到我說不出話為止，面試別人其實對自己來說也是個總結的過程，你在問別人之前起碼你要了解清楚你要問的東西的原理，那才會踏實，那就是一個提高的好辦法，所以我就讓我們團隊的小夥伴面我了，果然有效，她們當時還準備得挺充足的，我有幾個時刻就差點說不話來，哈哈，我當時也感覺到大家已經明顯進步很多了
• 時代變了，僅僅是找bug牛已經不夠了，所以後面每天一句：不要為了用工具學工具，要為了解決問題而學，還有要做質量保證，不僅僅是測試，bug是要預防，不是找，這讓我更加鞏固上文所提到的一些看法，也是在這段時間，我也不斷地再深化提升自己，把之前去年做過的技術方案通過理解原理和結合業務，優化了幾個技術方案並在團隊裏面使用，能解決問題，為團隊帶來好的改變，自然也會收到回報，除了能力的提升，地位的提升也會有的，今年3月我也被提拔為資深工程師級別，這些都是要靠積累的，要做上面的事情，我基本上每天只睡6小時，每天都在想盡一切辦法怎麽才能解決問題，提升質量，提高效率。天道酬勤

八、最後說幾句

• 人往高處走，自身的發展也很重要，也由於個人發展和家庭的原因，很快和現在的公司說88了，來公司兩年，讓我從一個測試新人蛻變，很感謝現在的團隊和公司給我那麽多機會和條件，讓我得以發展起來，同時也通過分享我過往的經歷，希望對測試新人們有一些小幫助，同時也歡迎前輩們繼續給我還有我們這一輩測試新人指導，我們一起創造測試界的光明和未來
• 一個成功的團隊少不了這三種角色，第一:把控方向的人，一般是產品負責人，團隊的生死幾乎就看他了，第二:團隊第一生產力，一般就是架構師，技術最牛的那位，有方向，有策略，還要看能不能實現，第三:據說外國對他有個稱號叫master，他懂技術，懂業務，懂流程，根本就是一名全棧人員，他了解團隊的優勢和劣勢，從而能在制定產品策略，技術方案以及生產過程提出建議和改進方法加以保證，給團隊發展保駕護航，他是團隊的消防員和安保員，測試人員的最終發展方向應該就是這個團隊第三人了，個人看法，大家一起加油，謝謝

畢業兩年做到測試經理的經歷總結