第1章  軟件測試引論

1.1  質量和質量認識論

質量的重要性是顯而易見的，客戶不可能去購買一個存在質量問題的產品，生產廠商如果生產出存在質量問題的產品就不可能賣出去。因此，有不少人說質量是決定產品存在的價值，質量是企業(yè)的生命。那么，什么叫質量呢？

質量這一概念有許多不同的定義，不同的立場，不同的觀念，對質量的定義就會不同。拋開這些因素，舉例說明?！掇o海》和《辭源》中，把質量解釋為“產品或工作的優(yōu)劣程度”。世界著名質量管理專家Juran博士，在他的經典著作《質量控制手冊》中，把質量定義為“產品在使用時能成功地適合用戶目的的程度”。再如，國際標準化組織（ISO）把質量定義為：“反映實體（可單獨描述和研究的事物，如活動、過程、產品、組織、體系或人，以及它們各項的任何組合）滿足明確和隱含需要能力的特性總和”。那么，人們是如何認識質量的呢？

狹義的質量概念就是產品質量。所謂產品質量好，往往被人們認為生產出最佳產品，即在盡可能充分利用現代生產技術水平的條件下，制造出最好的產品。而且，所謂“好”，常常僅從產品性能著眼。這種概念不能反映質量的全部內容。

廣義的質量概念包括產品質量和工作質量兩個組成部分，即全面質量。它既要反映客觀的要求，又要考慮到設計、制造、銷售服務的水平和能力。

在這里，需要對產品作一解釋，產品可分為4種類別，即硬件、流程性材料、軟件和服務。硬件是不連續(xù)的具有特定形狀的產品，如空調、洗衣機、電視機等；流程性材料是將原料轉化為某一預定狀態(tài)的有形產品，如流體、氣體、粒狀、塊狀、線狀或板狀，其典型的交付方式有桶裝、袋裝、罐裝、瓶裝或通過管道；軟件是通過支持媒體表達的信息所構成的一種智力創(chuàng)作，軟件的形式如概念、信息、程序、規(guī)劃、記錄、計算機程序等，可見此處的軟件是泛指，不單指計算機軟件；服務是為滿足客戶的需要，供方和顧客之間在接觸時的活動，以及供方內部活動所產生的結果。因此，產品的提供和使用可構成服務提供的一部分。服務可以與產品的制造和提供相關聯。當然，服務亦需投入資源和活動，也是一種價值的增值。

影響質量的因素是什么？其包括5大因素：人、材料、設備、方法和環(huán)境。顯而易見，人的因素第一，有了人的主動性、對質量的深刻認識，就會非常重視質量的各個環(huán)節(jié)；材料也非常重要，半導體的收音機和集成電路的收音機取材不同，質量也就有天壤之別；設備的先進程度和工作狀態(tài)的好壞也能夠深刻影響產品質量；方法包含內容更廣泛，它可以是生產方法、設計方法、管理方法、檢驗方法，這就是技術因素；環(huán)境也非常重要，集成電路的生產就與環(huán)境密切相關，如塵埃就能決定集成電路塊是否報廢。

任何一個機構，都必須確定質量目標，質量目標就是產品和工程質量在一定時間內可達到的水平，產品和工程質量目標的制訂需做3個方面的調查。

（1）用戶對開發(fā)新產品或改進老產品的意見和要求，包括產品性能、可靠性、安全性、價格、使用維修、外觀包裝和運輸儲存等。

（2）生產過程中老產品曾經出現過的問題及新產品開發(fā)中可能發(fā)生的問題。

（3）國內外有關的技術與經濟情況。

制定質量目標還需考慮成本的增加。任何一個產品或者工程項目，其價格是由銷售成本所決定的，銷售成本包括生產成本、質量成本和利潤。就質量成本而言，包括損失成本、檢驗成本和預防成本。損失成本是因產品未能達到質量要求而造成的各項損失費用，一般包括內部損失（如報廢、返修、降級等）和外部損失（如拒收、索賠、聲譽破壞等）；檢驗成本是用于檢驗產品質量所需的各項費用；預防成本是用于預防產生不良產品所需的各項費用，如員工培訓、質量管理開銷、檢測設備購置等。

現在人們不僅從技術層面上去思考產品質量，也從質量管理的角度去思考產品的質量保證，ISO 9000、CMM等都可以看作質量管理所引發(fā)的對機構在質量保證方面的考核。所謂質量管理就是為保證和提高產品或工程質量所進行的調查、計劃、組織、協(xié)調、控制、檢查、處理及信息反饋等各項活動的總和。按照國際標準化組織的定義，則包括確定質量方針、目標和職責，并在質量體系中通過例如質量策劃、質量控制、質量保證和質量改進，使其實施全部管理職能的所有活動。質量體系是為實施質量管理所需的組織結構、程序、過程和資源；質量策劃是確定質量以及采用質量體系要素的目標和要求的活動，包括產品策劃、管理和作業(yè)策劃，以及質量計劃的編制和質量改進的準備工作；質量控制是為達到質量要求所采取的作業(yè)技術和活動；質量保證是為了提供足夠的信任表明實體能滿足質量要求，而在質量體系中實施并根據需要進行證實的全部有計劃有系統(tǒng)的活動；質量改進是為向本機構及其顧客提供更多的收益，在整個機構內所采取的旨在提高活動和過程的效益和效率的各種措施。有關這些概念的認識，讀者可以參考清華大學出版社于1999年出版的《軟件企業(yè)ISO 9000質量體系的建立和認證》一書。

