【文章內容簡介】 互促進的（A）。A、可理解性和可測試性B、效率和可移植性 C、效率和可修改性 D、效率和結構好22. 軟件維護的困難主要原因是（C）A、費用低 B、人員少 C、開發(fā)方法的缺陷 D、用戶不配合23. 軟件維護費用高的主要原因是（C）。A、人員少B、人員多C、生產率低D、生產率高24. 為了適應軟硬件環(huán)境變化而修改軟件的過程是(C)。A、校正性維護 B、完善性維護 C、適應性維護D、預防性維護25. 可維護性的特性中，相互矛盾的是(B) 26. 各種不同的軟件維護中，以（C）維護所占的維護量最小。A、 糾錯性維護B、代碼維護C、預防性維護D、文檔維護27. 在變更控制中，（B）可以用來確保由不同用戶所執(zhí)行的并發(fā)變更。A．異步控制B．同步控制C．存取控制D．基線控制28. 變更控制是一項最重要的軟件配置任務，其中“檢出”和（A）處理實現(xiàn)了兩個重要的變更控制要素，即存取控制和同步控制。A．登入B．管理C．填寫變更要求D．審查29. 用Gantt圖表示軟件項目進度安排，下列說法中正確的是（B）30. 基線可作為軟件生存期中各開發(fā)階段的一個檢查點。當采用的基線發(fā)生錯誤時，可以返回到最近和最恰當?shù)模–）上二、 簡答題1. 為建立良好的編程風格應遵循什么原則？答：1）節(jié)簡化①不使用不必要的變量和函數(shù)②避免變量重名，變量重名可導致很難被發(fā)現(xiàn)的錯誤。③盡量減小代碼量。④盡量減少代碼的執(zhí)行時間，提高執(zhí)行效率。⑤避免功能冗余的模塊。⑥盡量不使用全局變量。2）模塊化 ①確保物理和邏輯功能密切相關。 ②限定一個模塊完成一個獨立的功能， 提高模塊的內聚度。 ③檢查代碼的重復率，重復多的代碼， 要抽出來作為一個單獨的模塊。3）簡單化 ①采用直接了當?shù)乃惴ǎ苊馐褂眉记? 性高和難懂的代碼。 ②使用簡單的數(shù)據(jù)結構，避免使用多維 數(shù)組、指針和復雜的表。 ③注意對象命名的一致性。 ④以手工的方式簡化算術和邏輯表達式。4）結構化①按標準化的次序說明數(shù)據(jù)；②按字母順序說明對象名③使用讀者明了的結構化程序部件；④采用直截了當?shù)乃惴?；⑤根?jù)應用背景排列程序各個部分；⑥不隨意為效率而犧牲程序的清晰度和可讀性；⑦讓機器多做煩瑣的工作，如重復、庫函數(shù)；⑧用公共函數(shù)調用代替重復出現(xiàn)的表達式；⑨避免循環(huán)、分支的嵌套層數(shù)過高；⑩單入口單出口。5）文檔化（documentation）①有效、適當?shù)厥褂米⑨?。②協(xié)調使用程序塊注釋和程序行注釋。③保持文檔和程序的同步。6）格式化（layout)①始終采用統(tǒng)一縮進規(guī)則；②適當插入括號表明運算次序、排除二義性；③有效地使用空格符以區(qū)別程序的不同意群。2. 什么是軟件測試？答：軟件測試從廣義上講,是指軟件產品生存周期內所有的檢查、評審和確認活動。從狹義上講，軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程?；蛘哒f，軟件測試是根據(jù)軟件開發(fā)各個階段的規(guī)格說明和程序內部結構而精心設計一批測試用例，用這些測試用例運行程序，以發(fā)現(xiàn)程序錯誤的過程。3. 軟件測試的原則是什么？答：軟件測試的原則有：1) 應該把測試貫穿在整個開發(fā)過程之中。事實上，從需求分析階段開始，每個階段結束之前都要進行階段審查，目的是盡早發(fā)現(xiàn)和糾正錯誤。2) 每個測試用例都應該包括測試輸入數(shù)據(jù)和這組數(shù)據(jù)輸入作用下的預期輸出結果。在實際操作中可以列出一張表格，包括每個測試用例的編號、類型、輸入數(shù)據(jù)、預期輸出結果、實際輸出結果、出錯原因分析。3) 要對每個測試結果進行全面檢查，不要漏掉已經(jīng)出現(xiàn)的錯誤跡象。4) 程序員應該盡量避免檢查自己編寫的代碼。測試工作需要嚴格的工作作風，程序員在測試自己編寫的代碼時往往會帶有一些傾向性，使得他們工作中常常出現(xiàn)一些疏漏。而且，程序員對設計規(guī)格說明書的理解錯誤而引入的錯誤更是難于發(fā)現(xiàn)。5) 在設計測試用例時，應該包括有效的、期望的輸入情況，也要包括無效的和不期望的輸入情況。既能夠驗證程序正常運行的合理輸入，也能夠驗證對異常情況處理的不合理輸入數(shù)據(jù)以及臨界數(shù)據(jù)。在測試程序時，人們常常過多地考慮合法的和期望的輸入條件，以檢查程序是否做了它應該做的事情，而忽視了不合法的和預想不到的輸入條件。事實上，用戶在使用系統(tǒng)時，輸入一些錯誤指令和參數(shù)是經(jīng)常發(fā)生的，如果軟件遇到這種情況不能做出適當?shù)姆磻?，給出相應的提示信息，就可能會誤導用戶，甚至造成嚴重損失。6) 軟件中遺留的錯誤數(shù)量與已經(jīng)發(fā)現(xiàn)的錯誤數(shù)量成正比。根據(jù)這個規(guī)律，對測試中發(fā)現(xiàn)錯誤成堆的模塊更要仔細測試。例如，在某個著名的操作系統(tǒng)中，44%的錯誤僅與4%的模塊有關。7) 回歸測試的關聯(lián)性要特別引起注意，修改一個錯誤而引起更多錯誤的現(xiàn)象并不少見。8) 測試程序時不僅要檢查程序是否做了它應該做的事情，還要檢查它是否做了不該做的事情。例如，工資軟件中，軟件只完成在編職工的工資計算和輸出，不在編人員的工資是不進行計算和輸出的。如果軟件將不在編人員的工資信息也輸出顯然是不合適的。9) 嚴格執(zhí)行測試計劃。在測試之前應該有明確的測試計劃，內容包括：要測試的軟件功能和內容、測試用例和預期結果、測試的進度安排、需要的工具和資源、測試控制方式和過程等。10）做好測試記錄，為統(tǒng)計和維護提供基礎數(shù)據(jù)。4. 請說明集成測試、系統(tǒng)測試和驗收測試有什么不同？答：集成測試界于單元測試和系統(tǒng)測試之間，起到“橋梁作用”，一般由開發(fā)小組采用白盒加黑盒的方式來測試，既驗證“設計”，又驗證“需求”。系統(tǒng)測試的粒度最大，一般由獨立測試小組采用黑盒方式來測試，主要測試系統(tǒng)是否符合“需求規(guī)格說明書”。驗收測試與系統(tǒng)測試相似，主要區(qū)別是測試人員不同，驗收測試由用戶執(zhí)行。5. 簡述單元測試的內容。 答：單元測試的內容有1）模塊接口測試：對通過被測模塊的數(shù)據(jù)流進行測試。為此，對模塊接口，包括參數(shù)表、調用子模塊的參數(shù)、全程數(shù)據(jù)、文件輸入/輸出操作都必須檢查。 2）局部數(shù)據(jù)結構測試：設計測試用例檢查數(shù)據(jù)類型說明、初始化、缺省值等方面的問題，還要查清全程數(shù)據(jù)對模塊的影響。 3）路徑測試：選擇適當?shù)臏y試用例，對模塊中重要的執(zhí)行路徑進行測試。對基本執(zhí)行路徑和循環(huán)進行測試可以發(fā)現(xiàn)大量路徑錯誤。4）錯誤處理測試：檢查模塊的錯誤處理功能是否包含有錯誤或缺陷。例如，是否拒絕不合理的輸入。出錯的描述是否難以理解、是否對錯誤定位有誤、是否出錯原因報告有誤、是否對錯誤條件的處理不正確。在對錯誤處理之前錯誤條件是否已經(jīng)引起系統(tǒng)的干預等。5）邊界測試：要特別注意數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值時出錯的可能性。對這些地方要仔細地選擇測試用例，認真加以測試。 5) 此外，如果對模塊運行時間有要求的話，還要專門進行關鍵路徑測試，以確定最壞情況下和平均意義下影響模塊運行時間的因素。這類信息對進行性能評價是十分有用的。6. 什么是白盒測試？它適應哪些測試？答：白盒測試也叫結構測試，測試者需要了解被測程序的內部結構。白盒測試通常根據(jù)覆蓋準則設計測試用例，有語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋和條件組合覆蓋。 白盒測試適用與單元測試、集成測試、系統(tǒng)測試7. 非漸增式測試與漸增式測試有什么區(qū)別？漸增式測試如何組裝模塊？答：1）漸增式可以較早地發(fā)現(xiàn)模塊界面之間的錯誤，非漸增式則要到最后將所有模塊連接起來時才能發(fā)現(xiàn)此類錯誤。 2）非漸增式需要較多的人工 3）漸增式有利于排錯。如果模塊界面間有錯，如果用非漸增式，這類錯誤到最后聯(lián)合測試時才能發(fā)現(xiàn)，此時很難判斷錯誤發(fā)生在哪一部分，但如果用漸增式，這類錯誤就較容易定位，它通常與最新加上去的模塊有關。 4）漸增式比較徹底。 5）漸增式需要較多的機器時間。 6）非漸增式方式，開始時允許幾個測試人員并行工作，對大型系統(tǒng)來說，是很有意義的。8. 采用黑盒技術設計測試用例有哪幾種方法？這些方法各有什么特點？答：黑盒測試設計測試用例的方法有1）等價類劃分法 特點是：a、測試的內容相同 b、一個等價類中的某個測試可以發(fā)現(xiàn)缺陷，那么這個等價類的其他測試也能發(fā)現(xiàn)缺陷 c、一個等價類中的某個測試不能發(fā)現(xiàn)缺陷，那么這個等價類的其它測試也不能發(fā)現(xiàn)缺陷2）邊界值分析法 特點是：用邊界值分析時時常收獲較大，它是在等價類的邊界上選擇測試用例3）錯誤推測法 特點是：沒有確定的步驟，很大程度上是憑借經(jīng)驗進行的 4）因果圖法 特點是：考慮輸入條件間的組合關系；考慮輸出條件對輸入條件的信賴關系；測試用例發(fā)現(xiàn)錯誤的效率高；能查出功能說明中的某些不一致或遺漏9. 白盒測試法有哪些覆蓋標準？試對它們的檢錯能力進行比較。答：白盒測試的覆蓋標準有：語句覆蓋判定覆蓋條件覆蓋判定/條件覆蓋條件組合覆蓋路徑覆蓋 檢錯能力由弱到強10. 根據(jù)下面程序代碼，畫出程序流程圖，然后設計滿足條件/判定覆蓋、條件組合覆蓋的測試用例。BEGIN T:=0 IF ( X=80 AND Y=80 )THEN T:=1ELSE IF ( X=90 AND Y=75 ) THEN T:=2 ENDIF IF (X=75 AND Y=90) THEN T:=3 ENDIFENDIF RETURN 測試用例： 條件/判定覆蓋：1 X=80 Y=80 2 X=90 Y=753 X=50 Y=50條件組合覆蓋：1 X=80 Y=802 X=80 Y=753 X=75 Y=804 X=75 Y=755 X=90 Y=756 X=90 Y=707 X=80 Y=758 X=80 Y=709 X=75 Y=9010 X=75 Y=9011 X=70 Y=9012 X=70 Y=8511. 軟件的可維護性是軟件設計師最關注的性能，談談為了獲得軟件良好的可維護性，在設計時應該注意哪些問題？答：為獲得軟件的良好可維護性，在設計階段應該做一些變更實驗，檢查系統(tǒng)的可維護性、靈活性和可移植性，設計時應該將今后可能變更的內容與其他部分分離開來，并且遵循高內聚、低偶合的原則。12. 在軟件文檔中，你認為哪些文檔對于軟件的維護最重要？需求分析文檔、設計文檔、程序文檔對軟件維護很重要13. 軟件維護時的源程序修改策略是什么？答：軟件維護時的源程序修改策略是：由于軟件維護最終落實在修改源程序和文檔上。為了正確、有效地修改源程序，通常要先分析和理解源程序，然后才能修改源程序，最后重新測試和驗證源程序。14. 軟件項目計劃包括那些內容？答：軟件項目計劃的內容包括：。對該軟件項目的綜合描述,定義起所要做的工作以及性能限制,它包括:　　(1)項目目標。　　(2)主要功能。　　(3)性能限制?！　?4)系統(tǒng)接口。　　(5)特殊要求?！　?6)開發(fā)概述?！　?1)人員資源?！　?2)硬件資源?！　?3)軟件資源?！　?4)其他。 。進度安排的好壞往往會影響整個項目的按期完成,因此這一環(huán)節(jié)是十分重要的。制定軟件進度與其他工程沒有很大的區(qū)別 ，其方法主要有：　　(1)工程網(wǎng)絡圖?！　?2)Gantt圖。　　(3)任務資源表?！　?4)成本估算。　　(5)培訓計劃。？什么是基線？ 答：配置管理能夠系統(tǒng)地處理變更，從而使得軟件系統(tǒng)可以隨時保持其完整性。配置管理又可成為變更控制，可以用來評估提出的變更請求，跟蹤變更，并保持系統(tǒng)在不同時間的狀態(tài)。軟件配置管理是一套規(guī)范、高效的軟件開發(fā)基礎結構?；€是：已經(jīng)通過正式復審和批準的某規(guī)約或產品，它因此可以作為進一步開發(fā)的基礎，并且只能通過正式的變化控制過程改變。 三、 應用題1. 請讀者參考能夠找到的編程規(guī)范，設計一個C語言編程規(guī)范。答： 文件結構 版權和版本的聲明版權和版本的聲明位于頭文件和定義文件的開頭（參見示例11），主要內容有：（1）版權信息。（2）文件名稱，標識符，摘要。（3）當前版本號，作者/修改者，完成日期。（4）版本歷史信息。/** Copyright (c) 2001,上海貝爾有限公司網(wǎng)絡應用事業(yè)部* All rights reserved.** 文件名稱：* 文件標識：見配置管理計劃書* 摘要：簡要描述本文件的內容** 當前版本：* 作者：輸入作者（或修改者）名字* 完成日期：2001年7月20日** 取代版本：* 原作者：輸入原作者（或修改者）名字* 完成日期：2001年5月10日*/示例11 版權和版本的聲明 頭文件的結構頭文件由三部分內容組成：（1）頭文件開頭處的版權和版本聲明（參見示例11）。（2）預處理塊。（3）函數(shù)和類結構聲明等。假設頭文件名稱為 ，頭文件的結構參見示例12。?? 【規(guī)則121】為了防止頭文件被重復引用，應當用ifndef/define/endif 結構產生預處理塊。?? 【規(guī)則 122】用include 格式來引用標準庫的頭文件（編譯器將從標準庫目錄開始搜索）。?? 【規(guī)則123】用include “” 格式來引用非標準庫的頭文件（編譯器將從用戶的工作目錄開始搜索）。?? 【建議121】頭文件中只存放“聲明”而不存放“定義”?? 【建議122】不提倡使用全局變量，盡量不要在頭文件中出現(xiàn)象extern int value 這類聲明。ifndef GRAPHICS_H // 被重復引用define GRAPHICS_Hinclude // 引用標準庫的頭文件?include “” // 引用非標準庫的頭文件?void Function1(?)。 // 全局函數(shù)聲明