軟件測試的基礎(chǔ)理論

1、軟件測試基礎(chǔ)理論1: 軟件缺陷含義2: 軟件缺陷的案例3: 軟件缺陷的定義4: 軟件缺陷的種類5: 軟件缺陷的級(jí)別判定6: 軟件缺陷的原因7: 軟件缺陷的組成8: 軟件測試的分類9: 軟件測試流程10:軟件測試模型11:單元測試的時(shí)間如何把握？ 軟件的質(zhì)量就是軟件的生命，為了保證軟件的質(zhì)量，人們?cè)陂L期的開發(fā)過程中積累了許多經(jīng)驗(yàn)并形成了許多行之有效的方法。但是借助這些方法，我們只能盡量減少軟件中的錯(cuò)誤和不足，卻不能完全避免所有的錯(cuò)誤。 如果把所開發(fā)出來的軟件看作一個(gè)企業(yè)生產(chǎn)的產(chǎn)品，那么軟件測試就相當(dāng)于該企業(yè)的質(zhì)量檢測部分。簡單地說，我們?cè)诰帉懲暌欢未a之后，檢查其是否如我們所預(yù)期的那樣運(yùn)行，這個(gè)

2、活動(dòng)就可以看作是一種軟件測試工作。新的測試?yán)碚?、測試方法、測試技術(shù)手段在不斷涌出，軟件測試機(jī)構(gòu)和組織也在迅速產(chǎn)生和發(fā)展，由此軟件測試技術(shù)職業(yè)也同步完善和健全起來。1:軟件測試的含義人們常常不把軟件當(dāng)回事，沒有真正意識(shí)到它已經(jīng)深入滲透到我們的日常生活中,軟件在電子信息領(lǐng)域里無處不在?，F(xiàn)在有許多人如果一天不上網(wǎng)查看電子郵件，簡直就沒法過下去。我們已經(jīng)離不開24小時(shí)包裹投遞服務(wù)、長途電話服務(wù)和最先進(jìn)的醫(yī)療服務(wù)了。 然而軟件是由人編寫開發(fā)的，是一種邏輯思維的產(chǎn)品，盡管現(xiàn)在軟件開發(fā)者采取了一系列有效措施，不斷地提高軟件開發(fā)質(zhì)量，但仍然無法完全避免軟件（產(chǎn)品）會(huì)存在各種各樣的缺陷。 2軟件缺陷案例下面以實(shí)

3、例來說明。（1）迪斯尼的獅子王游戲軟件缺陷。1994年秋天，迪斯尼公司發(fā)布了第一個(gè)面向兒童的多媒體光盤游戲獅子王動(dòng)畫故事書（the lion king animated storybook）。盡管已經(jīng)有許多其他公司在兒童游戲市場上運(yùn)作多年，但是這次是迪斯尼公司首次進(jìn)軍這個(gè)市場，所以進(jìn)行了大量促銷宣傳。結(jié)果，銷售額非?？捎^，該游戲成為孩子們那年節(jié)假日的“必買游戲”。然而后來卻飛來橫禍。12月26日，圣誕節(jié)的后一天，迪斯尼公司的客戶支持電話開始響個(gè)不停。很快，電話支持技術(shù)員們就淹沒在來自于憤怒的家長并伴隨著玩不成游戲的孩子們哭叫的電話之中。報(bào)紙和電視新聞進(jìn)行了大量的報(bào)道。后來證實(shí)，迪斯尼公司未能對(duì)

4、市面上投入使用的許多不同類型的pc機(jī)型進(jìn)行廣泛的測試。軟件在極少數(shù)系統(tǒng)中工作正常-例如在迪斯尼程序員用來開發(fā)游戲的系統(tǒng)中但在大多數(shù)公眾使用的系統(tǒng)中卻不能運(yùn)行。（2）愛國者導(dǎo)彈防御系統(tǒng)缺陷愛國者導(dǎo)彈防御系統(tǒng)是里根總統(tǒng)提出的戰(zhàn)略防御計(jì)劃（即星球大戰(zhàn)計(jì)劃）的縮略版本，它首次應(yīng)用在海灣戰(zhàn)爭中對(duì)抗伊拉克飛毛腿導(dǎo)彈的防御戰(zhàn)中。盡管對(duì)系統(tǒng)贊譽(yù)的報(bào)道不絕于耳，但是它確實(shí)在對(duì)抗幾枚導(dǎo)彈中失利，包括一次在沙特阿拉伯的多哈擊斃了28名美國士兵。分析發(fā)現(xiàn)癥結(jié)在于一個(gè)軟件缺陷，系統(tǒng)時(shí)鐘的一個(gè)很小的計(jì)時(shí)錯(cuò)誤積累起來到14小時(shí)后，跟蹤系統(tǒng)不再準(zhǔn)確。在多哈的這次襲擊中，系統(tǒng)已經(jīng)運(yùn)行了100多個(gè)小時(shí)。 （3）千年蟲問題20世紀(jì)

