軟件測試工程師的角色定位分析

　　(1) 測試最重要的一件事就是要考慮到所有的出錯可能性。同時，還要做一些不是按常規做的、非常奇怪的事。

　　說起來可能不太好聽，測試的過程就像黑客 (Hacker)的攻擊過程那樣?？梢赃@么說，像黑客這樣的人是最好的軟件安全測試員。他們專門找軟件的漏洞，從而破壞這個軟件，這樣就可以修復這些漏洞保證軟件的性能。如果找不到這種漏洞，那就說明該軟件質量己經很好了。

　　(2) 除了漏洞之外，測試還應該考慮性能 (Performance)問題，也就是一定要保證軟件運行得很好，非?？?，沒有內存泄漏，不會出現那種越來越慢的情況。

　　我們可以在不關機的情況下，與其他軟件一起持續運行一個多月，看看是否會出現越來越慢的情況 (當然必須保證其他軟件是沒有問題的 )。我們在做 IE的時候，就是讓它 72小時連續不停地打開不同的網頁，處理幾萬個不同的網頁，而且速度不能減慢。有許多軟件，當只有一兩個人用的時候，可能感覺不到什么問題，而當幾百個用戶一起用的時候，有的網站就出現各種各樣的異常，這就是測試工作還比較欠缺的原故。

　　(3) 另外，測試還要考慮軟件的兼容性 (Compatibility)。

　　一般來說，一個軟件是由許多小軟件構成的，如果其中一個小軟件與它的前一版本不兼容，那么這個軟件就會出現錯誤。這種錯誤需要通過測試來發現和解決。

　　許多人認為寫代碼的人一定能找出錯誤來。其實開發人員在寫代碼的時候，如果有錯誤，他可以意識到了，可是寫出來的錯誤，他不一定能想得到。我自己也編過程序，在編程序的時候很自信，覺得不會有錯，可事實上，即使是我編的小程序也有錯誤，但要自己找出來，卻要費很大勁。因為我一直認為自己不應該出錯，但常常錯誤就出現在我認為最有把握的地方。我是學數學的，是一個很細心的人，可是 --樣還是會出錯，但要找出自己的錯誤卻要花費很長的時間。后來我寫的代碼讓我的師弟幫我看，結果他很快就找到許多問題，可是我自己花一個月時間可能都找不到。所以，開發人員和測試人員完全不一樣，開發人員確實可以找到一些 Bug，但是有更多的 Bug是他意識不到的。

　　在一般的開發團隊中，并不需要測試人員定位 Bug的具體位置，所以，對測試人員的要求并不高。只要你愿意學，測試工作是非常容易做的。但是，我當年所在的 IE團隊 (IE 4.0)就不同，因為當時正在與另一個公司的產品競爭，所以微軟就要求盡量找到一流的開發人員和一流的測試人員，盡快開發出新產品，打敗對手。所以，當時對我們測試人員的要求非常嚴格，不僅要找出 Bug，而且要定位引起此 Bug的代碼行。然后將這些信息交給開發人員，后者就可以很快更正，省去了他們找錯誤出處的時間。因此，當時 IE的開發速度非?？?，一年之內就發布了一個新版本，而且幾乎役有任何大 Bug，大大超越了競爭對手。

　　Bug

　　Bug 的定義很廣泛，在軟件使用過程中所出現的任何一個可疑問題，或者導致軟件不能符合設計要求或滿足消費者需要的問題部是 Bug，即使這個 Bug在實踐中是可行的。

　　有時候， Bug并不是程序錯誤。例如，軟件沒有按照一般用戶的使用習慣來運行，此時也可以把這個問題看成是該軟件的一個 Bug。

　　首先，測試人員根據測試結果來報告他發現的所有 Bug。通常，這項工作還需要用戶的參與。微軟在正式發布一個軟件之前，經常要依次發布 Alpha測試版、 Beta測試版讓用戶試用，以便用戶能夠反饋出相關 Bug的信息。但是，現在隨著微軟測試隊伍的擴大及測試水平的提高，越來越多的 Bug都是我們內部的測試人員自己發現的，很少出現外部用戶所反饋的 Bug沒有被測試人員發現的情況。