1.2  軟件產品和其他產品的差異

1.1節(jié)中所講的產品包括4種類別，其中的軟件還不是單指計算機軟件，其范圍亦大得多。自從1968年提出軟件工程這一概念以來，就希望能夠借助傳統(tǒng)的工程方法來研發(fā)出軟件產品。因此，軟件產品在某些方面的確相似于其他工程中的有形產品，但畢竟不相同，它們之間存在一些重要的差別。所以，在軟件工程中，人們認識到不能夠簡單地把一般工程中的知識、方法和技術直接應用到軟件工程上來。那么軟件產品和其他產品有什么不同呢？

（1）軟件是邏輯產品而不是實物產品?？梢源致缘卣f軟件不是有形產品，磁盤、集成電路塊只是軟件的載體。這一事實就意味著費用集中在研制開發(fā)上而不在生產上。當然，由于是邏輯產品，軟件就不會用壞、磨損、老化，而且可以不斷地改進、優(yōu)化，其可靠性由邏輯確定。開發(fā)軟件在許多方面更像進行數學證明，可是軟件產品的評價卻主要決定于它們在問題求解中是否有用，而不是決定于抽象的正確性判定標準。換句話說，開發(fā)軟件產品時主要使用的是工程標準，而不是數學標準。

（2）由于軟件是邏輯產品，使得它的功能只能依賴于硬件和軟件的運行環(huán)境，以及人們對它的操作，才能得以體現。沒有計算機相關硬件的支持，軟件難有實用價值。同樣，沒有軟件支持的計算機硬件，也只是毫無使用價值的機器。軟件與硬件的密切相關的程度是一般工程所沒有的。

（3）對軟件產品的要求比一般有形產品要復雜。其一，軟件產品要完成的多種多樣功能，用戶難以清晰、準確地表達。憑此一項，軟件系統(tǒng)的復雜性可以比得上歷史上任何一個工程項目：即使保守估計，一個100萬條匯編語句的軟件，至少有1萬個分功能，其中每一個分功能至少可以用兩種不同方式制定。所以，在功能上，軟件設計者也得要從2¹⁰⁰⁰⁰（相當于10³⁰⁰⁰）種功能組合中進行挑選。其二，對軟件產品的要求，如可靠性、易移植性、易使用性等是隱含的，也是難以表達的，而且也缺少度量的具體標準，和有形產品的質量檢驗的精度相距甚遠。其三，軟件設計不僅涉及到技術復雜性，也涉及到管理復雜性。     美國Hetgel曾講過，當他負責一個軟件研制小組時，認為關鍵的問題是方法學問題；當他負責50人的軟件開發(fā)項目組時，逐漸理解到除方法學之外，程序文檔變得越來越重要了；后來他又領導200人的軟件開發(fā)項目組時，他的認識又有了變化，認識到最關鍵的問題是管理問題。這是很有代表性的認知過程。即使在今天軟件工程已有很大進展的情況下，許多人都不愿意去領導一個龐大的項目組。能像其他工程項目那樣進行規(guī)?；a并非易事。

（4）在軟件設計時發(fā)生的復雜性，引起的軟件特征包括4方面。其一，功能的多樣性。軟件提供的功能比一般工程產品提供的功能更加多種多樣，以致用戶一時難以掌握。為此，使用軟件產品，往往還會伴隨一個培訓任務，而且軟件產品的用戶手冊還不一定能全面描述其功能。其二，實現的多樣性。對軟件產品的要求不僅僅包括功能和性能要求，還必須包括在符合功能和性能要求的各種實現中作出選擇，更有實現算法上的優(yōu)化帶來的不同，所以實現上的差異會帶來使用上的差異。其三，能見度低。要看到軟件進度比看到有形產品的進度難得多，這里涉及到如何使用文檔（document）表示的概念能見度，這又為軟件管理復雜性增加難度。其四，軟件結構的合理性差。結構不合理使軟件管理復雜性隨著軟件規(guī)模增大而呈指數增長，換句話說，軟件規(guī)模的增長所引起的管理復雜性成了設計的難題。總之，前兩方面屬于技術復雜性。后兩方面屬于管理復雜性。為了控制軟件復雜性，人們進行了各種研究，這在一般工程中是前所未有的。

（5）任何一種工程，在其年輕時代總是人工密集的，而到其成熟時期卻成為資金密集的。但是軟件工程卻也有它自己的特點，盡管今后可能有許多活動可以自動化，而軟件的資金密集程度終究會比其他工程學科中的資金密集程度高，其中包含更多的人的成分，可以說軟件工程是智力密集型。從而，它的知識產權保護就顯得極為重要，軟件本身會越來越值錢，逐步體現出它應有的價值。

1.3  軟 件 質 量

1.2節(jié)討論了軟件產品與其他產品的差異，那么軟件產品質量與其他產品的質量有沒有區(qū)別呢？先來看軟件質量的定義：反映軟件系統(tǒng)或軟件產品滿足明確或隱含需求的能力有關的特性總和。其含義有四：其一，能滿足給定需要的性質和特性的全體；其二，具有所期望的各種屬性的組合程度；其三，顧客和用戶覺得能滿足其綜合期望的程度；其四，確定軟件在使用中將滿足顧客預期要求的程度。簡言之，軟件質量是軟件一些特性的組合，它依賴軟件的本身。

