軟件工程復(fù)習(xí)

1、1. 軟件：軟件是能夠滿足預(yù)定義的功能和性能的可執(zhí)行的計算機程序，包括使程序正常執(zhí)行所需要的輸入數(shù)據(jù)以及相關(guān)的使用文檔。2. 軟件工程的基本原理：a) 清晰第一，效率第二b) 設(shè)計先于編碼c) 使程序的結(jié)構(gòu)適合于問題的結(jié)構(gòu)d) 開發(fā)伴隨復(fù)用，開發(fā)為了復(fù)用3. 軟件危機：指在軟件開發(fā)過程中所遇到的一系列的問題。4. 軟件危機的原因:a) 軟件維護費用過高，直接威脅計算機應(yīng)用的擴大b) 軟件生產(chǎn)技術(shù)發(fā)展緩慢，進一步加劇了軟件危機5. 軟件的特征：a) 軟件的開發(fā)不同于硬件的設(shè)計b) 軟件的生產(chǎn)不同于硬件的制造c) 軟件的維護不同于硬件的維修6. 軟件工程從第一代開始已經(jīng)發(fā)展到了第三代，編程范型也經(jīng)

2、歷了三次的演變a) 過程式編程范型：著眼于程序的過程和基本控制結(jié)構(gòu)，粒度最小b) 面向?qū)ο缶幊谭缎停褐塾诔绦蛑械膶ο骳) 基于構(gòu)件技術(shù)的編程范型：著眼于適合整個領(lǐng)域的類對象用編程粒度的大小比較三種編程范型的差異。7. 軟件工程學(xué)的范疇a) 軟件開發(fā)技術(shù)i. 軟件開發(fā)方法學(xué)ii. 軟件工具（幫助開發(fā)軟件的軟件）iii. 軟件工程環(huán)境（方法與工具相結(jié)合，再加上配套的軟、硬件支持就形成環(huán)境）b) 軟件工程管理i. 軟件經(jīng)濟學(xué)ii. 軟件管理學(xué)iii. 軟件度量學(xué)軟件工程管理的目的是為了按照進度及預(yù)算完成軟件計劃，實現(xiàn)預(yù)期的經(jīng)濟和社會效益。7. 軟件生存周期：軟件產(chǎn)品從形成概念，經(jīng)過開發(fā)、使用和維護

3、，直到最后退役的全過程。8. 軟件生存周期一般劃分為：計劃、開發(fā)、運行三個階段。9. 將軟件生存周期劃分為若干個階段的意義將軟件生存周期劃分為若干個階段，每一個階段只賦予有限的活動，這就使因軟件規(guī)模大大增長而帶來的軟件復(fù)雜性變得容易控制和管理。10. 傳統(tǒng)的瀑布模型軟件生存周期的劃分階段：a) 需求分析b) 軟件分析c) 軟件設(shè)計d) 編碼e) 軟件測試f) 運行維護11. 瀑布模型（一種基于軟件生存周期的線性開發(fā)模型）的特點：a) 階段間的順序性和依賴性i. 順序性：只有前一階段的開發(fā)工作完成后，后一階段才能進行ii. 依賴性：前一階段的輸出文檔是后一階段的輸入文檔b) 推遲實現(xiàn)的觀點：瀑布

4、模型是一種線性模型，過早的編碼容易導(dǎo)致返工。所謂推遲實現(xiàn)是指將待開發(fā)軟件的邏輯設(shè)計和物理實現(xiàn)區(qū)分開來，即在需求分析和軟件設(shè)計階段只考慮系統(tǒng)的邏輯模型，等到編碼階段再完成實現(xiàn)。c) 保證質(zhì)量的觀點：i. 每一階段都必須要完成規(guī)定的文檔，不然不能視為完成該階段的任務(wù)ii. 每一階段都要對完成的文檔進行復(fù)審，以便盡早發(fā)現(xiàn)問題。d) 存有問題，風(fēng)險滯后釋放，不適合大型軟件的開發(fā)12. 瀑布模型存在的問題a) 不適合于需求模糊的系統(tǒng)b) 滯后的風(fēng)險釋放13. 快速原型模型定義：先建立一個滿足用戶主要需求的原型，讓用戶了解整個軟件的概貌，以便判斷哪些功能是需要的，哪些方面還需要改進。然后在此原型的基礎(chǔ)上進