　　然后，開發經理根據這些 Bug的危害性對它們進行排序，確定 Bug的優先級，并安排給相關的開發工程師。

　　接著，開發人員根據 Bug的輕重緩急依次修復各個 Bug。

　　最后，測試人員再對開發人員已經修復的 Bug 進行驗證， 確認 Bug是否已經被徹底更正。

　　微軟開發一個產品經常會遇到幾十萬條 Bug。隨著測試人員越來越多，測試工作也越來越完善。但是，如何快速有效地追蹤并修復 Bug，仍然是擺在軟件測試人員面前的一個主要困難。測試產品和追蹤 Bug時最重要的是問題的定義，要清楚需要解決什么樣問題，確定 Bug的主次關系，挑選出最主要的問題，并先解決它們。例如，有些 Bug可能會導致死機或程序崩潰，這時就要先修復它們，而另一些 Bug可能對軟件的運行影響不大，或者出現的機會很少，就可以考慮以后再修復。

　　可以說，沒有任何一個產品沒有 Bug，也永遠不可能找井修復所有的 Bug。在修復了舊的 Bug的同時，往往又會生新的 Bug。

　　這個過程就類似于數學中的“極限”的定義，盡管我們知道某個極限值為 0，但是它永遠也不可能達到 0。這也就產品的 Bug永遠也修復不完的原因。因此，我們在修復 Bug時要注意，一定要記住用戶最需要的是什么，然后優先盡力修復那些影響用戶使用的 Bug;而對于大部分對用戶影很少、甚至根本不影響的 Bug，則可以推遲修復，甚至不修復。

　　軟件測試階段及其職責

　?、?單元測試 (Unit Test): 按照代碼的單元組成逐個進行測試。

　?、?功能測試 (Function Test)或特性測試 (Feature Test): 按照軟件的功能或特性逐個進行測試。例如，在 Exchange中，發送郵件和接收郵件就是兩個不同的功能或特性，在測試時就分別對它們進行檢查，看是否工作正常。

　?、?提交測試 (Check-in Test): 在開發人員對代碼做了任何修改，或者修復了某個 Bug時，需要重新 Check-in代碼 (即將修改后的代碼放大到整個大的系統中 )。這時，開發人員往往也要進行測試，看代碼是否工作正常。為了保險起見，開發人員往往要找測試人員幫著一起進行測試 (我們把這種情況稱做 Buddy Test)。測試人員和開發人員之間搞好關系是非常重要的，稍后我會專門講述這一點。

　?、?基本驗證測試 (Build Verification Test，簡稱 BVT): 對完成的代碼進行編譯和連接，產生一個構造，以檢查程序的主要功能是否會像預期一樣進行工作。這是最簡單而又最省時的一種測試方法。每產生一個新的構造時都要進行測試。如果連 BVT部通不過，表明問題很嚴重，開發人員需要盡快修復出現的問題，測試人員也就不用浪費時間做其他測試了。

　?、?回歸測試 (Regression Test): 過一段時間以后，再回過頭來對以前修復過的 Bug重新進行測試，看該 Bug是否會重新出現。

　　(2) 使用測試 (Usage Testing)

　　使用測試是從用戶的角度 (即外部 )出發的測試方法。它也包括許多類型。

　?、?配置測試 (Configuration Test): 從用戶的使用出發進行多方面的測試。例如，保證軟件不僅能夠在 Windows 9X下運行，也能夠在 Windows ME下運行，還能夠在 Windows NT/200O/XP下運行 ;或者軟件不僅能夠在配置高的計算機上運行，也能夠在配置很低的計算機上正確地運行?？傊?，要考慮到用戶的多種情況，用多種配置對軟件進行測試。

　?、?兼容性側試 (Compatibility Test): 主要考慮兼容性問題，比如同一個產品的不同版本 (如 Office 2O00和 Office XP)之間的兼容問題，不同廠家的同一個產品 (如 IE和 Netscape)之間的兼容問題，不同類型軟件 (如 IE和 Office)之間的兼容問題等。最難測試的往往就是軟件的兼容性問題，往往要投人巨大的人力和物力。一些廠商開發出來的產品在兼容性上做得很不好，就是因為沒有足夠的人力和物力進行測試。

