測試十年-我難以逾越的困惑和痛苦和思考

高翔的測試發表於2017-11-24
很久沒寫文章了，之前的測試三年，測試六年都寫了blog來記錄自己的測試生涯和思考，這次測試10年肯定不會錯過了，當然了，YY比較多，乾貨也不多，反正紀念下，或許我很難寫測試15年的文章了。大家有任何問題，歡迎討論，歡迎吐槽。
 
— 10年測試的困惑和痛苦
轉眼間參加工作10年了，也就是意味著幹軟體測試10年了，經歷過3家公司，都有一些感悟，也難以相信我能在淘寶堅持了這麼久，7年了，人家都說七年一癢，我的確是有一點癢了，但是沒那麼大，不管怎麼樣，還是會做一些改變吧，7月份初我會離開淘寶BU，這個我奮鬥了7年的測試團隊，每一年BU和團隊和測試都在變化，我都堅持在淘寶BU做測試，一點點的落地我的想法和思考，看著淘寶業務的起起落落和變化；之後我會加入商家BU，跟隨第一任boss齊哥做一些自己想做的事情，去探索一些未知，包括業務和技術和心中的那個測試。
 
回顧這測試十年，我走了很多的彎路，也走了很多經典的路，前五年主要經歷在測試技術和開發技術的提升上，那個時候看了很多的書，讀了國外很多關於測試的paper，很開心；後五年帶團隊後，花在測試技術和開發開發的投入上大幅降低，很多時候很迷惘，需要處理一些小的瑣事，無法在管理和技術上找到比較好的平衡點，所以這幾年技術的提升相當不滿足期望，不開心；但是這個世界就是這樣，有得必有失，有失必有得，這是經典的老路，在國內做測試的大部分人都會走這條路，但是很多時候，看著測試技術的發展（特別是移動測試技術、大資料測試技術、雲端計算測試技術），包括國外技術的發展，不禁感慨我真的有點跟不上這個變化，這個時代了，必須做出改變，到底改變什麼呢？
 
改變業務：讓自己接觸不同的業務，不同的產品，運氣好的話，就會有不同的開發技術和測試技術等著呢，這樣你還可以多充實一會，多學點東西，讓自己的測試經驗更加豐滿，這樣熬過1-2年後，又會回到原點，路還是那麼窄，而我已經老了。
 
改變測試：做業務的測試的確是個很煩人的東西，很多雜七雜八的事情麻煩，需求變化，需求合理性，使用者體驗，測試資料，bug管理等等，偶爾會有一些自動化測試、看程式碼，分析開發設計實現 作為開胃菜，其他的都是痛苦的，無味的。那我不想做業務測試了，也不想帶業務測試團隊了，我們怎麼辦；測試的未來是很明顯的，我們肯定要在保障基礎質量的、提高效率的情況下減少測試的，這樣業務測試的人員會越來越少，帶領這樣的精英測試團隊？去做基礎的測試服務化的體系和平臺（支撐那些不能缺少的測試活動的高效執行）？能做到什麼程度，能得到什麼樣的結果？
 
改變工作：竟然看到了測試的未來，包括職業發展，包括方向和國內的現狀，是不是可以考慮不幹測試了，脫離測試這個很小的圈子，包括脫離測試平臺開發的圈子；在阿里，我知道一些測試高P成功的脫離測試圈子，進入到開發這個更有發展更有前途的圈子，未來肯定更好，這個是毋庸置疑的；我也是思考過幾十次說服自己必須要脫離測試這個圈子，長痛不如短痛，丟掉那些我自認為很擅長的東西，一次次的自卑懶惰猶豫打敗了自己，有時候很難相信自己是這樣沒有魄力的人。當然不一定非要進入開發這個圈子，PD也不錯啊，實在不行，做HR也很好啊，做Staffing也行啊，反正別幹測試的就好了呀；再看看創業的parter，有需要測試的嗎，都是開發啊、PD、運營才是核心班子呀，這樣下去，自己都沒法創業了，也就是沒法成為創業公司的核心成員了，這一輩子只能當個測試經理，測試總監？這些有意思嗎，這些當真不需要知道先進技術嗎？那樣會分分鐘被取代的，都這麼大年紀了，還沒有追求，等到猴年馬月啊；有家庭了，不能太折騰了，安穩點好哦；尼瑪，好了，我受不了我自己了，我要改變工作，還是改變生活，還是兩個都要改變？好了，不說了，我更加痛苦了。
 
哎呀呀，說到這裡，就說到國內測試屆的偶像了，段總，人家在測試領域最早是google測試經理，幾年前（2010？）很快就跳出測試圈子到豆瓣當然技術VP，然後到各個公司的VP，CTO，現在是CEO了，看看吧，這人生才充滿了挑戰和不確定性，路越走越大越寬了，當然了，行業也是越來越潮流，從網際網路、到網際網路遊戲、到網際網路金融；再次膜拜下段總，畢竟國內只有一個段總，卻有千千萬萬的測試經理和測試總監。
 
