在北美，怎樣找到軟件測試工程師的工作

　如何躋身于測試工程師的行列?以下幾個基本方向能使你從新手成為軟件測試的行家里手。

　　軟件工業是自動化工業的一部分。而且是最活躍發展最迅速的一個方面。到底有多迅速?任何人的想像力都不夠!正如我們不會把我們的事務托付給不可靠的經紀，任何有分量的公司都不會采用沒有質量保障的軟件。軟件測試人員，我是說有水平有經驗的軟件測試人員永遠是供不應求的。軟件測試經理不得不花很多的時間去面試有潛力的應聘者。一些應聘者在軟件方面或者軟件測試方面毫無實際經驗，明知道軟件測試工作是一個高回報的和最合適的軟件工業入門，就是無法抓住一個又一個機會。這些人真正需要的是一個指南能告訴他們如何成為一個軟件測試工程師。

　　首先，進入軟件測試需要哪些技能?

　　1 、軟件工程技能　你必須了解軟件軟件工程 ( 設計、開發和簡單測試 ) ，應用，系統，自動測試編程，及操作系統，數據庫，網絡系統和協議的設計和使用。

　　2、交流技巧　如果想確定軟件缺陷，你應當能夠指出什么時候的缺陷算是缺陷。

　　3、組織技能　如果你在別人都頭腦發昏的時侯保持清醒，你就可能是一個好的軟件測試工程師。在網絡時代軟件測試是一項有壓力的復雜性工作，但如果你能從這些紛繁中找到一種途徑，它就是一項回報豐厚的事業。

　　4、實踐技能　當一個工作需要經驗，而你又需要一個工作去豐富你的經驗時該怎么辦?這并不完全是一個兩難的問題，你可能采用幾種方式去獲得實際經驗。

　　5、態度　除了技術水平，你需要理解和采取適當的態度去做軟件測試。

　　1 、軟件工程技能 (Software Engineering Skills)

　　軟件工程技能可以分成三大塊：理解軟件工程的規則，了解計算機編程和操作系統知識。

　　理解軟件工程 “ 規則 ” 。有一種過時的眼光認為軟件工程只是由一些在工作期限之前瘋狂編程、靠著非凡的協調能力和超人般的咖啡消耗整夜不睡，不停地設計和測試程序的 “ 專家 ” 們組成的。這種現象確實存在，但你只有了解了軟件開發的真正過程，才會是一個專業人員。

　　從哪開始呢?先到圖書館去走一走。你需要建立軟件測試知識的軟件工程基礎。我的建議是閱讀 Roger Pressman 的軟件工程： A Practitioner's Approach, fifth edition ( 職業入門，第五版， McGraw Hill, 2000 年版 ) 和 Glenford Myers 的 The Art of Software Testing( 軟件測試藝術， John Wiley & Sons, 1979 年版 ) 。 Pressman 的書是一個對軟件工程原理的全面介紹。有很多關于軟件技巧、項目管理、要求分析和軟件設計等軟件工程方面的好書，但 Pressman 對這些方面在一本書里作了介紹。 Glenford Myers 不到二百頁， 1979 年發行，卻是軟件測試方面的圣經。 Myers 定義及詮釋的測試方法論已成為軟件測試的基本模塊。

　　Myers 還考查了軟件測試中的經濟 ( 缺陷的代價 ) 和心理學方面 ( 測試的目標就是發現失誤及不成功之處 ) ，以及主導軟件開發和測試的基本原則。

　　對參考書進行基本研究是一個好的開端，但這只是單方對話。如果你能和上千個直接具有軟件工程和測試經驗的人以及想進入這一領域的人對話是不是再好不過了呢?感謝那些網絡電子部落，你已經可以做到了。 Comp.software-eng 覆蓋了設計、編程、項目管理等軟件工程的各個方面。 Comp.software.testing 涵蓋了軟件測試的自動化、培訓、技巧等方面。