　　我在做 SQL Server的 XML測試的時候，為了解決 XML的兼容性問題，用了 6個測試人員和 100臺計算機進行測試。正因如此，微軟產品的兼容性都非常好。而不像市場上的一些產品，安裝以后就導致計算機上的許多其他軟件無法使用，或者出現各種各樣的問題，這樣不僅傷害了其他軟件，也傷害了用戶。

　?、?強力測試 (StressTest): 在各種極限情況下對產品進行測試 (如很多人同時使用該軟件，或者反復運行該軟件 )，以檢查產品的長期穩定性。例如，我們在開發 IE 4.0的時候，由于當時有一個非常強的競爭對手，因此我們必須保證 1E4.0要做得非常好。當時，為了測試 IE4.0的長期穩定性，我們專門設計了一套自動測試程序，它一分鐘可以下載上千個頁面。我們使用這個測試程序對 IE4.0進行了連續 72小時的測試，也沒有出現任何問題，如內存泄漏、程序崩潰等。

　　本項測試可以幫助找到一些大型的問題，如死機、崩損、內存泄漏等，因為有些存在內存泄漏問題的程序，在運行一兩次時可能不會出現問題，但是如果運行了成千上萬次，內存泄漏得越來越多，就會導致系統崩滑。

　?、?性能測試 (Performance Test): 本項測試是保證程序具有良好的性能。如果別人的產品只需 5秒鐘就能得出結果，而你的產品需要 10秒鐘才能得出結果，就說明你的產品性能不好。如果在測試過程中發現性能問題，修復起來是非常艱難的，因為這常常意味著程序的算法不好，結構不好，或者設計有問題。因此在產品開發的開始階段，就要考慮到軟件的性能問題。

　?、?文檔和幫助文件測試 (Documentation and help file Test ): 因為用戶通常是通過文檔和幫助文件來學習使用產品的，如果文檔和幫助文件存在錯誤，就可能會導致用戶無法正常使用產品。這項工作通常在產品即將 Ship(即準備包裝發布 )時進行，以避免在修復 Bug的過程中需要反復修改文檔，或者忘記修改文檔，導致文檔與產品的特性不相符。

　?、?Alpha和 Beta測試 (Alpha and Beta Test): 在正式發布產品之前往往要先發布一些測試版，讓用戶能夠反饋出相關信息，或者找到存在的 Bug，以便在正式版中得到解決。

　　還有一種分類方法將測試方法分為如下幾種。

　　(1) 白盒測試 (White Box Testing)

　　又叫做玻璃盒測試 (Glass Box Testing)。在軟件編碼階段，開發人員根據自己對代碼的理解和接觸所進行的軟件測試叫做白盒測試。這一階段測試以軟件開發人員為主，有時候 SDE/T也會輔助開發人員進行測試。

　　(2) 黑盒測試 (Black Box Testing)

　　黑盒測試的內容主要有以下幾個方面。