5、行開發(fā)，直到建立起滿足用戶全部功能的軟件系統(tǒng)。14. 一個關(guān)鍵的問題：到底用戶最終的需求是什么？ 術(shù)業(yè)有專攻，用戶不懂計算機，軟件系統(tǒng)分析員對用戶的專業(yè)也往往不了解，所以在開發(fā)的初始階段很難弄清用戶的需要到底是什么。15. 增量模型是瀑布模型的順序特征和快速原型模型的迭代特征相結(jié)合的產(chǎn)物。增量模型將軟件視作一系列相互聯(lián)系的增量，每一次的迭代過程，采用瀑布模型或快速原型模型完成對一個增量的開發(fā)。16. 螺旋模型：目前軟件開發(fā)中最常用的一種軟件開發(fā)模型，適合于大型軟件的開發(fā)。17. 當項目按順時針方向沿螺旋線移動時，每輪螺旋均包含一下內(nèi)容：a) 計劃b) 風(fēng)險分析c) 建立原型d) 用戶評審按以上

6、順序螺旋線周而復(fù)始，直到最后實現(xiàn)產(chǎn)品。螺旋模型每一次迭代過程都需要進行一次風(fēng)險分析。18. 構(gòu)件集成模型構(gòu)件是經(jīng)過適當設(shè)計和實現(xiàn)的類。19. 凈室模型是一種形式化的增量開發(fā)模型。其基本思想是力求在分析和設(shè)計階段消除錯誤，確保正確，然后在無缺陷或“潔凈”的狀態(tài)下實現(xiàn)軟件的制作。20 轉(zhuǎn)換模型：將形式化軟件開發(fā)和程序自動生成技術(shù)相結(jié)合的一種軟件開發(fā)模型。（自動或半自動的程序變換）21.軟件工程開發(fā)模型e) 傳統(tǒng)的軟件工程i. 瀑布模型ii. 快速原型模型f) 軟件演化模型：i. 增量模型ii. 螺旋模型iii. 構(gòu)件集成模型g) 形式化方法模型i. 轉(zhuǎn)換模型ii. 凈室模型22.7種軟件開發(fā)模型的

7、特點及適用場合A. 瀑布模型是一種線性開發(fā)模型，每一階段必須完成規(guī)定的文檔。適用于需求明確的中、小型軟件開發(fā)B. 快速原型模型：用戶介入早，采用快速開發(fā)工具，通過迭代完善用戶需求。適合于需求模糊的小型軟件開發(fā)C. 增量模型：每次迭代完成一個增量，可用于OO開發(fā)。適合于容易分塊的大型軟件開發(fā)。D. 螺旋模型：典型的迭代模型，重視風(fēng)險分析，可用于OO開發(fā)。適合于具有不確定性的大型軟件開發(fā)E. 構(gòu)件集成模型：軟件開發(fā)與構(gòu)件開發(fā)平行進行，主要用于OO開發(fā)。適用于領(lǐng)域過程、行業(yè)的中型軟件開發(fā)。F. 轉(zhuǎn)換模型：形式化的需求規(guī)格說明書，自動的程序變換系統(tǒng)。適用場合：理想化模型，尚無成熟工具支持。G. 凈室模

