軟件測試畢業(yè)論文(下載)[19頁]

1、1 四川師范大學(xué)四川師范大學(xué) 軟件工程專業(yè)畢業(yè)論文軟件工程專業(yè)畢業(yè)論文 姓姓 名：名： 專專 業(yè)業(yè): : 年年 級：級： 學(xué)學(xué) 號：號： 指導(dǎo)教師指導(dǎo)教師: : 2 軟件測試的概述及方法 、 、 完成時(shí)間：2012 年 3 月 摘要：摘要：從軟件產(chǎn)業(yè)的發(fā)展初期到目前的大型軟件開發(fā)過程，軟件測試 已成為其中一個(gè)不可分割的部分。隨著軟件規(guī)模的日益增大，軟件測 試問題也日益突出，現(xiàn)代社會對軟件的依賴越來越強(qiáng),高可信軟件測 試有著廣泛的需求，基于缺陷模式的軟件測試技術(shù)作為高可信軟件的 重要保證,可以大大降低軟件的缺陷密度,提高軟件的可信性。本文從 測試的基本概念入手,深入剖析軟件測試相關(guān)理論 關(guān)鍵字：

2、關(guān)鍵字：軟件測試、白盒測試、黑盒測試、類測試 3 目目 錄錄 1 1 軟件測試的發(fā)展史軟件測試的發(fā)展史.4 2 2 軟件測試的相關(guān)背景軟件測試的相關(guān)背景. .5 3 3 軟件測試概述軟件測試概述.6 3.1 軟件測試的定義. .6 3.2 軟件測試的描述. .6 3.3 軟件測試的目的.7 3.4 軟件測試的原則. .8 4 軟件測試的內(nèi)容軟件測試的內(nèi)容.9 4.1 驗(yàn)證(verification).9 4.2 確認(rèn)(validation). .9 5 5 軟件測試的分類軟件測試的分類.10 5.1 常用分類.10 5.2 黑盒測試.10 5.3 白盒測試. .11 5.4 靜態(tài)測試.14 5

3、.5 動態(tài)測試.15 4 6 6 軟件測試中的類測試軟件測試中的類測試.15 6.1 面向?qū)ο筌浖念悳y試概念. .156.2.類測試技術(shù). .16 7 7 參考文獻(xiàn)參考文獻(xiàn).17.17 8 8 致謝致謝.18 1 1 軟件測試的發(fā)展史軟件測試的發(fā)展史 軟件測試的發(fā)展歷史：20 世紀(jì) 60 年代（軟件工程建立前） ，為表明 程序正確而進(jìn)行測試。. 1972 年在北卡羅來納大學(xué)舉行了首屆軟件 測試正式會議。. 1975 年 John Good Enough 和 Susan Gerhart 在 IEEE 上發(fā)表了測試數(shù)據(jù)選擇的原理的文章，軟件測試被確定為 一種研究方向。. 1979 年，Glenf

4、ord Myers 的軟件測試藝術(shù) ， 對測試做了定義：測試是為發(fā)現(xiàn)錯(cuò)誤而執(zhí)行的一個(gè)程序或者系統(tǒng)的 過程。. 20 世紀(jì) 80 年代早期， “質(zhì)量”的號角開始吹響。軟件測試 定義發(fā)生了改變，測試不單純是一個(gè)發(fā)現(xiàn)錯(cuò)誤的過程，而且包含軟 件質(zhì)量評價(jià)的內(nèi)容。制定了各類標(biāo)準(zhǔn)。. 1983 年，Bill Hetzel 在 軟件測試完全指南中指出：測試是以評價(jià)一個(gè)程序或者系統(tǒng)屬 性為目標(biāo)的任何一種活動，測試是對軟件質(zhì)量的度量。. 20 世紀(jì) 90 年代，測試工具盛行起來。. 1996 年提出的測試能力成熟度 5 TCMM（Testing Capability Maturity Model） 、測試支持度