　　等等，別只停留在這里!你是不是應當經常訪問這些網址呢? Bug-Net( http://65.54.244.250/cgi-bin/linkrd?_lang=EN&lah=700d219edfe50a0e5b512fd6a075e9ab&lat=1056412649&hm___action=

　　http%3a%2f%2fwww%2ebugnet%2ecom ) 是有關軟件缺陷的在線雜志。閱讀有關缺陷的文章是學習如何工作及失敗的極好方式。你也應當查閱軟件測試及質量工程雜志 ( http://65.54.244.250/cgi-bin/linkrd?_lang=EN&lah=b16a960cd35e9df346843326584722e9&lat=1056412649&hm___action=

　　http%3a%2f%2fwww%2estqe%2ecom ) 。 STQE 是確定網絡軟件測試資源很好的始發站。

　　計算機編程。不能想像有的人喜歡測試產品卻從不閱讀、檢查和理解組成產品的軟件一樣。

　　不要誤解我的意思。你不必花所有的時間去讀源代碼，但任何你做過的有關自己程序的設計、編寫和糾錯都能大大地有助于測試別人編寫的程序。

　　你怎樣學習編程?通過編程?？梢試烂C地說，開始學習寫計算機程序是最簡單的事。記住我說的是 “ 開始學習 ” 。軟件編程環境，例如 Microsoft Windows Foundation Classes (MFC) or Sun's Java Foundation Classes (JFC, also called "Swing") 不斷變得越來越復雜，越來越難跟得上。

　　但我在努力超越自己。你應當怎樣學習編程呢?

　　首先，買 Microsoft Visual Basic 。不要讓名字騙了你。你能用這套組件建立相當復雜的程序。而且它只要一百元左右。下一步呢?等等，是 visual 編程警告的時候了!

　　現在你為你的 PC 買一個程序語言的時候，你其實是買了一個集成開發系統或稱為 IDE 。這些 IDE 通過對編程的簡化把開發過程流水線化。這些 IDE 其實會幫你寫很多編碼。這非常有利于盡早開發出一個產品，卻不利于你學習編程。如果你用 Windows 產生程序，你別無選擇，因為環境介入太多使你無法從頭編程。如果你從 Unix 系統產生程序，你能自己寫所有的編碼。

　　一旦你習慣了與參量、控制結構、對象、輸入輸出及更重要的 Visual Basic 糾錯打交道的時候，你就可以開始學習 C 語言了。學習 C 能使你熟悉十六進制系統，通過指針分配和參考內存，存取個體位碼及建立程序模塊。

　　我總是認為在學 Java 之前最好先學會 C ，因為 C 強迫你自己去完成許多任務而 Java 會自動處理 ( 例如，釋放未用的空間 ) 。用 C 工作比 Java 難，但你能學到編程更多的基本方面。你其實能用 Visual C++ IDE 從頭寫 C 程序，但最好還是在 Unix 系統中學 C 。

　　操作系統知識。你已經把它交給了在 Redmond, Washington 的那些人了。在短短的幾年內， Windows NT 已經成為世界上大部分計算機的標準操作系統。如果你要用 NT 工作，你需要了解它的寄存地址。 ( 它是一種用于存儲你的系統結構的各個方面的數據庫。 ) 我發現 Peter Norton 寫的 Inside Windows NT 4.0 (SAMS, 1998) 是一本很好的介紹書。但是，如果你的應用或系統要求高的保密度、產出、可靠性及靈活性， Unix 依然是最好的選擇。

　　如果你想成為一個成功的軟件工程師，你必須能在 Unix 的世界里工作，如果你想從頭學習編程，也要在 Unix 下進行。

　　你的選擇是什么?你可以到當地的學?；虼髮W學習課程，或者在家建立一個 Unix 系統。別昏過去了，你所需要的只是一臺 PC 和一份能讓你從網絡免費下載的 Linux 拷貝。 ( 你大約花二十九元能買一份在一個 CD-ROM 中帶了所有文件的拷貝。 )Linux 不是 Unix 的 “ 玩具 ” 版，它是真實的。它已經發行了七百萬份拷貝，一些主要的 PC 生產商甚至先替你裝載了它。

　　好了，你已經到了 Unix 或 Linux 系統了。你應當學些什么?文件和目錄結構，標準輸入輸出和錯誤流，背景 (background ，也稱為 "daemon") 處理，從 C 調用系統功能，好，我可以接下去了。一個好的開端是讀 Arnold Robbins 的 Unix in a Nutshell (O'Reilly & Associates, 1999) 或者是 Ellen Siever 的 Linux in a Nutshell (O'Reilly & Associates,1999) 。