8、型：形式化的增量開發(fā)模型，在潔凈狀態(tài)下實現(xiàn)軟件制作。適合場合：開發(fā)團隊熟悉形式化方法，中小型軟件開發(fā)。23. 軟件可行性的研究：a) 經(jīng)濟可行性b) 技術(shù)可行性c) 運行可行性d) 法律可行性24. 可行性研究的目的是弄清待開發(fā)的項目是不是可能實現(xiàn)和值得開發(fā)，通常由系統(tǒng)分析員完成，并需寫出可行性論證報告。25. 統(tǒng)一過程概念：統(tǒng)一過程描述了軟件開發(fā)各個環(huán)節(jié)中應(yīng)該做什么，怎么做，什么時候做已經(jīng)為什么要做，描述了一組以某種順序完成的活動。26. 結(jié)構(gòu)化分析與設(shè)計由結(jié)構(gòu)化程序設(shè)計擴展而來。結(jié)構(gòu)化設(shè)計（SD）的軟件設(shè)計技術(shù)，結(jié)構(gòu)化分析技術(shù)（SA）。27. 結(jié)構(gòu)化分析SA有兩項基本任務(wù)：a) 建立系統(tǒng)分

9、析模型b) 編寫軟件需求規(guī)格說明書SRS。SRS是分析階段編寫的，以文字為主的文檔。28. SA模型的組成：a) 數(shù)據(jù)字典（DD）：處于模型的核心部分，是系統(tǒng)涉及到的各種數(shù)據(jù)對象的總和。b) 實體聯(lián)系圖ER圖：用于描述數(shù)據(jù)對象間的關(guān)系。c) 數(shù)據(jù)流圖DFD：主要作用是指明系統(tǒng)中的數(shù)據(jù)是如何流動和變換的，以及描述使數(shù)據(jù)流進行變換的功能。d) 狀態(tài)變換圖STD:用于指明 系統(tǒng)在外部事件作用下將如何動作，表明系統(tǒng)的各種狀態(tài)以及狀態(tài)間的轉(zhuǎn)換。e) 數(shù)據(jù)對象說明f) 加工規(guī)格說明（PSPEC）g) 控制規(guī)格說明 （CSPEC）29. 數(shù)據(jù)流圖的組成符號：a) 圓框表示 數(shù)據(jù)加工（其中的內(nèi)容還應(yīng)進行編號）

10、b) 方框表示 數(shù)據(jù)源點和終點c) 箭頭表示 數(shù)據(jù)流（單箭頭表示只讀或只寫，雙向表示又讀又寫，箭頭的方向表示從文件讀出）。d) 雙杠或單杠表示 數(shù)據(jù)文件或數(shù)據(jù)庫30. 數(shù)據(jù)字典a) 定義：關(guān)于數(shù)據(jù)信息的集合，對數(shù)據(jù)流圖中的每個元素作完整的定義與說明b) 功能：對軟件中的每個數(shù)據(jù)規(guī)定一個定義條目。c) 組成：i. 數(shù)據(jù)流（由多個數(shù)據(jù)項組成）ii. 數(shù)據(jù)文件iii. 數(shù)據(jù)項 加過規(guī)格說明：通常用結(jié)構(gòu)化語言、判定表或判定樹作為描述工具。31. 結(jié)構(gòu)設(shè)計模型SD由結(jié)構(gòu)分析模型SA映射而來。體系結(jié)構(gòu)設(shè)計用來確定軟件結(jié)構(gòu)，其描述工具為結(jié)構(gòu)圖（structure chart），簡稱SC圖。32. 在SC圖中

11、，用矩形表示模塊，帶箭頭的連線表示模塊間的調(diào)用，并在調(diào)用線的兩旁標出傳入和傳出模塊的數(shù)據(jù)流。SC圖允許使用6種模塊。33. 軟件設(shè)計目前的兩種主流方法：基于結(jié)構(gòu)化程序設(shè)計的結(jié)構(gòu)化軟件設(shè)計，基于面向?qū)ο蠹夹g(shù)的面向?qū)ο筌浖O(shè)計。34. SD模型的組成：a) 過程設(shè)計b) 接口設(shè)計c) 體系結(jié)構(gòu)設(shè)計d) 數(shù)據(jù)設(shè)計35. 結(jié)構(gòu)化系統(tǒng)分析就是使用DFD，DD，結(jié)構(gòu)化英語，判定表，判定樹等工具，來建立一種新的，稱為結(jié)構(gòu)化說明書的目標文檔。36. 結(jié)構(gòu)化分析的基本步驟：a) 自頂向下，進行功能分解，畫出分層DFDb) 由后向前，定義系統(tǒng)的數(shù)據(jù)和加工，編制DD和PSPECc) 根據(jù)需要，建立復(fù)雜的數(shù)據(jù)模型d)