　?、?接受性測試 (Aclearcase/" target="_blank" >cceptance Testing)：類似于 BVT測試。

　?、?Alpha/Beta測試 (Alpha/Beta Testing): 在此過程中，產品特征不斷地修改。當發現 Bug后，在開發人員修改的同時，項目經理也會對產品計劃做出相應的調整，產品計劃不是一成不變的

　?、?菜單 / 幫助測試 (Menu/Help Testing) ：大家千萬不要以為這一項測試不值得進行。其實，在軟件產品開發的最后階段，文檔里發現的問題往往是最多的。因為在軟件測試過程中，開發人員會修復側試人員發現的 Bug ，而且可能會對軟件的有些功能進行修改，同時項目經理也會根據情況調整軟件的特性，因而在軟件開發和測試的過程中，所有的功能都不是固定不變的，都會進行調整。所以，一般來說，直到軟件 Ship 時才編寫軟件的幫助文檔，這樣才能保證幫助文件的內容與軟件功能相符，我在做幫助文件測試的時候，總是假裝什么都不懂，就按照幫助文件提供的步驟去做，看看該文件是否正確。在實際測試中，我經常能發現幫助文件中的 Bug 。

　?、?發行測試 ( Release Testing )：在正式發行前，產品要經過非常仔細的測試。除了專門的測試人員外，還需要幾千個甚至幾十萬其他用戶與合作者通過親自使用來對產品進行測試，然后將錯誤信息反饋給我們。到了發行測試這一步，如果出現非改不可的 Bug ，就必須推遲軟件的發行，有的時候一推就是幾個月，期間需要重新對軟件產品進行全面的測試，耗費大量的時間和人力物力。

　?、?回歸測試 ( Regression Testing )：回歸測試的目的就是保證以前已經修復的 Bug 在軟件 Ship 以前不會再出現。實際上，許多 Bug 都是在回歸測試時發現的，在此階段，我們首先要檢查以前找到的 Bug 是否已經更正了。值得注意的是，已經更正的 Bug 也可能有回來了，有的 Bug 經過修改之后可能又產生了新的 Bug 。所以，回歸測試可保證已更正的 Bug 不再重現，不產生新的 Bug 。

　?、?RTM 測試( Release To Manufacture Testing )：為產品真正的 Ship 做好準備所進行的測試。事實上，在這一測試階段，對每一個 Bug 都需要經過很高職務的人同意才能更正。因為這時候修改軟件非常容易產生其他的錯誤，所以只有那種非修復不可的 Bug 才會被允許進行修改。如果在發行階段軟件還有許多嚴重的 Bug 的話，恐怕就不能按時發布了。記得有一次一個微軟核心產品剛剛完成，準備 Ship 時，我對其進行 RTM 測試時就發現一個 Bug ：只要用該產品打印中文就會導致程序錯誤。這是一個很嚴重的 Bug ，浴室開發人員馬上修復了該 Bug ，重新 Ship 該產品。

　　功能及系統測試( Function & System Testing )：這一點是最重要的，他包括了非常多的內容。

　　Ø 規范驗證 (Specification Verification )

　　Ø 正確性 (Correctness )

　　Ø 可用性 (Usability )

　　Ø 邊界條件 (Boundary Condition )

　　Ø 性能 (Performance)

　　Ø 強力測試 (Stress)

　　Ø 錯誤恢復 (Error Recovery)

　　Ø 安全性 (Security)

　　Ø 兼容性 (Compatibility)

　　Ø 軟件配置 (Configuration)

　　Ø 軟件安裝 (Installation)

　　一、心態的調整

　　從我成為測試人員到如今已經有兩個多年頭了，我想從切身的體驗來跟大家介紹作為一個測試人員角色定位的問題，以及剛入門需要了解的相關知識和心態方面的問題。

　　隨著公司規模逐漸擴大，測試人員的隊伍也逐漸壯大。然而很多剛入門的同仁卻開始慢慢對做測試流露出迷茫的眼神，問其原因，很簡單，做測試學不到東西，整天就鼠標點點，鍵盤敲敲，很難學到真正的東西。聽了之后我不由得露出理解的笑容，我也是從這樣的境遇走過來的。剛進入公司的時候就讓做測試，經歷了同樣的鼠標點點，鍵盤敲敲的過程。然而正是這樣的一些成長經歷讓我在平淡中明白了很多道理，并且慢慢從因為工作而做測試轉化為因為興趣愛好而繼續做測試工作。

　　測試工作不僅僅是表面看到的這種敲敲點點現象的延續，還有更深層次的內涵，只是我們還沒到達這個境界，所以看起來很枯燥。剛開始做測試的朋友很多都在做黑盒測試，而黑盒測試往往對代碼編寫能力要求不是很高，這樣給剛入門的人就造成了一個測試人員不需要太多知識的誤解。事實上，測試工作需要很廣泛的知識;不僅僅只是專業上的，而且要了解很多開發人員不了解的東西，一個系統里面開發人員可以只了解客戶需求，而我們的測試人員需要了解全局;開發人員可以不用太多了解用戶的需求，而我們卻需要能夠準確捕獲客戶的觀點，對很多細節需要非常注意。這樣，是不是有點統籌全局的成就感!

　　二、測試入門工作的誤區

　　很多人在初入測試行業的時候往往非常熱衷于測試工具的學習以及使用，其實這并不是很正確。知識的學習是分階段分層次的。測試表面看來很簡單，只是給程序找錯誤，但是在整個軟件開發過程中，我們該如何有效地把測試流程和開發流程結合起來，都需要實踐，而這些是測試工具所不能完成的。

　　對整個測試流程方面的知識我們需要了解很多，而測試工具只是其中一小部分。我們所要學習的不僅僅只是這些表面知識，更需要深入研究測試的流程。包括：1)了解如何制定一個好的測試計劃來規劃我們的測試時間、測試范圍。2)了解如何寫一個好的測試用例來覆蓋整個測試范圍之內的測試實施。3)了解如何保證所測試出來的bug是開發人員的問題而不是因為自己了解不夠而出現的問題。4)如何總結Bug分析報告等等。還需要對我們的測試時間進行詳細規劃，盡量多地考慮各種可能性。這樣才可以盡量減少相關的風險。

