第1章  軟件測(cè)試引論

1.1  質(zhì)量和質(zhì)量認(rèn)識(shí)論

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

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

狹義的質(zhì)量概念就是產(chǎn)品質(zhì)量。所謂產(chǎn)品質(zhì)量好，往往被人們認(rèn)為生產(chǎn)出最佳產(chǎn)品，即在盡可能充分利用現(xiàn)代生產(chǎn)技術(shù)水平的條件下，制造出最好的產(chǎn)品。而且，所謂“好”，常常僅從產(chǎn)品性能著眼。這種概念不能反映質(zhì)量的全部?jī)?nèi)容。

廣義的質(zhì)量概念包括產(chǎn)品質(zhì)量和工作質(zhì)量?jī)蓚€(gè)組成部分，即全面質(zhì)量。它既要反映客觀的要求，又要考慮到設(shè)計(jì)、制造、銷售服務(wù)的水平和能力。

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

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

任何一個(gè)機(jī)構(gòu)，都必須確定質(zhì)量目標(biāo)，質(zhì)量目標(biāo)就是產(chǎn)品和工程質(zhì)量在一定時(shí)間內(nèi)可達(dá)到的水平，產(chǎn)品和工程質(zhì)量目標(biāo)的制訂需做3個(gè)方面的調(diào)查。

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

（2）生產(chǎn)過程中老產(chǎn)品曾經(jīng)出現(xiàn)過的問題及新產(chǎn)品開發(fā)中可能發(fā)生的問題。

（3）國(guó)內(nèi)外有關(guān)的技術(shù)與經(jīng)濟(jì)情況。

制定質(zhì)量目標(biāo)還需考慮成本的增加。任何一個(gè)產(chǎn)品或者工程項(xiàng)目，其價(jià)格是由銷售成本所決定的，銷售成本包括生產(chǎn)成本、質(zhì)量成本和利潤(rùn)。就質(zhì)量成本而言，包括損失成本、檢驗(yàn)成本和預(yù)防成本。損失成本是因產(chǎn)品未能達(dá)到質(zhì)量要求而造成的各項(xiàng)損失費(fèi)用，一般包括內(nèi)部損失（如報(bào)廢、返修、降級(jí)等）和外部損失（如拒收、索賠、聲譽(yù)破壞等）；檢驗(yàn)成本是用于檢驗(yàn)產(chǎn)品質(zhì)量所需的各項(xiàng)費(fèi)用；預(yù)防成本是用于預(yù)防產(chǎn)生不良產(chǎn)品所需的各項(xiàng)費(fèi)用，如員工培訓(xùn)、質(zhì)量管理開銷、檢測(cè)設(shè)備購置等。

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

1.2  軟件產(chǎn)品和其他產(chǎn)品的差異

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

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

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

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

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

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

1.3  軟 件 質(zhì) 量

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

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

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

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

軟件質(zhì)量模型  一個(gè)框架，它規(guī)定了內(nèi)部和外部質(zhì)量的質(zhì)量模型與使用質(zhì)量的質(zhì)量模型，以及它們?cè)谲浖嬷芷谥械年P(guān)系。內(nèi)部和外部質(zhì)量的質(zhì)量模型將軟件質(zhì)量屬性分類為6個(gè)特性，即功能性、可靠性、易用性、效率、易維護(hù)性和易移植性，并進(jìn)一步細(xì)分為27個(gè)子特性，從而構(gòu)成一個(gè)有層次的樹狀結(jié)構(gòu)，結(jié)構(gòu)的最高層由質(zhì)量特性組成，最低層則由軟件質(zhì)量屬性組成。使用質(zhì)量的質(zhì)量模型將軟件質(zhì)量屬性分類為4個(gè)特性，即有效性、生產(chǎn)率、安全性和滿意度。獲得軟件的使用質(zhì)量依賴于所取得的外部質(zhì)量，而取得的外部質(zhì)量依賴于獲得必要的內(nèi)部質(zhì)量，所取得的內(nèi)部質(zhì)量又依賴于生存周期中所規(guī)定的過程的質(zhì)量。同樣，為了獲得所需的使用質(zhì)量，就有助于確定外部質(zhì)量需求，從而有助于確定內(nèi)部質(zhì)量需求，進(jìn)而有助于確定過程的質(zhì)量。

