軟件測試，想說愛你不容易

發現一篇好文章跟你們分享下呵呵
軟件測試，想說愛你不容易 (2012-10-08 21:47:41)
標籤： 軟件測試 職業發展 前途 it
    一不留神，畢業後在軟件公司裏已經工做七年多了。期間經歷了民企、國企、美國硅谷小外企和大型外企，作過正規軟件開發（團隊規模10人以上，有產 品經理、開發人員、測試人員、文檔工程師，客戶爲Cisco，出過2個以上的版本，代碼量在20萬行以上），功能測試、性能測試、測試自動化、測試輔助工 具開發、國際化測試、本地化測試、兼容性測試、第三方測試、測試團隊管理，對軟件測試的理解也逐漸深刻。特寫下如下文字與你們分享。
l．軟件測試的前途
    軟件測試在整個軟件生命週期中是必不可少的重要一環，可是其在研發體系中的重要性要弱於軟件開發和基礎技術研究（如搜索引擎的搜索算法，圖像的識別算法，統計分析模型等），要高於大多數外圍工做（如安裝部署、環境搭建等），很難拿高薪，工做強度適中。
    作軟件測試的同窗們看了這個結論可能會很不爽，難以接受，但確確實實是我在工做多年、經歷了多家公司後總結出來的切身體會。重要性不是某我的或者 公司領導決定的，而是尤爲工做自身的特色決定的。爲何測試工程師則常常抱怨本身的工做不受重視，而不多有架構師抱怨呢？由於他們的工做內容門檻高，可替 代性低，通常人把他放到那個位置上也幹不了。
   拿大多數軟件公司來講，軟件開發和軟件測試是兩個最多見的工種，擁有最龐大的工程師羣體。通常來講，開發工程師比測試工程師能夠拿到更高的薪水。核 心開發工程師的工做內容技術門檻比較高，可替代性比較低。一個明星產品的原型，或者內核，每每也就是一兩我的寫出來的,Linux內 核，JBoss,Struts,Spring,Hibernate...太多太多這樣的例子。雖說一個技術原型和成功商業化的產品之間還有很大的距離， 還須要不一樣工種的人互相協做，可是誰在扮演更重要的角色不言而喻。畢竟，軟件是開發出來的，不是測試出來的。核心開發工程師作的工做，初中級工程師根本無 法染指。
   大多數測試工程師拿到的都是行業平均薪水，差距不大。對一個產品進行測試，80%的工做量是功能測試，性能、可靠性、國際化、易用性等等加一塊兒通常 也就佔20%。道理很簡單，若是一個產品的主要功能跑不起來，其餘東西都白搭。因爲種種緣由（如需求變化大致使界面變化大），功能測試又以手工測試爲主。 這部分是技術含量最低，替代性最強，我的知識積累最少的測試工做了。今天測試產品A，明天測試產品B，就比如今天當力工搬磚頭，明天搬木頭，只要力氣在， 搬就是了，管他搬的是什麼。甲作也能夠，乙作也能夠，經驗豐富、耐心細緻的能夠發現更多、隱藏更深的bug,可是不存在作不作的了的問題。3年下來，一名 開發工程師能夠掌握一門編程語言，懂點設計、架構、框架、UML，或者一我的前臺後臺持久層所有拿下。而一名手工功能測試工程師，只能成爲某個被測試產品 的使用專家，不用去懂J2EE或者.Net，Flex或者Html5,MVC或者SSH。被測產品一換，一切重頭再來。
    測試中比較有技術含量和門檻的是測試自動化開發和性能測試。
    先說說測試自動化開發。測試自動化開發主要有兩種，一種是用現成的工具如QTP、WinRunner編寫測試腳本。還有一種是本身用Java或者 C#編寫輔助測試工具。現成的工具都基於某種語言，如QTP基於VBScript,WinRunner基於本身獨有的類C語言，Selenium基於 Java。本身編寫的工具大多用於批量數據生成、導入、處理等。而這二者歸根到底仍是軟件開發，並且大多數是比較簡單的開發。
    測試腳本不少不須要界面，是命令行程序，這樣GUI開發中的不少難點就不會遇到了。
    大多數是單線程運行，由於是腳本，即便是上千個腳本，只要按照順序跑就能夠了，這樣多線程的麻煩就不用去處理了。
    不須要訪問數據庫，由於測試結果通常記到文件中如html文件，並以表格或者簡易報表的形式顯示就能夠了。這樣，在軟件開發中的一塊重頭戲-持久層開發和數據庫設計就不用考慮了。
    如此這般，對於通常的測試腳本或者工具開發，專業的軟件開發人員即便沒有什麼測試經驗，也能夠輕鬆上手，作得遊刃有餘。

   再說性能測試。
   性能測試的主要目的就是驗證一個軟件產品能夠容許多少用戶併發訪問，性能指標如響應時間、CPU和內存佔用率是多少。通常來講這種測試沒法手工作， 須要藉助於工具，如LoadRunner, QALoad,JMeter等等。首先，在錄製的腳本基礎上作一些編程是必不可少的。其次，在獲取到基本的性 能指標值後，如何去分析並解決問題，好比調整操做系統、數據庫、中間件的參數，作個集羣啦啥的，或者對程序作代碼級的優化，又遠遠超出了測試的範疇，是一 般的性能測試工程師根本作不了的，須要架構、IT工程師、開發人員協同攻關。能夠看出，一位性能測試工程師所做的腳本開發工做，對於專業開發人員來講，沒 有什麼門檻。而複雜的測試環境搭建的工做，又須要網絡工程師、數據庫工程師的強有力支持，我的難以獨自應付。

    國際化測試的門檻通常。核心的東西，擠幹了水分，也就兩三個月，包括字符集、編碼、字體、Bidirectional language、時間日 期貨幣小數點排序佈局等。換句話說，一位功能測試工程師，在通過好的導師三個月的專業培訓和學習後，就能夠基本勝任國際化測試的工做了。這裏的門檻在於， 市面上介紹國際化測試的書很少，不少東西須要在工做中去一個個知識點地學習，須要老員工來帶。不像對java、數據庫開發進行系統介紹的書那樣滿大街都 是。
  
    兼容性測試是典型的沒什麼技術含量的人力密集型工做。本人曾經作過一個月的打印機兼容性測試，上百臺打印機，一個接一個放入打印紙打印，看看對被 測試的國產Linux的支持程度。或者一個產品，測試對不一樣數據庫的支持。讓我想起在上大學的假期裏給人發傳單時，發一次掙30元錢，誰幹均可以，賣賣苦 力。後來改行寫遊戲外掛，一個月輕鬆掙3000多塊，讓室友們羨慕得不得了。
    手機/平板電腦應用的測試。手機或者平板電腦上的應用要麼是單機應用如雷電遊戲，要麼是客戶端程序如新浪微博客戶端，特色是輸入少，以瀏覽爲主。客戶端程序的開發難度要低於服務器端程序，其測試難度也相應得低一些。

    測試的另外一大不利因素是缺少成就感。設計人員、開發人員能夠出去和人說，你們用的某某殺毒軟件的小獅子是個人idea,某某輸入法是我開發的，某某網站是我寫的，裏面存在只有我知道的某某漏洞。測試人員與之相比則會比較尷尬。
    說了這麼多，絕對沒有輕視測試或者刻意擡高開發的意思。每個工種都是不可或缺和重要的。可是，他們帶給工程師自己的價值增值不同，工做時間越 長越明顯。打個不太恰當的比方，開發與測試工程師，就比如醫生與護士，會計和出納。醫生越老經驗越豐富，價值越高，每一個年代都名醫輩出，受人敬仰。而護 士，除了開創者南丁格爾外，沒有幾個能被你們所熟知和記住的。

    工做內容雜、重複性高是低價值工做的一個共同特色。而這是想在職業上有所發展的同窗必需要注意的一點。
    說了這麼多測試工做的侷限性，下面接着說說從事軟件測試這個行當的好處。畢竟，包括我在內的很大一個羣體都在靠這個行當吃飯，全是缺點的話，誰還願意幹這行。並且，想幹好測試的話，仍是須要花費一番心思的。
    勞動強度和工做壓力適中。開發人員的一大壓力是到了deadline可否作完分配的模塊。技術難點是不可避免的，沒有人能百分百地保證一個全新項目能按時開發完，能解決全部的技術難題。測試要好不少，測試工做主要是量的問題，大不了加加班，不存在完不成的問題。
    技術更新週期長。無論是Flex、Html5仍是Jsp寫的軟件界面，對功能測試人員來講區別不大。而對於開發人員來講，技術的切換則是一件比較痛苦的事情。就像被人從一個熱被窩裏面揪出來，再重新捂一個冷被窩。其中的辛苦，經歷過的人都知道。
    技術面、適用面比較廣。開發人員講究的是深度，測試人員講究的是廣度。測試人員在換工做時，從測試 .net 產品轉向測試Java產品問題不大，而對開發人員來講則是個大問題。
    開發人員比測試人員 ‘軸’的更多。不少牛人技術很好，可是溝通能力不好，朋友少，這和工做性質有很大關係。長期的編程形成了很多開發人員呆板的思惟方式。生活是豐富多彩的，遠不是隻有技術。

