1.2 關于蟲子的故事 在熟悉了公司的結構、開發流程，參與了部門例會之后，小白要開始從事具體的軟件測試工作了，對于他來說，這一領域陌生而令人興奮。
在剛上班的一周內，小白不斷地聽到周圍的測試工程師高興得喊道：“又發現Bug了！”，看著他們那興奮的樣子，小白也有點躍躍欲試，想趕緊在捉蟲的戰場上大展身手。那么，什么是Bug呢，它為什么這么重要，發現Bug為什么這樣興奮？
1.2.1 蟲子的來世今生
在本章的序幕部分，我們已經了解了很多由于軟件代碼的問題使得事情失敗的案例了。它們有的后果真的很嚴重，甚至能夠造成對生命的威脅。這肯定不是軟件設計者和開發者想要達到的目標，因此，出現這樣的情況可以說是軟件的錯誤。
細細的分起來，軟件的錯誤有如下幾個詞語來描述：
缺陷、偏差、錯誤、問題、事故、異常。在這一堆詞語當中，除了偏差之外，其他的詞語所造成的后果給人的感覺都相當嚴重。所謂偏差，就是軟件在使用過程中，和軟件設計說明（product specification）所不一致的行為。
那么為什么將這樣的軟件問題稱為Bug呢？這里面還有一個故事。
【史上第一個軟件Bug】
該詞的原意是“臭蟲”或“蟲子”。1947年9月9日，正值計算機剛剛被發明的時候，哈佛大學的某個計算機實驗室正在做實驗。由于當時的原始計算機由很 多龐大且昂貴的真空管組成，運行時會產生光和熱，在下午15點45分的時候，一個飛蛾（英文是Moth）鉆入了真空管內，導致整個計算機無法工作。當把這 只小蟲子從真空管中取出后，計算機又恢復正常。后來，蟲子的泛稱Bug這個名詞就沿用下來，而那個被拍死的飛蛾也成為了歷史上發現的第一個Bug。
【Bug滲透到日常生活中】
一般來說，擁有一定知識產權的產品的錯誤都能稱之為Bug。這方面有一個我們比較熟悉的例子就是電影。影迷們經常議論某熱門電影中出現了所謂的“穿幫” 鏡頭，比如在描述古代武俠的影片中天空掠過一架飛機，主角剛才是右臉有傷痕，過一會變成左臉等。這樣的鏡頭也可以說是Bug，甚至還有專門的網站來記錄這 些影迷的細心發現，比如http://www.chinabug.net。
1.2.2 軟件Bug的5個要素
前文籠統解釋了軟件Bug是軟件的錯誤或者偏差。那么在具體的工作中，小白如何判斷軟件的行為是Bug呢？說來簡單，根據軟件設計階段形成的功能說明 書，英文為Specification Document，一般簡稱Spec。對于具體的判斷標準，經理介紹了如下5個要素：
軟件沒有實現說明書中所列出的功能。
軟件出現了說明書中提到不應出現的事情。
軟件實現了說明書中沒有提到的功能。
軟件沒有實現說明書中沒有提到但應該實現的功能。
軟件非常難于學習、使用，運轉速度很慢，用戶認為無法達到預期。
為了充分理解上述5個要素，小白自己打開了Windows系統中最簡單的一款軟件Notepad，也就是我們平時“不屑于”用到的記事本程序，開始了自己的思考。
1．軟件沒有實現說明書中所列出的功能
對于“軟件沒有實現說明書中所列出的功能是Bug”這一點是比較好理解的。如果打開記事本軟件，卻無法在其中輸入漢字，或者輸入了文本，無法保存成文件，那么肯定是一個很重要的Bug。
2．軟件出現了說明書中提到不應出現的事情
對于第2點，“軟件出現了說明書中提到不應出現的事情也是Bug”，這一點和小白的性能測試工作有相對更緊密的關系。小白要測試的是公司的網站，它要求用戶在瀏覽網站時顯示頁面盡可能地快，如果超出5秒鐘則認為是不可接受的。這個“超出5秒鐘”就是說明書中提到不應該出現的事情，實際出現后肯定是一個Bug，需要開發人員找出哪里耗費了頁面顯示時間。
在記事本程序中，如果程序保存文件時出現了程序崩潰（Crash）現象，即屬于此類。
3．軟件實現了說明書中沒有提到的功能 軟件實現了說明書中沒有提到的功能也是Bug這一點可能有點難于理解。一個軟件，功能難道不是越多越強大嗎？其實不盡然，實現額外的功能有如下幾個缺點，如表1-3所示。
表1-3 軟件實現說明書中未提到功能所帶來的問題
| 缺 點 | 說 明 |
| 代碼量增大 | 由于代碼可能相互影響，因此這部分額外 的功能可能對其他功能的實現造成影響， 帶入新的Bug |
| 增加額外的開發、測試時間 | 在軟件項目時間固定的情況下，導致投入 到其他必備功能的開發測試時間減少， 可能影響它們的完成質量 |
| 增加了成本， 與軟件的宣傳不完全符合 | 雖然用戶對于增加功能一般不會有意見， 但可能影響了公司的銷售策略和市場定位 |
4．軟件沒有實現說明書中沒有提到但應該實現的功能
小白一般是將網上找到的有用文檔保存在隨身攜帶的U盤中。這一次，他在測試記事本程序的時候，同樣打算將文件保存在 U盤上，可是由于連日來的文檔太多了，優盤已經沒有空間，記事本提示無法保存，同時系統托盤有提示說磁盤空間已滿。在這種情況下記事本的行為，就屬于實現 了說明書中沒有提到卻應該實現的功能（在磁盤滿的情況下，給用戶以提示）。如果沒有提示，不符合絕大部分用戶的使用習慣，也是一個Bug。
5．軟件難于使用、性能差
軟件是拿來用的，再好的界面使用不方便也不會產生多大效果。一個網站如果半天都打不開，很難想象還會有多少用戶會訪問它。因此這樣的問題也是Bug，而且對于性能測試來說，這一個規則很重要。
1.2.3 發現蟲子的危害
既然軟件Bug對產品造成了這么多的影響，那么發現它就顯得非常重要了。業內人士都認為，在軟件生命周期內的不同階段發現Bug，所節省的成本是不同的，如圖1-5所示。
圖1-5 軟件生命周期內各階段發現與改正Bug所需成本示意圖
從圖中可以看出，在產品設計階段發現Bug要比在產品維護階段發現好得多，這是很好理解的。
在需求分析階段，對于用戶需求的理解停留在需求文檔中，對其中理解不正確的部分只需要修改文檔即可以，基本不會產生什么成本。
在軟件設計階段，發現的Bug很多都是設計思想的缺陷。由于尚未開始編碼，這樣的Bug一般需要進行深入的討論最終獲得一種正確的結論，因此改正成本也不高。
在軟件編碼階段和測試階段，代碼通過開發人員和測試人員的努力在進行不斷的完善，有關Bug的成本主要花費在項目內部的溝通與時間成本方面。
但是一旦產品發布，在軟件維護階段發現的Bug，其修改成本會非常高昂：一是因為軟件成為了系統，與開發階段重點檢 查各模塊功能相比更為復雜，尋找代碼上的產生Bug根源更加困難。特別是，如果前期工作沒有做好的話，甚至軟件產品的結構都需要進行大修改；二是因為牽扯 的部門明顯增加，比如客戶服務部門、產品部署部門、銷售部門等都要參與，導致公司內部、公司與客戶之間的溝通成本急劇增加；第三點則是影響產品質量與公司 的信譽、未來產品的銷售。
【千年蟲的問題】
在前幾年，有一個著名的蟲子把業內攪得不可開交，那就是千年蟲問題，也叫做2000年問題。它是指在某些使用了計算 機程序的智能系統（比如一般的計算機系統以及自動控制芯片等）中，由于其中的年份沿用早期的設計，只使用2位十進制數來表示，比如用80代表1980年， 因此當系統進行（或者涉及到）跨世紀的日期處理運算（比如計算1980年到2080年之間的日期）時，就會出現錯誤的結果，從而引發各種各樣的系統功能紊 亂甚至系統崩潰。
從千年蟲的實際例子中也可以看出，不考慮硬件上的限制，如果當初在設計日期表示格式的時候能夠想得更長遠一些，就完 全可以避免這個蟲子的發作，從而節省一大筆修改更新軟件等的費用（據未經證實的來自美國國際資料公司調查報告表明，光是1995年到1998年，全球捉" 千年蟲"的開銷就已經達到驚人的1840億美元）。
1.3 軟件測試的定義與分類 前文花費了不少文字來講述Bug的定義、危害和判斷原則，本節將在更廣的范圍內介紹軟件測試的定義與分類。
1.3.1 軟件測試的定義
軟件測試就是利用一定的方法對軟件的質量或者使用性進行判斷和評估的過程。這一定義獲得了較廣泛的認同。
1.3.2 軟件測試工程師的工作內容
軟件測試是由軟件測試工程師來完成的，他們的主要工作內容則是：
尋找軟件中的Bug，并且是越早發現越好（原因見1.2節）。
確認Bug的可重復性（Repro）以及Bug產生的步驟。
確認Bug是否被解決（Fixed）。
測試方法、測試計劃、測試平臺、測試代碼、測試用例、測試文檔、測試報告的確定、編寫和執行。
對于小白這樣剛入職的新人來說，主要工作就是前3項以及測試用例的編寫了。在1.4節將講述測試用例的知識。
1.3.3 軟件測試的分類
軟件測試可以有很多種分類，常見的有如下一些：
黑盒測試（Black box testing）；
白盒測試（White box testing）；
功能性測試（Functional testing）；
兼容性測試（Compatibility testing）；
性能測試（Performance testing）；
安全測試（Security testing）；
壓力測試（Stress testing）。
雖然看起來很多很復雜，但是目前，小白所要做的工作就是先熟悉這些名詞，這樣在閱讀眾多的技術文檔時，了解這些名詞屬于軟件測試的范疇就可以了。
對于軟件測試的兩個核心，則有必要在第1章詳細的介紹。這兩個核心分別是測試用例和測試工程師，分別代表了軟件測試的兩個方面：工具和人。
（未完待續）
相關鏈接：
捉蟲記--大容量Web應用性能測試與LoadRunner實戰(連載一)