我的測試經歷（一）

從事軟件測試行業至今已經有四年半的時間了，在這四年半的時間里，我已經從助理測試員成長為一名專業的軟件測試設計師，在這里我只想通過自己的工作經歷為剛剛從事這個行業或者想從事這個行業的新人提供一些制定未來發展目標的參考。

我的第一家公司是個只有幾十號人的私企，專門成立了軟件測試部，這非常難得。作為一名應屆生，我能夠從事自己喜歡的專業工作也很幸運，我的工作是在對軟件測試“零”了解的基礎上，從摸索學習中開始的。

剛開始工作的時候，沒有人給予專業方面的指導，因為每個人都有自己所負責的工作，抽出時間來指導你就會耽誤別人的時間，所以，學會“怎樣自學”才是最基本的生存之道，這種能力是在大學的課堂上學不到的，也正是因為這樣，有很多人以坐以待斃的方式等待成手的指導放棄了自己學習的機會，最終導致被淘汰出局。幾年前關于軟件測試方面的書籍寥寥無幾1，網絡上可參考的資源也少得可憐，經驗幾乎都是從動手實踐中得來的。最初接觸軟件的時候什么都是新奇的，熟練的掌握該軟件的所有操作步驟是首要任務，放下身段把自己當成什么都不懂的普通用戶，仔細的操作它把不太了解的細節或是操作不通的地方記錄下來。那么，下一步就是跟熟悉這個軟件的所有人去了解之前的操作應得出的正確結果，重點了解那些被記錄下來的問題，明白什么樣的結果才是這個軟件所需要的。后來我才明白做到這兩項，其實就已經朝著軟件測試的專業領域邁進了一步。我從工作的第一天起就養成了記筆記的習慣（手寫的那種），后來證明這種習慣對我的專業技術成長起到了非常重要的作用。

我的工作任務就是：操作軟件à從操作中找出BUG（錯誤）à告訴開發人員修改à重現BUGà告訴開發人員修改à驗證修改好的BUG，在這種工作方式中我不會去關心BUG發生的原因，修正這種BUG為什么會帶來更多的問題及什么是測試用例。當時我所負責的工作其實更應該稱為“軟件測試執行”，因為執行測試的人員不會去考慮軟件操作以外的事情。后來單獨負責起一個小軟件的測試時，在非常緊急的情況下，要求按照測試用例執行（我們以前都是手工執行測試，沒有測試用例可參照），寫用例的時間只有兩個小時，寫好后馬上開始測試，沒有辦法我硬著頭皮第一次寫了測試用例（雖然現在想起來只能稱之為測試大綱的東西），但僅僅是簡單的用例，卻對我的測試工作起到了非常重要的作用。它使我的測試方向更清楚，發現BUG以后能夠更好的協助開發人員定位問題，當然修改重現BUG的時間、修改BUG的時間也大大縮短了。這一次的甜頭使我認識到了“測試用例”的重要性，所以每當負責某一軟件產品測試之前，我都會自己列出相關的測試大綱，在測試的過程中逐漸去完善并且執行，在最后的兩個版本中完全執行一次，經過時間的累積，選擇了合適的模板后，成熟的測試用例出爐了。在執行的過程中，我考慮一些測試執行速度與代碼開發速度等軟件產品相關因素的協調結果，這個時期我才進入了初級“黑盒測試階段”，上述考慮到的那些問題就是最基本的“測試流程”，在技術角度講我又向前邁進了一步。

打這以后，網絡成為了我重要的信息來源，一有時間我就會從網上尋找一些軟件測試的相關資料來充實自己，從中我了解到了“軟件需求”、“測試管理”和“自動化測試”的概念，我們已經采用了TestDirect來進行測試管理，所以我只嘗試了使用WinRunner來執行測試，至于“軟件需求”是我后來才領悟到的。對某個軟件操作的熟練了，并不能證明了解該軟件的需求，只能說明工作的時間長了對這個軟件的特性有了一定的了解。在很多情況下，沒有明確的文檔來定義某個軟件產品的需求，積累了一定經驗的測試人員會根據自己的工作心得來判斷軟件是否符合客戶群體的需要。這種工作經驗的積累不僅體現在軟件測試技術方面，更多的將會體現在軟件專業領域上，比如說從事網絡相關軟件的測試工作就得了解相關網絡知識、網絡技術動態等等。擴展了行業知識，才會對該行業的軟件功能特性的制定具有一定的發言權。在這里我還要啰嗦幾句，英語真的非常重要，因為很多技術資料都是英文的，畢竟軟件測試是國外興起的行業，及時的信息一般都不會被翻譯成漢語，學好英語很有助于專業水平的提高，同時再奉勸幾句，對于工具大家最好還是用英文版的好。我的測試經歷（二）