5、70年代早期的某個(gè)時(shí)間，某位程序員正在為本公司設(shè)計(jì)開發(fā)工資系統(tǒng)。他使用的計(jì)算機(jī)存儲(chǔ)空間很小，迫使他盡量節(jié)省每一個(gè)字節(jié)。他將自己的程序壓縮得比其他任何人都緊湊。使用的其中一個(gè)方法是把4位數(shù)年份，例如1973年，縮減為2位數(shù)，73。因?yàn)楣べY系統(tǒng)相當(dāng)信賴于日期的處理，所以需要節(jié)省大量的存儲(chǔ)空間。他簡單的認(rèn)為只有在到達(dá)2000年，那時(shí)他的程序開始計(jì)算00或01這樣的年份時(shí)問題才會(huì)產(chǎn)生。雖然他知道會(huì)出這樣的問題，但是他認(rèn)定在25年之內(nèi)程序肯定會(huì)升級(jí)或替換，而且眼前的任務(wù)比現(xiàn)在計(jì)劃遙不可及的未來更加重要。然而這一天畢竟到來了。1995年他的程序仍然在使用，而他退休了，誰也不會(huì)想到如何深入到程序中檢查200

6、0年兼容問題，更不用說去修改了。估計(jì)全球各地更換或升級(jí)類似的前者程序以解決潛在的2000問題的費(fèi)用已經(jīng)達(dá)數(shù)千億美元。 3軟件缺陷的定義從上述的案例中可以看到軟件發(fā)生錯(cuò)誤時(shí)將造成災(zāi)難性危害或?qū)τ脩舢a(chǎn)生各種影響。軟件缺陷（bug），即計(jì)算機(jī)系統(tǒng)或者程序中存在的任何一種破壞正常運(yùn)行能力的問題、錯(cuò)誤，或者隱藏的功能缺陷、瑕疵。缺陷會(huì)導(dǎo)致軟件產(chǎn)品在某種程度上不能滿足用戶的需要。對(duì)于軟件缺陷的準(zhǔn)確定義，通常有以下5條描述：（1）軟件未實(shí)現(xiàn)產(chǎn)品說明書要求的功能。（2）軟件出現(xiàn)了產(chǎn)品說明書指明不會(huì)出現(xiàn)的錯(cuò)誤。（3）軟件超出實(shí)現(xiàn)了產(chǎn)品說明書提到的功能。（4）軟件實(shí)現(xiàn)了產(chǎn)品說明書雖未明確指出但應(yīng)該實(shí)現(xiàn)的目標(biāo)。（5

7、）軟件難以理解，不易使用，運(yùn)行緩慢或者終端用戶認(rèn)為不好。 4軟件缺陷的種類軟件缺陷表現(xiàn)的形式有多種，不僅僅體現(xiàn)在功能的失效方面，還體現(xiàn)在其他方面。軟件缺陷的主要類型有： 功能、特性沒有實(shí)現(xiàn)或部分實(shí)現(xiàn)。 設(shè)計(jì)不合理，存在缺陷。 實(shí)際結(jié)果和預(yù)期結(jié)果不一致。 運(yùn)行出錯(cuò)，包括運(yùn)行中斷、系統(tǒng)崩潰、界面混亂。 數(shù)據(jù)結(jié)果不正確、精度不夠。 用戶不能接受的其他問題，如存取時(shí)間過長、界面不美觀。 5軟件缺陷的級(jí)別（1）軟件缺陷的級(jí)別作為軟件測試員，可能所發(fā)現(xiàn)的大多數(shù)問題不是那么明顯、嚴(yán)重，而是難以覺察的簡單而細(xì)微的錯(cuò)誤，有些是真正的錯(cuò)誤，也有些不是。一般來說，問題越嚴(yán)重的，其優(yōu)先級(jí)越高，越要得到及時(shí)的糾正。軟件