　　我認為測試知識的學習可以分為以下三個階段來進行：

　　第一個階段，我們必須明白測試在整個軟件工程的重要性，了解測試的相關基礎知識，并且在了解這些知識的過程中逐漸挖掘出對測試的興趣。興趣愛好是做好一項工作的重要條件。

　　第二個階段，要對整個測試流程管理工作有個非常明確的認識。很多時候測試工作都是在團隊相互協調的情況下進行的，所以只有熟悉了整個軟件開發流程以及測試流程，才能更好地配合工作。在我們對這些都很熟悉并且在工作當中應用很流暢的時候，就可以對測試工具進行相應的學習。同時我們還必須擴充其他相關知識，對客戶需求的了解要比開發人員更全面，更深入，這樣才能保證我們的測試流程是按照客觀正確的方向前進。

　　第三個階段，學習測試管理和深入研究測試方法。這個階段我們需要繼續深入研究測試工具的使用及進一步提高自己的測試技能，在實際工作中總結測試經驗并最終熟練掌握自動化測試，成為技術專家。

　　測試人員的職業發展規劃

　　國內一位資深測試人員海松寶曾對測試人員的發展階段跟發展路徑規劃畫出一個很形象的發展圖(如下圖)：

　　從這個圖形大家也可以粗略的看出，對于初級測試工程師，這是兩個不同的發展方向，但是最終還是發展為一個終點(PM)。從一個初級測試工程師晉升到一個高級測試工程師比較快，但是從一個初級測試工程師發展到一個TeamLeader所需要的時間相對比較長。而從一個高級測試工程師發展到一個資深測試工程師花費時間更長一點，到達資深測試工程師之后就可以很容易做到測試主管了，以后可以發展到PM。當然從初級測試人員到高級、資深測試人員在上面的圖中并不是表述為“曲線發展過程”的，很多時候行業經驗、行業知識的累積等都很重要，而這點只有深入發展的人才會發現。所以我們做事必須要有耐心，羅馬非一日建成。相信明天就要緊緊把握今天。

　　優秀測試人員具備的素質

　　測試不順利的原因之一是測試人員的專業知識不夠。所以我們一定要加強我們自身的專業知識的學習。那么，一個真正的測試人員應該具備哪些知識呢?除了應具有相關的專業知識外，我想從大眾化的方面來闡述下面幾個需要我們注意的地方，這也是作為一個測試人員應該具備的基本素質：

　　1、我們需要具備很好的溝通能力：我們不僅要與開發人員進行溝通，有時候還要與客戶進行溝通。他們是兩種不同類型的人，關心問題的側重點也不同。所以我們溝通的時候需要掌握一定的技巧。由于開發人員與我們思考問題的角度不同，雙方自然會引起一些爭論、誤解，這時候我們應該心平氣和把寫出來的bug，向開發人員解釋清楚，從而雙方達到共識。對于客戶，我們要從客戶關心的問題入手，這樣才能從客戶那兒得到比較準確的需求。

