軟件測(cè)試的概述及方法畢業(yè)論文1

1、 軟件測(cè)試的概述及方法 摘要：從軟件產(chǎn)業(yè)的發(fā)展初期到目前的大型軟件開發(fā)過程，軟件測(cè) 試已成為其中一個(gè)不可分割的部分。隨著軟件規(guī)模的日益增大，軟 件測(cè)試問題也日益突出，現(xiàn)代社會(huì)對(duì)軟件的依賴越來(lái)越強(qiáng),高可信軟 件測(cè)試有著廣泛的需求，基于缺陷模式的軟件測(cè)試技術(shù)作為高可信 軟件的重要保證,可以大大降低軟件的缺陷密度,提高軟件的可信性。 本文從測(cè)試的基本概念入手,深入剖析軟件測(cè)試相關(guān)理論 關(guān)鍵字：關(guān)鍵字：軟件測(cè)試、白盒測(cè)試、黑盒測(cè)試、類測(cè)試 目目 錄錄 1 1 軟件測(cè)試的發(fā)展史軟件測(cè)試的發(fā)展史.4 2 2 軟件測(cè)試的相關(guān)背景軟件測(cè)試的相關(guān)背景. .5 3 3 軟件測(cè)試概述軟件測(cè)試概述.6 3.1 軟件測(cè)

2、試的定義. .6 3.2 軟件測(cè)試的描述. .6 3.3 軟件測(cè)試的目的.7 3.4 軟件測(cè)試的原則. .8 4 軟件測(cè)試的內(nèi)容軟件測(cè)試的內(nèi)容.9 4.1 驗(yàn)證(verification).9 4.2 確認(rèn)(validation). .9 5 5 軟件測(cè)試的分類軟件測(cè)試的分類.10 5.1 常用分類.10 5.2 黑盒測(cè)試.10 5.3 白盒測(cè)試. .11 5.4 靜態(tài)測(cè)試.14 5.5 動(dòng)態(tài)測(cè)試.15 6 6 軟件測(cè)試中的類測(cè)試軟件測(cè)試中的類測(cè)試.15 6.1 面向?qū)ο筌浖念悳y(cè)試概念. .156.2.類測(cè)試技術(shù). .16 7 7 參考文獻(xiàn)參考文獻(xiàn).17.17 8 8 致謝致謝.18 1 1

3、 軟件測(cè)試的發(fā)展史軟件測(cè)試的發(fā)展史 軟件測(cè)試的發(fā)展歷史：20 世紀(jì) 60 年代（軟件工程建立前） ，為表明 程序正確而進(jìn)行測(cè)試。. 1972 年在北卡羅來(lái)納大學(xué)舉行了首屆軟件 測(cè)試正式會(huì)議。. 1975 年 john good enough 和 susan gerhart 在 ieee 上發(fā)表了測(cè)試數(shù)據(jù)選擇的原理的文章，軟件測(cè)試被確定為 一種研究方向。. 1979 年，glenford myers 的軟件測(cè)試藝術(shù) ， 對(duì)測(cè)試做了定義：測(cè)試是為發(fā)現(xiàn)錯(cuò)誤而執(zhí)行的一個(gè)程序或者系統(tǒng)的 過程。. 20 世紀(jì) 80 年代早期， “質(zhì)量”的號(hào)角開始吹響。軟件測(cè)試 定義發(fā)生了改變，測(cè)試不單純是一個(gè)發(fā)現(xiàn)錯(cuò)誤的過

4、程，而且包含軟 件質(zhì)量評(píng)價(jià)的內(nèi)容。制定了各類標(biāo)準(zhǔn)。. 1983 年，bill hetzel 在 軟件測(cè)試完全指南中指出：測(cè)試是以評(píng)價(jià)一個(gè)程序或者系統(tǒng)屬 性為目標(biāo)的任何一種活動(dòng)，測(cè)試是對(duì)軟件質(zhì)量的度量。. 20 世紀(jì) 90 年代，測(cè)試工具盛行起來(lái)。. 1996 年提出的測(cè)試能力成熟度 tcmm（testing capability maturity model） 、測(cè)試支持度 tsm（testability support model） 、測(cè)試成熟度 tmm（testing maturity model） 。. 到了 2002 年，rick 和 stefan 在系統(tǒng)的軟 件測(cè)試一書中對(duì)軟件測(cè)試做

