《《軟件測試技術(shù)》PPT課件.ppt》由會員分享，可在線閱讀，更多相關(guān)《《軟件測試技術(shù)》PPT課件.ppt（74頁珍藏版）》請在裝配圖網(wǎng)上搜索。

Module2 軟件測試技術(shù) 主要內(nèi)容 軟件測試基本方法靜態(tài)分析白盒測試黑盒測試測試模式范圍測試說明書測試風險測試情景測試組合測試探索測試實際練習 什么是靜態(tài)分析 不實際運行程序 通過檢查和閱讀等手段來發(fā)現(xiàn)錯誤并評估代碼質(zhì)量的軟件測試技術(shù) 作用通過對代碼標準及質(zhì)量的監(jiān)控提高代碼可靠性盡可能早地通過對源代碼的檢查發(fā)現(xiàn)缺陷組織代碼審核定位易產(chǎn)生錯誤的模塊非常有效的質(zhì)量保證手段越來越多地被采用 靜態(tài)分析的主要內(nèi)容 檢查需求檢查設(shè)計檢查代碼 檢查需求 需求的標準完整性是否完整描述一個功能正確性是否正確反應(yīng)客戶要求可行性必要性Goldplating 無二義性會引起歧義嗎可驗證性測試用例怎么寫 實施無關(guān)性 需求規(guī)格說明的標準完整性是否包含所有需求FURPS一致性相互矛盾重復 需求檢查練習 例1產(chǎn)品必須在固定的時間間隔內(nèi)提供狀態(tài)信息 并且每次時間間隔不得小于60秒 完整嗎 清晰嗎 例2分析程序應(yīng)該能生成HTML標記錯誤的報告 從而使HTML初學者可以用它來快速排錯 是否有歧義 可驗證嗎 例3如果可能的話 應(yīng)當根據(jù)系統(tǒng)貨物編號列表 在線確認輸入的貨物編號 如果可能的話 是什么意思 需求檢查練習 例4產(chǎn)品不應(yīng)該提供將帶來災難性后果的查找和替換選擇 真正的需求是什么 例5系統(tǒng)對標準XYZ1 4 1的支持是可選的 有歧義嗎 例6當用戶選擇 緊湊內(nèi)存 選項時 程序通過Huffman解析矩陣方法將郵件列表數(shù)據(jù)壓縮到相應(yīng)的大小 可測嗎 代碼無關(guān)嗎 規(guī)格說明用語清單 絕對的肯定總是 每一種 所有 沒有 從不注意隱含的假設(shè)當然 因此 顯然 必然模棱兩可的詞某些 有時 常常 通常 經(jīng)常 太多 幾乎不可測的描述良好 迅速 廉價 高效 穩(wěn)定隱藏的需求已處理 已拒絕 已忽略 已消除缺少的分支如果 那么 沒有 否則 分支 檢查設(shè)計 在編碼開始前進行檢查功能設(shè)計說明 消除歧義功能的用意 總體位置輸入 輸出可能的錯誤 例外接口定義交互細節(jié)實施建議 檢查代碼 通過檢查代碼發(fā)現(xiàn)模塊中的錯誤 通過代碼檢查能夠發(fā)現(xiàn)大部分的錯誤 檢查代碼 研究分析代碼而不用實際執(zhí)行包括可執(zhí)行的代碼和非執(zhí)行的代碼提供的信息度量標準容易產(chǎn)生錯誤的代碼代碼規(guī)則的執(zhí)行流圖和調(diào)用圖的分析 80 的問題是由于20 的代碼引起的 度量元 復雜度度量McCabeHalstead嵌套級別 最大 平均 規(guī)格度量行數(shù)語句數(shù)注釋數(shù)聲明數(shù) 代碼審核內(nèi)容 分析容易產(chǎn)生錯誤的代碼 控制流分析非結(jié)構(gòu)化的代碼死代碼數(shù)據(jù)流分析未定義的數(shù)據(jù)的使用未使用的數(shù)據(jù)信息流分析斷言分析 代碼審核內(nèi)容 流圖和調(diào)用關(guān)系圖作為理解代碼的幫助作為審核符合設(shè)計的幫助作為測試設(shè)計的幫助作為調(diào)試的幫助代碼規(guī)則的執(zhí)行針對不同語言的特征格式和形式命名規(guī)范度量標準的強制 靜態(tài)分析方法 走查 Walkthrough審查 Inspection自動化工具 走查 Walkthrough 開發(fā)組內(nèi)部進行的采用講解 討論和模擬運行的方式查找錯誤的活動限時 避免跑題參加人員經(jīng)驗豐富的開發(fā)人員和本模塊相關(guān)的開發(fā)人員本項目組的新人由本模塊的開發(fā)者進行講解 回答問題并記錄不要現(xiàn)場修改檢查要點邏輯錯誤代碼標準 規(guī)范 風格 審查 Inspection 開發(fā)組 測試組和相關(guān)人員 QA 產(chǎn)品經(jīng)理等 聯(lián)合進行 采用講解 提問并使用Checklist方式進行的查找錯誤的活動 以會議的形式 制定目標 流程 規(guī)則和結(jié)果報告 相關(guān)資料要在會議前下發(fā)并閱讀 參加人員經(jīng)驗豐富的開發(fā)人員和本模塊相關(guān)的開發(fā)人員測試組和相關(guān)人員 審查 Inspection 由另外一名開發(fā)者進行講解 其他開發(fā)者主要按照Checklist進行提問并填表 本模塊開發(fā)者回答問題并記錄不要現(xiàn)場修改檢查要點設(shè)計需求代碼標準 規(guī)范 風格文檔的完整性和一致性 自動化工具 基于編碼規(guī)則LogiscopeLDRANuMega的CodeReview基于質(zhì)量度量LogiscopeMcCabeLDRA 如何使靜態(tài)分析更有效 必須引入 別人 的眼睛根據(jù)團隊及項目的實際情況 設(shè)計合理的實施辦法有準備地進行應(yīng)該有包含所有關(guān)注要點的Checklist把握會議時間每次以2小時為限可以進行多次 白盒測試 把測試對象看做一個透明的盒子利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息 設(shè)計或選擇測試用例 對程序所有邏輯路徑進行測試通過在不同點檢查程序的狀態(tài) 確定實際的狀態(tài)是否與預期的狀態(tài)一致 白盒測試目標 盡可能高的覆蓋率對程序模塊的所有獨立的執(zhí)行路徑至少測試一次對所有的邏輯判定 取 真 與取 假 的兩種情況都至少測試一次在循環(huán)的邊界和運行界限內(nèi)執(zhí)行循環(huán)體測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性執(zhí)行效率 邏輯覆蓋 以程序內(nèi)部的邏輯結(jié)構(gòu)為基礎(chǔ)的設(shè)計測試用例的技術(shù)主要包含以下幾種情況語句覆蓋判定覆蓋條件覆蓋路徑覆蓋 邏輯覆蓋 語句覆蓋設(shè)計若干個測試用例 使得每一可執(zhí)行語句至少執(zhí)行一次判定覆蓋設(shè)計若干個測試用例 使得程序中每個判斷的取真分支和取假分支至少經(jīng)歷一次判定覆蓋又稱為分支覆蓋條件覆蓋設(shè)計若干個測試用例 使得程序中每個判斷的每個條件的可能取值至少執(zhí)行一次路徑覆蓋設(shè)計足夠的測試用例 覆蓋程序中所有可能的路徑 黑盒測試 把測試對象看做一個黑盒子不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性只依據(jù)程序的需求規(guī)格說明書檢查程序的功能是否符合它的功能說明 黑盒測試 在程序接口上進行測試主要是為了發(fā)現(xiàn)以下錯誤是否有不正確或遺漏了的功能 在接口上 輸入能否正確地接受 能否輸出正確的結(jié)果 是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息 例如數(shù)據(jù)文件 訪問錯誤 性能上是否能夠滿足要求 是否有初始化或終止性錯誤 黑盒測試 在過去的測試中 我們常從開發(fā)者的視角出發(fā)分析代碼和規(guī)格說明書 規(guī)格說明書僅能給我們提供一部分風險類型 我們必須在更廣的范圍內(nèi)進行測試 不同領(lǐng)域的專家能夠看到不同的使系統(tǒng)產(chǎn)生缺陷的機會 并設(shè)計出能夠引發(fā)這些缺陷的測試用例 跳出框框進行思考和設(shè)計 是黑盒測試的精髓 黑盒測試模式 模式與技術(shù) 測試技術(shù)是進行測試的方法 測試模式指用于指導設(shè)計測試的思路 一種測試模式可能會用到一種或多種技術(shù) 設(shè)計任何測試需要包含五個方面的內(nèi)容 測試什么 試圖發(fā)現(xiàn)什么問題 如何判斷測試通過或失敗 怎么進行測試 誰來執(zhí)行測試 測試模式 范圍測試規(guī)格說明測試風險測試情景測試探索測試組合測試 模式 范圍測試 采用 抽樣 的策略 從眾多的可能情況中抽取合理的典型用例常見辦法等價類劃分將輸入劃分成若干等價組 從每一類中取一個代表值作為整個組的代表 如果一個測試發(fā)現(xiàn)的缺陷 也能被另一個測試發(fā)現(xiàn) 則兩個測試等價 邊界值測試邊界值是一個等價類向另一個等價類過度的點 程序在邊界更容易出錯 所以邊界值和邊界附近的值是最佳的測試點 范圍測試 優(yōu)點可以通過較少的用例檢測出最可能發(fā)生的錯誤很直觀的方法 易于普及弱點漏掉不位于邊界或典型值的錯誤邊界不易確定 范圍測試典型案例 三角型問題輸入 a b c 分別為三角形的三個邊長值輸出 該三角形為等邊 等腰 或不等邊如何設(shè)計測試用例 選擇什么樣的輸入值 模糊邊界問題 理論上說 等價類劃分的任務(wù)是將輸入分類成相互獨立并排斥的范圍 3D動畫游戲?qū)︼@卡的要求處理速度畫面效果兼容性必須測試游戲程序可支持的顯卡 模糊邊界問題 續(xù) 如何從數(shù)目眾多的顯卡中選出典型的測試對象 分類的思路市場占有率時間范圍品牌 驅(qū)動工業(yè)標準 芯片支持的操作系統(tǒng) 劃分等價類 設(shè)備兼容性測試顯示了多維空間無法明確劃分的情況 范圍測試成功的關(guān)鍵是記住 分區(qū)只是一種抽樣策略 它的目標是從大量潛在的測試中 選出最為合理并有價值的幾個代表 好的抽樣策略依賴于我們對具體領(lǐng)域的了解 而不僅僅是說明書 如果你知道多種使程序出錯的方法 那么對每一種錯誤 尋找最有可能使錯誤產(chǎn)生的設(shè)備 型號 版本 劃分等價類 客戶的問題 等價類方法對那些要求支持所有OEM系統(tǒng) 所有聲卡和顯卡 所有操作系統(tǒng) 及所有技術(shù) 例如DirectX3和5 的人非常有用 那么測試人員怎樣才能保證他的等價類表可以提供很好的覆蓋率 令人失望但真實的回答 即使分析和執(zhí)行的過程非常好 我們也很可能錯過一個可能造成缺陷的設(shè)備或驅(qū)動 或它們的組合 模式 規(guī)格說明測試 檢查產(chǎn)品滿足所有規(guī)格 需求文檔中的每一條陳述 檢查用戶手冊 安裝步驟 操作范例 優(yōu)點徹底分析每個被測功能項避免向客戶傳遞虛假或誤導信息 減少支持成本 客戶申告弱點未考慮交互影響任何沒有列入規(guī)格說明 和處理不當?shù)膯栴} 沒有規(guī)格說明怎么辦 所有存在的文檔內(nèi)部版本的軟件變更備忘錄用戶手冊草稿 或舊版本 有關(guān)產(chǎn)品的文章公布的樣式指南或UI標準第三方產(chǎn)品兼容性測試系列公布的規(guī)范內(nèi)部備忘錄 項目經(jīng)理給工程師的功能描述 采訪參與上一個版本開發(fā)的人員查看舊版本的客戶電話記錄 查看現(xiàn)場發(fā)現(xiàn)的缺陷易用性測試結(jié)果Beta測試結(jié)果 沒有規(guī)格說明怎么辦 市場演示 產(chǎn)品概念推銷缺陷報告及回復工程師對產(chǎn)品的審核會個人采訪開發(fā)負責人技術(shù)寫作人員客戶服務(wù)領(lǐng)域?qū)＜翼椖拷?jīng)理察看header文件 源代碼 數(shù)據(jù)庫表定義原型 實驗室有關(guān)原型的記錄 模式 風險測試 從可能發(fā)生的問題 風險 出發(fā) 設(shè)計測試 先找最大的缺陷 風險測試實例失敗模式和影響分析從預報的缺陷清單中抽取測試用例壓力測試 安全性測試測試預期的或擔心的錯誤 風險測試 優(yōu)點測試作用大直觀的測試弱點沒有識別或想像到的風險 風險測試 主要任務(wù)識別風險因素 系統(tǒng)發(fā)生故障的情形 對每一種風險因素 設(shè)計有足夠能力對付它的測試評估風險測試的覆蓋率 查找測試工作的漏洞評估測試結(jié)果和發(fā)現(xiàn)的缺陷 判斷這些測試所針對的風險是什么 考慮是否有更有效的測試方法 哪里有風險 質(zhì)量屬性能力可靠性易用性性能易安裝性兼容性可支持性可測試性可移植性可維護性 哪里有風險 從公布的缺陷統(tǒng)計和缺陷分類中 尋找你感興趣的缺陷 從清單中找出一個缺陷分析你的軟件是否會出現(xiàn)這個缺陷如果從理論上分析被測系統(tǒng)可能存在這個缺陷 思考如何把它找出來思考這個缺陷存在的可能性有多大 及它的嚴重性針對這類缺陷設(shè)計一個或多個測試公布的缺陷信息往往是過時的 且與你的被測系統(tǒng)相差很大 應(yīng)逐步積累并建立自己的缺陷模式 哪里有風險 需求 不完整 不正確 不清楚新東西 新功能可能出錯新技術(shù) 新的概念可能引發(fā)新錯誤學習曲線 由于無知或習慣而造成的錯誤修改 變更可能會破壞舊的代碼倉促的工作 經(jīng)費和時間不足造成低質(zhì)量工作疲勞的程序員 長時間的持續(xù)工作造成低效和錯誤 模式 情景測試 模擬真實使用情景的測試情景測試實例依照商業(yè)規(guī)范 客戶數(shù)據(jù) 或競爭對手的結(jié)果 對產(chǎn)品進行評估測試生命周期測試特點很現(xiàn)實 來自真實用戶或競爭對手的情形 測試通過或失敗的判定很明確測試覆蓋多個特征或功能每個測試都關(guān)系到某些涉眾 stakeholder 的利益 情景測試 優(yōu)點復雜 真實的事件 可以處理那些不易模擬的情形 能暴露隨時間發(fā)展而發(fā)生的問題弱點單個功能失敗可以使測試效率降低必須仔細考慮測試的覆蓋率 構(gòu)造情景的方法 目標驅(qū)動 某人想得到X 他怎么能得到X 序列驅(qū)動 某人 或系統(tǒng) 通常按照某個順序完成任務(wù)X 完成X所要經(jīng)歷的常見順序是什么 交易驅(qū)動 我們想完成一樁交易 如開銀行帳戶或發(fā)送信息 完成這個交易的步驟 數(shù)據(jù) 輸出和顯示是什么 從競爭對手的產(chǎn)品中獲取思路 文檔 廣告 幫助等 所有關(guān)于如何最好或最新穎地使用產(chǎn)品的途徑 我們的產(chǎn)品如何完成這些事情 構(gòu)造情景的方法 競爭對手的輸出 嗨 看看他們生成的這些漂亮的文件 或者 瞧他們能夠把語法錯誤的網(wǎng)頁顯示出來 咱們的產(chǎn)品能嗎 客戶的表格 這兒有幾種客戶在業(yè)務(wù)中使用的表格 我們的程序能處理 讀 填寫 顯示 確認 它們嗎 用例分析中提到的情景XP開發(fā)過程中的客戶故事 電視連續(xù)劇法 基于實際生活經(jīng)驗構(gòu)造情景 即用戶 客戶的經(jīng)驗 夸大其中的每一個方面 例如 對每一個變量 輸入一個極端的值例如 如果一個情景包含一個重復的環(huán)節(jié) 那就重復很多很多次將測試用例所處的環(huán)境設(shè)置得很糟糕 減少內(nèi)存 減少硬盤空間 網(wǎng)絡(luò)故障 打印機分辯率低 視頻分辨率低 等等 不要忘了所有可能發(fā)生問題的情形 將所有元素包含在一個 真實 的故事中 模式 組合測試 系統(tǒng)化地對測試變量進行合理組合為使某些缺陷發(fā)生 或重現(xiàn) 你必須有意識地控制兩個或多個變量的值 將數(shù)目眾多的組合減少到合理的程度組合測試實例組合多個變量的邊界值組合多個測試 因果圖 測試優(yōu)點可以用很少的測試達到很高的測試覆蓋率弱點可信度 組合測試實例 一個汽車保險公司的保險購買系統(tǒng)保險的檔次分為 1類 高風險 2類 中等風險 3類 低風險 系統(tǒng)根據(jù)用戶的年齡及駕齡 判斷應(yīng)給予哪一類的保險 組合測試實例 保險公司政策年齡 18 駕齡不計 拒絕服務(wù)18 年齡 22 且駕齡 1 1類18 年齡 22 且1 駕齡 2類22 年齡 55 且駕齡 1 1類22 年齡 55 且1 駕齡 3 2類22 年齡 55 且3 駕齡 3類55 年齡 75 且駕齡 1 1類55 年齡 75 且1 駕齡 2類75 年齡 駕齡不計 拒絕服務(wù) 組合測試實例 組合表 模式 探索測試 測試文檔缺少或不足的軟件時 測試人員必須在測試的過程中學習產(chǎn)品 及測試用例 策略可能發(fā)現(xiàn)的缺陷 邊學邊計劃 邊測試探索測試實例對整個產(chǎn)品進行熟練的探索測試游擊式測試 對某個方面進行一段苛刻的測試 緊急測試第三方構(gòu)件測試故障排除 發(fā)現(xiàn)缺陷后的補充測試 探索測試 在同一時間段里 了解產(chǎn)品了解市場了解導致產(chǎn)品失敗的途徑了解產(chǎn)品弱點學習如何測試產(chǎn)品測試產(chǎn)品報告問題要求修復在對產(chǎn)品已有了解的基礎(chǔ)上 設(shè)計新測試 探索測試 優(yōu)點關(guān)注用戶 關(guān)注風險利用測試者的能力應(yīng)變能力強可以避免重復的分析和測試高缺陷發(fā)現(xiàn)率弱點知道的越少 錯過的缺陷越多受測試者弱點的限制 可通過好的協(xié)調(diào)管理減輕對個人能力要求很高 沒有監(jiān)督的初期測試人員不能很好完成任務(wù) 需要注意的問題 適應(yīng)程度會影響發(fā)現(xiàn)問題的可能缺乏足夠信息會阻礙探索昂貴或困難的系統(tǒng)設(shè)置可能增加探索的耗費探索的反饋環(huán)節(jié)可能會比較慢問題可能會重復出現(xiàn)如果沒有完善的測試用例和過程 MTBF MeanTimeBetweenFailure 可能較低 探索的風格 經(jīng)驗豐富 老練的探索者形成自己特有的風格 通過觀察這些經(jīng)驗豐富的探索者 可以發(fā)現(xiàn)非常不同的風格 配對測試 PairedTesting 與XP開發(fā)模式中的PairedProgramming類似兩個測試人員工作結(jié)伴完成測試工作自愿結(jié)合負責某項測試任務(wù)的人 征召一個或多個同伴 每次一人 輔助自己的工作一個測試人員負責操作 另一人負責提供思路 意見 做記錄 詢問問題 找參考資料 等 探索測試模式的推薦方法 配對測試過程 從項目概要出發(fā) 選擇一個需要化一天或更少時間完成的任務(wù)略述將要進行的一期測試活動測試什么用什么工具使用什么測試方法可能有哪些風險關(guān)注什么樣的缺陷檢查什么文檔期望的結(jié)果是什么 每期測試活動一般持續(xù)60 90分鐘 配對測試的好處 有利于開發(fā)思路 產(chǎn)生建議的活動啟發(fā)式 開放式 多維的迫使測試人員解釋的思路 或?qū)e人的建議做出反應(yīng)交流的過程能夠促使更多的想法產(chǎn)生鼓勵創(chuàng)造性思維有助于獲得更多深入的信息有助于讓一個測試人員集中精力 進行持續(xù)的測試 非操作的測試人員可以 收集和記錄思路和零星的想法在第二臺機器上再現(xiàn)某個事件獲取執(zhí)行測試所需要的資源 查手冊 工具 打電話 找開發(fā)人員 等等 配對測試的好處 提供缺陷報告的質(zhì)量重現(xiàn)的可能更大所有報告的內(nèi)容都有第二個人審閱對每個設(shè)計問題進行合理性檢查有效的培訓方式對新手極有效的培訓不斷從別人那里學習新知識對經(jīng)驗豐富的測試人員快速掌握新領(lǐng)域很有幫助還有一些技術(shù)上的益處可以在兩臺機器上進行同樣的測試人工的負載測試易于完成一些需要多角色交互的測試 一些建議 應(yīng)允許初級測試人員執(zhí)行操作和發(fā)表看法 而不只是做一些雜物 責任應(yīng)當明確 配對測試組中的一人應(yīng)對任務(wù)的完成付責任 有些內(nèi)向的人可能需要一些獨立思考和工作時間 以準備團隊的合作 有些人有很強的思維主導性 不愿意接受別人的意見 需要接受一定的培訓 測試模式小結(jié) 測試模式只是輔助測試人員構(gòu)思測試的框架 并不局限于列舉的這些 模式相互可以重疊 例如你可以采用 基于規(guī)范說明的組合測試基于風險的情景測試探索式的范圍測試 最重要的是思考的方式 而不是教條 你可以總結(jié)自己的模式 并不斷提高 黑盒測試技術(shù)練習 BroadbandGateway 互聯(lián)網(wǎng) 服務(wù)器 ISPRouter 用戶電腦 被測系統(tǒng) 規(guī)格說明及相關(guān)信息 具有4個10 100Base TEthernet端口 可與PC網(wǎng)卡相連LAN側(cè)支持DHCP協(xié)議 可給PC分配動態(tài)IPWAN側(cè)通過一個寬帶口與ISP路由器相連 最高可支持雙方向速率1 5MbpsWAN側(cè)支持NetworkAddressTranslation NAT 協(xié)議有一個電源開關(guān)Router啟動后 自動與ISPRouter取得連接 獲得WAN側(cè)IP地址 默認網(wǎng)關(guān)地址 及DNS 用戶電腦可同時通過該Router訪問互聯(lián)網(wǎng) 進行上傳及下載前面板有三個指示燈 分別顯示電源開啟 ISP連接 網(wǎng)絡(luò)數(shù)據(jù)活動 WAN側(cè)連接 規(guī)格說明及相關(guān)信息 需要在一臺機器上安裝管理軟件 并通過Ethernet連接在Router上設(shè)置以下參數(shù) LANIP地址范圍 默認為 192 168 0 1 192 168 0 255Router的LAN端IP地址 默認為 192 168 0 1管理員名稱和密碼 默認為 admin 1234可以啟動防火墻功能 進一步進行設(shè)置 略 用戶可通過管理軟件查看網(wǎng)絡(luò)使用情況LAN側(cè)IP分配WAN側(cè)IP及DNS信息與ISP連接的實際帶寬 分組練習 分別按照下面模式設(shè)計測試用例規(guī)范說明模式根據(jù)前面的說明 及你對Router的了解 分析被測系統(tǒng)可能具備的功能對每個功能 設(shè)計可能發(fā)現(xiàn)缺陷的測試用例風險模式列出被測系統(tǒng)可能出現(xiàn)的問題 風險 對每種可能的問題 設(shè)計相應(yīng)的測試用例情景模式構(gòu)想被測系統(tǒng)可能經(jīng)歷的情景 包括每一種情景中可能出現(xiàn)的 意外 設(shè)計一組情景的測試用例 測試練習分析 對每個測試用例 分析 可能發(fā)現(xiàn)的問題是否有其它的方法發(fā)現(xiàn)同樣問題 哪種更有效匯總幾種模式所產(chǎn)生出的測試 分析 各模式的長短處相互補充能力 回顧 軟件測試技術(shù) 靜態(tài)測試 動態(tài)測試 代碼走查 代碼審查 代碼評審 黑盒測試 白盒測試 規(guī)范說明測試 情景測試 探索測試 語句覆蓋 分支覆蓋 路徑覆蓋 范圍測試 風險測試 EndofModule2