[計算機]面向對象分析設計chapter-展示頁
2024-10-28 03:54本頁面
【正文】 的記錄和文檔。 測試方法 基于代碼 —— 代碼走查 靜態(tài) 基于非代碼 —— 評審 (需求和設計規(guī)格說明 ) 動態(tài) —— 測試用例驅動代碼執(zhí)行 根據(jù)測試方式目的可分為： 數(shù)據(jù)流測試方式； 控制流測試方式； 事務流測試方式 (數(shù)據(jù)流和控制流綜合測試 )。這種模糊性帶入了設計，甚至代碼中，將可能引發(fā)幾倍，甚至幾十倍的錯誤，這必將極大地消耗系統(tǒng)的資源和成本。 同時也減少了返工的幾率，應盡早發(fā)現(xiàn)并解決這些問題。 分析模型測試的重要性 必須首先重視需求的質量，而測試是質量保證的重要手段。 需求的質量影響并決定了設計的質量，進而影響并決定了代碼，直至整個系統(tǒng)的最終質量。 在不同的軟件開發(fā)過程模型中，需求、設計和編碼總是有一定的時序特性。 在需求階段不會執(zhí)行什么實在的測試用例，定義測試用例。 第五章 分析模型的測試 分析模型的測試實際上包括兩部分內(nèi)容： 針對分析模型測試模型的完整性； 根據(jù)分析模型為系統(tǒng)的測試 (包括類級別的單元測試、集成測試等 )，定義測試用例。 需求和設計是代碼產(chǎn)生的基礎，需要對需求和設計進行測試。 類狀態(tài)模型的測試 167。 用例模型的測試 167。 測試過程 167。 167。 分析模型測試的重要性 第五章 分析模型的測試 167。 測試方法 第五章小結 167。 類模型的測試 167。 典型場景的測試 傳統(tǒng)的觀點認為測試要在編碼之后才進行，假設測試的對象是程序代碼。 需求或設計的測試通常以兩種方式進行： 一是在沒有代碼的情況下進行測試； 二是在有代碼的情況下進行測試。 通常模型的測試采用正式評審會方式進行。 在設計階段需要設計測試用例。 需求模型、設計模型和實現(xiàn)代碼之間還具備解釋特性，即 設計解釋了需求，實現(xiàn)代碼解釋了設計。 167。 需求測試可以較早地發(fā)現(xiàn)需求中不合理的項目、以及錯誤地理解了用戶需求的項目，避免對于成本和資源的消耗。 用戶需求是用戶對待實現(xiàn)的系統(tǒng)的要求，通常以一種非正規(guī)的形式給出，具有一定的模糊性。 167。 測試是否應深入到代碼邏輯中： 黑盒測試 白盒測試 在 UML中，對需求模型的測試： 評審； 事務流 (場景 )模型等方法測試 (需結合具體的模型描述 )； 正式 —— 承擔責任，寫出評審報告
教學課件相關推薦
鄂ICP備17016276號-1