5、TSM（Testability Support Model） 、測試成熟度 TMM（Testing Maturity Model） 。. 到了 2002 年，Rick 和 Stefan 在系統(tǒng)的軟 件測試一書中對軟件測試做了進(jìn)一步定義：測試是為了度量和提 高被測軟件的質(zhì)量，對測試軟件進(jìn)行工程設(shè)計(jì)、實(shí)施和維護(hù)的整個(gè) 生命過程。 2 2 軟件測試的相關(guān)背景軟件測試的相關(guān)背景 相關(guān)背景：前段時(shí)間, 就是在我沒有認(rèn)真了解測試行業(yè)之前, 可能由于測試在中國的重視程度的問題, 我也一直認(rèn)為測試應(yīng)該是 不重要的, 甚至認(rèn)為有必要有專門的測試職業(yè)嗎？認(rèn)為軟件主要是 開發(fā)人員的事, 軟件的成果也是由開發(fā)人員決定

6、的, 當(dāng)我在參加工 作后, 真正從學(xué)校的學(xué)習(xí)環(huán)境中走上實(shí)際運(yùn)用開發(fā)的時(shí)候, 事實(shí)上 真的不是那么一回事哦。軟件無處不在, 軟而, 軟件是人編的 所以不完美。臭名昭著的軟件測試案例： 1、迪士尼的獅子王 （19941995）軟件在少數(shù)系統(tǒng)中能正常 工作, 但在大眾使用的常見系統(tǒng)中不行。后來證實(shí), 迪士尼公司沒 有對市場上投入實(shí)用的各種 pc 機(jī)型進(jìn)行正確的測試。 2、英特爾奔騰浮點(diǎn)除法軟件缺陷（1994）英特爾為自己處理軟 件缺陷拿出 4 億美元支付更換壞芯片的費(fèi)用。導(dǎo)致付出如此昂貴的 代價(jià), 其主要原因是發(fā)現(xiàn)了軟件缺陷沒有正確的處理。 6 3、美國航天局火星極地登陸（1999）該項(xiàng)目使用前有經(jīng)

7、過測試, 兩個(gè)測試小組雙方獨(dú)立工作都很好, 但從未走在一起。 4、愛國者導(dǎo)彈防御系統(tǒng) （1991）一枚導(dǎo)彈在多哈擊斃 28 名美 國士兵, 癥結(jié)在于一個(gè)軟件缺陷：一個(gè)很小的系統(tǒng)時(shí)鐘錯(cuò)誤累積起 來就可能拖延 14 小時(shí), 造成跟蹤系統(tǒng)失去準(zhǔn)確度。在多哈襲擊戰(zhàn)中 系統(tǒng)被拖延 100 小時(shí)。 5、千年蟲 （大約 1974）估計(jì)世界各地更換或升級該系統(tǒng)程序 解決原有 2000 年錯(cuò)誤的費(fèi)用已經(jīng)超過數(shù)億美元。 3 3 軟件測試的概述軟件測試的概述 3.1 軟件測試的定義 軟件測試使用人工或者自動手段來運(yùn)行或測試某個(gè)系統(tǒng)的過程, 其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果 之間的差別。它是

8、幫助識別開發(fā)完成（中間或最終的版本）的計(jì)算 機(jī)軟件（整體或部分）的正確度(correctness) 完全度 (completeness)和質(zhì)量(quality)的軟件過程；是 SQA(software quality assurance)的重要子域。 (1)測試并不僅僅是為了找出錯(cuò)誤.通過分析錯(cuò)誤產(chǎn)生的原因和 錯(cuò)誤的發(fā)生趨勢,可以幫助項(xiàng)目管理者發(fā)現(xiàn)當(dāng)前軟件開發(fā)過程中的缺 陷,以便及時(shí)改進(jìn)； (2)這種分析也能幫助測試人員設(shè)計(jì)出有針對性的測試方法,改 7 善測試的效率和有效性； (3)沒有發(fā)現(xiàn)錯(cuò)誤的測試也是有價(jià)值的,完整的測試是評定軟件 質(zhì)量的一種方法。 3.2 軟件測試的描述 測試是軟件開發(fā)過

