填空

1.軟件測試的目的是盡可能多地發現軟件中存在的錯誤，將測試結果作為糾錯的依據。

2.測試階段的基本任務是根據軟件開發各階段的和程序的，精心設計一組，利用這些實例執行，找出軟件

中潛在的各種和.

3.測試用例山和預期的兩部分組成。

4.軟件測試方法一般分為兩天類：方法和方法.

5.動態測試通過發現借誤。根據的設計方法不同，動態測試又分為與兩類。

6.靜態測試采用和的手段對程序進行檢測.

7.人工審查程序偏重于的檢驗,而軟件審查除了審查還要對各階段進行檢驗.

8.計算機輔助靜態分析利用工具對測試程序進行分析.

9.黑盒法只在軟件的處進行測試，依據說明書，檢查程序是否滿足要求。

10.白盒法必須考慮程序的和，以檢查的細節為基礎，對程序中盡可能多的邏輯路徑進行。

11.白盒測試是測試，被測對象是，以程序的為基礎設計測試用例.

12.邏輯覆蓋是對程序內部有存在的邏輯結構設計測試用例，根據程序內部的邏輯法蓋程度又可分為、、、、

和6種覆蓋技術。

13.實際的邏輯覆蓋測試中，一般以覆蓋為主設計測試用例，然后再補充部分用例，以達到覆蓋測試標準.

14.循環漫蓋是對程序內部有存在的邏輯結構設計測試用例，它通過限制來測試。

15.基本路徑測試是在程序基礎上，通過分析控制構造的笈雜性，導出集合，從而設計測試用例.

16.黑盒測試是測試,用黑盒技術設計測試用例有4種方法:、、

和.

17.等價類劃分從程序的說明，找出一個輸入條件（通常是或），然后將每個輸入條件劃分成兩個或多個。

18.邊界值分析是將測試情況作為重點目標，選取正好等于、剛剛大于或剛剛小于的測試數據.如果輸入或

輸出域是一個有序集合，則應選取集合的元素和元素作為測試用例，

19.在測試程序時，根據經驗或直覺推測程序中可能存在的各種錯誤，稱為。

20.因果圖的基本原理是通過畫圖，把用自然語言描述的轉換為，最后為每一列設計一個測試用例。

21.測試的綜合策略是在測試中，聯合使用各種方法。通常先用法設計基本的測試用例，再用法補充一些

必要的測試用例.

22.軟件測試過程中筋要3類信息：、和。

23.軟件測試一般經過4個測試：、、和。

24.指對源程序中每?個程序單元進行測試，檢查各個模塊是否正確實現規定的功能，從而發現模塊在編

碼中或算法中的錯誤，它涉及和的文檔。

25.單元測試主要測試的5個基本特征：、、、和.

26.在單元測試中，需要為被測模塊設計模塊和模塊。用來模擬被測模塊的上級調用模塊，用來代替被測模塊

所調用的模塊.

27.集成測試指在測試基礎上將所有模塊按照設計要求組裝成一個完整的系統進行的測試。也稱測試或測

試。

28.集成測試的方法有兩種:和.

29.漸增式測試有兩種不同的組裝模塊的方法:和。

30,自頂向下漸增式測試不需要編寫模塊，只需要編寫模塊，其步驟是從模塊開始，沿著被測程序的的控制

路徑逐步向下測試，它有兩種組合策略：和。

31.自底向上漸增式測試不需要編寫模塊，只需要編寫模塊。

32.確認測試指檢查軟件的與是否與說明書中確定的指標相符合，又稱測試。

33.確認測試在模擬環境下運用測試方法，由和參加的測試。

34.確認測試開始前需要制定計劃，結束后要寫出報告，其測試用例要選用的數據。

35.軟件配置審查的任務是檢查軟件的所有文檔資料的和。

36.調試也稱，是在成功的測試之后才開始進行，其目的是確定錯誤的和，并改正錯誤。

37.調試技術包括、、和。

38.回溯法調試是從出發，而歸納法調試是從入手。

39.被測試程序不在機器上運行，而是采用人工檢測和計算機輔助分析檢測的手段稱為

測試。

40.用等價類劃分法設計一個測試用例時，使其覆蓋尚未被覆蓋的合理等價類。

41.用等價類劃分法設計一個測試用例時，使其覆蓋不合理等價類.

42.在單元測試時，需要為被測模塊設計.

43.在集成測試時有兩種測試方法，它們是。

44.軟件測試是為了而執行程序的過程.

45.運行被測程序的方法稱為測試。

46.動態測試中，主要測試軟件功能的方法稱為法。

47.選擇測試用例，使得被測程序中每個判定的每個分支至少執行?次，這種邏輯覆蓋標準稱為.

48.要覆蓋含循環結構的所有路徑是不可能的，一般通過限制來測試。

49.用等價類劃分法設計測試用例時，如果被測程序的某個輸入條件規定了取值范圍，則可確定一個合理

的等在和。

50.憑經驗或直覺推測程序中可能存在的錯誤而設計測試用例的方法是.

51.集成測試中的具體方法是。

52.確認測試階段的兩項工作是。

53.在單元測試中，測試一個模塊時，需要設計.

54.軟件配置管理，簡稱SCM,它用于整個軟件工程過程。其主要目標是：、、

、O

55.SCM是一組管理整個軟件生存期各階段中的活動。

56.基線的作用是把各階段的開發工作劃分得更加明確,便于檢查與確認階段成果。因此，基線可以作為項

目的一個。

2。義檔資料內部結構測試用例程序錯誤缺陷3。揚入數據愉出數據4。動態測試靜念測試5。運行程

序測試用例黑盒測試白盒測試6.人工檢測計算機輔助靜態分析7。編碼質量編碼軟件產劉8。靜態分析

特性9.接口需求規格功能10.內部結構處理過程處理過程測試11.結構源程序內部邏輯12.判定語句覆蓋

判定覆蓋條件覆蓋判定/條件潼蓋條件組合覆蓋路徑禱蓋13。條件組合路徑14。循環循環次數15e控

制流程圖環路基本路徑16.功能等價類劃分邊界值分析錯誤推測因果圖17.功能一句話一個短語等價類18.

邊界邊界值第一個最后一個19.錯誤推測法20.因果功能說明判定表判定表21。測試黑盒白盒22。軟件

配置測試配置測試工具23.單元測試集成測試確認測試系統測試24?單元測試編碼詳細設計25.模塊模

塊接口局部數據結構市要的執行路徑錯誤處理邊界條件26。驅動樁驅動模塊樁模塊27。單元組裝聯合

28。非漸增式測試漸增式測試29。自頂向下結合自底向上結合30。驅動樁頂層軟件結構圖深度優先策

略寬度優先策略31o樁驅動32.功能性能需求規格有效性33.黑盒專門測試人員用戶34.測試測試分析

實際運用35。完整性正確性36。糾錯原因位置