12、 編寫SRS37. 為什么對DFD分層（畫分層數(shù)據(jù)流圖）對于大型規(guī)模的軟件系統(tǒng)，可能會有成百上千個DFD圖，不可能一次將所有的DFD圖畫完，所以必須要從系統(tǒng)的基本模型開始，對系統(tǒng)逐層進行分解。38. 分層DFD的優(yōu)點：a) 便于使用b) 便于實現(xiàn)39. 結(jié)構(gòu)化軟件的設(shè)計通常從DFD圖到SC圖的映射開始。40. 從SA獲得的DFD，所有系統(tǒng)都可以歸結(jié)為變換型結(jié)構(gòu)和事務(wù)型結(jié)構(gòu)。a) 變換型結(jié)構(gòu)：只有一個傳入路徑，變換中心和傳出路徑組成。b) 事物型結(jié)構(gòu)：由至少一條接受路徑，一個事務(wù)中心和若干條動作路徑組成。當外部信息沿著接受路徑進入系統(tǒng)后，進過事務(wù)中心獲得某一個特定的值，就能據(jù)此啟動某一條動作路徑

13、。41. 優(yōu)化初始SC圖的指導(dǎo)準則a) 對模塊劃分的原則b) 高扇入/低扇出的原則。（扇入高，則上級模塊多，能夠增加模塊的利用率；扇出低，則表示下級模塊少，可以減少模塊調(diào)用和控制的復(fù)雜度）42. 模塊化設(shè)計的原則與方法a) 清晰第一的設(shè)計風(fēng)格b) 結(jié)構(gòu)化的控制結(jié)構(gòu)c) 逐步細化的實現(xiàn)方法。43. 需求分析的步驟：需求獲??；需求提煉；需求描述；需求驗證。44. 需求分析的任務(wù)：a) 需求分析主要有兩個基本任務(wù)：一是根據(jù)對用戶問題的分析、理解和綜合建立分析模型；二是在全面理解用戶對系統(tǒng)的明確定義的基礎(chǔ)上，通過軟件需求規(guī)格說明書SRS來描述用戶需求。45. 分析階段的任務(wù)是決定設(shè)計一個什么樣的系統(tǒng)，

14、即解決系統(tǒng)做什么的問題，而不是去刻畫系統(tǒng)如何做。面向?qū)ο蟮能浖こ?. 對象是現(xiàn)實世界中個體或事物的抽象，具有特征和服務(wù)功能2. 類是一組對象集合的描述，這些對象具有共同的屬性、操作、關(guān)系和語義解釋3. 面向?qū)ο蟮幕咎卣鳎篴) 抽象：忽略主題中與當前目標無關(guān)的因素，把充分的注意力放在與當前目標相關(guān)的因素上b) 封裝：將數(shù)據(jù)和操作包圍起來，對數(shù)據(jù)的操作只能通過已定義的類接口實現(xiàn)c) 繼承：新的類可以從已有的類中派生出來d) 多態(tài)：不同類的對象可以對同一消息做出響應(yīng)，執(zhí)行不同的處理。4. 面向?qū)ο蟮膬?yōu)點：a) 提高軟件的可擴展性b) 提高軟件的可維護性c) 提高軟件的可復(fù)用性d) 容易建造模型，

