軟件工程教程課后參考答案

第1章

一、選擇題

(1)D(2)B(3)C(4)D(5)D(6)A(7)D

二、簡答題

(1)什么是軟件危機?軟件危機表現在哪些方面？

答：具體來說，軟件危機出現的原因可以概括如下。

①忽視軟件開發前期的需求分析。

②開發過程缺乏統一的、規范化的方法論指導。

③文檔資料不齊全或不準確。

④忽視與用戶之間、開發組成員之間的交流。

⑤忽視測試的重要性。

⑥不重視維護或由于上述原因造成維護工作的困難。

⑦從事軟件開發的專業人員對這個產業的認識不充分，缺乏經驗。

⑧沒有完善的質量保證體系。

具體地說，軟件危機的表現形式可以概括如下。

①軟件開發費用和進度失控。

②軟件系統實現的功能與實際需求不符。

③軟件的可靠性差。

④軟件難以維護。

⑤軟件通常沒有適當的文檔資料。

⑥軟件成本在計算機系統總成本中所占的比例居高不下，且逐年上升。

⑦軟件生產率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢。

(2)簡述軟件和軟件工程的定義以及軟件工程的形成過程。

答：軟件是計算機系統中與硬件相對應的另一部分，是一系列程序、數據

及其相關的文檔集合。在這里，程序是按照特定順序組織的計算機數據和指令

的集合；數據是使程序能正常執行的數據結構；文檔是是開發、使用和維護程

序所需要的圖文資料。

1

軟件工程是應用計算機科學理論和技術以及工程管理原則和方法，按預算

和進度，實現滿足用戶要求的軟件產品的定義、開發、發布和維護的工程或進

行研究的學科。

軟件工程的發展經歷了以下四個階段。

①20世紀70年代。為了解決軟件項目失敗率高、錯誤率高以及軟件維護

任務重等問題，人們提出了軟件生產工程化的思想，希望使軟件生產走上正規

化的道路，并努力克服軟件危機。人們發現將傳統工程學的原理、技術和方法

應用于軟件開發，可以起到使軟件生產規范化的作用。

②20世紀80年代。面向對象的方法與技術受到了廣泛的重視,maltalk-80

的出現標志著面向對象的程序設計進入了實用和成熟階段。20世紀80年代末,

逐步發展起來的面向對象的分析與設計方法，己經形成了完整的面向對象技術

體系，使系統的生存周期更長，適應更大規模、更廣泛的應用。

③20世紀90年代末。出現了許多的敏捷方法，如自適應軟件開發、水晶

項目開發、動態系統開發、極限編程、特征驅動開發和Scrum等。這些主要的

敏捷方法的創始人在2001年聚集一堂，并發表了敏捷開發宣言。

④21世紀。對快速應用開發(RapidApplicationDevelopment,RAD)追

求的趨勢仍在繼續，在信息技術、組織、競爭對策及環境等方面的變革步伐也

正在加快。云計算、大數據、物聯網、人工智能和機器學習、移動互聯網、三

維打印、可穿戴式技術、虛擬現實、增強現實、社交媒體、無人駕駛汽車和飛

機等技術不斷涌現。“大規模計算”、“自治和生化計算機”、“模型驅動體

系結構”和“構件化軟件開發”等新領域都可能成為接下來軟件工程發展的主

要方向。

(3)軟件工程的目標是什么？如何解決多目標之間的矛盾？

答：軟件工程要達到的基本目標包括以下六方面。

①達到要求的軟件功能。

②取得較好的軟件性能。

③開發出高質量的軟件。

④付出較低的開發成本。

⑤需要較低的維護費用。

⑥能按時完成開發工作，及時交付使用。

2

軟件工程的首要問題是軟件質量。軟件工程的目的就是在以上目標的沖突

之間取得一定程度的平衡。因此，在涉及平衡軟件工程目標這個問題的時候，

軟件的質量應該擺在最重要的位置加以考慮。軟件質量可用功能性、可靠性、

可用性、效率、可維護性和可移植性等六個特性來評價。