對于軟件質量有多種不同的視面。用戶主要感興趣的是如何使用軟件、軟件性能和使用軟件的效用，特別是在指定的使用環(huán)境（context）下獲得與有效性、生產率、安全性和滿意度有關的規(guī)定目標的能力，即使用質量。開發(fā)者負責生產出滿足質量要求的軟件，所以他們對中間制品和最終產品的質量都感興趣，當然開發(fā)者視面也要體現軟件維護者所需要的質量特性。對于管理者也許更注重總的質量而不是某一特性，必須從管理準則，如在進度拖延或成本超支與質量提高之間進行權衡，以達到用有限的人力、成本和時間使軟件質量達到優(yōu)化的目的。

保證軟件質量基本上可用兩種途徑來實現，一種是保證生存周期過程，另一種是評價軟件最終產品的質量。這兩種途徑都很重要，且都要求有一系統(tǒng)來管理質量，該系統(tǒng)應確定管理對質量的保證，指明其策略以及恰當的詳細執(zhí)行步驟。前者是采用ISO 9001質量體系——設計、開發(fā)、生產、安裝和服務的質量保證模式，或者CMM——能力成熟度模型，或者ISO 15504軟件過程評估（也稱為SPICE，即軟件過程改進和能力確定）等方法來取得滿足質量要求的軟件。后者是把軟件產品評價看作軟件生存周期的一個過程，目標就是讓軟件產品在指定的使用環(huán)境下具有所需的效用，可以通過測量內部屬性，也可以通過測量外部屬性，或者通過測量使用質量屬性來評價。

軟件質量管理  經濟地實現符合用戶要求的軟件質量或服務的方法體系及其一系列活動，具體包括確定質量方針和目標、確定崗位職責和權限、建立質量體系（如質量策劃、質量控制、質量保證和質量改進）并使之有效運行等所有活動。任何一個機構，要想使自己提供給用戶的產品達到并保持一定的質量水平，都必須進行嚴格的質量管理。對于一個軟件機構來說，也必須建立質量管理體系。目前能被大家接受和公認的是基于軟件生存周期過程的質量管理，包括ISO 9001、CMM、ISO 15504等都是屬于這種類型，如能力成熟度模型（CMM）較全面地描述和分析軟件機構的軟件過程能力的發(fā)展程度，建立了一個描述軟件機構的軟件過程成熟度的分級標準和框架。軟件過程能力是描述遵循一個軟件過程而得到期望結果的程度，軟件過程成熟度是指一個具體的軟件過程被明確定義、管理、控制其實效的程度。利用能力成熟度模型，軟件機構可以評估自己當前的過程成熟度，并通過提出更嚴格的軟件質量標準和過程改進，來選擇自己的改進策略，以達到更高一級的成熟程度。軟件產品評價需要策劃和管理，從而也是管理職能中的一個部分。

軟件質量模型  一個框架，它規(guī)定了內部和外部質量的質量模型與使用質量的質量模型，以及它們在軟件生存周期中的關系。內部和外部質量的質量模型將軟件質量屬性分類為6個特性，即功能性、可靠性、易用性、效率、易維護性和易移植性，并進一步細分為27個子特性，從而構成一個有層次的樹狀結構，結構的最高層由質量特性組成，最低層則由軟件質量屬性組成。使用質量的質量模型將軟件質量屬性分類為4個特性，即有效性、生產率、安全性和滿意度。獲得軟件的使用質量依賴于所取得的外部質量，而取得的外部質量依賴于獲得必要的內部質量，所取得的內部質量又依賴于生存周期中所規(guī)定的過程的質量。同樣，為了獲得所需的使用質量，就有助于確定外部質量需求，從而有助于確定內部質量需求，進而有助于確定過程的質量。

軟件質量特性

功能性：在指定條件下使用時，軟件產品提供滿足明確和隱含需求功能的能力；

可靠性：在指定條件下使用時，軟件產品維持規(guī)定的性能級別的能力；

易用性：在指定條件下使用時，軟件產品被理解、學習、使用及其吸引用戶的能力；

效率：在規(guī)定條件下，相對于所用資源的數量，軟件產品可提供適當性能的能力；

易維護性：軟件產品可被修改的能力，修改可能包括修正、改進或者適應環(huán)境、需求和功能規(guī)約的變化；

易移植性：軟件產品從一種環(huán)境遷移到另一種環(huán)境的能力；

有效性：軟件產品在指定使用環(huán)境下，使用戶準確、完整地獲得規(guī)定目標的能力；

生產率：軟件產品在指定使用環(huán)境下，使用戶花費合適的與有效性相關的資源數量的能力；

安全性：軟件產品在指定使用環(huán)境下，獲得可接受的損害人類、商務、軟件、財產或環(huán)境風險級別的能力；

滿意度：軟件產品在指定使用環(huán)境下，使用戶滿意的能力。

軟件質量度量  能被用來確定軟件系統(tǒng)或軟件產品某屬性值的一種測量方法或測量尺度。測量尺度可以根據滿足不同程度的需求細分為多個級別，如劃分為兩級，不能令人滿意的和令人滿意的；如劃分為4級，包括超出需求、達到目標、可接受的最低級別和不可接受的。軟件質量度量有內部度量、外部度量和使用質量的度量3種。內部度量可應用于在設計和編碼期間的非執(zhí)行軟件產品（如設計規(guī)約或源代碼），能提供給用戶、評價者、測試員和開發(fā)者評價軟件質量，并盡早地發(fā)布質量問題。外部度量是通過測試、操作和觀察可執(zhí)行軟件，能提供給用戶、評價者、測試員和開發(fā)者評價軟件質量。使用質量的度量是在指定使用環(huán)境下，測量有效性、生產率、安全性和滿意度達到所規(guī)定的目標的程度。