軟件質(zhì)量特性

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

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

易用性：在指定條件下使用時(shí)，軟件產(chǎn)品被理解、學(xué)習(xí)、使用及其吸引用戶的能力；

效率：在規(guī)定條件下，相對(duì)于所用資源的數(shù)量，軟件產(chǎn)品可提供適當(dāng)性能的能力；

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

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

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

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

安全性：軟件產(chǎn)品在指定使用環(huán)境下，獲得可接受的損害人類、商務(wù)、軟件、財(cái)產(chǎn)或環(huán)境風(fēng)險(xiǎn)級(jí)別的能力；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

個(gè)體軟件過程（PSP）

群組軟件過程（TSP）

另外，國(guó)際標(biāo)準(zhǔn)化組織為組織軟件過程評(píng)價(jià)標(biāo)準(zhǔn)的制訂，成立了“軟件過程改進(jìn)和能力確定（Software Process Improvement and Capability Determine，SPICD）”項(xiàng)目，ISO/IEC JTCI的SC 7分技術(shù)委員會(huì)于1996年9月正式公布了工作草案，代號(hào)為15504，即ISO/IEC TR 15504 Information Technology—Software Process Assessment。

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

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

1.4  軟 件 測(cè) 試

1.4.1  軟件測(cè)試的重要性

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

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

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

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

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

1.4.2  軟件測(cè)試的目的和原則

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

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

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

q        一個(gè)成功的測(cè)試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的多個(gè)缺陷的測(cè)試。

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

根據(jù)這些測(cè)試目的和目標(biāo)，軟件測(cè)試應(yīng)該注意些什么呢？鄭人杰等人編著的《實(shí)用軟件工程》^［5］第2版（清華大學(xué)出版社，1999年）中有一段描述對(duì)此問題進(jìn)行了回答，現(xiàn)摘錄如下：

① 應(yīng)當(dāng)把“盡早地和不斷地進(jìn)行軟件測(cè)試”作為軟件開發(fā)者的座右銘。

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

② 測(cè)試用例應(yīng)由測(cè)試輸入數(shù)據(jù)和與之對(duì)應(yīng)的預(yù)期輸出結(jié)果這兩部分組成。

在做測(cè)試以前，應(yīng)當(dāng)根據(jù)測(cè)試的要求選擇在測(cè)試過程中使用的測(cè)試用例。測(cè)試用例主要用來檢驗(yàn)程序員編制的程序，因此不但需要測(cè)試的輸入數(shù)據(jù)，而且需要針對(duì)這些輸入數(shù)據(jù)的預(yù)期輸出結(jié)果。如果對(duì)測(cè)試輸入數(shù)據(jù)沒有給出預(yù)期的程序輸出結(jié)果，那么就缺少了檢驗(yàn)實(shí)測(cè)結(jié)果的基準(zhǔn)，就有可能把一個(gè)似是而非的錯(cuò)誤結(jié)果當(dāng)成正確結(jié)果。

③ 程序員應(yīng)避免檢查自己的程序。

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

④ 在設(shè)計(jì)測(cè)試用例時(shí)，應(yīng)當(dāng)包括合理的輸入條件和不合理的輸入條件。

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

⑤ 充分注意測(cè)試中的群集現(xiàn)象。

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

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

⑥ 嚴(yán)格執(zhí)行測(cè)試計(jì)劃，排除測(cè)試的隨意性。

測(cè)試計(jì)劃應(yīng)包括：所測(cè)試軟件的功能，輸入和輸出，測(cè)試內(nèi)容，各項(xiàng)測(cè)試的進(jìn)度安排，資源要求，測(cè)試資料，測(cè)試工具，測(cè)試用例的選擇，測(cè)試的控制方式和過程，系統(tǒng)組裝方式，跟蹤規(guī)程，排錯(cuò)規(guī)程，回歸測(cè)試的規(guī)定以及評(píng)價(jià)標(biāo)準(zhǔn)等（下面還會(huì)作介紹）。

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

