測試方法

黑盒測試法：

黑盒測試也稱為功能測試，在完全不考慮軟體的內部結構和特性的情況下，測試軟體的外部特性。

白盒測試法：

根據程序的內部結構和邏輯來設計測試用例，對程序的路徑和過程進行測試，檢查是否滿足設計的需要。

白盒測試常用的技術是邏輯覆蓋、循環覆蓋和基本路徑測試。

（1）邏輯覆蓋

語句覆蓋。語句覆蓋是指選擇足夠的測試數據，使被測試程序中每條語句至少執行一次。語句覆蓋對程序執行邏輯的覆蓋很低，因此一般認為它是很弱的邏輯覆蓋。

判定覆蓋（分支覆蓋）。判定覆蓋是指設計足夠的測試用例，使得被測程序中每個判定表達式至少獲得一次「真」值和「假」值。或者說是程序中的每一個取「真」分支和取「假」分支至少都通過一次，因此判定覆蓋也稱為分支覆蓋。

條件覆蓋。條件覆蓋是指構造一組測試用例，使得每一判定語句中每個邏輯條件的各種可能的值至少滿足一次。

路徑覆蓋。路徑覆蓋是指覆蓋被測試程序中所有可能的路徑。

功能需求：

管道過濾器體系結構：

系統設計的基本原理

1．抽象

抽象是一種設計技術，重點說明一個實體的本質方面，而忽略或者掩蓋不很重要或非本質的方面。

2．模塊化

模塊在程序中是數據說明、可執行語句等程序對象的集合，或者是單獨命名和編址的元素。

模塊化是指將一個待開發的軟體分解成若干個小的簡單部分——模塊，每個模塊可獨立地開發、測試，最後組裝成完整的程序。

3．信息隱蔽

信息隱蔽是開發整體程序結構時使用的法則，即將每個程序的成分隱蔽或封裝在一個單一的設計模塊中，定義每一個模塊時儘可能少地顯露其內部的處理。

1）耦合

耦合性是指模塊之間聯繫的緊密程度。耦合性越高，則模塊的獨立性越差。模塊間耦合的高低取決於模塊間接口的複雜性、調用的方式及傳遞的信息。模塊的耦合有以下幾種類型。

• 無直接耦合。指兩個模塊間沒有直接的關係，它們分別從屬於不同模塊的控制與調用，它們之間不傳遞任何信息。因此，模塊間耦合性最弱，模塊獨立性最高。
• 數據耦合。指兩個模塊之間有調用關係，傳遞的是簡單的數據值，相當於高級語言中的值傳遞。這種耦合程度較低，模塊的獨立性較高。
• 標記耦合。指兩個模塊之間傳遞的數據結構，如高級語言中的數據組名、記錄名、文件名等這些名字即為標記，其實傳遞的是這個數據結構的地址。
• 控制耦合。指一個模塊調用另一個模塊時，傳遞的是控制變量，被調模塊通過該控制變量的值有選擇地執行塊內的某一功能。
• 公共耦合。指通過一個公共數據環境相互作用的那些模塊之間的耦合。
• 內容耦合。這是程度最高的耦合。當一個模塊直接使用另一個模塊的內部數據，或通過非正常入口而轉入另一個模塊內部，這種模塊之間的耦合為內容耦合，這種情況往往出現在彙編程序設計中。

2）內聚

內聚是指模塊內部各元素之間聯繫的緊密程度，例如一個完成多個功能的模塊的內聚度就比完成單一功能的模塊的內聚度低。內聚度越低，模塊的獨立性越差。內聚性有以下幾種類型。

• 偶然內聚。指一個模塊內的各個處理元素之間沒有任何聯繫。
• 邏輯內聚。指模塊內執行幾個邏輯上相似的功能，通過參數確定該模塊完成哪一個功能。
• 時間內聚。把需要同時執行的動作組合在一起形成的模塊為時間內聚模塊。
• 通信內聚。指模塊內所有處理元素都在同一個數據結構上操作，或者指各處理使用相同的輸入數據或者產生相同的輸出數據。
• 順序內聚（過程內聚）。指一個模塊中各個處理元素都密切相關於同一功能且必須順序執行，前一功能元素的輸出就是下一功能元素的輸入。（也叫過程內聚）
• 功能內聚。這是最強的內聚。指模塊內所有元素共同完成一個功能，缺一不可。耦合性和內聚性是模塊獨立性的兩個定性標準，將軟體系統劃分模塊時，儘量做到高內聚、低耦合，提高模塊的獨立性。

維護類型

軟體維護