最初由Rubey和Hartwick于1968年提出了一些屬性的測量方法，但未建立質量度量體系。Boehm等人于1976年提出了定量地評價軟件質量的概念，并提出了60個質量度量公式，并首次提出了軟件質量度量的層次模型。1978年Walters和McCall提出了從軟件質量要素、準則到度量的3層次軟件質量模型，將質量要素降到11個。上海計算機軟件中心于1988年提出了軟件質量評價體系，由6個質量特性和22個評價準則，以及眾多的度量和度量元構成了一個4層次樹狀模型，并提出了評價準則與質量特性的關系和應用策略。國際標準化組織于1991年制定了ISO/IEC 9126-1991標準，給出了6個特性和21個子特性，又于1994年開始對ISO/IEC 9126修訂，直到2001年才完成修訂工作，現已被兩個系列標準 “ISO/IEC 14598 軟件工程  產品評價”和“ISO/IEC 9126 軟件工程  產品質量”所    取代。

軟件質量評價過程  由于評價的出發(fā)點不同，可分為3種評價過程：其一，開發(fā)者用的過程，計劃開發(fā)新產品或增強現有產品時為了預測最終產品質量指標；其二，需求方用的過程，計劃獲取或復用某個已有產品時，為了決定接受產品或者從眾多可選產品選擇某個產品；其三，評價者用的過程，應開發(fā)者、需方或其他機構的請求，對產品進行獨立評估，它們通常是第三方機構。不論哪一種評價過程，都是首先要確立評價需求，然后是規(guī)定評價、設計評價和執(zhí)行評價等活動。確立評價需求應確立評價目的，確定產品類型（中間制品、最終產品），規(guī)定質量模型；規(guī)定評價包括選擇度量、建立度量評定等級、確立評估準則；設計評價包括制定評價計劃；執(zhí)行評價包括進行度量、與評估準則相比較，評價結果。

早在20世紀60年代末，已經有人討論大型軟件開發(fā)項目的組織管理問題。隨著軟件工程在實踐過程中發(fā)生的問題，人們認識到軟件產品和軟件項目的開發(fā)，不完全取決于軟件開發(fā)方法。與程序的復雜性和系統(tǒng)的復雜性相比，前者已得到較大的緩解，更重要的是后者。如進度推遲、經費超支、質量差、軟件人員不稱職，均與管理有關。自20世紀80年代初，軟件界就關注“軟件過程”。1984年10月在美國召開的第一屆國際軟件過程討論會，正式提出了“軟件過程”的概念。1991年9月美國電氣和電子工程師學會（IEEE）的標準化委員會制定了“軟件生存周期過程開展”標準。1994年國際標準化組織和國際電工委員會（ISO/IEC）制定了“軟件生存周期過程”標準草案，1995年正式公布了“ISO/IEC 12207-1995 信息技術 軟件生存周期過程”國際標準。同時，在國際標準化組織中質量管理和質量保證技術委員會（ISO/TC176）制定了ISO 9000簇標準，共有27個標準。其中有一個“ISO 9000-3 質量管理和質量保證——第3部分”，主要針對軟件開發(fā)、供應、安裝和維護中的使用指南，其1997版替代了1993版，內容已大多數和ISO/IEC 12207-1995相吻合，讀者可以參考清華大學出版社于1999年出版的《軟件企業(yè)ISO 9000質量體系的建立和認證》一書。

20世紀80年代中期，IBM在Watts S.Humphrey的指導下，Ron Radice等人將成熟度框架首次應用于軟件過程，并由Humphrey于1986年將此成熟度框架帶到卡內基·梅隆大學的軟件工程研究所（CMU/SEI）。

應美國聯邦政府要求，為其提供一個評價軟件開發(fā)商能力的方法，1986年11月，CMU/SEI在MITRE公司的幫助下開始設計過程成熟度框架，以此幫助軟件機構改進他們的軟件過程。1987年9月，CMU/SEI發(fā)表了一個簡短的軟件過程成熟度框架。其后在Humphrey的《管理軟件過程》一書中進行擴充。書中提出了軟件過程評估和軟件能力評估，和成熟度問卷，用于評估軟件過程成熟度?；谶@些設想，由Jim Withey，Mark Paulk和Cynthia Wise在1990年推出了最早的草案。1991年8月Mary Beth Chrissis和Bill Curtis幫助Mark Paulk校訂，推出了CMM（成熟度模型）1.1版。

CMU/SEI原先計劃在1997年下半年推出2.0版，1998年推出2.1版。但由于種種原因，未能按計劃推出2.0版。

由于美國聯邦政府的大力推行，CMM模型得到了廣泛應用，CMU/SEI于2001年公布了通過CMM評估的軟件機構共有964家，并對其作了統(tǒng)計分析。目前CMM本身還在向縱深發(fā)展，CMM家族有：

軟件能力成熟度模型（SW-CMM）

軟件獲取能力成熟度模型（SA-CMM）

人員能力成熟度模型（People-CMM）

系統(tǒng)工程能力成熟度模型（SE-CMM）

集成產品開發(fā)能力成熟度模型（IPD-CMM）

個體軟件過程（PSP）

群組軟件過程（TSP）

另外，國際標準化組織為組織軟件過程評價標準的制訂，成立了“軟件過程改進和能力確定（Software Process Improvement and Capability Determine，SPICD）”項目，ISO/IEC JTCI的SC 7分技術委員會于1996年9月正式公布了工作草案，代號為15504，即ISO/IEC TR 15504 Information Technology—Software Process Assessment。