15、更密切的映射現(xiàn)實世界5. UML是一種基于面向?qū)ο蟮目梢暬ＵZ言，它提供了豐富的以圖形符號表示的模型元素，這些標準的圖形符號隱藏了UML 的語法，而由這些圖形符號組成的各種模型表示了UML 的語義。6. UML的兩種模型元素：一類模型元素用于表示模型中的某個概念；另一類用于表示模型元素之間相互連接的關(guān)系。7. 按照UML 的語義，UML模型可定義為4個抽象層次（從低到高）：元元模型、元模型、模型、用戶模型。8. 元元模型定義了描述元模型的語言，它是任何模型的基礎(chǔ)；9. 元模型定義了用于描述模型的語言，它組成了UML的基本元素。10. 模型定義了用于描述信息領(lǐng)域的語言，它組成了UML 的模型1

16、1. 用戶模型是模型的實例，它用于表示一個模型的特定情況。（UML中用名稱下面帶有下劃線表示實例）12. UML的九種圖a) 靜態(tài)建模：i. 用例圖：描述系統(tǒng)的功能ii. 類圖：描述系統(tǒng)的靜態(tài)結(jié)構(gòu)iii. 對象圖：描述系統(tǒng)在某個時刻的靜態(tài)結(jié)構(gòu)iv. 構(gòu)件圖：描述系統(tǒng)元素間的組織v. 部署圖：描述系統(tǒng)環(huán)境元素的配置b) 動態(tài)建模：狀態(tài)圖：描述系統(tǒng)元素的狀態(tài)條件和響應(yīng)時序圖：按時間順序描述系統(tǒng)元素間的交互協(xié)作圖：按照連接關(guān)系描述系統(tǒng)元素間的交互活動圖：描述系統(tǒng)元素的活動流程13. 用例圖可描述軟件系統(tǒng)和外部參與者之間的交互。用例圖通常包含系統(tǒng)邊界、用例、參與者和關(guān)聯(lián)等組成符號。系統(tǒng)邊界以一個矩形表

17、示，上方標注系統(tǒng)名稱，內(nèi)部包含一個或多個用例；每個用例由一個橢圓形表示，其中標上用例的名稱；參與者用一個人形的符號表示；參與者和用例之間或用例和用例之間的關(guān)聯(lián)均用直線表示。14. 用例是一組動作序列及其變體的描述。15. 消息是對象間通信的規(guī)約，對象間的交互通過對象間的消息傳遞完成。16. UML定義的消息有三種：簡單消息；同步消息；異步消息。17. 狀態(tài)圖用于描述一個特定對象的所有可能狀態(tài)以及引起狀態(tài)遷移的事件。18. 時序圖用與描述對象之間的動態(tài)交互，著重體現(xiàn)對象間消息傳遞的時間順序。它以垂直軸表示時間，水平軸表示不同的對象。對象用一個帶有垂直虛線的矩形框表示，并標有對象名和類名。垂直虛線

18、是對象的生命線，用于表示在某段時間內(nèi)對象是存在的。對象間的通信在對象的生命線間通過消息符號來表示，消息的箭頭指明消息的類型。19. 協(xié)作圖用于描述相互協(xié)作的對象間的交換和鏈接。20. UML的特點：a) 統(tǒng)一標準b) 面向?qū)ο骳) 表達能力強大、可視化21. 軟件需求主要指一個軟件系統(tǒng)必須遵循的條件或具備的能力。軟件需求可以從兩方面描述：a) 系統(tǒng)的外部特性：用戶解決問題或達到目標所需的條件或能力。b) 系統(tǒng)的內(nèi)部特性：系統(tǒng)為了滿足合同、規(guī)范或其他規(guī)定文檔所需具有的條件或能力。22. 需求分析的步驟：a) 需求獲取b) 需求建模c) 需求描述d) 需求驗證23. 面向?qū)ο蟮男枨蠼) 畫用例

