《軟件工程》60’

一.、軟件過程

1、軟件過程的概念

答：

1）**軟件過程描述為為了開發出客戶需要的軟件，什么人、在什么時候、做什么事以及怎么做這些事以實現某一種的具體目標。**ISO9000把過程定義為：“使用資源將輸入轉化為輸出的活動所構成的系統”。（《軟件工程導論》p14）

2）過程定義了運用方法的順序、應該交付的文檔資料、為保證軟件質量和協調變化所需要采取的管理措施以及標志軟件開發各個階段任務完成的里程碑。（《軟件工程導論》p14）

3）軟件過程是軟件生成周期中的一系列相關的過程。過程是活動的集合，活動是任務的集合。（《復旦大學軟工PPT》）

軟件過程有三層含義：

個體含義：

即指軟件產品或系統在生存周期中的某一類活動的集合，如軟件開發過程，軟件管理過程等；

整體含義：

即指軟件產品或系統在所有上述含義下的軟件過程的總體；

工程含義：

即指解決軟件過程的工程，它應用軟件工程的原則、方法來構造軟件過程模型，并結合軟件產品的具體要求進行實例化，以及用戶環境下的運作，以此進一步提高軟件生產率，降低成本。

2、經典軟件過程模型特點（瀑布模型、增量模型、演化模型、統一過程模型）

答：

瀑布模型

• 瀑布模型將軟件生命周期劃分為需求分析、規格說明、設計、程序編寫、軟件測試和運行維護等六個基本活動，并且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。

• 瀑布模型強調文檔的作用，并要求每個階段都要仔細驗證。

• 瀑布模型模型的線性過程太理想化，已不再適合現代的軟件開發模式，幾乎被業界拋棄，主要問題是：

  1.各個階段的劃分完全固定，階段之間生成大量的文檔，極大地增加了工作量；

  2.由于開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而增加了開發的風險；

  3.早期的錯誤可能要等到開發后期的測試階段才能發現，進而帶來嚴重的后果。

增量模型

與建造大廈相同，軟件也是一步一步建造起來的。

在增量模型中，軟件被作為一系列的增量構件來設計、實現、集成和測試，每一個構件是由多種相互作用的模塊所形成的提供特定功能的代碼片段構成。

• 增量模型在各個階段并不交付一個可運行的完整產品，而是滿足客戶需求的一個子集的可運行產品。
• 增量模型側重于每個增量都提交一個可以運行的產品。
• 整個產品被分解成若干個構件，開發人員逐個構件地交付產品，這樣做的好處是軟件開發可以較好地適應變化，客戶可以不斷地看到所開發的軟件，從而降低開發風險。

但是，增量模型也存在以下缺陷：

1.由于各個構件是逐漸并入已有的軟件體系結構中的，所以加入構件必須不破壞已構造好的系統部分，還需要軟件具備開放式的體系結構。

2.在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其事情這種變化的能力大大優于瀑布模型和快速原型模型，但是也很容易退化為邊做邊改模型，從而使軟件過程的控制失去整體性。

在使用增量模型時，第一個增量往往是實現基本需求的核心產品。核心產品交付用戶使用后，經過評價形成下一個增量的開發計劃，它包括對核心產品的修改和一些新功能的發布。每個過程在每個增量發布后不斷重復，直到產生最終的完善產品。

演化模型

演化模型是一種全局的軟件（或產品）生存周期模型。屬于迭代開發方法。

即根據用戶的基本需求，通過快速分析構造出該軟件的一個初始可運行版本，這個初始的軟件通常稱之為原型，然后根據用戶在使用原型的過程中提出的意見和建議對原型進行改進，獲得原型的新版本。重復這一過程，最終可得到令用戶滿意的軟件產品。

采用演化模型的開發過程，，實際上就是從初始的原型逐步演化成最終軟件產品的過程。演化模型特別適用于對軟件需求缺乏準確認識的情況。

缺點：

1.如果所有的產品需求在一開始并不完全弄清楚的話，會給總體設計帶來困難以及削弱產品設計的完整性，并因而影響產品性能的優化及產品的可維護性；

2.如果缺乏嚴格的過程管理的話，這個生命周期模型很可能退化為一種原始的無計劃的“試-錯-改”模式；

統一過程模型

