【正文】 測試） { { 軟件測試方法 軟件測試方法分為兩類：靜態(tài)分析、動(dòng)態(tài)測試 一、靜態(tài)分析方法 指以人工的 、 非形式化的方法對程序進(jìn)行分析和測試 。 READY Y0 N X:=Y X0 Y N Y 調(diào)用子程序 A B C D E 即執(zhí)行 ABC后，是不可能執(zhí)行路徑CDE的。 常用的方法： 白盒法 分析程序的內(nèi)部邏輯結(jié)構(gòu)，注意選擇適當(dāng)?shù)母采w標(biāo)準(zhǔn)，設(shè)計(jì)測試用例，對主要路徑進(jìn)行盡可能多的測試。 ② 判定覆蓋 ： 執(zhí)行足夠的測試用例，使得程序中每個(gè)判定至少都獲得一次 “ 真 ” 值和 “ 假 ” 值。 白盒法 常用的覆蓋標(biāo)準(zhǔn) 白盒法步驟： 例：用 白盒法測試以下程序段： Procedure（ VAR A， B， X： REAL）； BEGIN IF （ A1) AND (B=0) THEN X:=X/A 。 3）選擇確定測試用例。 A1 AND B=0 X:=X/A A=2 OR X1 X:=X+1 Y N Y N 邏輯結(jié)構(gòu) 語句覆蓋 使得程序中每個(gè)語句至少都能被執(zhí)行一次。 判定 /條件覆蓋 同時(shí)滿足判斷覆蓋和條件覆蓋。 1. 等價(jià)分類法 基本思想： 根據(jù)程序的 I/O特性，將程序的定義域劃分為有限個(gè)等價(jià)區(qū)段 —“ 等價(jià)類 ”，從等價(jià)類中選擇出的用例，具有“ 代表性 ”。 例如：每個(gè)學(xué)生可選修 13門課程 可以劃分一個(gè)有效等價(jià)類：選修 13門課程 。 分析步驟： A 先劃分等價(jià)類。 C 輸出值域的邊界。 B 按照輸入 /輸出值個(gè)數(shù)的邊界 。 設(shè)計(jì)用例：可檢索0篇 、 1篇 、 4篇 ， 和 5篇 （ 錯(cuò)誤 ） 。 語句格式為： DIMENSION ad[,ad] … ad為數(shù)組描述符， 形式為 n（ d[,] … 其中： n－ 數(shù)組名 ， 字母打頭的字母數(shù)字串 ， 長 6。根據(jù)這種關(guān)系可選擇高效的測試用例。 “ 或 ” 函數(shù) 若 a或 b為 1，則 d為 1，否則 d為 0。 O約束（唯一 ） — 選一 a、 b中僅有一個(gè)為 1。 原因 —輸入條件 結(jié)果 —輸出或系統(tǒng)變換 將因果圖轉(zhuǎn)換為有限項(xiàng)判斷表。滿足則修改文件。 11 11 ∨ 51 50 3 52 ∧ 1 2 E 發(fā) X 12 發(fā) X 13 修改文件 1 2 3 4 5 6 7 8 條 件 原 因 ① 1 1 1 1 0 0 0 0 ② 1 1 0 0 1 1 0 0 ③ 1 0 1 0 1 0 1 0 1 1 1 1 0 0 動(dòng) 作 結(jié) 果 0 0 0 0 1 1 1 0 1 0 0 0 0 1 0 1 0 1 測試用例 A3 A8 AMA？ B5 B4 BNB！ C2X6 DYPI 11 51 50 52 軟件測試的步驟 測試步驟及策略 所有測試過程都應(yīng)采用綜合測試策略；即先 作靜態(tài)分析，再作動(dòng)態(tài)測試。 檢查“錯(cuò)誤處理程序”本身的錯(cuò)誤。 驅(qū)動(dòng)模塊 （ driver） — 模擬主程序功能，用于向被測模塊傳遞數(shù)據(jù)，接收、打印從被測模塊返回的數(shù)據(jù)。測試方法以白盒法為主。 也稱為 聯(lián)合測試 或 集成測試， 重點(diǎn)測試模塊的接口部分，需設(shè)計(jì)測試過程使用的驅(qū)動(dòng)模塊或樁模塊。 M2 M3 M4 第二步，依次用 M MM4替代樁模塊 S S S3，每替代一次進(jìn)行一次測試。 自底而上 增值 M3 M6 M5 D1 D2 D3 M2 M4M1第四步，把已測試的子系統(tǒng)按程序結(jié)構(gòu)連接起來完成程序整體的組裝測試。 D6 深度優(yōu)先與寬度優(yōu)先 無論是 自頂而下增值還是自底而上增值，還可選擇 深度優(yōu)先 或者 寬度優(yōu)先 增值。 缺點(diǎn)：無法驗(yàn)證樁模塊是否完全模擬了下屬模塊的功能。 ② 盡早測試包含 I/O的模塊。 回歸測試 在回歸測試中自底而上，對其余部分（引起是對修改過的子系統(tǒng)）采用自頂而下。 （ 2）軟件配置復(fù)查 軟件配置 —指軟件工程過程中所產(chǎn)生的所有信 息項(xiàng)：文檔、報(bào)告、程序、表格、數(shù)據(jù)。 ?測試 由 支持軟件預(yù)發(fā)行 的客戶對 FLURPS進(jìn)行測試，主要目的是測試系統(tǒng)的可支持性。 ： （ 1）由課題組根據(jù)測試用例，自己演示系統(tǒng)所有功能。 因此 ， 無論哪一個(gè)測試階段 ， 都 應(yīng)該采用綜合測試策略 ， 才能夠?qū)崿F(xiàn)測試的目標(biāo) 。 面向?qū)ο蟮臏y試 而面向?qū)ο蟮臏y試貫穿軟件開發(fā)的全過程，是與開發(fā)過程密切相關(guān)，而又分離出來的過程。 面向?qū)ο鬁y試的特點(diǎn) ，通常以兩種方式進(jìn)行 ： 在沒有代碼的情況下進(jìn)行測試； 在有代碼的情況下進(jìn)行測試。 多態(tài)性 —提供強(qiáng)大的處理能力，但也增加測試的復(fù)雜性。 完整的類測試包括： ? 類屬性的測試 ? 類操作的測試 ? 可能狀態(tài)下的對象測試 注意：不能 “ 孤立 ” 進(jìn)行測試 ，操作測試應(yīng)該包括其可能被調(diào)用的各種情況 。 面向?qū)ο鬁y試類型 模型測試 類測試 交互測試 系統(tǒng)（子系統(tǒng)）測試 驗(yàn)收和發(fā)布測試 測試系統(tǒng)或獨(dú)立子系統(tǒng)，確保系統(tǒng)無明顯故障，并滿足用戶需求。 需求的質(zhì)量影響并決定了設(shè)計(jì)的質(zhì)量 在軟件開發(fā)過程模型中，需求、設(shè)計(jì)和編碼總是有一定的時(shí)序特性。 測試實(shí)際上也是一個(gè)項(xiàng)目。實(shí)際上，通常對用例模型、類對象模型以及用例中典型場景進(jìn)行測試。 三、 用例模型的測試 下面以一個(gè)訂貨中心系統(tǒng)的用例模型為例說明測試用例的設(shè)計(jì)。 假設(shè)訂貨中心共有三個(gè)倉庫，管理者要決定應(yīng)該選擇哪個(gè)倉庫處理訂單。 以上測試未觸及某個(gè)具體用例，體現(xiàn)了用例模型測試和用例測試的區(qū)別。 printDate（）是打印日期信息。 類的測試 date dd:Day mm:Month yy:Yers Date(pDay:integer,pMonth:integer,pYers:integer) decrease(argname) printDate() calendarUnit currentVal:Integer CalenderUnit(pVal:Integer) SetValue(pVal:Integer) decrease() Day Month Yers 注意：操作測試應(yīng)該考慮其可能被調(diào)用的各種情況 。 類模型是分析模型中的核心，它抽象出了問題域中的對象和實(shí)體，以及它們在問題域中的職責(zé)。 類模型的測試 針對每個(gè)類提問： (1)該類在問題域中對應(yīng)的實(shí)體 (或?qū)ο?)是什么？ (2)履行什么職責(zé)？ (3)在類圖中被賦予了哪些職責(zé)？ (4)該類在問題域中的職責(zé)和在類圖中的職責(zé)能匹配嗎？ (5)該類的每個(gè)數(shù)據(jù)屬性都是問題域所關(guān)心的嗎？ 針對類圖中的類之間的關(guān)系提問： (1)這種類關(guān)系是反映了問題域本質(zhì)的關(guān)系還是為管理類模型而引入的關(guān)系 ？ (如果類之間的關(guān)系并非反映問題域的本質(zhì) ， 那么這個(gè)關(guān)系的存在就值得懷疑 。 典型場景測試主要關(guān)注用例執(zhí)行情況，典型場景測試可能涉及到不止一個(gè)用例，通常測試的是系統(tǒng)的功能。 A、 綜合測試策略（靜態(tài)分析、白盒法為主，輔以黑盒法） B、 測試情況（根據(jù)覆蓋標(biāo)準(zhǔn)列出） C、 測試用例（保留） D、 查錯(cuò)記錄（數(shù)量、位置）、分析結(jié)果。糾錯(cuò)的關(guān)鍵是“錯(cuò)誤定位”。 注意在修改一個(gè)錯(cuò)誤的同時(shí)，又引入新的錯(cuò)誤。 歸納法 從測試結(jié)果發(fā)現(xiàn)的錯(cuò)誤入手，分析它們之間的 聯(lián)系查找錯(cuò)誤。 列舉可能 的原因 排除不適 當(dāng)?shù)脑? 對保留的假 設(shè)繼續(xù)推斷 證明 假設(shè) 糾正 錯(cuò)誤 收集更多 的數(shù)據(jù) 沒有剩余 不能 能 有剩余 演繹法排錯(cuò)的步驟