一個軟件測試工程師的工作心得(轉)

寫這篇文章主要有兩個目的。
　　1、 對自己這一年零八個月的工作進行回顧和總結，把第一份工作的記憶都寫下來；
　　2、 自己做了一年多的軟件測試工程師，對軟件測試工作算是有一定程度的了解，希望與大家分享我的感受和經歷。
　　
　　先介紹一下我的背景：通信類院校05年畢業、本科、計算機專業，畢業后進入一家大型通信設備商工作，任職軟件測試工程師。
　　
　　一、T項目執行
　　
　　05年7月13日入部門，此時才知道自己被分配到了測試部。部門主管把我領走后，就把我交給了導師。
　　
　　入部門的頭幾天，主要熟悉公司的工作環境，認識部門同事，了解產品知識。由于我們是做傳輸設備的，所以當時學習的產品知識主要以SDH原理為主，包括SDH的幀結構、網絡的保護和倒換等。
　　
　　下面介紹一下我所做的項目。
　　項目名稱：T軟件
　　
　　項目概況：該項目是在PC和Sun工作站上開發的軟件，屬于CS結構。Client端用Java開發(開始使用JDK1.3，后來改用JDK1.4)，實現跨平臺；Server端用C++開發，使用ACE實現跨平臺（Windows和Unix）。
　　人力投入：開發好像是9人，測試3人。（我來的時候是產品的第2個版本，人力投入大概如此）
　　
　　我入部門幾天后，T項目就進入了測試階段。我的任務就是執行分配給我的測試用例。當時我只知道根據測試用例描述的內容，去點鼠標，如果發現程序出現錯誤或異常，就填寫問題單。我就這樣沒有任何思考的按著測試用例點了3個月的鼠標 : )
　　
　　現在想起當初的測試工作，實在有太多的不足，和待改進點。
　　
　　1、 測試用例。對于一個軟件的測試來講，測試用例是至關重要的。測試用例要覆蓋所有測試規格，而且測試用例要易于理解、易于執行，簡單的講就是要描述的規范。而當時我們的測試用例卻是一團糟，最糟糕的是用例的質量很差，使用這些測試用例，根本無法保證產品質量。測試用例的預置條件、操作步驟、預期結果的描述也是亂糟糟的，而且用于存儲測試用例的Excel表格設計的很差，界面很不友好，從一定程度上降低了測試效率。
　　
　　2、 產品知識。T軟件雖然是在PC和工作站上運行的，但是開發T軟件的目的是為產品服務的，所以我們必須具備產品知識，才能更好的對T軟件進行測試。恰巧當時包括我導師在內的3個人，都不太了解產品，所以就造成我們無法判斷某些測試用例是否驗證通過。從而導致了與開發人員的多次爭吵。

　3、 軟件測試的重點不明確。軟件測試是軟件工程中的一項重要活動，它盡可能發現程序中存在的缺陷，保證程序的質量。但軟件作為一種商業品，有它的發布時限，老板說這個軟件要1月份發布，你總不能測到12月份再給他發布吧。當時我們在一些小問題上與開發人員糾纏過多，而很多重點卻沒有得到重視，一些嚴重問題暴露的比較晚，導致測試時間延了又延，版本測了一個又一個，想起那些日子，只能如此描述：“累并痛苦著”。 : (

4、 測試流程的把握。7月份中旬，T項目從開發部轉到測試部，進入了測試階段，實際當時的產品質量并不能達到轉測試的標準，而我們卻讓他們通過了轉測試，結果就給我們自己帶來了巨大的痛苦。而且后續的幾個版本也如此，我們是測了一輪又一輪，測的我們都要絕望了�；仡^想一想，T軟件還真的是我們測出來的，而不是開發寫出來的 : )

5、 缺少針對性測試。軟件也可以分很多種，不同的軟件有不同的特點，自然就需要針對性的測試了，譬如GUI的軟件與嵌入式軟件的測試方法肯定有很大不同。最初我們在做T項目測試時，就缺少針對性方法。有兩個教訓讓我們刻骨銘心：1、界面測試，T軟件發布后沒多久，其他組同事就發現某界面一個按鈕的單詞拼寫錯誤——“rollback”被寫成“roolback”；2、效率測試，軟件測試到后期才發現T軟件在實際環境中運行效率很低，根本無法滿足達實際應用的需要。從那以后我們就準備了專門針對T軟件的測試項目，包括：界面測試、效率測試、資料測試、穩定性測試等。