9、程的重要組成部分, 是用來確認(rèn)一個(gè)程序的 品質(zhì)或性能是否符合開發(fā)之前所提出的一些要求。軟件測試的目的, 第一是確認(rèn)軟件的質(zhì)量, 其一方面是確認(rèn)軟件做了你所期望的事情 （Do the right thing）, 另一方面是確認(rèn)軟件以正確的方式來做 了這個(gè)事件（Do it right） ；第二是提供信息, 比如提供給開發(fā)人 員或程序經(jīng)理的反饋信息, 為風(fēng)險(xiǎn)評估所準(zhǔn)備的信息；第三軟件測 試不僅是在測試軟件產(chǎn)品的本身, 而且還包括軟件開發(fā)的過程。如 果一個(gè)軟件產(chǎn)品開發(fā)完成之后發(fā)現(xiàn)了很多問題, 這說明此軟件開發(fā) 過程很可能是有缺陷的。 3.3 軟件測試的目的 如果測試的目的是為了盡可能多地找出錯(cuò)誤，那么

10、測試就應(yīng)該 直接針對軟件比較復(fù)雜的部分或是以前出錯(cuò)比較多的位置。如果測 試目的是為了給最終用戶提供具有一定可信度的質(zhì)量評價(jià)，那么測 試就應(yīng)該直接針對在實(shí)際應(yīng)用中會經(jīng)常用到的商業(yè)假設(shè)。 在談到 軟件測試時(shí)，引用 Grenford J. Myers 在The Art of Software Testing一書中的觀點(diǎn): (1)軟件測試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程 8 序的過程; (2)測試是為了證明程序有錯(cuò)，而不是證明程序無錯(cuò)誤; (3)一個(gè)好的測試用例是在于它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯(cuò)誤; (4)一 個(gè)成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯(cuò)誤的測試。 這種觀點(diǎn)可以 提醒人們測試要以查找錯(cuò)誤為中心，而不是為了演示軟

11、件的正確功 能。但是僅憑字面意思理解這一觀點(diǎn)可能會產(chǎn)生誤導(dǎo)，認(rèn)為發(fā)現(xiàn)錯(cuò) 誤是軟件測試的唯一目，查找不出錯(cuò)誤的測試就是沒有價(jià)值的，事 實(shí)并非如此。 首先，測試并不僅僅是為了要找出錯(cuò)誤。通過分析 錯(cuò)誤產(chǎn)生的原因和錯(cuò)誤的分布特征，可以幫助項(xiàng)目管理者發(fā)現(xiàn)當(dāng)前 所采用的軟件過程的缺陷，以便改進(jìn)。同時(shí)，這種分析也能幫助我 們設(shè)計(jì)出有針對性地檢測方法，改善測試的有效性。其次，沒有發(fā) 現(xiàn)錯(cuò)誤的測試也是有價(jià)值的，完整的測試是評定測試質(zhì)量的一種方 法。 3.4 軟件測試的原則 1應(yīng)當(dāng)把盡早和不斷的測試作為開發(fā)者的座右銘。 2程序員應(yīng)該避免檢查自己的程序, 測試工作應(yīng)該由獨(dú)立的專 業(yè)的軟件測試機(jī)構(gòu)來完成。 3設(shè)計(jì)測

12、試用例時(shí)應(yīng)該考慮到合法的輸入和不合法的輸入以及 各種邊界條件, 特殊情況下要制造極端狀態(tài)和意外狀態(tài), 比如網(wǎng)絡(luò) 異常中斷、電源斷電等情況。 4一定要注意測試中的錯(cuò)誤集中發(fā)生現(xiàn)象, 這和程序員的編程 水平和習(xí)慣有很大的關(guān)系。 5對測試錯(cuò)誤結(jié)果一定要有一個(gè)確認(rèn)的過程, 一般有 A 測試出 9 來的錯(cuò)誤, 一定要有一個(gè) B 來確認(rèn), 嚴(yán)重的錯(cuò)誤可以召開評審會進(jìn) 行討論和分析。 6制定嚴(yán)格的測試計(jì)劃, 并把測試時(shí)間安排的盡量寬松, 不要 希望在極短的時(shí)間內(nèi)完成一個(gè)高水平的測試。 7回歸測試的關(guān)聯(lián)性一定要引起充分的注意, 修改一個(gè)錯(cuò)誤而 引起更多的錯(cuò)誤出現(xiàn)的現(xiàn)象并不少見。 8妥善保存一切測試過程文檔,