統一過程（RUP/UP,Rational Unified Process）是一種以用例驅動、以體系結構為核心、迭代以及增量的軟件過程模型，由UML方法和工具支持，廣泛應用于各類面向對象項目。

RUP是Rational公司開發并維護，和一系列軟件開發工具緊密集成。RUP蘊含了大量優秀的實踐方法，這些經驗被稱為“最佳實踐”。

最佳實踐包括：

• 迭代式軟件開發
• 需求管理
• 基于構件的架構應用
• 建立可視化的軟件模型
• 軟件質量嚴重
• 軟件變更控制等

RUP的靜態結構包括6個核心工作流（業務建模、需求、分析設計、實現、測試、部署）和3個核心支持工作流（配置與變更管理、項目管理、環境）

RUP把軟件的生命周期劃分成4個連續的階段。每個階段都有明確的目標，并且定義了用來評估是否達到這些目標的里程碑。每個階段的目標通過一次或多次迭代來完成。

4個階段的工作目標包括：初始階段、精華階段、構建階段、移交階段。

RUP模型采用迭代開發，通過多次執行不同的開發工作流，逐步確定一部分需求分析和風險，在設計、實現并確認這部分后，再去做下一部分的需求分析、設計、實現和確認工作，依次進行下去，直到整個項目完成，這樣能夠在逐步集成中更好地理解需求，構建一個健壯的體系結構。

3、過程評估與CMM/CMMI的基本概念

答：

1）CMM(Capability Maturity Model)即能力成熟度模型，是美國卡耐基梅隆大學軟件工程研究所（SEI）在美國國防部資助下于二十世紀八十年代末建立的，用于評價軟件機構的軟件過程能力成熟度的模型。此模型在建立和發展之初，主要目的在于提供一種評價軟件承接方能力的方法，為大型軟件項目的招投標活動提供一種全面而客觀的評審依據。而發展到后來，又同時被軟件組織用于改進其軟件過程。（《復旦大學軟件工程ppt》）

CMM提供了一個成熟度等級框架：

• 1級-初始級
• 2級-可重復級
• 3級-已定義級
• 4級-已管理級
• 5級-優化級

2）美國國防部、美國國防工業委員會和SEI/CMU于1998年啟動CMMI項目，希望CMMI是若干過程模型的綜合和改進，是支持多個工程學科和領域的系統的、一致的過程改進框架，能適應現代工程的特點和需要，能提高過程的質量和工作效率。（《復旦大學軟件工程ppt》）

3）CMMI模型為每個學科的組合都提供兩種表示法：階段式模型和連續式模型。

4、敏捷宣言與敏捷過程的特點

1）敏捷宣言：

（《復旦大學軟件工程ppt》）

? （1）個人和交互高于過程和工具

不是否定過程和工具的重要性，而是強調軟件開發中人的作用和交流的作用。軟件是由人組成的團隊來開發的，與軟件項目相關的各類人員通過充分的交流和有效的合作，才能成功地開發出得到用戶滿意的軟件。

如果光有定義良好的過程和先進的工具，而人員的技能很差，又不能很好地交流和協作，軟件是很難成功地開發的。

? （2）可運行軟件高于詳盡的文檔

通過一個可運行的軟件了解軟件做了什么，遠比閱讀厚厚的文檔要容易得多。

敏捷軟件開發強調不斷地快速地向用戶提交可運行的軟件（不一定是完整的軟件），以得到用戶的認可。

好的必要的文檔仍是需要的，它幫助我們理解軟件做什么，怎么做，以及如果使用，但軟件開發的主要目標時創建可運行的軟件。

? （3）與客戶協作高于合同（契約）談判

只有客戶才能明確說明需要什么樣的軟件，然而，大量的實踐表明，在開發的早期客戶常常不能完整地表達他們的全部需求，有些早期確定的需求，以后也可能會改變。

要想通過合同談判的方式，將需求固定下來常常是困難的。

敏捷軟件開發強調與客戶的協作，通過與客戶的交流和緊密合作來F愛心那用戶的需求。

（4）對變更及時做出反應高于遵循計劃

任何軟件項目的開發都應該制訂一個項目計劃，以確定開發任務的優先順序和起止日期。然而，隨著項目的進展，需求、業務環境、技術等都可能變化，任務的優先順序和起止日期也可能因種種原因會改變。

