軟件測試工程師指南

軟件測試工程師指南
　　作者簡介:
　　Timur 趙,Nortel 高級測試主管,浙大博士;
　　當你生活于網絡時代，只要原地不動就很容易落伍了。
　　沒有經驗，不知如何躋身于測試工程師的行列？以下幾個基本方向能使你從新手成為軟件測試的行家里手。
　　軟件工業是自動化工業的一部分。而且是最活躍發展最迅速的一個方面。到底有多迅速？任何人的想像力都不夠！正如我們不會把我們的事務托付給不可靠的經紀，任何有分量的公司都不會采用沒有質量保障的軟件。軟件測試人員，我是說有水平有經驗的軟件測試人員永遠是供不應求的。軟件測試經理不得不花很多的時間去面試有潛力的應聘者。一些應聘者在軟件方面或者軟件測試方面毫無實際經驗，明知道軟件測試工作是一個高回報的和最合適的軟件工業入門，就是無法抓住一個又一個機會。這些人真正需要的是一個指南能告訴他們如何成為一個軟件測試工程師。
　　首先，進入軟件測試需要哪些技能？
　　1、軟件工程技能　你必須了解軟件軟件工程(設計、開發和簡單測試)，應用，系統，自動測試編程，及操作系統，數據庫，網絡系統和協議的設計和使用。
　�。�、交流技巧　如果想確定軟件缺陷，你應當能夠指出什么時候的缺陷算是缺陷。
　�。�、組織技能　如果你在別人都頭腦發昏的時候保持清醒，你就可能是一個好的軟件測試工程師。在網絡時代軟件測試是一項有壓力的復雜性工作，但如果你能從這些紛繁中找到一種途徑，它就是一項回報豐厚的事業。
　�。�、實踐技能　當一個工作需要經驗，而你又需要一個工作去豐富你的經驗時該怎么辦？這并不完全是一個兩難的問題，你可能采用幾種方式去獲得實際經驗。
　�。�、態度　除了技術水平，你需要理解和采取適當的態度去做軟件測試。
　　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...%2ebugnet%2ecom)是有關軟件缺陷的在線雜志。閱讀有關缺陷的文章是學習如何工作及失敗的極好方式。你也應當查閱軟件測試及質量工程雜志(http://65.54.244.250/cgi-bin/linkrd...ww%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...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組所進行的完整測試能使開發經理的工作變得多簡化。
　　正象我所說的，當你生活于網絡時代，只要原地不動就很容易落伍了。
　　相對于其他軟件工程人員， 軟件測試工程師的知識面應該非常寬廣，但最重要的品質應該是能夠在第一時間內接受新技術。
　　由于公司之間的競爭日益集中在質量方面，所以公司對軟件測試人員的需求量也越來越大，這一點，在北美尤為明顯，這決定了軟件測試行業的前景可喜，同時也為愿意不斷進取、學習新技術的華人移民提供了廣闊的就業空間，軟件測試工程師的就業機會一直都是非常多的，最關鍵，要善于抓住機遇并肯付出努力，踏踏實實的學起來、做起來。