(4)什么是軟件生存周期?它分為幾個時期?幾個階段？

答：軟件生存周期是指從設計該產品的構想開始，到軟件需求的確定、軟

件設計、軟件實現、產品測試與驗收、投入使用，以及產品版本的不斷更新，

到該產品最終被市場淘汰的全過程。軟件生存周期由軟件定義、軟件開發和運

行維護三個時期組成，劃分為問題定義、可行性研究、需求分析、概要設計、

詳細設計、軟件實現和單元測試、綜合測試和運行維護八個階段。

(5)什么是軟件生存周期模型?有哪些主要軟件過程模型？

答：軟件生存期模型也稱為軟件過程模型，是從軟件項目需求定義直至軟

件運行維護為止，跨越整個生命周期的系統開發、運行和維護所實施的全部過

程、活動和任務的結構框架。典型的包括瀑布模型、快速原型模型、增量模型、

螺旋模型、統一過程、敏捷過程等。

(6)在軟件工程知識體系中，將軟件工程劃分為哪些知識域？

答：SWEBOK將軟件工程知識體系劃分為10個知識域，包含在兩類過程中。

一類過程是開發與維護過程，包括軟件需求、軟件設計、軟件構造、軟件測試

和軟件維護；另一類過程是支持過程，包括軟件配置管理、軟件工程管理，軟

件工程過程、軟件工程工具寫方法、軟件質量。每個知識域還可進一步分解為

若干個論題，在論題描述中引用有關知識的參考文獻，形成一個多級層次結構,

以此確定軟件工程知識體系的內容和邊界。

3

（2）設計一個軟件的開發成本為5萬元，壽命為3年。未來3年的每年收益預

計為：2200元，24000元，26620元。銀行年利率為10%。試對此項目進行成

本-效益分析，以決定其經濟可行性。

解：進行投入產出分析時，未來的收益和現在消耗的成本不能直接進行比

較，必須在考慮貨幣的時間價值后，才能進行準確的投入、產出分析。

22000/（1+10%）+24000/（1.1x1.1）+26620/（1.1x1.1x1.1）-50000=20000+1983

4.71

+20000-50000=9834.71

經濟可行性分析投資收益為：9834.71元。

（3）某軟件公司統計發現該公司研發部門每一萬行C語言源代碼形成的源文

件（.c和.h文件）約為250K。某項目的源文件大小為3.75M。

①問該項目的規模是多少KLOC（源代碼行數）？該公司研發部門的生產

率是0.625KLOC/人月，人工價是10000元/人月。

②問工作量和總成本是多少？

③每行代碼的價值是多少？

解：①3.75M/250K=15萬行=150KLOC

②工作量=規模/生產率=150KLOC/0.625KLOC=240人月

成本二工作量x人工價=240人月*10000元/人月=240萬元

③24（）萬元/15萬行=16元/行

（4）某計算機系統投入使用后，每年可節約人民幣20000元，假設軟件生存期

為4年，系統投資額為50000元，若年利率為5%,試計算效益。

解：表面上看，4年共節約20000*4=80000元，扣除投資55000元可產生

純收入25000元。其實不然，因為投資在前，效益產生有一個時間過程，所以

需要把4年內每年預計節約的錢折合成當前價值才能比較。若按年利率5%計

算,折合到當前值的數目如表1所示：

表1每年效益折算的當前值