　　2 、交流技能 (Communications Skills)

　　能寫出計算機程序卻寫不出一個完整句子的軟件工程師現在還有。但不幸的是，要成為一個成功的軟件測試工程師，你需要清楚的交流。

　　你怎么去學習寫?通過寫。如果文字水平太粗糙，上一門創造性寫作的課。每天寫工程流水記錄或發 email 。關鍵是學習 ( 或重新學習 ) 怎樣用清晰可懂的語言表達你的思想。一個好的寫作參謀是 William Strunk Jr. 和 E.B. White 寫的 The Elements of Style(Allyn & Bacon, 2000) ，它一點也不象初中教科書。

　　測試工程師必須把產品測試的技術寫成文件。測試計劃提供指導并把測試設計轉化為設置、實現測試和評估結果的步驟指導。具有一般軟件和產品特性不同層次經驗的工程師都能使用這樣一個詳細的測試計劃。如此測試設計者或測試方案作者之外的工程師也能能進行測試。

　　測試計劃也幫著佐證測試策略的正確性。項目中的每個人都應當參與審查 ( 即市場、開發、支持、技術寫作及測試人 ) 。計劃的審查是必不可少的，因為盡管測試工程師盡最大努力來達成一個對產品的全面定義，這一測試設計者所基于的定義不一定是完整或準確的。此外，就象開發者很難測試他們自己的編碼一樣，測試工程師也很難明確評估他們自己的測試計劃。每一個計劃審查者都可能根據其經驗及專長建議修改，有時侯審查者還能提供測試工程師在組織產品定義時不具備的信息。例如，一個市場人員可能了解到了新的客戶要求，一個軟件支持專家可能從有關的產品領域了解到了一個新的缺陷報告。

　　測試計劃強調測試計劃和執行的原則。在測試計劃中描述進行測試所需的測試設計和步驟是另一層關于測試設計和計劃的原則。在測試設計和計劃中的錯誤與欠缺在設計轉化成測試計劃中特定的結構和測試步驟后就經常是再已無法彌補。

　　測試計劃可作為其它項目，例如為不同的產品準備測試時的參考資料。當被測試軟件找到缺陷解決并證實后，測試計劃所述的測試可以用于證實缺陷的解決方案。同時，一個主要的測試設計信息來源，特別對于舊產品的新版本而言，是相關產品或前版本的測試計劃。在建立新版本時，舊版本的軟件測試計劃都應當被重新審查。

　　與功能與設計說明不同，測試計劃將從測試的角度來描述產品的功能操作。從這方面說，測試計劃構成了公司公共檔案的一部分。隨著時間的流逝人們會離開公司，帶走他們的知識。以前產品的測試計劃就能幫助你定義新產品的測試。

　　軟件測試工程師還要寫測試結果報告。測試結果必須寫成文檔，這樣就能確定被測軟件的狀態，提供關于必須要解決的缺陷的記錄。產品測試中發現的所有缺陷的記錄是測試部門最顯眼、保存時間最長的文檔。測試計劃和測試報告在項目的最后常被遺忘，但現存缺陷的清單 ( 或數據庫 ) 代表項目未完成的議程。這一議程沒完成是因為一些缺陷必須在對原來產品的一個 patch 或 maintenance release 的時候糾正，或者它們在這個產品作為后續產品的基礎之前被修復。

　　在與軟件產品打交道的過程中，測試工程師比其他部門的人參與項目的更多方面。測試部門應當記錄項目過程中重大事件 ( 例如設計決定 ) 的信息。這個信息應能幫助測試部門和其他部門避免在后續項目中犯同樣的錯誤。錯誤是不可避免，在一個項目中可能出問題。從這些經驗中學習就可能避免問題，避免今后的同樣錯誤。從錯誤中學習的第一步就是記住它們，記憶的第一步就是把它們寫下來。

　　3 、組織技能 (Organizational Skills)

　　每當執行一個軟件項目的測試計劃，幾乎不可能不遇到至少會阻礙一些測試而必須解決的缺陷。一個測試工程師應當能靈活地停止測試產品的一部分而開始測試其他部分。有時被測軟件需要做根本變動引起大量的測試結果失效，測試也許得重做不止一次。在問題被查找和改變在進行的過程中，測試工程師必須有條理，保持對執行測試的軟件的前后關系的明確感受 ( 例如目前被測試的程序特定版本的不同部分 ) 。