我的第二個工作單位，是規模較大的軟件公司。與以前不同的是，新的工作單位是做某一類產品的研發而不是單指某一個產品，在產品立項之前，會經過嚴密的市場考核，N多次需求討論才會確定最終的開發方案，這兩個任務做完以后PRD文檔、需求文檔才會陸續出臺。這個過程在下面的敘述中會更加詳細的。

相信很多在小企業工作過，后來又跳到大型企業的人都會遇到這種尷尬的局面 “小企業來的，沒見過世面，什么技術啊、流程啊都不懂”。在這種時候大多數人都會熱切的去表現自己，很少會冷靜下來做這樣的事情：一、分列出自己以往所擔任的工作、自己的角色；二、自己在項目經驗和技術能力方面的優、缺點；三、目前的項目組的工作性質、需要的人員角色；四、目前所需要的項目經驗和技術能力。當然上述四個方面也可以加以細化，列出這些以后，自己的優勢與劣勢就顯而易見了。還有一種方法，就是查相關的崗位能力字典，大多數的大型企業都會制定比較完善的崗位能力手冊，不妨查查看，自己的實際情況符合哪些條款，哪些是有待加強和學習的，了解自身的缺點進步才能更快一些！

我最初的工作任務是了解產品的用戶手冊（因為涉及保密的問題概要設計文檔和需求設計文檔必須在轉正后才能看到），閱讀產品手冊是一項非常枯燥乏味的工作，它的描述并不能幫助我理解產品的功能特性，但是卻幫助我了解了產品的操作方法，對以后的測試很有幫助。很幸運的是在入職半個月以后，正趕上個人工作季度總結的評估，每個人都會根據一本“個人行為能力手冊”來評估自己在業務、技術等方面的分數，也就是從這個時候起，我認真的看了他們對“軟件測試工程師”這一職位的要求。的確，自己還有很多不足之處，比如說我欠缺相關的行業知識，以往沒有考慮過行業知識會對測試有什么影響，在這方面并沒有下功夫去學習，既然現在的工作對行業知識有所要求，那就必須去了解它了。接下來的一個半月的時間，我是在學習行業知識中度過的，每天都是自己在看書幾乎不同其他人交流，當知識積累到一定程度的時候，我才體會到行業知識的積累對于測試來說真是如虎添冀，它能夠更加明確測試的目的，減少測試中的盲區，這就好比一個人在黑夜中行走，沒有燈光的指引全憑著感覺，那么碰壁就在所難免了，行業知識就好比是黑夜中的燈火，指引前進的方向。在這期間我經歷了兩次業務考核答辯，有點像大學畢業時的那種，答辯內容是根據每個月的學習內容來確定的，我從第一次的自信滿滿到第二次的尷尬落逃，心理上承受了相當大的落差，反思這兩個月的學習情況，最大的失敗就是從不主動與他人交流，其中也包括我自己的導師（新員工都有一名老員工帶領，這就是導師制度），對自己的學習能力過度的自信，不去了解學習的重點，自己對某一知識點理解有偏差的地方，甚至是不明白的問題就那么一帶而過不去深究。我犯的這個錯誤是十分不可取的，過度的自信就是自負，一個人的能力是有限的，特別是在學習新知識的時候，虛心請教有經驗的老員工會得到事半功倍的效果。在第三個月中我與導師一起補充由于第二個月學習效果不佳而欠缺的行業知識，同時也開始了測試執行的工作。經過我們一個月的共同努力，終于在第三次轉正答辯的時候獲得了領導的好評，記得當時我的導師比我還要緊張，答辯完畢看到領導的笑臉時我們倆都松了一口氣，從此，我開始了新的工作旅程。

我的測試經歷（二）

剛開始的一個月就是按照現成的測試用例去執行，但是慢慢的我發現，原有的測試用例不太適用于當前的測試任務，一是測試用例覆蓋率1較低，如果完全按照測試用例來執行，會有很多遺漏的功能點走不到；二是執行流程不好，比如功能點1執行完畢以后，執行功能點2會節省測試時間，而且從功能特性的角度來講流程更順暢，但是原有的用例卻沒有按照這個順序來編寫；三是用例中關于操作步驟和期望結果的描述不明確，不易于理解或是容易產生誤解。根據上述三個問題，我決定從一個較小的功能模塊著手重新設計測試用例2。我先是整理出了該模塊的功能特性，然后做了一個類似連線的表格，這樣就明確了各功能點之間的關聯，對于確定功能點測試順序有很大幫助，接下來就是確認測試用例的分類了，我將測試用例大概分成如下四類：基本功能測試用例，異常情況測試用例，關聯性測試用例和壓力測試用例。基本功能測試用例，顧名思義，就是指測試某一具體模塊的常用功能，用以驗證功能的完整性、可用性、可執行性；異常情況測試用例，是指在網絡、數據庫連接異常等突發狀態下軟件的穩定性；關聯性測試用例，是驗證有功能關聯關系的各個模塊之間，執行測試后的運行結果；壓力測試，用于驗證大數據量的情況下軟件的穩定性。