8、公司對(duì)缺陷嚴(yán)重性級(jí)別的定義不盡相同，但一般可以概括為4種級(jí)別：致命的：致命的錯(cuò)誤，造成系統(tǒng)或應(yīng)用程序崩潰、死機(jī)、系統(tǒng)懸掛，或造成數(shù)據(jù)丟失、主要功能完全喪失等。嚴(yán)重的：嚴(yán)重錯(cuò)誤，指功能或特性沒有實(shí)現(xiàn)，主要功能部分喪失，次要功能完全喪失，或致命的錯(cuò)誤聲明,對(duì)用戶的操作有很大影響普通的：不太嚴(yán)重的錯(cuò)誤，這樣的軟件缺陷雖然不影響系統(tǒng)的基本使用，但沒有很好地實(shí)現(xiàn)功能，沒有達(dá)到預(yù)期效果。如次要功能喪失，提示信息不太準(zhǔn)確，或用戶界面差，操作時(shí)間長等。輕微的：一些小問題，對(duì)功能幾乎沒有影響，產(chǎn)品及屬性仍可使用，如有個(gè)別錯(cuò)別字、文字排列不整齊等。除了這4種之外，有時(shí)需要“建議”級(jí)別來處理測試人員所提出的建議或質(zhì)

9、疑，如建議程序做適當(dāng)?shù)男薷模瑏砀纳瞥绦蜻\(yùn)行狀態(tài)，或?qū)υO(shè)計(jì)不合理、不明白的地方提出質(zhì)疑。 6軟件缺陷的原因 軟件缺陷的產(chǎn)生，首先是不可避免的。其次我們可以從軟件本身，團(tuán)隊(duì)工作和技術(shù)問題等多個(gè)方面分析，比較容易確定造成軟件缺陷的原因，歸納如下。技術(shù)問題算法錯(cuò)誤。語法錯(cuò)誤。計(jì)算和精度問題。系統(tǒng)結(jié)構(gòu)不合理，造成系統(tǒng)性能問題。接口參數(shù)不匹配出現(xiàn)問題。 7軟件缺陷的組成 我們知道軟件缺陷是由很多原因造成的，如果把它們按需求分析結(jié)果規(guī)格說明書，系統(tǒng)設(shè)計(jì)結(jié)果，編程的代碼等歸類起來，比較后發(fā)現(xiàn)，結(jié)果規(guī)格說明書是軟件缺陷出現(xiàn)最多的地方，見圖1-1。圖1-1 軟件缺陷構(gòu)成示意圖8軟件測試的分類從不同的角度，可以把軟

10、件測試技術(shù)分成不同種類。（1）從是否需要執(zhí)行被測軟件的角度分類從是否需要執(zhí)行被測軟件的角度，可分為靜態(tài)測試（static testing）和動(dòng)態(tài)測試(dynamic testing)。顧名思義，靜態(tài)測試就是通過對(duì)被測程序的靜態(tài)審查，發(fā)現(xiàn)代碼中潛在的錯(cuò)誤。它一般用人工方式脫機(jī)完成，故亦稱人工測試或代碼評(píng)審（code review）;也可借助于靜態(tài)分析器在機(jī)器上以自動(dòng)方式進(jìn)行檢查，但不要求程序本身在機(jī)器上運(yùn)行。按照評(píng)審的不同組織形式，代碼評(píng)審又可分為代碼會(huì)審，走查以及辦公桌檢查，同行評(píng)分4種。對(duì)某個(gè)具體的程序，通常只使用一種評(píng)審方式。動(dòng)態(tài)測試的對(duì)象必須是能夠由計(jì)算機(jī)真正運(yùn)行的被測試的程序。它分為黑

