【文章內(nèi)容簡介】 訂 書 單填 寫 是 否 正 確是 否 有 班 主 任 簽 名填 寫 領(lǐng) 書 單班 主 任 簽 名領(lǐng) 書 單返 回 給 班 長領(lǐng) 書修 改檢 查 庫 存登 記 圖 書 信 息提 交 采 購 部 使用順序圖描述下面的情景，當(dāng)用戶在自己的計(jì)算機(jī)上向網(wǎng)絡(luò)打印機(jī)發(fā)出一個(gè)打印任務(wù)時(shí)，他的計(jì)算機(jī)便向打印機(jī)服務(wù)器發(fā)送一條打印命令 print(file)，打印機(jī)服務(wù)器如果發(fā)現(xiàn)網(wǎng)絡(luò)打印機(jī)處于空閑 狀態(tài)，則向打印機(jī)發(fā)送打印命令 print(file)，否則向打印隊(duì)列發(fā)送一條保存命令 store(file)。 解：計(jì) 算 機(jī) 打 印 服 務(wù) 器 打 印 機(jī) 隊(duì) 列P r i n t ( )（ 空 閑 ） 打 印（ 忙 ） 存 儲(chǔ) 隊(duì) 列打 印打 印 結(jié) 束打 印 結(jié) 束 某報(bào)社采用面向?qū)ο蠹夹g(shù)實(shí)現(xiàn)報(bào)刊征訂的計(jì)算機(jī)管理系統(tǒng)，該系統(tǒng)基本需求如下： （ 1）報(bào)社發(fā)行多種刊物，每種刊物通過訂單來征訂，訂單中有代碼，名稱，訂期，單價(jià)，份數(shù)等項(xiàng)目，訂戶通過填寫訂單來訂閱報(bào)刊。 （ 2）報(bào)社下屬多個(gè)發(fā)行站，每個(gè)站負(fù)責(zé)收集登陸訂單、打印收款憑證等事務(wù)。 （ 3）報(bào)社負(fù)責(zé)分類并統(tǒng)計(jì)各個(gè)發(fā)行站送來的報(bào)刊 訂閱信息。 請(qǐng)就此需求建立對(duì)象模型。 解：11n11n nn書 號(hào)書 名定 價(jià): :書 刊 信 息書 刊 代 碼訂 期名 稱單 價(jià)份 數(shù): :訂 單 信 息n打 印 收 款 憑 據(jù) ( )+接 受 訂 單( )+: :發(fā) 行 站1+分 類 統(tǒng) 計(jì) 訂 單 信 息 ( ): :出 版 社客 戶 名 稱客 戶 地 址客 戶 電 話: :客 戶 信 息1 軟件工程作業(yè) 3 一、 選擇題 1. 結(jié)構(gòu)化語言是介于自然語言和形式語言之間的一種 （ D）。 A．半形式語言 B． 計(jì)算機(jī)語言 C． 低級(jí) 語言 D．高級(jí)語言 2. 程序設(shè)計(jì)語言的技術(shù)特性不應(yīng)包括（ C）。 A、數(shù)據(jù)結(jié)構(gòu)的描述性 B、抽象類型的描述性 C、數(shù)據(jù)庫的易操作性 D、軟件的可移植性 3. 程序的三種基本控制結(jié)構(gòu)是（ B） 。 A．過程、子程序和分程序 B．順序、選擇和重復(fù) C．遞歸、堆棧和隊(duì)列 D．調(diào)用、返回和轉(zhuǎn)移 4. 結(jié)構(gòu)化程序設(shè)計(jì)主要強(qiáng)調(diào)的是（ D） 。 A．程序的規(guī)模 B．程序的效率 C．程序設(shè)計(jì)語言的先進(jìn)性 D．程序易讀性 5. 下列關(guān)于功能性注釋不正確的說法是 (B)。 ，用于說明程序段或語句的功能以及數(shù)據(jù)的狀態(tài) ，需要在每一行都要加注釋 ，以便很容易區(qū)分注釋和程序 6. 下列關(guān)于效率的說法不正確的是 (D)。 性能要求，其目標(biāo)應(yīng)該在需求分析時(shí)給出 ，數(shù)據(jù)結(jié)構(gòu)與算法 7. 結(jié)構(gòu)化維護(hù)與非結(jié)構(gòu)化維護(hù)的主要區(qū)別在于 (B )。 8. 關(guān)于 JAVA語言下列說法不正確的是（ B）。 9. 使用白盒測試方法時(shí)，確定測試數(shù)據(jù)應(yīng)根據(jù) （ A） 和指定的覆蓋標(biāo)準(zhǔn)。 A程序內(nèi)部邏輯 B．程序 復(fù)雜結(jié)構(gòu) C．使用說明書 D．程序的功能 10. 確認(rèn)測試主要涉及的文檔是（ A）。 A、需求規(guī)格說明書 B、概要設(shè)計(jì)說明書 C、詳細(xì)設(shè)計(jì)說明書 D、源程序 11. 測試的關(guān)鍵問題是 （ D）。 12. 黑盒測試在設(shè)計(jì)測試用例時(shí)，主要研究 （ A）。 13. 下面哪些測試屬于黑盒測試（ B）。 A、路徑測試 B、等價(jià)類劃分 C、條件判斷 D、循環(huán)測試 14. 在下述哪一種測試中，測試人員必須接觸到源程序（ B）。 A、 功能測試 B、 結(jié)構(gòu)測試 C、 功能測試和結(jié)構(gòu)測試 D、性能測試 15. 檢查軟件產(chǎn)品是否符合需求定義的過程稱為（ D）。 A、確認(rèn)測試 B、集成測試 C、驗(yàn)收測試 D、驗(yàn)證測試 16. 軟件測試方法中，黑盒、白盒測試法是常用的方法，其中白盒測試主要用于測試（ D）。 A、 結(jié)構(gòu)合理性 B、軟件外部功能 C、程序正確性 D、程序內(nèi)部邏輯 17. 軟件維護(hù)中，因修改交互輸入的順序，沒有正確的記錄而引起的錯(cuò)誤是 （ A） 產(chǎn)生的副作用 。 A、文檔 B、數(shù)據(jù) C、編碼 D、設(shè)計(jì) 18. 以下屬于軟件維護(hù)階段文檔的是 (C)。 A、軟件需求說明 B、操作手冊(cè) C、軟件問題報(bào)告 D、測試分析報(bào)告 19. 產(chǎn)生軟件維護(hù)的副作用，是指 （ C）。 A、開發(fā)時(shí)的錯(cuò)誤 B、隱含的錯(cuò)誤 C、因修改軟件而造成的錯(cuò)誤 D、運(yùn)行時(shí)誤操作 20. 維護(hù)中，因誤刪除一個(gè)標(biāo)識(shí)符而引起的 錯(cuò)誤是 （ C） 副作用。 A、文檔 B、數(shù)據(jù) C、編碼 D、設(shè)計(jì) 21. 可維護(hù)性的特性中 ， 相互促進(jìn)的 （ A）。 A、 可理解性和可測試性 B、效率和可移植性 C、效率和可修改性 D、效率和結(jié)構(gòu)好 22. 軟件維護(hù)的困難主要原因是（ C） A、費(fèi)用低 B、人員少 C、開發(fā)方法的缺陷 D、 用戶不配合 23. 軟件維護(hù)費(fèi)用高的主要原因是（ C）。 A、人員少 B、人員多 C、生產(chǎn)率低 D、生產(chǎn)率高 24. 為了適 應(yīng)軟硬件環(huán)境變化而修改軟件的過程是 (C)。 A、校正性維護(hù) B、完善性維護(hù) C、適應(yīng)性維護(hù) D、預(yù)防性維護(hù) 25. 可維護(hù)性的特性中，相互矛盾的是 (B) 26. 各種不同的軟件維護(hù)中 ， 以（ C）維護(hù)所占的維護(hù)量最小。 A、 糾錯(cuò)性維護(hù) B、代碼維護(hù) C、預(yù)防性維護(hù) D、文檔維護(hù) 27. 在變更控制中， （ B） 可以 用來確保由不同用戶所執(zhí)行的并發(fā)變更。 A．異步控制 B．同步控制 C．存取控制 D．基線控制 28. 變更控制是一項(xiàng)最重要的軟件配置任務(wù)，其中 “ 檢出 ” 和 （ A） 處理實(shí)現(xiàn)了兩個(gè)重要的變更控制要素，即存取控制和同步控制。 A．登入 B．管理 C．填寫變更要求 D．審查 29. 用圖表示軟件項(xiàng)目進(jìn)度安排，下列說法中正確的是 （ B） 依賴制約關(guān)系 30. 基線可作為軟件生存期中各開發(fā)階段的一個(gè)檢查點(diǎn)。當(dāng)采用的基線發(fā)生錯(cuò)誤時(shí)，可以返回到最近和最恰當(dāng)?shù)?（ C） 上 二、 簡答題 1. 為建立良好的編程風(fēng)格應(yīng)遵循什么原則？ 答： 1）節(jié)簡化 ①不使用不必要的變量和函數(shù) ②避免變量重名，變量重名可導(dǎo)致很難被發(fā) 現(xiàn)的錯(cuò)誤。 ③盡量減小代碼量。 ④盡量減少代碼的執(zhí)行時(shí)間，提高執(zhí)行效率。 ⑤避免功能冗余的模塊。 ⑥盡量不使用全局變量。 2）模塊化 ①確保物理和邏輯功能密切相關(guān)。 ②限定一個(gè)模塊完成一個(gè)獨(dú)立的功能， 提高模塊的內(nèi)聚度。 ③檢查代碼的重復(fù)率，重復(fù)多的代碼， 要抽出來作為一個(gè)單獨(dú)的模塊。 3）簡單化 ①采用直接了當(dāng)?shù)乃惴?，避免使用技? 性高和難懂的代碼。 ②使用簡單的數(shù)據(jù)結(jié)構(gòu)，避免使用多維 數(shù)組、指針和復(fù)雜的表。 ③注 意對(duì)象命名的一致性。 ④以手工的方式簡化算術(shù)和邏輯表達(dá)式。 4）結(jié)構(gòu)化 ①按標(biāo)準(zhǔn)化的次序說明數(shù)據(jù)； ②按字母順序說明對(duì)象名 ③使用讀者明了的結(jié)構(gòu)化程序部件； ④采用直截了當(dāng)?shù)乃惴ǎ? ⑤根據(jù)應(yīng)用背景排列程序各個(gè)部分； ⑥不隨意為效率而犧牲程序的清晰度和可讀性； ⑦讓機(jī)器多做煩瑣的工作，如重復(fù)、庫函數(shù)； ⑧用公共函數(shù)調(diào)用代替重復(fù)出現(xiàn)的表達(dá)式； ⑨避免循環(huán)、分支的嵌套層數(shù)過高； ⑩單入口單出口。 5）文檔化（ documentation） ①有效、適當(dāng)?shù)厥褂米⑨尅? ②協(xié)調(diào)使用程序塊注釋和程序行注釋。 ③保持文 檔和程序的同步。 6）格式化（ layout) ①始終采用統(tǒng)一縮進(jìn)規(guī)則； ②適當(dāng)插入括號(hào)表明運(yùn)算次序、排除二義性； ③有效地使用空格符以區(qū)別程序的不同意群。 2. 什么是軟件測試？ 軟件測試的原則是什么？ 答：軟件測試從 廣義上講 ,是指軟件產(chǎn)品生存周期內(nèi)所有的檢查、評(píng)審和確認(rèn)活動(dòng)。 從狹義上講，軟件測試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程?；蛘哒f，軟件測試是根據(jù)軟件開發(fā)各個(gè)階段的規(guī)格說明和程序內(nèi)部結(jié)構(gòu)而精心設(shè)計(jì)一批測試用例，用這些測試用例運(yùn)行程序，以發(fā)現(xiàn)程序錯(cuò)誤的過程。 軟件測試的原則有： 1) 應(yīng)該把測試貫穿在整個(gè)開發(fā)過程之中。事 實(shí)上，從需求分析階段開始，每個(gè)階段結(jié)束之前都要進(jìn)行階段審查，目的是盡早發(fā)現(xiàn)和糾正錯(cuò)誤。 2) 每個(gè)測試用例都應(yīng)該包括測試輸入數(shù)據(jù)和這組數(shù)據(jù)輸入作用下的預(yù)期輸出結(jié)果。在實(shí)際操作中可以列出一張表格，包括每個(gè)測試用例的編號(hào)、類型、輸入數(shù)據(jù)、預(yù)期輸出結(jié)果、實(shí)際輸出結(jié)果、出錯(cuò)原因分析。 3) 要對(duì)每個(gè)測試結(jié)果進(jìn)行全面檢查，不要漏掉已經(jīng)出現(xiàn)的錯(cuò)誤跡象。 4) 程序員應(yīng)該盡量避免檢查自己編寫的代碼。測試工作需要嚴(yán)格的工作作風(fēng)，程序員在測試自己編寫的代碼時(shí)往往會(huì)帶有一些傾向性，使得他們工作中常常出現(xiàn)一些疏漏。而且，程序員對(duì)設(shè)計(jì)規(guī)格說明書的理 解錯(cuò)誤而引入的錯(cuò)誤更是難于發(fā)現(xiàn)。 5) 在設(shè)計(jì)測試用例時(shí)，應(yīng)該包括有效的、期望的輸入情況，也要包括無效的和不期望的輸入情況。既能夠驗(yàn)證程序正常運(yùn)行的合理輸入，也能夠驗(yàn)證對(duì)異常情況處理的不合理輸入數(shù)據(jù)以及臨界數(shù)據(jù)。在測試程序時(shí)，人們常常過多地考慮合法的和期望的輸入條件，以檢查程序是否做了它應(yīng)該做的事情，而忽視了不合法的和預(yù)想不到的輸入條件。事實(shí)上，用戶在使用系統(tǒng)時(shí)，輸入一些錯(cuò)誤指令和參數(shù)是經(jīng)常發(fā)生的，如果軟件遇到這種情況不能做出適當(dāng)?shù)姆磻?yīng)，給出相應(yīng)的提示信息，就可能會(huì)誤導(dǎo)用戶，甚至造成嚴(yán)重?fù)p失。 6) 軟件中遺留的錯(cuò)誤數(shù) 量與已經(jīng)發(fā)現(xiàn)的錯(cuò)誤數(shù)量成正比。根據(jù)這個(gè)規(guī)律，對(duì)測試中發(fā)現(xiàn)錯(cuò)誤成堆的模塊更要仔細(xì)測試。例如，在某個(gè)著名的操作系統(tǒng)中， 44%的錯(cuò)誤僅與 4%的模塊有關(guān)。 7) 回歸測試的關(guān)聯(lián)性要 特別 引起注意，修改一個(gè)錯(cuò)誤而引起更多錯(cuò)誤的現(xiàn)象并不少見。 8) 測試程序時(shí)不僅要檢查程序是否做了它應(yīng)該做的事情，還要檢查它是否做了不該做的事情。例如，工資軟件中，軟件只完成在編職工的工資計(jì)算和輸出，不在編人員的工資是不進(jìn)行計(jì)算和輸出的。如果軟件將不在編人員的工資信息也輸出顯然是不合適的。 9) 嚴(yán)格執(zhí)行測試計(jì)劃。在測試之前應(yīng)該有明確的測試計(jì)劃，內(nèi)容包括：要 測試的軟件功能和內(nèi)容、測試用例和預(yù)期結(jié)果、測試的進(jìn)度安排、需要的工具和資源、測試控制方式和過程等。 10）做好測試記錄，為統(tǒng)計(jì)和維護(hù)提供基礎(chǔ)數(shù)據(jù)。 3. 請(qǐng)說明集成測試、系統(tǒng)測試和驗(yàn)收測試有什么不同？ 答：集成測試界于單元測試和系統(tǒng)測試之間，起到“橋梁作用”，一般由開發(fā)小組采用白盒加黑盒的方式來測試，既驗(yàn)證“設(shè)計(jì)”，又驗(yàn)證“需求”。 系統(tǒng)測試的粒度最大，一般由獨(dú)立測試小組采用黑盒方式來測試，主要測試系統(tǒng)是否符合“需求規(guī)格說明書”。 驗(yàn)收測試與系統(tǒng)測試相似，主要區(qū)別是測試人員不同，驗(yàn)收測試由用戶執(zhí)行。 4. 簡述單元測試 的 內(nèi)容。 答：單元測試的內(nèi)容有 1）模塊接口測試：對(duì)通過被測模塊的數(shù)據(jù)流進(jìn)行測試。為此，對(duì)模塊接口，包括參數(shù)表、調(diào)用子模塊的參數(shù)、全程數(shù)據(jù)、文件輸入 /輸出操作都必須檢查。 2）局部數(shù)據(jù)結(jié)構(gòu)測試：設(shè)計(jì)測試用例檢查數(shù)據(jù)類型說明、初始化、缺省值等方面的問題，還要查清全程數(shù)據(jù)對(duì)模塊的影響。 3）路徑測試：選擇適當(dāng)?shù)臏y試用例，對(duì)模塊中重要的執(zhí)行路徑進(jìn)行測試。對(duì)基本執(zhí)行路徑和循環(huán)進(jìn)行測試可以發(fā)現(xiàn)大量路徑錯(cuò)誤。 4）錯(cuò)誤處理測試：檢查模塊的錯(cuò)誤處理功能是否包含有錯(cuò)誤或缺陷。例如，是否拒絕不合理的輸入 。出錯(cuò)的描述 是否難以理解、是否對(duì)錯(cuò)誤定位有誤、是否出錯(cuò)原因報(bào)告有誤、是否對(duì)錯(cuò)誤條件的處理不正確 。在對(duì)錯(cuò)誤處理之前錯(cuò)誤條件是否已經(jīng)引起系統(tǒng)的干預(yù)等。 5）邊界測試：要特別注意數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值時(shí)出錯(cuò)的可能性。對(duì)這些地方要仔細(xì)地選擇測試用例，認(rèn)真加以測試。 5) 此外，如果對(duì)模塊運(yùn)行時(shí)間有要求的話，還要專門進(jìn)行關(guān)鍵路徑測試，以確定最壞情況下和平均意義下影響模塊運(yùn)行時(shí)間的因素。這類信息對(duì)進(jìn)行性能評(píng)價(jià)是十分有用的。 5. 什么是 白盒測試？它適應(yīng)哪些測試？ 答：白盒測試也叫結(jié)構(gòu)測試，測試者需要 了解被測程序的內(nèi)部結(jié)構(gòu)。 白盒測試通常根據(jù)覆蓋準(zhǔn)則設(shè)計(jì)測試用例， 有語句覆蓋、判定覆蓋、條件覆蓋、判定 /條件覆蓋和條件組合覆蓋 。 白盒測試適用與單元測試、集成測試、系統(tǒng)測試 6. 非漸增式測試與漸增式測試有什么區(qū)別？漸增式測試如何組裝模塊？ 答： 1）漸增式可以較早地發(fā)現(xiàn)模塊界面之間的錯(cuò)誤，非漸增式則要到最后將所有模塊連接起來時(shí)才能發(fā)現(xiàn)此類錯(cuò)誤。 2）非漸增式需要較多的人工 3）漸增式有利于排錯(cuò)。如果模塊界面間有錯(cuò)，如果用非漸增式，這類錯(cuò)誤到最后聯(lián)合測試時(shí)才能發(fā)現(xiàn)，此時(shí)很難判斷錯(cuò)誤發(fā)生在哪一部分，但 如果用漸增式，這類錯(cuò)誤就較容易定位，它通常與最新加上去的模塊有關(guān)。 4）漸增式比較徹底。 5）漸增式需要較多的機(jī)器時(shí)間。 6）非漸增式方式，開始時(shí)