19、圖i. 確定參與者（參與者泛指所有存在于系統(tǒng)外部并與系統(tǒng)交互的人、硬件或其他系統(tǒng)。參與者主要是開發(fā)系統(tǒng)的使用者）ii. 確定用例iii. 繪制和檢查用例圖b) 寫用例規(guī)約i. 用例規(guī)約一般包含：1. 簡要說明2. 事件流3. 特殊需求4. 前置條件和后置條件c) 描述補充規(guī)約i. 補充規(guī)約用于記錄在用例模型中不宜表述的系統(tǒng)需求。24. 如何確定參與者：a) 系統(tǒng)開發(fā)完成后，有哪些人使用該系統(tǒng)b) 系統(tǒng)需要從哪些人或系統(tǒng)中獲得數(shù)據(jù)c) 系統(tǒng)會為那些人或其他系統(tǒng)提供數(shù)據(jù)d) 系統(tǒng)會與哪些系統(tǒng)相關(guān)聯(lián)e) 系統(tǒng)由誰來維護和管理25. 需求管理是伴隨著軟件需求的發(fā)展而成長起來的管理技術(shù)。需求管理的5個實

20、踐：a) 獲得對需求的理解b) 獲取需求承諾c) 管理需求變更d) 在需求變更后維護對需求的雙向可追溯性e) 標識項目工作與需求的不一致性面向?qū)ο蠓治?. 面向?qū)ο蠓治鯫OA的首要任務(wù)：a) 首先要理解用戶的需求，包括全面理解和分析用戶需求，明確所開發(fā)的系統(tǒng)的職責，形成文件并規(guī)范的加以表述b) 然后進行分析，提取類和對象，并結(jié)合分析進行建模。其步驟是：標識類，定義屬性和方法；刻畫類的層次；表示對象以及對象與對象之間的關(guān)系；對象的行為建模。這些步驟可反復(fù)進行，直至完成建模。結(jié)構(gòu)化分析SA有兩項基本任務(wù)：a) 建立系統(tǒng)分析模型b) 編寫軟件需求規(guī)格說明書SRS。SRS是分析階段編寫的，以文字為主的

21、文檔。2. P 139 SA、OOA模型。3. 分析類的查找：a) 邊界類對象擔負著協(xié)調(diào)用例與參與者之間進行交互的職責。一對（用例/參與者）對應(yīng)一個邊界類b) 為每個用例設(shè)置一個控制類c) 實體類：需要長期存儲的數(shù)據(jù)面向?qū)ο笤O(shè)計1. 模塊：模塊是一個擁有明確定義的輸入、輸出和特性的程序?qū)嶓w2. 模塊化設(shè)計的目的是按照規(guī)定的原則把大型軟件劃分為一個個較小的、相對獨立但相互關(guān)聯(lián)的模塊3. 分解和模塊獨立性是模塊化設(shè)計的兩個重要指導(dǎo)思想。a) 分解b) 模塊獨立性：概括了把軟件劃分為模塊時所要遵守的準則。4. 模塊獨立性從兩個方面度量：模塊本身的內(nèi)聚和模塊間的耦合a) 內(nèi)聚指模塊內(nèi)部各個成分之間的聯(lián)

22、系b) 耦合指一個模塊和其他模塊間的聯(lián)系5. 內(nèi)聚是從功能的角度對模塊內(nèi)部聚合能力的度量a) 偶然性內(nèi)聚（在組成成分上互不相關(guān)，內(nèi)聚程度最弱）b) 邏輯性內(nèi)聚c) 時間性內(nèi)聚d) 過程性內(nèi)聚e) 通信性內(nèi)聚f) 順序性內(nèi)聚g) 功能性內(nèi)聚（塊內(nèi)聯(lián)系最強的內(nèi)聚，所有成分結(jié)合在一起，用于完成一個單一的功能）6. 耦合是對軟件內(nèi)部塊間聯(lián)系的度量：a) 非直接耦合b) 數(shù)據(jù)耦合c) 特征耦合d) 控制耦合e) 外部耦合f) 公共耦合g) 內(nèi)容耦合7. 面向?qū)ο笤O(shè)計的任務(wù)a) 系統(tǒng)架構(gòu)設(shè)計i. 系統(tǒng)高層結(jié)構(gòu)設(shè)計ii. 確定設(shè)計元素iii. 確定任務(wù)管理策略iv. 確定分布式實現(xiàn)機制v. 確定數(shù)據(jù)存儲策略