　　網絡時代要求的動態開發和測試模式使組織性的工作方式對測試工程師越來越重要。在整個開發過程中被測試軟件可能會不斷地改進。測試工程師在計劃和實施測試的時侯必須考慮這些變化因素，必須控制測試環境來保證測試結果的有效性。

　　記住計劃是一個動詞。作為一個軟件工程師，你永遠不會有你想要的所有時間和資源。你總是必須通過理解技術和產品，開發組織方式，從你和其他人的錯誤中學習，以及在設計必須改變和出問題的時侯的迅速調整，使你的測試效果和效率最大化。如何能做到這點呢?基本代數：量化任務、目標和結果來減少方程中的變量數。把產品的功能定義成要求。在測試計劃和測試中量化測試及其預期的和實際的結果，把信息提供給項目組。你東點一下西點一下是不能完成整個測試的。未來軟件開發的組織模式要求有靈活的設計和不斷進化的開發周期。對產品測試必須隨著產品的進化而進化。

　　4 、實踐經驗 (Hands-On Experience)

　　這是個典型的兩難問題。你需要軟件測試經驗來找工作，你沒工作你就沒經驗。你該怎么辦?

　　Be careful! 這需要勇氣和你的 PC 的小心備份。

　　作為自愿者參與 beta 測試。怎樣發現需要 beta 測試員的公司呢?首先，給你在軟件公司工作的親友打電話。偶爾有人會需要 beta 的測試人員。如果這不行，到你最喜歡的網絡搜索引擎上去找 “beta test” 。你會發現很多小 ( 和不那么小的 ) 公司亟需 beta 測試員。為什么?這得感謝互聯網，競爭的加劇使公司必須做出產品模型貼到他們的網址上作為 “beta” 版推出。這些公司希望人們不僅測試他們的產品，而且對這些免費品感興趣進而購買他們的產品。

　　你也能參與開放資源的項目，例如 Mozilla ，開放資源的網絡瀏覽器是網絡瀏覽器的基礎。 Mozilla 缺陷跟蹤系統 (bugzilla.mozilla.org) 允許網上任何感興趣的人直接

　　在 http://65.54.244.250/cgi-bin/linkrd?_lang=EN&lah=305b645e23c84b49d4b41cffd53cb67f&lat=1

　　056412649&hm___action=http%3a%2f%2fwww%2emozilla%2eorg 的開放資源項目中直接報告和跟蹤缺陷。

　　一句忠告：如果你要把很多 beta 軟件下載到你家里的 PC 里，投資你的備份設備和防病毒組件。

　　5 、態度( Attitude )

　　“ 我希望你幸福的夢想，被你打破了! ”

　　我打賭這句話能勾起一些人童年記憶的創傷。我不是心理學家，但我還敢說這種說法是因為我們渴望看到成功。在軟件測試中，你不僅要證實軟件在做它該做的，還要證實它不會做它不該做的。為了做到這一點，你得找出軟件的失敗之處。

　　進行軟件測試需要很多人的眼光要進行一百八十度的轉變，因為測試的目標是要讓被測軟件失敗，由此產生出等同于其他東西工作正確時的成功。在軟件測試中，一個成功的測試揭示一個缺陷。進行軟件測試也是因為互聯網的來臨要求人們用一種大不同以往的眼光來看待動態的開發和測試模型。

　　6 、必備特性( Necessary Traits )

　　軟件測試工程師除了技術，還要求具有否定性的創造力;探測技巧;總體理解產品的能力;用客戶的眼光進行評估;懷疑的而不是敵意的態度;能經受得住壞消息而保持目標;擁抱新技術的熱望等特征。

　　否定性的創造力。一個軟件工程師不能怕引起一個產品的癱瘓或燒毀。在軟件測試中，邊界意味著被超越而不是被遵從。如果一個程序對某個值的極限為 10( 例如，可以在一時間被打開的最大文件數 ) ，測試工程師的第一想法應當是 “ 如果我把那個值取 11 ，或 0 ，或 10.1 ，甚至不設這個值會如何? ”