⑦ 應(yīng)當(dāng)對(duì)每一個(gè)測(cè)試結(jié)果做全面檢查。

這是一條最明顯的原則，但常常被忽視。有些錯(cuò)誤的征兆在輸出實(shí)測(cè)結(jié)果時(shí)已經(jīng)明顯地出現(xiàn)了，但是如果不仔細(xì)全面地檢查測(cè)試結(jié)果，就會(huì)使這些缺陷或錯(cuò)誤被遺漏掉。所以必須對(duì)預(yù)期的輸出結(jié)果明確定義，對(duì)實(shí)測(cè)的結(jié)果仔細(xì)分析檢查，抓住癥候，暴露錯(cuò)誤。

⑧ 妥善保存測(cè)試計(jì)劃，測(cè)試用例，出錯(cuò)統(tǒng)計(jì)和最終分析報(bào)告，為維護(hù)提供方便。

1.4.3  軟件測(cè)試過程

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

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

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

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

1.4.4  軟件測(cè)試與相關(guān)的幾個(gè)概念

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

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

（2）驗(yàn)證（verification）有3個(gè)含義：

其一，確定軟件生存周期中的一個(gè)給定階段的產(chǎn)品是否達(dá)到前階段確立的需求的過程；

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

其三，評(píng)審、審查、測(cè)試、檢查、審計(jì)等各類活動(dòng)，或?qū)δ承╉?xiàng)處理、服務(wù)或文件等是否和規(guī)定的需求相一致進(jìn)行判斷和提出報(bào)告。

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

由此，可以把驗(yàn)證與確認(rèn)看成是軟件測(cè)試的一部分工作。

1.5  軟件測(cè)試方法分類

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

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

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

q        按照軟件層面分類；

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

q        按照測(cè)試用例所依據(jù)的信息來源分類；

q        按照判斷測(cè)試的充分性分類；

q        按照軟件測(cè)試的完整性分類。

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

在軟件開發(fā)過程中，每產(chǎn)生一個(gè)文檔，或每一個(gè)活動(dòng)結(jié)束時(shí)產(chǎn)生的文檔，都必須對(duì)文檔進(jìn)行測(cè)試，靜態(tài)測(cè)試通過了，則該過程或活動(dòng)才算結(jié)束，開發(fā)工作取得了進(jìn)展，可以進(jìn)入下一個(gè)階段或活動(dòng)，對(duì)這種靜態(tài)測(cè)試亦叫做評(píng)審。

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

（2）按照軟件層面來分，美國(guó)國(guó)家宇航局建議將軟件評(píng)審的內(nèi)容分兩個(gè)層面來進(jìn)行，即技術(shù)評(píng)審和管理評(píng)審。

① 技術(shù)評(píng)審的任務(wù)

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

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

q        評(píng)價(jià)項(xiàng)目的狀態(tài)，判明有關(guān)技術(shù)問題的近期、長(zhǎng)期風(fēng)險(xiǎn)，并加以討論；

q        在技術(shù)代表的權(quán)限內(nèi)，達(dá)成已判明風(fēng)險(xiǎn)的轉(zhuǎn)移策略；

q        標(biāo)識(shí)呈交給管理人員討論的風(fēng)險(xiǎn)要素和有關(guān)問題；

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

② 管理評(píng)審的任務(wù)

q        報(bào)告上級(jí)管理部門該項(xiàng)目的狀態(tài)、所采取的方針、所達(dá)成的技術(shù)協(xié)議，以及軟件產(chǎn)品進(jìn)展的總體情況；

q        解決技術(shù)評(píng)審不能解決的問題；

q        就技術(shù)評(píng)審不能解決的近期、長(zhǎng)期風(fēng)險(xiǎn)可達(dá)成的轉(zhuǎn)移戰(zhàn)略；

q        鑒別并解決管理方面的問題以及技術(shù)評(píng)審沒有提出的風(fēng)險(xiǎn)；

q        征得用戶的同意和各方認(rèn)可以便及時(shí)完成。

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

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

q        單元測(cè)試

q        集成測(cè)試

q        系統(tǒng)測(cè)試