CMM的廣泛采納和成功推廣，推動了軟件及其他學科的類似模型的開發(fā)，從而模型繁衍，導致了過程改善目標和技術的沖突。要求的培訓工作有了相當大的增長，部分實踐人員在應用各種不同的模型來實現特定的需要時產生了混淆。針對這種情況，美國聯邦政府、產業(yè)界和CMU/SEI于1998年啟動了“能力成熟度模型集成（Capability Maturity Model Integration，CMMI）”項目，于2000年第四季度發(fā)布了第一個正式的CMMI，最近的修改是2002年6月10日。CMMI包括了大量的工程改善和過程改善的信息，提供了單一的集成化框架來改善跨越幾個學科的機構的工程過程，從而提高機構過程改善的質量和有效性。相信CMMI將會逐步替代CMM。

另外我國也非常重視CMM的研究和應用，目前已經參照CMM1.1版制定國家軍標“軍用軟件成熟度模型”，以及參照CMMI制定行業(yè)標準“ST/T11234 軟件過程能力評估模型” 和“ST/T 11235軟件能力成熟度模型”。

1.4  軟 件 測 試

1.4.1  軟件測試的重要性

計算機和程序是一對孿生兄弟，自從計算機誕生之日就必須要有程序在其上運行。為了使所編制的程序能在計算機上運行，從而得到問題的正確解，必須對程序的功能性進行測試。所以，軟件測試工作是在軟件工程誕生之前就客觀存在了，一直延用至今，且其測試的內容和技術也有了較大的發(fā)展。

無論是ISO 9000的質量體系認證，還是CMU/SEI的CMM認證，其中均涉及到測試，如ISO 9000中共有19個要素，其中一個要素就是“檢驗和試驗”，對于軟件來說就是測試；再如CMU/SEI的CMM中共有18個過程關鍵域，其中有一個質量保證過程關鍵域，就是對過程的監(jiān)視和測量。

因此，無論從何種角度講，軟件測試是一個必不可少的活動，是對軟件需求分析、設計規(guī)約和編碼的最終復審；是軟件質量保證的關鍵步驟。軟件測試是根據軟件開發(fā)各階段的規(guī)約和軟件的內部結構，精心設計一批測試用例（包括輸入數據及其預期的輸出結果），并利用這些測試用例去運行程序，以發(fā)現軟件中不符合質量特性要求（即缺陷或錯誤）的過程。目前，許多軟件開發(fā)機構將研制力量的40%以上投入到軟件測試之中，體現了充分重視軟件質量要求。眾所周知，軟件中存在的缺陷甚至是錯誤，如果遺留到軟件交付投入運行之時，終將會暴露出來。但到那時，不僅改正這些缺陷所花的代價更高，而且往往造成惡劣的后果。由此可知軟件測試的重要性。

軟件測試不等同于程序測試。軟件測試應當貫穿軟件生存周期全過程。因此，需求描述、需求規(guī)約、設計規(guī)約、模塊設計書以及程序等都應成為軟件測試的對象。換句話說，軟件測試包括程序測試和各類文檔的評審，這就是對軟件測試的廣義理解。相對的狹義理解就是程序測試，但也不等于程序編好了才進行測試。

在進行軟件產品或軟件系統(tǒng)開發(fā)時，主要有3類人員必須參與，他們是項目經理、開發(fā)人員和測試人員。一般來說，大家都會十分重視開發(fā)工作，因此在一個項目組中，會有很多的開發(fā)人員，而測試人員都比較少。經過多次實踐后，才會增加測試人員，如微軟公司就是這種情況。目前軟件測試人員就比較多了，如Exchange 2000，項目經理23人，開發(fā)人員140人，測試人員350人；再如Windows 2000，項目經理250人，開發(fā)人員1700人，測試人員3200人，可以看出測試人員和開發(fā)人員之比，竟達5∶3。對于我國當前的軟件企業(yè)來說，軟件測試的力度遠遠不夠，隨著市場的成熟和企業(yè)的發(fā)展，必將會極大地投入到測試工作中去，那時測試人員將會十分走俏。

1.4.2  軟件測試的目的和原則

基于不同的立場，存在著不同的測試目的。從用戶的角度看，一般希望通過軟件測試暴露軟件中隱藏的缺陷，以此來決定是否可以接受該軟件產品和軟件系統(tǒng)。從軟件開發(fā)者的角度看，總是希望通過測試說明軟件中不存在缺陷，表明該軟件已正確地實現了用戶的要求，從而確立用戶對該軟件的質量信任。由軟件管理者角度看，普遍希望花費有限的資源達到該軟件用戶的質量要求，經費和進度是其首要考慮的焦點。因此，Grenford.J.Myers就軟件測試目的提出如下的觀點：

q        測試是程序的執(zhí)行過程，目的在于發(fā)現缺陷；

q        一個好的測試用例在于能發(fā)現至今未發(fā)現的缺陷；

q        一個成功的測試是發(fā)現了至今未發(fā)現的多個缺陷的測試。

所以，測試的目標是以最少的資源和時間，找出軟件中隱藏的各種缺陷甚至錯誤。測試的成功與否就是以發(fā)現軟件中潛在的缺陷多少來衡量。

根據這些測試目的和目標，軟件測試應該注意些什么呢？鄭人杰等人編著的《實用軟件工程》^［5］第2版（清華大學出版社，1999年）中有一段描述對此問題進行了回答，現摘錄如下：