因此，項目計劃應具有可塑性，有變動的余地。當出現變化時幾十做出反應，修訂計劃以適應變化。

2)敏捷過程的特點

（《復旦大學軟件工程ppt》）

? （1）最優先的是通過盡早地和不斷地提交有價值的軟件使用戶滿意

? （2）歡迎變化的需求，即使該變化出現在開發后期，為了提升對客戶的競爭優勢，Agile過程利用變化作為動力。

? （3）以幾周到幾個月為周期，盡快、不斷地發布可運行軟件

? （4）在整個項目過程中，業務人員和開發人員必須天天一起工作

? （5）以積極向上的員工為中心建立項目組，給予他們所需要的環境和支持，對他們的工作予以充分的信任

? （6）項目組內效率最高、最有效的信息傳遞方式是面對面的交流

? （7）測量項目進展的首要依據是可運行的軟件

? （8）敏捷過程提倡可持續的開發，項目發起者、開發者和用戶應能長期保持恒定的速度

? （9）應時刻關注技術上的精益求精和好的設計，以增強敏捷性

? （10）簡單化是必不可少的，這是盡可能減少不必要工作的藝術

? （11）最好的架構、需求和設計出自于自我組織的團隊

? （12）團隊要定期反思怎樣才能更有效，并據此調整自己的行為

二、軟件需求

1、軟件需求的概念

答：

主觀需求：用戶解決一個問題或達到一個目標所需要的一種狀態或能力；

客觀需求：系統為了滿足一種約定、標準、規格說明或其它正式文件而必須滿足或擁有的一種狀態或能力；

功能性需求：

系統需要提供的服務或功能：如圖書檢索；

系統對特定輸入的處理方式：如對非法輸入的提示；

系統在特定環境下的行為：如長時間無操作的屏保；

非功能性需求：

對系統功能或服務附加的質量約束，例如響應時間、容錯性、安全性等-客戶所關心的（外部質量）；

從系統開發和維護角度的質量屬性，例如可理解下、可擴展性等-軟件開發或維護者所關心的（內部質量、軟件所持有）

2、需求工程的基本過程

答：

需求獲取、需求分析與協商、系統建模、需求規約、需求驗證、需求管理

3、分層數據流模型

答：

分層數據流圖的設計方法

第一步，畫子系統的輸入輸出

把整個系統視為一個大的加工，然后根據數據系統從哪些外部實體接受數據流，以及系統發送數據流到哪些外部實體，就可以畫出輸入輸出圖。這張圖稱為頂層圖。

第二步，畫子系統的內部

把頂層圖的加工分解成若干個加工，并用數據流將這些加工連接起來，使得頂層圖的輸入數據經過若干加工處理后，變成頂層圖的輸出數據流。這張圖稱為0層圖。從一個加工畫出一張數據流圖的過程就是對加工的分解。可以用下述方法來確定加工：在數據流的組成或值發生變化的地方應該畫出一個加工，這個加工的功能就是實現這一變化，也可以當作一個單位來處理（這些數據一起到達、一起處理）時，可以把這些數據看成一個數據流。關于數據存儲，對于一些以后某個時間要使用的數據，可以組織成為一個數據存儲來表示。

第三步，畫加工的內部

把每個加工看作一個小系統，把加工的輸入輸出數據流看成小系統的輸入輸出流。于是可以像畫0層圖一樣畫出每個小系統的加工DFD圖。

第四步，畫子加工的分解圖

對第三步分解出來的DFD圖中的每個加工，重復第三步的分解過程，直到圖中尚未分解的加工都是足夠簡單的（即不可再分解）。至此，得到一套分層數據流圖。

第五步，對數據流圖和加工編號

對于一個軟件系統，其數據流圖可能有許多層，每一層又有許多張圖。為了區分不同的加工和不同的DFD子圖，應該對每張圖進行編號，以便于管理。

• 頂層圖只有一張，圖中的加工也只有一個，所以不必為其編號。
• 0層圖只有一張，圖中的加工號分別為0.1、0.2、…,或者1,2.
• 子圖就是父圖中被分解的加工號。
• 子圖中的加工號是由圖號、圓點和序號組成，如：1.12、1、3等等。

4、用例和場景建模及其UML表達（用例圖、活動圖、泳道圖、順序圖）

用例圖：