5、了進(jìn)一步定義：測(cè)試是為了度量和提 高被測(cè)軟件的質(zhì)量，對(duì)測(cè)試軟件進(jìn)行工程設(shè)計(jì)、實(shí)施和維護(hù)的整個(gè) 生命過程。 2 2 軟件測(cè)試的相關(guān)背景軟件測(cè)試的相關(guān)背景 相關(guān)背景：前段時(shí)間, 就是在我沒有認(rèn)真了解測(cè)試行業(yè)之前, 可能由于測(cè)試在中國(guó)的重視程度的問題, 我也一直認(rèn)為測(cè)試應(yīng)該是 不重要的, 甚至認(rèn)為有必要有專門的測(cè)試職業(yè)嗎？認(rèn)為軟件主要是 開發(fā)人員的事, 軟件的成果也是由開發(fā)人員決定的, 當(dāng)我在參加工 作后, 真正從學(xué)校的學(xué)習(xí)環(huán)境中走上實(shí)際運(yùn)用開發(fā)的時(shí)候, 事實(shí)上 真的不是那么一回事哦。軟件無(wú)處不在, 軟而, 軟件是人編的 所以不完美。臭名昭著的軟件測(cè)試案例： 1、迪士尼的獅子王 （19941995）

6、軟件在少數(shù)系統(tǒng)中能正常 工作, 但在大眾使用的常見系統(tǒng)中不行。后來(lái)證實(shí), 迪士尼公司沒 有對(duì)市場(chǎng)上投入實(shí)用的各種 pc 機(jī)型進(jìn)行正確的測(cè)試。 2、英特爾奔騰浮點(diǎn)除法軟件缺陷（1994）英特爾為自己處理軟 件缺陷拿出 4 億美元支付更換壞芯片的費(fèi)用。導(dǎo)致付出如此昂貴的 代價(jià), 其主要原因是發(fā)現(xiàn)了軟件缺陷沒有正確的處理。 3、美國(guó)航天局火星極地登陸（1999）該項(xiàng)目使用前有經(jīng)過測(cè)試, 兩個(gè)測(cè)試小組雙方獨(dú)立工作都很好, 但從未走在一起。 4、愛國(guó)者導(dǎo)彈防御系統(tǒng) （1991）一枚導(dǎo)彈在多哈擊斃 28 名美 國(guó)士兵, 癥結(jié)在于一個(gè)軟件缺陷：一個(gè)很小的系統(tǒng)時(shí)鐘錯(cuò)誤累積起 來(lái)就可能拖延 14 小時(shí), 造成跟