① 應當把“盡早地和不斷地進行軟件測試”作為軟件開發(fā)者的座右銘。

由于原始問題的復雜性，軟件的復雜性和抽象性，軟件開發(fā)各個階段工作的多樣性，以及參加開發(fā)各種層次人員之間工作的配合關系等因素，使得開發(fā)的每個環(huán)節(jié)都可能產生錯誤。所以不應把軟件測試僅僅看作是軟件開發(fā)的一個獨立階段，而應當把它貫穿到軟件開發(fā)的各個階段中。堅持在軟件開發(fā)的各個階段的技術評審，這樣才能在開發(fā)過程中盡早發(fā)現和預防錯誤，把出現的錯誤克服在早期，杜絕某些隱患，提高軟件質量。

② 測試用例應由測試輸入數據和與之對應的預期輸出結果這兩部分組成。

在做測試以前，應當根據測試的要求選擇在測試過程中使用的測試用例。測試用例主要用來檢驗程序員編制的程序，因此不但需要測試的輸入數據，而且需要針對這些輸入數據的預期輸出結果。如果對測試輸入數據沒有給出預期的程序輸出結果，那么就缺少了檢驗實測結果的基準，就有可能把一個似是而非的錯誤結果當成正確結果。

③ 程序員應避免檢查自己的程序。

測試工作需要嚴格的作風，客觀的態(tài)度和冷靜的情緒。人們常常由于各種原因，具有一種不愿否定自己工作的心理，認為揭露自己程序中的問題總不是一件愉快的事，這一心理狀態(tài)就成為測試自己程序的障礙。另外，程序員對規(guī)約理解錯誤而引入的錯誤更難發(fā)現。如果由別人來測試程序員編寫的程序，可能會更客觀，更有效，并更容易取得成功。要注意的是，這點不能與程序的排錯（debugging，亦譯成調試）相混淆。排錯由程序員自己來做可能更有效。

④ 在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。

合理的輸入條件是指能驗證程序正確的輸入條件，而不合理的輸入條件是指異常的、臨界的及可能引起問題異變的輸入條件。在測試程序時，人們常常傾向于過多地考慮合法的和期望的輸入條件，以檢查程序是否做了它應該做的事情，而忽視了不合法的和預想不到的輸入條件。事實上，軟件在投入運行以后，用戶的使用往往不遵循事先的約定，使用了一些意外的輸入，如用戶在鍵盤上按錯了鍵或輸入了非法的命令。如果開發(fā)的軟件遇到這種情況時不能做出適當的反應，給出相應的信息，那么就容易產生故障，輕則給出錯誤的結果，重則導致軟件失效。因此，軟件系統(tǒng)處理非法命令的能力也必須在測試時受到檢驗。用不合理的輸入條件測試程序時，往往比用合理的輸入條件進行測試能發(fā)現更多的錯誤。

⑤ 充分注意測試中的群集現象。

測試時不要以為找到了幾個錯誤問題就已解決，不需繼續(xù)測試了。經驗表明，測試后程序中殘存的錯誤數目與該程序中已發(fā)現的錯誤數目或檢錯率成正比。根據這個規(guī)律，應當對錯誤群集的程序段進行重點測試，以提高測試投資的效益。

在所測程序段中，若發(fā)現錯誤數目多，則殘存錯誤數目也比較多。這種錯誤群集性現象，已為許多程序的測試實踐所證實。例如美國IBM公司的OS/370操作系統(tǒng)，47%的錯誤僅與該系統(tǒng)的4%的程序模塊有關。這種現象對測試很有用。如果發(fā)現某一程序模塊似乎比其他程序模塊有更多的錯誤傾向時，則應當花費較多的時間和代價測試這個程序模塊。

⑥ 嚴格執(zhí)行測試計劃，排除測試的隨意性。

測試計劃應包括：所測試軟件的功能，輸入和輸出，測試內容，各項測試的進度安排，資源要求，測試資料，測試工具，測試用例的選擇，測試的控制方式和過程，系統(tǒng)組裝方式，跟蹤規(guī)程，排錯規(guī)程，回歸測試的規(guī)定以及評價標準等（下面還會作介紹）。

對于測試計劃，要明確規(guī)定，不要隨意解釋。

⑦ 應當對每一個測試結果做全面檢查。

這是一條最明顯的原則，但常常被忽視。有些錯誤的征兆在輸出實測結果時已經明顯地出現了，但是如果不仔細全面地檢查測試結果，就會使這些缺陷或錯誤被遺漏掉。所以必須對預期的輸出結果明確定義，對實測的結果仔細分析檢查，抓住癥候，暴露錯誤。

⑧ 妥善保存測試計劃，測試用例，出錯統(tǒng)計和最終分析報告，為維護提供方便。

1.4.3  軟件測試過程

軟件測試過程可以在兩個不同的層次上分析，在低層次上，軟件測試過程是一個不斷地運行一個程序段，不斷地輸入數據，觀察和記錄程序的運行行為和輸出的結果，并判斷其行為和輸出結果的正確性，直到能夠由這些結果有效地分析該程序段的特性的過程。