　　2、我們需要具備很好的自信心：由于開發人員認為測試人員的開發知識不如他們，因而會輕視測試人員，這個時候我們除了要擴充自己的專業知識外還需要有很強的自信心。。要知道有了一定的專業水平，別人就會尊重你的勞動成果并聽取你的見解。當然這種自信心也是建立在心平氣和下的溝通，不是完全對立的。

　　3、我們需要保持一種職業懷疑的精神：我們會經常碰到這樣一種情況，我們將發現的bug交給開發人員時他們總是盡他們最大的努力解釋每個他們認為不是bug的bug。這時候我們不能輕易下定論，而應持懷疑態度直到自己仔細確認后。

　　4、我們需要耐心和很好的記憶力：有時候往往一個bug要花費我們大量的時間和精力，這就要求我們要有耐心。如果我們有很好的記憶力，就可以輕松地獲得一些類似的bug的資料，。當然，如果記不住的話，，那么相關的文檔就是我們最好的查詢資料。我們可以在不斷的查詢過程中修改文檔，使文檔日臻完善，

　　5、我們需要一顆安靜的心：因為浮躁的人是找不出隱藏在深處的bug的，所以當我們測試的時候應該保持內心的平靜，從而憑借很好的洞察力來尋找那些隱藏很深的bug，或者是相關的重點。這點是很重要的。否則你的測試跟流水賬沒什么區別，只是根據業務流程、用戶需求、開發人員的思路，發現一些皮毛的bug。這不是一個優秀的測試人員應該做的。

　　6、我們還應學會承受壓力并排遣壓力：我們經常承受著一定的壓力，客戶在催促，開發人員在delay，所以我們要能夠承受壓力，包括外界的、工作上的壓力。并且不要把因為壓力而導致的不好的情緒帶到工作當中。學會排遣這些壓力，保持一顆輕松、平靜的心，全身心投入到我們的工作。

　　只是想強調一點：測試在中國的發展前景是非常好的，而這點從這幾年無論是測試人員和測試環境的變化還是客戶對產品質量的要求越來越高都可以看出。

　　微軟的軟件測試人員分為兩類 :測試工具軟件開發工程師( Software Development Engineer in Test,簡稱 SDE/T)和軟件測試工程師 (Software Test Engineer，簡稱 STE)。

　　測試工具軟件開發工程師 : 負責寫測試工具代碼，并利用測試工具對軟件進行測試;或者開發測試工具為軟件測試工程師服務。產品開發后的性能測試 (Performance Test)、提交測試 (Check-in Test)等過程，都有可能要用到 SDE/T開發的測試工具。由于 SDE/T和 SDE的工作都是寫代碼，具有相通的地方，所以兩者之間互相轉換的情況比較多。但需要注意的是，兩者寫出來的代碼用途是不一樣的， SDE寫的是產品的代碼，而 SDE/T寫的代碼只用于測試產品。

　　軟件測試工程師 : 負責理解產品的功能要求，然后對其進行測試，檢查軟件有沒有錯誤 (Bug)，決定軟件是否具有穩定性 (Robustness)，并寫出相應的測試規范和測試案例。

　　除此之外，在一個軟件產品的研發和銷售過程中，還會需要負責給產品打補丁 (Service Pack)的快速修正工程師比( Quick Fix Engineer)，通常曲 SDE來擔任，通過電話方式向用戶提供售后技術支持的支持工程師 (Support Engineer)，銷售和市場 (Sales and Marketing)人員，研究員和研究工程師 (Researchers & Research SDE)。

　　在進行產品開發的時候，主要是由前面三類人員 (項目經理、開發人員及測試人員 )組成產品開發團隊來進行的。在微軟內部，軟件測試人員與軟件開發人員的比率一般為 1.5-2.5左右，這可能遠遠超出了大家對測試人員的理解，但微軟軟件開發的實踐過程已經證明了這種人員結構的合理性

　　測試時應考慮的幾個問題

原文轉自：http://www.anti-gravitydesign.com