用例是對一個活動者使用系統的一項功能時所進行的交互過程的一個文字描述序列。對系統的用戶需求的描述，表達的是系統的功能和所提供的服務，它只描述活動者和系統在交互過程中做些什么，并不描述怎么做。

活動圖：

活動圖是狀態圖的一種特殊情況。用于簡化描述一個過程或者操作的工作步驟。活動用圓角矩形表示-比狀態圖更窄，更接近橢圓。一個活動中的處理一旦完成，則自動引起下一個活動的發生。箭頭表示從一個活動轉移到下一個活動。和狀態圖類似，活動圖中的起點用一個實心圓表示，終點用一個同心圓（內圓是實心圓）表示。在活動圖中可以帶判定點，即一組條件引發一條執行路徑，另一組條件則引發另一條執行路徑，并且這兩條執行路徑時互斥的。判定點常用小的菱形圖標表示，同時在相關路徑的附近指明引起這條路徑被執行的條件，條件用方括號括起來。請用活動圖描述打電話過程。

泳道圖：

泳道將活動圖中的活動劃分為若干組。并將一組指定給負責這組活動的業務組織。在活動圖中，泳道使用垂直的實線繪制。

順序圖：

順序圖是強調消息時間的交互圖，其描述了對象之間傳送消息的時間順序，用來表示用例中的行為順序。在該二維圖中，對象由左至右排列，消息則沿著縱軸由時間順序排列。在構筑改圖時，應布局簡潔。

示意圖，購買小車簡圖。

5、數據模型建模及其UML表達（類圖）

答：

類圖（Class Diagram）是描述類、接口、協作以及它們之間關系的圖，用來顯示系統中各個類的靜態結構。類圖是定義其他圖的基礎，在類圖基礎上，可以使用狀態圖、協作圖、組件圖和配置圖等進一步描述系統其他方面的特性。

在UML中，類被表述成為具有相同結構、行為和關系的一組對象的描述符號。所用的屬性與操作都被附在類中。類定義了一組具有狀態和行為的對象。其中，屬性和關聯用來描述狀態。屬性通常使用沒有身份的數據值來表示，如數字和字符串。關聯則使用有身份的對象之間的關系表示。行為由操作來描述，方法是操作的具體實現。對象的生命周期則由附加給類的狀態機來描述。

在UML的圖形表示中，類的表示法是一個矩形，這個矩形由三個部分構成，分別是類的名稱（Name）、類的屬性（Attribute）和類的操作（Operation）。類的名稱位于矩形的頂端，類的屬性位于矩形的中間部位，而矩形的底部顯示類的操作。中間部位不僅顯示類的屬性，還可以顯示屬性的類型以及屬性的初始化值等。矩形的底部也可以顯示操作的參數表和返回類型等，如圖1所示。

在類的構成中還應當包含類的職責（Resopnsibility）、類的約束（Constraint）和類的注釋（Note）等信息。

6、行為模型建模及其UML表達（狀態機圖）

答：

狀態機圖是用來為對象的狀態及造成狀態改變的事件建模。UML的狀態機圖主要用于建立對象類或對象的動態行為模型，表現一個對象所經歷的狀態序列，引起狀態或活動轉移的事件，以及因狀態或活動轉移而伴隨的動作。狀態機圖也可用于描述Use Case，以及全系統的動態行為。

三、軟件設計與構造

1、軟件體系結構及體系結構風格的概念

答：

軟件體系結構（百度版）：具有一定形式的結構化元素，即構件的集合，包括處理構件、數據構件和連接構件。處理構件負責對數據進行加工，數據構件是被加工的信息，鏈接構件把體系結構的不同部分分組組合連接起來。這一定義注重區分處理構件、數據構件和連接構件，這一方法在其他的定義和方法中基本上得到保持。由于軟件系統具有的一些共同特性，這種模型可以在多個系統之間傳遞，特別是可以應用到具有相似質量屬性和功能需求的系統中，并能夠促進大規模軟件的系統級復用。

軟件體系結構（指定教材版本）：程序或計算機系統的軟件體系結構是指系統的一個或者多個結構，它包括軟件構件、構件的外部可以見屬性以及它們之間的相互關系。

體系結構并非可運行的程序。它是一種表達，能達到以下三種目的：

1）對設計在滿足既定需求方面的有效性分析