6、 溝通問題。自從工作開始，開發人員和測試人員的爭吵從來就沒有停止過。最初是什么問題都吵，很多沒有意義的爭吵甚至非理性的爭吵，慶幸的是現在的爭吵大多是有針對性的、理性的。個人覺得以前無為爭吵過多的原因是：開發人員、測試人員的工作技能和職業素養都比較欠缺。吵了大半年后，人員提升了工作技能和職業素養后，吵架都吵的比較有默契了。當然最重要的是開發人員和測試人員的目標要一致：保證產品的質量，滿足客戶需求。

二、自動化測試
　　06年過完年后，我被主管派到一個大組去學習自動化測試技術。這個測試組是個比較大的測試組，總共有幾十號人，其中有很多牛人。他們的自動化測試框架就是由幾個牛人耗時1年多開發出來的。到現在，他們的自動化用例覆蓋率約50％，應用率好像有70％，總之這個自動化測試框架還是滿牛X的，不過就是整個框架實現太復雜了，涉及的編程腳本就用了三種 : (
　　
　　下面簡單介紹一下該GUI自動化測試框架。
　　測試工具：IBM Rational Robot
　　自動化測試技術：第三代自動化測試框架，叫什么DDE，具體什么意思已經記不住了 : )
　　測試腳本：Robot中使用的是sqabasic腳本（基于basic的一種腳本），另外還使用了TCL、COM組建等，并自行開發了一個抓包工具用于自動化測試。還有我們測試的產品界面是使用Java開發的，如果要讓Robot能夠正常識別界面，還需涉及到Java編程。呵呵，實現上可是夠復雜的 : (
　　
　　學習自動化的頭一個星期，我只是學習該測試組的產品知識，學習如何使用自動化測試。后面的幾個星期就開始承擔自動化測試的建設任務了。想想當初自己還是滿辛苦的，白天上班學習產品知識，晚上回家就對著電腦看basic腳本的語法，周末還去公司無償加班看代碼。

在技術文檔的選擇上，我基本只看英文的，單詞不懂就拿金山詞霸查，實在看不懂了才會去找些中文的資料看。為什么要選擇英文的呢？因為很多中國寫書的人很浮躁，只想著快點把書出版了好賺錢，所以很多中文的資料質量很差。首先要貶低的就是那本譚教授的《C語言程序設計》。記得讀大學時，照著譚教授的書敲程序，沒多少程序能編譯通過的，真是誤人子弟。
　　當時帶我學習自動化的導師姓L，他是個大忙人，有時一整天都在開會。L的師傅姓W，W是該自動化創始人之一。我呢，充其量算是徒孫一輩，呵呵。由于L太忙，而且不那么愛說話，于是乎我就只能自己對著文檔看代碼。
　　當時對我比較有用的文檔就只有兩篇：一篇是匯集型的chm文檔，是篇比較全面的介紹，其中包括自動化框架的介紹，原理的介紹，各模塊介紹，自動化執行的流程等；另外一篇則是由W寫的自動化建設指導書，寫的還是滿不錯的，在我有一定基礎后，照著指導書就能完成簡單的自動化建設。

在我整個學習過程中，是按照以下的過程開展的：1、初步了解整個自動化和產品知識，嘗試使用自動化進行測試；2、熟悉sqabasic語法；3、對著文檔讀代碼，嘗試調試腳本，跟蹤到代碼的最底層。
　　其實最好的學習方式就是實踐，去做自動化建設。當有一定基礎后，去完成導師交給的自動化建設任務，就是最好的學習方式。后來，我教別人的時候，也是安排實際任務給他做，然后再進行相應的引導。
　　在我的學習期間，有件事情讓我滿討厭的。就是我必須給原部門的主管和測試組人員講課，然后那些家伙會不停的提問，以檢驗我的學習效果。雖然這招很BT，但是對個人的成長還是滿有利的。假設你學會了一項技能，此時你可能只在第一個層次上，如果你能夠把這項技能教會別人，那么你的層次上升了一個檔次。
　　記得當時是06年2月初去參加學習的，4月初就應急被調回原測試組了�？偣膊坏絻蓚�月的時間，我總共完成了3個模塊的自動化建設，第1個模塊搞了3個多星期，第2個模塊不到2個星期，第3個模塊一個星期就搞完了（第3個模塊算是友情支援呢，哈哈）。
　　4月初被調回原測試組后，就一直做救火的工作。差不多5月份的時候才正是開始做我們T項目的自動化。其實也就是把我學習的自動化框架移植過來，做T項目自動化測試。
　　另我比較遺憾的是，T項目的測試一直都很緊，而自動化測試并沒有被推廣和充分利用。直到我離職前，測試組為應付測試部自動化考核指標，才得到重視。

這里我談一下自己對自動化測試的理解。
　　1、 自動化測試用于提高測試效率；
　　2、 自動化測試可以完成一些無法手工完成的測試，例如長時間不間斷的測試；
　　3、 自動化雖然能夠發現問題，但主要是對繼承的功能進行測試，保證以前的老功能。（這個跟項目有關， GUI自動化測試比較復雜，如果是嵌入式設備或芯片的自動化測試，對自動化測試的理解可能會不一樣）

三、開發小工具
　　我在自動化學習期間，表現出來的專業技能和良好的學習能力，得到了同事和主管的認可。鑒于此，在4月中旬的時候，測試組的Leader給我安排一個任務，使用Excel表格開發一個工具，用于收集和統計記錄的數據。要求該工具能夠代替手工計算，提升測試效率。任務完成的截至日期是五一。給我安排的時間大概為一周。
　　該工具的實現方式并不難，就是設計一個Excel表格，然后在里面嵌入VBA腳本，以宏的方式代替手工計算。對我來說最大的挑戰就是：1、短時間內學會VBA編程；2、提取需求，設計Excel表格的格式，使該工具具有較好的易用性。
　　當我接到任務后，下班回家就開始到網上搜集關于VBA資料。當時我找了一個星期，都沒有讓我滿意的文檔。最終只找到一篇國人寫的PDF文檔，但是那篇PDF文檔只是讓我初步了解了VBA是個什么東東，并不能滿足我的實際需求。最終，在寫VBA腳本期間，我還是參考微軟自帶的幫助文檔搞定的。（搞忘球當初是否裝了MSDN）

本來計劃是在四月底的一個星期開展該項任務，但實際上直到4月的最后兩天我才有時間。記得當時，我花了一天半的時間與我的客戶——也就是我的同事，共同討論需求，并設計Excel表格的格式，讓其評審。最終寫腳本花費了4月的最后一個下午，以及五一期間的三個下午的時間，總計4個下午的時間，完成該工具的開發。而且我五一期間的工作并沒有申報加班，是無償勞動啊 : (
　　另外，令我欣喜的是，從此我成了我們組的“牛人”，哈哈哈哈。。。。。。
　　其實工具開發完成后，還是有些問題，如：
　　1、 程序崩潰（不小心除了0，呵呵，加入異常處理就OK了）；
　　2、 有1/3的功能基本沒有被使用（郁悶，花那么大精力。。。我的五一�。�；
　　3、自動生成的表格，奇丑無比（直到現在，我都沒改，哈哈）。
　　
　　記得當時有個做了5年以上C++的開發人員，看到我寫的Excel表格，居然說“誒，這東西還滿神奇的嘛”。我當時的一個感覺就是，暈，這個家伙工作效率肯定不高。
　　Excel還真是好用，功能強大��！

四、負責M項目測試
　　06年10月份，我開始獨立負責M項目的測試工作。M項目是個小項目，大體情況如下：
　　代碼量：大約10K行
　　開發語言：C#
　　軟件環境：Windows PPC 2003
　　硬件環境：hp的PDA（具體型號忘了，反正是便宜貨，大概1000塊）
　　人力投入：開發3人，測試就我1人
　　M項目的測試需求分析、測試設計、測試用例編寫、測試執行到測試報告，全部由我一個人搞定。
　　
　　06年10月～12月中旬這段時間，主要是完成前期的測試分析與設計。12月中旬，就進入了實際的測試階段，07年1月底，軟件發布�；仡欉@4個月的工作，有做的好的，也有做的差的。下面對這些進行總結。
　　做的比較好的：
　　1、 測試進度把握比較好，在規定時間內，甚至提前完成了測試任務；
　　2、 與開發人員的溝通較好，使問題能夠較順利的解決，基本沒有內耗，雙方合作愉快；
　　3、 測試的重點把握較好，把很多嚴重問題，在測試前期就給暴露出來了；

做的不好的，待改進的：
　　1、 前期的測試分析能力較弱，測試規格分析不全，測試用例編寫質量不是高。到后期測試時，才發現很多規格沒有覆蓋到，需要補充測試用例。而且之前寫的測試用例與實際測試情況，有些偏差，用例的可用性差，又花了很多時間去修改用例。
　　2、 前期的測試計劃制定比較差，實際工作較之計劃偏差過大。反正10月、11月那段時間，M項目的工作是亂七八糟的，還好關鍵時間點的把握還算到位。
　　3、 測試對象選擇上疏忽，導致漏測。M程序是個工具軟件，主要用于查詢和設置設備的某些參數或配置。我當時只考慮到對所有支持的設備進行遍歷，卻未考慮到設備上所有單板的遍歷。結果技術支持工程師到香港試用該工具時，發現某塊叫PM1D的單板無法識別。后續，我們對大部分單板進行了遍歷，還發現了很多隱藏的問題。這是一項較大的疏忽。
　　4、 在做內部模擬試驗局測試時，對測試環境的選擇有較大疏忽，導致漏測。在做內部試驗局的時候，我為了偷懶只選擇了3個不同設備的組網測試，而沒有考慮到大規模組網情況下的測試。后來，技術支持工程師拿M軟件到廣州試用時，程序的某項功能就不正常了，原因就是大規模組網時，通信數據的傳輸是多包的，而M程序的底層函數沒有對多包的情況進行處理，導致該項功能不正常。當時，在其他實驗室是有類似環境的，而我卻為了偷懶 : (
　　
　　雖然M項目的測試有很多不足，但是總體情況良好，我對產品的質量有信心 : )

五、救火
　　大概是06年7月份時，我們組組長跟我說，要派我到B組去學習3個星期。等我去了B組才發現自己是被派來救火的。來B組支援測試，主要是完成一項測試任務，說具體點，就是把一件事情干600多次，沒任何技術含量。我當時真是郁悶壞了 : (
　　
　　雖然心底是比較郁悶，但畢竟也就3個星期，想著忍忍就過去了。
　　具體的任務很簡單：大概有80種板子，每種板子大概有8套軟件，用T工具對80多塊板子把8套軟件都加一次，觀察軟件加載過程中，業務是否正常，板子加完軟件后，運行是否正常。
　　
　　還有一個也是其他組借調過來的新員工，跟我一起干這件事情。我600多次，他也差不多600次。還好這個家伙，心態很好，做事情也很勤奮。
　　
　　最初B組給的方案是這樣的：先用第1套軟件把80多個板子加載一遍，再用第2套，第3套，直到第8套。
　　
　　開始工作幾天，我們就按這種方案執行，但按這種方案執行的效率很差。主要因為實驗室常用的板子差不多只有30塊，其他的板子都藏在箱子里，而且有些板子B組根本沒有，需要到其他項目組去借，這樣針對軟件版本，對80多塊板子進行輪循加載，效率就很低，因為每加一套軟件，就要去尋找80多塊板子。
　　
　　當時，我和那個新員工都很愁，按照這種做法，這項任務3個星期根本就無法完成。B組負責帶我們的兩個員工，也表示比較無奈。
　　
　　郁悶過的第2天一早，我就直接找B組的老大談話，“按照你們提供的這種方案，我們在三個星期內根本無法完成任務，而且還有諸多其他困難：1、部分板子是壞的；2、某些板子實驗室里根本就沒有；3、對設備不熟悉�！�
　　
　　就這樣，B組老大把組內相關骨干人員都叫過來開會，重新商討了一套方案，并要求他們全力支持我們的工作。
　　
　　開了會后，B組的人就比較支持我們的工作了，啟用新的方案后，還提前了1天時間把工作完成 : )
　　
　　這里我體會比較深的是：在做一份工作前，一定要弄清楚這項任務到底要做些什么、要怎么做、要做到什么程度，工作中還要定期匯報工作（基本上以日報、周報的形式，用郵件發送），如果出現了解決不了的困難，一定要向老大匯報，如果老大也解決不了，那他也不能責怪你無能 : )

六、工作中的陷阱
　　在辭職前的幾個月，有個師弟也是老鄉X君，得知我做過自動化項目后，便來向我了解自動化測試相關的情況。
　　
　　從與X的聊天過程中了解到，他也正在做自動化，他們組測試的產品規模比較大，不過做自動化的只有兩個新人，而且是使用一種新的GUI測試工具。他在給我講他們具體工作時，了解到他們的自動化測試非常原始，就是針對一個用例錄制一套腳本，幾百個測試用例，大概錄制幾百個腳本，根本沒有對公共進行提取，更別提有什么自動化測試框架了。X君與另外一個人，在自動化方面都是新手，沒有相關經驗，他們不知道這樣做會給后期的維護帶來多大的麻煩。而且他們主管也不太懂GUI測試的自動化，只是每天要他們匯報工作進度，期望在兩個月內完成那幾百個腳本。
　　
　　經過我細致詢問后，我猜測他們做這項自動化工作，基本上是為了應付部門自動化考核而做的，而并非為了提高測試效率，保證產品質量。
　　
　　我也可以體諒X君主管的難處：測試組人力本來就緊張，而部門又要考核自動化指標，他只有弄兩個人來應付一下部門的考核了。
　　這樣說來，X君和他另外一位同事就是受害者了，被安排做一件這么沒意義的事情。對他們我只能表示同情了。
　　
　　對于這類BT主管吩咐的沒啥意義的事情，我的體會就是能推掉不做就不做，如果實在推不掉，就完全按照他的意思做，他要怎么做就怎么做，要做成什么樣就做成什么樣。實在搞郁悶了就老板炒魷魚吧。
　　
七、其他
　　記得剛進公司那一陣，對我們新員工有這樣那樣的培訓，估計轉正前至少被培訓了20門課吧。具體講的都是產品知識、測試技能、編程方面的東東。那些講課的老師水平也參差不齊，PPT寫的水準也有好有壞�？傮w感覺就是那些培訓是在浪費時間，如果自己看這些資料效果都要好很多。
　　
　　在轉正前，作為新員工要給部門的“老”員工講課，講自己所學習過的知識，然后下面的“老”員工會發狂了似的問你問題�，F在我感覺這種方式真的是一種非常好的檢驗方法，不但檢驗了你的學習情況還鍛煉了你講解PPT的能力。
　　
　　通過這種方式，我覺得自己在很多方面有提高：
　　1、 寫PPT的水平。后續工作中，寫PPT匯報工作，做的是又快，又漂亮。
　　2、 溝通能力。最初別人問我一個問題，我還沒完全理解他的意圖，就以自己的理解，淅瀝嘩啦的說了一堆別人不想知道的東東，搞得別人一頭霧水。此后，別人每問我一個問題，我都會先把他的意圖或意思搞搞清楚了，確認后，再以最精練的語言來回答他的問題。
　　3、 懂就是懂，不懂就別亂說。記得最早“老”員工問我一個我自己不是很懂的問題，我通常是按自己的理解方式，跟他胡吹一通。結果他再一細問，我就傻了。知道就知道，不知道就別亂說，這點很重要，尤其是在參加面試的時候，如果自己不是很動，別人一問你就會露餡。
　　
　　寫到這里，第一份工作的感受也寫的差不多了�？偟膩碚f可以如此形容我這份工作：任務重、壓力大、加班多，雖然公司也存在各種各樣讓人非常不爽的事情，但打心眼里我還是感謝它的——是它讓我明白了什么是工作，鍛煉了我的學習能力、抗壓能力、溝通能力，培養了我的職業素養。雖然也有非常多的人在罵公司，但我希望它還是能越走越好�。�！