11、盒測試和白盒測試，也是我們下面將要介紹的內(nèi)容。 （2）從軟件測試用例設(shè)計(jì)方法的角度分類從軟件測試用例設(shè)計(jì)方法的角度，可分為黑盒測試（black-box testing）和白盒測試（white-box testing）。黑盒測試是一種從用戶觀點(diǎn)出發(fā)的測試，又稱為功能測試，數(shù)據(jù)驅(qū)動(dòng)測試和基于規(guī)格說明的測試。若測試用例的設(shè)計(jì)是基于產(chǎn)品的功能，目的是檢查程序各個(gè)功能是否實(shí)現(xiàn)，并檢查其中的功能錯(cuò)誤，則這種測試方法稱為黑盒。白盒測試基于產(chǎn)品的內(nèi)部結(jié)構(gòu)來進(jìn)行測試，檢查內(nèi)部操作是否按規(guī)定執(zhí)行，軟件各個(gè)部分功能是否得到充分利用。白盒測試又稱為結(jié)構(gòu)測試，邏輯驅(qū)動(dòng)測試或基于程序的測試。即根據(jù)被測程序的內(nèi)部結(jié)構(gòu)設(shè)計(jì)測

12、試用例，測試者需事先了解被測試程序的結(jié)構(gòu)。 （3）從軟件測試的策略和過程的角度分類。按照軟件測試的策略和過程分類，軟件測試可分為單元測試（unit testing），集成測試（integration testing）,確認(rèn)測試（validation testing）,系統(tǒng)測試（system testing）和驗(yàn)收測試（verification testing）.單元測試是針對(duì)每個(gè)單元的測試，是軟件測試的最小單位。它確保每個(gè)模塊能正常工作。單元測試多數(shù)使用白盒測試，用以發(fā)現(xiàn)內(nèi)部錯(cuò)誤。集成測試是對(duì)已測試過的模塊進(jìn)行組裝，進(jìn)行集成測試的目的主要在于檢驗(yàn)與軟件設(shè)計(jì)相關(guān)的程序結(jié)構(gòu)問題。集成測試一般通過黑

13、盒測試方法來完成。確認(rèn)測試是檢驗(yàn)所開發(fā)的軟件能否滿足所有功能和性能需求的最后手段，通常采用黑盒測試方法。系統(tǒng)測試的主要任務(wù)是檢測被測軟件與系統(tǒng)的其他部分的協(xié)調(diào)性。驗(yàn)收測試是軟件產(chǎn)品質(zhì)量的最后一關(guān)。這一環(huán)節(jié)，測試主要從用戶的角度著手，其參與者主要是用戶和少量的程序開發(fā)人員。 回歸測試 制定測試計(jì)劃 設(shè)計(jì)測試 實(shí)施測試 執(zhí)行測試 評(píng)估測試 9.軟件測試流程10.軟件測試過程模型瀑布模型v模型w模型h模型n瀑布測試模型瀑布模型特點(diǎn)線性化模型各階段劃分明確基于文檔的驅(qū)動(dòng)嚴(yán)格的階段評(píng)審v模型編碼用戶需求需求分析與系統(tǒng)設(shè)計(jì)概要設(shè)計(jì)詳細(xì)設(shè)計(jì)單元測試集成測試確認(rèn)測試與系統(tǒng)測試驗(yàn)收測試v模型是最具有代表意義的測

14、試模型 。v模型是軟件開發(fā)瀑布模型的變種，它反映了測試活動(dòng)與分析和設(shè)計(jì)的關(guān)系 。從左到右，描述了基本的開發(fā)過程和測試行為，非常明確地標(biāo)明了測試過程中存在的不同級(jí)別，并且清楚地描述了這些測試階段和開發(fā)過程期間各階段的對(duì)應(yīng)關(guān)系 。箭頭代表了時(shí)間方向，左邊下降的是開發(fā)過程各階段，與此相對(duì)應(yīng)的是右邊上升的部分，即各測試過程的各個(gè)階段。 v模型存在一定的局限性，它僅僅把測試過程作為在需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)及編碼之后的一個(gè)階段。容易使人理解為測試是軟件開發(fā)的最后的一個(gè)階段，主要是針對(duì)程序進(jìn)行測試尋找錯(cuò)誤，而需求分析階段的隱藏的問題一直到后期的驗(yàn)收測試才被發(fā)現(xiàn)。在v模型中增加軟件各開發(fā)階段應(yīng)同步進(jìn)行的