2．測試團隊管理
1）誰在作軟件測試？
計算機專業畢業的女同窗：軟件測試的勞動強度和壓力比軟件開發小不少，還要求耐心和細緻，很適合但願幹本行的科班出身的女同窗
非計算機專業畢業的同窗：軟件測試的入行門檻比開發要低一些，不少學與計算機相關的理工科專業（如信息系統、數學、物理、電子）畢業，甚至是當年由於幾分之差與計算機專業失之交臂，同時又對此行業很感興趣的同窗轉行過來
軟件開發、售前、售後技術支持工程師轉行作測試：部分軟件開發工程師在工做若干年後，不太喜歡太大的工做壓力和強度，但願可以保持工做和生活的平衡，多一 些時間陪陪家人。他們強大的開發背景很快就能在測試組裏顯山漏水，鶴立雞羣，即使開發能力在開發組中只是通常般的；部分售前、售後工程師在結婚生子後不希 望太多的時間在外地出差，但願能多照顧家庭，他們的行業知識和溝通能力對測試工做也大有裨益。

2）測試工程師的內心在想什麼？
每一個人的需求不同，這就須要管理人員根據每一個人的需求來作工做，因人而異，才能達到最好的效果。
有的人衝勁很足，渴望挑戰技術難點，提高技術水平，就讓他多作核心工做，得到成就感。
有的人求安穩，不求職業有多大發展，但求多照顧家庭，少加班；或者階段性的，好比家裏剛要了小孩兒，但願能多照顧家庭，就分配一些沒難度的工做給他
有的在工做若干年後對測試逐漸失去興趣，會轉行作開發或者技術支持。只要有心的話，在平常工做中均可以覺察的到。