　　在我的早期的工作生涯中，有一次我測試一個開發和 QA 工程師遺漏下來的 PC 數據庫。有問題的數據庫是 2.01 版。這本身就說明產品有問題。 2.0 版沒解決 1.0 版的所有缺陷嗎?或者 2.0 版又加入了新的缺陷?很遺憾因為時間緊我沒有調查這些，只是證實了最后的缺陷修復后就告捷了。

　　這是很大的錯誤。我應當重測開發人員所謂 “ 沒有變化 ” 的所有產品功能。 2.0 版本中的缺陷確實復修了，但在修復的過程中，有人破壞了請求。事實就是如此，在數據庫里不能搜索數據了，第一個收到這項產品的 beta 客戶發現了這個缺陷。

　　我宣布以前的測試無效，要求對產品進行全面測試。找到幾個缺陷之后，我發現這個數據庫讀取寫保護文件或寫保護了的磁盤的時候就會引起癱瘓。開發人員很吃驚我會試著寫保護一個數據庫。他們的反應就是： “ 沒人會這么干的! ” 產品的市場經理很快用他們的方式承認了錯誤。

　　探測技巧。在一個理想的世界中，軟件測試應當在一個經常更新的寫得很清楚的功能與設計說明文件 ( 一般被稱為 “specifications”) 中被完整而精確地描述。不幸的是，這一完善被開發程序每一方面文件的任務，包括記錄在開發中對程序不可避免的改變，要花很多的時間和精力以至于人們無法完成編程。而且花費也太大。

　　正式與非正式的信息源

　　正式系統

　　要求文件

　　功能說明書

　　設計說明書

　　非正式系統

　　用戶文件

　　與其他開發人員的交流

　　與軟件支持人員的交流

　　有關產品的文件

　　有關產品的缺陷

　　從工作于相關或早期版本產品獲得的 “ 局部知識 ”

　　因為我們不是在理想世界里編程，測試工程師應當能夠自己找出工作的方式。典型的是，總會有一些設計和功能說明書讓測試工程師用于開始他的研究。這些文件能看成為描述被測試軟件的 “ 正式 ” 系統。測試工程師應當能用更廣大的 “ 非正式 ” 系統的信息來擴展 “ 正式 ” 系統的信息。同時，在項目周期的任何一個點，任何文件都可能是正確或不正確的，所以測試工程師必須根據對軟件工作模式的觀察，與開發人員和其他項目人員的交談，或對有關或看上去不那么相關文件的審核，來確定文件的精確性。

　　總體理解產品。在一個程序項目是，軟件開發工程師主要把他們的精力和注意力集于自己的項目部分。結果當這些項目部分組合在一起進行測試的時候，就會碰到兼容性的問題。到產品寄給一個客戶之前，唯一能見到整個產品的就是測試工程師。因此測試工程師必須能夠對整個產品的操作與使用保持一種 “ 系統 ” 的眼光。

　　測試工程師對產品的任何一部分的操作可能不是最好的專家，但他必須是產品整體操作的專家。例如，如果被測的產品是一個類似于 Microsoft Office 的由文字處理、擴展頁和其他有關程序組成的辦公室自動組件，測試工程師必須了解每個程序的操作，各個程序之間的相互作用和客戶其他的軟件硬件和軟件環境。

　　用客戶的眼光進行評。測試工程師必須是客戶的擁護者。被測程序有可能運行可靠滿足所有的設計要求，但在客戶的軟件環境中未必能夠用。產品被送到客戶之前的測試之一就是要證實產品達到了客戶的要求與期望。在這項測試中，測試工程師必須模擬用戶的軟件環境，把自己放到他們的位置上。

　　關于軟件功能 “ 正確 ” 而不能滿足客戶需要的一個悲劇性的例子就是美國航空公司 965 航班 1995 年在哥倫比亞卡利市的一次失事。在飛行著陸時，空中信號控制系統指示機組人員朝一個叫 “Rozo” 的航空信號燈飛。這個信號燈在航空圖中標為 R 。機組人員把 R 輸入到飛行管理計算機中，看到了明顯是由近到遠列出的六個航空信號燈。機組人員選了第一個信號燈，以為這就是 Rozo 。但那不是。自動駕駛儀把飛機向左轉了九十度，撞到了山上。