改正性維護(正確性維護)。是指改正在系統開發階段已發生而系統測試階段尚未發現的錯誤。

適應性維護：是指使應用軟體適應信息技術變化和管理需求變化而進行的修改。

改善型維護：這是為擴充功能和改善性能而進行的修改，主要是指對已有的軟體系統增加一些在系統分析和設計階段中沒有規定的功能與性能特徵。

預防性維護：為了改進應用軟體的可靠性和可維護性，為了適應未來的軟硬體環境的變化，應主動增加預防性的新的功能，以使應用系統適應各類變化而不被淘汰。

軟體工程

軟體開發過程模型（重點，各模型的特點和區別）

瀑布模型:

瀑布模型是將軟體生存周期各個活動規定為依線性順序連接的若干階段的模型。需求是明確和完整的。

它是一種理想的線性開發模式，缺乏靈活性，特別是無法解決軟體需求不明確或不準確的問題。

演化模型:

大量的軟體開發實踐表明，許多開發項目在開始時對軟體需求的認識是模糊的，因此很難一次開發成功。為了減少因對軟體需求的了解不夠確切而給開發工作帶來的風險，可以在獲取了一組基本的需求

後，通過快速分析構造出該軟體的一個初始可運行版本，這個初始的軟體通常稱為原型（Prototype），然後根據用戶在使用原型的過程中提出的意見和建議對原型進行改進，獲得原型的新版本。重複這一過程，最終可得到令用戶滿意的軟體產品。採用演化模型的開發過程，實際上就是從初始的原型逐步演化成最終軟體產品的過程。演化模型特別適用於對軟體需求缺乏準確認識的情況。

演化模型適合初始時需求不明確的項目，通過用戶交互和疊代完成最終開發。

螺旋模型：

螺旋模型最大的特點在於引入了其他模型不具備的風險分析，使軟體在無法排除重大風險時有機會停止，以減小損失。同時，在每個疊代階段構建原型是螺旋模型用以減小風險的途徑。螺旋模型更適合大型的昂貴的系統級的軟體應用。

對於複雜的大型軟體，開發一個原型往往達不到要求。螺旋模型將瀑布模型和演化模型結合起來，加入了兩種模型均忽略的風險分析，彌補了這兩種模型的不足。

螺旋模型將開發過程分為幾個螺旋周期，每個螺旋周期大致和瀑布模型相符合。在每個螺旋周期分為如下4個工作步。

（1）制定計劃。確定軟體的目標，選定實施方案，明確項目開發的限制條件。

（2）風險分析。分析所選的方案，識別風險，消除風險。

（3）實施工程。實施軟體開發，驗證階段性產品。

（4）用戶評估。評價開發工作，提出修正建議，建立下一個周期的開發計劃。

噴泉模型:

噴泉模型是一種以用戶需求為動力，以對象作為驅動的模型，適合於面向對象的開發方法。它克服了瀑布模型不支持軟體重用和多項開發活動集成的局限性。噴泉模型使開發過程具有疊代性和無間隙

性。疊代意味著模型中的開發活動常常需要重複多次，在疊代過程中不斷地完善軟體系統。無間隙是指在開發活動（如分析、設計、編碼）之間不存在明顯的邊界，也就是說，它不像瀑布模型那樣，需求分析活動結束後才開始設計活動，設計活動結束後才開始編碼活動，而是允許各開發活動交叉、疊代地進行。

增量模型

增量模型是一種非整體開發的模型，該模型具有較大的靈活性，適合於軟體需求不明確的一種模型。使用該模型開發產品，一般是儘快構造出可運行的產品，然後在該產品的基礎上再增加需要的新的構建，使產品更趨於完善。

原型模型

原型模型基於這樣一種客觀事實：並非所有的需求在系統開發之前都能準確地說明和定義。因此，它不追求也不可能要求對需求的嚴格定義，而是採用了動態定義需求的方法。它適用於需求不明確的開發環境。

軟體開發方法

面向數據流方法（結構化方法）

結構化方法由結構化分析、結構化設計、結構化程序設計構成，它是一種面向數據流的開發方法。結構化分析是根據分解與抽象的原則，按照系統中數據處理的流程，用數據流圖來建立系統的功能模型，從而完成需求分析工作。結構化設計是根據模塊獨立性準則、軟體結構優化準則將數據流圖轉換為軟體的體系結構，用軟體結構圖來建立系統的物理模型，實現系統的概要設計。結構化程序設計是根據結構程序設計原理，將每個模塊的功能用相應的標準控制結構表示出來，從而實現詳細設計。