7、蹤系統(tǒng)失去準(zhǔn)確度。在多哈襲擊戰(zhàn)中 系統(tǒng)被拖延 100 小時(shí)。 5、千年蟲 （大約 1974）估計(jì)世界各地更換或升級(jí)該系統(tǒng)程序 解決原有 2000 年錯(cuò)誤的費(fèi)用已經(jīng)超過數(shù)億美元。 3 3 軟件測(cè)試的概述軟件測(cè)試的概述 3.1 軟件測(cè)試的定義 軟件測(cè)試使用人工或者自動(dòng)手段來(lái)運(yùn)行或測(cè)試某個(gè)系統(tǒng)的過程, 其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果 之間的差別。它是幫助識(shí)別開發(fā)完成（中間或最終的版本）的計(jì)算 機(jī)軟件（整體或部分）的正確度(correctness) 完全度 (completeness)和質(zhì)量(quality)的軟件過程；是 sqa(software quality assu

8、rance)的重要子域。 (1)測(cè)試并不僅僅是為了找出錯(cuò)誤.通過分析錯(cuò)誤產(chǎn)生的原因和 錯(cuò)誤的發(fā)生趨勢(shì),可以幫助項(xiàng)目管理者發(fā)現(xiàn)當(dāng)前軟件開發(fā)過程中的缺 陷,以便及時(shí)改進(jìn)； (2)這種分析也能幫助測(cè)試人員設(shè)計(jì)出有針對(duì)性的測(cè)試方法,改 善測(cè)試的效率和有效性； (3)沒有發(fā)現(xiàn)錯(cuò)誤的測(cè)試也是有價(jià)值的,完整的測(cè)試是評(píng)定軟件 質(zhì)量的一種方法。 3.2 軟件測(cè)試的描述 測(cè)試是軟件開發(fā)過程的重要組成部分, 是用來(lái)確認(rèn)一個(gè)程序的 品質(zhì)或性能是否符合開發(fā)之前所提出的一些要求。軟件測(cè)試的目的, 第一是確認(rèn)軟件的質(zhì)量, 其一方面是確認(rèn)軟件做了你所期望的事情 （do the right thing）, 另一方面是確認(rèn)軟件以

9、正確的方式來(lái)做 了這個(gè)事件（do it right） ；第二是提供信息, 比如提供給開發(fā)人 員或程序經(jīng)理的反饋信息, 為風(fēng)險(xiǎn)評(píng)估所準(zhǔn)備的信息；第三軟件測(cè) 試不僅是在測(cè)試軟件產(chǎn)品的本身, 而且還包括軟件開發(fā)的過程。如 果一個(gè)軟件產(chǎn)品開發(fā)完成之后發(fā)現(xiàn)了很多問題, 這說(shuō)明此軟件開發(fā) 過程很可能是有缺陷的。 3.3 軟件測(cè)試的目的 如果測(cè)試的目的是為了盡可能多地找出錯(cuò)誤，那么測(cè)試就應(yīng)該 直接針對(duì)軟件比較復(fù)雜的部分或是以前出錯(cuò)比較多的位置。如果測(cè) 試目的是為了給最終用戶提供具有一定可信度的質(zhì)量評(píng)價(jià)，那么測(cè) 試就應(yīng)該直接針對(duì)在實(shí)際應(yīng)用中會(huì)經(jīng)常用到的商業(yè)假設(shè)。 在談到 軟件測(cè)試時(shí)，引用 grenford j

10、. myers 在the art of software testing一書中的觀點(diǎn): (1)軟件測(cè)試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程 序的過程; (2)測(cè)試是為了證明程序有錯(cuò)，而不是證明程序無(wú)錯(cuò)誤; (3)一個(gè)好的測(cè)試用例是在于它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯(cuò)誤; (4)一 個(gè)成功的測(cè)試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試。 這種觀點(diǎn)可以 提醒人們測(cè)試要以查找錯(cuò)誤為中心，而不是為了演示軟件的正確功 能。但是僅憑字面意思理解這一觀點(diǎn)可能會(huì)產(chǎn)生誤導(dǎo)，認(rèn)為發(fā)現(xiàn)錯(cuò) 誤是軟件測(cè)試的唯一目，查找不出錯(cuò)誤的測(cè)試就是沒有價(jià)值的，事 實(shí)并非如此。 首先，測(cè)試并不僅僅是為了要找出錯(cuò)誤。通過分析 錯(cuò)誤產(chǎn)生的原因和錯(cuò)誤的分布特征，可以幫助項(xiàng)

