【正文】 三個訂單信息如下： 訂單號 送貨地點 貨物名稱及數(shù)量 客戶信譽 訂單 1 北城某集團公司 G1(200)， G5(100)， G10(40) 95 訂單 2 東城某街道 G5(10)， G6(5) 80 訂單 3 北城某街道 G4(10) 85 倉庫名稱 倉庫位置 存貨品名及數(shù)量 訂單處理 客戶信譽度 A 東城 G1(200)， G5(100)， G6(1000)， G10(70)， G11(90) 85 B 西城 G1(1000)， G2(100)， G5(250)， G8(150)， G10(98) 95 C 北城 G1(220)， G4(300)， G5(350)， G7(400)， G10(700) 80 結合考慮上面三個因素，以最少的成本取得最好的收益， 測試用例 1： 輸入：訂單 1 預期結果：選擇倉庫 B來處理訂單 (三個均可，大宗訂單，客戶信譽度高 )； 測試用例 2： 輸入：訂單 2 預期結果：選擇倉庫 A來處理訂單 (個人訂單，客戶信譽一般 )； 測試用例 3： 輸入：訂單 3 預期結果：選擇倉庫 C來處理訂單。 以上測試未觸及某個具體用例，體現(xiàn)了用例模型測試和用例測試的區(qū)別。 類模型是分析模型中的核心，它抽象出了問題域中的對象和實體，以及它們在問題域中的職責。 為確保類模型的正確性和完整性，只根據(jù)問題域測試類模型。測試方法是 評審會 。 類圖實際上由類和類之間的關系組成，評審會的檢查單可從以下兩個方面制定。 類模型的測試 針對每個類提問： (1)該類在問題域中對應的實體 (或對象 )是什么？ (2)履行什么職責？ (3)在類圖中被賦予了哪些職責？ (4)該類在問題域中的職責和在類圖中的職責能匹配嗎？ (5)該類的每個數(shù)據(jù)屬性都是問題域所關心的嗎？ 針對類圖中的類之間的關系提問： (1)這種類關系是反映了問題域本質的關系還是為管理類模型而引入的關系 ？ (如果類之間的關系并非反映問題域的本質 ，那么這個關系的存在就值得懷疑 。 ) (2)仔細檢查每個繼承關系 ， 到底是聚集關系還是繼承關系 ？ (3)針對關聯(lián)關系中的關聯(lián)數(shù)目 ， 提一些問題結合實際場景來考察 。 從模型的角度可以關心如下問題： (1)狀態(tài)模型刻畫了對象的生命周期嗎？ (2)針對每個狀態(tài)而言，狀態(tài)轉移觸發(fā)條件是狀態(tài)轉移的充分條件嗎？ (3)對象在問題域需要響應的所有條件是否在狀態(tài)模型中都有響應？ (4)關心對象在某些狀態(tài)中的動作，如果對象需要發(fā)送消息給其它對象，那么此時接收該消息的對象處在其聲明周期的什么階段？ (5)從初始狀態(tài)開始 ， 每個狀態(tài)都可以達到嗎 ？ 類狀態(tài)模型的測試 類狀態(tài)模型描述了一個對象在問題域中的活動歷程。 在分析階段，識別的對象還只是停留在較粗的層次上，因此，對象狀態(tài)模型的測試通常只能采用評審會的辦法。只測試在問題域中非常重要的對象，如電梯系統(tǒng)中的電梯對象。 上述五個問題可以作為評審會問題檢查單的選擇。 對問題 (1)： 檢查狀態(tài)模型對于對象狀態(tài)的劃分，一旦出現(xiàn)識別的狀態(tài)不足，或者某些狀態(tài)超出問題域的關心，分析原因，分析員在評審會報告想法和理由。 對問題 (2)： 檢查狀態(tài)轉移條件，驗證當觸發(fā)條件滿足時是否會出現(xiàn)狀態(tài)轉移，要求觸發(fā)條件是最簡化的 (無冗余條件 )。 對問題 (3)： 通過一張對照表可以找出答案。 對問題 (4)： 檢查較復雜，容易發(fā)現(xiàn)分析錯誤的一個環(huán)節(jié)。通常，分析員以為進行交互的其它對象都處于 “ 良好 ” 狀態(tài)，但這個假設常常不能成立，因為兩個不同的對象可能與相應的事件會有交叉 (如定時事件 )。因此，當當前分析的對象發(fā)生了狀態(tài)轉移時，其它對象也發(fā)生了狀態(tài)轉移，所以在對象發(fā)送消息給其它對象時，也要注意接收該消息的對象是否處于合適的狀態(tài)中。 對問題 (5)： 如果某個狀態(tài)根本就不可達到，那么可以斷定分析模型有錯誤。 類級別的單元測試中，狀態(tài)模型可以輔助進行測試用例的模型。 順著不同的狀態(tài)演變路徑來測試對象的動作行為 (操作序列 )，如帳號對象的狀態(tài)圖。 open setup deposit (initial) deposit withdraw balance count withdraw (final) close 空帳號 帳號設置 工作帳號 無效帳號 當空帳號 銀行帳號共有 5個生命周期狀態(tài)，設計下面的測試用例： (1)測試用例 1： open, setup, deposit (initial), withdraw (final), close。 (2)測試用例 2： open, setup, deposit (initial), deposit, balance count, withdraw (final), close。 (3)測試用例 3： open, setup, deposit (initial), deposit, withdraw, balance count, withdraw (final), close. 上述測試用例覆蓋每個狀態(tài)，并增量測試每個狀態(tài)的轉移。 該例不涉及復雜對象之間的交互情況，有對象交互的測試用例設計將更加困難。 如果通過覆蓋狀態(tài)模型中的每個狀態(tài)和每個狀態(tài)轉移，那么就可以測試到對象之間的各種情況。 類狀態(tài)模型的測試 典型場景是指系統(tǒng)用戶經(jīng)常使用系統(tǒng)的方式。典型場景是用例模型的一個實例。 典型場景測試主要關注用例執(zhí)行情況，典型場景測試可能涉及到不止一個用例，通常測試的是系統(tǒng)的功能。 測試可以根據(jù)需求分析出發(fā)列出的一些典型場景 (順序圖模型所描述 )進行 。 如果無典型場景的順序圖模型 ，可以把幾個不同用例的順序圖模型聯(lián)合起來 ， 并選擇一條對象交互鏈作為一個典型場景 ， 這個場景就是測試用例 。 典型場景的測試 5 軟件糾錯技術 軟件測試的目的是發(fā)現(xiàn)錯誤，在發(fā)現(xiàn)錯誤后，則應按照一定的技術去糾正它。糾錯的關鍵是“錯誤定位”。 一、糾錯的原則 注意錯誤的“群集現(xiàn)象”。 不能只修改錯誤的征兆、表現(xiàn)。還應該修改錯誤的本質。 注意在修改一個錯誤的同時，又引入新的錯誤。 二、糾錯的技術 硬性糾錯 又稱為蠻干法，是使用較多，效率較低的方法。 主存信息轉儲法 關鍵部分設置打印語句 使用自動糾錯工具 回 溯法排錯 適用于小程序。發(fā)現(xiàn)錯誤時，人工沿控制流 追蹤源代碼程序。 歸納法 從測試結果發(fā)現(xiàn)的錯誤入手，分析它們之間的 聯(lián)系查找錯誤。是一種從特殊推斷一般的系統(tǒng)化 思考方法。 收集 有關數(shù)據(jù) 組織數(shù)據(jù) 研究數(shù)據(jù) 間的關系 提出假設 證明假設 糾正錯誤 能 能 不能 不能 列出所有已知 的測試用例和 程序執(zhí)行結果 常用的構造 線索的技術 是“分類法” 分析線索之間 的關系，找出 矛盾，設計出 錯原因的假設 歸納排錯法步驟 將假設與原始線索 或數(shù)據(jù)進行比較， 能否解釋現(xiàn)象，證 明假設。 yes no What When where How 演繹法排錯 演繹法是一種從一般原理出發(fā)，經(jīng)過排除和精化的過程，推導出結論的方法。 列舉可能 的原因 排除不適 當?shù)脑? 對保留的假 設繼續(xù)推斷 證明 假設 糾正 錯誤 收集更多 的數(shù)據(jù) 沒有剩余 不能 能 有剩余 演繹法排錯的步驟