13、意義是不言而喻的, 測試的重 現(xiàn)性往往要靠測試文檔 4 4 軟件測試的內(nèi)容軟件測試的內(nèi)容 4.1 驗(yàn)證(verification) 驗(yàn)證(verification)是保證軟件正確地實(shí)現(xiàn)了一些特定功能的 一系列活動, 即保證軟件做了你所期望的事情。(Do the right thing) 1.確定軟件生存周期中的一個(gè)給定階段的產(chǎn)品是否達(dá)到前階段 確立的需求的過程； 2.程序正確性的形式證明, 即采用形式理論證明程序符號設(shè)計(jì) 規(guī)約規(guī)定的過程； 3.評市、審查、測試、檢查、審計(jì)等各類活動, 或?qū)δ承╉?xiàng)處 理、服務(wù)或文件等是否和規(guī)定的需求相一致進(jìn)行判斷和提出報(bào)告。 10 4.2 確認(rèn)(validati

14、on) 確認(rèn)(validation)是一系列的活動和過程, 目的是想證實(shí)在一 個(gè)給定的外部環(huán)境中軟件的邏輯正確性。即保證軟件以正確的方式 來做了這個(gè)事件(Do it right) 1.靜態(tài)確認(rèn), 不在計(jì)算機(jī)上實(shí)際執(zhí)行程序, 通過人工或程序分 析來證明軟件的正確性； 2.動態(tài)確認(rèn), 通過執(zhí)行程序做分析, 測試程序的動態(tài)行為, 以 證實(shí)軟件是否存在問題。 軟件測試的對象不僅僅是程序測試, 軟件測試應(yīng)該包括整個(gè)軟 件開發(fā)期問各個(gè)階段所產(chǎn)生的文檔, 如需求規(guī)格說明、概要設(shè)計(jì)文 檔、詳細(xì)設(shè)計(jì)文檔, 當(dāng)然軟件測試的主要對象還是源程序。 5 5 軟件測試的分類軟件測試的分類 5.1 常用分類 從是否需要執(zhí)行

15、被測軟件的角度, 可分為： 靜態(tài)測試 和動態(tài)測試 從測試是否針對系統(tǒng)的內(nèi)部結(jié)構(gòu)和具體實(shí)現(xiàn)算法的角度來看, 可分為 ： 白盒測試 和黑盒測試 11 5.2 黑盒測試 黑盒測試 指的是把被測軟件看作是一個(gè)黑盒子, 我們不去關(guān)心盒子里面 的結(jié)構(gòu)是什么樣子, 只關(guān)心軟件的輸入數(shù)據(jù)和輸出結(jié)果。 黑盒測試方法是在程序接口上進(jìn)行測試, 主要是為了發(fā)現(xiàn)以下 錯(cuò)誤: 是否有不正確或遺漏了的功能? 在接口上, 輸入能否正確地接受? 能否輸出正確的結(jié)果? 是否有數(shù)據(jù)結(jié)構(gòu)錯(cuò)誤或外部信息(例如數(shù)據(jù)文件)訪問錯(cuò)誤? 性能上是否能夠滿足要求? 是否有初始化或終止性錯(cuò)誤? 用黑盒測試發(fā)現(xiàn)程序中的錯(cuò)誤, 必須在所有可能的輸入條

16、件和 輸出條件中確定測試數(shù)據(jù), 來檢查程序是否都能產(chǎn)生正確的輸出。 但這是不可能的。 n 假設(shè)一個(gè)程序 P 有輸入量 X 和 Y 及輸出量 Z。在字長為 32 位 的計(jì)算機(jī)上運(yùn)行。若 X、Y 取整數(shù), 按黑盒方法進(jìn)行窮舉測試： n 可能采用的 測試數(shù)據(jù)組： 232232 264 n 如果 測試一組數(shù)據(jù)需要 1 毫秒, 一年工作 365 24 小時(shí), 完成所有測試 需 5 億年。 黑盒測試的測試用例設(shè)計(jì) 等價(jià)劃分法 邊界值法 12 錯(cuò)誤推測法 因果圖法 5.3 白盒測試 白盒測試指的是把盒子蓋打開, 去研究里面的源代碼和程序結(jié) 構(gòu)。 白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試, 它是知道產(chǎn)品內(nèi)部工 作過