2）在設計變更相對容易的階段，考慮體系結構可能的選擇方案

3）降低與軟件構建相關的風險

體系結構風格：對軟件體系結構風格的研究和實踐促進了對設計的復用，一些經過實踐證實的解決方案也可以可靠地用于解決新的問題。體系結構風格的不變部分使不同的系統可以分享同一個實現代碼。只要系統是使用常用的、規范的方法來組織，就可使別的設計者很容易地理解系統的體系結構。例如，如果某人把系統描述為“客戶/服務器”模式，則不必給出設計細節，我們立刻就會明白系統是如何組合和工作的。

下面是Garlan和Shaw對通用體系結構風格的分類：

1）數據流風格：批處理序列；管道/過濾器

2）調用/返回風格：主程序/子程序；面向對象風格；層次結構

3）獨立構件風格：進程通訊；事件系統

4）虛擬機風格：解釋器；基于規則的系統

5）倉庫風格：數據庫系統；超文本系統；黑板系統

2、設計模式的概念（來自百度）

答：

軟件設計模式（Design Pattern），又稱設計模式，是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性、程序的重用性。

3、模塊化設計的基本思想及概念（抽象、分解、模塊化、封裝、信息隱藏、功能獨立）（來自教材）

1)模塊化：模塊化設計思想是把整個軟件劃分為幾個獨立命名的或者獨立訪問的構成成分，這些模塊集合起來就滿足了問題的需要，就能把一個大而復雜的軟件系統劃分成易于理解的比較單純的模塊化結構。

模塊化的要求：需要滿足信息隱蔽原則，模塊之間相互獨立，并且盡量符合高內聚低耦合的要求。

2）封裝：是一種信息隱蔽技術，用戶只能看到對象封裝界面上的信息，對象的內部實現對用戶是隱蔽的。封裝的目的是使對象的使用和生產者分離。使對象的定義和實現分開。一個對象通常由對象名、屬性和操作三部分組成。

3）信息隱蔽：每個模塊的實現細節對于其它模塊來說是隱蔽的（不可訪問），即模塊中所包含的信息（數據和過程）不允許其它不需要這些信息的模塊使用。

信息隱蔽作用：設計時把一些可能發生變化的因素隱蔽在某個模塊中，以提高可維護性，并且可以減少錯誤向外傳播。

4、軟件重構的概念；軟件體系結構的UML建模（包圖、類圖、構件圖、順序圖、部署圖）；（來自博客與教材）

答：

1）重構：以不改變代碼外部行為而改進其內部結構的方式來修改軟件系統的過程。這是一種凈化代碼以盡可能減少引入錯誤的嚴格方法。

2)包圖（略，非重點）：屬于靜態圖的一種

3）類圖（重點）：展示系統類的靜態結構，即類與類之間的相互聯系。

具體含義及其畫法（看網站一學就會）https://blog.csdn.net/monkey_d_meng/article/details/6005764（博客 ）

4)構件圖

構件圖顯示代碼的靜態結構、是用代碼組件來顯示代碼物理結構的。

5）順序圖（重點）

用來顯示對象之間發送消息的順序，以及對象之間的交互，例題：

6）部署圖（略，非重點）

展現系統中硬件和軟件的物理機構

畫法：https://blog.csdn.net/wangyongxia921/article/details/8250129

5、接口的概念；面向對象設計原則（開閉原則、Liskov替換原則、依賴轉置原則、接口隔離原則）

開閉原則：

類的改動是通過增加代碼進行的，而不是修改源代碼。

里氏代換原則：

任何抽象類出現的地方都可以用他的實現類進行替換，實際就是虛擬機制，語言級別實現面向對象功能。

依賴倒轉原則：

依賴于抽象（接口），不要依賴具體的實現（類），也就是針對接口編程。

接口隔離原則：

不應該強迫用戶的程序依賴他們不需要的接口方法。一個接口應該只提供一種對外功能，不應該把所有的操作都封裝到一個接口中去。

6、內聚與耦合的概念，常見的內聚和耦合類型

答：

“高內聚，低耦合”

起因：模塊獨立性指每個模塊只完成系統要求的獨立子功能，并且與其他模塊的聯系最少且接口簡單，兩個定性的度量標準-耦合性和內聚性。

