摘要：記錄我從畢業到現在的軟件測試成長之路，從初入測試之門，到深入了解測試，到現在的資深測試工程師，每個階段的收獲都有所不同，服役的每個公司學到的東西也不同。總之，都是一筆非常寶貴的財富吧
關鍵詞：軟件測試；測試職業發展；
引子
我03年畢業，剛畢業就進了一家國企，在綜合信息室的網絡中心工作，干了1年，覺得沒多大前途，主要是感覺在那里學不到東西，大學學的東西根本用不上多少，上班也就是喝茶（我還沒這個愛好）、看報，然后就是那個部門有了新郵件了就打電話過來，我給他們收收郵件，（因為我們單位是軍工單位，有些牽扯到國家 保密的資料，所以沒有上外網）。有時候哪個部門的電腦壞了，就打個報告讓我們計算機小組去維修，如果維修不了就報廢，我就簽個字，其他的一概不管，去這個單位，我收獲最大的就是給單位建了個企業網站，以前的網站太破了，剛進去，領導就給我分了這么個任務，以前沒接觸過這方面的東西，我也是邊學邊做，其間也是拖拖拉拉，反正廠里也不急，以前在學校學的都是些書本上的理論，真正用的上的也沒多少，在此期間，自學了dreamweaver、photoshop、 flash，還會點CAD，可憐的我大學期間沒有電腦，這些東西在大學就應該會的，我工作了才學。不過學了總比沒有學好，和我一同進單位的還有20多個學生，他們整整半年也沒干個啥，整天上班就是下車間實習，美其名曰：了解流程，但是他們在實習期間因為沒有領導管，車間的工人也不怎么認識他們，所以上班期間經常窩在宿舍睡大覺或者集體玩游戲，那時候真羨慕那些下車間的同事，羨慕他們不用上班，現在想想其實那樣也未必是好事。也因為我剛進去就有了要干的事情，所以年終給我發的獎金是我們那批學生中最多的，但是這樣我還是感覺在那里真的很無聊，完成了單位的企業網站，我就沒啥事情做了。春節過完后辦公室搬了新樓，我們又為新樓的網絡忙活了一陣子，測整個大樓的網絡通不通，我們使用的是局域網，好幾天都是在整個樓上跑上跑下，測試每個房間的網線通不通，這時候對硬件有一些了解了，忙完了這個后，我就已經覺得真的該跳槽了，否則我可能就要廢了。6月底我就請假去西安找工作，聽同學建議說我剛從國企出來，如果直接轉做軟件開發，可能不好入門，工作也不好找，做測試可能比較好點，運氣還不錯，很快我就找了份測試的工作，工作找好了先上了1周的班，感覺自己對這個工作還能應付得了，就回去辭職了，因為是沒到合同規定的時間辭職，所以我還交了3000的違約金，那時候我一門心思的想跳出來。
初入測試門，對測試了解很淺顯
我的測試生涯就是從04年7月份開始的，剛開始因為自己所在在得單位用到的開發語言是c++，可是我在大學就學了c語言，所以我打算利用閑暇時間自學c++， 每天都有要做的事情，我給自己訂了個計劃，每天做什么，看多少c++，學多少測試知識等等，雖然每次都沒有按時完成（可能我這個人比較懶散吧），但是我每天都在學習，這點我比較欣慰。剛開始接觸測試，感覺對測試理解的太淺了，覺得做測試太簡單了，就是拿個軟件隨便在上面用鼠標點一點，沒有邏輯性，剛開始也不會設計用例，后來隨著測試經驗的積累，感覺自己在測試行業還是個門外漢，很多知識需要加強，像配置管理，還有版本測試方面，我根本就不懂，有時候測試環境的搭建都要開發同事來幫忙完成，那時候感覺自己好笨，真想把什么都弄懂了，但是什么事情都不像自己想象的那么簡單容易，做了2個大項目的測試，都感覺不怎么理想。有的項目在馬上驗收的時候才發現bug，所以開發人員只能加班加點的在修改，我知道這是我的失職，但是他們從來沒埋怨過我一句，這讓我很感動。我還有個缺點就是臉皮薄，剛開始遇到bug，覺得不好意思給別人提，這也是那個項目最后延期的一個原因，也是我在測試中對bug的定位不夠導致，應該公私分明，是bug就是bug，不能因為覺得發現開發人員的bug了，就是得罪他了。另一個原因就是個測試人員介入項目的時間太晚了，我是項目開發后期才介入的，對項目的需求搞得不清楚，好多文檔都沒有，什么都要靠自己去琢磨，沒有概要設計和詳細設計說明書，以至于到項目后期，設計改了再改，而我這個測試人員有時候卻不知情，測出來bug，提交給開發人員的時候，他們卻說這個已經不是這樣設計的了。搞得自己干的很吃力，也很沒有成就感。到了第二年公司開發部經理打算實施 CMMII，全體員工都開始學習軟件工程和RUP，RUP2000上面說的那些可能不適合我們這些小公司，開發部經理就讓我們在一起討論，看那些該刪除，那些該修改，這樣的活動我感覺真的很不錯，每周都有討論交流會，把上周自己學習到的東西或遇到的問題提出來交流，最后公司制定了一套軟件開發管理制度，以后項目的開發管理都比較正規了，這也是我感到最高興的事情，因為管理正規了，測試工作也好開展多了。在此期間，我還自學了Rational 那套自動化測試工具， 已經能使用Robot進行自動化測試了，但是僅限于GUI測試，VU測試還在摸索階段。第二年3月底公司接了個項目，經理決定采用正規的開發流程，需求階段測試人員就介入，需求說明、概要設計、詳細設計和部署都要有詳細的文檔說明。詳細設計規定的一些軟件規約都要記錄在案以備以后測試或者修改之需，這次測試我感覺做的比較理想，但是肯定還有很多不足之處，那就是版本控制不嚴格，還有軟件的需求變更自己和開發人員溝通的不到位。現在我還在研究 ClearQuest，我想以后公司能夠用ClearQuest來進行缺陷管理。
…………………… 3、測試計劃
根據需求文檔和設計文檔，測試工程師準備測試計劃。測試計劃包括：相關文檔鏈接（需求、設計）、被測系統功能邏輯概要、測試內容、測試環境、測試任務分配及測試進度安排、是否需要性能測試等
4、測試用例設計及測試用例實例化
5、測試用例評審
主要參與人為開發工程師、測試工程師。
6、測試執行
開發提測后，開始測試執行
7、測試完成準備上線
待所有bug都關閉測試完成后，測試提交測試總結報告，等待上線。
8、測試總結
總結這次測試做的好的地方，以及做的不好的地方，好的地方繼續推廣給大家，不好的地方尋找改進措施。避免下次出現類似問題。
性能測試
在這里我能接手性能測試，這讓我對性能測試有了比較深入的了解。性能測試不論使用何種測試工具，基本測試思想是一樣的。即通過對被測系統加壓，尋找系統的最大壓力下的服務狀態。性能測試，首先是編寫性能測試方案，根據性能測試方案來開展性能測試。
……………………
查看全文請點擊下載：http://www.51testing.com/html/76/n-844176.html
6、測試工具
列舉出性能測試需要的工具，如http_load、loadrunner等。以及測試命令
7、測試數據
這部分很重要。性能測試根據不同的性能需求構造不同的測試數據，如查詢流程為A-B，如果A-B無結果，走A-C，如果A-C還無結果則走A-D，這時候就要準備這些數據，而且分幾種情況進行，根據線上數據分析，走各個分支的百分比，算出個百分數，然后準備各個分支的測試數據，最后再準備一份給系統帶來最大查詢壓力下的A-D的測試數據。
8、測試方法
壓力測試還是穩定性測試。
壓力測試：加壓條件，加壓命令，每次加壓多長時間，如何進行加壓的（這時候網絡拓撲圖就有他的價值了，從圖上可以看出是對那個模塊加壓的，是系統加壓還是分模塊加壓）
穩定性測試：正常壓力下，系統長時間運行，驗證系統正常提供服務，內存正常，無coredump等。
9、測試任務劃分以及進度
劃分測試任務，誰來造數據、多久能造好、誰來部署環境、多久能部署好環境、誰來執行壓力測試等
10、問題及風險
性能測試中可能遇到的問題，如性能差、測試時間短、測試工程師并行多個測試任務等，這些風險如何預防。
查看全文請點擊下載：http://www.51testing.com/html/76/n-844176.html
本文收錄于《51測試天地》電子雜志第二十九期。
版權聲明：本文出自51Testing軟件測試網電子雜志——《51測試天地》第二十九期。51Testing軟件測試網及相關內容提供者擁有51testing.com內容的全部版權，未經明確的書面許可，任何人或單位不得對本網站內容復制、轉載或進行鏡像，否則將追究法律責任。
查看全文請點擊下載：http://www.51testing.com/html/76/n-844176.html
測試更加深入
由于在上面一家公司的自動化測試基本已經非常成熟了，自己發揮的余地不多了，2年后，我又跳槽進入了互聯網行業，這次跳槽，基本是從通訊行業到互聯網行業的跨越，通訊行業的特點是被測系統很龐大，測試周期長，測試質量要求很高。而互聯網行業的特點是被測系統不是很龐大，測試周期很短（為了適應市場快速發展的需求），測試質量要求沒有通訊行業那么高。互聯網行業，往往為了搶占市場先機，快速開發一個產品，測試只要沒有太大的問題，就能快速上線，這里沒有所謂的bug收斂度，也沒有版本的概念，就是需求測試，新增需求或者修改需求。這里由于存在的變數比較多，所以很多東西都沒有像上一家公司那么固化，有自己可以發揮的余地。比如測試自動化、測試策略等。每次接到新需求都和前一個需求存在很大的變數，比如你現在測的這個是使用c++實現的，下一個你要測的可能就是用java實現的，比如現在你接手的這個項目是搜索引擎測試，下一個你接手的項目可能就是離線任務計算的測試。所以需要不斷的學習才能適應不斷的變化。在這里也是非常鍛煉人的。讓你不斷的學習，不斷的接收新的東西，不斷的有成就感。總的感覺是工作的很happy。
測試流程
這里說說互聯網行業的測試流程。來了一個新需求后，下面的測試流程一般是必須有的
1、需求評審
產品經理、開發、測試一起來review下需求，確認該需求是否可實現，是接受還是拒絕
2、設計評審
需求評審通過后，開發開始根據需求進行設計，并進行設計評審，參與人：開發相關人員、測試人員