【正文】 第三步 ， 設(shè)計驅(qū)動模塊 D D5 和 D6模擬調(diào)用 ， 分別對新子系統(tǒng)進(jìn)行測試 。 A B C D H G J E F I K L M N 確定集成過程的原則 自頂而下增值 優(yōu)點：能夠盡早發(fā)現(xiàn)系統(tǒng)主控方面的問題。 集成過程的原則 ① 盡早測試關(guān)鍵模塊。 對含有寫操作的子系統(tǒng)采用自頂而下。 選擇測試人員 選擇測試用例 實際運行測試 軟件計劃 用戶文檔 開發(fā)文檔 源程序文本 支持環(huán)境 有效性 測試 軟件 配置 審查 管理 機(jī)構(gòu) 裁決 專家 鑒定會 交用戶 運行維護(hù) 測試報告 軟件配置 確認(rèn)測試步驟 （ 1）有效性測試 制定測試計劃，運用黑盒法，驗證軟件特性是否與需求符合。 （ 3） ?測試和 ?測試 ?測試 是在開發(fā)機(jī)構(gòu)的監(jiān)督下，由個別用戶在確認(rèn)測試階段后期對軟件進(jìn)行測試，目的是評價軟件的 FLURPS（ 功能、局域化、可使用性、可靠性、性能和支持） ， 注重界面和特色。軟件工程課程設(shè)計的驗收測試， 19周進(jìn)行。 A、 綜合測試策略（靜態(tài)分析、白盒法為主，輔以黑盒法） B、 測試情況（根據(jù)覆蓋標(biāo)準(zhǔn)列出） C、 測試用例（保留） D、 查錯記錄（數(shù)量、位置）、分析結(jié)果。 需求和設(shè)計是代碼產(chǎn)生的基礎(chǔ)，需要對需求和設(shè)計進(jìn)行測試。 需求模型 、 設(shè)計模型和實現(xiàn)代碼之間還具備解釋特性 ， 即設(shè)計解釋了需求 ， 實現(xiàn)代碼解釋了設(shè)計 。 同時也減少了返工的幾率 ， 應(yīng)盡早發(fā)現(xiàn)并解決這些問題 。 在 UML中，對需求模型的測試： ● 評審； ● 事務(wù)流 (場景 )模型等方法測試 (需結(jié)合具體的模型描述 )； 測試的目的是發(fā)現(xiàn)代碼中的錯誤，測試的關(guān)鍵是確定高效的測試用例。 二、參加評審人員： 用戶，軟件項目負(fù)責(zé)人，軟件工程師，軟件配置管理人員，軟件質(zhì)量保證人員；軟件獨立驗證與確認(rèn)人員，軟件開發(fā)無關(guān)的專家。 UML分析模型的每個模式，從嚴(yán)格意義上說都應(yīng)該經(jīng)過測試。通過系統(tǒng)的用戶對系統(tǒng)的功能需求來設(shè)計測試用例。 分析模型測試內(nèi)容 用例模型的測試相當(dāng)于系統(tǒng)測試，測試的主要目標(biāo)是用例模型對于用戶需求的可跟蹤性。 用例模型的測試 下面以一個訂貨中心系統(tǒng)的用例模型為例說明測試用例的設(shè)計。 (3)系統(tǒng)中的事件一定要告訴管理者嗎？ 答：是。 系統(tǒng)用戶考慮分配訂單到某倉庫的因素： (1)首先倉庫必須能夠滿足訂單上的貨物要求； (2)選擇地理位置與發(fā)貨點較近的倉庫發(fā)貨； (3)信譽滿意度越高的客戶就越應(yīng)該以較高的服務(wù)質(zhì)量來回報。 為確保類模型的正確性和完整性，只根據(jù)問題域測試類模型。 ) (2)仔細(xì)檢查每個繼承關(guān)系 ， 到底是聚集關(guān)系還是繼承關(guān)系 ？ (3)針對關(guān)聯(lián)關(guān)系中的關(guān)聯(lián)數(shù)目 ， 提一些問題結(jié)合實際場景來考察 。 上述五個問題可以作為評審會問題檢查單的選擇。 對問題 (4)： 檢查較復(fù)雜，容易發(fā)現(xiàn)分析錯誤的一個環(huán)節(jié)。 類級別的單元測試中，狀態(tài)模型可以輔助進(jìn)行測試用例的模型。 (3)測試用例 3： open, setup, deposit (initial), deposit, withdraw, balance count, withdraw (final), close. 上述測試用例覆蓋每個狀態(tài)，并增量測試每個狀態(tài)的轉(zhuǎn)移。典型場景是用例模型的一個實例。 典型場景的測試 5 軟件糾錯技術(shù) 軟件測試的目的是發(fā)現(xiàn)錯誤，在發(fā)現(xiàn)錯誤后，則應(yīng)按照一定的技術(shù)去糾正它。還應(yīng)該修改錯誤的本質(zhì)。發(fā)現(xiàn)錯誤時，人工沿控制流 追蹤源代碼程序。 yes no What When where How 演繹法排錯 演繹法是一種從一般原理出發(fā)，經(jīng)過排除和精化的過程，推導(dǎo)出結(jié)論的方法。是一種從特殊推斷一般的系統(tǒng)化 思考方法。 二、糾錯的技術(shù) 硬性糾錯 又稱為蠻干法，是使用較多，效率較低的方法。 一、糾錯的原則 注意錯誤的“群集現(xiàn)象”。 測試可以根據(jù)需求分析出發(fā)列出的一些典型場景 (順序圖模型所描述 )進(jìn)行 。 如果通過覆蓋狀態(tài)模型中的每個狀態(tài)和每個狀態(tài)轉(zhuǎn)移，那么就可以測試到對象之間的各種情況。 open setup deposit (initial) deposit withdraw balance count withdraw (final) close 空帳號 帳號設(shè)置 工作帳號 無效帳號 當(dāng)空帳號 銀行帳號共有 5個生命周期狀態(tài)，設(shè)計下面的測試用例： (1)測試用例 1： open, setup, deposit (initial), withdraw (final), close。因此，當(dāng)當(dāng)前分析的對象發(fā)生了狀態(tài)轉(zhuǎn)移時，其它對象也發(fā)生了狀態(tài)轉(zhuǎn)移，所以在對象發(fā)送消息給其它對象時，也要注意接收該消息的對象是否處于合適的狀態(tài)中。 對問題 (2)： 檢查狀態(tài)轉(zhuǎn)移條件，驗證當(dāng)觸發(fā)條件滿足時是否會出現(xiàn)狀態(tài)轉(zhuǎn)移，要求觸發(fā)條件是最簡化的 (無冗余條件 )。 在分析階段，識別的對象還只是停留在較粗的層次上，因此，對象狀態(tài)模型的測試通常只能采用評審會的辦法。 類圖實際上由類和類之間的關(guān)系組成，評審會的檢查單可從以下兩個方面制定。 以上測試未觸及某個具體用例，體現(xiàn)了用例模型測試和用例測試的區(qū)別。 可見，管理者要使用系統(tǒng)的十個功能，因此至少可以設(shè)計出十個測試用例。 管理者需要做： 生成訂單；查詢訂單時輸入訂單號。 以系統(tǒng)的用戶為主要的出發(fā)點設(shè)計測試用例，通過模擬某個系統(tǒng)用戶的行為來測試整個系統(tǒng)，對于該用戶的服務(wù)提供情況，從而檢查系統(tǒng)功能的完整性，用戶需求可跟蹤性等情況。 — 黑盒法 用例測試 是對某些用例中的典型場景進(jìn)行測試，典型場景的測試關(guān)心的是用例的執(zhí)行情況。 測試過程 通常測試步驟如下： 測試用例模型 ? 測試某些用例中的典型場景 ? 類及對象模型 ? 某些類測試其狀態(tài)模型 用例模型測試 重點是檢查用例模型作為整體是否實現(xiàn)了用戶需求。 測試也有需求 、 設(shè)計和實現(xiàn) ， 并且測試本身也會有測試(測試中的測試 )。 ２、面向?qū)ο蟮募蓽y試 集成測試的策略有： ①基于線程的測試 (Threadbased testing) ②基于使用的測試 (Usebased testing) 面向?qū)ο蟮拇_認(rèn)測試 類似傳統(tǒng)的確認(rèn)測試和系統(tǒng)測試，根據(jù)動態(tài)模型和描述系統(tǒng)行為的腳本來設(shè)計測試用例，可用黑盒法。 這種模糊性帶入了設(shè)計 ， 甚至代碼中 ， 將可能引發(fā)幾倍 ， 甚至幾十倍的錯誤 ， 這必將極大地消耗系統(tǒng)的資源和成本 。 必須首先重視需求的質(zhì)量 ， 而測試是質(zhì)量保證的重要手段 。 面向?qū)ο蟮臏y試，既要使用許多傳統(tǒng)的成熟的軟件測試方法和技術(shù)，也有其不同的特點；主要反映在測試對象和內(nèi)容的不同。 功能測試與系統(tǒng)測試 與上類似。 （ 2）由教師進(jìn)行測試。 Function Testing 功能測試 Local Area Testing 局域化測試 Usability Testing 可使用性測試 Regression Testing 回歸測試 Performance Testing 性能測試 Supportability Testing 可支持 性測試 四、系統(tǒng)測試 （ system testing ） 將經(jīng)過確認(rèn)測試的軟件，與計算機(jī)硬件、外設(shè)、 支持軟件等一起，在實際運行環(huán)境下測試。 隨著軟 件工程過程的進(jìn)展軟件配置項 （ SCI soft