耦合性也稱塊間聯系。指軟件系統結構中各模塊間互相聯系緊密程度的一種度量。模塊之間聯系越緊密，其耦合性就越強，模塊的獨立性則越差。模塊間耦合高低取決于模塊間接口的復雜性、調用的方式及傳遞的信息。

耦合性分類（低-高）：無直接耦合；數據耦合；標記耦合；控制耦合；公共耦合；內容耦合；

1）無直接耦合：兩個模塊之間沒有直接聯系，它們之間的聯系完全是通過主模塊的控制和調用來實現的；

2）數據耦合：指兩個模塊之間有調用關系，傳遞的是簡單的數據值，相當于高級語言的值傳遞；

3）標記耦合：指連個模塊之間傳遞的是數據結構，如高級語言中的數組名、記錄名、文件名等這些名字即標記，其實傳遞的是這個數據結構的地址；

4）控制耦合：指一個模塊調用另外一個模塊時，傳遞的是控制變量（如開關、標志等），被調模塊通過該控制變量的值有選擇地執行塊內某一功能；

5）公共耦合：指通過一個公共數據環境相互作用的那些模塊間的耦合。公共耦合的復雜程序隨耦合模塊的個數增加而增加。

6）內容耦合：這是最高程度的耦合，也是最差的耦合。當一個模塊直接使用另一個模塊的內部數據，或通過非正常入口而轉入另一個模塊內部。

內聚性又稱塊內聯系。指模塊的功能強度的度量，即一個模塊內部各個元素彼此結合的緊密程度的度量。若一個模塊內各元素（語名之間、程序段之間）聯系的越緊密，則它的內聚性就越高。

內聚性分類（低-高）：偶然內聚；邏輯內聚；時間內聚；通信內聚；順序內聚；功能內聚；

1）偶然內聚：指一個模塊內的各處理元素之間沒有任何聯系。

2）邏輯內聚：指模塊內執行幾個邏輯上相似的功能，通過參數確定該模塊完成哪一功能。

3）時間內聚：把需要同時執行的動作組合在一起形成的模塊稱為時間內聚模塊。

4）通信內聚：指模塊內所有處理元素都在同一個數據結構上操作（有時稱之為信息內聚），或者指各處理使用相同的輸入數據或者產生相同的數據數據。

5）順序內聚：指一個模塊中各個處理元素都密切相關于同一功能且必須順序執行，前一功能元素輸出就是下一個功能元素的輸入。

6）功能內聚：這是最強的內聚，指模塊內所有元素共同完成一個功能，缺一不可。與其他模塊耦合是最弱的。

耦合性與內聚性是模塊獨立性的兩個定性標準，將軟件系統劃分模塊時，盡量做到高內聚低耦合，提高模塊獨立性，為設計高質量的軟件結構奠定基礎。

四、軟件測試

1、軟件測試及測試用例的概念；

答：

軟件測試是在規定的條件下對程序進行操作，以發現程序錯誤，衡量軟件質量，并對其是否能滿足設計要求進行評估的過程。

測試用例是為了某個特殊的目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求。

2、單元測試、集成測試、確認測試、系統測試、回歸測試的概念；

答：

單元測試：又稱模塊測試，著重對軟件設計的最小單位（程序模塊）進行驗證。單元測試根據設計描述，對重要的控制路徑進行測試，以發現各個模塊內部的錯誤。單元測試通常采用白盒測試，并且多個模塊并行進行測試。

集成測試：又稱組裝測試。、聯合測試，經單元測試后，每個模塊都能獨立工作，但把它們放在一起往往不能正常工作。確認測試以軟件需求規格說明書為依據，檢查軟件的功能和性能及其它特寫是否與用戶的需求一致，包括合同規定的全部功能和性能、文檔資料（正確且合理）、其他需求（如可移植性、兼容性、錯誤恢復能力、可維護性等）。

系統測試：是將通過確認測試的軟件，作為整個基于計算機系統的一個元素，與其它系統成分（如硬件、外設、某些支持軟件、數據和人員等）集成起來，在實際運行環境下，對計算機系統進行一系列的集成測試和確認測試。系統測試的目的在于通過與系統的需求定義作比較，發現軟件與系統定義不符合或與之矛盾的地方。

回歸測試：是指修改舊代碼后，重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產出錯誤。