q        驗(yàn)收測(cè)試

軟件開發(fā)過程中的測(cè)試，大部分是開發(fā)單位自行完成的。當(dāng)然，也可交第三方軟件測(cè)試機(jī)構(gòu)執(zhí)行，但往往是系統(tǒng)測(cè)試和驗(yàn)收測(cè)試。有時(shí)，這種測(cè)試，因?yàn)椴皇怯捎脩暨M(jìn)行的，又稱α測(cè)試。

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

② 軟件產(chǎn)品測(cè)試。其測(cè)試對(duì)象是產(chǎn)品化或正在產(chǎn)品化的軟件。這種測(cè)試的內(nèi)容包含范圍很廣，通常由第三方軟件測(cè)試機(jī)構(gòu)執(zhí)行。

A．通常的軟件產(chǎn)品測(cè)試：

q        功能測(cè)試

q        性能測(cè)試

q        β測(cè)試（用戶測(cè)試）

q        Benchmark測(cè)試

B．專門的軟件產(chǎn)品測(cè)試：

q        可靠性測(cè)試

q        標(biāo)準(zhǔn)符合性測(cè)試

q        互操作性測(cè)試

q        安全性測(cè)試

q        強(qiáng)度測(cè)試

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

① 以程序?yàn)榛A(chǔ)的測(cè)試。通過對(duì)程序的分析形成測(cè)試用例，并以程序被執(zhí)行的程度來判斷測(cè)試是否充分，這就是“白盒法”。

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

③ 程序和需求相結(jié)合的測(cè)試。綜合考慮需求和實(shí)現(xiàn)形成測(cè)試用例。

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

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

① 結(jié)構(gòu)性測(cè)試，旨在充分覆蓋程序結(jié)構(gòu)，并以程序中的某類成分是否都已得到測(cè)試為依據(jù)，來判斷測(cè)試的充分性，如語句覆蓋是一種結(jié)構(gòu)性測(cè)試。

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

③ 分域測(cè)試，通過對(duì)軟件的需求和實(shí)現(xiàn)進(jìn)行分析，將軟件的輸入空間劃分成一系列子空間，然后在每一個(gè)子空間內(nèi)選擇一個(gè)或多個(gè)測(cè)試數(shù)據(jù)。

④ 功能測(cè)試，根據(jù)軟件所需的功能和所實(shí)現(xiàn)的功能，形成測(cè)試用例，分析測(cè)試的充   分性。

（6）按照軟件測(cè)試的完整性，Shooman 從程序結(jié)構(gòu)和測(cè)試覆蓋程度分為如下幾種。

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

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

② 圖路徑測(cè)試

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

③ 程序路徑測(cè)試

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

④ 窮舉測(cè)試

對(duì)輸入?yún)?shù)的所有值執(zhí)行所有程序路徑，或?qū)斎雲(yún)?shù)的所有值和所有輸入序列，以及初始條件的所有組合，執(zhí)行所有程序路徑。

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

1.6  軟件錯(cuò)誤的分級(jí)

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

軟件測(cè)試的任務(wù)，就在于找出或發(fā)現(xiàn)軟件中存在的錯(cuò)誤（假如錯(cuò)誤存在的話）。由于錯(cuò)誤的性質(zhì)不同，危害性也不同。軟件測(cè)試如果能發(fā)現(xiàn)軟件中危害性大的錯(cuò)誤（如果存在的話），那么該軟件測(cè)試的價(jià)值就越高。一般將軟件錯(cuò)誤分為5級(jí)。

q        第1級(jí)錯(cuò)誤

不能完全滿足軟件需求，基本功能未完全實(shí)現(xiàn)，危及人員或設(shè)備安全的錯(cuò)誤。

q        第2級(jí)錯(cuò)誤

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

q        第3級(jí)錯(cuò)誤

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

q        第4級(jí)錯(cuò)誤

不影響完全滿足軟件需求或基本功能的實(shí)現(xiàn)，但有不便于操作員操作的錯(cuò)誤。

q        第5級(jí)錯(cuò)誤

不屬于第1~4級(jí)錯(cuò)誤的其他錯(cuò)誤。