軟件工程知識點

軟件工程知識點軟件工程知識點軟件工程知識點xxx公司軟件工程知識點文件編號：文件日期：修訂次數(shù)：第1.0次更改批準審核制定方案設計，管理制度第一章軟件危機：軟件危機是指在計算機軟件的開發(fā)和維護過程中所遇到的一系列嚴重問題。軟件危機的表現(xiàn)：（1）軟件開發(fā)進度和成本難以控制。（2）軟件產(chǎn)品難以滿足用戶的需求。（3）軟件質量難以得到保證。（4）軟件產(chǎn)品難以進行維護。（5）軟件的文檔資料難以管理。（6）軟件產(chǎn)品的生產(chǎn)率難以得到提高。軟件危機出現(xiàn)的原因：一方面是軟件自身特點，另一方面是開發(fā)軟件和使用軟件的人員。對軟件開發(fā)缺乏正確的理論指導。（2）軟件開發(fā)人員與用戶缺乏充分的交流。（3）對軟件開發(fā)過程缺乏整體認識。（4）對軟件產(chǎn)品缺乏有效一致的質量評價標準。軟件工程發(fā)展的四個階段：（1）傳統(tǒng)軟件工程階段：用工程化思想指導軟件項目開發(fā)逐步為業(yè)界所理解和接受。（2）面向對象軟件工程階段：這一階段的發(fā)展是以“對象”為基礎展開的。（3）過程工程的軟件工程階段：提出對軟件項目管理的計劃，實施，監(jiān)控，成本核算，質量保證以及軟件配置的技術和過程，逐步形成了過程軟件工程，并衍生出群體過程和個體過程兩個子類。（4）構建工程的軟件工程階段：重視發(fā)展軟件體系結構，軟件設計模式，系統(tǒng)交互性，標準化等領域的重用，積極提倡基于軟構件的開發(fā)方法。軟件工程的概念：應用計算機科學理論和技術以及工程管理原則和方法，按預算和進度，實現(xiàn)滿足用戶要求的軟件產(chǎn)品和定義，開發(fā)，發(fā)布和維護的工程或進行研究的學科。軟件工程三要素：方法，工具，過程。簡答第一大題衡量軟件質量的因素：（1）：可理解性：它對軟件體系結構，數(shù)據(jù)程序的描述清晰和易于掌握的程度。（2）功能性：它是軟件所實現(xiàn)的功能和達到的性能與滿足用戶實際需求的程度（3）安全性：它是軟件具有的自身保護能力的程度。（4）可靠性：它是軟件在給定的時間、空間、外部環(huán)境等條件下，按照設計須有，成功運行的能力。（5）有效性。它是軟件能充分利用計算機時間、空間、寬帶等資源的能力。（6）可擴充性；它是軟件在功能或性能發(fā)生變化時，系統(tǒng)改變的容易程度。（7）可維護性，它是軟件出現(xiàn)異常時，對系統(tǒng)進行修改、改進、刪除、增加等操作，并恢復系統(tǒng)正常運行的能力。（8）可重用性，它是軟件的部分或整體被其他系統(tǒng)利用的程度（9）可移植性，它是將軟件系統(tǒng)有一個軟件或硬件環(huán)境轉移到另一個軟件或硬件環(huán)境的容易程度。軟件的七大基本原理1，用分階段的生命周期計劃嚴格管理。2，堅持進行階段評審。3，執(zhí)行嚴格的產(chǎn)品質量控制4，采用現(xiàn)代程序設計技術5，結果應能清楚地審查。6，開發(fā)人員應少而精。7，承認不斷改進軟件工程的必要性軟件實現(xiàn)的是一個從現(xiàn)實問題域（輸入）到信息域的解（輸出）的過程，在此過程中包括程序、數(shù)據(jù)、文檔、以及它們之間的聯(lián)系軟件生命周期六個階段1，可行性與計劃研究階段。2需求分析階段。3，設計階段。4，實現(xiàn)階段。5，測試階段、6，運行和維護階段軟件過程模型：瀑布模型：1、特點：簡單、嚴格（每一階段過程都始于前一階段過程的結束，每一階段結束后都進行技術審查和管理復查）、順序、質量保證。2、適用領域：瀑布模型是一次性單向開發(fā)，難以適應軟件需求不明確或出現(xiàn)變動的情況。原型模型：1、特點：快速、符合用戶預期。2、適用領域：原型模型不適宜開發(fā)大型軟件項目，是在需求不明確的情況下開發(fā)的。增量模型：1、特點：靈活性（可以按照用戶需求有選擇地先開始進行系統(tǒng)中重要部分內(nèi)容的分析與設計）、降低風險。2、適用領域：需求不明確、開發(fā)功能多、開發(fā)時間長的系統(tǒng)。螺旋模型：將原型模型和瀑布模型相結合，并第一個引入風險分析機制，是迭代式開發(fā)過程。特點：1、風險分析，螺旋模型首次采納風險分析，讓開發(fā)者和客戶能較好地對待和理解每一次迭代所帶來的風險，降低軟件開發(fā)中的技術、管理和成本的風險。2、特別適應大型復雜系統(tǒng)的開發(fā)，能及時發(fā)現(xiàn)開發(fā)過程中出現(xiàn)的風險，并能盡早地規(guī)避風險，或給出消除風險的方案。噴泉模型：1、特點：開發(fā)階段的相互重疊、支持重用、不嚴格的階段劃分，增量式開發(fā)、對象驅動。2、適用領域：用于面向對象軟件開發(fā)，并支持重用。敏捷過程模型：1、特點：簡單（以快速、簡單、使用、滿足用戶需求為要旨）、變化（敏捷過程模型要能反映這種變化，并將變化及時反映在軟件的設計和實現(xiàn)中）、有目的的建模（多與團隊人員溝通，與客戶溝通，保證建模的正確性和足夠詳細）、快速反饋（在開發(fā)過程中，自己所做的工作，與別人合作，都應該及時得到反饋，快速反饋是建立在團隊合作的基礎上）2、優(yōu)點：綜合瀑布模型和原型模型的優(yōu)點，在保證減少錯誤的前提下，快速得到用戶系統(tǒng)，在每個階段都引入風險分析?？焖匍_發(fā)、建模，不但能夠促進個人和團隊開發(fā)人員之間的溝通。第二章基本的需求分析任務是：定義軟件的適用領域和必須滿足的約束（需求發(fā)現(xiàn)），確定系統(tǒng)功能、性能、領域等內(nèi)容，確定軟件與其他成分間的借口和通信（需求分析），建立數(shù)據(jù)模型、功能模型和行為模型（建模），最終定義需求規(guī)格說明書，并經(jīng)技術審查和管理復審，用作評價確認測試和質量評估的依據(jù)。系統(tǒng)中最主要的、最基本的要求是功能需求。定義邏輯模型：通過定義邏輯模型，把問題域中的問題轉換為信息領域問題。需求分析的原則：軟件人員要從用戶角度考慮軟件需求；以流程為主線；盡量重用軟部件；劃分需求的優(yōu)先級；需求變更要及時反饋；需求分析的內(nèi)容：功能需求，性能需求，領域需求，其他需求。功能需求：描述系統(tǒng)提供的服務和在特定條件下的行為，包括系統(tǒng)登陸、輸入、響應、輸出、異常等，有事還需要特別的說明系統(tǒng)不應該做什么。通過功能需求分析，劃分出系統(tǒng)必須完成的所有功能。軟件的功能描述滿足完整性和一致性。性能需求：規(guī)定了軟件系統(tǒng)必須滿足在時間上或空間上的約束，通常包括系統(tǒng)響應時間，主存容量，儲存容量，安全性，壓力等方面的需求。領域需求：與軟件系統(tǒng)的具體應用范圍有關，它是對需求中的功能或數(shù)據(jù)在領域上需要的特別實現(xiàn)，具有特殊性。其他需求：是軟件系統(tǒng)有關的外在約束，如法律需求，道德需求，外部數(shù)據(jù)交換需求，預期需求等。需求工程過程中的活動：需求工程過程是一個可行性研究、需求獲取、需求分析與建模、需求評審的迭代過程?？尚行匝芯浚菏切枨蠊こ套畛醯挠媱濍A段，目的不是確定問題如何去解，而是確定問題是否值得去解。可行性分析主要包括四個方面的內(nèi)容：（1）技術可行性：從問題的復雜性、現(xiàn)有技術、技術所需代價、技術風險等三個方面出發(fā)。（2）操作可行性。（3）經(jīng)濟可行性：運用軟件成本估算技術（成本/效益分析等方法）判斷是否盈利。（4）法律可行性。需求分析與建模：采用軟件開發(fā)方法提供的圖形工具，用形式化或半形式化的定義來描述初步需求，確保需求的完整性、正確性和一致性，將目標系統(tǒng)的物理模型轉換為詳細模型。需求工程的管理：存在兩大難題：一是需求確認困難，二是需求不斷變更。對傳統(tǒng)的需求變更管理過程來說，主要包括軟件配置、軟件基線和變更審查。軟件配置項主要有兩類：一是屬于產(chǎn)品自身需要的內(nèi)容，如開發(fā)文檔、代碼、數(shù)據(jù)等；二是為軟件產(chǎn)品服務的內(nèi)容，如進度計劃，人員安排，報告等。軟件基線由一組軟件配置組成，當軟件配置處于穩(wěn)定狀態(tài)后（如需求文檔經(jīng)過評審以后），就確定了這組軟件配置項的基線。需求獲取技術：（1）個別會議和小組會議：小組會議則體現(xiàn)了用戶群組的集思廣益。W5H2原則（Why：為什么要開發(fā)該系統(tǒng)，What：系統(tǒng)將要開發(fā)的功能是什么，When：什么時候開發(fā)，Who：系統(tǒng)由誰負責系統(tǒng)會有哪些相關的人、事務或其他系統(tǒng)Where：所開發(fā)的業(yè)務處于整個系統(tǒng)的什么位置，How：完成系統(tǒng)的開發(fā)目標技術上采用何種方法管理上如何進行，Howmuch：開發(fā)系統(tǒng)需要那些資源需要多少）（2）調(diào)查問卷。（3）面向用例的場景分析：訪談和問卷調(diào)查是一種抽象的需求描述，存在用戶描述模糊，分析員工不理解甚至誤解的情況。用戶的一次手工操作就是一個用例。場景讓分析員實際模擬了用戶的操作流程，但需要注意防止場景陷阱。（4）快速原型技術：快速原型技術的基本思想是，在系統(tǒng)的開發(fā)時期就讓用戶盡早地接觸系統(tǒng)，對系統(tǒng)原型進行評估，指出不足之處并提出修改意見?？焖僭陀袃煞N不同類型：拋棄型原型法和演化型原型法。演化型原型法是無風險機制，任然是迭代的。結構化需求分析和建模：主要目的是減少分析時的錯誤，通過自定向下地建立系統(tǒng)邏輯模型，降低系統(tǒng)設計時的復雜性，提高系統(tǒng)的可維護性。結構化分析的核心是數(shù)據(jù)。包括：實體關系模型，數(shù)據(jù)流圖，狀態(tài)轉換圖。面向對象的數(shù)據(jù)建模：數(shù)據(jù)建模給出了軟件開發(fā)過程中與各部分設計有關的所有數(shù)據(jù)對象。數(shù)據(jù)對象包括實體、實體屬性和實體間關系。實體關系模型（ER）是結構化建模的可視化圖形工具，他描述了數(shù)據(jù)對象（實體），對象屬性和對象間關系。關系和基數(shù)：基數(shù)表明數(shù)據(jù)對象在關系上的數(shù)量約束，在ER模型中，關系用菱形表示，它通常是一個動詞或動賓短語?；鶖?shù)關系（一對一一對多多對多）數(shù)據(jù)流圖是結構化建模中最流行的功能建模工具。建模的基本過程：（1）確定系統(tǒng)的外部信息源，數(shù)據(jù)源或外部系統(tǒng)的接口。（2）畫出頂層（0層）DFD圖。（3）第一次精化：劃分系統(tǒng)的子系統(tǒng)。（4）逐層求精：對各子系統(tǒng)進一步精化。面向狀態(tài)轉換的行為建模：行為建模是所有需求分析辦法的操作性原則，系統(tǒng)狀態(tài)的改變狀態(tài)轉換圖來描述。STD圖中的狀態(tài)分為初態(tài)，終態(tài)，中間狀態(tài)和復合狀態(tài)。狀態(tài)變換是由事件或條件觸發(fā)的。STD圖定義了3個標準事件，它們都沒有參數(shù)：（1）entry事件：用于說明轉換到該狀態(tài)的特定動作。（2）exit事件：用于說明觸發(fā)該狀態(tài)的特定動作。（3）do事件：用于說明處于當前狀態(tài)時執(zhí)行的動作。數(shù)據(jù)字典：以結構化方式定義了在數(shù)據(jù)建模、功能建模和行為建模過程中設計的所有數(shù)據(jù)信息、控制信息。詞條描述：詳細說明了數(shù)據(jù)和控制信息在系統(tǒng)內(nèi)的傳播途徑，它包括數(shù)據(jù)流詞條，數(shù)據(jù)元素詞條，加工詞條和存儲文件詞條等內(nèi)容。定義式特點：清晰、準確、無二義地定義數(shù)據(jù)。Warnier圖用樹形結構表示數(shù)據(jù)的層次結構，利用順序，選擇和重復三種結構對應數(shù)據(jù)的層次分解，并指出可以從數(shù)據(jù)層次結構導出程序結構。加工邏輯：也稱為過程說明，用于描述DFD中加工部分的流程或算法。加工邏輯的形式主要有過程描述語言、判斷樹和判斷表等。過程描述語言也稱為偽碼語言，它是一種介于自然語言和形式語言之間的結構化語言。第三章軟件設計的目標就是要構造一個高內(nèi)聚、高可靠性、高維護性和高效的軟件模型。軟件設計的依據(jù)是需求規(guī)格說明和數(shù)據(jù)規(guī)格說明，并將它們映射為軟件設計的內(nèi)容。一般把軟件設計分為概要設計和詳細設計兩個子階段。概要設計包括：體系結構設計、界面設計和數(shù)據(jù)設計。模塊化設計的指導思想是分解、抽象、求精、信息隱藏和模塊獨立性。界面設計的任務主要包括用戶特性研究、用戶工作分析、界面任務分析、界面類型確定和界面原型評估。分布式結構存在的不足：復雜性、安全性、運行狀態(tài)難以確定。出選擇：體系結構設計：確定各子系統(tǒng)模塊間的數(shù)據(jù)傳遞、調(diào)用關系。界面設計：包括與系統(tǒng)交互的人機界面設計以及模塊間、系統(tǒng)與外部的接口關系。數(shù)據(jù)設計：包括數(shù)據(jù)庫、數(shù)據(jù)文件、全局數(shù)據(jù)結構的定義。體系結構設計是軟件設計的早期活動，它的作用集中在兩點：1、提供軟件設計師能預期的體系結構描述2、數(shù)據(jù)結構、文件組織、文件結構體現(xiàn)了軟件設計的早期抉擇，這些抉擇將極大地影響著后續(xù)的軟件開發(fā)人員，影響著軟件產(chǎn)品的最后成功。抽象：抽象是指對軟件設計不同層次的理解，它與分解是解決問題的兩個方面。分解是對問題細節(jié)的表述，抽象則忽略問題的細節(jié)，抓住問題的本質。抽象根據(jù)對象類型的不同，分為對實體對象抽象、接口抽象和設計模式抽象。模塊獨立性由內(nèi)聚性好人耦合度兩個指標來評價。內(nèi)聚性高或耦合度低，獨立性就強。內(nèi)聚性：偶然內(nèi)聚：模塊間功能偶然聚集在一起，導致模塊的不易理解，不易修改維護。邏輯內(nèi)聚：將邏輯相關的功能放在同一模塊內(nèi)，由模塊參數(shù)來決定執(zhí)行哪一個功能。時間內(nèi)聚：各任務間彼此無聯(lián)系，但由于需要在同一時間運行而聚集在一起。過程內(nèi)聚：按照過程描述，在同一模塊內(nèi)至上而下的組織各任務。通信內(nèi)聚：模塊中各成分引用共同的數(shù)據(jù)，即模塊內(nèi)的功能使用統(tǒng)一輸入數(shù)據(jù)。順序內(nèi)聚：各成分中，前一部分的輸出是下一部分的輸入，它們彼此具有較高的依賴性。功能內(nèi)聚：共同完成一個具體功能，它們之間緊密聯(lián)系，不可分割，具有較高的內(nèi)聚性。耦合度:耦合度越低，模塊尖緊密程度月松散，模塊獨立性越強。非直接耦合：模塊間沒有直接的數(shù)據(jù)調(diào)用關系。數(shù)據(jù)耦合：模塊間相互調(diào)用時，傳遞的是基本數(shù)據(jù)類型，而非復合數(shù)據(jù)結構。特征耦合：模塊間相互調(diào)用時，傳遞的是復合數(shù)據(jù)結構而非基本數(shù)據(jù)結構?？刂岂詈希耗K間傳遞的數(shù)據(jù)不是普通的值信息，而是控制變量。公共耦合:多個模塊訪問全局變量、結構、文件等公共信息都稱為公共耦合。內(nèi)容耦合：一個模塊直接訪問另一個模塊內(nèi)部的數(shù)據(jù)，或一個模塊有多個入口，或一個模塊非法進入另一個模塊內(nèi)部?？紤]模塊耦合度時，應遵循“盡量使用數(shù)據(jù)耦合，少用控制耦合，限制公共耦合范圍，堅決避免使用內(nèi)容耦合”。數(shù)據(jù)倉庫模型是一種集中式模型。詳細設計的任務是完成過程設計。過程設計包括:確定軟件各模塊內(nèi)部的具體實現(xiàn)過程和局部數(shù)據(jù)結構。軟件設計的原則：分而治之、重用設計模式、可跟蹤性、靈活性、一致性。簡答題：數(shù)據(jù)倉庫模型的優(yōu)點：1、數(shù)據(jù)統(tǒng)一存儲和管理，確保了數(shù)據(jù)的實時性2、數(shù)據(jù)倉庫對數(shù)據(jù)復雜性的統(tǒng)一封裝有利于數(shù)據(jù)共享3、采用黑板模型，與某類數(shù)據(jù)有關的應用系統(tǒng)能及時獲取數(shù)據(jù)4、采用數(shù)據(jù)訂閱推送模型，應用系統(tǒng)在有數(shù)據(jù)更新時，能自動獲得數(shù)據(jù)，而不用采取詢問方式，提高了數(shù)據(jù)管理效率5、各應用系統(tǒng)間僅通過數(shù)據(jù)倉庫完成數(shù)據(jù)交換，在功能上沒有關聯(lián)，增加，刪除應用系統(tǒng)及其部分功能，將不會影響其他應用系統(tǒng)的正常運行。集中式數(shù)據(jù)倉庫不足：1、增加了數(shù)據(jù)倉庫設計的復雜性，降低了數(shù)據(jù)傳遞的效率2、應用系統(tǒng)的數(shù)據(jù)結構發(fā)生改變，就需要單獨設計數(shù)據(jù)適配器，以實現(xiàn)新的結構與數(shù)據(jù)倉庫在數(shù)據(jù)上的匹配3、數(shù)據(jù)共享帶來的訪問控制的復雜性、安全性、效率、備份、存儲、恢復策略等一系列問題，影響了倉庫模型的有效利用。分布式結構特點：1、共享:實現(xiàn)了數(shù)據(jù)共享，云計算的提出還能進一步實現(xiàn)云計算共享2、異構型:客戶端/服務器允許軟件配置不同3、開放性：只要符合互聯(lián)網(wǎng)協(xié)議，任何計算機，局域網(wǎng)，智能設備和物品等都可連入互聯(lián)網(wǎng)。4、易修改性：由于用戶界面，系統(tǒng)邏輯和數(shù)據(jù)訪問分布的不同，各部分具有較強的獨立性，易于系統(tǒng)的修改和維護5、透明性：分布式結構中僅需要知道服務器的服務位置，而對后端的邏輯實現(xiàn)，數(shù)據(jù)存儲，數(shù)據(jù)訪問等不必清楚其架構和訪問方式。簡答第二大題可能啟發(fā)式規(guī)則：改進軟件結構，提高模塊獨立性2、模塊規(guī)模適中3、軟件結構的寬度、深度、扇出度和扇出度都應適中4、模塊的作用域應在模塊控制域之內(nèi)5、設計單入口、單出口的模塊，并力爭降低模塊接口的復雜度?？赡艿诙箢}簡答模塊的作用域是指模塊內(nèi)定義的所有元素（如數(shù)據(jù)、變量等）各自有效的使用范圍。模塊的控制域是指模塊所能操作和調(diào)用的所有元素（如其他模塊等）的集合。模塊的作用域應在模塊的控制域之內(nèi)TheoMandel提出的界面設計黃金三原則：置用戶與控制之下2、減少用戶的記憶負擔3、保持界面一致。MVC軟件設計模型：模型—視圖—控制器。模型是系統(tǒng)的主體部分，使用系統(tǒng)處理數(shù)據(jù)規(guī)則和使用控制邏輯的業(yè)務規(guī)則?？刂破鞫x了應用程序的行為，它負責對用戶的請求進行解析。視圖完成對數(shù)據(jù)的展示，包括數(shù)據(jù)接收、數(shù)據(jù)分布、維度分析、信息展示等一系列步驟，但視圖不包括應用系統(tǒng)的任何數(shù)據(jù)規(guī)則和業(yè)務邏輯。MVC軟件設計模型優(yōu)勢：一個模型對應多個不同的視圖2、模型的自包含性3、控制層把一個模型和多個不同的視圖組合在一起，能夠完成多種類型的請求4、MVC分層模式使得只修改其中某層就能滿足用戶新的需求，使系統(tǒng)達到不同的效果，且更易于系統(tǒng)的更新升級5、MVC利于軟件工程的工程化管理。缺點:1、增加了系統(tǒng)的復雜性2、導致修改的連鎖反應3、數(shù)據(jù)訪問效率低。第四章結構化設計方法填空題：結構化設計分為面向數(shù)據(jù)流的設計方法和面向數(shù)據(jù)的設計方法。結構圖與層次圖的不同是，它增加了對連線的數(shù)據(jù)流描述。*變換分析法還是事務分析法是以數(shù)據(jù)流圖為基礎，并根據(jù)數(shù)據(jù)流的特征進行軟件系統(tǒng)結構涉及到方法。*結構化設計的詳細設計階段，主要完成系統(tǒng)各模塊功能的過程描述。詳細設計提供了圖形，表格和語言等三類不同工具。結構化設計的思想，是提供一種自頂向下，逐步求精，單入口單出口的程序設計。判斷：由于合圖沒有控制流，控制的跳轉就不能隨意轉移PAD圖體現(xiàn)了自頂向下，自左向右，逐步細化，逐層推進的設計工程。第五章軟件實現(xiàn)客觀題：程序設計語言的分類：機器語言：自從有了計算機，就有了計算機語言。匯編語言：匯編語言也是與系統(tǒng)硬件直接交互的機器語言，但它已經(jīng)有了一定的符號指令。高級語言：4GL：4GL是過程描述語言。將要實現(xiàn)的功能，而實現(xiàn)的過程被隱藏起來。4GL應用是數(shù)據(jù)庫的結構化查詢語言。簡答題：源代碼形式的復用源代碼復用要求被復制重用的代碼和新系統(tǒng)的開發(fā)代碼是同一種語言，或是能兼容的程序語言。利用中間語言實現(xiàn)跨語言的重要。泛型編程提供了一定抽象層面的源代碼復用，并提供了一組標準容器類。源代碼形式的重用導致代碼兼容的問題。填空： 面向對象程序設計語言機制：類，繼承性，多態(tài)性，消息機制選擇：變量和常量的命名應遵循匈牙利命名法。軟件復用包括代碼復用，設計模式復用，軟件開發(fā)過程復用代碼復用是最低級的判斷：語句結構處理 每行語句只表達一個語義信息，如賦值，運算，函數(shù)調(diào)用，判斷等。不能同時具有多個表達式。 現(xiàn)階段對編碼的標準，已是可理解性第一，效率第二。 代碼評審分為正式評審和輕重量級評審正式評審：正是評審是針對代碼編寫完成之后召開的評審會議。輕重量級的評審：主要采取非正式的代碼走查方式，不需要組織正式會議，因此它成本小，靈活性強。第六章測試的重要概念的定義：失敗，錯誤，缺陷，測試用例判斷：軟件測試是在一定軟件環(huán)境下，以最小的成本來驗證系統(tǒng)能否按照需求正確運行，并盡可能多地發(fā)現(xiàn)存在的錯誤。測試只能證明程序有錯，并盡可能多地發(fā)現(xiàn)存在的錯誤。軟件測試的目的發(fā)現(xiàn)程序中的錯誤，它既找不出錯誤發(fā)生地位置，也不分析出錯的原因。一個好的測試用例和過程有可能發(fā)現(xiàn)一個尚未發(fā)現(xiàn)的錯誤。一個成功的測試用例是發(fā)現(xiàn)了一個尚未發(fā)現(xiàn)的錯誤。進行測試要求有測試配置（如測試方案，測試計劃，測試用例等），測試環(huán)境配置，執(zhí)行測試過程，最后進行測試結果與預期結果的對比及評價。簡答：測試的V模型測試W模型測試H模型主要特點軟件測試不再是一個獨立階段，而是貫穿于整個開發(fā)過程，與各流程并發(fā)。軟件測試分階段，分層次，分對象，并按照開發(fā)過程先后順序進行的活動，是一個迭代過程。軟件測試應早準備，早執(zhí)行。軟件測試需要測試配置，測試方案，測試用例和預期測試結果，而不僅是測試的運行?？陀^題：1應盡早地和不斷地進行測試軟件錯誤的放大效應，即每一階段產(chǎn)生的錯誤都會給下一階段造成更大的錯誤。2開發(fā)人員應盡量避免參加測試3注重測試用例的設計和選擇對測試對象進行完全測試是困難的表現(xiàn)在：不可能測試所有的輸入數(shù)據(jù)。不可能測試用戶的輸入行為。不可能測試所有路徑。4增量式測試5充分注意測試的群集現(xiàn)象充分注意測試的群集現(xiàn)象:軟件中的錯誤不是均勻分布在各部分中的，而是出現(xiàn)扎堆的現(xiàn)象。當發(fā)現(xiàn)某部分出現(xiàn)錯誤時，就應該進一步測試是否還存在更多的錯誤。6合理安排測試計劃，嚴格執(zhí)行測試計劃7全面統(tǒng)計和分析檢測試結果8保存測試文檔，并及時更新設計階段分為概要設計和詳細設計兩個子階段概要設計確認測試的方案保證軟件系統(tǒng)整體的功能，性能符合需求。詳細設計單元測試方案既要完成內(nèi)部流程測試，也要驗證接口定義是否符合設計規(guī)范，并能正確傳遞數(shù)據(jù)或信息。填空題：靜態(tài)測試的測試對象包括源程序和文檔。對文檔的測試數(shù)據(jù)都屬于靜態(tài)測試。動態(tài)測試的測試對象是源程序白盒測試和黑盒測試綜合題邏輯覆蓋1語句覆蓋（最弱）2判定覆蓋3條件覆蓋4判定/條件覆蓋5條件組合覆蓋路經(jīng)測試，等價劃分綜合題有效等價類是指對被測程序來講，是最有意義的，合理的數(shù)據(jù)組合。無效等價類正好相反，試圖通過無效的，無意義的數(shù)據(jù)，從反面說明軟件功能和性能可靠性。邊界值分析是對等價類劃分的有益補充。再劃分等價類的過程中，有效和無效等價類的邊界，往往是測試的重點。判斷題：錯誤推測是根據(jù)測試人員的經(jīng)驗和直覺來推測程序中可能存在的各類錯誤。因果圖是一個通過邏輯網(wǎng)絡表示的形式語言，他將輸入數(shù)據(jù)作為因，把輸出數(shù)據(jù)看做果填空或選擇1模塊接口2局部數(shù)據(jù)結構