15、測試，被演化為一種w模型。開發(fā)是“v”，測試也是與此相重疊的“v”。w模型體現(xiàn)了“盡早地和不斷地進(jìn)行軟件測試”的原則。w模型編碼用戶需求需求分析與系統(tǒng)設(shè)計(jì)概要設(shè)計(jì)詳細(xì)設(shè)計(jì)單元測試集成測試確認(rèn)測試與系統(tǒng)測試驗(yàn)收測試用戶需求v&v驗(yàn)收測試設(shè)計(jì)需求分析與系統(tǒng)設(shè)計(jì)v&v確認(rèn)與系統(tǒng)測試設(shè)計(jì)概要設(shè)計(jì)v&v集成測試設(shè)計(jì)詳細(xì)設(shè)計(jì)v&v單元測試設(shè)計(jì)交付實(shí)施集成相比于v模型，w模型更科學(xué)。w模型可以說是前者自然而然的發(fā)展，它強(qiáng)調(diào)：測試伴隨著整個(gè)軟件開發(fā)周期，而且測試的對(duì)象不僅僅是程序，需求、功能和設(shè)計(jì)同樣要測試。 測試與開發(fā)是同步進(jìn)行的，從而有利于盡早地發(fā)現(xiàn)問題。以需求為例，需求分

16、析一完成，我們就可以對(duì)需求進(jìn)行測試，而不是等到最后才進(jìn)行針對(duì)需求的驗(yàn)收測試。 測試不僅僅是評(píng)定軟件的質(zhì)量，測試還可以盡可能早地找出缺陷所在，從而幫助改進(jìn)項(xiàng)目內(nèi)部的質(zhì)量。 h模型單元測試的時(shí)間如何把握？如果按照項(xiàng)目時(shí)間這樣劃分：1/3 計(jì)劃和設(shè)計(jì)， 1/6 實(shí)現(xiàn)， 1/4 組件測試， 1/4 系統(tǒng)測試。則在代碼實(shí)現(xiàn)中，不僅要包含coding的時(shí)間，而且要包含單元測試的時(shí)間，他們的比例大概是1/3的時(shí)間做東西， 2/3的時(shí)間做檢查。這樣才能保證“零件質(zhì)量”。單元測試不是為了增大自己的工作量，而是減少你未來的工作量。否則，從工程學(xué)上來說，或者有過真正工程經(jīng)驗(yàn)的人，都知道其質(zhì)量保證是掩耳盜鈴，最終將自

17、食其果。 哪些函數(shù)無需做單元測試：這個(gè)函數(shù)是不是簡單到一眼就能檢查出輸出和起征點(diǎn)的錯(cuò)誤？如果的確是，那么這個(gè)函數(shù)不用做單元測試。有些公司和員工為了敷衍了是做一些“偽單元測試”，有點(diǎn)形而上學(xué)，根本不是高效的單元測試。哪些函數(shù)需要做單元測試：1. 邏輯或算法復(fù)雜，函數(shù)內(nèi)部邏輯或算法很復(fù)雜，判斷條件、循環(huán)、停頓跳轉(zhuǎn)很多，一眼看不出輸入什么結(jié)果，那么需要做單元測試來驗(yàn)證期望的輸出；2. 涉及很多對(duì)象，單元測試一定要做，因?yàn)槟軌蛴行У陌l(fā)現(xiàn)和隔離依賴項(xiàng)，有助于更好的解耦；（一個(gè)緊耦合的系統(tǒng)的確很難做單元測試，需重構(gòu)）3. 拋出異?；虿蹲疆惓＃魏魏瘮?shù)如果存在內(nèi)部斷點(diǎn)或跳出點(diǎn)，一定要做單元測試模擬程序內(nèi)部跳轉(zhuǎn)和停止的情況；4. 越底層函數(shù)越需要單元測試，指的是系統(tǒng)越底層的函數(shù)、越核心的函數(shù)，越需要單元測試，反之，越高層的，比如ui層，越不要單元測試。記住，不要去測試類中的每個(gè)方法。挑選以上幾種函數(shù)進(jìn)行測試，而且要根據(jù)需求來測試這個(gè)類對(duì)外所能提供的功能, 這些功能可能是其中的幾個(gè)重要方法, 可能需要類中的幾個(gè)方法協(xié)作，可以對(duì)這幾