Jackson方法（一種面向數據結構的開發方法）

JSP方法是以數據結構為驅動的，適合於小規模的項目。

原型化開發：

原型化開發比較適合於用戶需求不清、業務理論不確定、需求經常變化的情況。當系統規模不是很大也不太複雜時，採用該方法是比較好的。

面向對象方法

面向對象開發方法的基本出發點是儘可能按照人類認識世界的方法和思維方法來分析和解決問題。客觀世界是由許多具體的事物、事件、概念和規則組成，這些均可被看成對象，面向對象方法正是以對

象作為最基本的元素，它也是分析問題、解決問題的核心。

結構化設計

在結構化設計中，系統由多個邏輯上相對獨立的模塊組成，在模塊劃分時需要遵循如下原則：

（1）模塊的大小要適中。系統分解時需要考慮模塊的規模，過大的模塊可能導致系統分解不充分，其內部可能包括不同類型的功能，需要進一步劃分，儘量使得各個模塊的功能單一；過小的模塊將導致系統的複雜度增加，模塊之間的調用過於頻繁，反而降低了模塊的獨立性。

（2）模塊的扇入和扇出要合理。一個模塊的扇出是指該模塊直接調用的下級模塊的個數；扇出大表示模塊的複雜度高，需要控制和協調過多的下級模塊。扇出過大一般是因為缺乏中間層次，應該適當增加中間層次的控制模塊；扇出太小時可以把下級模塊進一步分解成若干個子功能模塊，或者合併到它的上級模塊中去。一個模塊的扇入是指直接調用該模塊的上級模塊的個數；扇入大表示模塊的復用程度高。

（3）深度和寬度適當。深度表示軟體結構中模塊的層數，如果層數過多，則應考慮是否有些模塊設計過於簡單，看能否適當合併。寬度是軟體結構中同一個層次上的模塊總數的最大值，一般說來，寬度越大系統越複雜，對寬度影響最大的因素是模塊的扇出。

軟體複雜性

McCabe度量法:

節點數n＝6，弧數m＝9，p＝1

V(G)=m-n+2p=9-6+2=5

數據流圖

數據流圖或稱數據流程圖（Data Flow Diagram, DFD），是一種便於用戶理解、分析系統數據流程的圖形工具。它擺脫了系統的物理內容，精確地在邏輯上描述系統的功能、輸入、輸出和數據存儲等，

是系統邏輯模型的重要組成部分。

• 數據流。數據流由一組固定成分的數據組成，表示數據的流向。值得注意的是，DFD中描述的是數據流，而不是控制流。除了流向數據存儲或從數據存儲流出的數據流不必命名外，每個數據流都必須有一個合適的名字，以反映該數據流的含義。
• 加工。加工描述了輸入數據流到輸出數據流之間的變換，也就是輸入數據流經過什麼處理後變成了輸出數據流。每個加工有一個名字和編號。編號能反映出該加工位於分層DFD中的哪個層次和哪張圖中，也能夠看出它是哪個加工分解出來的子加工。
• 數據存儲。數據存儲用來表示存儲的數據，每個數據存儲都有一個名字。
• 外部實體。外部實體是指存在於軟體系統之外的人員或組織，它指出系統所需數據的發源地和系統所產生的數據的歸宿地。

測試策略和測試方法

1、自頂向下集成

優點：較早地驗證了主要控制和判斷點；按深度優先可以首先實現和驗證一個完整的軟體功能；功能較早證實，帶來信心；只需一個驅動，減少驅動器開發的費用；支持故障隔離。

缺點：柱的開發量大；底層驗證被推遲；底層組件測試不充分。

適應於產品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要儘早被驗證；希望儘早能看到產品的系統功能行為。

2、自底向上集成

優點：對底層組件行為較早驗證；工作最初可以並行集成，比自頂向下效率高；減少了樁的工作量；支持故障隔離。

缺點：驅動的開發工作量大；對高層的驗證被推遲，設計上的錯誤不能被及時發現。

適應於底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。

3.三明治法

統一過程（ Rational Unified Process）

統一過程模型是一種「用例驅動，以體系結構為核心，疊代及增量」的軟體過程框架，由UML方法和工具支持。

RUP把一個項目分為四個不同的階段：

構思階段 ：包括用戶溝通和計劃活動兩個方面，強調定義和細化用例，並將其作為主要模型。

細化階段 ：包括用戶溝通和建模活動，重點是創建分析和設計模型，強調類的定義和體系結構的表示。 （關注需求分析和架構演進）