37.簡單調試歸納法調試演繹法調試回溯法調試38.程序產生錯誤的地方測試結果發現的線索39.靜態

40.盡可能多的41.一個42.驅動模塊與樁模塊43.漸增式和非浙增式44.發現錯誤45.動態測試年?黑

盒法47.判定覆蓋48.循環次數49.兩個不合理的等價類50.錯誤推測法51.漸增式和非漸增式測試方

法52.進行確認測試和軟件配置審查53.驅動模塊和樁模塊54.標識變更控制變更確保變更匚確地

實現報告有關變更55.變更56.檢查點

1.程序設計語言的特性主要有心理特性、工程特性和技術特性三個方面.

2.程序語言的工程特性主要&現為可移植性、開發工具的可利注性、軟件的可重用性和可維護性。

3.為了提高程序的易讀性，同時為減少錯誤，提高軟件開發效率，編碼時應注意養成良好的程序設計風格。

4.程序加注釋對理解程序提仗了明確指導，根據作用不同注釋分序言性注釋和功能性注釋。

5.軟件需求分析之后,軟件的設計、編碼、測試與語言的特性有很大的關系，這個特性主要是語言的技術

特性。

6.語句構造的原則是簡單直接,不能為了追求效率而使代碼復雜化.

7.FORTRAN語言上世界上第一個被正式推廣應用的計算機運言,它不僅面向科學計算，數據處理能力

也極強。

8.匯編語言是面向機器的,可以完成恁級語言無法滿足要求的冬殊功能，如與外部設備之間的一些接口操

作.

9.為了使數據定義更容易理解和維護，一個語句說明多個變量時，備變量名按

字典排列.

10.里嶼是將詳細設計得到的處理過程的描述轉換為基于某種計算機語言的程序.

1.軟件原來沒有幫助信息，使用不方便,現在要增加幫助信息.這種維護性活動稱之為完善性維護.

2.調試也稱糾借,是在成功的測試之后才開始進行，其目的是確定錯誤的原因和位置,并改正錯誤，

3.調試技術包括簡單調試、歸納法調試、演繹法調試和回溯法調試。

4.回溯法調試是從程序產生錯誤的地方出發,而歸納法調試是從測試結果發現的線索入手。

簡答題

1簡述1983年IEEE為軟件下的定義.5822926

計算機程序、方法、規則、相關的文檔資料以及在計算機上運行程序時所必需的數據.

2簡述軟件危機的表現有哪些？以及解決軟件危機的途徑有哪些？

軟件危機的主要表現包括：

(1)軟件開發進度難以預測,開發成本難以控制，導致超預算、超時；

(2)產品功能難以滿足用戶需求；

(3)軟件產品質量無法保證；

(4)軟件缺少適當的文檔資料，維護困難；

(5)軟件成本超過硬件成本；

(6)軟件開發生產率的提高速度跟不上”?算機應用普及深入的趨勢；

解決軟件危機的途徑有：

1管理措施：項目管理、配置管理、過程管理、質量控制

2技術措施:開發過程、開發技術與方法和開發工具

3軟件工程的定義

1993年IEEE給出的定義：軟件工程是：

①系統的、規范的、可度量的途徑應用于軟件開發、運行和維護過程，也就是把匚程應用于?軟件：

②研究①中提到的途徑。”

軟件工程是圍繞軟件開發的一門交叉學科：軟件工程=計算機科學+工程學+管理學

4軟件工程的10個知識領域

軟件工程過程(SoftwareEngineeringProcess)

軟件工程工具和方法(SoftwareEngineeringToolsandMethods)

軟件需求(SoftwareRequirement)1

軟件設計(SoftwareDesign)

軟件構造(SoftwareConstruction)

軟件測試(SoftwareTesting)

軟件維護(SoftwareMaintenance)

軟件配置管理<Softwareigurationmanagement)

軟件工程管理(SoftwareEngineeringmanagement)

軟件質量(SoftwareQuality)

5軟件工程的目標是什么，軟件工程的三要素都是什么？

軟件工程的目標：軟件工程必須以有組織的質量保證為基礎，進行全面質量管理，不斷地過程改進使軟件

工程方法走向成熟。

軟件工程的三要素包括：過程、方法和工具

過程為及時合理地開發出滿足用戶需求的計算機軟件而進行?系列有組織的活動。過程定義r技術方法的

采用、工程產品(包括模型、文檔、數據、報告、表格等)的產生、里程碑的建立、質量的保證和變更的管

理.

方法為軟件開發提供“如何做”的技術,它涵蓋了項目計劃、需求分析、系統設計、程序實現、測試與維護

等一系列的開發活動如何來做。開發方法經歷了從面向結構、面向對象、面向組件到面向服務的發展工程。

工具為過程和方法提供自動的或半自動的支持。這些軟件工具被集成起來，建立起一個支持軟件開發的系

統,稱之為計算機輔助軟件工程(CASE,ComputerAidedSoftwareEngineering)o

6軟件工程的七條基本原理