17、程, 可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī) 定正常進(jìn)行, 按照程序內(nèi)部的結(jié)構(gòu)測試程序, 檢驗(yàn)程序中的每條通 路是否都有能按預(yù)定要求正確工作, 而不顧它的功能。 使用被測單 元內(nèi)部如何工作的信息, 允許測試人員對程序內(nèi)部邏輯結(jié)構(gòu)及有關(guān) 信息來設(shè)計(jì)和選擇測試用例, 對程序的邏輯路徑進(jìn)行測試。基于一 個(gè)應(yīng)用代碼的內(nèi)部邏輯知識, 測試是基于覆蓋全部代碼、分支、路 徑、條件。 白盒測試的主要方法： 邏輯驅(qū)動測試 基本路徑測試 主要用于軟件驗(yàn)證。 使用程序設(shè)計(jì)的控制結(jié)構(gòu)導(dǎo)出測試用例。 邏輯驅(qū)動測試： 主要是測試覆蓋率, 以程序內(nèi)在邏輯結(jié)構(gòu)為基礎(chǔ)的測試。包括 以下 6 種類型： 13 語句覆蓋

18、 判斷覆蓋 條件覆蓋 判定-條件覆蓋 條件組合覆蓋 路徑覆蓋 白盒測試的主要目的 保證一個(gè)模塊中的所有獨(dú)立路徑至少被執(zhí)行一次； 對所有的邏輯值均需要測試真、假兩個(gè)分支； 在上下邊界及可操作范圍內(nèi)運(yùn)行所有循環(huán)； 檢查內(nèi)部數(shù)據(jù)結(jié)構(gòu)以確保其有效性 白盒測試的實(shí)施方案 在開發(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ù)性、可靠性 以及可移植性等。 在測試階段 與軟件產(chǎn)品的開發(fā)過程一樣, 測試過程也需要有一定的

19、準(zhǔn)則, 來指導(dǎo)、度量、評價(jià)軟件測試過程的質(zhì)量。 定義測試準(zhǔn)則 14 為控制測試的有效性以及完成程度, 必須定義準(zhǔn)則和策略, 以 判斷何時(shí)結(jié)束測試階段。準(zhǔn)則必須是客觀的, 可量化的元素, 而不 能是經(jīng)驗(yàn)或感覺。 根據(jù)應(yīng)用的準(zhǔn)則和項(xiàng)目相關(guān)的約束, 項(xiàng)目領(lǐng)導(dǎo)可以定義使用的 度量方法, 和要達(dá)到的覆蓋率。 度量測試的有效性、完整性 對每個(gè)測試的測試覆蓋信息和累計(jì)信息, 用圖形方式顯示 覆蓋比率, 并根據(jù)測試運(yùn)行情況實(shí)時(shí)更新, 隨時(shí)顯示新的測試所反 映的測試覆蓋情況。 允許所有的測試運(yùn)行依據(jù)其有效性進(jìn)行管理, 用戶可以減 少不適用于非回歸測試的測試的過程。 概念： 1.語句覆蓋：語句覆蓋就是設(shè)計(jì)若干個(gè)測

20、試用例, 運(yùn)行被測試 程序, 使得每一條可執(zhí)行語句至少執(zhí)行一次； 2.判定覆蓋（也稱為分支覆蓋）：設(shè)計(jì)若干個(gè)測試用例, 運(yùn)行 所測程序, 使程序中每個(gè)判斷的取真分支和取假分支至少執(zhí)行一次； 3.條件覆蓋：設(shè)計(jì)足夠多的測試用例, 運(yùn)行所測程序, 使程序 中每個(gè)判斷的每個(gè)條件的每個(gè)可能取值至少執(zhí)行一次； 4.判定-條件覆蓋：設(shè)計(jì)足夠多的測試用例, 運(yùn)行所測程序, 使 程序中每個(gè)判斷的每個(gè)條件的所有可能取值至少執(zhí)行一次, 并且每 個(gè)可能的判斷結(jié)果也至少執(zhí)行一次, 換句話說, 即是要求各個(gè)判斷 的所有可能的條件取值組合至少執(zhí)行一次； 15 5.條件組合測試：設(shè)計(jì)足夠多的測試用例, 運(yùn)行所測程序, 使

