【正文】 可支持 性測試 四、系統(tǒng)測試 （ system testing ） 將經(jīng)過確認(rèn)測試的軟件，與計(jì)算機(jī)硬件、外設(shè)、 支持軟件等一起，在實(shí)際運(yùn)行環(huán)境下測試。 一般都應(yīng)該先進(jìn)行靜態(tài)測試 ， 再考慮動(dòng)態(tài)測試 。 ，根據(jù) 面向?qū)ο蟮闹饕匦裕枰淖儨y試策略和方法。 面向?qū)ο鬁y試類型 模型測試 類測試 交互測試 系統(tǒng)（子系統(tǒng)）測試 驗(yàn)收和發(fā)布測試 交互測試用于代替?zhèn)鹘y(tǒng)測試方法中的集成測試。而且，需求模型、設(shè)計(jì)模型和實(shí)現(xiàn)代碼之間還具備解釋特性。 二、 測試過程 通常測試步驟如下： 測試用例模型 ? 測試某些用例中的典型場景 ? 類及對象模型 ? 某些類測試其狀態(tài)模型 單個(gè)用例測試采取典型應(yīng)用場景的測試方法，用例模型的測試相當(dāng)于系統(tǒng)測試，測試的主要目標(biāo)是用例模型對于用戶需求的可跟蹤性。 倉庫名稱 倉庫位置 存貨品名及數(shù)量 訂單處理 客戶信譽(yù)度 A 東城 G1(200)， G5(100)， G6(1000)， G10(70)， G11(90) 85 B 西城 G1(1000)， G2(100)， G5(550)， G8(150)， G10(980) 95 C 北城 G1(220)， G4(300)， G5(350)， G7(400)， G10(700) 80 訂單主要信息：訂單號(hào)、送貨地點(diǎn)、貨物名稱及數(shù)量等。而 Date類的三個(gè)成員變量所屬的類是calendarUnit類的子類。 為確保類模型的正確性和完整性，只根據(jù)問題域測試類模型。 測試可以根據(jù)需求分析出發(fā)列出的一些典型場景 (順序圖模型所描述 )進(jìn)行。 一、糾錯(cuò)的原則 注意錯(cuò)誤的“群集現(xiàn)象”。是一種從特殊推斷一般的系統(tǒng)化 思考方法。發(fā)現(xiàn)錯(cuò)誤時(shí)，人工沿控制流 追蹤源代碼程序。 軟件糾錯(cuò)技術(shù) 軟件測試的目的是發(fā)現(xiàn)錯(cuò)誤，在發(fā)現(xiàn)錯(cuò)誤后，則應(yīng)按照一定的技術(shù)去糾正它。典型場景是用例模型的一個(gè)實(shí)例。 有效等價(jià)類 : D1=|一個(gè)月的第一天與最后一天 之間 | D2=|一個(gè)月的第一天 | D3=|1月 1日 | M1=|前一個(gè)月是 30天 | M2=|前一個(gè)月是 31天 | M3=|前一個(gè)月是 2月 | Y1=|非閏年 | Y2=|閏年 | Y3=|2022年 | 無效等價(jià)類 : D4=|本月的第一天 | D4=|本月的最后一天 | M4=|1| M5=|12| Y=|0| 用例 ID 月 日 年 預(yù)期結(jié)果 1 7 19 1998 1998年 7月 18日 2 9 19 2022 2022年 9月 18日 3 3 19 2022 2022年 3月 18日 4 7 1 1998 1998年 6月 30日 5 9 1 2022 2022年 8月 31日 6 3 1 1998 1998年 2月 28日 7 3 1 2022 2022年 2月 29日 8 1 1 1998 1997年 12月 31日 9 1 1 2022 2022年 12月 31日 10 1 1 2022 1999年 12月 31日 11 7 0 1998 無效輸入 12 7 32 2022 無效輸入 ………………………………………………………… 共 22個(gè)用例，其中無效用例 12個(gè)。 例 2 Date類是一個(gè)描述日期的類，其屬性為三個(gè)成員變量：年、月、日，在 Date類中，操作 decrease（）是使Date類的對象改變?yōu)楫?dāng)前日期的前一天。 以第三條功能 “ 根據(jù)訂單信息選擇倉庫，并將訂單發(fā)送給該倉庫 ” 為例，說明用例的選擇。 UML分析模型的每個(gè)模式，從嚴(yán)格意義上說都應(yīng)該經(jīng)過測試。 需求測試可以較早地發(fā)現(xiàn)需求中問題 如：不合理的項(xiàng)目 、 以及錯(cuò)誤地理解了用戶需求的項(xiàng)目 ，避免對于成本和資源的消耗 。 面向?qū)ο鬁y試類型 模型測試 類測試 交互測試 系統(tǒng)（子系統(tǒng)）測試 驗(yàn)收和發(fā)布測試 類測試即傳統(tǒng)測試中的單元測試 ， 即驗(yàn)證類的實(shí)現(xiàn)與類的規(guī)約是否一致的活動(dòng) 。 強(qiáng)調(diào)需求或設(shè)計(jì)的測試，通常以兩種方式進(jìn)行 ： 在沒有代碼的情況下進(jìn)行測試； 在有代碼的情況下進(jìn)行測試。 軟件測試方案是測試階段的關(guān)鍵技術(shù)問題 ， 基本目標(biāo)是選擇最少量的高效測試用例 ， 從而盡可能多地發(fā)現(xiàn)軟件中的問題 。 （ 3） ?測試和 ?測試 ?測試 是在開發(fā)機(jī)構(gòu)的監(jiān)督下，由個(gè)別用戶在確認(rèn)測試階段后期對軟件進(jìn)行測試，目的是評價(jià)軟件的 FLURPS（ 功能、局域化、可使用性、可靠性、性能和支持） ， 注重界面和特色。 對含有寫操作的子系統(tǒng)采用自頂而下。 確定集成過程的原則 自頂而下增值 優(yōu)點(diǎn)：能夠盡早發(fā)現(xiàn)系統(tǒng)主控方面的問題。組裝測試完畢。 ②測試方法以黑盒法為主，按照組裝方案進(jìn)行 測試。 也稱單元測試（ unit testing ) 考慮到被測模塊與其它模塊的聯(lián)系，因此測試時(shí)需要使用兩類 輔助模塊 來模擬其他模塊。 考慮到原因 2不可能同時(shí)為 1，加上 E約束。 標(biāo)識(shí)出規(guī)范中的原因與結(jié)果。 “ 非 ” 函數(shù) 若 a為 1，則 b為 0，否則 b為 1。 邊值分析法舉例 黑盒法應(yīng)用實(shí)例 對 FORTRAN編譯系統(tǒng)中的 DIMENSION語句進(jìn)行測試。 例如：輸入值的范圍是 ， 則可選擇用例 : –、 、 、 。 ② 選擇測試用例 等價(jià)分類法步驟 2. 邊值分析法 基本思想： 選擇等價(jià)類的邊緣值作為測試用例，讓每個(gè)等價(jià)類的邊界都得到測試，選擇測試用例既考慮 輸入 亦考慮 輸出 。 滿足以下覆蓋情況： ① A1, B =0 ② A1, B≠0 ③ A≤1, B =0 ④ A≤1, B≠0 ⑤ A=2, X1 ⑥ A=2, X≤1 ⑦ A≠2, X1 ⑧ A≠2, X≤1 選擇用例： [(2,0,4),(2,0,3)] ① ⑤ [(2,1,1),(2,1,2)] ② ⑥ [(1,0,3),(1,0,4)] ③ ⑦ [(1,1,1),(1,1,1)] ④ ⑧ 二、動(dòng)態(tài)測試方法 （ 2） 等 價(jià) 分 類 法 邊 值 分 析 法 錯(cuò) 誤 推 測 法 因 果 圖 法 (2)黑盒法 不考慮程序的內(nèi)部結(jié)構(gòu)與特性，只根據(jù)程序功能或程序的外部特性設(shè)計(jì)測試用例。 IF (A=2) OR (X1) THEN X:=X+1 END。 ⑤ 條件組合覆蓋 ： 執(zhí)行足夠的例子 ， 使得每個(gè)判定中條件的各種可能組合都至少出現(xiàn)一次 。 d — 定義 r — 引用 u — 未引用 R： duuuuu S ： uruuur Y： uuddru R= W=1/S Y=A**W Y=E*W Z=X+Y C=Z*S 1 2 3 4 5 6 只定義不用 未定義引用 連續(xù)定義 二、動(dòng)態(tài)測試方法 （ 1） 通過選擇適當(dāng)?shù)臏y試用例，執(zhí)行程序。 長期保存測試用例。但這是不可能的： 例：程序 P有兩個(gè)整型輸入量 X、 Y， 輸出量為 Z，在 32位機(jī)上運(yùn)行。 1963年美國飛往火星的火箭爆炸，原因是FORTRAN程序： DO 5 I=1， 3 誤寫為： DO 5 I=1. 3 損失 1000萬美元。只有選擇 — “高效的測試用例” 什么是 “高效的測試用例” ？ 如何選擇 “高效的測試用例” ？ 這就是本章討論的主要問題?。?！ 三、軟件測試的基本原則 充分注意測試中的群集現(xiàn)象。 ② 數(shù)據(jù)流分析圖 檢查分析變量的定義和引用情況。 白盒法 白盒法又稱為邏輯覆蓋法，其測試用例選擇，是按照不同覆蓋標(biāo)準(zhǔn)確定的。 1）選擇邏輯覆蓋標(biāo)準(zhǔn)。 A1 AND B=0 X:=X/A A=2 OR X1 X:=X+1 a b c