23、vi. 設(shè)計人機交互界面b) 系統(tǒng)元素設(shè)計i. 確定類/對象ii. 確定子系統(tǒng)iii. 確定包8.軟件維護1. 軟件維護是指系統(tǒng)在交付運行以后，為改正或滿足新的需要所進行修改的過程。2. 軟件維護是軟件生存周期中花錢最多，延續(xù)時間最長的環(huán)節(jié)。3. 軟件維護的類型a) 完善性維護（在整個維護工作量中，占比高達50%60%，居于第一位）：不斷改善和加強產(chǎn)品的功能和性能，以滿足用戶日益增長的需要。b) 適應(yīng)性維護：指使軟件適應(yīng)運行環(huán)境的改變而進行的一類維護c) 糾錯性維護：糾正在開發(fā)期間未能發(fā)現(xiàn)的錯誤d) 預(yù)防性維護：改善軟件的可維護性，減少今后對它們維護時所需要的工作量。4. 可維護性：衡量維護容

24、易程度的一種軟件屬性?？删S護性取決于軟件的可理解性、可修改性和可測試性，三者一起構(gòu)成軟件的質(zhì)量屬性。5. 軟件再工程：所謂軟件再工程是指將新技術(shù)和新工具應(yīng)用于老的軟件的一種較“徹底”的預(yù)防性維護。軟件測試1. 軟件測試是動態(tài)查找程序代碼中的各類錯誤和問題的過程。2. 測試的目的是為了發(fā)現(xiàn)程序中的錯誤；糾錯的目的是為了定位和改正程序中的錯誤。3. 測試的任務(wù)是通過在計算機上執(zhí)行程序，暴露其中潛在的錯誤；糾錯的任務(wù)是消除軟件故障，保證程序的可靠運行。4. 測試用例：一次程序執(zhí)行所需要的測試數(shù)據(jù)稱為一個測試用例。5. 測試用例 ：= 測試數(shù)據(jù)+期望結(jié)果，測試結(jié)果：=測試數(shù)據(jù)+期望結(jié)果+實際結(jié)果6.

25、測試的特性：a) 挑剔性：測試是為了證明程序有錯而不是為了證明程序沒有錯誤。只有抱著證明程序有錯的目的去測試，才能把程序中潛在的所有錯誤都找出來。b) 復(fù)雜性：測試用例的設(shè)計需要細致和高度的技巧。c) 不徹底性：程序測試只能證明程序錯誤的存在，不能證明錯誤不存在。其根本原因在于在實踐中無法進行窮舉測試，即將所有的輸入情況在被測程序下執(zhí)行一遍。d) 經(jīng)濟型：要選擇典型的、有代表性的測試樣例。7. 測試的方法：a) 靜態(tài)分析法（并非由計算機執(zhí)行）i. 靜態(tài)分析器分析ii. 人工審查法1. 代碼會審2. 走查法3. 辦公桌檢查b) 動態(tài)分析法i. 黑盒測試（測試系統(tǒng)的功能）ii. 白盒測試（測試系統(tǒng)的結(jié)構(gòu)）8. 黑盒測試：將待測試對象視作一個黑盒子，測試人員不考慮系統(tǒng)內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)在特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能說明。9. 黑盒測試的四種技術(shù)：a) 等價分類法b) 邊界值分析法c) 錯誤猜測法d) 因果圖法10. 白盒測試：將測試對象視作一個透明的盒子，測試人員可以根據(jù)系統(tǒng)的內(nèi)部特性和邏輯結(jié)構(gòu)設(shè)計測試樣例，對程序的所有邏輯路徑