年效益（元）利率(1+0.()5尸當前值（元）預計當前值（元）

1200001.051904719047

2200001.10251814037187

32(X)0()1.15761727754464

42(X)()()1.21551645470918

5

根據表1可計算出以下經濟指標：

純收入=4年累計的當前值-系統投資=70918-55000=15918（元）

投資回收期=3+（55000-54464）/16454-3.033年

（5）某旅館的電話號他服務如下：

可以撥分機號和外線號碼。分機號是從7201?7299。外線號碼先撥9,然

后是市話號碼或長話號碼。長話號碼是以區號和市話號碼組成。區號是從

100?300中任意的數字串。市話號碼是以局號和分句號組成。局號可以是455、

466、888、552中任意一個號碼。分局號是是任意長度為4的數字串。

要求：寫出在數據字典中，電話號碼的數據條目的定義（即組成）

解：電話號碼二分機號|外線號碼

分機號=7201...7299

外線號碼=9+［市話號碼|長話號碼］

長話號碼=區號+市話號碼

區號=100...300

市話號碼=局號+分局號

局號=L455|466|888|552J

分局號:4｛數字｝4

（6）某工廠的采購部每天需要一張訂貨報表，報表按零件編號排序，表中列出

所有需要再次訂貨的零件。對于每個需要再次訂貨的零件，應該列出下述數據:

零件編號，零件名稱，訂貨數量，目前價格，主要供應者，次要供應者。零件

入庫或出庫稱為事務，通過存放在庫房的CRT終端把事務報告給定貨系統。當

零件庫存量少于庫存量臨界值，決定再次訂貨，畫出訂貨系統的數據流圖。

解：問題分析：源點/終點，處理，數據存儲,數據流

1）源點/終點：系統之外的實體（人，物,系統）

源點：倉庫管理員

終點：采購員

2）處理：

需要報表一＞產生報表

處理日常事務一＞事務處理

3）數據存儲：

6

訂貨信息

庫存清單

4）數據流：

訂貨報表：零件編號、名稱、數量

事務：零件編號、事務類型、數量

Stepl：頂層數據流圖系統級

表1訂貨系統頂層DFD圖

構成：基本系統模型+源點+終點

一般采用自頂向下逐步細化的分層繪制方法

Step2：進一步分解——功能級

表2訂貨系統。層DFD圖

Step3：進一步分解——功能級

表3訂貨系統1層DFD圖

（7）開發某工程中使用的CAD系統需要投資20萬元，經估算在工程中用該

CAD系統后將取代大部分人工設計工作，每年可節省9.6萬元。若該軟件的生

存期為5年，年利率按5%計算，試求該項目的凈收入。

解：若按年利率5%計算，貨幣時間價值折合到當前值的數目如表2所示：

7

表2貨幣時間價值（萬元）

年份將來值(l+i)n現在值累計現在值

（萬元）（萬元）

19.61.059.14299.1429

29.61.10258.707517.8513

39.61.15768.292826.1432

49.61.21557.897934.0411

59.61.27637.521941.5630

純收入=5年累計的當前值-系統投資=41.5630-20=21.5630（萬元）

8

第3章

一、選擇題

(1)B(2)D(3)B(4)B(5)B

二、簡答題

(1)答：需求分析需要4個步驟，分別獲取、建模、描述和驗證。獲取需求實

質上是一個需求收集的過程，要做充分的調查研究°通常是從分析當前系統包

含的數據開始，分析當前系統在處理信息時的不足，用戶希望改進的主要問題

及迫切性等。收集需求的常用方法有問卷調查、訪談、實地操作、建立原型等,

收集的需求主要包括功能需求、性能需求、可靠性需求、可用性、人機界面需

求、約束、出錯處理等內容。需求分析的核心任務是建立分析模型，即把來自

用戶的需求信息通過分析、提取、歸納、抽象建立起描述目標系統的模型。傳

統的面向過程的軟件工程方法學，主要采用數據流圖建立目標系統的邏輯模型。

需求描述是指編制需求分析階段各類文檔。一般情況下，對于大型、復雜軟件

系統在需求分析階段會產生3個文檔：系統定義文檔(用于描述用戶需求的報

告)、系統需求規格說明書、軟件需求規格說明書，分別從不同的角度和層次

描述項目開發的需求。對于簡單的小規模軟件系統，只需編制SRS即可。因為

需求分析的成果是后續開發的重要依據和基礎，為了提高軟件產品的最終質量,

降低開發成本，必須對需求分析結果從完整性、一致性、有效性和現實性4個

方面進行嚴格的正確性驗證，并且要對需求的變更實施可回溯的管理，避免無

法追蹤錯誤來源導致的混亂。

(2)答：包括6個方面：確定對系統的綜合要去；分析系統的數據需求；建立

系統的邏輯模型；修訂系統開發計劃；編寫軟件需求規格說明書；需求分析評

審。

(3)答：結構化分析方法采用歸納思維和演繹思維的邏輯方法，逐步建立目標

系統的邏輯模型(包括數據模型、功能模型和行為模型)，進而描繪出滿足用

戶要求的軟件系統。

結構化需求分析方法基于“分解“和”抽象”的基本指導思想，采用面向數據流自

頂向下逐步求精的分析策略，逐步建立目標系統的邏輯模型。

“分解”是面對一個復雜系統時，為了將復雜性降低到人類認知能力可以掌

握的程度，而把一個大系統(問題)分解成若干個小問題，然后分別解決。

9

需求分析的目標之一是把數據流圖中的數據流和數據存儲分解定義到元素

級。通常做法是從數據流圖的輸出端著手分析，這是因為輸出數據決定了系統

必須具有的最基本的組成元素（即功能）。

具體做法是，沿著數據流圖從輸出端往輸入端回溯，以確定每個數據元素

的來源，與此同時也就初步定義了有關的算法。通常把分析過程中得到的數據

元素的信息定義成數據字典，對算法的簡明描述記錄在IPO表中。通過分析而

補充的數據流、數據存儲和處理，應該添加到數據流圖的適當位置。復查的過

程是從輸入端開始，向用戶解釋輸入的數據是經過怎樣的處理一步步變成了輸

出數據。反復經過上述過程，把數據流圖“分解“擴展到更低（即更詳細）的層

次，從而得到更具體、更令人滿意的功能性需求的了解。

（4）答：首先進行初步訪談，通過用戶對基本問題的回答，初步確定待解決問

題的范圍和解決方案。然后開發者和用戶分別寫出“產品需求

定會議的時間和地點以及主持會議的協調人。邀請雙方的代表出席會議，

并在會前預先把寫好的產品需求分發給每一位與會者。

要去每位與會者會前認真審查產品需求，并列出作為系統環境組成的部分

對象、系統將產生的對象以及系統為了完成自己的功能將使用的對象。此外，

還要求每位與會者列出操作這些對象或與這些對象交互的服務（即處理或功

能）。最后還應該列出約束條件（例如成本、規模、完成日期）和性能標準（例

如速度、容量）。并不希望每位與會者列出的內容毫無遺漏，但求能夠獲得對

目標系統準確的認識。

會議開始后，討論的第一個問題是是否需耍這個新產品，一旦大家都同意

確實需要這個新產品，每位與會者則把他們會前準備好的列表展示出來供大家

討論。在這個階段，嚴格禁止批評和爭論，以免影響每位與會者深入交流的意

愿。

在討論的基礎上，大家一起共同創建一張包含各個議題的組合列表。調整

后的組合列表并不真正刪除某項內容。在每個議題的組合列表都建立起來后，

在由協調人主持討論這些列表，以形成每個議題都達到意見一致的局面。

一旦得到了意見一致的列表，就把與會者分成更小的小組，針對每張列表

中的項目制定小型規格說明（需要對列表中包含的單詞或短語進行準確的說

明）。

10

然后，每個小組向全體與會者展示他們制定的小型規格說明，供大家討論。

意見一致后，每個與會者都制定一整套確認標準，并把自己制定的標準再次提

交會議討論，以創建出意見一致的確認標準。最后，有一名或多名與會者根據

會議成果起草完整的軟件規格說明書。

三、應用題

(1)描繪本系統功能的數據流圖如圖所示。

利

息

清

單

5

打印利息

清單

描繪本系統數據模型的E-R圖如下:

(2)描繪本系統的功能級數據流圖如下:

11

12

第4章

一、選擇題(多選)

(1)A(2)ABCD(3)BD(4)C(5)A

二、簡答題

(1)答：總體設計目標是：是得到良好的軟件總體結構，即獨立性良好、

規模適中的一組模塊以及深度、寬度、扇入、扇出合適的系統結構。主要任務

是把分析階段得到的數據模型映射成數據庫設計，把數據流圖映射成軟件功能

結構，行為模型可以用于詳細設計階段的流程、算法設計。

(2)答：設想供選擇的方案，選取合理的方案，推薦最佳方案，功能分級,

設計軟件結構，數據庫設計，制定測試計劃，編寫文檔，審查和復查。

(3)答：改進軟件結構提高模塊獨立性，模塊規模應該適中，深度、寬度、

扇入、扇出都應當適中，模塊的作用域應該在控制與內，降低模塊結構的復雜

度，設計單入口、單出口的模塊，模塊功能應該可以預測。

(4)答：復查基本系統模型，復查并精化數據流圖，確定數據流圖的類型,

確定數據流的邊界，完成“第一級分解”，完成“第二級分解”，優化。

(5)答：機械地遵循上述映射規則很可能會得出一些不必要的控制模塊,

如果它們確實用處不大，那么應該合并它們。如果控制模塊功能過分復雜，可

以適當地增加中間層的控制模塊或者進一步將它們分解。

何優化過程不能違背設計原理，不能違背問題域常識、不能為了最求所謂

的“最佳設計”而優化。

設計的優化可能會導出不同的軟件結構，要從中選優，力求得到“最好”的

結構。避免把結構的優化留到過程設計階段，這也是把結構設計和過程設計分

開的價值所在。

結構簡單往往表明效率高。設計優化應該力求做到在有效模塊化的前提下

使用盡可能少的模塊數，以及在能夠滿足信息要求的前提下使用最簡單的數據

結構。

三、應用題

(1)答：工資管理子系統數據流圖如下所示。

13

計算應扣除

稅金

稅金

生成工資表

工資表信息

工資管理子系統層次圖如下：

工資管理系統

子系統

錄入扣除信息計算數據輸出數據

（2）頂層數據流圖

14

還書處理分支數據流圖

修改庫存

I

次

庫存

查詢處理分支數據流圖

15

借書文件庫存

借閱事務前輛事務

信息渺利

接收讀者借閱庫存

事務?

事務查詢查詢查詢

借閱處理分支數據流圖

注意事項：必須保證登記完借書文件和修改完庫存后再出借圖書給借閱人，“登

記借書文件”和“修改庫存”誰先誰后影響不大。

事務

16

某圖書管理

系統

輸入信息業務辦理日常管理

借

借

借

庫

證用

用

還

書

書

閱

存

件

戶

戶

書

證

檢

查

手

查

查

注

手

錄

驗

詢

續

詢

詢

冊

續

入

—

—

借

庫

打

書

存

印

查

查

文

量

統

超

超

件

量

查

期

計

錄

詢

表

入

——

「

——

——

更

新

更

新

借

庫

書

存

文

件

17

第5章

一、填空題

(1)順序、選擇和循環三種基本控制結構

(2)完整嵌套

(3)層次線

(4)程序流程圖

(5)表格

(6)模塊接口計

(7)數據結構

(8)結構化程序設計、自頂向下、逐步求精油

(9)SP、問題分析圖

(10)結構化

(11)詳細設計說明書

二、選擇題

⑴D(2)C(3)C⑷B(5)A(6)B(7)B(8)A

⑼D(10)C(11)B(12)B(13)A(14)B(15)D

三、簡答題

(1)詳細設計的基本任務是什么?有哪兒種描述方法？

答：①為每個模塊確定采用的算法。

②確定每一模塊的內部數據結構及數據庫的物理結構。

③確定模塊接口的細節。

④要為每一個模塊設計出一組測試用例。

⑤編寫文檔，參加復審。

詳細設計的描述方法有圖形、表格和語言，其中，圖形常用結構化程序流

程圖、盒圖和PAD(問題分析圖)為描述工具，語言常用過程設計語言(PDL)來作

為工具。

(2)答：結構化程序設計的要點主要有以下三個。

①采用自頂向下、逐步求精的程序設計方法。

②使用三種基本控制結構構造程序。任何程序都可以由順序、選擇、重復

(循環)三種基本控制結構構造。

18

③每個程序模塊只有一個人口和一個出口。

(3)答：詳細設計階段描述處理過程常用的三種工具:圖形、表格和語言。

詳細設計工具有結構化程序流程圖、問題分析圖、盒圖和過程設計語言、判定

表及判定樹。

(4)答：流程圖的優點是直觀清晰、易于使用，是開發者普遍采用的工具,

但是它具有自身的缺點。

①可隨心所欲地控制流程線的流向.容易造成非結構化的程序結構。

②流程圖不易反映逐步求精的過程，往往反映最后結果。

③不易表示數據結構。

為克服流程圖的最大缺陷，要求流程圖由三種控制結構順序組合和完全嵌

套而成，不能交叉，這樣的流程圖是結構化的流程圖。

(5)答：PAD的特點如下。

①清晰反映程序的層次結構。

②支持逐步求精的設計方法，自左至右逐步細化。

③易讀易寫，使用方便。

④支持結構化的程序設計原理。

⑤可自動生成程序。

(6)答：PDL是在偽碼的基礎上，擴充了模塊的定義與調用、數據定義和

輸入輸出而形成的。它是一種用于描述模塊算法設計和處理細節的語言。分為

內外兩層語言，外層語法具有嚴格的規則;內層表示實際操作和條件的自然語

言，語法自由。

PDL表示的程序結陶一般有下列幾種:順序結構、選擇結構、重復結構、出

口結構、擴充結構(模塊定義、模塊調用、數據定義、輸入/輸出)等。

PDL的特點如下：

①關鍵字應有固定的語法,提供結構化的控制結構和數據說明，并在控制結

構的頭尾都加關鍵字，體現模塊化的特點。

②用自然語言敘述系統處理功能。

③應有說明各種數據結構的手段.

④描述模塊定義和調用及模塊接口模式。

PDL的優缺點如下：

19

①可以靈活地表達算法或作為注釋直接插入到原程序當中,可用普通的文

字處理系統進行書寫和編輯，并可用自動處理程序自動生成。就明的道

②不如圖形工具形象直觀，對復雜的描述不如判定表清晰。

(7)答：用方框圖來代替傳統流程圖的方法，稱為N-S圖。N-S圖的優點是

所有程序結構均用方框表示，無論并列或嵌套，程序結構清晰可見。而且它只能表

達結構化的程序邏輯，使用它的人必須遵守結構化程序設計的規定。不足是當

程序內嵌套的層數增多時，內層的方框會越來越小，從而增加繪圖的難度，并使

圖形清晰性受影響。

四、應用題

(1)用Halstead度量還可以用來預測程序中可能存在的錯誤E。一個程序對

75個數據庫項共訪問1300次，對150個運算符共使用了1200次，預測該程序

的錯誤數是多少？

那么預測該程序的錯誤數：

E=(l200+1300)*log2(75+150)/3000?6.5

即預測該程序中可能包含6?7個錯誤。

(2)假設某航空公司規定，乘客可以免費托運重量不超過30kg的行李。當行

李重量超過30kg時，對頭等艙的國內乘客超重部分每公斤收費4元，對其他艙

的國內乘客超重部分每公斤收費6元，對外國乘客超重部分每公斤收費比國內

乘客多一倍，對殘疾乘客超重部分每公斤收費比正常乘客少一半。用判定樹表

示計算行李費的算法。

20

Rules

__________________人___________________

Rulenumbers123456789

國內乘客TTTTFFFF

Condition頭等艙TFTFTFTF

rows<

殘疾乘客FFTTFFTT

行李重量WSQ30TFFFFFFFF

免費X

(W-30)xX

Actionrows(W-30)xX

《(W-30)xXX

(W-30)xXX

(W-30)*X

(W-30)x12X

頭等艙匚殘疾乘客(W-30)X2

正常乘客"-30)X4

國內乘客

殘疾乘客

其他艙匚(Jr-3O)X3

行李重量正常乘客"-30)X6

[K>30kg

頭等艙匚殘疾乘客""30)X4

正常乘客(獷-30)X8

外國乘客

行李費殘疾乘客(?z-30)X6

算法其他艙匚

正常乘客"-30)X12

行李重量

%(30kg免費

圖1用判定樹表示計算行李費的算法

(3)畫出下列偽碼程序的程序流程圖和盒圖

START

IFpTHEN

WHILEqDO

f

ENDDO

ELSE

BLOCK

o

n

ENDBLOCK

ENDIF

STOP

21

22

第6章

一、選擇題

(1)D(2)B(3)A(4)C(5)C(6)C(7)D(8)C(9)D(10)

B

(11)B(12)A

二、簡答題

(1)軟件測試應該劃分為幾個階段？各個階段應重點測試的內容是什么？

答:軟件測試可分為單元測試，集成測試，系統測試，驗收測試四個階段。

單元測試又稱模塊測試、邏輯測試或結構測試，是針對軟件設計的最小單

位一一程序模塊或功能模塊，進行正確性檢驗的測試工作。其目的在于檢驗每

個程序單元能夠正確實現詳細設計說明中的模塊功能、性能、接口和設計約束

等要求，發現各個模塊內部可能存在的各種錯誤。

集成測試又稱組裝測試、綜合測試或聯合測試。通常在單元測試的基礎上,

將所有的程序模塊進行有序的、遞增的測試。集成測試是檢驗程序單元或部件

的接口關系，逐步集成為符合概要設計要求的程序部件或整個系統。

系統測試為驗證和確認系統是否達到其原始目標，而對集成的硬件和軟件

系統進行的測試。系統測試是在真實或模擬系統運行的環境下，檢查完整的程

序系統能否和系統(包括計算機硬件、外設、網絡和系統軟件、支持平臺等)

正確配置、連接，并滿足用戶需求。系統測試的主要依據是《系統需求規格說

明書》文檔。

驗收測試又稱交付測試，是軟件在完成了單元測試、集成測試、系統測試

之后，產品發布之前進行的軟件測試活動。驗收測試又分為Alpha測試(。測

試)和Beta測試(B測試)，Alpha測試是由一個用戶在開發環境下進行的測

試，或者是公司內部的月戶在模擬實際操作環境下進行的受控測試，Beta測試

是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。

(2)在軟件測試中，應遵循哪些原則？

答：在軟件測試過程中，通常應該遵循以下七個原則。

①所有的測試都應追溯到用戶需求。這是因為軟件的目的是使用戶完成預

定的任務，滿足其需求。而軟件測試揭示軟件的缺陷和錯誤，一旦修正這些錯

誤，就能更好地滿足用戶需求。

23

②應盡早地和不斷地進行軟件測試。由于軟件的復雜性和抽象性，在軟件

生命周期各階段都可能產生錯誤，所以不應把軟件測試僅僅看作是軟件開發的

一個獨立階段，而應當把它貫穿到軟件開發的各個階段中去。在需求分析和設

計階段就應開始進行測試工作，編寫相應的測試計劃及測試設計文檔，同時堅

持在開發各階段進行技術評審和驗證，這樣才能盡早發現和預防錯誤，杜絕某

些缺陷和錯誤，提高軟件的質量。測試工作進行得越早，越有利于提高軟件的

質量,這是預防性測試的基本原則。

③在有限的時間和資源下進行完全測試并找出軟件所有的錯誤和缺陷是

不可能的，軟件測試不能無限進行下去，應適時終止。因為，測試輸入量大、

輸出結果多、路徑組合多、用有限的資源來達到完全測試是不現實的。

④測試只能證明軟件存在錯誤，而不能證明軟件沒有錯誤。測試無法顯示

潛在的錯誤和缺陷，繼續進一步測試可能還會找到其它錯誤和缺陷。

⑤充分關注測試中的集群現象。在測試的程序段中，若發現的錯誤數目比

較多，則殘存在