軟件工程第8章軟件測試.ppt

第八章 8 軟件測試 本章內(nèi)容 8 1軟件測試背景8 2軟件測試的基本概念8 3測試用例的設(shè)計8 4軟件測試過程 8 1軟件測試背景 8 1 1軟件缺陷與故障案例軟件缺陷的定義軟件缺陷的特征8 1 2軟件缺陷產(chǎn)生的原因 8 1 1軟件缺陷與故障 1 軟件缺陷和軟件故障案例案例1美國迪斯尼公司的獅子王游戲軟件bug兼容性問題案例2美國航天局火星登陸事故系統(tǒng)測試銜接問題案例3跨世紀(jì) 千年蟲 問題案例4愛國者導(dǎo)彈防御系統(tǒng)炸死自家人系統(tǒng)時鐘誤差積累案例5英特爾奔騰浮點除法上述所有實例中的軟件問題在軟件工程或軟件測試中都被稱為軟件缺陷或軟件故障 軟件是復(fù)雜的 知識高度密集的邏輯產(chǎn)品 因此軟件錯誤防不勝防 對于規(guī)模大 復(fù)雜性高的軟件更是如此 這些錯誤中 有些神之石致命的 若不排除 會導(dǎo)致財產(chǎn)以及生命的重大損失 1963年美國飛往火星的火箭爆炸 造成1000萬美元的損失 原因是FORTRAN程序 DO5I 1 3誤寫為 DO5I 1 3 1967年蘇聯(lián) 聯(lián)盟一號 載人宇宙飛船在返航時 由于軟件忽略一個小數(shù)點 導(dǎo)至在進入大氣層時因打不開降落傘而燒毀 軟件危機 軟件缺陷與故障 續(xù) 2 軟件缺陷的定義 1 軟件未達到產(chǎn)品說明書中已經(jīng)標(biāo)明的功能 2 軟件出現(xiàn)了產(chǎn)品說明書中指明不會出現(xiàn)的錯誤 3 軟件未達到產(chǎn)品說明書中雖未指出但應(yīng)當(dāng)達到的目標(biāo) 4 軟件功能超出了產(chǎn)品說明書中指明的范圍 5 軟件測試人員認(rèn)為軟件難以理解 不易使用 或者最終用戶認(rèn)為該軟件使用效果不良 軟件缺陷與故障 續(xù) 3 軟件缺陷的特征 看不到 軟件的特殊性決定了缺陷不易看到 看到但是抓不到 發(fā)現(xiàn)了缺陷 但不易找到問題發(fā)生的原因所在 8 1 2軟件缺陷產(chǎn)生的原因 軟件缺陷的主要類型 現(xiàn)象 功能 特性沒有實現(xiàn)或部分實現(xiàn)設(shè)計不合理 存在缺陷實際結(jié)果和預(yù)期結(jié)果不一致運行出錯 包括運行中斷 系統(tǒng)崩潰 界面混亂數(shù)據(jù)結(jié)果不正確 精度不夠用戶不能接受的其他問題 如存取時間過長 界面不美觀 常見導(dǎo)致錯誤的根源 缺乏有效的溝通 或者沒有進行溝通 軟件復(fù)雜度不斷變更的需求時間的壓力缺乏文檔的代碼軟件開發(fā)工具 圖8 1軟件缺陷產(chǎn)生的原因分布 軟件缺陷產(chǎn)生的原因有很多 但最主要的原因要歸咎于產(chǎn)品描述 軟件測試的復(fù)雜性分析 續(xù) 8 2軟件測試基礎(chǔ)概念 8 2 1軟件測試的定義8 2 2軟件測試的基本概念8 2 3軟件測試方法與策略 8 2 1軟件測試定義 軟件測試是一個貫徹于軟件開發(fā)過程始終的過程 是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程 是根據(jù)軟件開發(fā)各階段的規(guī)格說明和程序的內(nèi)部結(jié)構(gòu)結(jié)構(gòu)而精心設(shè)計一批測試用例 什么是軟件測試 使用人工或者自動手段來運行或測定某個系統(tǒng)的過程目的在于檢驗它是否滿足規(guī)定的需求 弄清預(yù)期結(jié)果與實際結(jié)果之間的差別可簡述為 按照特定規(guī)程 發(fā)現(xiàn)軟件錯誤的過程 軟件測試定義 續(xù) 1 軟件測試的目的 軟件測試的目標(biāo)是以最少的時間和人力 系統(tǒng)的找出軟件中潛在的各種錯誤和缺陷測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程好的測試方案 測試用例 在于盡可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試 8 2 2軟件測試基本概念 軟件測試目的 續(xù) 測試并不僅僅是為了找出錯誤 通過分析錯誤產(chǎn)生的原因和錯誤的發(fā)生趨勢 可以幫助項目管理者發(fā)現(xiàn)當(dāng)前軟件開發(fā)過程中的缺陷 以便及時改進 這種分析也能幫助測試人員設(shè)計出有針對性的測試方法 改善測試的效率和有效性 沒有發(fā)現(xiàn)錯誤的測試也是有價值的 完整的測試是評定軟件質(zhì)量的一種方法 軟件測試員的目標(biāo) 發(fā)現(xiàn)軟件缺陷 2 軟件測試的目標(biāo) 最終目的是確保軟件的功能符合用戶的需求 把盡可能多的問題在發(fā)布或交付前發(fā)現(xiàn)并改正 確保軟件完成了它所承諾或公布的功能 缺少規(guī)范的書面文檔 確保軟件滿足性能的要求 界面 操作 性能 確保軟件是健壯的和適應(yīng)用戶環(huán)境的 哪怕不健壯 也要給出解決方案 2 軟件測試的目標(biāo) 為軟件的質(zhì)量評估提供依據(jù) 項目驗收 為軟件質(zhì)量改進和管理提供幫助 經(jīng)驗教訓(xùn)等知識轉(zhuǎn)移 軟件測試的生命周期 3 軟件測試的特性 軟件測試與分析 設(shè)計 編碼等工作相比 具有若干特殊的性質(zhì) 挑剔性 測試是一種 挑剔性 行為 以證明程序有錯的目的去進行測試 才能把程序中潛在的錯誤找出來 復(fù)雜性 設(shè)計測試用例是一項需要細(xì)致和高度技巧的工作 不徹底性 測試只能證明軟件中存在錯誤 不能證明軟件中不存在錯誤所謂徹底測試 也就是窮舉測試 顯然在實際測試中無法實現(xiàn)或行不通 經(jīng)濟性 降低測試成本 應(yīng)遵守的經(jīng)濟性原則 一 根據(jù)程序的重要性和一旦發(fā)生故障將造成的損失來確定他的可靠性等級 不要隨意提高等級使測試成本增加 二 要認(rèn)真研究測試策略 以便使用盡可能少的測試用例來發(fā)現(xiàn)盡可能多的程序錯誤 為保證測試質(zhì)量 軟件測試必須完成規(guī)定的文檔 按照軟件工程的要求 測試文檔應(yīng)包括測試計劃和測試報告兩方面內(nèi)容 測試計劃的主體是 測試內(nèi)容說明 它包括測試項目名稱 各項測試的目的 步驟和進度 以及測試用例的設(shè)計等 測試報告的主體是 測試結(jié)果 它包括測試項目名稱 實測結(jié)果與期望結(jié)果的比較 發(fā)現(xiàn)的問題 以及測試達到的效果 4 軟件測試的文檔 測試用例 測試數(shù)據(jù) 期望結(jié)果 測試結(jié)果 測試數(shù)據(jù) 期望結(jié)果 實際結(jié)果 軟件測試國家標(biāo)準(zhǔn) GB T9386 1988 計算機軟件測試文件編制規(guī)范 GB T15532 1995 計算機軟件單元測試規(guī)范 GB T17544 1998 信息技術(shù)軟件包質(zhì)量要求和測試 GB T16260 1 2003 軟件工程產(chǎn)品質(zhì)量 第1部份 質(zhì)量模型GB T16260 2 200X 軟件工程產(chǎn)品質(zhì)量 第2部份 外部度量GB T16260 3 200X 軟件工程產(chǎn)品質(zhì)量 第3部份 內(nèi)部度量GB T16260 4 200X 軟件工程產(chǎn)品質(zhì)量 第4部份 使用質(zhì)量度量GB T18905 1 2002 軟件工程產(chǎn)品質(zhì)量 第1部份 概述GB T18905 2 2002 軟件工程產(chǎn)品質(zhì)量 第2部份 策劃和管理GB T18905 3 2002 軟件工程產(chǎn)品質(zhì)量 第3部份 開發(fā)者用的過程GB T18905 4 2002 軟件工程產(chǎn)品質(zhì)量 第4部份 需方用的過程GB T18905 5 2002 軟件工程產(chǎn)品質(zhì)量 第5部份 評價者用的過程GB T18905 6 2002 軟件工程產(chǎn)品質(zhì)量 第6部份 評價模塊文檔編寫 國標(biāo)來自的國際標(biāo) GB T16260 1 6取自ISO IEC9126 1 2001ISO IEC9126 2 2003ISO IEC9126 3 2003ISO IECTR9126 4 2004GB T18905 1 6取自ISO IEC14598 1 1999ISO IEC14598 2 2000ISO IEC14598 3 2000ISO IEC14598 4 1999ISO IEC14598 5 1998ISO IEC14598 6 2001GB T17544 1998取自ISO IEC12119 1994 5 軟件測試的原則 Good enough 一種權(quán)衡投入 產(chǎn)出比的原則 選擇測試保證測試的覆蓋程度 但窮舉測試是不可能的 有限測試所有的測試都應(yīng)追溯到用戶需求越早測試越好 測試過程與開發(fā)過程應(yīng)是相結(jié)合的測試的規(guī)模由小而大 從單元測試到系統(tǒng)測試為了盡可能地發(fā)現(xiàn)錯誤 應(yīng)該由獨立的第三方來測試不能為了便于測試擅自修改程序既應(yīng)該測試軟件該做什么也應(yīng)該測試軟件不該做什么 傳統(tǒng)的瀑布模型中軟件測試學(xué)僅處于運行維護階段之前 項目規(guī)劃階段 負(fù)責(zé)從單元測試到系統(tǒng)測試的整個測試階段的監(jiān)控 需求分析階段 確定測試需求分析 系統(tǒng)測試計劃的制定 評審后成為管理項目 詳細(xì)設(shè)計和概要設(shè)計階段 確保集成測試計劃和單元測試計劃完成 編碼階段 由開發(fā)人員進行自己負(fù)責(zé)部分的測試代碼 在項目較大時 由專人進行編碼階段的測試任務(wù) 測試階段 依據(jù)測試代碼進行測試 并提交相應(yīng)的測試狀態(tài)報告和測試結(jié)束報告 6 測試在開發(fā)各階段的作用 圖8 2完整的開發(fā)流程 7 完整的軟件開發(fā)流程 8 軟件測試和缺陷修復(fù)的代價 軟件在從需求 設(shè)計 編碼 測試一直到交付用戶公開使用后的過程中 都有可能產(chǎn)生和發(fā)現(xiàn)缺陷 隨著整個開發(fā)過程的時間推移 更正缺陷或修復(fù)問題的費用呈幾何級數(shù)增長 圖8 3軟件缺陷在不同階段發(fā)現(xiàn)時修復(fù)的費用示意圖 軟件測試是有風(fēng)險的行為 如果決定不去測試所有的情況 那就是選擇了風(fēng)險 軟件缺陷的寄生蟲性 找到的軟件缺陷越多 就說明軟件缺陷越多 原因 程序員的疲倦程序員往往犯同樣的錯誤某些軟件的缺陷其實是大災(zāi)難的征兆 軟件測試的殺蟲劑現(xiàn)象 軟件測試越多 其免疫力越強的現(xiàn)象 克服方法 不斷編寫不同的新的測試程序?qū)Τ绦虻牟煌糠诌M行測試 軟件測試的不修復(fù)原則 并非所有軟件缺陷都能修復(fù) 不需要修復(fù)軟件缺陷的原因 沒有足夠的時間不算真正的軟件缺陷修復(fù)的風(fēng)險太大不值得修復(fù) Pareto原則 Pareto原則暗示著測試發(fā)現(xiàn)的錯誤中的80 很可能起源于程序模塊中的20 軟件測試中的誤區(qū) 調(diào)試和測試是一樣的 測試組應(yīng)當(dāng)為保證質(zhì)量負(fù)責(zé) 把測試作為新員工的一個過渡工作 關(guān)注測試的執(zhí)行而忽略測試的設(shè)計 測試自動化是萬能的 測試是枯燥乏味 缺乏創(chuàng)造力的工作 8 2 3軟件測試方法與策略 軟件測試策略軟件測試方法測試關(guān)鍵詞靜態(tài)測試與動態(tài)測試白盒測試與黑盒測試軟件測試模型 軟件測試策略 什么是軟件測試策略 是為軟件工程過程定義的一個軟件測試的模板 也就是把特定的測試用例方法放置進去的一系列步驟 軟件測試策略包含的特征 1 測試從模塊層開始 然后擴大延伸到整個基于計算機的系統(tǒng)集合中 2 不同的測試技術(shù)適用于不同的時間點 3 測試是由軟件的開發(fā)人員和 對于大型系統(tǒng)而言 獨立的測試組來管理的 4 測試和調(diào)試是不同的活動 但是調(diào)試必須能夠適應(yīng)任何的測試策略 軟件測試策略 測試信息流分析設(shè)計階段需求說明書評測概要設(shè)計說明書評測詳細(xì)設(shè)計說明書評測軟件編碼規(guī)范評測開發(fā)階段單元測試集成測試確認(rèn)測試系統(tǒng)測試驗收測試軟件驗證和確認(rèn)過程 軟件測試關(guān)鍵詞 單元測試集成測試系統(tǒng)測試確認(rèn)測試驗收測試白盒測試黑盒測試灰盒測試 單元測試 單元測試又稱模塊測試是針對軟件設(shè)計的最小單元 程序模塊進行正確性檢驗的測試工作其目的在于檢查每個程序單元能否實現(xiàn)詳細(xì)設(shè)計說明中的模塊功能 性能 接口和設(shè)計約束等要求 發(fā)現(xiàn)各模塊內(nèi)部可能存在的錯誤 集成測試 集成測試 也叫組裝測試或聯(lián)合測試在單元測試的基礎(chǔ)上 將所有模塊按照設(shè)計要求 如根據(jù)結(jié)構(gòu)圖 組裝成為子系統(tǒng)或系統(tǒng) 進行集成測試集成測試是檢驗程序單元和部件的接口關(guān)系實踐表明 一些模塊雖然能夠單獨地工作 但并不能保證連接起來也能正常的工作 程序在某些局部反映不出來的問題 在全局上很可能暴露出來 影響功能的實現(xiàn) 系統(tǒng)測試 系統(tǒng)測試是將已經(jīng)確認(rèn)的軟件 計算機硬件 外設(shè) 網(wǎng)絡(luò)等其他元素結(jié)合在一起 進行信息系統(tǒng)的各種組裝測試和確認(rèn)測試 其目的是通過與系統(tǒng)的需求相比較 發(fā)現(xiàn)所開發(fā)的系統(tǒng)與用戶需求不符或矛盾的地方系統(tǒng)測試的任務(wù)是近可能徹底的檢查出程序中的錯誤 提高軟件系統(tǒng)的可靠性 其目的是檢驗系統(tǒng) 做得怎樣 確認(rèn)測試 確認(rèn)測試的目的是向未來的用戶表明系統(tǒng)能夠像預(yù)定要求那樣工作 經(jīng)集成測試后 已經(jīng)按照設(shè)計把所有的模塊組裝成一個完整的軟件系統(tǒng) 接口錯誤也已經(jīng)基本排除了 接著就應(yīng)該進一步驗證軟件的有效性 這就是確認(rèn)測試的任務(wù) 即軟件的功能和性能如同用戶所合理期待的那樣確認(rèn)測試又稱有效性測試 有效性測試是在模擬的環(huán)境下 運用黑盒測試的方法 驗證被測軟件是否滿足需求規(guī)格說明書列出的需求 任務(wù)是驗證軟件的功能和性能及其他特性是否與用戶的要求一致 對軟件的功能和性能要求在軟件需求規(guī)格說明書中已經(jīng)明確規(guī)定 它包含的信息就是軟件確認(rèn)測試的基礎(chǔ) 驗收測試 系統(tǒng)開發(fā)生命周期方法論的一個階段 這時相關(guān)的用戶和 或獨立測試人員根據(jù)測試計劃和結(jié)果對系統(tǒng)進行測試和接收 它讓系統(tǒng)用戶決定是否接收系統(tǒng) 它是一項確定產(chǎn)品是否能夠滿足合同或用戶所規(guī)定需求的測試這是管理性和防御性控制的測試過程 白盒測試 白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試 它是按照程序內(nèi)部的結(jié)構(gòu)測試程序 通過測試來檢測產(chǎn)品內(nèi)部動作是否按照設(shè)計規(guī)格說明書的規(guī)定正常進行 檢驗程序中的每條通路是否都能按預(yù)定要求正確工作是把測試對象看作一個打開的盒子 測試人員依據(jù)程序內(nèi)部邏輯結(jié)構(gòu)相關(guān)信息 設(shè)計或選擇測試用例 對程序所有邏輯路徑進行測試 通過在不同點檢查程序的狀態(tài) 確定實際的狀態(tài)是否與預(yù)期的狀態(tài)一致 黑盒測試 黑盒測試也稱功能測試 它是通過測試來檢測每個功能是否都能正常使用 在測試地 把程序看作一個不能打開的黑盒子 在完全不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下 在程序接口進行測試 它只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用 程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息 黑盒測試著眼于程序外部結(jié)構(gòu) 不考慮內(nèi)部邏輯結(jié)構(gòu) 主要針對軟件界面和軟件功能進行測試 灰盒測試 灰盒測試 確實是介于白盒測試與黑盒測試之間的測試灰盒測試關(guān)注輸出對于輸入的正確性 同時也關(guān)注內(nèi)部表現(xiàn) 但這種關(guān)注不象白盒那樣詳細(xì) 完整 只是通過一些表征性的現(xiàn)象 事件 標(biāo)志來判斷內(nèi)部的運行狀態(tài) 有時候輸出是正確的 但內(nèi)部其實已經(jīng)錯誤了 這種情況非常多 如果每次都通過白盒測試來操作 效率會很低 因此需要采取這樣的一種灰盒的方法 軟件測試技術(shù)的發(fā)展趨勢 1 軟件驗證技術(shù) 2 靜態(tài)測試分析技術(shù) 3 測試數(shù)據(jù)的選擇 主要對測試用例進行選擇通常從下面幾個方面評價測試用例的質(zhì)量 檢測軟件缺陷的有效性 測試用例的可重用性 測試用例的經(jīng)濟性 測試用例的可維護性 4 集成化測試 研究如何實現(xiàn)軟件測試的自動化過程以及相關(guān)的一系列內(nèi)容 軟件測試方法的分類 按照軟件測試用例的設(shè)計方法而論 軟件測試可分為白盒測試法和黑盒測試法 按照軟件測試是否執(zhí)行程序而論 軟件測試又可以分為靜態(tài)測試和動態(tài)測試 按照軟件設(shè)計方法是否采用面向?qū)ο笤O(shè)計技術(shù)而論 軟件測試又可以分為傳統(tǒng)測試方法和面向?qū)ο鬁y試方法 按照網(wǎng)絡(luò)環(huán)境下C S應(yīng)用結(jié)構(gòu)的特定環(huán)境而論 軟件測試又有其相應(yīng)的方法 這些都是軟件測試具體的測試方法 靜態(tài)測試與動態(tài)測試 1 靜態(tài)測試靜態(tài)測試不實際運行軟件 主要是對軟件的編程格式 結(jié)構(gòu)等方面進行評估 靜態(tài)測試包括代碼檢查 靜態(tài)結(jié)構(gòu)分析 代碼質(zhì)量度量等 它可以由人工進行 也可以借助軟件工具自動進行 靜態(tài)測試方法也可利用計算機作為對被測程序進行特性分析的工具 但與人工測試方式有著根本區(qū)別 另一方面 因它并不真正運行被測程序 只進行特性分析 這又與動態(tài)方法不同 所以 靜態(tài)方法常常稱為 分析 靜態(tài)測試是對被測程序進行特性分析方法的總稱 靜態(tài)測試與動態(tài)測試 續(xù) 代碼檢查代碼檢查包括代碼走查 桌面檢查 代碼審查等 主要檢查代碼和設(shè)計的一致性 代碼對標(biāo)準(zhǔn)的遵循 可讀性 代碼的邏輯表達的正確性 代碼結(jié)構(gòu)的合理性等方面 代碼檢查的具體內(nèi)容 變量檢查 命名和類型審查 程序邏輯審查 程序語法檢查和程序結(jié)構(gòu)檢查等 代碼檢查的優(yōu)點 在實際使用中 代碼檢查比動態(tài)測試更有效率 能快速找到缺陷 發(fā)現(xiàn)30 70 的邏輯設(shè)計和編碼缺陷 代碼檢查看到的是問題本身而非征兆 代碼檢查的缺點 非常耗費時間 而且代碼檢查需要知識和經(jīng)驗的積累 靜態(tài)測試與動態(tài)測試 續(xù) 靜態(tài)結(jié)構(gòu)分析靜態(tài)結(jié)構(gòu)分析主要是以圖形的方式表現(xiàn)程序的內(nèi)部結(jié)構(gòu) 例如函數(shù)調(diào)用關(guān)系圖 函數(shù)內(nèi)部控制流圖 其中 函數(shù)調(diào)用關(guān)系圖以直觀的圖形方式描述一個應(yīng)用程序中各個函數(shù)的調(diào)用和被調(diào)用關(guān)系 控制流圖顯示一個函數(shù)的邏輯結(jié)構(gòu) 由許多節(jié)點組成 一個節(jié)點代表一條語句或數(shù)條語句 連接結(jié)點的叫邊 邊表示節(jié)點間的控制流向 靜態(tài)測試與動態(tài)測試 續(xù) 代碼質(zhì)量度量軟件質(zhì)量包括六個方面 功能性 可靠性 易用性 效率 可維護性和可移植性 軟件的質(zhì)量是軟件屬性的各種標(biāo)準(zhǔn)度量的組合 針對軟件的可維護性 目前業(yè)界主要存在三種度量參數(shù) Line復(fù)雜度 Halstead復(fù)雜度和McCabe復(fù)雜度 其中Line復(fù)雜度以代碼的行數(shù)作為計算的基準(zhǔn) Halstead以程序中使用到的運算符與運算元數(shù)量作為計數(shù)目標(biāo) 直接測量指標(biāo) 然后可以據(jù)以計算出程序容量 工作量等 McCabe復(fù)雜度一般稱為圈復(fù)雜度 它將軟件的流程圖轉(zhuǎn)化為有向圖 然后以圖論來衡量軟件的質(zhì)量 靜態(tài)測試與動態(tài)測試 續(xù) 靜態(tài)測試階段的任務(wù) 1 檢查算法的邏輯正確性 2 檢查模塊接口的正確性 3 檢查輸入?yún)?shù)是否有合法性檢查 4 檢查調(diào)用其他模塊的接口是否正確 5 檢查是否設(shè)置了適當(dāng)?shù)某鲥e處理 6 檢查表達式 語句是否正確 是否含有二義性 7 檢查常量或全局變量使用是否正確 8 檢查標(biāo)識符的使用是否規(guī)范 一致 9 檢查程序風(fēng)格的一致性 規(guī)范性 10 檢查代碼是否可以優(yōu)化 算法效率是否最高 11 檢查代碼注釋是否完整 是否正確反映了代碼的功能 靜態(tài)測試與動態(tài)測試 續(xù) 靜態(tài)測試可以完成以下工作 1 發(fā)現(xiàn)下列程序的錯誤 錯用局部變量和全局變量 未定義的變量 不匹配的參數(shù) 不適當(dāng)?shù)难h(huán)嵌套或分支嵌套 死循環(huán) 不允許的遞歸 調(diào)用不存在的子程序 遺漏標(biāo)號或代碼 2 找出以下問題的根源 從未使用過的變量 不會執(zhí)行到的代碼 從未使用過的標(biāo)號 潛在的死循環(huán) 3 提供程序缺陷的間接信息 所用變量和常量的交叉應(yīng)用表 是否違背編碼規(guī)則 標(biāo)識符的使用方法和過程的調(diào)用層次 4 為進一步查找做好準(zhǔn)備 5 選擇測試用例 6 進行符號測試 靜態(tài)測試與動態(tài)測試 續(xù) 2 動態(tài)測試動態(tài)方法的主要特征是 計算機必須真正運行被測試的程序 通過輸入測試用例 對其運行情況即輸入與輸出的對應(yīng)關(guān)系進行分析 以達到檢測的目的 動態(tài)測試包括 1 功能確認(rèn)與接口測試 2 覆蓋率分析 3 性能分析 4 內(nèi)存分析 黑盒測試和白盒測試 若測試規(guī)劃是基于產(chǎn)品的功能 目的是檢查程序各個功能是否能夠?qū)崿F(xiàn) 并檢查其中的功能錯誤 則這種測試方法稱為黑盒測試 Black boxTesting 方法 黑盒測試又稱為功能測試 數(shù)據(jù)驅(qū)動測試和基于規(guī)格說明的測試 它是一種從用戶觀點出發(fā)的測試 一般被用來確認(rèn)軟件功能的正確性和可操作性 若測試規(guī)劃基于產(chǎn)品的內(nèi)部結(jié)構(gòu)進行測試 檢查內(nèi)部操作是否按規(guī)定執(zhí)行 軟件各個部分功能是否得到充分使用 則這種測試方法稱為白盒測試 White boxTesting 方法 白盒測試又稱為結(jié)構(gòu)測試 邏輯驅(qū)動測試或基于程序的測試 一般用來分析程序的內(nèi)部結(jié)構(gòu) 黑盒測試和白盒測試 續(xù) 兩種測試方法從完全不同的角度出發(fā) 反映了測試思路的兩方面情況 適用于不同的測試階段 黑盒測試和白盒測試 續(xù) 1 黑盒測試黑盒測試的基本觀點是 任何程序都可以看作是從輸入定義域映射到輸出值域的函數(shù)過程 被測程序被認(rèn)為是一個打不開的黑盒子 黑盒中的內(nèi)容 實現(xiàn)過程 完全不知道 只明確要做到什么 黑盒測試主要根據(jù)規(guī)格說明書設(shè)計測試用例 并不涉及程序內(nèi)部構(gòu)造和內(nèi)部特性 只依靠被測程序輸入和輸出之間的關(guān)系或程序的功能設(shè)計測試用例 黑盒測試的特點 1 黑盒測試與軟件的具體實現(xiàn)過程無關(guān) 在軟件實現(xiàn)的過程發(fā)生變化時 測試用例仍然可以使用 2 黑盒測試用例的設(shè)計可以和軟件實現(xiàn)同時進行 這樣能夠壓縮總的開發(fā)時間 黑盒測試和白盒測試 續(xù) 黑盒測試和白盒測試 續(xù) 黑盒測試主要是為了發(fā)現(xiàn)以下幾類錯誤 是否有不正確或遺漏了的功能 在接口上 輸入能否正確地接受 能否輸出正確的結(jié)果 是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息訪問錯誤 性能上是否能夠滿足要求 是否有初始化或終止性錯誤 黑盒測試的難點 在哪個層次上進行測試 黑盒測試的具體技術(shù)方法 邊界值分析法等價類劃分法因果圖法錯誤猜想法決策表法 黑盒測試和白盒測試 續(xù) 2 白盒測試白盒測試將被測程序看作一個打開的盒子 測試者能夠看到被測源程序 可以分析被測程序的內(nèi)部結(jié)構(gòu) 此時測試的焦點集中在根據(jù)其內(nèi)部結(jié)構(gòu)設(shè)計測試用例 白盒測試要求是對某些程序的結(jié)構(gòu)特性做到一定程度的覆蓋 或者說這種測試是 基于覆蓋率的測試 通常的程序結(jié)構(gòu)覆蓋有 語句覆蓋判定覆蓋條件覆蓋判定 條件覆蓋路徑覆蓋 黑盒測試和白盒測試 續(xù) 黑盒測試和白盒測試 續(xù) 3 黑盒測試法和白盒測試法的比較 黑盒測試和白盒測試 續(xù) 黑盒測試 以用戶的觀點 從輸入數(shù)據(jù)與輸出數(shù)據(jù)的對應(yīng)關(guān)系 即根據(jù)程序外部特性進行測試 而不考慮內(nèi)部結(jié)構(gòu)及工作情況 黑盒測試技術(shù)注重于軟件的信息域 范圍 通過劃分程序的輸入和輸出域來確定測試用例 若外部特性本身存在問題或規(guī)格說明的規(guī)定有誤 則應(yīng)用黑盒測試方法是不能發(fā)現(xiàn)問題的 白盒測試 只根據(jù)程序的內(nèi)部結(jié)構(gòu)進行測試 測試用例的設(shè)計要保證測試時程序的所有語句至少執(zhí)行一次 而且要檢查所有的邏輯條件 如果程序的結(jié)構(gòu)本身有問題 比如說程序邏輯有錯誤或者有遺漏 那也是無法發(fā)現(xiàn)的 黑盒測試和白盒測試 續(xù) 測試模型 V模型W模型H模型X模型 V模型圖 W模型圖 H模型圖 在整個生產(chǎn)周期中某個層次上的一次測試 微循環(huán) 圖中的其他流程圖可以是任意開發(fā)流程 例如 設(shè)計流程和編碼流程 也可以是其他非開發(fā)流程 例如 SQA流程 甚至是測試流程本身 只要測試條件成熟了 測試準(zhǔn)備活動完成了 測試執(zhí)行活動就可以進行了 X模型 X模型是由Marick提出的X模型描述的是針對單獨程序片段所進行的相互分離的編碼和測試 此后將進行頻繁的交換 通過集成最終合成為可執(zhí)行的程序 X模型是一種探索測試模型 X模型圖 8 3測試用例的設(shè)計 如何以最少的人力 資源投入 在最短的時間內(nèi)完成測試 發(fā)現(xiàn)軟件系統(tǒng)的缺陷 保證軟件的優(yōu)良品質(zhì) 則是軟件測試探索和追求的目標(biāo) 測試用例是測試工作的指導(dǎo) 是軟件測試的必須遵守的準(zhǔn)則 更是軟件測試質(zhì)量穩(wěn)定的根本保障 什么是測試用例 所謂的測試用例就是將軟件測試的行為活動 做一個科學(xué)化的組織歸納 軟件測試是有組織性 步驟性和計劃性的 而設(shè)計軟件測試用例的目的 就是為了能將軟件測試的行為轉(zhuǎn)換為可管理的模式 軟件測試是軟件質(zhì)量管理中最實際的行動 同時也是耗時最多的一項 基于時間因素的考慮 軟件測試行為必須能夠加以量化 才能進一步讓管理階層掌握所需要的測試過程 而測試用例就是將測試行為具體量化的方法之一 什么是測試用例 因為我們不可能進行窮舉測試 為了節(jié)省時間和資源 提高測試效率 必須要從數(shù)量極大的可用測試數(shù)據(jù)中精心挑選出具有代表性或特殊性的測試數(shù)據(jù)來進行測試 目前研究室測試過程中 所有的測試用例都放在 測試大綱 中 使用測試大綱的好處 保證測試功能不被遺漏 使得功能不被重復(fù)測試 合理安排測試人員 使得軟件測試不依賴于個人 測試用例內(nèi)容 實施一次測試而向被測系統(tǒng)提供的輸入數(shù)據(jù) 操作或各種環(huán)境設(shè)置 對交互式系統(tǒng) 軟件交互執(zhí)行過程的控制也是一種測試用例 測試用例的設(shè)計與生成是依據(jù)測試大綱對其中每個測試項目的進一步實例化 比如 對于一個輸入項的測試 應(yīng)當(dāng)設(shè)計一組測試數(shù)據(jù) 包括合法的 邊界的和非法的數(shù)據(jù)等 測試用例設(shè)計生成的基本準(zhǔn)則 測試用例的代表性 能夠代表并覆蓋各種合理的和不合理 合法的和非法的 邊界的和越界的 以及極限的輸入數(shù)據(jù) 操作和環(huán)境設(shè)置等 測試結(jié)果的可判定性 即測試執(zhí)行結(jié)果的正確性是可判定的 每一個測試用例都應(yīng)有相應(yīng)的期望結(jié)果 測試結(jié)果的可再現(xiàn)性 即對同樣的測試用例 系統(tǒng)的執(zhí)行結(jié)果應(yīng)當(dāng)是相同的 測試用例的特征 最有可能抓住錯誤的 不是重復(fù)的 多余的 一組相似測試用例中最有效的 不要太簡單 也不要太復(fù)雜 測試用例的組織和跟蹤 在執(zhí)行測試過程中 會遇到如下問題 計劃執(zhí)行哪些測試用例 執(zhí)行需要多少時間 一輪測試需要多少測試人員 能否挑出測試套裝 相關(guān)測試用例子集 來測試某些特性或軟件部分 在執(zhí)行測試用例時 能否記錄哪些通過 哪些失敗 當(dāng)前測試是否按計劃進行 上次執(zhí)行測試用例時通過的百分比是多少 測試用例跟蹤管理方式 測試用例追蹤表 測試用例的意義 使用測試用例的好處主要體現(xiàn)在以下幾個方面 在開始實施測試之前設(shè)計好測試用例 可以避免盲目測試并提高測試效率 測試用例的使用令軟件測試的實施重點突出 目的明確 在軟件版本更新后只需修正少部分的測試用例便可展開測試工作 降低工作強度 縮短項目周期 功能模塊的通用化和復(fù)用化使軟件易于開發(fā) 而相對于功能模塊的測試用例的通用化和復(fù)用化則會使軟件測試易于開展 并隨著測試用例的不斷精化其效率也不斷攀升 測試用例的意義 組織性 有利于測試的組織 功能覆蓋 確保功能不被遺漏 重復(fù)性 有利于測試的重復(fù) 跟蹤 有利于測試的跟蹤 測試確認(rèn) 在少數(shù)高風(fēng)險的測試中 必須證明確實執(zhí)行了計劃執(zhí)行的測試 8 3 1白盒測試方法 為什么要進行白盒測試 如果所有軟件錯誤的根源都可以追溯到某個唯一原因 那么問題就簡單了 然而 事實上一個bug常常是由多個因素共同導(dǎo)致的 如下圖所示 假設(shè)此時開發(fā)工作已結(jié)束 程序送交到測試組 沒有人知道代碼中有一個潛在的被0除的錯誤 若測試組采用的測試用例的執(zhí)行路徑?jīng)]有同時經(jīng)過x 0和y 5 x進行測試 顯然測試工作似乎非常完善 測試用例覆蓋了所有執(zhí)行語句 也沒有被0除的錯誤發(fā)生 白盒測試方法 續(xù) 白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試 是針對被測單元內(nèi)部是如何進行工作的測試 它根據(jù)程序的控制結(jié)構(gòu)設(shè)計測試用例 主要用于軟件或程序驗證 白盒測試法檢查程序內(nèi)部邏輯結(jié)構(gòu) 對所有邏輯路徑進行測試 是一種窮舉路徑的測試方法 但即使每條路徑都測試過了 仍然可能存在錯誤 因為 窮舉路徑測試無法檢查出程序本身是否違反了設(shè)計規(guī)范 即程序是否是一個錯誤的程序 窮舉路徑測試不可能查出程序因為遺漏路徑而出錯 窮舉路徑測試發(fā)現(xiàn)不了一些與數(shù)據(jù)相關(guān)的錯誤 白盒測試方法 續(xù) 采用白盒測試方法必須遵循以下幾條原則 才能達到測試的目的 保證一個模塊中的所有獨立路徑至少被測試一次 所有邏輯值均需測試真 true 和假 false 兩種情況 檢查程序的內(nèi)部數(shù)據(jù)結(jié)構(gòu) 保證其結(jié)構(gòu)的有效性 在上下邊界及可操作范圍內(nèi)運行所有循環(huán) 白盒測試主要是檢查程序的內(nèi)部結(jié)構(gòu) 邏輯 循環(huán)和路徑 常用測試用例設(shè)計方法有 邏輯覆蓋法 邏輯驅(qū)動測試 基本路徑測試方法 8 3 1 1白盒測試的基本概念 控制流圖環(huán)形復(fù)雜度圖矩陣 控制流圖 控制流圖 可簡稱流圖 是對程序流程圖進行簡化后得到的 它可以更加突出的表示程序控制流的結(jié)構(gòu) 控制流圖中包括兩種圖形符號 節(jié)點和控制流線 節(jié)點由帶標(biāo)號的圓圈表示 可代表一個或多個語句 一個處理框序列和一個條件判定框 假設(shè)不包含復(fù)合條件 控制流線由帶箭頭的弧或線表示 可稱為邊 它代表程序中的控制流 對于復(fù)合條件 則可將其分解為多個單個條件 并映射成控制流圖 常見結(jié)構(gòu)的控制流圖 常見結(jié)構(gòu)的控制流圖 其中 包含條件的節(jié)點被稱為判定節(jié)點 也叫謂詞節(jié)點 由判定節(jié)點發(fā)出的邊必須終止于某一個節(jié)點 由邊和節(jié)點所限定的范圍被稱為區(qū)域 環(huán)形復(fù)雜度 環(huán)形復(fù)雜度也稱為圈復(fù)雜度 它是一種為程序邏輯復(fù)雜度提供定量尺度的軟件度量 環(huán)形復(fù)雜度的應(yīng)用 可以將環(huán)形復(fù)雜度用于基本路徑方法 它可以提供 程序基本集的獨立路徑數(shù)量 確保所有語句至少執(zhí)行一次的測試數(shù)量的上界 獨立路徑是指程序中至少引入了一個新的處理語句集合或一個新條件的程序通路 采用流圖的術(shù)語 即獨立路徑必須至少包含一條在本次定義路徑之前不曾用過的邊 測試可以被設(shè)計為基本路徑集的執(zhí)行過程 但基本路徑集通常并不唯一 計算環(huán)形復(fù)雜度的方法 環(huán)形復(fù)雜度以圖論為基礎(chǔ) 為我們提供了非常有用的軟件度量 可用如下三種方法之一來計算環(huán)形復(fù)雜度 控制流圖中區(qū)域的數(shù)量對應(yīng)于環(huán)形復(fù)雜度 給定控制流圖G的環(huán)形復(fù)雜度 V G 定義為V G E N 2其中 E是控制流圖中邊的數(shù)量 N是控制流圖中的節(jié)點數(shù)量 給定控制流圖G的環(huán)形復(fù)雜度 V G 也可定義為V G P 1其中 P是控制流圖G中判定節(jié)點的數(shù)量 圖矩陣 圖矩陣是控制流圖的矩陣表示形式 圖矩陣是一個方形矩陣 其維數(shù)等于控制流圖的節(jié)點數(shù) 矩陣中的每列和每行都對應(yīng)于標(biāo)識的節(jié)點 矩陣元素對應(yīng)于節(jié)點間的邊 通常 控制流圖中的結(jié)點用數(shù)字標(biāo)識 邊則用字母標(biāo)識 如果在控制流圖中從第i個結(jié)點到第j個結(jié)點有一個標(biāo)識為x的邊相連接 則在對應(yīng)圖矩陣的第i行第j列有一個非空的元素x 8 3 1 2覆蓋測試 測試覆蓋率邏輯覆蓋法面向?qū)ο蟮母采w測試覆蓋準(zhǔn)則 測試覆蓋率 測試覆蓋率 用于確定測試所執(zhí)行到的覆蓋項的百分比 其中的覆蓋項是指作為測試基礎(chǔ)的一個入口或?qū)傩?比如語句 分支 條件等 測試覆蓋率可以表示出測試的充分性 在測試分析報告中可以作為量化指標(biāo)的依據(jù) 測試覆蓋率越高效果越好 但覆蓋率不是目標(biāo) 只是一種手段 測試覆蓋率包括功能點覆蓋率和結(jié)構(gòu)覆蓋率 功能點覆蓋率大致用于表示軟件已經(jīng)實現(xiàn)的功能與軟件需要實現(xiàn)的功能之間的比例關(guān)系 結(jié)構(gòu)覆蓋率包括語句覆蓋率 分支覆蓋率 循環(huán)覆蓋率 路徑覆蓋率等等 邏輯覆蓋法 根據(jù)覆蓋目標(biāo)的不同 邏輯覆蓋又可分為語句覆蓋 判定覆蓋 條件覆蓋 判定 條件覆蓋 組合覆蓋和路徑覆蓋 語句覆蓋 選擇足夠多的測試用例 使得程序中的每個可執(zhí)行語句至少執(zhí)行一次 判定覆蓋 通過執(zhí)行足夠的測試用例 使得程序中的每個判定至少都獲得一次 真 值和 假 值 也就是使程序中的每個取 真 分支和取 假 分支至少均經(jīng)歷一次 也稱為 分支覆蓋 條件覆蓋 設(shè)計足夠多的測試用例 使得程序中每個判定包含的每個條件的可能取值 真 假 都至少滿足一次 邏輯覆蓋法 續(xù) 判定 條件覆蓋 設(shè)計足夠多的測試用例 使得程序中每個判定包含的每個條件的所有情況 真 假 至少出現(xiàn)一次 并且每個判定本身的判定結(jié)果 真 假 也至少出現(xiàn)一次 滿足判定 條件覆蓋的測試用例一定同時滿足判定覆蓋和條件覆蓋 組合覆蓋 通過執(zhí)行足夠的測試用例 使得程序中每個判定的所有可能的條件取值組合都至少出現(xiàn)一次 滿足組合覆蓋的測試用例一定滿足判定覆蓋 條件覆蓋和判定 條件覆蓋 路徑覆蓋 設(shè)計足夠多的測試用例 要求覆蓋程序中所有可能的路徑 邏輯覆蓋法 續(xù) 邏輯覆蓋法 續(xù) voidDoWork intx inty intz intk 0 j 0 if x 3 語句塊3 邏輯覆蓋法 續(xù) 語句覆蓋 要實現(xiàn)DoWork函數(shù)的語句覆蓋 只需設(shè)計一個測試用例就可以覆蓋程序中的所有可執(zhí)行語句 測試用例輸入為 x 4 y 5 z 5 程序執(zhí)行的路徑是 abd分析 語句覆蓋可以保證程序中的每個語句都得到執(zhí)行 但發(fā)現(xiàn)不了判定中邏輯運算的錯誤 即它并不是一種充分的檢驗方法 例如在第一個判定 x 3 z 10 中把 錯誤的寫成了 這時仍使用該測試用例 則程序仍會按照流程圖上的路徑abd執(zhí)行 可以說語句覆蓋是最弱的邏輯覆蓋準(zhǔn)則 判定覆蓋 要實現(xiàn)DoWork函數(shù)的判定覆蓋 需要設(shè)計兩個測試用例 測試用例的輸入為 x 4 y 5 z 5 x 2 y 5 z 5 程序執(zhí)行的路徑分別是 abd ace分析 上述兩個測試用例不僅滿足了判定覆蓋 同時還做到語句覆蓋 從這點看似乎判定覆蓋比語句覆蓋更強一些 但仍然無法確定判定內(nèi)部條件的錯誤 例如把第二個判定中的條件y 5錯誤寫為y 5 使用上述測試用例 照樣能按原路徑執(zhí)行而不影響結(jié)果 因此 需要有更強的邏輯覆蓋準(zhǔn)則去檢驗判定內(nèi)的條件 判定覆蓋 續(xù) 說明 以上僅考慮了兩出口的判斷 我們還應(yīng)把判定覆蓋準(zhǔn)則擴充到多出口判斷 如Case語句 的情況 因此 判定覆蓋更為廣泛的含義應(yīng)該是使得每一個判定獲得每一種可能的結(jié)果至少一次 條件覆蓋 在實際程序代碼中 一個判定中通常都包含若干條件 條件覆蓋的目的是設(shè)計若干測試用例 在執(zhí)行被測程序后 要使每個判定中每個條件的可能值至少滿足一次 對DoWork函數(shù)的各個判定的各種條件取值加以標(biāo)記 對于第一個判定 x 3 z3取真值記為T1 取假值記為 T1條件z5 條件x 4取真值記為T3 取假值記為 T3條件y 5取真值記為T4 取假值記為 T4 條件覆蓋 續(xù) 根據(jù)條件覆蓋的基本思想 要使上述4個條件可能產(chǎn)生的8種情況至少滿足一次 設(shè)計測試用例如下 分析 上面這組測試用例不但覆蓋了4個條件的全部8種情況 而且將兩個判定的4個分支b c d e也同時覆蓋了 即同時達到了條件覆蓋和判定覆蓋 條件覆蓋 續(xù) 說明 雖然前面的一組測試用例同時達到了條件覆蓋和判定覆蓋 但是 并不是說滿足條件覆蓋就一定能滿足判定覆蓋 如果設(shè)計了下表中的這組測試用例 則雖然滿足了條件覆蓋 但只是覆蓋了程序中第一個判定的取假分支c和第二個判定的取真分支d 不滿足判定覆蓋的要求 判定 條件覆蓋 判定 條件覆蓋實際上是將判定覆蓋和條件覆蓋結(jié)合起來的一種方法 即 設(shè)計足夠的測試用例 使得判定中每個條件的所有可能取值至少滿足一次 同時每個判定的可能結(jié)果也至少出現(xiàn)一次 根據(jù)判定 條件覆蓋的基本思想 只需設(shè)計以下兩個測試用例便可以覆蓋4個條件的8種取值以及4個判定分支 判定 條件覆蓋 續(xù) 分析 從表面上看 判定 條件覆蓋測試了各個判定中的所有條件的取值 但實際上 編譯器在檢查含有多個條件的邏輯表達式時 某些情況下的某些條件將會被其它條件所掩蓋 因此 判定 條件覆蓋也不一定能夠完全檢查出邏輯表達式中的錯誤 例如 對于第一個判定 x 3 z3和z3為假 則編譯器將不再檢查z5 來說 若條件x 4滿足 就認(rèn)為該判定為真 這時將不會再檢查y 5 那么同樣也無法發(fā)現(xiàn)這個條件中的錯誤 組合覆蓋 組合覆蓋的目的是要使設(shè)計的測試用例能覆蓋每一個判定的所有可能的條件取值組合 對DoWork函數(shù)中的各個判定的條件取值組合加以標(biāo)記 1 x 3 z3 z 10記做T1 T2 第一個判定的取假分支3 x 10記做 T1 T2 第一個判定的取假分支5 x 4 y 5記做T3T4 第二個判定的取真分支6 x 4 y5記做 T3T4 第二個判定的取真分支8 x 4 y 5記做 T3 T4 第二個判定的取假分支 組合覆蓋 續(xù) 根據(jù)組合覆蓋的基本思想 設(shè)計測試用例如下 分析 上面這組測試用例覆蓋了所有8種條件取值的組合 覆蓋了所有判定的真假分支 但是卻丟失了一條路徑abe 路徑覆蓋 前面提到的5種邏輯覆蓋都未涉及到路徑的覆蓋 事實上 只有當(dāng)程序中的每一條路徑都受到了檢驗 才能使程序受到全面檢驗 路徑覆蓋的目的就是要使設(shè)計的測試用例能覆蓋被測程序中所有可能的路徑 根據(jù)路徑覆蓋的基本思想 在滿足組合覆蓋的測試用例中修改其中一個測試用例 則可以實現(xiàn)路徑覆蓋 路徑覆蓋 續(xù) 分析 雖然前面一組測試用例滿足了路徑覆蓋 但并沒有覆蓋程序中所有的條件組合 丟失了組合3和7 即滿足路徑覆蓋的測試用例并不一定滿足組合覆蓋 說明 對于比較簡單的小程序 實現(xiàn)路徑覆蓋是可能做到的 但如果程序中出現(xiàn)較多判斷和較多循環(huán) 可能的路徑數(shù)目將會急劇增長 要在測試中覆蓋所有的路徑是無法實現(xiàn)的 為了解決這個難題 只有把覆蓋路徑數(shù)量壓縮到一定的限度內(nèi) 如程序中的循環(huán)體只執(zhí)行一次 在實際測試中 即使對于路徑數(shù)很有限的程序已經(jīng)做到路徑覆蓋 仍然不能保證被測試程序的正確性 還需要采用其他測試方法進行補充 習(xí)題 為以下流程圖所示的程序段設(shè)計一組測試用例 要求分別滿足語句覆蓋 判定覆蓋 條件覆蓋 判定 條件覆蓋 組合覆蓋和路徑覆蓋 面向?qū)ο蟮母采w 繼承上下文覆蓋由于傳統(tǒng)的結(jié)構(gòu)化度量沒有考慮面向?qū)ο蟮囊恍┨匦?如多態(tài) 繼承和封裝等 所以在面向?qū)ο箢I(lǐng)域 傳統(tǒng)的結(jié)構(gòu)化覆蓋必須被加強 以滿足面向?qū)ο筇匦?繼承上下文覆蓋考慮在每個類的上下文內(nèi)獲得的覆蓋率級別 它是擴展到面向?qū)ο箢I(lǐng)域里的一種覆蓋率度量方法 用于度量在系統(tǒng)中的多態(tài)調(diào)用被測試得多好 繼承上下文定義將基類上下文內(nèi)例行程序的執(zhí)行作為獨立于繼承類上下文內(nèi)例行程序的執(zhí)行 同樣 它們在考慮繼承類上下文內(nèi)例行程序的執(zhí)行也獨立于基類上下文內(nèi)例行程序的執(zhí)行 為了獲得100 繼承上下文覆蓋 代碼必須在每個適當(dāng)?shù)纳舷挛膬?nèi)被完全執(zhí)行 面向?qū)ο蟮母采w 續(xù) 基于狀態(tài)的上下文覆蓋在絕大多數(shù)面向?qū)ο蟮南到y(tǒng)中存在這樣的一些類 這些類的對象可以存在于眾多不同狀態(tài)中的任何一種 并且由于類的行為依賴于狀態(tài) 每個類的行為在每個可能的狀態(tài)中其性質(zhì)是不同的 基于狀態(tài)的上下文覆蓋對應(yīng)于被測類對象的潛在狀態(tài) 這樣基于狀態(tài)的上下文覆蓋把一個狀態(tài)上下文內(nèi)的一個例行程序的執(zhí)行認(rèn)為是獨立于另一個狀態(tài)內(nèi)相同例行程序的執(zhí)行 為了達到100 的基于狀態(tài)的上下文覆蓋 例行程序必須在每個適當(dāng)?shù)纳舷挛?狀態(tài) 內(nèi)被執(zhí)行 測試覆蓋準(zhǔn)則 邏輯覆蓋的出發(fā)點是合理的 完善的 所謂 覆蓋 就是想要做到全面而無遺漏 但邏輯覆蓋并不能真正做到無遺漏 例如 我們不小心將前面提到的程序段中的if x 3 Z 3 Z 10 按照我們前面設(shè)計的測試用例 x的值取2或4 來看 邏輯覆蓋對這樣的小問題都無能為力 分析出現(xiàn)這一情況的原因在于 錯誤區(qū)域僅僅在x 3這個點上 即僅當(dāng)x的值取3時 測試才能發(fā)現(xiàn)錯誤 面對這類情況 我們應(yīng)該從中吸取的教訓(xùn)是測試工作要有重點 要多針對容易發(fā)生問題的地方設(shè)計測試用例 測試覆蓋準(zhǔn)則 續(xù) ESTCA覆蓋準(zhǔn)則 在容易發(fā)生問題的地方設(shè)計測試用例 即重視程序中謂詞 條件判斷 的取值 ESTCA覆蓋準(zhǔn)則是一套錯誤敏感用例分析規(guī)則 這一規(guī)則雖然并不完備 但在普通程序中卻是有效的 原因在于這是一種經(jīng)驗型的覆蓋準(zhǔn)則 規(guī)則本身針對了程序編寫人員容易發(fā)生的錯誤 或是圍繞著發(fā)生錯誤的頻繁區(qū)域 從而提高了發(fā)現(xiàn)錯誤的命中率 具體規(guī)則如下 規(guī)則1 對于ArelB型 rel可以是 的分支謂詞 應(yīng)適當(dāng)?shù)倪x擇A與B的值 使得測試執(zhí)行到該分支語句時 AB的情況分別出現(xiàn)一次 這是為了檢測邏輯符號寫錯的情況 如將 AB 測試覆蓋準(zhǔn)則 續(xù) 規(guī)則2 對于ArelC型 rel可以是 或時 應(yīng)適當(dāng)?shù)倪x擇A的值 使A C M 這是為了檢測 差1 之類的錯誤 如 A 1 錯寫成 A 0 規(guī)則3 對外部輸入變量賦值 使其在每一個測試用例中均有不同的值與符號 并與同一組測試用例中其他變量的值與符號不同 這是為了檢測程序語句中的錯誤 如應(yīng)該引用某一變量而錯成引用另一個常量 測試覆蓋準(zhǔn)則 續(xù) 關(guān)于LCSAJLCSAJ LinearCodeSequenceandJump 的字面含義是線性代碼序列與跳轉(zhuǎn) 在程序中 一個LCSAJ是一組順序執(zhí)行的代碼 以控制跳轉(zhuǎn)為其結(jié)束點 LCSAJ的起點是根據(jù)程序本身決定的 它的起點可以是程序第一行或轉(zhuǎn)移語句的入口點 或是控制流可跳達的點 如果有幾個LCSAJ首尾相接 且第一個LCSAJ起點為程序起點 最后一個LCSAJ終點為程序終點 這樣的LCSAJ串就組成了程序的一條路徑 LCSAJ路徑 一條LCSAJ程序路徑可能是由2個 3個或多個LCSAJ組成的 測試覆蓋準(zhǔn)則 續(xù) 基于LCSAJ與路徑的關(guān)系 提出了層次LCSAJ覆蓋準(zhǔn)則 它是一個分層的覆蓋準(zhǔn)則 可以概括的描述為 第一層 語句覆蓋 第二層 分支覆蓋 第三層 LCSAJ覆蓋 即程序中的每一個LCSAJ都至少在測試中經(jīng)歷過一次 第四層 兩兩LCSAJ覆蓋 即程序中的每兩個相連的LCSAJ組合起來在測試中都要經(jīng)歷一次 第n 2層 每n個首尾相連的LCSAJ組合在測試中都要經(jīng)歷一次 在實施測試時 若要實現(xiàn)上述的層次LCSAJ覆蓋 需要產(chǎn)生被測程序的所有LCSAJ 測試覆蓋準(zhǔn)則 續(xù) 例 找出前面DoWork函數(shù)的所有LCSAJ和LCSAJ路徑 LCSAJ 5個 1 intk 0 j 0 if x 3 j j 3 5 j j 3LCSAJ路徑 4條 1 2 4 1 2 5 1 3 4 1 3 5 8 3 1 3路徑測試 路徑表達式基本路徑測試方法循環(huán)測試方法產(chǎn)生測試用例 Return 路徑表達式 為了滿足路徑覆蓋 必須首先確定具體的路徑以及路徑的個數(shù) 我們通常采用控制流圖的邊 弧 序列和節(jié)點序列表示某一條具體路徑 更為概括的表示方法為 1 弧a和弧b相乘 表示為ab 它表明路徑是先經(jīng)歷弧a 接著再經(jīng)歷弧b 弧a和弧b是先后相接的 2 弧a和弧b相加 表示為a b 它表明兩條弧是 或 的關(guān)系 是并行的路段 路徑數(shù)的計算 在路徑表達式中 將所有弧均以數(shù)值1來代替 再進行表達式的相乘和相加運算 最后得到的數(shù)值即為該程序的路徑數(shù) 基本路徑測試方法 路徑測試就是從一個程序的入口開始 執(zhí)行所經(jīng)歷的各個語句的完整過程 從廣義的角度講 任何有關(guān)路徑分析的測試都可以被稱為路徑測試 完成路徑測試的理想情況是做到路徑覆蓋 但對于復(fù)雜性大的程序要做到所有路徑覆蓋 測試所有可執(zhí)行路徑 是不可能的 在不能做到所有路徑覆蓋的前提下 如果某一程序的每一個獨立路徑都被測試過 那么可以認(rèn)為程序中的每個語句都已經(jīng)檢驗過了 即達到了語句覆蓋 這種測試方法就是通常所說的基本路徑測試方法 基本路徑測試方法 續(xù) 基本路徑測試方法是在控制流圖的基礎(chǔ)上 通過分析控制結(jié)構(gòu)的環(huán)形復(fù)雜度 導(dǎo)出執(zhí)行路徑的基本集 再從該基本集設(shè)計測試用例 基本路徑測試方法包括以下4個步驟 1 畫出程序的控制流圖 2 計算程序的環(huán)形復(fù)雜度 導(dǎo)出程序基本路徑集中的獨立路徑條數(shù) 這是確定程序中每個可執(zhí)行語句至少執(zhí)行一次所必須的測試用例數(shù)目的上界 3 導(dǎo)出基本路徑集 確定程序的獨立路徑 4 根據(jù) 3 中的獨立路徑 設(shè)計測試用例的輸入數(shù)據(jù)和預(yù)期輸出 基本路徑測試方法 續(xù) voidSort intiRecordNum intiType 1 2intx 0 3inty 0 4while iRecordNum 0 5 6If iType 0 7x y 2 8else9If iType 1 10 x y 10 11else12x y 20 13 14 基本路徑測試方法 續(xù) 畫出控制流圖 如右圖所示計算環(huán)形復(fù)雜度 10 條邊 8 個節(jié)點 2 4導(dǎo)出獨立路徑 用語句編號表示 路徑1 4 14路徑2 4 6 7 14路徑3 4 6 9 10 13 4 14路徑4 4 6 9 12 13 4 14 基本路徑測試方法 續(xù) 設(shè)計測試用例 習(xí)題 1 使用基本路徑測試方法 為以下程序段設(shè)計測試用例 voidDo intX intA intB 1if A 1 5 2 在三角形問題中 要求輸入三個邊長 a b c 當(dāng)三邊不可能構(gòu)成三角形時提示錯誤 可構(gòu)成三角形時計算三角形的周長 若是等腰三角形打印 等腰三角形 若是等邊三角形 則打印 等邊三角形 畫出相應(yīng)的程序流程圖 并采用基本路徑測試方法為該程序設(shè)計測試用例 循環(huán)測試方法 從本質(zhì)上說 循環(huán)測試的目的就是檢查循環(huán)結(jié)構(gòu)的有效性 通常 循環(huán)可以劃分為簡單循環(huán) 嵌套循環(huán) 串接循環(huán)和非結(jié)構(gòu)循環(huán)4類 1 測試簡單循環(huán) 設(shè)其循環(huán)的最大次數(shù)為n 可采用以下測試集 跳過整個循環(huán) 只循環(huán)一次 只循環(huán)兩次 循環(huán)m次 其中m n 分別循環(huán)n 1 n和n 1次 循環(huán)測試方法 續(xù) 2 測試嵌套循環(huán) 如果將簡單循環(huán)的測試方法用于嵌套循環(huán) 可能的測試次數(shù)會隨嵌套層數(shù)成幾何級數(shù)增加 此時可采用以下辦法減少測試次數(shù) 測試從最內(nèi)層循環(huán)開始 所有外層循環(huán)次數(shù)設(shè)置為最小值 對最內(nèi)層循環(huán)按照簡單循環(huán)的測試方法進行 由內(nèi)向外進行下一個循環(huán)的測試 本層循環(huán)的所有外層循環(huán)仍取最小值 而由本層循環(huán)嵌套的循環(huán)取某些 典型 值 重復(fù)上一步的過程 直到測試完所有循環(huán) 3 測試串接循環(huán) 若串接的各個循環(huán)相互獨立 則可分別采用簡單循環(huán)的測試方法 否則采用嵌套循環(huán)的測試方法 4 對于非結(jié)構(gòu)循環(huán)這種情況 無法進行測試 需要按結(jié)構(gòu)化程序設(shè)計的思想將程序結(jié)構(gòu)化后 再進行測試 Z路徑覆蓋下的循環(huán)測試方法 Z路徑覆蓋是路徑覆蓋的一種變體 它是將程序中的循環(huán)結(jié)構(gòu)簡化為選擇結(jié)構(gòu)的一種路徑覆蓋 循環(huán)簡化的目的是限制循環(huán)的次數(shù) 無論循環(huán)的形式和循環(huán)體實際執(zhí)行的次數(shù) 簡化后的循環(huán)測試只考慮執(zhí)行循環(huán)體一次和零次 不執(zhí)行 兩種情況 即考慮執(zhí)行時進入循環(huán)體一次和跳過循環(huán)體這兩種情況 在循環(huán)簡化的思路下 循環(huán)與判定分支的效果是一樣的 即 循環(huán)要么執(zhí)行 要么跳過 產(chǎn)生測試用例 在實踐中 除了前面給出的各種方法外 通常還可以采用以下三種方法來補充設(shè)計測試用例 1 通過非路經(jīng)分析得到測試用例 這種方法得到的測試用例是在應(yīng)用系