為了高效地執(zhí)行這一過程，往往需要書寫一段程序來調用被測試的程序段，向被測試程序段輸送測試數據，打印、顯示或記錄該程序段運行的行為。這樣一段程序被稱之為該測試的驅動程序。同樣亦往往需要編寫另一段程序來為被測試的程序段提供數據（在正式交付用戶運行時，這些數據可能是由其他程序段被調用后運行的結果，也可能是由其他程序段直接提供）。這樣一段程序稱之為該測試的樁基模塊（stub）。對程序動態(tài)運行行為的觀察和記錄，只限于該程序段測試的輸出結果是不夠的，有時需要對程序段的執(zhí)行路徑以及在路徑上的一些關鍵點的中間結果進行記錄和分析。為了有效地記錄該測試的動態(tài)行為，需要在該程序段中插入一些程序代碼，這樣的代碼稱為軟件測試監(jiān)視代碼。

軟件測試過程還可以在一個更高的層次上來進行分析。軟件測試過程可以看成不斷地進行測試、排錯、修改程序和文檔，然后再進行測試（回歸測試），直到軟件達到用戶質量特性要求的一個循環(huán)往復的過程。

一個成功的測試包括兩個主要方面：其一是被測試的程序段在足夠多的測試數據上是正確的。注意，并不是指被測試的程序段是正確的，它可能發(fā)現存在隱含的缺陷，也可能在某些測試數據上未發(fā)現缺陷，只說明在這種情況下，被測試的程序段是正確的。其二是測試數據是充分的，即該程序段在測試數據上的動態(tài)行為能夠充分反映質量特性的總體  表現。

1.4.4  軟件測試與相關的幾個概念

軟件測試不僅僅是軟件質量保證體系中的重要一環(huán)，而且也是保證質量的重要技術手段，在前面已討論了它們之間的關系。除此之外，還有幾個概念需要進一步說明。

（1）排錯（debugging）是查找、分析和糾正錯誤的過程。而測試（testing）是由人工或自動方法來執(zhí)行或評價軟件系統(tǒng)或軟件子系統(tǒng)的過程，以驗證是否滿足規(guī)定的需求，或識別出期望的結果和實際結果之間有無差別。因此，測試的任務是盡可能多地發(fā)現軟件中的缺陷和錯誤，而排錯的任務是進一步診斷和改正程序中潛在的缺陷和錯誤。一般來說，排錯有兩類活動：其一是確定程序中可疑缺陷或錯誤的確切性質和位置；其二，是對程序（設計、編碼）進行修改，從而排除這個潛在的缺陷或錯誤。

（2）驗證（verification）有3個含義：

其一，確定軟件生存周期中的一個給定階段的產品是否達到前階段確立的需求的過程；

其二，程序正確性的形式證明，即采用形式理論證明程序符合設計規(guī)約規(guī)定的過程；

其三，評審、審查、測試、檢查、審計等各類活動，或對某些項處理、服務或文件等是否和規(guī)定的需求相一致進行判斷和提出報告。

（3）確認（validation）是在軟件開發(fā)過程結束時，對軟件進行評價，以確認它和軟件需求是否相一致的過程，其目的是想證實在一個給定的外部環(huán)境中軟件的正確性。確認一般包括需求規(guī)約的確認和程序的確認，而程序的確認又分靜態(tài)確認和動態(tài)確認。靜態(tài)確認不在計算機上實際執(zhí)行程序，通過人工分析或者程序正確性證明來證實程序的正確性。動態(tài)確認主要通過動態(tài)執(zhí)行程序作分析，或者測試程序來檢查其動態(tài)行為，以證實程序是否存在問題，這通常就叫確認測試。

由此，可以把驗證與確認看成是軟件測試的一部分工作。

1.5  軟件測試方法分類

軟件測試無論技術還是應用都處在發(fā)展中，所以軟件測試的內容、工具，甚至關于軟件測試的名詞術語也都在不斷擴大中。而這些軟件測試的內容、工具和名詞術語，都代表著軟件測試的某個方面，有其特定的含義。為了比較正確地理解其含義和比較正確地將其定位，應該從宏觀角度對軟件測試加以分類。

軟件測試有各種分類方法，按照不同的分類原則有不同的分類結果。軟件測試的分類原則可以有以下幾種：

q        按照軟件測試的動、靜態(tài)分類；

q        按照軟件層面分類；

q        按照軟件開發(fā)過程的內、外分類；

q        按照測試用例所依據的信息來源分類；

q        按照判斷測試的充分性分類；

q        按照軟件測試的完整性分類。

（1）按照軟件測試的動、靜態(tài)來分，有靜態(tài)測試和動態(tài)測試。

在軟件開發(fā)過程中，每產生一個文檔，或每一個活動結束時產生的文檔，都必須對文檔進行測試，靜態(tài)測試通過了，則該過程或活動才算結束，開發(fā)工作取得了進展，可以進入下一個階段或活動，對這種靜態(tài)測試亦叫做評審。

動態(tài)測試就是通過運行程序來檢驗程序的動態(tài)行為和運行結果的正確性。運行程序并非動態(tài)測試的目的，通過運行來檢驗程序是否正確才是動態(tài)測試的目的。動態(tài)測試必須具備測試用例，有時還需要具備驅動程序、樁模塊和測試監(jiān)視代碼。

（2）按照軟件層面來分，美國國家宇航局建議將軟件評審的內容分兩個層面來進行，即技術評審和管理評審。

① 技術評審的任務

q        建立軟件配置管理基線；

q        提出并解決技術問題，審查技術工作；

q        評價項目的狀態(tài)，判明有關技術問題的近期、長期風險，并加以討論；

q        在技術代表的權限內，達成已判明風險的轉移策略；

q        標識呈交給管理人員討論的風險要素和有關問題；

q        確保用戶和軟件開發(fā)技術人員之間的交流通暢。