好吧，再次承認這兩年我是真的很困惑，目標和方向都不清晰，產出和得到的東西較少，這樣下去，那是沒救了，但是我還在測試領域做什麼呢，還要學習什麼呢，哪些東西是真的有用的，哪些東西是真的對公司有用的，對部門有用的，長期的還是短期的，好吧，再次迷惘。
 
— 10年測試的思考
當然了，在阿里巴巴的測試的相關技術的突破和創新，我是一直在關注的，的確有很多自動化測試、線上監控、測試服務化、線上線下資料對比等相關的突破性的結果產出，都是或多或少的改變了原來的工作模式。但是我們一直不能忘記的是 上下文驅動派的 原則之一，那就是 根本就沒有最佳實踐，只有某個上下文背景下存在好的實踐。
 
大家有沒有想過，開發的核心產出是程式碼，是的可以永恆的儲存在程式碼倉庫的，而且這個倉庫的許可權和重要性不言而喻。測試的核心產出是什麼呢？測試程式碼？Bug？測試場景設計？當然，如果我們的自動化測試做的非常好，那麼我們的test code 也可以有它非常大的價值，但是如果沒有呢？我們對應的測試場景描述、bug 就沒有得到足夠的重視和價值透出。大家都知道，測試對於業務邏輯的理解和整理應該是在開發之上的，我們往往忽略業務沉澱和技術沉澱的融合產出的價值的重要性，同時忽略了這個產出的可持續性、迭代性、可跟蹤性（程式碼其實都具有這樣的特徵）。
 
所以我們可以發揮想象，我們是不是可以將系統服務能力地圖、測試場景、相應程式碼在git上統一管理和對映起來，TC 的 可持續性的版本控制、review的流程化機制、主幹TC和分支TC的管理、TC的元件化和對外提供服務。我們把測試設計場景真正作為一個資產來管理和共享出來。注意這種動態管理測試場景的好處很多，這裡就不描述了，當然其實我們還可以包括測試資料服務的關聯關係，真正的打通系統的各個環節（產品邏輯、開發程式碼、測試場景、機器、線上環境、資料），且能夠清晰的知道和如何完善系統的點點滴滴，這是個大圖，我一直很想看到這個，好吧，我可能在YY。
 
那繼續YY下，開發人員的質量意識到底怎麼來提高，如果我們要做10：1的開發測試比，測試人員做的事情和開發人員做的事情在現在的專案流程中是有很大的不同的，我自己都看過Google的開發人員寫的單測程式碼和方法，那是相當讚的，一個普通的sort排序能寫20幾個單元測試的testcese，比很多測試人員都思考的全面，這樣的測試sense在，系統的單元測試、介面測試、甚至整合的自動化測試都很有可能都是開發來完成的，那是相當讚的，國內公司的開發編碼時間都沒有，更不用說寫單元測試程式碼的時間了，那到底是時間問題還是開發人員的質量意識和責任問題呢。另外，我還發現一個現象，大家都很BS UI自動化測試，都會認為UI自動化測試的維護成本高，都去做介面測試，我們是不是有點走極端了（現在已經很難看到有UI自動化指令碼在持續整合了，估計大家都不寫UI自動化指令碼了吧），UI自動化測試的作用不僅僅在測試環境，包括線上上環節的功能監控都是能起到關鍵的作用，而我們基本上都是擯棄了這個作用，我們自己沒法找到分層自動化測試的平衡點，就一味的選擇放棄，再想想，後端開發能做單元測試、介面測試，那我們的前端開發是不是也可以做UI自動化測試呢，他們也是比測試更加擅長去寫自動化測試指令碼，我們可以不可以去嘗試。
 
其實，不管測試如何發展，測試效率如何提升，系統質量誰來把控，這些都是永恆的話題，誰做不是做呢。我們要做的就是不斷變革，變革自己，變革開發，變革整個研發流程。如果測試人員還守著自己的一畝三分田，進步和收穫都是相當少的，測試需要去做很多開發需要做的事情，比如非功能的專項上，效能、穩定性、安全，不一定是專項測試上，整個解決方案上都要有比較不錯的結果，注意這裡不是說業務上的開發能力的體現。
 
不管怎樣，當你測試幹了10年的時候，我覺得是不是可以思考更大的問題，因為這些問題是不可避免的，無法逃避的。當然，這裡不是說我們不能做一線測試工作，但是如果我們的重心是不停的去測試執行，去提bug，去寫自動化測試指令碼，這是不可取的；我們還是需要了解一線測試人員的痛苦，鬱悶，難受，問題的地方；而這些抽象放大的問題，就是我們需要去解決的。測試架構師們需要解決的問題就是在平衡質量的前提下（無P1P2級線上故障），快速釋出，提高測試效率，提高開發測試比。我們到底要做什麼，做哪些具體的action，我們做的事情的目標和規劃是不是圍繞著這個核心？
 