11、目管理者發(fā)現(xiàn)當(dāng)前 所采用的軟件過程的缺陷，以便改進(jìn)。同時(shí)，這種分析也能幫助我 們?cè)O(shè)計(jì)出有針對(duì)性地檢測(cè)方法，改善測(cè)試的有效性。其次，沒有發(fā) 現(xiàn)錯(cuò)誤的測(cè)試也是有價(jià)值的，完整的測(cè)試是評(píng)定測(cè)試質(zhì)量的一種方 法。 3.4 軟件測(cè)試的原則 1應(yīng)當(dāng)把盡早和不斷的測(cè)試作為開發(fā)者的座右銘。 2程序員應(yīng)該避免檢查自己的程序, 測(cè)試工作應(yīng)該由獨(dú)立的專 業(yè)的軟件測(cè)試機(jī)構(gòu)來(lái)完成。 3設(shè)計(jì)測(cè)試用例時(shí)應(yīng)該考慮到合法的輸入和不合法的輸入以及 各種邊界條件, 特殊情況下要制造極端狀態(tài)和意外狀態(tài), 比如網(wǎng)絡(luò) 異常中斷、電源斷電等情況。 4一定要注意測(cè)試中的錯(cuò)誤集中發(fā)生現(xiàn)象, 這和程序員的編程 水平和習(xí)慣有很大的關(guān)系。 5對(duì)測(cè)試錯(cuò)

12、誤結(jié)果一定要有一個(gè)確認(rèn)的過程, 一般有 a 測(cè)試出 來(lái)的錯(cuò)誤, 一定要有一個(gè) b 來(lái)確認(rèn), 嚴(yán)重的錯(cuò)誤可以召開評(píng)審會(huì)進(jìn) 行討論和分析。 6制定嚴(yán)格的測(cè)試計(jì)劃, 并把測(cè)試時(shí)間安排的盡量寬松, 不要 希望在極短的時(shí)間內(nèi)完成一個(gè)高水平的測(cè)試。 7回歸測(cè)試的關(guān)聯(lián)性一定要引起充分的注意, 修改一個(gè)錯(cuò)誤而 引起更多的錯(cuò)誤出現(xiàn)的現(xiàn)象并不少見。 8妥善保存一切測(cè)試過程文檔, 意義是不言而喻的, 測(cè)試的重 現(xiàn)性往往要靠測(cè)試文檔 4 4 軟件測(cè)試的內(nèi)容軟件測(cè)試的內(nèi)容 4.1 驗(yàn)證(verification) 驗(yàn)證(verification)是保證軟件正確地實(shí)現(xiàn)了一些特定功能的 一系列活動(dòng), 即保證軟件做了你所期望

13、的事情。(do the right thing) 1.確定軟件生存周期中的一個(gè)給定階段的產(chǎn)品是否達(dá)到前階段 確立的需求的過程； 2.程序正確性的形式證明, 即采用形式理論證明程序符號(hào)設(shè)計(jì) 規(guī)約規(guī)定的過程； 3.評(píng)市、審查、測(cè)試、檢查、審計(jì)等各類活動(dòng), 或?qū)δ承╉?xiàng)處 理、服務(wù)或文件等是否和規(guī)定的需求相一致進(jìn)行判斷和提出報(bào)告。 4.2 確認(rèn)(validation) 確認(rèn)(validation)是一系列的活動(dòng)和過程, 目的是想證實(shí)在一 個(gè)給定的外部環(huán)境中軟件的邏輯正確性。即保證軟件以正確的方式 來(lái)做了這個(gè)事件(do it right) 1.靜態(tài)確認(rèn), 不在計(jì)算機(jī)上實(shí)際執(zhí)行程序, 通過人工或程序分 析

14、來(lái)證明軟件的正確性； 2.動(dòng)態(tài)確認(rèn), 通過執(zhí)行程序做分析, 測(cè)試程序的動(dòng)態(tài)行為, 以 證實(shí)軟件是否存在問題。 軟件測(cè)試的對(duì)象不僅僅是程序測(cè)試, 軟件測(cè)試應(yīng)該包括整個(gè)軟 件開發(fā)期問各個(gè)階段所產(chǎn)生的文檔, 如需求規(guī)格說(shuō)明、概要設(shè)計(jì)文 檔、詳細(xì)設(shè)計(jì)文檔, 當(dāng)然軟件測(cè)試的主要對(duì)象還是源程序。 5 5 軟件測(cè)試的分類軟件測(cè)試的分類 5.1 常用分類 從是否需要執(zhí)行被測(cè)軟件的角度, 可分為： 靜態(tài)測(cè)試 和動(dòng)態(tài)測(cè)試 從測(cè)試是否針對(duì)系統(tǒng)的內(nèi)部結(jié)構(gòu)和具體實(shí)現(xiàn)算法的角度來(lái)看, 可分為 ： 白盒測(cè)試 和黑盒測(cè)試 5.2 黑盒測(cè)試 黑盒測(cè)試 指的是把被測(cè)軟件看作是一個(gè)黑盒子, 我們不去關(guān)心盒子里面 的結(jié)構(gòu)是什么樣子,