構建階段 ：將設計轉化為實現，並進行集成和測試。

移交階段 ：將產品發布給用戶進行測試評價，並收集用戶的意見，之後再次進行疊代修改產品使之完善。

數據流

數據流圖的設計原則：

① 數據守恆原則

② 守恆加工原則

③ 對於每個加工，必須既有輸入數據流，又有輸出數據流

④ 外部實體與外部實體之間不存在數據流

⑤ 外部實體與外部存儲之間不存在數據流

⑥ 數據存儲與數據存儲之間不存在數據流

⑦ 父圖與子圖的平衡原則

⑧ 數據流與加工有關，且必須經過加工

真題

1. 以下關於管道過濾器體系結構的有點的敘述中，不正確的是（ C ）。

A．軟體構件具有良好的高內聚、低耦合的特點 B.支持重用 C.支持並行執行 D.提高性能

試題分析

管道過濾器不支持批處理和並發操作。

1. 並列爭球法使用了疊代的方法，其中，把每段時間（30天）一次的疊代稱為一個「衝刺」，並按需求的優先級別來實現產品，多個自組織和自治的小組並行地遞增實現產品。

3.軟體質量特性

可移植性包含：適應性、易安裝性、共存性和易替換性四個特性。

4.噴泉模型屬於面向對象開發模型

5.

6.根據軟體過程活動對軟體工具進行分類，則逆向工程工具屬於（ 軟體維護 ）工具。

7.採用McCabe度量法計算下列程序圖的環路複雜性為（ ）。

試題分析

點數：8，邊數：10。

10-8+2=4。

8.以下關於增量模型的敘述中，正確的是（ ）。

B.可以快速構造核心產品

試題分析

增量模型融合了瀑布模型的基本成分（重複應用）和原型實現的疊代特徵，該模型採用隨著日程時間的進展而交錯的線性序列，每一個線性序列產生軟體的一個可發布的「增量」。當使用增量模型時，第1個增量往往是核心的產品，即第1個增量實現了基本的需求，但很多補充的特徵還沒有發布。客戶對每一個增量的使用和評估都作為下一個增量發布的新特徵和功能，這個過程在每一個增量發布後不斷重複，直到產生了最終的完善產品。

9.CMM（Capability Maturity Model）是能力成熟度模型的縮寫

（1）初始級：軟體過程的特點是無秩序或說無定規的，有時甚至是混亂的。軟體過程定義幾乎處於無章法、無步驟可循的狀態，軟體產品所取得的成功往往依賴於極個別人的努力和機遇。

（2）可重複級：已建立了基本的項目管理過程，可用於對成本、進度和功能特性進行跟蹤。對類似的應用項目，有章可循並能重複以往所取得的成功。

（3）已定義級：用於管理的和工程的軟體過程均已文檔化、標準化，並形成了整個軟體組織的標準軟體過程。全部項目均採用與實際情況相吻合的、適當修改後的標準軟體過程來進行操作。

（4）已管理級：軟體過程和產品質量有詳細的度量標準。軟體過程和產品質量得到了定量的認識和控制。

（5）優化級：通過對來自過程、新概念和新技術等方面的各種有用信息的定量分析，能夠不斷地、持續地對促進過程進行改進。（成熟度最高）

10.在軟體開發過程中，系統測試階段的測試目標來自於（ 需求分析）階段。

11.增量式開發的主要優點包括：

1、由於能夠在較短的時間內向用戶提交一些有用的工作產品，因此能夠解決用戶的一些急用功能。

2、由於每次只提交用戶部分功能，用戶有較充分的時間學習和適應新的產品。

3、對系統的可維護性是一個極大的提高，因為整個系統是由一個個構件集成在一起的，當需求變更時只變更部分部件，而不必影響整個系統。

12.系統的可維護性的評價指標包括：可理解性、可測試性、可修改性。

13.需求分析階段的任務主要是要解決系統做什麼的問題，即弄清楚問題的要求，包括需要輸入什麼數據，要得到什麼結果，最後應輸出什麼。

概要設計的主要任務是把需求分析得到的結果轉換為軟體結構和數據結構，即將一個複雜系統按功能**進行模塊劃分、建立模塊的層次結構及調用關係、確定模塊間的接口及人機界面、確定數據的結構特性、以及資料庫的設計**等。

詳細設計是在概要設計的基礎上更細緻的設計，它包括具體的業務對象設計、功能邏輯設計、界面設計等工作。詳細設計是系統實現的依據，需要更多地考慮設計細節。

編碼即編寫程序代碼，具體實現系統。