3）測試的技能要求
編程：編程能力是一切IT相關行業的基礎，尤爲對於軟件測試來講，編程能力和功底越高越好。這樣他就能夠知道開發過程當中哪些地方容易出問題，發現不少純黑盒測試人員發現不到的深層次bug。

數據庫、中間件、操做系統：被測試的系統千差萬別，測試人員不少狀況下須要本身搭建測試環境，在測試過程當中發現問題後須要甄別是測試環境的問題仍是被測系統存在bug,因此常見的數據庫、中間件、操做系統都要會裝會用，至少要熟練使用一種。

行業背景知識：若是被測試的軟件是QQ，Office這類通用軟件，那不須要什麼行業知識。若是測試一個複雜的財務軟件或者ERP軟件，沒有基本的背景知 識的話，不少流程會走不到，或者根本就走不通，測試覆蓋率會出現嚴重的問題。全期望產品使用說明文檔或者客戶現場支持是不現實的。

測試工具的使用：最經常使用的如QTP,LoadRunner。這個沒有難度，就是個熟練度。

溝通：各個工種都須要
英語：IT的各個工種都須要

4）FAQ
Q:在作測試的時候，發現並記錄bug後，是否提倡由測試人員分析並修復呢？
A:我在作測試時，和我所在的團隊成員曾經這樣嘗試過，最後發現費時費力，事倍功半。由於對於一個大型軟件系統來講，代碼結構比較複雜，即便是這個產品的 開發人員，讓他調試不是本身所編寫的模塊的代碼，都須要花好大一番功夫。而對於某個模塊的開發人員來講，對本身編寫的模塊瞭如指掌，調試並修復bug事半 功倍。並且對於開發人員來講，寫前臺的不懂後臺，或者寫中間層的不懂持久層都很常見，在開發過程當中都須要相互配合聯合調試。若是測試人員真想提升技能的 話，不如本身多動手寫一些程序，或者精讀一些代碼更有益一些。固然，願意多鑽研是一件很是好的事情。
 
Q：如何儘可能規避測試覆蓋率不足的風險？
A：測試的最大風險在於測試覆蓋率不夠致使漏報，最終被漏掉的問題在產品發佈後被客戶在使用中發現。而實踐又證實，沒有開發人員的幫助，測試人員100% 會漏掉一些重要的bug。因此，須要在制度設計上有所考慮。若有興趣，具體方法可聯繫本人。固然，全部方法都只能儘可能提升測試覆蓋率，對於一個幾十萬行代 碼量的中大型系統，沒有完美的方法能保證100%的覆蓋率。