測試用例剛剛完成，我們就進行了交差測試，新接手的測試人員說新用例比以前的老用例易于理解操作起來很方便，而且功能點含蓋得很全面，在周例會上他講了自己的看法，并且把新的測試用例拿給大家評審，最后得到了大家的首肯“可以應用到系統測試執行當中”。這次的成功，為我以后的工作得到認可奠定了堅實的基礎。接下來我對核心模塊的測試用例進行了修改，仍沿續以往的風格，但采用了不同的思路，因為第一次的成功，測試負責人對修改測試用例的工作很重視，每完成一個模塊都會召集大家進行評審，經過三次評審以后，大家對我的用例編寫水平給予了充分的肯定，在測試管理工具上給我分配了修改測試用例的權限。我，在軟件測試工作師的道路上又前進了一步。

說一下當時我們的工作情況，我們項目組做的產品處于研發階段，一直沒有面向市場營銷，雖然部門內部制定了相關的時間表，但時間點執行并不是十分嚴格，工作用時相對比較寬欲。就測試這方面來講，我們黑盒測試人員只負責系統測試，每一版本的測試分為接收測試（0.5-1工作日）、系統測試（12工作日）、發散測試（3工作日）三個階段。接收測試階段，驗證產品功能的完整性，評估產品質量是否達到系統測試標準，如果已達標則進入系統測試階段，否則返回給開發人員修改；系統測試階段，全面的執行各個子模塊的測試用例，檢查各個功能點；發散測試階段（我們也戲稱為發瘋測試），不考慮測試用例，進行測試用例外的各種嘗試。我有很多靈感都是來自于發散測試階段，因為沒有了測試用例的約束，想象的空間得到充分發揮，很多意想不到的思路就產生了。持續一段時間只執行某項固定的工作，很容易使人產生倦怠的情緒讓工作失去原有的生氣，測試工作尤其如此，所以我覺得測試人員應該隨時抱著一顆好奇心，發掘新奇的東西，這樣才會找出更多的問題。

在工作的同時，我也跟開發人員學到了不少的東西，他們教我一些瀏覽代碼的技巧，當然也要求測試人員有一定的編程功底。在我對代碼就比較熟悉以后，偶爾會幫助開發人員定位BUG或是提供一些修改意見。記得有一次，我發現了一個能夠導致整個軟件系統死鎖無法操作的BUG，開發人員用了兩個多小時修改了很多次，問題還是沒有解決，情緒有些急躁，后來我跟他一起看了那段代碼，我發現是一個變量的返回值寫錯了，糾正了這個小小的錯誤，上述看似很嚴重的問題就解決了。

部門領導為了提高大家的測試技術，特別組織了一次為期一個月的培訓，包括溝通技巧、黑盒測試技術3、性能測試、自動化測試工具四門課程。

其中溝通技巧這門課是同時面向測試人員與開發人員的，講述了互相矛盾、互相對立的兩個不同職位的人員應該采用什么樣的溝通手段，很高興的是講師非常同意我“測試人員與開發人員是朋友”的觀點，向他人微笑得到的回報同樣也是微笑，與“予人玫瑰手有余香”是同樣的道理，因為不論是開發還是測試，都是團隊的成員，那么只有朋友才會一心一意為著共同的利益和目標努力。這次培訓也讓我第一次明白團隊的確切含義，一個團隊小到可以說具有相同工作性質的團體，比如一個項目組中的測試組可以叫一個團隊；有共同前進目標的團體，比如一個部門也可以稱為團隊；再或者有共同經濟利益的團體，比如一個公司。不同規模的團體有著不同的利益，小利益服從大利益才會獲得更多的經濟效益，所以那些一味把小團隊的地位放在首位，不去考慮大團隊的利益的人，最終會被團隊所淘汰。

另外兩門課程都是面向測試的專業技術培訓，不是很系統，但知識面卻很廣。我比較感興趣的是黑盒測試技術和自動化測試工具這兩門課。關于黑盒測試技術，因為講師并不善長此項，所以培訓的內容基本都是照本宣科，理論與實踐完全脫軌，并且遠不及網絡上的資料來得全面，對于工作沒有什么實質性的幫助。自動化測試技術的課講得很生動，主要介紹QTP（QuickTest Professional）4和LR（LoadRunner）的使用，只可惜，因為我們的產品性質和質量的原因，一直沒有機會在實踐中系統的應用。