軟件測試工程師資料與面試題.pdf

開發(fā)思想 邏輯能力 目錄目錄 測試用例 2 測試用例的設(shè)計 3 一 白盒技術(shù) 3 二 黑盒技術(shù) 4 面試題 9 測試用例 測試用例 Test Case 是為某個特殊目標(biāo)而編制的一組測試輸入 執(zhí) 行條件以及預(yù)期結(jié)果 以便測試某個程序路徑或核實是否滿足某個特 定需求 指對一項特定的軟件產(chǎn)品進(jìn)行測試任務(wù)的描述 體現(xiàn)測 試方案 方法 技術(shù)和策略 內(nèi)容包括測試目標(biāo) 測試環(huán)境 輸 入數(shù)據(jù) 測試步驟 預(yù)期結(jié)果 測試腳本等 并形成文檔 測試 用例構(gòu)成了設(shè)計和制定測試過程的基礎(chǔ) 編制測試用例的具體做法 1 測試用例文檔 2 測試用例的設(shè)置 3 設(shè)計測試用例 測試用例在軟件測試中的作用 1 指導(dǎo)測試的實施 測試用例主要適用于集成測試 系統(tǒng)測試和 回歸測試 2 規(guī)劃測試數(shù)據(jù)的準(zhǔn)備 3 編寫測試腳本的 設(shè)計規(guī)格說明書 4 評估測試結(jié)果的度量基準(zhǔn) 完成測試實施后需要對測試結(jié)果進(jìn)行 評估 并且編制測試報告 判斷軟件測試是否完成 衡量測試質(zhì)量需 要一些量化的結(jié)果 例 測試覆蓋率是多少 測試合格率是多少 重要測試合格率是多少 等等 5 分析缺陷的標(biāo)準(zhǔn) 測試用例的設(shè)計 一 白盒技術(shù) 白盒測試是結(jié)構(gòu)測試 所以被測對象基本上是源程序 以程 序的內(nèi)部邏輯為基礎(chǔ)設(shè)計測試用例 1 邏輯覆蓋 程序內(nèi)部的邏輯覆蓋程度 當(dāng)程序中有循環(huán)時 覆蓋每條路 徑是不可能的 要設(shè)計使覆蓋程度較高的或覆蓋最有代表性的路 徑的測試用例 1 語句覆蓋 為了個提高發(fā)現(xiàn)錯誤的可能性 在測試時應(yīng)該執(zhí)行到程序中 的每一個語句 語句覆蓋是指設(shè)計足夠的測試用例 使被測試程 序中每個語句至少執(zhí)行一次 2 判定覆蓋 判定覆蓋指設(shè)計足夠的測試用例 使得被測程序中每個判定 表達(dá)式至少獲得一次 真 值和 假 值 從而使程序的每一個 分支至少都通過一次 因此判定覆蓋也稱分支覆蓋 3 條件覆蓋 條件覆蓋是指設(shè)計足夠的測試用例 使得判定表達(dá)式中每個 條件的各種可能的值至少出現(xiàn)一次 4 判定 條件測試 該覆蓋標(biāo)準(zhǔn)指設(shè)計足夠的測試用例 使得判定表達(dá)式的每個 條件的所有可能取值至少出現(xiàn)一次 并使每個判定表達(dá)式所有可 能的結(jié)果也至少出現(xiàn)一次 5 條件組合覆蓋 條件組合覆蓋是比較強(qiáng)的覆蓋標(biāo)準(zhǔn) 它是指設(shè)計足夠的測試 用例 使得每個判定表達(dá)式中條件的各種可能的值的組合都至少 出現(xiàn)一次 6 路徑覆蓋 路徑覆蓋是指設(shè)計足夠的測試用例 覆蓋被測程序中所有可 能的路徑 在實際的邏輯覆蓋測試中 一般以條件組合覆蓋為主設(shè)計測 試用例 然后再補(bǔ)充部分用例 以達(dá)到路徑覆蓋測試標(biāo)準(zhǔn) 2 循環(huán)覆蓋 3 基本路徑測試 二 黑盒技術(shù) 黑盒測試也稱功能測試 它是通過測試來檢測每個功能是否都能 正常使用 在測試中 把程序看作一個不能打開的黑盒子 在完全不 考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下 在程序接口進(jìn)行測試 它只 檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用 程序是否能 適當(dāng)?shù)亟邮蛰斎霐?shù)據(jù)而產(chǎn)生正確的輸出信息 黑盒測試著眼于程序外 部結(jié)構(gòu) 不考慮內(nèi)部邏輯結(jié)構(gòu) 主要針對軟件界面和軟件功能進(jìn)行測 試 1 等價類劃分 1 劃分等價類 如果某個輸入條件規(guī)定了取值范圍或值的個數(shù) 則可確定 一個合理的等價類 輸入值或數(shù)在此范圍內(nèi) 和兩個不合理等價類 輸入值或個數(shù)小于這個范圍的最小值或大于這個范圍的最大 值 如果規(guī)定了輸入數(shù)據(jù)的一組值 而且程序?qū)Σ煌妮斎胫?做不同的處理 則每個允許輸入值是一個合理等價類 此處還有 一個不合理等價類 任何一個不允許的輸入值 如果規(guī)定了輸入數(shù)據(jù)必須遵循的規(guī)則 可確定一個合理等 價類 符合規(guī)則 和若干個不合理等價類 從各種不同角度違反規(guī) 則 如果已劃分的等價類中各元素在程序中的處理方式不同 則應(yīng)將此等價類進(jìn)一步劃分為更小的等價類 2 確定測試用例 為每一個等價類編號 設(shè)計一個測試用例 使其盡可能多地覆蓋尚未被覆蓋過的 合理等價類 重復(fù)這步 直到所有合理等價類被測試用例覆蓋 設(shè)計一個測試用例 使其只覆蓋一個不合理等價類 2 邊界值分析 使用邊界值分析方法設(shè)計測試用例時一般與等價類劃分結(jié)合 起來 但它不是從一個等價類中任選一個例子作為代表 而是將 測試邊界情況作為重點目標(biāo) 選取正好等于 剛剛大于或剛剛小 于邊界值的測試數(shù)據(jù) 1 如果輸入條件規(guī)定了值的范圍 可以選擇正好等于邊界值 的數(shù)據(jù)作為合理的測試用例 同時還要選擇剛好越過邊界值的數(shù) 據(jù)作為不合理的測試用例 如輸入值的范圍是 1 100 可取 0 1 100 101 等值作為測試數(shù)據(jù) 2 如果輸入條件指出了輸入數(shù)據(jù)的個數(shù) 則按最大個數(shù) 最 小個數(shù) 比最小個數(shù)少 1 比最大個數(shù)多 1 等情況分別設(shè)計測試 用例 如 一個輸入文件可包括 1 255 個記錄 則分別設(shè)計有 1 個記錄 255 個記錄 以及 0 個記錄的輸入文件的測試用例 3 對每個輸出條件分別按照以上原則 1 或 2 確定輸出值 的邊界情況 如 一個學(xué)生成績管理系統(tǒng)規(guī)定 只能查詢 95 98 級大學(xué)生的各科成績 可以設(shè)計測試用例 使得查詢范圍內(nèi)的某 一屆或四屆學(xué)生的學(xué)生成績 還需設(shè)計查詢 94 級 99 級學(xué)生成 績的測試用例 不合理輸出等價類 由于輸出值的邊界不與輸入值的邊界相對應(yīng) 所以要檢查輸 出值的邊界不一定可能 要產(chǎn)生超出輸出值之外的結(jié)果也不一定 能做到 但必要時還需試一試 4 如果程序的規(guī)格說明給出的輸入或輸出域是個有序集合 如順序文件 線形表 鏈表等 則應(yīng)選取集合的第一個元素和 最后一個元素作為測試用例 3 錯誤推測 在測試程序時 人們可能根據(jù)經(jīng)驗或直覺推測程序中可能存 在的各種錯誤 從而有針對性地編寫檢查這些錯誤的測試用例 這就是錯誤推測法 4 因果圖 等價類劃分和邊界值方法分析方法都只是孤立地考慮各個輸 入數(shù)據(jù)的測試功能 而沒有考慮多個輸入數(shù)據(jù)的組合引起的錯誤 5 綜合策略 每種方法都能設(shè)計出一組有用例子 用這組例子容易發(fā)現(xiàn)某種類 型的錯誤 但可能不易發(fā)現(xiàn)另一類型的錯誤 因此在實際測試中 聯(lián)合使用各種測試方法 形成綜合策略 通常先用黑盒法設(shè)計基 本的測試用例 再用白盒法補(bǔ)充一些必要的測試用例 測試用例模板 模塊描述 XX 項目 XX 模塊 提交時間 測試人 測試時間 測試環(huán)境 測試工具 功能 1 描述 XX 項目 XX 模塊 XX 功能 用例目的 前提條件 輸入 動作 期望的輸出 相應(yīng) 實際情況 期待輸出和實際比較 軟件測試工具也分為自動化軟件測試工具和測試管理工具 國內(nèi) 免費(fèi)軟件測試工具有 黑盒測試工具 AutoRunner 可以用來完成功 能測試 回歸測試 每日構(gòu)建測試與自動回歸測試等工作和 TestCenter 是一款功能強(qiáng)大測試管理工具 它可以幫助您 實現(xiàn) 測試用例的過程管理 對測試需求過程 測試用例設(shè)計過程 業(yè) 務(wù)組件設(shè)計實現(xiàn)過程等整個測試過程進(jìn)行管理 面試題面試題 一 判斷題 1 軟件測試的目的是盡可能多的找出軟件的缺陷 Y 2 Beta 測試是驗收測試的一種 Y 3 驗收測試是由最終用戶來實施的 N 4 項目立項前測試人員不需要提交任何工件 Y 5 單元測試能發(fā)現(xiàn)約 80 的軟件缺陷 Y 6 代碼評審是檢查源代碼是否達(dá)到模塊設(shè)計的要求 N 7 自底向上集成需要測試員編寫驅(qū)動程序 Y 8 負(fù)載測試是驗證要檢驗的系統(tǒng)的能力最高能達(dá)到什么程度 N 9 測試人員要堅持原則 缺陷未修復(fù)完堅決不予通過 N 看情況有時候 就是堅持原則 10 代碼評審員一般由測試員擔(dān)任 N 11 我們可以人為的使得軟件不存在配置問題 N 12 集成測試計劃在需求分析階段末提交 N 二 選折 1 軟件驗收測試的合格通過準(zhǔn)則是 ABCD A 軟件需求分析說明書中定義的所有功能已全部實現(xiàn) 性能指標(biāo)全部達(dá)到要 求 B 所有測試項沒有殘余一級 二級和三級錯誤 C 立項審批表 需求分析文檔 設(shè)計文檔和編碼實現(xiàn)一致 D 驗收測試工件齊全 2 軟件測試計劃評審會需要哪些人員參加 ABCD A 項目經(jīng)理B SQA 負(fù)責(zé)人C 配置負(fù)責(zé)人D 測試組 3 下列關(guān)于 alpha 測試的描述中正確的是 AD A alpha 測試需要用戶代表參加D alpha 測試是驗收測試的一種 4 測試設(shè)計員的職責(zé)有 BC B 設(shè)計測試用例C 設(shè)計測試過程 腳本 5 軟件實施活動的進(jìn)入準(zhǔn)則是 ABC A 需求工件已經(jīng)被基線化B 詳細(xì)設(shè)計工件已經(jīng)被基線化 C 構(gòu)架工件已經(jīng)被基線化 三 添空 1 軟件驗收測試包括 正式驗收測試 alpha 測試 beta 測試 2 系統(tǒng)測試的策略有 功能測試 性能測試 可靠性測試 負(fù)載測試 易用性測 試 強(qiáng)度測試 安全測試 配置測試 安裝測試 卸載測試 文擋測試 故障恢 復(fù)測試 界面測試 容量測試 兼容性測試 分布測試 可用性測試 有的可 以合在一起 分開寫只要寫出 15 就滿分哦 3 設(shè)計系統(tǒng)測試計劃需要參考的項目文擋有 軟件測試計劃 軟件需求工件和迭 代計劃 4 對面向過程的系統(tǒng)采用的集成策略有 自頂向下 自底向上兩種 5 這題出的有問題哦 詳細(xì)的 5 步驟為 通過畫因果圖來寫測試用例的步驟 為 1 分析軟件規(guī)格說明描述中 哪些是原因 即輸入條件或輸入條件的等價類 哪些是結(jié)果 即輸出條件 并給每個原因和結(jié)果賦予一個標(biāo)識符 2 分析軟件規(guī)格說明描述中的語義 找出原因與結(jié)果之間 原因與原因之間 對應(yīng)的是什么關(guān)系 根據(jù)這些關(guān)系 畫出因果圖 3 由于語法或環(huán)境限制 有些原因與原因之間 原因與結(jié)果之間的組合情況 不可能出現(xiàn) 為表明這些特殊情況 在因果圖上用一些記號標(biāo)明約束或限制條件 4 把因果圖轉(zhuǎn)換成判定表 5 把判定表的每一列拿出來作為依據(jù) 設(shè)計測試用例 四 簡答 資料是搜集整理的 感謝前輩的解題 無 1 區(qū)別階段評審的與同行評審 同行評審目的 發(fā)現(xiàn)小規(guī)模工作產(chǎn)品的錯誤 只要是找錯誤 階段評審目的 評審模塊 階段作品的正確性 可行性 及完整性 同行評審人數(shù) 3 7 人 人員必須經(jīng)過同行評審會議的培訓(xùn) 由 SQA 指導(dǎo) 階段評審人數(shù) 5 人左右 評審人必須是專家 具有系統(tǒng)評審資格 同行評審內(nèi)容 內(nèi)容小 一般文檔 40 頁 代碼 500 行 階段評審內(nèi)容 內(nèi)容多 主要看重點 同行評審時間 一小部分工作產(chǎn)品完成 階段評審時間 通常是設(shè)置在關(guān)鍵路徑的時間點上 2 什么是軟件測試 為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程 3 簡述集成測試的過程 系統(tǒng)集成測試主要包括以下過程 1 構(gòu)建的確認(rèn)過程 2 補(bǔ)丁的確認(rèn)過程 3 系統(tǒng)集成測試測試組提交過程 4 測試用例設(shè)計過程 5 測試代碼編寫過程 6 Bug 的報告過程 7 每周 每兩周的構(gòu)建過程 8 點對點的測試過程 9 組內(nèi)培訓(xùn)過程 4 怎么做好文檔測試 仔細(xì)閱讀 跟隨每個步驟 檢查每個圖形 嘗試每個示例 P142 檢查文檔的編寫是否滿足文檔編寫的目的 內(nèi)容是否齊全 正確 內(nèi)容是否完善 標(biāo)記是否正確 5 白盒測試有幾種方法 總體上分為靜態(tài)方法和動態(tài)方法兩大類 靜態(tài) 關(guān)鍵功能是檢查軟件的表示和描述是否一致 沒有沖突或者沒有歧義 動態(tài) 語句覆蓋 判定覆蓋 條件覆蓋 判定條件覆蓋 條件組合覆蓋 路徑覆 蓋 6 系統(tǒng)測試計劃是否需要同行審批 為什么 需要 系統(tǒng)測試計劃屬于項目階段性關(guān)鍵文檔 因此需要評審 7Alpha 測試與 beta 的區(qū)別 Alpha 測試 在系統(tǒng)開發(fā)接近完成時對應(yīng)用系統(tǒng)的測試 測試后仍然會有少量的 設(shè)計變更 這種測試一般由最終用戶或其它人員完成 不能由程序或測試員完成 黑盒 白盒 壓力 應(yīng)力等等 Beta 測試 當(dāng)開發(fā)和測試根本完成時所做的測試 最終的錯誤和問題需要在最終 發(fā)行前找到 這種測試一般由最終用戶或其它人員完成 不能由程序員或測試員 完成 常用來表示軟件測試過程中的三個階段 是第一階段 一般只供內(nèi)部 測試使用 是第二個階段 已經(jīng)消除了軟件中大部分的不完善之處 但仍有可 能還存在缺陷和漏洞 一般只提供給特定的用戶群來測試使用 是第三個階段 此時產(chǎn)品已經(jīng)相當(dāng)成熟 只需在個別地方再做進(jìn)一步的優(yōu)化處理即可上市發(fā)行 8 比較負(fù)載測試 容量測試和強(qiáng)度測試的區(qū)別 負(fù)載測試 在一定的工作負(fù)荷下 系統(tǒng)的負(fù)荷及響應(yīng)時間 強(qiáng)度測試 在一定的負(fù)荷條件下 在較長時間跨度內(nèi)的系統(tǒng)連續(xù)運(yùn)行給系統(tǒng)性能 所造成的影響 容量測試 容量測試目的是通過測試預(yù)先分 析出反映軟件系統(tǒng)應(yīng)用特征的某項 指標(biāo)的極限值 如最大并發(fā)用戶數(shù) 數(shù)據(jù)庫記錄數(shù)等 系統(tǒng)在其極限值狀態(tài)下 沒有出現(xiàn)任何軟件故障或還能保持主要功能正常運(yùn)行 容量測試還將確定測試對 象在給定時間內(nèi)能夠持續(xù)處理的最大負(fù)載或工作量 容量測試的目的是使系統(tǒng)承 受超額的數(shù)據(jù)容量來發(fā)現(xiàn)它是否能夠正確處理 容量測試是面向數(shù)據(jù)的 并且它 的目的是顯示系統(tǒng)可以處理目標(biāo)內(nèi)確定的數(shù)據(jù)容量 9 測試結(jié)束的標(biāo)準(zhǔn)是什么 用例全部測試 覆蓋率達(dá)到標(biāo)準(zhǔn) 缺陷率達(dá)到標(biāo)準(zhǔn) 其他指標(biāo)達(dá)到質(zhì)量標(biāo)準(zhǔn) 10 描述軟件測試活動的生命周期 測試周期分為計劃 設(shè)計 實現(xiàn) 執(zhí)行 總結(jié) 其中 計劃 對整個測試周期中所有活動進(jìn)行規(guī)劃 估計工作量 風(fēng)險 安排人力物力 資源 安排進(jìn)度等 設(shè)計 完成測試方案 從技術(shù)層面上對測試進(jìn)行規(guī)劃 實現(xiàn) 進(jìn)行測試用例和測試規(guī)程設(shè)計 執(zhí)行 根據(jù)前期完成的計劃 方案 用例 規(guī)程等文檔 執(zhí)行測試用例 總結(jié) 記錄測試結(jié)果 進(jìn)行測試分析 完成測試報告 11 軟件的缺陷等級應(yīng)如何劃分 A 類 嚴(yán)重錯誤 包括以下各種錯誤 1 由于程序所引起的死機(jī) 非法退出 2 死循環(huán) 3 數(shù)據(jù)庫發(fā)生死鎖 4 因錯誤操作導(dǎo)致的程序中斷 5 功能錯誤 6 與數(shù)據(jù)庫連接錯誤 7 數(shù)據(jù)通訊錯誤 B 類 較嚴(yán)重錯誤 包括以下各種錯誤 1 程序錯誤 2 程序接口錯誤 3 數(shù)據(jù)庫的表 業(yè)務(wù)規(guī)則 缺省值未加完整性等約束條件 C 類 一般性錯誤 包括以下各種錯誤 1 操作界面錯誤 包括數(shù)據(jù)窗口內(nèi) 列名定義 含義是否一致 2 打印內(nèi)容 格式錯誤 3 簡單的輸入限制未放 在前臺進(jìn)行控制 4 刪除操作未給出提示 5 數(shù)據(jù)庫表中有過多的空字段 D 類 較小錯誤 包括以下各種錯誤 1 界面不規(guī)范 2 輔助說明描述不清 楚 3 輸入輸出不規(guī)范 4 長操作未給用戶提示 5 提示窗口文字未采用行 業(yè)術(shù)語 6 可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標(biāo)志 E 類 測試建議 大體是這樣 還會有一些變動 同時最后一道題出的是畫流程圖和控制圖的題 等腰三角形那個 好了 僅供參考 一 等價類劃分 三角形三條邊 A B C 的數(shù)據(jù)類型不同 二 邊界值分析 由于三角形的邊長可以是正整數(shù)或正小數(shù) 所以就不對長度進(jìn) 行測試 那么邊界值分析就不用了 三 因果圖法 三角形的三條邊數(shù)據(jù)輸入組合 我們看一下三角形的流程圖 我們再分析一下三角形的等價類 有效等價類 輸入 3 個正整數(shù)或正小數(shù) 1 兩數(shù)之和大于第三數(shù) 如 A B C B C A C0 1 B 0 2 C 0 3 A B C 4 B C A 5 C A B 6 A 0 7 B 0 8 C 0 9 A B C 10 B C A 11 C A B 12 是否是等腰三角形 A B 13 B C 14 C A 15 A B and B C and C A 16 是否是等腰直角三角形 A B and A2 B2 C2 17 B C and B2 C2 A2 18 C A and C2 A2 B2 19 A B and B C and C A 20 是否是等邊三角形 A B and B C and C A 21 A B 22 B C 23 C A 24 三角形測試用例 序號 A B C 覆蓋等價類 輸出 1 3 4 5 1 2 3 4 5 6 是三角形 2 0 1 2 7 非三角形 3 1 0 2 8 非三角形 4 1 2 0 9 非三角形 5 1 2 3 10 非三角形 6 1 3 2 11 非三角形 7 3 1 2 12 非三角形 8 3 3 4 1 2 3 4 5 6 13 等腰三角形 9 3 4 4 1 2 3 4 5 6 14 等腰三角形 10 3 4 3 1 2 3 4 5 6 15 等腰三角形 11 2 2 2 2 4 1 2 3 4 5 6 17 等腰直角三角形 12 4 2 2 2 2 1 2 3 4 5 6 18 等腰直角三角形 13 2 2 4 2 2 1 2 3 4 5 6 19 等腰直角三角形 14 3 4 5 1 2 3 4 5 6 16 20 22 23 24 是三角形 15 3 3 3 1 2 3 4 5 6 16 21 等邊三角形 16 無效等價類 錯誤提示 17 3 4 5 無效等價類 錯誤提示 18 a 3 無效等價類 錯誤提示 19 3 4 無效等價類 錯誤提示 針對缺陷采取怎么樣的管理措施 只是對缺陷的生命周期進(jìn)行管理和跟蹤 Bugzilla 或者 TD 已經(jīng)足夠了 1 要更好的管理缺陷 必須引入缺陷管理工具 商用的或者開源的都可 2 根據(jù)缺陷的生命周期 考慮缺陷提交的管理 缺陷狀態(tài)的管理和缺陷分析的管 理 3 所有發(fā)現(xiàn)的缺陷 不管是測試發(fā)現(xiàn)的還是走讀代碼發(fā)現(xiàn)的 都必須全部即時的 準(zhǔn)確的提交到缺陷管理工具中 這是缺陷提交的管理 4 缺陷提交后 需要即時的指派給相應(yīng)的開發(fā)人員 提交缺陷的人需要密切注意 缺陷的狀態(tài) 幫助缺陷的盡快解決 缺陷解決后需要即時對缺陷的修復(fù)進(jìn)行驗證 這樣的目的有兩個 一個是讓缺陷盡快解決 二是方便后面缺陷的分析 保證缺 陷相關(guān)的信息準(zhǔn)確 如齡期等 這是缺陷狀態(tài)的管理 5 為了更好的改進(jìn)開發(fā)過程和測試過程 需要對缺陷進(jìn)行分析 總結(jié)如缺陷的類 別 缺陷的齡期分布等信息 這是缺陷分析的管理 測試計劃的目的是什么 答 測試的目的是想以最少的人力 物力和時間找出軟件中潛在的各種錯誤和缺 陷 通過修正種錯誤和缺陷提高軟件質(zhì)量 回避軟件發(fā)布后由于潛在的軟件缺陷 和錯誤造成的隱患帶來的商業(yè)風(fēng)險 軟件測試應(yīng)該劃分幾個階段 簡述各個階段應(yīng)重點測試的點 各個階段的含義 答 大體上來說可分為單元測試 集成測試 系統(tǒng)測試 驗收測試 每個階段又分為 以下五個步驟 測試計劃 測試設(shè)計 用例設(shè)計 執(zhí)行結(jié)果 測試報告 初始測試集中在每個模塊上 保證源代碼的正確性 該階段成為單元測試 主要用白盒測試方法 接下來是模塊集成和集成以便組成完整的軟件包 集成測試集中在證實和程 序構(gòu)成問題上 主要采用黑盒測試方法 輔之以白盒測試方法 軟件集成后 需要完成確認(rèn)和系統(tǒng)測試 確認(rèn)測試提供軟件滿足所有功能 性能需求的最后保證 確認(rèn)測試僅僅應(yīng)用黑盒測試方法 單元測試 單元測試是對軟件中的基本組成單位進(jìn)行的測試 如一個模塊 一個過程等 等 它是軟件動態(tài)測試的最基本的部分 也是最重要的部分之一 其目的是檢驗 軟件基本組成單位的正確性 集成測試 集成測試是在軟件系統(tǒng)集成過程中所進(jìn)行的測試 其主要目的是檢查軟件 單位之間的接口是否正確 系統(tǒng)測試 系統(tǒng)測試是對已經(jīng)集成好的軟件系統(tǒng)進(jìn)行徹底的測試 以驗證軟件系統(tǒng)的正 確性和性能等滿足其規(guī)約所指定的要求 檢查軟件的行為和輸出是否正確并非一 項簡單的任務(wù) 它被稱為測試的 先知者問題 驗收測試 驗收測試旨在向軟件的購買者展示該軟件系統(tǒng)滿足其用戶的需求 它的測試數(shù)據(jù) 通常是系統(tǒng)測試的測試數(shù)據(jù)的子集 回歸測試 回歸測試是在軟件維護(hù)階段 對軟件進(jìn)行修改之后進(jìn)行的測試 其目的是檢 驗對軟件進(jìn)行的修改是否正確 1 測試退出標(biāo)準(zhǔn) 測試退出標(biāo)準(zhǔn)為完成測試需求中列出的所有功能及測試過程中發(fā)現(xiàn)缺陷的 回歸測試 1 單元測試退出標(biāo)準(zhǔn) 1 單元測試用例設(shè)計已經(jīng)通過評審 2 核心代碼 100 經(jīng)過 Code Review 3 單元測試功能覆蓋率達(dá)到 100 4 單元測試代碼行覆蓋率不低于 80 5 所有發(fā)現(xiàn)缺陷至少 60 都納入缺陷追蹤系統(tǒng)且各級缺陷修復(fù)率達(dá)到標(biāo)準(zhǔn) 6 不存在 A B 類缺陷 7 C D E 類缺陷允許存在 8 按照單元測試用例完成了所有規(guī)定單元的測試 9 軟件單元功能與設(shè)計一致 2 集成測試退出標(biāo)準(zhǔn) 1 集成測試用例設(shè)計已經(jīng)通過評審 2 所有源代碼和可執(zhí)行代碼已經(jīng)建立受控基線 納入配置管理受控庫 不經(jīng)過 審批不能隨意更改 3 按照集成構(gòu)件計劃及增量集成策略完成了整個系統(tǒng)的集成測試 4 達(dá)到了測試計劃中關(guān)于集成測試所規(guī)定的覆蓋率的要求 5 集成工作版本滿足設(shè)計定義的各項功能 性能要求 6 在集成測試中發(fā)現(xiàn)的錯誤已經(jīng)得到修改 各級缺陷修復(fù)率達(dá)到標(biāo)準(zhǔn) 7 A B 類 BUG 不能存在 8 C D 類 BUG 允許存在 但不能超過單元測試總 BUG 的 50 9 E 類 BUG 允許存在 3 系統(tǒng)測試退出標(biāo)準(zhǔn) 1 系統(tǒng)測試用例設(shè)計已經(jīng)通過評審 2 按照系統(tǒng)測試計劃完成了系統(tǒng)測試 3 系統(tǒng)測試的功能覆蓋率達(dá) 100 4 系統(tǒng)的功能和性能滿足產(chǎn)品需求規(guī)格說明書的要求 5 在系統(tǒng)測試中發(fā)現(xiàn)的錯誤已經(jīng)得到修改并且各級缺陷修復(fù)率達(dá)到標(biāo)準(zhǔn) 6 系統(tǒng)測試后不存在 A B C 類缺陷 7 D 類缺陷允許存在 不超過總?cè)毕莸?5 8 E 類缺陷允許存在 不超過總?cè)毕莸?10 如果能夠執(zhí)行完美的黑盒測試 還需要進(jìn)行白盒測試嗎 黑盒測試 從用戶角度出發(fā) 根據(jù)規(guī)格說明設(shè)計測試用例 并不涉及程序的內(nèi) 部特性和內(nèi)部結(jié)構(gòu) 只依靠被測程序輸入和輸出之間的關(guān)系或程序的功能設(shè)計測 試用例 黑盒測試有兩個顯著特點 1 黑盒測試與軟件的具體實現(xiàn)過程無關(guān) 在軟件實現(xiàn)的過程發(fā)生變化時 測試用例仍然可以用 2 黑盒測試用例的設(shè)計可以和軟件實現(xiàn)同時進(jìn)行 這樣能夠壓縮總的開 發(fā)時間 黑盒測試主要是為了發(fā)現(xiàn)以下幾類錯誤 1 是否有不正確 遺漏或額外的功能實現(xiàn) 2 在接口上 輸入是否能正確的接受 能否輸出正確的結(jié)果 3 是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息 例如數(shù)據(jù)文件 訪問錯誤 4 性能上是否能夠滿足要求 5 是否有初始化或終止性錯誤 白盒測試 已知程序的內(nèi)部結(jié)構(gòu) 檢查內(nèi)部操作是否按規(guī)定執(zhí)行 主要對程 序細(xì)節(jié)進(jìn)行嚴(yán)密檢驗 針對特定條件和循環(huán)設(shè)計測試用例 對程序的邏輯路徑進(jìn) 行測試 通過在程序的不同點檢查程序狀態(tài) 確定實際狀態(tài)是否與預(yù)期的狀態(tài)一 致 白盒測試主要是想對程序模塊進(jìn)行如下檢查 1 程序的所有語句至少執(zhí)行一次 2 對所有的邏輯條件都能至少執(zhí)行一次 3 在循環(huán)的邊界和運(yùn)行的界限內(nèi)執(zhí)行循環(huán)體 4 測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性 等等 從以上可以看出就算執(zhí)行了完美的黑盒測試也是無法測試程序內(nèi)部特定部位 另外當(dāng)規(guī)格說明本身有誤 也不能發(fā)現(xiàn)問題 而白盒測試能對程序的內(nèi)部特定部 位進(jìn)行覆蓋測試 所以黑盒和白盒測試為互補(bǔ)關(guān)系 結(jié)合起來進(jìn)行測試用例的設(shè) 計更為合理 經(jīng)驗表明 通常在進(jìn)行單元測試時采用白盒測試方法 集成測試采用灰盒測試方 法 系統(tǒng)測試采用黑盒測試方法 軟件的缺陷等級應(yīng)如何劃分 1 致命錯誤