第1章 什么是軟件測試
在我國宋代，有一位叫宋慈的法醫學家寫了一本《洗冤集錄》。在書中，他講述了很多斷案的經驗，其中有一個用銀針驗毒的方法至今仍廣為流傳。比如在很多電視劇中，我們能經常看到皇帝在進膳的時候，由于害怕被人暗害，總要讓可憐的太監或者宮女先用銀筷子嘗上幾口飯菜，沒有出現問題再正式用餐。這種用銀針進行的試驗就可以說是一種測試的雛形吧，銀針充當了測試工具，而太監或者宮女就是古代的測試工程師。
時光飛逝。隨著科技的發展，我們生活周圍有了越來越多的產品，它們在出廠銷售前都要進行測試，不僅要保證功能完好，還要確保對使用者的傷害在允許范圍內。因此在工廠里，逐漸出現了這樣一個部門，由它來負責檢驗產品，被稱之為質量檢驗或者質量保證部。
上個世紀中后期，軟件出現了，它作為人們日常生活中天天都會使用的產品，同樣也需要質量的保證。有一種誤解：軟件的質量問題并不那么重要，比如Windows等操作系統，各種桌面的應用軟件，像IE瀏覽器，如果它出現了問題，程序會失去響應甚至嚴重的系統會藍屏，那么只需要在任務管理器中將它刪掉就可以了，最多重新啟動電腦，一般都能夠繼續使用。這只是一方面，另一方面，有很多非常重要的軟件在我們看不見的地方默默地運行著，如果它們出現了問題，影響就很大了。
為了說明軟件質量的重要性，這里舉一個比較著名的軟件質量造成的事故。
1962年，美國的航海家1號（Mariner 1）火箭升空，由于控制火箭的軟件出現問題，直接導致火箭升空后因偏離軌道而被迫引爆，造成當時1800萬美元的損失。事后查明，是程序員在編寫軟件代碼時，誤寫了其中一個公式的上標造成軌道計算失誤的。
因此，軟件公司也需要質量保證部門。我們把該部門的組成人員稱為QA工程師，QA即Quality Assurance質量保證的簡稱。軟件是否符合質量是通過測試來驗證的，因此他們也被稱為軟件測試工程師。在本書中您即將遇到的各種行為，絕大多數都將是軟件測試工程師在工作中所要實現和完成的。
1.1 軟件開發的基本知識
對于每一位進入軟件測試行業的新人來講，公司的入職培訓是一個很好的學習機會。
1.1.1 軟件開發公司技術部門的基本結構
可將軟件測試部門類比于工廠車間的質量保證部門，那么顯而易見，如果在工廠中要做好質量控制的工作，必須熟悉本廠生產的產品和流程。換句話來說，作為軟件生產的參與者，了解被測試的軟件也是非常重要的一件事情。這也正是經理要求小白在短期內盡快熟悉的內容。
【什么是軟件】
中國大百科全書中對軟件的定義是：軟件是計算機系統中的程序和相關文件或文檔的總稱。軟件是從英文Software翻譯過來的名詞，與硬件（Hardware）相對應。
因此，軟件開發公司就是制造這些程序和相關文件或文檔的商業機構。一般來說，軟件開發公司的技術部門由幾個子部門或者角色組成：開發部門、測試部門、部門經理或者項目經理，另外有的公司還有技術支持部門。對應于傳統行業，分別相當于生產車間，質量控制部門，部門經理和售后服務部門。如表1-1列出了常見軟件開發公司技術部門的不同職責。
表1-1 常見軟件開發公司技術部門的角色分類
部 門 | 職 責 |
軟件開發部門 | 開發軟件：確定軟件實現方法， 編寫軟件程序代碼 |
軟件測試部門 | 測試軟件：確定測試方法，編寫自動 測試軟件的代碼，手工測試軟件， 記錄并跟蹤軟件Bug |
技術總監或項目經理 | 在所屬或其他部門之間溝通，協調項 目或者開發測試進度，為成員提供各種資源 |
技術支持部門 | 軟件開發完成后在客戶處部署產品， 并解決與反饋使用中出現的問題 |
Web應用是一種特殊的軟件。那么開發Web應用的網站與一般的軟件開發公司有什么不同呢？
對于小白所處的商業網站來說，網站程序和相關文件或文檔也可以稱之為軟件，其技術部門的結構也和軟件開發公司基本類似，但是各部門日常工作的方式則有所不同。
商業網站每天都要有很多頁面的更新，每次更新后當時瀏覽網站的人立即可以看到；而軟件開發公司一般一年或者幾年推出一個產品，在產品沒有上市的時間內，用戶只能使用舊的版本。也就是說網站軟件的變化要比軟件開發公司頻繁，網站軟件的開發與用戶使用處于同一時間段內。
商業網站以服務器為核心，網站軟件主要運行在服務器上；而軟件開發公司的產品主要運行在用戶的電腦上。
【演唱會與專輯】
商業網站與軟件開發公司的運作模式有點類似于歌手開演唱會和發專輯的區別。在演唱會上，歌手與觀眾的互動性更強，每一個細節的變化也都能被觀眾捕捉到；而歌手專輯則相當于軟件產品的某個版本，是提前制作完成之后再上市銷售的。
1.1.2 軟件危機
小白在熟悉了技術部門的大致結構，網站與軟件開發公司的區別之后，經理開始介紹和軟件測試相關的背景知識。軟件危機就是產生軟件測試這一職業的重要推動力之一。
從20世紀50年代以來，軟件的規模越來越大，復雜性也越來越高，另外，在20世紀80年代，伴隨著計算機的普及和應用需求的飛速增長，互聯網開始蓬勃興起。現在，現代人的生活已經越來越依賴各種各樣的軟件，軟件不再是大學實驗室里科學家的工具，而成為我們生活的一部分。從操作系統，比如每一臺個人電腦所安裝的Windows XP或者Vista系統，到小小的桌面程序--一個簡單的連連看小游戲，再到Google網站上可以編輯的在線文檔工具，軟件的開發、管理、維護的復雜性和高成本現象也日益突出，在某一段時期，暴露了很多問題。因此在20世紀，有人提出了"軟件危機"的說法，來說明這種現象。
【軟件復雜性的類比】
其實我們中國人是很容易理解軟件復雜性的。一些在人口少的國家不成為問題的問題，放在十幾億人口的環境中，就會產生不大不小的麻煩，比如每年的春運--需要火車票的人是如此之多，而火車的座位是固定數量的；需要回家的人的分布是如此之廣，而火車站的位置也是固定的。依此類比，當軟件的代碼量越來越龐大，要滿足的需求越來越廣泛時，出現局部的危機是很容易理解的。
1.1.3 軟件危機的幾個體現
隨著軟件越來越復雜，質量越來越難于控制，于是出現了所謂“軟件危機”。具體而言，軟件危機有以下幾個體現。
軟件需求的增長無法快速得到滿足。這一點在前文已經有所講述。
軟件生產成本變高，價格越來越昂貴。軟件的代碼量增加，所投入的人工成本，也就是軟件開發相關人員的成本也會增加，還要增加采用各種新技術的成本等。
軟件生產進度難于控制。
軟件的用戶需求不容易定義。這一點也很重要：目前絕大多數的軟件已經不止滿足單一的需求，因此用戶真正所需要的不一定能夠完美地實現。
軟件質量不容易保證。這一點也是由軟件復雜度的增加而增加。還是舉春運的例子，如果火車上人人都有座位，那么每個人的心情都會很好；但如果到處擠滿了人，每位旅客回家的心情總會受到影響，從而影響對列車服務的評價。軟件質量和用戶的評價同樣是相關的：經常造成死機、異常退出或者按鈕單擊后沒有反應的軟件，很難說是質量好的軟件。
軟件可維護性變差。軟件同樣是需要維護的：一方面是對于用戶使用過程中的維護，這一功能由客戶服務或者技術支持部門來完成；另一方面是對于軟件本身代碼和文件文檔的維護，這一功能由開發部門或者測試部門來完成。隨著軟件的日益龐大，軟件本身經歷的修改越來越多，管理維護軟件的各種版本變得日益困難。
由于軟件危機有這么多的影響和危害，所以促使人們靜下心來研究軟件開發過程中的規律，這就產生了軟件生命周期的概念。
1.1.4 軟件生命周期
軟件生命周期，英文為Software Lifecycle，就是軟件開發、使用和消亡的過程，具體而言，包含軟件需求分析、軟件設計、軟件實現與測試和軟件發布、部署與維護這4個過程。
在商業軟件開發公司內部，人們往往遵循一定的軟件生命周期模型，這樣和被開發軟件相關的所有人員都按照這個模型的標準或者步驟開展工作，統一行動，有助于提高生產效率，從而減少溝通和實施的成本，獲得更大的商業利益。而對于軟件生命周期的不同理解和劃分，就形成了不同的軟件生命周期模型。
1.1.5 常見的軟件生命周期模型
目前來講，主要的軟件生命周期模型有如下幾種。
Big-Bang：大爆炸模型。
Waterfall：瀑布模型。
Spiral：螺旋模型。
Code and Fix：邊做邊改模型。
由于本書并不是以軟件工程為探討內容，因此在這里只通過人們過河的類比來簡單介紹一下前述這幾種軟件生命周期模型的特點。
小學課本里有個寓言叫做"小馬過河"，小馬在過河前遇到了不同的小動物，它們對于河水深度的理解是不同的，會導致小馬過河時的不同選擇，參見圖1-1。假設把待開發的軟件產品比喻為小馬面前橫著的那條小河，那么開發軟件的過程也就是過河的過程，那么如何過河就會有不同的結果。
圖1-1 小馬過河：對河深度的理解影響過河的方法
1.1.6 直接沖過河去的大爆炸模型
大爆炸這個名稱來自于天體物理有關宇宙形成方式的一種理論：宇宙是在億萬年前的大爆炸中誕生的。與此類似，軟件開發公司把金錢、辦公場地和人員全部投入到一個產品的開發當中，經過一段時間，產品出爐，這樣的形式就是大爆炸模型。
大爆炸模型的優點就是簡單，沒有很多的軟件設計，對項目的管理也很少，目前不少小公司由于各方面的限制不得已或者不自覺地采用了這樣的開發模型。但是它的優點也造成了它的缺點：開發出來的軟件質量不可控制。
在這樣的模型中，由于沒有周密的計劃，軟件測試往往是在產品即將上市的前夕才開始，在很多公司中甚至沒有專職的測試工程師，由開發人員或者其他人員代勞，因此測試人員面對的產品與客戶、使用者要面對的產品基本一致。從前文所述可以得知，在這樣的階段發現Bug，返工修改代碼的代價是非常大的。
回到過河的比喻中來，大爆炸模型就相當于小馬先退后幾步，集中精力和能量，然后快速沖過去。這樣的結果取決于河的寬度和深度。如果軟件非常復雜，很可能過河的小馬半途就淹死了，無法到達對岸。
1.1.7 摸著石頭過河的邊做邊改模型
邊做邊改模型比起大爆炸模型來說進了一步。在開發軟件產品的開始階段，先有一個大概的設計，然后開始編碼，測試，發現Bug，修改Bug這樣的循環，直到整個產品的輪廓日漸清晰，最終完成產品。用一句俗話來描述，就是"摸著石頭過河"的過程：先以河里的一些石頭為支點，走入河道，再經過不斷的試探和返回得到一條路線，最終到達目的地。
由此可見，邊做邊改模型中測試的參與要比大爆炸模型中要早得多，而且也重要得多。邊做邊改模型的優點就是適用于某些中小型項目的快速開發，軟件產品的成果也會在最早的階段顯現出來：和在岸邊冥思苦想如何過河的人相比，先站在河道里的石頭上，總是讓人看到更多的希望。
【邊做邊改模型被較多采用】
這種開發模型被大多數公司所采用，是大多數測試工程師在實際工作中最常遇到的開發模型之一。而且，它和最近幾年很流行的敏捷開發也有一定的關系。
1.1.8 制定周密過河計劃的瀑布模型
從現在開始，下面的這兩個模型就不適合小馬了，只有人和外星人才有這樣的能力。如圖1-2介紹了軟件開發的瀑布模型，由于圖中的箭頭好像瀑布的水流，從上至下，因此得名。
圖1-2 瀑布模型示意圖
回到過河的例子中來，瀑布模型過河具備如下特點：
過河前，首先花費大部分的時間對河進行詳細的勘察，選擇合適的下水點，選擇合適的過河工具，制定詳細的分步驟過河計劃。
一旦過河計劃制定，將不會大更改，開始過河。在河中完全按照計劃進行，無法返回起點。這也是為什么稱此模型為瀑布的原因，瀑布是飛流直下三千尺，想從下面返回瀑布的頂端，何其難。
在每步驟即將完成時，都會對這一步驟進行總結，如果進行下一步驟的條件不具備，將停留在原地，等待條件具備。
瀑布模型看起來給人很專業的感覺，所以，對于軟件開發人員有比較高的要求。
要對待開發的軟件（或者要過的河）有細致、全面、準確的了解。如果理解錯誤，將導致計劃失敗，沒有返回重來的機會。
職業素質、職業紀律要比較高。軟件開發人員要具備堅定執行計劃的能力。
這種要求也就產生了瀑布模型的缺點，那就是無法完美適應當今要求快速開發產品，從而占領市場的軟件行業現狀。因為制定詳細的、理解完整的計劃很難，聚合很多專業的開發人員有時候也很難，而市場對于軟件更新換代的要求期限越來越短。為了適應變化，人們又提出了螺旋模型。
1.1.9 計劃趕得上變化的螺旋模型
前文提到，為了適應計劃和變化兩方面的因素，螺旋模型被提出。螺旋模型的示意如圖1-3所示。可以看到，它的確很類似一個螺旋。
圖1-3 螺旋模型示意圖
與邊做邊改模型類似，螺旋模型也具有循序漸進的特點，對軟件最終實現什么不一定有完全確定的理解，而是摸著石頭先下水。但是在選擇過河的每一個石頭前經過了周密的計劃和考慮，從這一點看，又類似瀑布模型。可見，螺旋模型實際上是邊做邊改模型和瀑布模型的有機結合。螺旋模型有如下4個步驟。
（1）確定項目目標、可用資源、各種實現的方法，項目的各個階段。
（2）在某個階段中，確認、解決當前階段項目進展中出現的風險。
（3）評估各種方法，開發、測試代碼，實現當前階段的目標。
（4）總結當前階段，計劃下階段的目標和實現方法，重復第（2）步。
在圖1-3中螺旋線被兩條直線劃分成4個部分，分別是上述的4個步驟。在每一步驟中由于被直線切割會有多段曲線，每一段曲線就代表了在不同階段中所進行的相同某個步驟。
【螺旋模型的優點】
由此可見，螺旋模型是多次計劃，邊做邊改，這樣既保證了軟件開發任務的清晰，也降低了開始一次計劃，因為理解不完整或者市場變化后導致項目失敗的可能性。
1.1.10 4種模型的總結
前文講述了4種軟件開發模型，那么在具體項目開發中采取哪一種最好呢？答案是它們各有利弊，需要靈活采用。這幾種開發流程的優缺點比較如表1-2所示。
表1-2 4種軟件開發流程的優缺點
開發流程分類 | 優 點 | 缺 點 |
大爆炸模型 | 簡單，不用學習就會 | 拍腦門的想法，產品質量 無法保證。盡量避免使用 |
邊做邊改模型 | 快速得到可運行的版本 | 計劃有些缺乏，導致版本前 后變化較大。可選擇的模型之一 |
瀑布模型 | 計劃周密，專業， 按部就班實現 | 相對難于做到快速開發， 以搶占市場。可選擇的模型之一 |
螺旋模型 | 計劃變化同時考慮 | 可選擇的模型之一 |
當然，在幾十年的軟件開發過程中，人們還提出了很多其他的開發模型，不過，作為測試工程師，我們對這幾種主流模型有所了解就可以了。進一步深入的內容并不是本書所講述的范疇，讀者可以參看軟件工程的相關書籍。
1.1.11 軟件開發的幾個階段
不管采用哪一種開發模型，按照時間順序，所有的軟件開發項目都要經歷如下4個階段。
（1）項目啟動階段：了解客戶需求、配置相關資源。
（2）項目設計階段：明確客戶需求，確立軟件開發、測試的方法。
（3）項目執行階段：開發與測試階段。
（4）項目竣工階段：軟件的上市、后期維護與技術支持。
這一分類很好理解，下面再結合小白的工作場景，進行展開介紹。
（1）項目啟動階段。這一階段一般技術人員參與較少，主要是市場部門，銷售部門，技術總監、項目經理等角色的參與：項目成本是多大，開發人員有多少，測試人員有多少，完成時間在什么時候等。
（2）項目設計階段。這一階段主要參與者就是需求分析人員、開發人員、項目經理和小白這樣的測試人員了。主要目的是確定軟件該如何做，做什么：開發人員利用何種技術開發，測試工程師該如何測試該軟件，客戶如何使用該軟件等。這些問題都要確定，形成各自的開發文檔、測試文檔和需求文檔等。
（3）項目執行階段。開發、測試以及對其的管理就是執行，這一階段的參與者是開發人員、測試人員和項目經理。開發人員編寫程序代碼，進行單元測試；測試人員編寫測試代碼、測試用例，進行功能測試等多種測試。項目經理控制進度，協調各種資源，與設計人員溝通等。
（4）項目竣工階段。當項目執行完畢的時候，依然要進行部署、軟件光盤生產、客戶支持、升級補丁包開發和測試等多項工作。這階段主要的參與者是項目經理，少量的開發人員和測試人員，售后技術支持人員、客戶服務人員等。
1.1.12 軟件發布的方式
按照目前的軟件發布方式，一般有RTM（Ready To Market，市場發布）、RTW（Ready To Web，在網絡上發布）、RTO（Ready To Operation，可以運營）等多種方式。
RTM方式需要在工廠進行光盤的復制生產，用戶購買光盤后安裝。大部分的操作系統和應用軟件采用這種方式的比較多。
RTW方式需要在網絡上提供下載鏈接，一般的軟件升級包或者游戲軟件采用這種方式的比較多。
RTO方式則很簡單，在服務器上部署軟件產品，用戶購買其中的某項或者多項服務即可，這是大部分網站或者在線游戲采用的方式。
1.1.13 項目管理與甘特圖
前面提到軟件項目的流程很重要，那么這種流程的控制一般是由項目經理來完成的，他或者她所從事的這個工作叫做項目管理。
小白所在的技術部門一般一周都要開一個例會，在會上，開發部門、測試部門和項目經理都要對上一周各自所做的工作進行一番總結，安排下周將要做的工作。在這樣的例會上，同事們經常會查看項目的進度圖來進行講解，他們把這樣的進度圖稱為甘特圖（Gantt Chart）。
如圖1-4顯示的是軟件開發過程中常用的項目管理工具Microsoft Office Project軟件（在這里是2003版本，最新為2007版本）運行的界面，在其中我們可以清楚地看到軟件生命周期中的各個子任務的時間分配，負責人員和項目進度的甘特圖。
圖1-4 Project 2003中的甘特圖
【甘特圖的來歷】
甘特圖的名稱由發明者亨利·勞倫斯·甘特（Henry Laurence Gantt，1861-1919）而來。甘特早年從事的是電氣工程師的職業，后來轉而從事管理業界的咨詢。甘特圖是他在晚年發明的一種用于顯示項目計劃和進度的圖表。在誕生的初期，甘特圖就被譽為20世紀20年代的最重要發明之一，廣泛應用于一系列的大工程之中。比如1931年前后修建的美國胡佛水壩（如果你看過2007年的熱門電影《變形金剛》，那么對關押威震天的那個水壩應該有印象，它就是胡佛水壩）。在軟件開發領域，很多公司也應用甘特圖這一工具來進行項目管理，比如著名的微軟公司。
（未完待續）