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

轉：http://blog.sina.com.cn/s/blog_6cf812be0102wo6d.html

好久沒寫blog了，以前的測試三年，測試六年都寫了blog來記錄本身的測試生涯和思考，此次測試10年確定不會錯過了，固然了，YY比較多，乾貨也很少，反正記念下，或許我很難寫測試15年的blog了。你們有任何問題，歡迎討論，歡迎吐槽。

--- 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，會面臨不少問題，可是我找到了六道網體系，我會爲了它，獻出我長時間的思考和總結，包括學習（最近常常看這些架構設計，技術思考等），我相信我能找到合適、心中的那個測試。下一個測試十年，道路確定不平坦，確定會有不少的挑戰，惟有 雄關漫道真如鐵，而今邁步從頭越！