15、 只關(guān)心軟件的輸入數(shù)據(jù)和輸出結(jié)果。 黑盒測(cè)試方法是在程序接口上進(jìn)行測(cè)試, 主要是為了發(fā)現(xiàn)以下 錯(cuò)誤: 是否有不正確或遺漏了的功能? 在接口上, 輸入能否正確地接受? 能否輸出正確的結(jié)果? 是否有數(shù)據(jù)結(jié)構(gòu)錯(cuò)誤或外部信息(例如數(shù)據(jù)文件)訪問錯(cuò)誤? 性能上是否能夠滿足要求? 是否有初始化或終止性錯(cuò)誤? 用黑盒測(cè)試發(fā)現(xiàn)程序中的錯(cuò)誤, 必須在所有可能的輸入條件和 輸出條件中確定測(cè)試數(shù)據(jù), 來(lái)檢查程序是否都能產(chǎn)生正確的輸出。 但這是不可能的。 n 假設(shè)一個(gè)程序 p 有輸入量 x 和 y 及輸出量 z。在字長(zhǎng)為 32 位 的計(jì)算機(jī)上運(yùn)行。若 x、y 取整數(shù), 按黑盒方法進(jìn)行窮舉測(cè)試： n 可能采用的 測(cè)試數(shù)

16、據(jù)組： 232232 264 n 如果 測(cè)試一組數(shù)據(jù)需要 1 毫秒, 一年工作 365 24 小時(shí), 完成所有測(cè)試 需 5 億年。 黑盒測(cè)試的測(cè)試用例設(shè)計(jì) 等價(jià)劃分法 邊界值法 錯(cuò)誤推測(cè)法 因果圖法 5.3 白盒測(cè)試 白盒測(cè)試指的是把盒子蓋打開, 去研究里面的源代碼和程序結(jié) 構(gòu)。 白盒測(cè)試也稱結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試, 它是知道產(chǎn)品內(nèi)部工 作過程, 可通過測(cè)試來(lái)檢測(cè)產(chǎn)品內(nèi)部動(dòng)作是否按照規(guī)格說(shuō)明書的規(guī) 定正常進(jìn)行, 按照程序內(nèi)部的結(jié)構(gòu)測(cè)試程序, 檢驗(yàn)程序中的每條通 路是否都有能按預(yù)定要求正確工作, 而不顧它的功能。 使用被測(cè)單 元內(nèi)部如何工作的信息, 允許測(cè)試人員對(duì)程序內(nèi)部邏輯結(jié)構(gòu)及有關(guān) 信息來(lái)設(shè)

17、計(jì)和選擇測(cè)試用例, 對(duì)程序的邏輯路徑進(jìn)行測(cè)試?；谝?個(gè)應(yīng)用代碼的內(nèi)部邏輯知識(shí), 測(cè)試是基于覆蓋全部代碼、分支、路 徑、條件。 白盒測(cè)試的主要方法： 邏輯驅(qū)動(dòng)測(cè)試 基本路徑測(cè)試 主要用于軟件驗(yàn)證。 使用程序設(shè)計(jì)的控制結(jié)構(gòu)導(dǎo)出測(cè)試用例。 邏輯驅(qū)動(dòng)測(cè)試： 主要是測(cè)試覆蓋率, 以程序內(nèi)在邏輯結(jié)構(gòu)為基礎(chǔ)的測(cè)試。包括 以下 6 種類型： 語(yǔ)句覆蓋 判斷覆蓋 條件覆蓋 判定-條件覆蓋 條件組合覆蓋 路徑覆蓋 白盒測(cè)試的主要目的 保證一個(gè)模塊中的所有獨(dú)立路徑至少被執(zhí)行一次； 對(duì)所有的邏輯值均需要測(cè)試真、假兩個(gè)分支； 在上下邊界及可操作范圍內(nèi)運(yùn)行所有循環(huán)； 檢查內(nèi)部數(shù)據(jù)結(jié)構(gòu)以確保其有效性 白盒測(cè)試的實(shí)施方案