美國著名的軟件工程專家巴利?玻姆(Bar"Boehm)提出了軟件工程的七條基本原理：

1.用分階段的生命周期計劃嚴格管理：

2.堅持進行階段評審：

3.實行嚴格的產品控制；

4.采納現代程序設計技犬；

5.結果應能清楚地審查：

6.開發小組的人員應少而精；

7.承認不斷改進軟件工程實踐的必要性.

7簡述軟件過程的定義，軟件過程又可以分為那幾個類型？

軟件過程(SoftwareProcedure)是為獲得軟件產品，在軟件工具支持卜由軟件工程師完成的一系列軟件工

程活動.

軟件過程可概括為基本過程、支持過程和組織過程等三種類型。

其中，基本過程包括：獲取過程、供應過程、開發過程、運作過程和維護過程。支持過程包括：義檔編制過

程、配置管理過程、質量保證過程、驗證過程、確認過程、聯合評審過程和問題解決過程等過程。組織過

程包括：管理過程、基礎設施過程、改進過程和培訓過程。

8里程碑(MileStone)思想

階段工作的目標進行總結、評審、調整和部署卜一個里程碑。目的：合理分配，細化管理“粒度”，降低項

目風險。

9基線思想

基線是指一個(或一組)配置頊在項目生命周期的不同時間點的一種狀態，各階段有各階段的基線：需求基

線、設計基線、測試基線等.基線一旦建立后變化需要受控制。

10簡述軟件生存周期的概念，說明軟件生存周期劃分為那幾個主要時期？每個時期有包括哪些主要階

段？

軟件生存周期是指軟件產品從定義到開發、使用和維護,直到最終被棄用的時期，稱為生存周期。

生存周期的可劃分為計劃時期、開發時期和運行時期等三個主要時期。

其中計劃時期包括問題定義和可行性研究兩個階段.開發時期包括需求分析、總體設計、詳細設計和實現等

四個階段。運行時期的乂稱為運行和維護階段。

11簡述教材中介紹了那些軟件開發模型?這些模型各有什么特點？

教材中重點介紹了瀑布、原型、增量、螺旋四個傳統模型和RUP、XP兩個現代模型.

其中，瀑布模型嚴格按照生存周期開發軟件，每個階段必須完成規定的、完整、準確的合格文檔，前?階段

的輸出文檔就是后一階段的愉入文檔。

其主要特點包括：①活動間具有順序性和依賴性：②推遲實現的觀點：③質量保證的觀點；

快速原型模型法是開發人員在一個基本的需求的基礎上快速開發出一個軟件原型，然后由用戶使用和評價

原型、開發人員根據用戶意見再修改原型，然后再使用評價再修改、直至將原型進化為最終產品.

快速原型模型的特點包括：①做出系統原型，及早向用戶展示系統要實現的界面及功能，增強用戶的合作

信心；②直觀化的表達，容易交流，消除理解上的岐義：③修改集中在前期的原型確認上，較大程度減

少后期實施中的返工.④入手快,加快開發進度；

增量模型是一種演化模型，先完成一個系統子集的開發，再按同樣的開發步驟增加子集，如此遞增卜.去直至

滿足全部系統需求.每個增量可按快速原型法進行.

增量模型的特點包括：①無紀等待獲取完整需求就可入手，盡快見到成果，增強雙方信心：②分步開發,

降低復雜性和難度，減少技術風險，并可并行開發：③邊開發邊投入，可及早發現問題，減少投資風險；

④各個子集是逐漸并入已有的系統中，加入子集不能破壞已構造好的部分，這需要軟件具備開放式的體系

結構；⑤適用于需求不完整的軟件開發，指的是需求逐漸摸清、逐步完善，并非隨意改變，需求改變過大會

導致整體性失控。后面要介紹的XP(極限編程)屬于該模型。

螺旋模型(Spiralmodel)是一種融合了瀑布模型、快速原型模型和增量模型的演進模型，并引入風險分

析機制。適合大型復雜的系統開發。

螺旋模型特點包括：①多種模型結合的一種演進模型，融合了瀑布模型、快速原型和增量模型的所有特點，

融進了循環往發、迭代演進的思想；②增加風險分析，一旦風險成立，原方案應終止、修訂，力求風險可

控③客戶始終參與每個階段的開發，每個階段的成果需客戶確認，避免錯誤的枳累.

統一過程RIP(RationalUnifiedProcess)是由Rational公司在推出統一建模語言UML后，推出的一

個軟件開發框架RUP,稱為軟件統一開發過程。

12統一過程RUP定義了那幾個主要階段？

?初始階段(Inception)：主要完成商業需求，確定項目邊界。里程碑是生命周期目標(Lifecycle

Objective),評價項目基本的生存能力。

?細化階段(Elaboration):主要完成領域問題分析和軟件設計。獲取用戶需求(功能和非功能需求)，

建立需求模型：進一步確立體系結構和設計軟件結構等工作。里程碑是生命周期結構(Lifecycle

Architecture)0

■構造階段(Construction)：主要完成系統實現、測試,里程碑是初始功能(InitialOperational),

產品版本常被稱為“beta”版.

?交付階段(Transition):重點是確保軟件對最終用戶是可用的。里程碑:產品發布(ProductRelease)

13統一過程RUP工作流

6個核心過程工作流(CoreProcessWorkflows)

?商業建模(BusinessModeling)：弄清項目邊界和約束，做出計劃。

?需求(Rcquircmenls):描述系統應做什么，開發人員和用戶達成需求基線.

?分析和設計(Analysis&Design):將需求轉化成計算機可以實現的模型。

?實現(Implementation):用程序設計語言將設計模型狙織成可執行的文件、數據.

?測試(Test)：是發現軟件中的錯誤，在實驗環境下驗證所有的需求是否被正確的實現。

?部署(Deployment):將軟件分發給最終用戶，安裝在真實的環境卜.，由用戶操作運行。

3個核心支持工作流(CoreSupportingWorkflows)是對核心過程工作流的配套支持和管理，保障核心過

程工作流順暢、高效運行。

?配置和變更管理.：工作文檔的管理,在版本更新、需求變更中做到各類文檔及時、同步跟蹤，保

證各文檔內容完整、一致。

?項目管理(ProjectVanagemenl):資源配置、評估監控、風險控制、計劃調整等管理工作，目

的效益最大化。

?環境（Environment）：軟件開發環境，包括人員、設備、過程和工具，以及各種規范、指導手冊

和保障措施.

14簡述rup模型中基線與里程碑的概念，二者之間的關系。

基線，是軟件文檔或源碼（或其它產出物）的一個穩定版本，它是進一步開發的基礎，也可以理解成為一個

階段的起點并已經制定了相應的工作標準，并且只有經過授權后才能變更這個標準。

里程碑，是計劃中確定的階段性工作完成目標，要求提交階段交付物，作為階段評估的標準。

基線和里程牌的關系:基線是為了建立參照點，是階段的起點;里程牌是建立階段性目標，是階段終點，最

后的里程牌可能是一次迭代的終結。

15簡述軟件計劃的目標和主要工作.

軟件計劃的目標：研究項目的可行性，研究合理地運用軟件項目開發所需的資源、經費，掌握開發進度，

控制項目開發過程按此計劃進行.

主要工作包括:確定項目實施范圍、定義遞交的工作成果、評估實施過程中主要的風險、制定項目實施的時

間計劃、成本和預算計劃、人力資源計劃等.

16軟件計劃的活動有哪些？這些活動的內容是什么？

軟件計劃主要活動包括：問題定義，可行性研究，項目計劃。

這些活動的內容是：

問題定義:確定項目實施范圍，回答項目“做什么？”的問題.

可行性研究：項目的必要性和可能性。

制定項目計劃:編制項目開發計劃。

17簡述問題定義的目的和主要任務。

問題定義的目的:弄清要計算機解決的根本問題所在（要解決的何題是什么？），確定新系統的作用域，以

及項目所需的資源、工期和經費。

問題定義的主要任務:編寫項目報告提交審查，作為可行性分析儂依據。

18簡述可行性分析的目的、任務和內容。

可行性分析的目的:確定項目的必要性和可能性。

可行性分析的任務包括：可行性分析；寫可行性研究報告；編制開發計劃。

可行性分析的內容包括：技術、經濟和社會三個方面的可行性：

19簡述需求分析的目的、必要性和參與角色

需求分析的目的是：弄清用戶對系統的細節要求，完整、準確、清晰、具體地問答目標系統“做什么”。準

確地理解用戶提出的軟件功能、性能及其環境的要求.

需求分析的必要性：用戶與開發者的知識領域不同，產生歧義;軟件開發失敗50%是需求不合理，早期錯誤

易放大。

參與角色：開發方包括分析師、設計師和架構師。用戶方包括領域專家、用戶和部門負責人。

20需求開發的任務有哪些？

需求開發的任務包括

需求獲取：收集用戶對目標軟件系統在功能、性能、行為、設計約束等方面的期望。

需求分析：通過符號和文字說明描述系統模型，使用戶和開發者間建立共同語言基礎，消除理解上的歧義的

過程。

需求說明：既編寫需求文檔，也稱編寫需求規格說明書.需求說明書是需求分析階段的最終成果，也是需求

分析階段復審的依據：是用戶領域專家、軟件分析師、軟件設計師共同交流的途徑和媒介；是交付給用戶

文檔的一部份；

需求驗證:即需求評審。根據需求說明書，分析師、設計師、客戶會審文檔，對需求的正確性、一致性、完

整性、無二義行進行評審、確認。

21需求的層次

軟件需求包括三個不同的層次：業務需求、用戶需求、功能需求，也包括非功能需求.

1.業務需求(businessrequirement)

業務需求是反映企業/組織對軟件系統的高層次目標要求，即軟件系統的建設目標.

業務需求通常是“問題定義”或“可行性研究”階段獲取的內容；在需求規格說明書中反映在項目背毋、

系統目標或任務概述的描述中。

獲取的主要對象是客戶方的高管、專家、部門負責人.

2.用戶需求(userrequirement)

用戶需求，用來描述用戶使用產品必須要完成的任務：使用業務領域的術語描述,采用JT?發者與用戶都能

理解的語言和圖形表達。用戶需求是經過調查、歸納后雙方認同的結果。

獲取的主要對象是部門負責人、軟件的操作者或稱終端用戶。

3。功能需求(functionalrequirement)

功能需求定義了開發人員必須實現的軟件功能,結果在需求規格說明書中：功能需求用軟件行業術語表達：

通常是需求建模的結果即目標系統的邏輯模型，如結構化的功能模型、數據模型、行為模型，面向對象的類

模型等。

4。非功能需求

特性是指一些非功能需求，是滿足業務需求的性能要求。如界面的交互性、數據的安全性、數據的事務性、

用戶的并發性、響應的快速性、操作的實時性、錯誤與異常的恢芟性、軟件的容錯性等等。項目的失敗或

拖延一般不是在功能上，而恰恰倒是在性能要求上，因為這些性能與軟件的體系結構有關，與構成系統的網

路與硬件環境等底層技術有關，往往超越一般開發人員的技術能力。

22需求獲取的一般方法

①需求獲取方法以采訪、觀察、座談、對先前的系統版本的測試等。必要時采用快速原型法。

②先集中在使用者對系統的觀點上，以收集用戶原始資料，數據、工作方式、工作流程、使用要求等為

工作起點，深入到部門、車間、班組，做好原始紀錄：

③然后根據對問題及環境的理解與開發經驗，改正用戶需求的模糊、歧義和不一致性要求，排除月戶的

不合理要求，挖掘用戶尚未提出但具有價值的潛在需求，使用戶需求逐步精確化、一致化和完全化；

④需求獲取非一次完成：需要往更進行、逐步深化。

⑤筋求獲取的內容:寫進“希求規格說明書”，確認。

23需求獲取的策略

①循序漸進的策略；

②確定優先級:先進行重點的需求調研,有助于識別出重大的風險，并為制定迭代計劃提供指導：

③不要陷入技術：需求未明確，應回避對技術問題討論。

④挖掘用戶需求：“誘導式”就是挖掘用戶需求。客戶并非IT專業人士，需求的概念是模糊的、籠統的，

而且尺度難以把握,預測潛在需求.

⑤區分不必要的需求：客戶對有些需求提不出來，自然也會提出一些不必要的筋求。

24簡述概要設計和詳細設計的內容.

軟件設計包括概要設計和詳細設計.概要設計又分為體系結構設計和領域問題結構設計。

體系結構設計:是支撐和管理軟件運行的環境設計。由于現代的軟件是處在操作系統、網絡、各種服務器共

同搭建的環境下運行，并且具有并發、安全、事務等多方面的管理，是軟件設計優先考慮的問題。

領域問題結構設計：滿足需求的軟件功能設計,核心所在。將領域問題的分析模型細化成軟件結構模型,也

就是劃分軟件的模塊結構及確定模塊之間的關系。

②詳細設計又分為如下三個部分：

?對模塊內部的過程和數據結構進行設計。也就是對模塊內進行算法分析和程序設計。

?人機交互界面的具體設計，還有與其它外部系統接口設計。

?完成對數據庫的物理設計

概要設計是根據需求確定軟件和數據的總體框架；詳細設計是進一步精化成軟件的算法和數據結構。

25

25簡述衡量軟件模塊獨立性的度量標準有哪些？

模塊獨立性是指模塊能夠完成獨立的功能：模塊符合信息隱藏和信息局部化原則；模塊間關連和依賴程度盡

量小。

衡量軟件模塊獨立性的度量標準的指標有取決于模塊的內部特征的指標內聚度和取決于模塊的外部特征的

指標耦合度。

內策度：一個模塊內部各個元素間(語句和程序段)彼此的紫密程度的度量.

耦合度：指軟件結構中各模塊間相互聯系緊密程度的一種度量。

26簡述內聚度的七個等級？

內聚度表示一個模塊內部各成分之間彼此結合的緊密程度.內聚度按其高低程度可分為七級，高內聚度模塊

獨立性強，設計盡可能提高模塊內聚度。

①偶然性內聚：是指一個模塊內各成分為完成-?組功能而組合在一?起，它們相互之間即使有關系，也

很松散。

②邏輯性內聚：模塊內完成的諸任務邏輯上相關。該類內聚的缺點是執行中要從模塊外引入用作判

斷的開關量，從而增加了塊間偶合(控制偶合)。

③時間性內聚：如果一個模塊包含的諸任務必須在同一時間段內執行，則稱之為時間性內聚

④過程性內聚:模塊的過程性內聚度是指模塊內成份彼此相關，并且必須按特定的次序在木模塊內執

行：

⑤通訊性內聚：是指模塊中各組成成分都將對某個數據結構的同一區域進行操作，以達到通信的目

的。

⑥順序性內聚:一個模塊內的各處理成分均與同一功能相關，且這些處理必須順序執行，通常，一個

處理成分的輸出是另一個處理成分的輸入.

⑦功能性內聚：模塊內所有成分形成一個整體，完成單個功能，則稱功能內聚，功能內聚是最高程度

的內聚形式。

27耦合度的七個等級

耦合度是模塊獨立性最顯著特征。耦合度按其高低程度可分為七級，松耦合是軟件設計一直追求的目標。

①非直接耦合：模塊不依賴另一個模塊能獨立工作，這是最松的耦合。

②數據耦合：兩模塊間通過參數交換數據信息，則稱這兩模塊為數據耦合。

③特征耦合:模塊之間除傳遞關健數據外還附加公共數據。

④控制耦合：如果兩模塊間通過參數交換信息,此時若傳遞的信息中含有控制信息,則為控

制耦合。

⑤外部耦合：當若干模塊均與同一個外部環境關愛，它們之間便存在外部耦合。

⑥公共耦合：當若干模塊通過全局的數據環境相互作用時，它們之間存在公共耦合.

⑦內容耦合：當一個模塊使用另一個模塊內部的數據或控制信息；一個模塊直接轉移到另一

個模塊內部等,模塊間的耦合就是內容耦合.

28簡述模塊的作用域與控制域的概念及其相關設計原則.

模塊的作用域：從功能方面考慮，受模塊內一個判定影響的所有模塊的集合：

模塊的控制域：從結構方面考慮,包括它自己及其所有下屬模塊的集合。

相關設計原則是：模塊的作用域應在控制域之內。

29詳細設計的表達方式有哪些？

1.偽代碼(Pseudocode)：是一種算法描述語言，也稱PDL語言(ProgramDesignLanguage).偽代碼介于自

然語言與編程語言之間，用偽代碼描述的算法可以容易用任何種編程語言實現。偽代碼表達算法必須結

構清晰、代碼簡單、可讀性好。

2.程序流程圖：用圖形符號表達算法，直觀表達循環、分支等復雜結構，是喜聞樂見的表現形式。

3.盒圖(N-S)(NassifflShneiderman)：也是一種圖形符號表達方式，同樣可以表達各種流向控制，但比

程序流程圖緊湊、功能域明確。

4.PAD圖(PAD-ProblemAnalysisDiagram)[28]：同樣是用圖形符號表達算法，但它具有結構化的表達方

式，因此結構十分清晰，很容易翻譯成程序代碼。PAD支持自頂向下，逐步求精方法的使用。判定表與判定

樹：對于規則較多，判定條件較復雜的情況，宜采用這兩種方法表達.

5。判定表與判定樹：對于規則較多，判定條件較復雜的情況，宜采用這兩種方法表達。

30簡述面向數據流的結構化分析SA方法中，有哪些建模方法？

功能建模:數據流圖DFD(DataFlowDiagram)+數據字典DD(DalaDictionary)：

數據建模：實體關系圖ERD(EnlityRelationDiagram);

行為建模:狀態轉換圖STD(StateTransformDiagram)：

加工說明PESPEC(ProcessSPECification)和判定表等輔助工具.

31簡述數據流圖(DFD)的圖形符號有哪些？

①數據流:表示數據流的名稱和數據的流向(從加工出發或流向加工)；

②外部實體：系統外與系統交互的人或實體；

③數據加工:數據處理：

④數據存儲；數據進行持久保存的環節；

32簡述數據字典的作用、內容和組成元素有哪些？

數據流圖描述了數據加工，但沒有描述數據的內容。數據流圖必須與描述并組織數據條目的數據字典

DD(DataDictionary)配套使月。

數據字典描述的對象：描述數據流圖中出現的所有數據和加工.這里的數據描述是概念性的，屬數據結構的

抽象描述；加工采用加工小說明進行概念性的描述。

數據字典的組成元素包括：數據流條目、數據存儲條目、數據項條目：加工條目(也稱為小說明)：

33簡述面向對象的基本概念有哪些？

1.對象與面向對象

對象(Object)：即表示客觀世界中的某個具體的事物。面向對象(ObjectOriented)：是人類的活動，是

人類認知、觀察客觀事物的方法論。

2.面向對象的抽象與分類

3.類的封裝與對象的整體性

4.關聯性與交互性

客觀事物都不是孤立存在的，萬物之間相互依存、相互交流。關聯性表達客觀事物的社會性、共存性、組

織性，是靜態的結構描述。消息機制是對象的交互性，表示對象生存環境的依賴性。

5.繼承性

對事物的分類本身就體現繼承性.軟件開發利用繼承性可對Object更好地分類，軟件結構更嚴謹，代碼的

復用性更強。

6.多態性

對象在不同的條件卜，同樣的行為會表現不同的效果，這就是Object的多態(polymorphism).

面向對象編程語言提供抽象類、接口、重載等技術支持多態的實現.

34面向對象的五大特性有哪些？

面向對象的特性有抽象性、封裝性、繼承性、多態性和消息機制等五大特性。

35簡述面向對象開發過程的內容有哪些？

①需求獲取:開發者以00的觀點(00V)來觀察客觀世界的目標即獲取需求，然后用自然語言寫到需求規格

說明(005)中，也就是對客觀世界的最高層抽象。

②面向對象分析OOA(ObjectOrientedAnalysis)與面向對象設計00D(ObjectOrientedDesign),

③面向對象編程ObjectOrientedProgram(OOP)與面向對象測試ObjectOrientedTesting(00T)是代

碼實現過程，它依賴于?編程語言和工具。

④軟件維護ObjectOrientedSoftwareMaintenance(OOSM).

36與傳統的軟件開發方法相比較，面向對象開發的主要優點有哪些？

1.自然性即客觀性

2.操作數據對象而非數據實體

3.階段銜接平滑

4.結構性好、復用性強

5.提高擴展性和維護性

37簡述UML中定義了那些圖形符號？并簡述起作用。

用例圖(UseCase)描述系統參與者與領域問題的功能

類圖(Class)描述系統的邏輯結構，類、接口及它們的協作關系

包圖(Package)描述類的復用組織一分組

對象圖(Object)描述類的實例在某時刻的關系

構件圖(Component)描述系統按構件組成上的關系

配置圖(Deployment)描述系統運行環境的配置.情況

時序圖(Sequence)描述某些對象共同合作完成某項功能而按時間順序進行的消息傳遞

協作圖(Collaboration)描述某些對象共同合作完成某項功能的依賴關系

活動圖(.Activity)描述杲個用例按事件流轉所經歷的的活動，即業務流程

狀態圖(Statechart)描述某個業務流程按事件流轉所經歷的狀態，即狀態機

38簡述用例圖中有哪些模型元素？并簡述其含義？

①參與者:指存在于系統外部并與該系統發生交互的人或其他系統，代表系統的使用者或使用環境。

②用例(UseCase),用例用于表示系統提供的服務，它定義了系統是如何與參與者交互，描述了參與者與

系統之間的交互過程。

③角色與用例間的關系關聯，它表示參與者與系統中的哪些用例交互。

用例之間的關系：包含((include,、和擴充《(extend〉〉關系以及泛化關系。

參與者之間的泛化關系。

39簡述類圖中有哪些模型元素?并簡述其含義？

提示:一切可以出現在類圖中的元素。

類：

類名、屬性、方法(可見性、作用域)

特殊類:接口

類之間的關系的定義、表示和屬性：

關聯、依賴、聚合、組合、泛化、實現.

各種類關系之間的關系。

40簡述包圖中有哪些模型元素？并簡述其含義？

提示:一切可以出現在包圖中的元素。

包和包之間的關系。

41簡述活動圖中有哪些構成元素？并簡述這些元素的含義？

42簡述OOA模型的結構

00A的核心任務是搞清用戶需求，最終要建立起OOA模型。UML的OOA模型由“用例模型”和“概念模型”

兩大部分組成。

①用例模型，是將用自然語言描述的領域問題，轉換成UML語言表達的模型，主要面向用戶，反映用戶需

求.

完整的用例模型由用例圖和業務場景描述兩個部分組成，用例圖表示功能的劃分；

業務場景描述則對每個用例的事件流進行描述；

②概念模型(類模型/結構模型/靜態模型)。

將用例模型映射成類模型：從用例模型中找出類，面向設計人員,

主要工作是：根據用例圖進行類的劃分與封裝：描述類間的靜態關系與結構：用交互圖表達類對象間的消

息傳遞。

43對象間的可訪問性

①屬性可見性：B是A的一個屬性(關聯、聚合)；

②參數可見性：B的對象是A的一個方法的參數；

③局部聲明可見性:B的對象是在A的一個方法中聲明的一個局部變量：

④全局可見性：B的對象在某種程度上全局可見；

44對象持久化對象持久化常用技術

實體類的實例稱為數據對象，對象持久化主要用于數據對象的持久化，簡稱數據持久化。

一個數據對象的持久化就是保存到實體表中的一條記錄，對實體對象的訪問就是操作屬性的值。

對象持久化常用技術

①對象的序列化

指將對象的相關信息(對象序列號、屬性名、屬性值等)轉換為字節流，然后再把字節流寫入數據流。可以

把對象這些信息存循在本地的義件里，也可以把它通過網絡傳輸到遠程。通過對象反序列化，得到原對象完

全相同的副木。

②對象持久化到數據庫中

數據庫可以是對象數據庫或關系數據庫。

③用XML(extensibleMarkupLanguage)存儲。

45"實體模型〃到“關系模型”的OR映射

(1)一個對象類可以映射為一個以上的庫表，當類間有一對多的關系時.，一個表也可以對應多個類。

(2)對象關系(一對一、一對多、多對多)的映射可能有多種情況，但一般映射為一個表或多個表，在表間

定義相應的主鍵PK(Primarykey)和外鍵FK(Foreignkey)建立實體間的關系。

(3)單一繼承的泛化關系可以對超類、子類分別映射表，也可以不定義父類表而讓子類表擁有父類屬性；反

之，也可以不定義子類表而讓父類式擁有全部子類屬性。

(4)對多重繼承的超類和子類分別映射表，對多次多重繼承的泛化關系也映射一個表。

(5)對映射后的庫表進行冗余控制調整，使其達到合理的關系范式。

46軟件測試的定義

軟件測試是為了發現錯誤而運行程序的過程；軟件測試的目的是發現程序中的錯誤，是為了證明程序有錯，

而不是證明程序無錯：測試對象不僅是程序，還應該包括開發過程中產生的所有產品，包括文檔，其目的

是為了盡早地、盡可能多的發現并排除軟件中潛在的錯誤。

47軟件測試的基本原則

①Who來測試？

測試工作應該由獨立的、專業的軟件測試機構來完成，設計人員和程序員要參與測試；對測試結果一定要

有一個確認的過程,一般由角色A測試出來的錯誤，一定要有一個角色B來確認，嚴重的錯誤可以召開評審

會進行討論和分析：

②測試What?

程序員交付的模塊、系統和文檔；

③測試Extent?

設計測試用例.充分覆蓋所有條件或所有語句即可：

④When測試?

盡早和不斷的測試，即將這種“測試”貫穿于軟件開發的各個階段，堅持各個階段的技術評審，以便盡早地

發現和預防錯誤；

⑤How測試？

設計測試用例時不僅要考慮到合法的輸入，還要考慮到不合法的輸入以及各種邊界條件；對發現錯誤較多

的程序模塊，應進行重點測試。

48軟件缺陷，軟件缺陷的屬性：

從產品內部看，缺陷是軟件產品開發或維護過程中存在的錯誤、毛病等各種問題：從產品外部看，缺陷是

系統所需要實現的某種功能的失效或違背。

軟件缺陷的屬性：

缺陷標識、缺陷類型、缺陷嚴重、程度缺陷、優先級、缺陷狀態、缺陷起源、缺陷來源、缺陷根源等。

49簡述測試用例的概念

測試用例(TestCase)是關F具體測試步驟的文檔，以判斷被測軟件的工作是否正常。

內容包括：測試目標、測試環境、輸入數據、測試步驟、預期結果等。從表現形式上看，測試用例可以是純

文本的文檔，也nJ■以是用程序設計語言編寫的一段代碼。

50簡述基本測試方法的分類情況

測試方法分類內容

走查

靜態測試

評審

語句覆蓋語句覆蓋是最簡單、最弱覆蓋。它只覆蓋可執行語句至少執行一次。

判定覆蓋判定覆蓋又叫分支覆蓋，是對每個判定式取真、假各一次，使每個判定的

每個分支都至少執行一次，同時滿足語句覆蓋。

邏條件覆蓋條件覆蓋是把程序中每個判斷的每個條件為真和假各取值一次.條件覆蓋

動白

輯深入到判定中的每個條件，但不一定滿足判定覆蓋的要求.

態念

覆判定/條件覆判定/條件覆蓋能同時滿足判定、條件兩種漫蓋標準的取值.就是使得判定中

測廁

蓋蓋每個條件的所有可能取值至少執行一次，同時每個判定本身所有取值至少

試試

注執行一次.

條件組合覆條件組合覆蓋.是按每個判斷的所有條件取值進行組合。這是5種覆蓋中最

蓋強的范蓋。它不但可覆蓋所有條件，還可覆蓋所有判斷的可取分支。

基本路徑覆蓋法基本路徑測試步驟：

①導出程序流程圖的拓撲結構一流圖（控制流程圖）：

②計算流圖G的環路復雜性V（G）;

③確定只包含獨立路徑的基本路徑集；

④設計測試用例；

等價類劃分法對測試數據進行區間劃分，從這些區間中選取典型值作為用例代表，認為

黑

測試等價類中的一個代表值的結果就等于對該類其它值的測試.

盒

邊界值分析法邊界值分析法就是對輸入或輸出的邊界值進行測試的一種方法.

測

錯誤推測法

試

因果圖法

51簡述軟件測試過程的主要內容。

1.需求與設計評審

2.單元測試（UnitTesting）

3.集成測試

4.功能測試

5.系統測試

6。驗收測試

7.a與B測試

52簡述單元測試（UnitTesting）的主要內容。

單元測試又稱模塊測試，是針對軟件設計的最小單位程序模塊（函數、類等）進行正確性檢驗的測試工作。

單元測試采用黑盒+白盒混合萬式，采用黑盒測試為主為先，白盒測試為輔為后的策略。

1）用黑盒進行模塊接口測試

2）用黑盒進行模塊邊界條件的測試

3）用白盒進行模塊局部數據結構和算法的測試

4）用白盒進行模塊中獨立路徑的測試

5）模塊中各條錯誤處理路徑的測試

53簡述集成測試的主要內容

集成測試也叫組裝測試或聯合測試。

集成測試是在單元測試基礎上，再將單元按照概要設計規格說明的要求組裝成更大的模塊、子系統或系統。

1）非漸增式集成測試

非漸增式集成測試又叫?次性集成測試，就是把所有經過單元測試的模塊按照設計規格說明書?次性組裝

成系統，然后進行統一的測試。

2）漸增式集成測試

漸增式集成測試即把下一個要測試的模塊同已經測試好的模塊結合起來進行測試，測完后，再把下一個應

該測試的模塊結合進來測試.

54。簡述驗收測試的概念

驗收測試是軟件交付之前的最后一個測試操作，驗收測試的目的是確保軟件準備就緒，并且可以讓最終用

戶將其用于執行軟件的既定功能和任務.

55.a與B測試

這兩種測試是針對商用軟件的系統測試。

商用軟件與合同定制式軟件不同，它面向的使用群體數量大、不確定，沒用針對性的驗收用戶。因此在軟件

正式面市之前免費供用戶試用，由用戶在試用中發現問題,這就是3測試。

提供給用戶的B版如果BUG太多，客戶將無法試用和承受，因此首先軟件開發組織內部人員模擬各類用戶

對即將面市軟件產品進行測試，此時稱為。測試。

56簡述軟件維護的概念

軟件維護是在軟件交付使用之后，為了改正錯誤或滿足新的需求而修改軟件的過程。

57軟件維護的分類

糾錯性維護(CorrectiveMaintenance)

糾錯性維護是在軟件交付后，糾正哪些在運行中發現的殘留錯誤,也稱改正性維護。

適應性維護(AdaptiveMaintenance)

為適應軟件運行環境(軟件生態環境)的變化而修改軟件的活動稱為適應性維護。

完善性維護(PerfectiveMaintenance)

根據用戶在軟件使用過程中提出的建設性意見(需求變化)而進行的維護活動稱為改善性維護.

預防性維護(PreventiveMaintenance)

為了進一步改善軟件的可靠性和易維護性，或者為將來的維護奠定更好的基礎而對軟件進行修改.

58簡述軟件維護的副作用及困難有哪些？

1.維護的副作用

維護的副作用就是指由于維護或在維護過程中其他?些不期望的行為引入的錯誤。

引起副作用的維護修改可分三類：代碼副作用；數據副作用；文檔副作用。

2.維護工作面臨的困難

周期長、難度大、費用高.維拉費用高達開發費用的55%-70%,而且逐年上漲.

維護中還可能引入新的潛在錯誤。分析設計的缺欠、非維擴■者開發、現場追蹤等等。

59簡述軟件配置項的概念和內容.

軟件配置項SCI(softwareConfigurationItem)

軟件生存周期各個階段活動的產物經審批后即可稱之為軟件配置項。軟件配置項包括：

與合同、過程、計劃和產品有關的文檔和資料；

源代碼、目標代碼和可執行代碼：

相關產品，包括軟件工具、庫內的可重用軟件、外購軟件及顧客提供的軟件等。

60簡述結構化維護和非結構化軟件維護的概念.

1.非結構化維護是指滿足如下條件的維護

?軟件的配置中只行源代碼.

?由于沒有分析和設計文檔，無法對程序的功能進行反向追蹤，理解別人的代碼是很痛苦的事情。

?由于配置中沒有測試文檔，所以維護后的代碼無法進行回歸測試。因而導致程序的結構化被不斷的破壞，

維護的質量無法得到保證。

2.結構化維護是指滿足如卜.蕓件的維護

?待維護的軟件的配置是完整的。

?用戶提出的維護申請用正向追蹤很容易從分析設計文檔追蹤直至代碼中，從而使維護人員很容易定位代

碼的維護點。所以這種維護不會破壞軟件的結構。

?結構化維護不僅能減少維護的工作量，還能提高維護的質量。

軟件配置文檔的重要性.

1.為什么說軟件測試是軟件開發中不可缺少的重要?環，但不是軟件質量保證的安全網？

2.軟件測試的目的是什么?為什么把軟件測試的目的定義為只是發現錯誤？

3.軟件測試應當遵循什么原則？為什么要遵循這些原則？

4.軟件測試的步驟是什么？這些測試與軟件開發各階段之間的關系？

5.軟件測試的過程是什么？

6.單元測試、集成測試和確認測試各自主要目標是什么？它們之間有什么不同？相互有什么關系？

7.什么是黑盒測試與R盒測試？它們都適應哪些測試？

8.簡述軟件測試與軟件調試的區別.

9.軟件配置管理的任務。

10.試述第三代界面的優點.

11.試述人機界面的設計過程。

lo①軟件測試是軟件開發中不可缺少的重要一環，原因是：

?測試的工作量約占整個項目開發工作量的40%左右，幾乎一半。如果是關系到人的生命安全的軟件,

測試的工作量還要成倍增加。

?軟件測試代表了需求分析、設計、編碼的最終復審。

②軟件測試不是軟件質量保證的安全網，因為軟件測試只能發現錯誤，不能保證沒有錯誤。

2.軟件測試的目的有：

①軟件測試是為了發現錯誤而執行程序的過程。

②一個好的測試用例能夠發現至今尚未發現的錯誤。

③一個成功的測試是發現了至今尚未發現的錯誤。

軟件測試的目標定義為只是發現錯誤，原因是軟件測試可以有兩個目標，一個是預防錯誤，另一個是發

現錯誤.由于軟件開發是人的創造性勞動，人的活動不可能完美無跳，錯誤可能發生在任何一個階段，因此預

防錯誤這一目標幾乎是不可實現的，所以軟件測試的目標定義為只是發現錯誤.

3.軟件測試應當遵循原則如下：

①用例由輸入數據和預期的輸出數據兩部分組成，因為這樣便于對照檢查，做到有的放矢。

②用例不僅選用合理的輸入數據，還要選擇不合理的輸入數據.因為當以特殊方式使用程序時，會突然發現

程序中有許多錯誤,故使用預期的不合理的輸入數據進行程序測試，比用合理的輸入數據收獲要大，從而能

更多地發現錯誤，提高程序可靠性。

③除了檢查程序是否做了它應該做的事，還應該檢查程序是否做了它不應該做的事，因為如果程序做了它不

應該做的事，即使程序能做它應該做的事，程序也是錯誤的。

④應制定測試計劃并嚴格執行,因為這樣可以排除隨意性。

⑤長期保留測試用例，因為測試用例的設計耗費很大的工作量，而修改后的程序可能有新的錯誤，需要進行

回歸測試，故必須將測試用例作為文檔保存，使測試具有可重復性，同時測試用例是將來系統維護測試叮確

認的依據，保存測J試用例也為以后的維護提供方便。

⑥對發現錯誤較多的程序段，應進行更深入的測試，因為發現錯誤較多的程序段，其質量較差，同町在修

改錯誤過程中又容易引入新的錯誤。

⑦程序員避免測試自己設計的程序，因為測試目的是找錯。從心理學角度講，程序員大多對自己的程序存有

偏見，總認為沒有錯誤或錯誤不大，另外程序員對需求規格說明的理解而引入的錯誤則更難發現，應該由別

人或另外的機構來測試會更客觀、更有效。

4.①軟件測試的步驟如圖7-3所示。

1^17-3軟件測試的步驟

②這些測試與軟件開發各階段之間的關系如圖7—2所示。因為系統測試已經超出了軟件工程的范圍，所以

圖7-2中的系統測試不包括在內。

5.軟件測試是一個規則的過程，包括測試設計、測試執行以及測試結果比較等。

①測試設計：根據軟件開發各階段的文檔資料和程序的內部結構，利用各種設計測試用例技術精心設計測

試用例。

②測試執行：利用這些測試用例執行程序，得到測試結果.

③測試結果比較:將預期的結果與實際測試結果進行比較，如果二者不符合，對于出現的錯誤進行糾錯，并修

改相應文檔。修改后的程序還要進行再次測試，直到滿意為止。如果測試發現不了錯誤，可能由于測試配置

考慮不周到，應考慮重新制定測試方案，設計測試用例。

6。單元測試、集成測試和確認測試各自主要目標是：

①單元測試的主要目標是檢查各個模塊是否正確實現規定的功能，從而發現模塊在編碼中或算法中的錯誤.

②集成測試的生要目標是檢查與設計相關的軟件體系結構的有關問題。

③確認測試的主要目標是檢查已實現的軟件是否滿足需求規格說明書中確定的各種需求。

單元測試、集成測試和確認測試之間的不同如下：

①測試內容不同：單元測試集中于單個模塊的功能和結構檢驗，其則試內容主要包括模塊接口、局部數據結

構、重要的執行路徑、錯誤處理和邊界測試：集成測試集中于模塊組合的功能和軟件結構檢驗，其測試內

容主要包括模塊組裝中可能出現的問題，即數據穿過接口可能丟失、一個模塊可能破壞另一個模塊的內容、

子功能組裝可能不等于主功能、全程數據結構問題、誤差累積問題；確認測試集中于論證軟件需求的可追

溯性，主要包括測試軟件功能和性能是否與軟件需求一致、測試軟件配置的所有程序與文檔是否正確完整

而且一致.

②測試的方法不同：單元測試總是使用白盒測試法，為被測模塊沒計驅動模塊和樁模塊：集成測試使用漸

增式測試和非漸增式測試，漸增式測試又有分為自頂向下結合法和自底向上結合法；確認測試總是使用黑

盒測試法。

③發現的錯誤不同：單元測試發現的錯誤主要是在編碼階段產生的錯誤，集成測試發現的錯誤主要是在設

計階段產生的錯誤，確認測試發現的錯誤主要是在需求分析階段產生的錯誤。

④涉及的文檔不同：單元測試涉及編碼和詳細設計文檔，集成測試涉及詳細設計文檔和概要設計文檔，確

認測試涉及軟件需求規格說明出和用戶手冊.

三者相互關系是：單元測試、集成測試和確認測試是順序實現的.首先單元測試對各個模塊進行測試,然后集

成測試以單元測試為基礎,將所有已測模塊按照設計要求組裝成一個完整的系統，對模塊組合的功能和軟件

結構檢驗進行測試，最后確認測試是以集成測試為基礎，測試集成的軟件是否滿足需求規格說明書中確定的

各種需求。

7=①黑盒測試指把測試對象看成一個黑盒子，測試人員完全不考慮程序的內部結構和處理過程，只在軟件的

接口處進行測試，依據需求規格說明書，檢查程序是否滿足功能要求,又稱為功能測試或數據驅動測試，

②白盒測試指把測試對象看成一個打開的盒子，測試人員需了解程序的內部結構和處理過程,以檢查處理過

程的細節為基礎，對程序中盡可能多的邏輯路徑進行測試，檢驗內部控制結構和數據結構是否有錯，實際的

運行狀態與預期的狀態是否一致。

③白盒測試適應的測試有單元測試、邏輯覆蓋（按邏輯覆蓋程度大同，有語句覆蓋、判定覆蓋、條件覆蓋、

判定/條件覆蓋、條件組合覆卷和路徑停蓋循環覆蓋（限制循環次數，存單循環和嵌套循環）和基本路

徑測試。

④黑盒測試適應的測試有:確認測試、等價類劃分、邊界值分析、錯誤推測和因果圖。

8e軟件測試與軟件調試在目的、技術和方法等方面存在很大的區別，主要表現在：

①測試從一個側面證明程序員的失敗,而調試是為了證明程序員的正確.

②測試從已知條件開始，使用預先定義的程序，且有預知的結果，不可預見的只是程序是否通過測試。調試

一般以不可知的內部條件開始，除統計性調試外，結果是不可預見的.

③測試是有計劃的,并要進行測試設計，而調試是不受時間約束的。

④測試姑一個發現錯誤、改正錯誤、重新測試的過程，而調試是一個推理過程。

⑤測試的執行是有規程的，而調試的執行往往要求程序員進行必要的推理及知覺的飛躍。

⑥測試經常由獨立的測試組在不r解軟件設計的前提下完成，而調試必須由r解詳細設計的程序員完成。

⑦大多數測試的執行和設計可由工具支持，而調試時，程序員能利用的工具主要是調試器。

1、程序語言有哪些共同特征？

答：程序語m的共同特征（似為特性更符合題意）是指程序設計語旨的語旨特性，包括心理特性、工程特性

和技術特性三個方面。語言的心理特性對人機通信的質量有主要的影響;語言的工程特性對軟件開發成功一

否有重要的影響,此外，語言的技術特性也會影響軟件設計的質量.

2、在項目開發時選擇程序設計語言通常考慮哪些因素？

答：通常要考慮的因素有:項目的應用領域、軟件開發的方法、軟件執行的環境、算法和數據結構的復雜性

以及軟件開發人員的知識等。

3、第4代語言（4GL）有哪些主要特征？

答：4GL的主要特征是：（1）友好的用戶界面（2）兼有過程性和非過程性雙重特性（3）高效的程序代碼（4）

完備的數據庫（5）應用程序生成器

4、舉例說明各種程序設計語可的特點及適用范圍？

答：以常見的一些編程語言為例：

FORTRAN語言，它不僅面向科學計算，數據處理能力也極強。適用于科學工程計算