標籤:style io os 使用 java sp strong 檔案 資料
我覺得我上一篇寫得太簡略了,估計很多人看了覺得不過如此,我決定在這篇裡深化一下。
本文中,我定義技術路線長度或技術基礎的標準為:普通人完全掌握一種技術所需要的時間,我把他的單位名稱定義為Y,M,D (年,月,日)
比如3Y表示某技術需要普通人花3年時間來掌握,1M表示某技術需要普通人花1個月時間掌握。
本文有以下前提條件,基於我的個人理解:
前提一
電腦專業應屆生的技術路線基礎理論上為4Y,因為大學要讀4年
培訓班畢業非電腦專業的學生,以培訓一年為例,技術基礎為1Y
黑盒手工測試的技術路線為3M,因為一般只要培訓3個月,不管你是不是電腦專業都能勝任
同理,軟體開發中路線最短的XXX資訊管理系統開發人員培訓3到6個月也可勝任,算他6個月,那麼特定於某種語言或架構下開發XXX資訊管理系統的開發人員的技術路線長度為6M
前提二
對於大多數人來說,技術不用,則會漸漸遺忘。
也就是說假如應屆電腦專業畢業生技術基礎是4Y,他從事了1年與電腦無關的事業,則他的技術基礎將小於4Y。(事實上,一年的空白,將使得此人的技術能力接近於0。)
推論一
我的推論就是:一個人的核心競爭力 =硬能力 + 軟能力 + 外部能力
硬能力= 技術積累 + 業務積累 + 語言積累(英語)
軟能力= 溝通能力+管理能力+寫PPT能力+其他對工作有用的非技術能力,或者說技術能力的表現力
外部能力 = 人脈、運氣、家庭條件 等等來自於外界的附加值
- 為什麼不建議應屆畢業生直接從事黑盒手工測試工作?為什麼特別不建議應屆畢業生從事外包行業的黑盒手工測試工作?
在上述前提基礎上,我們不難看出,一個電腦應屆畢業生假如一畢業就從事黑盒手工測試則他的技術基礎會被浪費4Y-3M = 3Y9M
也就是說浪費了3年零9個月,並且這3年零9個月的基礎將在1年內消失,
一年之後,此人的技術基礎將變為3M : 4Y(大學4年) + 3M(培訓黑盒手工測試3個月) - 4Y(一年後,大學知識遺忘完畢) + 0(黑盒手工測試1年,零積累) =3M這也是我不建議一畢業就做測試的原因。
也就是說,工作1年的黑盒手工測試工程師如果這一年完全不接觸技術,則他的技術基礎變為3M,遠小於應屆畢業生的4Y,競爭力急劇下降。
因為,當若干年後,我們要問,一個黑盒手工測試工程師和應屆生有多大區別。假如沒區別或只有業務知識的積累,則當業務發生變化時/公司不景氣時,此黑盒手工測試工程師將遭遇職業危機。
(這裡,不排除此人在從事黑盒手工測試過程中,他的業務基礎有可能不斷增加(比如他做金融測試,金融以業務複雜著稱),則業務積累可以替代技術積累成為他的核心競爭力。此類例子不在我考慮範圍之內,因為我沒進銀行之類業務為核心的單位,大部分人也不容易進這樣的單位。)
這個危機在外包行業尤為嚴重,因為外包行業通常沒有多少業務積累。每次換項目,他的業務積累就歸零。
外包行業的應屆黑盒手工測試工程師將遭遇到的最大挑戰是,無論工作多少年,他的技術基礎永遠是3M,業務基礎永遠不停歸零。
當然,你還可以積累語言基礎,比如外資外包公司,積累良好的英語能力,這也是一種方法。
我知道有的外包公司派出剛完成黑盒手工測試3個月培訓的應屆生,假裝成2年工作經驗的黑盒手工測試工程師派去客戶單位幹活,並且最後獲得客戶好評的故事。實際上這個故事裡,客戶賺了。因為他用的人的技術基礎是4Y3M,假如真的給他2年經驗的,則那個人技術基礎只有3M。於是客戶當然給出了好評。
理想的情況下,我們從開發開始做起,並選擇技術路線長(>=10Y)的開發工作,若干年後轉成相關領域的測試,不但熟悉業務,更熟悉代碼,就像國外一些幾十年開發/測試經驗的資深者(老頭子)一樣,驕傲地說我可以測試任何軟體產品。這種測試人員,就是我們最初接觸軟體測試時,從大學老師或書籍上看到的“資深的開發做的測試”,或者說“好的測試”。但這隻是理想情況。
實際上,我們中大多數人從一個錯誤的入口過早地進入了軟體測試行業,並且選擇了技術路線為3M的黑箱測試。
一個好的開始是成功的一半,假如你是從開發開始做或者直接從自動化開始做的,可以跳到後面部分了。
黑盒手工測試,我稱之為“3M眾”,3M眾是最多的。有本專業的,有其他專業的,不管什麼專業,你從事黑盒手工測試一年以上或者培訓3個月以上,你就是3M眾的一員了。
我接觸的最多,同時也是向我提問的人力最多的就是3M眾,我以前也是“3M眾”之一,並幾乎完全荒廢了大學4年的技術基礎,剛畢業的時候我還會寫jsp,還會用ssh,還會資料庫建模和設計,還能用java自己寫個動態網站。後來我會個毛線,全忘光。
基於我的個人理解,
黑盒手工測試工程師的技術門檻是0,技術路線長度(包括門檻)是3M,簡稱3M眾
3M眾要掌握的東西通常有:
1.幾十年沒變化過的測試案例設計方法
2.變來變去其實還是一樣的軟體生命週期,從瀑布模型到快速迭代模型
3.至少一個bug管理工具,如jira,並學會如何提交bug,如何說服開發修bug
4.至少一個測試案例管理工具,甚至excel也行,並掌握如何寫測試案例、如何填測試結果
5.至少一個拿得出手的手工黑箱測試項目,如參與測試XXX資訊管理系統的使用者註冊模組,XXXX模組
畢業標準則是:
1.至少一個拿得出手的完整項目。如負責測試xxxx資訊管理系統的A模組、B模組;並能測類似的新項目
高一點的要求是:
2.能自己搭建測試環境做build做deploy
3M眾最大的迷茫就是:“感覺學不到東西"
然後3M眾最常聽到的就是,“從使用者角度來看問題找BUG”、“提高溝通能力以適應各種(怪)脾氣開發人員”、“如果需求不停變,你能忍受嗎”、“能忍受重複勞動的枯燥嗎”、“一個優秀的測試人員應該具備什麼素質”
我覺得這些是在誘使一個3M眾成為一個永久的3M眾,並且開始向業務積累、軟能力以及自我安慰方向發展。
其中的成功人士因為有了足夠的業務積累和軟能力而直接變身為測試管理員。這確實很好,但是,這比例太低了點吧。人人都想變管理,人人都想進銀行之類業務複雜到能讓測試人員依靠業務積累就成正果的行業。
但是這成功比例太低
我有工作了7年當上測試經理的同事,也有工作了8年,還是資深黑盒手工測試工程師的同事,這種事情見得多了。不一定誰強誰弱,有時起決定性因素的是外部能力。而且另一個問題是“中年危機”你怎麼應對,40歲遭遇公司倒閉,你一個3M眾怎麼辦?假如你的行業被互連網行業衝擊得要消失了你怎麼辦(比如我的同事遭遇了DVD光碟片燒錄行業之衰落)。
一個3M眾自然而然地會開始迷茫”學不到東西“,然後到處發帖、問人、互相討論。運氣不好的人會被引領到“軟能力”方向、“業務積累”方向、甚至“混日子”方向和“自我催眠”方向。
然後有一部分3M眾因為遇到一個好領導或者好公司或者看到一些好文章,而被點撥,開始走自動化測試的路線。
自動化測試路線是最常見的黑盒手工測試人員的技術發展方向,直接走效能測試路線的人比這個少多了。
但這條路並不好走。首先是技術門檻問題。
黑盒手工測試技術門檻是0,而網頁自動化測試技術門檻我覺得是1Y+ X(X取決於英語能力,英語越強則X越小)
自動化測試的路線上,我個人掌握其基礎大概花了3個月,掌握其原理又花了3個月,從掌握到應用自如的程度又花了6個月,之後繼續充電和深化,從應用自如到有所突破又花了大概3個月。中間還有浪費在黑盒手工測試上和重複勞動上的沉澱時間若干個月。
照我自身經驗來看,自動化測試的技術門檻是大學剛畢業的那個4Y+掌握基礎用的3M,或者培訓班裡培訓java開發用的6M+掌握基礎用的3M,然後自動化測試的技術路線長度對我來說是一共9M+若干沉澱時間。
這裡大部分人沒我快,主要原因是:英語的積累不同
我這裡的自學速度快的主要原因是接觸到的學習資料品質高,全部用英文資料,並且個人學習能力還不錯。
那麼根據我接觸的一般人的進度,掌握基礎(包括程式語言基礎)要1Y,掌握原理又要1Y,應用自如又要1Y,最後能不能有所突破則要看緣分了。
所以我的理解下,
自動化測試工程師的技術門檻是1Y+ X(X取決於英語能力,英語越強則X越小),技術路線長度(包括門檻)是3Y,簡稱3Y眾
3Y眾要掌握的東西通常有:
1.至少一個程式語言或指令碼語言,如java或python
2.至少一個主流自動化測試載入器,如selenium,並理解其大概原理
3.至少一個主流測試執行器,如testNG,並理解其大概原理
4.至少一個拿得出手的自動化測試專案,如自動化測試XXX資訊管理系統。
而畢業標準則是
1.至少一個拿得出手的自己負責自動化測試專案,如基於XXX架構做了XXX系統的自動化測試指令碼
2.理解至少一個自動化測試載入器的深入原理,如selenium,並能在此基礎上搭建自己的測試架構,如我們可以隨便搭建一個java+selenium2+testNG+Jenkins+selenium grid的測試架構並使用page object factory模式。
高一點的要求是
3.能理解別人的自動化測試架構的代碼和他們這樣寫的原因,比如我隨便看看以前公司其他人搭建的自動化測試架構,可以看出他的寫法有哪些好的地方,不好的地方,他當時為什麼選擇了這種不好的寫法,現在能不能最佳化,成本要多少。他用的某種測試載入器的優缺點,他選用的測試資料群組織方式是否有可以最佳化的地方
4.讀過一點開源工具的原始碼
5.至少一個持續整合下的自動化測試專案,如jenkins下的
6.至少掌握一個非windows作業系統的操作和基本指令碼
如果是你是做自動化介面測試的,那真是好運氣,相應的只是改了改工具,而介面自動化測試遭遇垃圾架構的幾率小得多。
自動化測試最怕的是:
1.錄製回放測試載入器 - 這工具不但扼殺你的技術路線,還會讓你陷入一直傻傻錄指令碼的尷尬境地。唯一好處是給公司省錢。
2.垃圾架構 - 由初級開發人員在未掌握自動化測試基本原理時製作而成,會讓你做自動化測試做得比黑盒手工測試還痛苦。諸如200個方法的上帝類,20個類的繼承鏈,1000行測試資料和1000行預期結果混合雜亂放置的測試資料文字檔,麻煩得要死的關鍵字驅動的excel表格,一半要人工複核的不可靠測試結果,傻傻搞不清楚的業餘級測試執行方式,莫名其妙死在那裡還沒法調試的持續整合測試指令碼等等,以上均是我目睹的自動化測試做得比較成功的案例裡的,他們至少自動化做出來了,雖然很垃圾,還有很多半途而廢的失敗案例更糟。
3.承擔不起自動化測試成本的公司。自動化測試成本較高,特別是使用者介面層最高。即使是介面層,仍比手工測試高。小公司我看還是算了吧,搞不來的。現在2014年,你花個12k/月在杭州只能請到3Y眾裡水平一般的,想找個技術好的純屬碰運氣。但你看,小公司可能會20k/月請一個資深ios開發,但不會給20k/月來請一個資深自動化測試,資深自動化測試還是比不過資深開發。
3Y眾的迷茫是“沒有開發收入高“,“要不要做管理”,“效能測試怎麼做”,“學的新東西老用不到,不用一段時間又忘記了”,“開發基礎沒打好,好多東西不懂”,“技術路線後面還有沒有了“,”這架構太垃圾,做自動化測試比手工還累“
到了這個階段已經沒多少人會滿足於3M時代的“與開發溝通的技巧”之類的東西了。很顯然當我們有和開發對等的技能時,並不需要看誰的臉色。很多人的工作根本不直接和開發打交道,就是寫測試指令碼、指令碼發現的bug自然有人去跟。也有人做測試架構,壓根不接觸開發。我有段時間主要做測試架構的維護改進、測試指令碼的review和帶轉職過來做自動化測試的開發,也有一段時間做自動化測試培訓。
此時我們有了和一般開發不同的技能樹,至少在面對初級開發人員時會比較有底氣,當然進階的開發人員還是略顯牛逼。顯然,對於測試人員來說,從3Y到10Y的技術路線不是那麼好找的。
如果一個自動化測試人員自以為自己有10Y的技術積累,而實際上和3Y路線走上來的新人水平差不多,那就會遇到和黑盒手工測試人員一樣的被替代的危機。當然另一個方面來說,如果項目不倒灶,自己寫的自動化測試指令碼,自己維護起來顯然比別人有優勢。問題是這裡仍舊有一個進階版"中年危機",如果你參與的自動化測試專案結束了。如果你使用的自動化測試技術過時了,如selenium 1,如果你用的工具本身就很有局限性如fitnesse,或者你用的是一些內部工具,然後公司倒閉,內部工具的工作經驗變得毫無用處,如諾基亞手機部門。那你怎麼辦呀。實際上,當自動化測試掌握到一定程度後,我發現,自動化測試工作崗位在杭州很少,但是“要求懂一點自動化的黑盒手工測試崗位”不少。跟上海的同事交流發現那邊自動化測試崗位比杭州多,但也有很多拿自動化做幌子的崗位存在,包括現在互連網巨頭的一些測試開發工作崗位也有其實是黑盒手工測試為主的。
最後特別指出,外包行業的自動化測試仍然是不靠譜的佔多數,比如所謂的平台自動化測試工程師,有些外包到互連網巨頭做自動化測試的人在一些屬於巨頭的測試開發人員做好的自動化測試平台上,使用被封裝又封裝的面向領域語言編寫測試指令碼,對個人毫無技術積累,和黑盒手工測試有一拼。這是由外包行業能用就行,達到需求就能收錢,以及產值固定(如你的合約簽訂多少錢一人月就是多少錢一人月)決定的。不像做產品,不但要能用,還要精益求精以求賣得更好,當產品賣得好的時候,個人平均產值也高,說明工作產生的價值高。
總的來說,混到3Y眾這個層級,算是傲視3M眾了,有無數3M眾一輩子也到不了3Y眾的高度,如果基礎太差,或者學習能力不足,很可能卡在某個地方上不來。
下一期/幾期我想總結一下對於以下路線的理解
- 從3M眾到3Y眾(偽) - 懂一點自動化的黑盒手工測試路線(“偽”3Y眾仍舊可以混得比3M眾好很多)
- 從3M眾到3Y眾 - 介面自動化測試路線(我專門開一個講介面測試的章節滿足一下有的朋友的好奇心吧)
- 從3M眾到3Y眾 - 移動端測試(我也不熟,只能憑感覺寫寫)
還有一些我不確定的猜想
- 從3Y眾往上走 - 效能測試路線?
- 從3Y眾往上走 - 測試開發路線?白盒測試路線?
- 從3Y眾往上走 - 如果掌握3個3Y眾路線是不是可以搖身一變變成9Y眾甚至傳說中的測試架構師?
- 從3Y眾往上走 - 管理路線,走還是不走?
後面還有一些我想整理的
- 核心競爭力 - 所謂“博”靠的是一堆不稀奇的技術組合成一個稀缺的技術組合?
- 技術重疊度 - 來自開發人員、營運人員、其他技術人員的挑戰
- 公司/工作崗位和測試人員的技術路線、業務路線、管理路線的長度 - 怎麼選公司?
- 無盡的加班 - 小公司加班地獄的經曆 - 為啥每次上線總是在半夜三更或淩晨,不管是做中國用的網站還是美國用的網站都在中國半夜上線?
我對軟體測試行業的個人理解 4