18、在開發(fā)階段 要保證產(chǎn)品的質(zhì)量, 產(chǎn)品的生產(chǎn)過程應(yīng)該遵循一定的行業(yè)標(biāo)準(zhǔn)。 軟件產(chǎn)品也是同樣, 沒有標(biāo)準(zhǔn)可依自然談不上質(zhì)量的好壞。所有關(guān) 心軟件開發(fā)質(zhì)量的組織、單位, 都要定義或了解軟件的質(zhì)量標(biāo)準(zhǔn)、 模型。其好處是保證公司實(shí)踐的均勻性, 產(chǎn)品的可維護(hù)性、可靠性 以及可移植性等。 在測(cè)試階段 與軟件產(chǎn)品的開發(fā)過程一樣, 測(cè)試過程也需要有一定的準(zhǔn)則, 來(lái)指導(dǎo)、度量、評(píng)價(jià)軟件測(cè)試過程的質(zhì)量。定義測(cè)試準(zhǔn)則 為控制測(cè)試的有效性以及完成程度, 必須定義準(zhǔn)則和策略, 以 判斷何時(shí)結(jié)束測(cè)試階段。準(zhǔn)則必須是客觀的, 可量化的元素, 而不 能是經(jīng)驗(yàn)或感覺。 根據(jù)應(yīng)用的準(zhǔn)則和項(xiàng)目相關(guān)的約束, 項(xiàng)目領(lǐng)導(dǎo)可以定義使用的 度

19、量方法, 和要達(dá)到的覆蓋率。 度量測(cè)試的有效性、完整性 對(duì)每個(gè)測(cè)試的測(cè)試覆蓋信息和累計(jì)信息, 用圖形方式顯示 覆蓋比率, 并根據(jù)測(cè)試運(yùn)行情況實(shí)時(shí)更新, 隨時(shí)顯示新的測(cè)試所反 映的測(cè)試覆蓋情況。 允許所有的測(cè)試運(yùn)行依據(jù)其有效性進(jìn)行管理, 用戶可以減 少不適用于非回歸測(cè)試的測(cè)試的過程。 概念： 1.語(yǔ)句覆蓋：語(yǔ)句覆蓋就是設(shè)計(jì)若干個(gè)測(cè)試用例, 運(yùn)行被測(cè)試 程序, 使得每一條可執(zhí)行語(yǔ)句至少執(zhí)行一次； 2.判定覆蓋（也稱為分支覆蓋）：設(shè)計(jì)若干個(gè)測(cè)試用例, 運(yùn)行 所測(cè)程序, 使程序中每個(gè)判斷的取真分支和取假分支至少執(zhí)行一次； 3.條件覆蓋：設(shè)計(jì)足夠多的測(cè)試用例, 運(yùn)行所測(cè)程序, 使程序 中每個(gè)判斷的每個(gè)條