　　什么地方出錯了呢?當航空表里把 Rozo 列為 R 的時候，飛行管理計算機要求機組人員輸入信號燈的全名調出它的方位。同時，計算機只顯示了信號燈的編碼字母和方位。計算機功能 “ 正確 ” ，但不滿足用戶的需求。

　　要求變化。項目剛開始時的要求與最終項目完成時的要求一致的情況是極少見的。有時技術變化了，產品必須改變以適應于技術。有時競爭對手的產品具有你的產品所沒有的功能。很多情況下，客戶的或潛在客戶的要求需要變化。這些因素合在一起的一個例子就是目前 Microsoft Internet Explorer 和 Netscape 的競爭。

　　隨著計算機首次用戶的迅速增加，今天的測試工程師比以往更需要把自己置于客戶的位置上。這些新的非技術用戶不愿意接受缺陷，對缺陷的解釋或理性思考，或通過 “ 升級 ” 修正缺陷。他們只希望他們所買產品的軟件和硬件都是能工作的。

　　懷疑的而不是敵意的態度。測試工程師不能按表面值接受事物，必須執著地對一切提出疑問直到被證實。工程師必須用一種與項目的其他的人合作精神來平衡這種懷疑性與執著性。測試部門與其有關部門的關系可能會變得緊張，特別是在大量缺陷被發現后，或者在每個找出的缺陷會潛在地延遲產品的發貨時間而延遲了項目時。測試工程師應當記住要攻擊程序的整體性，而不是程序員。

　　經受得住壞消息而保持目標的能力。一個測試工程師必須忠實地匯報產品中的缺陷。這一信息應當被項目組歡迎，因為每一個測試工程師遇到的問題 ( 除非加入新的問題 ) 都意味著減少客戶會面臨的問題。但不幸的是很多人不想聽到有問，特別是在程序項目的后期。

　　測試工程師應當能處理因為工作做得太好而引起責備的情況。這對有些人來說是很難做到的，會嚴重地影響斗志與自尊。

　　看起來常常是測試工程師阻撓了向客戶交貨?？陀^的項目經理才能感覺到測試工程師是在對項目提供有價值的服務。我清楚地記得一個項目經理舉起他的手求我他要的是： “ 解決方案，不是問題! ”( 他不明白解決方案的實現有時要求一個問題的解決。 ) 有時項目經理在項目計劃不方便的時候對于因為發現缺陷而打折是有壓力的。在這些情況下，測試工程師應當能基于他對產品的經驗和知識進行辯護，但他不應表現為象是他個人受到了威脅。

　　如何避免這些情形呢?就測試的內容、時間及如何更新測試結果和缺陷信息，設定其他項目組成員的期望。我曾經為一個希望延遲產品發送日期的 QA 經理工作過。他的目的不是為了產品成功，而是政治權力的操縱。他確信自己能被提升，把一些為他工作的工程師指定為 “manager” ，開始自稱為 “director” ，還要大樓管理人員把他的辦公隔間加寬一英尺。 ( 這沒有實現，但至少他的座位有了更多伸腳的余地。 )

　　擁抱新技術的熱望。對多數人來說，年齡越大越難學習。在商業世界里，人員越往公司的食物鏈高處走，越遠離他們所建立的技術基礎。這一部分是因為他們需要把精力集中于其他的經營和指導其下屬的任務中。有時也是因為他們不幸地認為自己已不需要進行實踐的技術工作了?；ヂ摼W增加了技術變化的速度。不繼續學習或跟著發展就無法做出商務與技術的決斷。

　　從前的一個經理給我樹立了如何對待新技術的榜樣。我跟他工作的時候他年近六十，但他象新手一樣地熱心于學習新技術。他大量地獲取信息，不斷補充在網絡服務器、防火墻、和 Perl 或 Expect 等新語言的知識。他還重視做 QA 或測試組織的工作。他的最初背景是軟件開發和開發管理，但他并不認為做 QA 經理是在降低他的聲望。他明白一個獨立的測試或 QA 組所進行的完整測試能使開發經理的工作變得多簡化。

　　正象我所說的，當你生活于網絡時代，只要原地不動就很容易落伍了。

原文轉自：http://www.kjueaiud.com