② 管理評審的任務

q        報告上級管理部門該項目的狀態(tài)、所采取的方針、所達成的技術協(xié)議，以及軟件產品進展的總體情況；

q        解決技術評審不能解決的問題；

q        就技術評審不能解決的近期、長期風險可達成的轉移戰(zhàn)略；

q        鑒別并解決管理方面的問題以及技術評審沒有提出的風險；

q        征得用戶的同意和各方認可以便及時完成。

（3）按照軟件開發(fā)過程的內、外進行分類。

① 軟件開發(fā)過程中的測試。按軟件開發(fā)過程中所處的階段（或活動）及其作用來    分，有

q        單元測試

q        集成測試

q        系統(tǒng)測試

q        驗收測試

軟件開發(fā)過程中的測試，大部分是開發(fā)單位自行完成的。當然，也可交第三方軟件測試機構執(zhí)行，但往往是系統(tǒng)測試和驗收測試。有時，這種測試，因為不是由用戶進行的，又稱α測試。

出現在軟件開發(fā)過程中各個階段（或活動）的還有“回歸測試”。只要對軟件的代碼有修改，不論是修改錯誤還是增加功能或提高性能，原則上都要進行回歸測試，以保證對代碼修改的正確性，并不會對其他部分帶來負面影響。

② 軟件產品測試。其測試對象是產品化或正在產品化的軟件。這種測試的內容包含范圍很廣，通常由第三方軟件測試機構執(zhí)行。

A．通常的軟件產品測試：

q        功能測試

q        性能測試

q        β測試（用戶測試）

q        Benchmark測試

B．專門的軟件產品測試：

q        可靠性測試

q        標準符合性測試

q        互操作性測試

q        安全性測試

q        強度測試

（4）按照測試用例所依據的信息來源，測試方法可以分為如下幾種。

① 以程序為基礎的測試。通過對程序的分析形成測試用例，并以程序被執(zhí)行的程度來判斷測試是否充分，這就是“白盒法”。

② 以需求規(guī)約和需求描述為基礎的測試。通過分析軟件的需求描述和需求規(guī)約形成測試用例，并根據需求描述和需求規(guī)約所規(guī)定的功能和性能是否得到了充分的檢驗來判斷測試是否充分。這就是“黑盒法”。

③ 程序和需求相結合的測試。綜合考慮需求和實現形成測試用例。

④ 以接口為基礎的測試，僅僅依靠軟件與其運行環(huán)境之間的接口形成測試用例，隨機測試就是一種以接口為基礎的測試方法。

（5）按照判斷測試的充分性，測試方法可以分為如下幾種。

① 結構性測試，旨在充分覆蓋程序結構，并以程序中的某類成分是否都已得到測試為依據，來判斷測試的充分性，如語句覆蓋是一種結構性測試。

② 排錯性測試，旨在排除程序中潛在缺陷的可能性，并根據測試用例集成排除軟件潛在缺陷可能性的能力判斷測試的充分性。

③ 分域測試，通過對軟件的需求和實現進行分析，將軟件的輸入空間劃分成一系列子空間，然后在每一個子空間內選擇一個或多個測試數據。

④ 功能測試，根據軟件所需的功能和所實現的功能，形成測試用例，分析測試的充   分性。

（6）按照軟件測試的完整性，Shooman 從程序結構和測試覆蓋程度分為如下幾種。

① 完全性和連續(xù)性測試

要求程序中的所有指令至少執(zhí)行一次（100%的語句覆蓋）

② 圖路徑測試

所有圖路徑至少執(zhí)行一次（100%的圖路徑覆蓋）

③ 程序路徑測試

所有程序路徑至少執(zhí)行一次（100%的程序路徑覆蓋）

④ 窮舉測試

對輸入參數的所有值執(zhí)行所有程序路徑，或對輸入參數的所有值和所有輸入序列，以及初始條件的所有組合，執(zhí)行所有程序路徑。

以上這6種軟件測試的分類方法，從不同的技術角度對軟件測試進行分類。實際上，它們之間有很多交互和相關之處。例如，同一測試技術可以融在不同類的相關測試階段之中。在本書中，主要依據軟件開發(fā)過程的內、外分類方法安排章節(jié)目錄。

1.6  軟件錯誤的分級

在軟件產品開發(fā)中，不論哪一階段產生的缺陷和錯誤，其最后的表現就是：軟件產品達不到用戶的要求，由于存在軟件錯誤，使之不能有效地完成規(guī)定的任務。

軟件測試的任務，就在于找出或發(fā)現軟件中存在的錯誤（假如錯誤存在的話）。由于錯誤的性質不同，危害性也不同。軟件測試如果能發(fā)現軟件中危害性大的錯誤（如果存在的話），那么該軟件測試的價值就越高。一般將軟件錯誤分為5級。

q        第1級錯誤

不能完全滿足軟件需求，基本功能未完全實現，危及人員或設備安全的錯誤。

q        第2級錯誤

不利于完全滿足軟件需求或基本功能的實現，并且不存在可以變通的解決辦法（重新裝入或重新啟動該軟件不屬于變通解決辦法）。

q        第3級錯誤

不利于完全滿足軟件需求或基本功能的實現，但卻存在合理的、可以變通的解決辦法（重新裝入或重新啟動該軟件不屬于變通解決辦法）。

q        第4級錯誤

不影響完全滿足軟件需求或基本功能的實現，但有不便于操作員操作的錯誤。

q        第5級錯誤

不屬于第1~4級錯誤的其他錯誤。