20、件的每個(gè)可能取值至少執(zhí)行一次； 4.判定-條件覆蓋：設(shè)計(jì)足夠多的測(cè)試用例, 運(yùn)行所測(cè)程序, 使 程序中每個(gè)判斷的每個(gè)條件的所有可能取值至少執(zhí)行一次, 并且每 個(gè)可能的判斷結(jié)果也至少執(zhí)行一次, 換句話說(shuō), 即是要求各個(gè)判斷 的所有可能的條件取值組合至少執(zhí)行一次； 5.條件組合測(cè)試：設(shè)計(jì)足夠多的測(cè)試用例, 運(yùn)行所測(cè)程序, 使 程序中每個(gè)判斷的所有可能的條件取值組合至少執(zhí)行一次； 6.路徑測(cè)試：設(shè)計(jì)足夠多的測(cè)試用例, 運(yùn)行所測(cè)程序, 要覆蓋 程序中所有可能的路徑。 5.4 靜態(tài)測(cè)試 是指不實(shí)際運(yùn)行被測(cè)軟件, 而只是靜態(tài)的檢查程序代碼、界面 或文檔中可能存在的錯(cuò)誤的過程。 其中包括代碼測(cè)試、界面測(cè)試和

21、文檔測(cè)試 3 個(gè)方面。對(duì)于代碼 測(cè)試, 主要測(cè)試代碼是否符合相應(yīng)的標(biāo)準(zhǔn)和規(guī)范。對(duì)于界面測(cè)試, 主要測(cè)試軟件的實(shí)際界面與需求中的說(shuō)明是否相符。對(duì)于文檔測(cè)試, 主要測(cè)試用戶手冊(cè)和需求說(shuō)明是否符合用戶的實(shí)際要求。 5.5 動(dòng)態(tài)測(cè)試 是指實(shí)際運(yùn)行被測(cè)程序, 輸入相應(yīng)的測(cè)試數(shù)據(jù), 檢查實(shí)際輸出 結(jié)果和預(yù)期結(jié)果是否相符的過程。所以, 我們判斷一個(gè)測(cè)試屬于動(dòng) 態(tài)還是靜態(tài)測(cè)試 , 唯一的標(biāo)準(zhǔn)就是看是否運(yùn)行程序。 6 6 軟件測(cè)試中的類測(cè)試軟件測(cè)試中的類測(cè)試 6.1面向?qū)ο筌浖暮暧^上來(lái)看是各個(gè)類之間的相互作用。在 面向?qū)ο笙到y(tǒng)中,系統(tǒng)的基本構(gòu)造模塊是封裝了的數(shù)據(jù)和方法的類和 對(duì)象,而不再是一個(gè)個(gè)能完成特定功能

22、的功能模塊。每個(gè)對(duì)象有自己 的生存周期,有自己的狀態(tài)。消息是對(duì)象之間相互請(qǐng)求或協(xié)作的途徑, 是外界使用對(duì)象方法及獲取對(duì)象狀態(tài)的唯一方式。對(duì)象的功能是在 消息的觸發(fā)下,由對(duì)象所屬類中定義的方法與相關(guān)對(duì)象的合作共同完 成,且在不同狀態(tài)下對(duì)消息的響應(yīng)可能完全不同。對(duì)象中的數(shù)據(jù)和方 法是一個(gè)有機(jī)的整體,測(cè)試過程中不能僅僅檢查輸入數(shù)據(jù)產(chǎn)生的輸出 結(jié)果是否與預(yù)期的吻合,還要考慮對(duì)象的狀態(tài)。模塊測(cè)試的概念已不 適用于對(duì)象的測(cè)試“類測(cè)試將是整個(gè)測(cè)試過程的一個(gè)重要步驟。 6.2 類測(cè)試技術(shù) 6.2.1 基于服務(wù)的類測(cè)試技術(shù) 基于服務(wù)的類測(cè)試主要考察封裝在類中的一個(gè)方法對(duì)數(shù)據(jù)進(jìn)行 的操作，它可以采用傳統(tǒng)的白盒測(cè)試方法。為克服軟件測(cè)試的盲目 性和局限性,保證測(cè)試的質(zhì)量,提高軟件的可靠性,下面我們介紹一種 類的服務(wù)的測(cè)試模型及相應(yīng)的測(cè)試策略。 bbd 通常有兩種獲取途徑。一是采用逆向工程的方法根 據(jù)源程