好吧，其實我一直有一些自己的亂七八糟的想法，瞭解了很多測試團隊的做法，瞭解很多測試相關的創新工具和流程，但是我之前一直沒有想到的是，我心中的測試到底是什麼樣的，我為了這種測試，我做了哪些事情，我沒有做到很好的抽象，總結、規劃自己心中的測試。不管這個測試是美好的，還是現實的；不管這個測試是不可能落地實現的，還是可以做到的，我都沒有很好的思考這個測試的整體。這10年來，我經歷的點很多，但是我沒有把它串成一條線，沒有把它連成一個面。
 
— 我心中的測試
 
好吧，前面太囉嗦了，現在回到正題了，這兩個月我確實思考了很多，包括看了自己之前寫的一些blog，從中選取一些很好的想法，加上自己看到的一些變化。最後，我思考了一個六道網質量防控體系，肯定會存在一些問題，後續一些想法和思考都會圍著這個體系來建設，從而完善它，真正的把它做好，真正的服務到整個專案團隊成員。
 
why-六道網質量防控體系
首先說下，為什麼會有這樣的一個六道網質量防控體系呢，因為我們想：
全方位多角度的測試活動來保障系統質量
改變傳統模式下的開發測試工作方式
 提升研發團隊的測試成熟度，助力組織升級
 質量可控情況下，提升開發測試比
 更顯性化的展現系統質量控制過程和結果
 
六道網質量防控體系大圖

六道網質量防控體系實施策略  （去掉了怎麼做、工具、結果）
當然了，這裡面每道網都有自己的獨立的實施流程和策略，我這也思考的一些，但是現在不方便拿出來，所以這裡就先不討論了，後續有機會再詳細描述一下，這裡就是要注意的是，不同的產品特點會對應不同的實施策略，純後端的、標準web的、H5的、native的，SDK的，ISV的，大資料的，演算法的等等都有自己合適的實施策略，我們要的就是配置不同的專案，自動化配置不同的實施策略，包括實施的進度，狀態，風險控制等等。
 
六道網質量防控體系的機制&標準問題：
 
六道網系統的專案接入標準是什麼？
 如何知道某一道網防控的進度情況？
 如何知道某一道網防控的效果和問題？
 六道網的具體action如何保證落地執行？
 六道網防控的質量風險無法提前暴露？
 六道網無法綜合各道網的防控結果做出決策？
 六道網如何獲取防控過程中出現的內部和外部資料？
 
上述這些問題我很多都沒有想好，想透，而且我一直在思考的是六道網系統的核心競爭力到底是什麼？對外提供的服務能力到底是什麼？系統和功能架構到底是什麼樣的？我得承認，我做測試工作10年了，平時對系統設計方案、架構設計、業務抽象設計做的其實不多，對平臺設計、架構抽象的能力實在不行，這個問題很大的限制了我的發展，我無法體系化的思考一個平臺是什麼樣的，無法準確的設計一個平臺的配置性、可擴充套件性、穩定性、多樣性等。
 
大家都看過軍事題材的電影或電視劇吧，我們經常看到的是軍事演習或對戰的時候，指揮部的大屏顯示的內容，那TMD的太帥了，我就是想要那樣的系統，那樣的六道網防控體系，那樣的給指揮部所有成員作出決策提供資訊的支撐。但是不得不承認的是，目前阿里巴巴還沒有這樣的大屏，沒有這樣的讓我非常清楚一個專案、一個系統該有的實施資訊和控制決策，不僅僅是自動化的問題，還包括我們做專案的標準輸入、標準輸出的問題，我們一直做網際網路產品，一直要的快速，一直要的是隨心所欲，一直要的自己方便就好，最後就只能這樣了。
 
平臺和想法規劃的再好，也需要落地執行能力，對於平臺和產品來說，有些人說的是從上而下的支援和鼓勵，有些人說的是平臺帶來的解決的問題，有些人說兩個缺一不可；大家都害怕改變，改變意味著帶來了新的不可避免的成本，帶來不熟悉的工作方式，帶來了可能是自己工作量的加大。我們的目標是確定的，我們不希望靠增加測試人員來提升和保障系統質量，我們就是要減少測試人員，去探索那肯定會來到的測試未來。
 
不管怎麼樣，最早我就提到了，如今我離開原先的淘寶測試團隊，獨自一個人去商家BU，會面臨很多問題，但是我找到了六道網體系，我會為了它，獻出我長時間的思考和總結，包括學習（最近經常看這些架構設計，技術思考等），我相信我能找到合適、心中的那個測試。下一個測試十年，道路肯定不平坦，肯定會有很多的挑戰，唯有 雄關漫道真如鐵，而今邁步從頭越！ 


相關文章