3、調試的概念、調試與測試的關系；

答：

測試的目的是發現錯誤，調試（也稱排錯）的目的是確定錯誤的原因和準確位置，并加以糾正。

調試與測試的關系：測試和調試在目標、方法和思路上都有所不同，測試是一個過程，目的是顯示存在的軟件錯誤，通常由軟件測試工程師實施。而調試是一種方法，一種手段，目的是發現錯誤原因并解決，一般來說調試時測試后的活動，通常由開發工程師實施。

4、測試覆蓋度的概念

答：

測試覆蓋度評估是衡量階段性軟件測試執行狀態的重要手段之一，來確定測試是否達到事先設定的測試任務完成的標準。測試覆蓋率則是測試覆蓋度評估中一種量化的表示方法，一般通過被測試的軟件產品需求、功能點、測試用例數或程序代碼等來進行計算。

5、白盒測試、黑盒測試的概念

答：

白盒測試又稱結構測試，這種方法把測試對象看作一個透明的盒子，測試人員根據程序內部的邏輯結構及有關信息涉及測試用例，檢查程序中所有邏輯路徑是否按預定的要求正確地工作。

黑盒測試又叫做功能測試，這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能說明。

6、代碼圈復雜度的計算方法

答：

圈復雜度是一種代碼復雜度的衡量標準。在軟件測試的概念里，圈復雜度用來衡量一個模塊判定結構的復雜程度，數量上表現為獨立線性路徑條數，即合理的預防 錯誤所需測試的最小路徑條數，圈復雜度大說明程序代碼可能質量低且難以測試和維護，根據經驗，程序的可能錯誤和高的圈復雜度有很大關系。它的計算方法為：V（G）=e-n-2p。e表示控制流圖中邊的數量，n表示控制流圖中節點的數量，p表示圖的連接組件數目（圖的組件數是相連節點的最大集合），因為控制流圖都是連通的，所以p永遠為1

V（G）=區域數=判定節點數+1

V（G）=R。R代表平面被控制流圖劃分成的區域數

7、白盒測試中的基本路徑測試方法

答：

基本路徑測試是一種白盒測試技術，這種方法首先根據程序或設計圖畫出控制流圖，并計算其區域數，然后確定一組組里的程序執行路徑（稱為基本路徑），最后為每一條基本路徑設計一個測試用例。在實際問題中，一個不太復雜的程序，其路徑數可能很大，特別在包含循環時。因此要把覆蓋的路徑數壓縮到一定的限度內。

8、黑盒測試中等價類劃分方法

答：

等價類劃分是指由于不能窮舉所有可能的輸入數據來進行測試，所以只能選擇少量有代表性的輸入數據，來揭露盡可能多的程序錯誤，等價類劃分方法將所有可能的輸入數據劃分成若干個等價類，然后在每個等價類中選取一個代表性的數據作為測試用例，測試用例由有效等價類和無效等價類的代表組成，從而保證測試用例具有完整性和代表性。

mg-5OugY4Ha-1607958334409)]

V（G）=區域數=判定節點數+1

[外鏈圖片轉存中…(img-Paxa2fta-1607958334410)]

V（G）=R。R代表平面被控制流圖劃分成的區域數

[外鏈圖片轉存中…(img-wcfd9uYF-1607958334410)]

7、白盒測試中的基本路徑測試方法

答：

基本路徑測試是一種白盒測試技術，這種方法首先根據程序或設計圖畫出控制流圖，并計算其區域數，然后確定一組組里的程序執行路徑（稱為基本路徑），最后為每一條基本路徑設計一個測試用例。在實際問題中，一個不太復雜的程序，其路徑數可能很大，特別在包含循環時。因此要把覆蓋的路徑數壓縮到一定的限度內。

8、黑盒測試中等價類劃分方法

答：

等價類劃分是指由于不能窮舉所有可能的輸入數據來進行測試，所以只能選擇少量有代表性的輸入數據，來揭露盡可能多的程序錯誤，等價類劃分方法將所有可能的輸入數據劃分成若干個等價類，然后在每個等價類中選取一個代表性的數據作為測試用例，測試用例由有效等價類和無效等價類的代表組成，從而保證測試用例具有完整性和代表性。

總結

以上是生活随笔為你收集整理的【细说软件工程】《软件工程》Software Engineering的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。