21、程序中每個(gè)判斷的所有可能的條件取值組合至少執(zhí)行一次； 6.路徑測試：設(shè)計(jì)足夠多的測試用例, 運(yùn)行所測程序, 要覆蓋 程序中所有可能的路徑。 5.4 靜態(tài)測試 是指不實(shí)際運(yùn)行被測軟件, 而只是靜態(tài)的檢查程序代碼、界面 或文檔中可能存在的錯(cuò)誤的過程。 其中包括代碼測試、界面測試和文檔測試 3 個(gè)方面。對于代碼 測試, 主要測試代碼是否符合相應(yīng)的標(biāo)準(zhǔn)和規(guī)范。對于界面測試, 主要測試軟件的實(shí)際界面與需求中的說明是否相符。對于文檔測試, 主要測試用戶手冊和需求說明是否符合用戶的實(shí)際要求。 5.5 動態(tài)測試 是指實(shí)際運(yùn)行被測程序, 輸入相應(yīng)的測試數(shù)據(jù), 檢查實(shí)際輸出 結(jié)果和預(yù)期結(jié)果是否相符的過程。所以,

22、我們判斷一個(gè)測試屬于動 態(tài)還是靜態(tài)測試 , 唯一的標(biāo)準(zhǔn)就是看是否運(yùn)行程序。 6 6 軟件測試中的類測試軟件測試中的類測試 6.1面向?qū)ο筌浖暮暧^上來看是各個(gè)類之間的相互作用。在 16 面向?qū)ο笙到y(tǒng)中,系統(tǒng)的基本構(gòu)造模塊是封裝了的數(shù)據(jù)和方法的類和 對象,而不再是一個(gè)個(gè)能完成特定功能的功能模塊。每個(gè)對象有自己 的生存周期,有自己的狀態(tài)。消息是對象之間相互請求或協(xié)作的途徑, 是外界使用對象方法及獲取對象狀態(tài)的唯一方式。對象的功能是在 消息的觸發(fā)下,由對象所屬類中定義的方法與相關(guān)對象的合作共同完 成,且在不同狀態(tài)下對消息的響應(yīng)可能完全不同。對象中的數(shù)據(jù)和方 法是一個(gè)有機(jī)的整體,測試過程中不能僅僅檢查

23、輸入數(shù)據(jù)產(chǎn)生的輸出 結(jié)果是否與預(yù)期的吻合,還要考慮對象的狀態(tài)。模塊測試的概念已不 適用于對象的測試“類測試將是整個(gè)測試過程的一個(gè)重要步驟。 6.2 類測試技術(shù) 6.2.1 基于服務(wù)的類測試技術(shù) 基于服務(wù)的類測試主要考察封裝在類中的一個(gè)方法對數(shù)據(jù)進(jìn)行 的操作，它可以采用傳統(tǒng)的白盒測試方法。為克服軟件測試的盲目 性和局限性,保證測試的質(zhì)量,提高軟件的可靠性,下面我們介紹一種 類的服務(wù)的測試模型及相應(yīng)的測試策略。 BBD 通常有兩種獲取途徑。一是采用逆向工程的方法根 據(jù)源程序畫出流程圖,然后構(gòu)造出 BBD。但這畢竟是在缺少軟件開發(fā) 前期的分析、設(shè)計(jì)文檔或文檔不齊全的情況下退而求其次的辦法。 當(dāng)源程序

24、不正確時(shí)構(gòu)造出來的 BBD 就是錯(cuò)誤的。另一種途徑就是追 根溯源,在軟件的分析、設(shè)計(jì)階段就根據(jù)測試的需要構(gòu)造出相應(yīng)的 BBD。這樣就能從根本上解決問題,正確地指導(dǎo)類的服務(wù)的測試。 17 6.2.2 基于層次增量的類測試 層次增量測試的基本思想是:首先分別測試父類的各個(gè)成員函 數(shù),再測試成員函數(shù)間的相互作用,把測試用例和執(zhí)行信息保存在/測 試歷史中,在測試子類時(shí),根據(jù)父類的測試歷史修改部分的定義以及實(shí) 現(xiàn)語言的繼承映射來決定子類中的哪些特征應(yīng)當(dāng)重測試以及父類的 哪些測試用例可以復(fù)用。 這種根據(jù)類間繼承關(guān)系的層次特性對類進(jìn)行增量測試的技術(shù)是 由 M. Harrold 等人提出的,其特點(diǎn)是復(fù)用父類的測試信息來指導(dǎo)子類 的測試。 7 參考文獻(xiàn)參考文獻(xiàn)