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

一不留神，畢業後在軟件公司裏已經工作七年多了。期間經歷了民企、國企、美國硅谷小外企和大型外企，做過正規軟件開發（團隊規模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: [email protected]
MSN: [email protected]