Q:測試組和開發組的關係就像貓和狗同樣天生不和麼？如何理順？
A:在不少軟件公司，測試組和開發組的關係都比較緊張，很差調和。開發組認爲測試組發現不了多少重要的bug，就會在一些邊角問題上吹毛求疵，雞蛋裏挑骨 頭，在領導面前說壞話，在開發進度已經很緊張的狀況下還要來擠佔寶貴的時間問這問那；測試組認爲開發組作的東西太爛了，報的bug沒有引發足夠的重視，得 不到足夠的開發狀態更新和支持配合。這些矛盾是由多方面的緣由引發的。
1）評價體系
    測試組沒有有效發現bug,等產品上線後被客戶發現了，致使投訴甚至經濟上的損失，是測試組的責任；測試組發現的bug,開發組沒法按時修復，是 開發組的責任。測試人員心中大罵：由於開發人員作得東西爛，才致使本身沒有發現所有的bug；若是開發作得好，本身怎麼會漏掉bug進而影響了年終獎。開 發人員也極其不爽：都怪測試人員臨到最後才發現了一個致命的bug，致使本身沒有時間修復，讓產品帶着問題發佈了。
    因而乎，爲了各自的飯碗和聲譽，悲劇開始了。
    測試組會不遺餘力提升測試覆蓋率，報bug,寧肯有少許誤報，也不敢遺漏；而要提升測試覆蓋率，測試組須要開發組的大力支持和配合。實踐證實，沒有開發人員的幫助，好比介紹哪一個模塊有潛在問題和複雜的邏輯分支，測試組沒法獨自發現不少重要的bug。
    而開發組在項目後期壓力會比較大，一邊拼命修復bug,一邊看着新bug一個個先僕後繼地冒出來，感受bug就如同蒼蠅般轟都轟不走。遇到比較嚴 重又很差修復的bug,更是倍感壓力，茶不思飯不香。忽然間，開發人員本身發現了一個比較嚴重又很差修復的bug，次日就要交付產品，時間來不及了，而 測試組尚未發現。該如何抉擇呢？
    a. 主動報告bug，本身承擔所有責任；爲了這個bug,可能須要專門給產品開發一個patch,在公司上下都形成了負面影響
    b. 隱瞞bug,測試組最終也沒有發現，產品交付使用後被客戶發現了，測試組承擔所有責任
    c. 隱瞞bug,測試組最終也沒有發現，產品交付使用後客戶也沒有發現，皆大歡喜，在下一個版本里本身悄悄修復
   公司不一樣，企業文化不一樣，獎懲激勵制度評價體系不一樣，最終會使開發人員在一番權衡以後作出大相徑庭的決定，進而影響這個產品甚至整個公司。
 
2）組織架構
    在不少大公司裏，部門會按照職能來劃分。測試部下轄若干測試小組，每一個小組負責測試一個或者一類產品；開發部下轄若干開發小組，每一個小組負責開發 一個或者一類產品。測試部經理和開發部經理都直接向研發中心的經理彙報。當測試部經理和開發部經理在一些工做上意見不一致時，沒有人來直接作裁決，致使互 相扯皮。一箇中大型研發中心同時會有至少幾十個項目在運做，研發中心的經理在宏觀層面上掌控全局，根本無暇顧及每一個項目的細節，不少時候就職由測試組和開 發組的人來互相角力了。項目經理和產品經理在不一樣的公司裏話語權差別很大，常常沒法有效調和這些矛盾。
    在有些公司裏，部門會根據事業部/產品線來劃分。部門甲負責一個或者一類產品，下轄開發組，測試組，項目經理，產品經理，UI設計人員等。當開發組和測試組意見不一致時，由部門經理最終拿主意，對項目的成敗負所有責任。這種架構下狀況會好不少。
 
Q: 如何評價測試人員的工做？
A: 須要bug數量和經理的主觀感覺相結合。單純依賴bug數量，就如同單純依賴代碼行數來評價開發人員同樣片面。其一，Bug的數量能夠摻水；其二，作性能測試的人員所報bug數要遠遠小於作功能測試的人員，作測試開發的人員就根本沒有bug可報。
 
Q：在從事若干年測試工做後，你們都向哪些方向發展了？
A：根據我和身邊同事們所經歷過的各種公司的經驗，大體有以下幾種出路。
1）測試管理。管理職位是稀缺的，不是想作管理的人都能有機會去作，即便各方面能力都具有了。
2）轉開發。測試轉開發 比 開發轉測試 的難度要大得多，越早越好，轉失敗的不在少數。
3）轉售前售後技術支持、顧問、培訓。測試的好處在於對產品的整理理解和把握，同時研發的背景對於這幾個工種很是有益。
4）在測試的道路上長期走下去，作技術專家。這是大部分人的選擇，無論是主動的仍是無奈被動的。

附註：多年的心得濃縮成此文，如轉載，還望註明出處，謝謝！
熱烈歡迎評論或者和我郵件聯繫：
email: jjggww2002@sina.com  
MSN: jiangguowei2000@hotmail.com

嘿嘿，個人郵箱 ccg890811@163.com  QQ: 2412 2059 但願能和你們一塊兒學習測試！ 呵呵！！
------解決思路----------------------
不錯哦，看看
------解決思路----------------------
總結全面而深入. 每一個崗位都須要相似的總結