超碰人人人人人,亚洲AV午夜福利精品一区二区,亚洲欧美综合区丁香五月1区,日韩欧美亚洲系列

第1章  軟件測試引論

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

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

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

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

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

在這里，需要對產(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ī)軟件；服務(wù)是為滿足客戶的需要，供方和顧客之間在接觸時的活動，以及供方內(nèi)部活動所產(chǎn)生的結(jié)果。因此，產(chǎn)品的提供和使用可構(gòu)成服務(wù)提供的一部分。服務(wù)可以與產(chǎn)品的制造和提供相關(guān)聯(lián)。當(dāng)然，服務(wù)亦需投入資源和活動，也是一種價值的增值。

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

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

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

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

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

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

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

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

1.1節(jié)中所講的產(chǎn)品包括4種類別，其中的軟件還不是單指計算機(jī)軟件，其范圍亦大得多。自從1968年提出軟件工程這一概念以來，就希望能夠借助傳統(tǒng)的工程方法來研發(fā)出軟件產(chǎn)品。因此，軟件產(chǎn)品在某些方面的確相似于其他工程中的有形產(chǎn)品，但畢竟不相同，它們之間存在一些重要的差別。所以，在軟件工程中，人們認(rèn)識到不能夠簡單地把一般工程中的知識、方法和技術(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)品，軟件就不會用壞、磨損、老化，而且可以不斷地改進(jìn)、優(yōu)化，其可靠性由邏輯確定。開發(fā)軟件在許多方面更像進(jìn)行數(shù)學(xué)證明，可是軟件產(chǎn)品的評價卻主要決定于它們在問題求解中是否有用，而不是決定于抽象的正確性判定標(biāo)準(zhǔn)。換句話說，開發(fā)軟件產(chǎn)品時主要使用的是工程標(biāo)準(zhǔn)，而不是數(shù)學(xué)標(biāo)準(zhǔn)。

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

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

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

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

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ù)期要求的程度。簡言之，軟件質(zhì)量是軟件一些特性的組合，它依賴軟件的本身。

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

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

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

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

軟件質(zhì)量特性

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

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

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

效率：在規(guī)定條件下，相對于所用資源的數(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ù)、軟件、財產(chǎn)或環(huán)境風(fēng)險級別的能力；

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

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

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

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

早在20世紀(jì)60年代末，已經(jīng)有人討論大型軟件開發(fā)項目的組織管理問題。隨著軟件工程在實(shí)踐過程中發(fā)生的問題，人們認(rèn)識到軟件產(chǎn)品和軟件項目的開發(fā)，不完全取決于軟件開發(fā)方法。與程序的復(fù)雜性和系統(tǒng)的復(fù)雜性相比，前者已得到較大的緩解，更重要的是后者。如進(jìn)度推遲、經(jīng)費(fèi)超支、質(zhì)量差、軟件人員不稱職，均與管理有關(guān)。自20世紀(jì)80年代初，軟件界就關(guān)注“軟件過程”。1984年10月在美國召開的第一屆國際軟件過程討論會，正式提出了“軟件過程”的概念。1991年9月美國電氣和電子工程師學(xué)會（IEEE）的標(biāo)準(zhǔn)化委員會制定了“軟件生存周期過程開展”標(biāo)準(zhǔn)。1994年國際標(biāo)準(zhǔn)化組織和國際電工委員會（ISO/IEC）制定了“軟件生存周期過程”標(biāo)準(zhǔn)草案，1995年正式公布了“ISO/IEC 12207-1995 信息技術(shù) 軟件生存周期過程”國際標(biāo)準(zhǔn)。同時，在國際標(biāo)準(zhǔn)化組織中質(zhì)量管理和質(zhì)量保證技術(shù)委員會（ISO/TC176）制定了ISO 9000簇標(biāo)準(zhǔn)，共有27個標(biāo)準(zhǔn)。其中有一個“ISO 9000-3 質(zhì)量管理和質(zhì)量保證——第3部分”，主要針對軟件開發(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)美國聯(lián)邦政府要求，為其提供一個評價軟件開發(fā)商能力的方法，1986年11月，CMU/SEI在MITRE公司的幫助下開始設(shè)計過程成熟度框架，以此幫助軟件機(jī)構(gòu)改進(jìn)他們的軟件過程。1987年9月，CMU/SEI發(fā)表了一個簡短的軟件過程成熟度框架。其后在Humphrey的《管理軟件過程》一書中進(jìn)行擴(kuò)充。書中提出了軟件過程評估和軟件能力評估，和成熟度問卷，用于評估軟件過程成熟度?；谶@些設(shè)想，由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版。

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

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

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

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

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

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

個體軟件過程（PSP）

群組軟件過程（TSP）

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

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

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

1.4  軟 件 測 試

1.4.1  軟件測試的重要性

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

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

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

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

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

1.4.2  軟件測試的目的和原則

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.4.3  軟件測試過程

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

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

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

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

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

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

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

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

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

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

其三，評審、審查、測試、檢查、審計等各類活動，或?qū)δ承╉椞幚?、服?wù)或文件等是否和規(guī)定的需求相一致進(jìn)行判斷和提出報告。

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

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

1.5  軟件測試方法分類

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

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

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

q        按照軟件層面分類；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

q        單元測試

q        集成測試

q        系統(tǒng)測試

q        驗收測試

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

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

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

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

q        功能測試

q        性能測試

q        β測試（用戶測試）

q        Benchmark測試

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

q        可靠性測試

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

q        互操作性測試

q        安全性測試

q        強(qiáng)度測試

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

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

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

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

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

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

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

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

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

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

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

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

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

② 圖路徑測試

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

③ 程序路徑測試

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

④ 窮舉測試

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

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

1.6  軟件錯誤的分級

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

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

q        第1級錯誤

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

q        第2級錯誤

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

q        第3級錯誤

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

q        第4級錯誤

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

q        第5級錯誤

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