1. 2012年下半年試題（7）
●下列針對某文檔處理軟件的說明中，不適宜作為需求描述的是（7） 。
A.采用基于字符串匹配的快速分詞方法
B.找出文檔的拼寫錯誤并提供替換項(xiàng)列表來替換拼錯的詞
C.找到錯詞并予以高亮度提示，顯示提供替換詞的對話框
D.用戶應(yīng)能有效地糾正文檔中的拼寫錯誤
試題分析：
本題考查軟件需求的特點(diǎn)。
軟件需求說明(Software Requirement Specification,SRS)SRS 應(yīng)該具有以下特性：無歧義性、完整性、可驗(yàn)證性、一致性、可修改性、可追蹤性（向后追蹤、向前追蹤：)、運(yùn)行和維護(hù)階段的可使用性。
《Software Requirements》舉了一個字處理程序的例子來說明需求的這三種不同種類。業(yè)務(wù)需求可能是：“用戶能有效地糾正文檔中的拼寫錯誤”，該產(chǎn)品的包裝盒封面上可能會標(biāo)明這是個滿足業(yè)務(wù)需求的拼寫檢查器。而對應(yīng)的用戶需求可能是“找出文檔中的拼寫錯誤并通過一個提供的替換項(xiàng)列表來供選擇替換拼錯的詞”。同時，該拼寫檢查器還有許多功能需求，如找到并高亮度提示錯詞的操作；顯示提供替換詞的對話框以及實(shí)現(xiàn)整個文檔范圍的替換。
參考答案：A

2. 2012年下半年試題（30）
●一般情況下，（30）屬于軟件項(xiàng)目非功能性需求。
（30）A.操作界面差異性 B.系統(tǒng)配置內(nèi)容 C.系統(tǒng)穩(wěn)定性 D.系統(tǒng)聯(lián)機(jī)幫助
試題分析：根據(jù)GB/T 16260.1產(chǎn)品質(zhì)量中質(zhì)量屬性包括：功能性、可靠性、易用性、效率、可
維護(hù)性和可移植性。
所謂非功能性需求，是指軟件產(chǎn)品為滿足用戶業(yè)務(wù)需求而必須具有且除功能需求以外的特性。
在 IEEE中，軟件需求的定義是：用戶解決問題或達(dá)到目標(biāo)所需的條件或功能。一般包
含業(yè)務(wù)需求、用戶需求、功能需求、行業(yè)隱含需求和一些非功能性需求。業(yè)務(wù)需求反映了客
戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求；功能需求定義了開發(fā)人員必須實(shí)現(xiàn)的軟件功能。所謂非
功能性需求，是指為滿足用戶業(yè)務(wù)需求而必須具有除功能需求以外的特性。包括系統(tǒng)性能、
可靠性、可維護(hù)性、易用性和對技術(shù)和對業(yè)務(wù)適應(yīng)性等。其中最常見的是軟件界面、操作方
便等一系列要求。
參考答案：C

3. 2012年上半年試題（7）
用戶需求在項(xiàng)目開始時定義不清，開發(fā)過程密切依賴用戶的良好配合，動態(tài)響應(yīng)用戶的需求，通過反復(fù)修改來實(shí)現(xiàn)用戶的最終系統(tǒng)需求，這是（7）的主要特點(diǎn)。
（7） A、蒙特卡洛法 B、原型法
C、面向?qū)ο蠓椒?D、頭腦風(fēng)暴法
試題分析：
原型法認(rèn)為在很難一下子全面準(zhǔn)確地提出用戶需求的情況下，首先不要求一定要對系統(tǒng)做全面、詳細(xì)的調(diào)查、分析，而是本著開發(fā)人員對用戶需求的初步理解，先快速開發(fā)一個原型系統(tǒng)，然后通過反復(fù)修改來實(shí)現(xiàn)用戶的最終系統(tǒng)需求。
參考答案：B

4. 2012年上半年試題（10）
軟件需求可理解為：為解決特定問題而由被開發(fā)或被修改的軟件所展示出的特性。所有軟件需求的基本特性是（10）。
（10） A、可驗(yàn)證性 B、與用戶交互性 C、解決沖突 D、面向?qū)ο?
試題分析：
所有軟件需求的一個基本特性就是可驗(yàn)證性。驗(yàn)證某些軟件需求可能很困難或者成本很高。 軟件需求和軟件質(zhì)保人員都必須保證，在現(xiàn)有的資源約束下，需求可以被驗(yàn)證。
參考答案：A

5. 2011年下半年上午題（10）
●以下關(guān)于軟件需求分析的描述中，不正確的是(10)。
A．軟件需求除了所表達(dá)的行為特性外，還具有優(yōu)先級等特性
B．架構(gòu)設(shè)計的工作就是把滿足需求的職貢分配到組件上
C．軟件需求分析的關(guān)鍵是開發(fā)反映真實(shí)世界問題的模型
D．可實(shí)現(xiàn)性是軟件需求的基本特征
試題分析：
所有軟件需求的一個基本特征就是可驗(yàn)證性，驗(yàn)證某些軟件需求可能很困難或者成本很高。
參考答案：D

6. 2011年下半年上午題（11）
●以下關(guān)于軟件質(zhì)量保證和質(zhì)量評價的描述中，不正確的是(11)。
A．軟件質(zhì)量保證過程通過計劃制訂、實(shí)施和完成一組活動提供保證，這些活動保證項(xiàng)目生命周期中的 軟件產(chǎn)品和過程符合其規(guī)定的需求
B．驗(yàn)證和確認(rèn)過程確定某一開發(fā)和維護(hù)活動的產(chǎn)品是否符合活動的需求，最終的產(chǎn)品是否滿足用戶需求
C．檢查的目的是評價軟件產(chǎn)品，以確定其對使用意圖的適合性，目標(biāo)是識別規(guī)范說明與標(biāo)準(zhǔn)的差異， 并向管理提供證據(jù)
D．軟件審計的目的是提供軟件產(chǎn)品和過程對于可應(yīng)用的規(guī)則、標(biāo)準(zhǔn)、指南、計劃和流程的遵從性的獨(dú)立評價
分析
驗(yàn)證的過程試圖去日報活動的輸出產(chǎn)品已經(jīng)被正確制造，既活動的輸出產(chǎn)品滿足前面活動施加的說明，確認(rèn)過程則試圖確保建造了正確的產(chǎn)品，既產(chǎn)品滿足其特征的目的。
參考答案：C

7. 2011年上半年上午題（6）
●模糊測試（Fuzztesting）是一種通過向目標(biāo)系統(tǒng)提供非預(yù)期的輸入并監(jiān)視異常結(jié)果來發(fā)現(xiàn)軟件漏洞的方法，是用于系統(tǒng)安全漏洞發(fā)掘的重要技術(shù)。模糊測試的測試用例通常是 (6)。
A．預(yù)定數(shù)量的字符串
B．預(yù)定長度的字符串
C．模糊集的隸屬度
D．隨機(jī)數(shù)據(jù)
試題分析：根據(jù)題中對模糊測試的定義，“模糊測試（Fuzztesting）是一種通過向目標(biāo)系統(tǒng)提供非預(yù)期的輸入并監(jiān)視異常結(jié)果來發(fā)現(xiàn)軟件漏洞的方法”，其輸入是“非預(yù)期的”，因此測試用例是“隨機(jī)數(shù)據(jù)”。應(yīng)選擇D。
參考答案：D

8. 2011年上半年上午題（7）
●軟件設(shè)計包括軟件架構(gòu)設(shè)計和軟件詳細(xì)設(shè)計。架構(gòu)設(shè)計屬于高層設(shè)計，主要描述軟件的結(jié)構(gòu)和組織，標(biāo)識各種不同的組件。由此可知，在信息系統(tǒng)開發(fā)中， (7)屬于軟件架構(gòu)設(shè)計師要完成的主要任務(wù)之一。
A．軟件復(fù)用
B．模式設(shè)計
C．需求獲取
D．需求分配
試題分析：軟件架構(gòu)設(shè)計師需要參與項(xiàng)目開發(fā)的全過程，包括需求分析、架構(gòu)設(shè)計、系統(tǒng)實(shí)現(xiàn)、集成、測試和部署各個階段，其負(fù)責(zé)在整個項(xiàng)目中對技術(shù)活動和技術(shù)說明進(jìn)行指導(dǎo)和協(xié)調(diào)。架構(gòu)師主要職責(zé)有4個：確認(rèn)需求、系統(tǒng)分解、技術(shù)選型、制定技術(shù)規(guī)格說明。
對于選項(xiàng)A軟件復(fù)用，是軟件程序員的工作職責(zé)；B選項(xiàng)模式設(shè)計為系統(tǒng)分析師的工作職責(zé)；C選項(xiàng)需求獲取為項(xiàng)目經(jīng)理組織需求調(diào)研小組進(jìn)行的工作。
參考答案：D

9. 2011年上半年上午題（8）
●下列測試方法中， (8) 均屬于白盒測試的方法。
A．語句覆蓋法和邊界值分析法
B．條件覆蓋法和基本路徑測試法
C．邊界值分析法和代碼檢查法
D．等價類劃分和錯誤推測法
試題分析：白盒測試又稱結(jié)構(gòu)測試或邏輯驅(qū)動測試，需要考慮到模塊間的邏輯結(jié)構(gòu)。按照程序內(nèi)部的結(jié)構(gòu)測試程序，通過測試來檢測產(chǎn)品內(nèi)部動作是否按照設(shè)計規(guī)格說明書的規(guī)定正常進(jìn)行，檢驗(yàn)程序中的每條通路是否都能按預(yù)定要求正確工作。
白盒測試包含語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。應(yīng)選擇B。
參考答案：B

10. 2009年上半年信息系統(tǒng)監(jiān)理師上午題（27）
● 為了滿足用戶提出的增加新功能、修改現(xiàn)有功能以及一般性的改進(jìn)要求和建議，需要對軟件進(jìn)行（27）。
（27）A．完善性維護(hù) B．適應(yīng)性維護(hù) C．預(yù)防性維護(hù) D．改正性維護(hù)
試題分析：改正性維護(hù)：為了識別和糾正軟件錯誤、改正軟件性能上的缺陷、排除實(shí)施中的錯誤，應(yīng)當(dāng)進(jìn)行的診斷和改正錯誤的過程叫做改正性維護(hù)。
適應(yīng)性維護(hù)：在使用過程中，外部環(huán)境（新的硬件軟件配置）、數(shù)據(jù)環(huán)境（數(shù)據(jù)庫、數(shù)據(jù)格式、數(shù)據(jù)輸入/輸出方式、數(shù)據(jù)存儲介質(zhì)）可能發(fā)生變化。為使軟件適應(yīng)這種變化，而進(jìn)行的軟件修改過程叫做適應(yīng)性維護(hù)。
完善性維護(hù)：在軟件的使用過程中，用戶往往會對軟件提出新的功能、性能要求。為了滿足這種要求而進(jìn)行的軟件功能擴(kuò)充、增強(qiáng)性能的維護(hù)過程叫做完善性維護(hù)。
預(yù)防性維護(hù)：為了提高軟件的可維護(hù)性、可靠性等，為以后進(jìn)一步改進(jìn)軟件打下良好的基礎(chǔ)。即把今天的方法學(xué)用于昨天的系統(tǒng)以滿足明天的需要。
參考答案：（27）A

11. 2011年上半年上午題（10）
●為了改進(jìn)應(yīng)用軟件的可靠性和可維護(hù)性，并適應(yīng)未來軟硬件環(huán)境的變化，應(yīng)主動增加新的功能以使應(yīng)用系統(tǒng)適應(yīng)各類變化而不被淘汰。為了適應(yīng)未來網(wǎng)絡(luò)帶寬的需要，在滿足現(xiàn)有帶寬需求下，修改網(wǎng)絡(luò)軟件從而使之支持更大的帶寬，這種軟件維護(hù)工作屬于__(10)__。
A．更正性維護(hù)
B．適應(yīng)性維護(hù)
C．完善性維護(hù)
D．預(yù)防性維護(hù)
試題分析：本題同上，也是考察各類維護(hù)的內(nèi)容。
參考答案：D

12. 2011年上半年上午題（11）
●軟件開發(fā)項(xiàng)目規(guī)模度量(sizemeasurement)是估算軟件項(xiàng)目工作量、編制成本預(yù)算、策劃合理項(xiàng)目進(jìn)度的基礎(chǔ)。在下列方法中， (11) 可用于軟件的規(guī)模估算，幫助軟件開發(fā)團(tuán)隊(duì)把握開發(fā)時間、費(fèi)用分布等。
A．德爾菲法
B．V模型方法
C．原型法
D．用例設(shè)計
試題分析：
德爾菲法預(yù)測的實(shí)質(zhì)就是利用專家的主觀判斷，通過信息溝通與不斷反饋的過程，使預(yù)測意見逐步趨于一致，接近實(shí)際值。德爾菲法的特點(diǎn)是：匿名性、反饋性、預(yù)測結(jié)果的統(tǒng)計特性。德爾菲法既可以用于短期市場預(yù)測，也可以用于長期市場預(yù)測。其預(yù)測步驟為：①擬定意見征詢表；②選定征詢對象；③反復(fù)征詢專家意見；④作出預(yù)測結(jié)論。
參考答案：A

13. 2011年上半年上午題（12）
●在信息系統(tǒng)集成項(xiàng)目中，經(jīng)常使用 (12) 對集成的系統(tǒng)進(jìn)行性能測試。
A．Bugzilla
B．TestManager
C．TrueCoverage
D．LoadRunner
試題分析：LoadRunner，是一種預(yù)測系統(tǒng)行為和性能的負(fù)載測試工具。通過以模擬上千萬用戶實(shí)施并發(fā)負(fù)載及實(shí)時性能監(jiān)測的方式來確認(rèn)和查找問題，LoadRunner能夠?qū)φ麄€企業(yè)架構(gòu)進(jìn)行測試。通過使用 LoadRunner，企業(yè)能最大限度地縮短測試時間，優(yōu)化性能和加速應(yīng)用系統(tǒng)的發(fā)布周期。 LoadRunner是一種適用于各種體系架構(gòu)的自動負(fù)載測試工具，它能預(yù)測系統(tǒng)行為并優(yōu)化系統(tǒng)性能。
參考答案：D

14. 2010年下半年上午題（17）
● “容器是一個構(gòu)件，構(gòu)件不一定是容器；一個容器可以包含一個或多個構(gòu)件，一個構(gòu)件只能包含在一個容器中”。根據(jù)上述描述，如果用UML 類圖對容器和構(gòu)件之間的關(guān)系進(jìn)行面向?qū)ο蠓治龊徒?，則容器類和構(gòu)件類之間存在（17）關(guān)系。
① 繼承 ②擴(kuò)展 ③聚集 ④ 包含
（17）A．① ② B．② ④ C．① ④ D．① ③
試題分析：
該題的選項(xiàng)是D 。“容器是一個構(gòu)件”暗示容器類和構(gòu)件類之間存在“① 繼承（也叫類屬Generalization）”關(guān)系，“一個容器可以包含一個或多個構(gòu)件”暗示容器類和構(gòu)件類之間存在“③聚集（Aggregation）”關(guān)系。
參考答案：D

15. 2010年下半年上午題（18）
● 面向?qū)ο蠓治雠c設(shè)計技術(shù)中，（18）是類的一個實(shí)例。
（18）A．對象 B．接口 C．構(gòu)件 D．設(shè)計模式
試題分析
對象是由數(shù)據(jù)及其操作構(gòu)成的封裝體，是系統(tǒng)中用來描述客觀事物的一個封裝，是構(gòu)成系統(tǒng)的基本單位。類是現(xiàn)實(shí)世界中實(shí)體的形式化描述，類將該實(shí)體的數(shù)據(jù)和函數(shù)封裝在一起。接口是對操作規(guī)范的說明。模式是一條由三部分組成的規(guī)則，它表示了一個特定環(huán)境、一個問題和一個解決方案之間的關(guān)系。類和對象的關(guān)系可以總結(jié)為：
每一個對象都是某一個類的實(shí)例；
每一個類在某一時刻都有零個或更多的實(shí)例；
類是靜態(tài)的，對象是動態(tài)的；
類是生成對象的模板。
由此可知，對象是類的一個實(shí)例，因此應(yīng)選A。
參考答案： A。

16. 2010年下半年（7）
● 在軟件需求規(guī)格說明書中，有一個需求項(xiàng)的描述為：“探針應(yīng)以最快的速度響應(yīng)氣壓值的變化”。該需求項(xiàng)存在的主要問題是不具有（7）。
A．可驗(yàn)證性 B．可信性 C．兼容性 D．一致性
試題分析：軟件需求是一個為解決特定問題而必須由被開發(fā)或被修改的軟件展示的特性。所有軟件需求的一個基本特性就是可驗(yàn)證性。軟件需求和軟件質(zhì)保人員都必須保證，在現(xiàn)有資源約束下，需求可以被驗(yàn)證。
在需求項(xiàng)“探針應(yīng)以最快的速度響應(yīng)氣壓值的變化”中，沒有定量的闡述探針響應(yīng)氣壓值變化的速度，在現(xiàn)有資源約束下不具有可驗(yàn)證性。因此應(yīng)選A.
參考答案：A

17. 2010年下半年（8）
● UML中的用例和用例圖的主要用途是描述系統(tǒng)的（8）。
A．功能需求 B．詳細(xì)設(shè)計
C．體系結(jié)構(gòu) D．內(nèi)部接口
試題分析：
UML(Unified Modeling Language，統(tǒng)一建模語言)，是用來對軟件密集系統(tǒng)進(jìn)行可視化建模的一種語言。UML的重要性內(nèi)容可以由5類圖（共9種圖形）來定義，其中的第一類是比例圖，從用戶角度描述系統(tǒng)功能，并指出各功能的操作者。
因此，用例圖描述的是系統(tǒng)的功能，即功能需求，所以應(yīng)選A.
參考答案：A

18. 2010年下半年（10）
● 某程序由相互關(guān)聯(lián)的模塊組成，測試人員按照測試需求對該程序進(jìn)行了測試。出于修復(fù)缺陷的目的，程序中的某個舊模塊被變更為一個新模塊。關(guān)于后續(xù)測試，（10）是不正確的。
A．測試人員必須設(shè)計新的測試用例集，用來測試新模塊
B．測試人員必須設(shè)計新的測試用例集，用來測試模塊的變更對程序其它部分的影響
C．測試人員必須運(yùn)行模塊變更前原有測試用例集中仍能運(yùn)行的所有測試用例，用來測試程序中沒有受到變更影響的部分
D．測試人員必須從模塊變更前的原有測試用例集中排除所有不再適用的測試用例，增加新設(shè)計的測試用例，構(gòu)成模塊變更后程序的測試用例集
試題分析：
回歸測試是指修改了舊代碼后，重新進(jìn)行測試以確認(rèn)修改沒有引入新的錯誤或?qū)е缕渌a產(chǎn)生錯誤。在給定的預(yù)算和進(jìn)度下，盡可能有效率地進(jìn)行回歸測試，需要對測試用例庫進(jìn)行維護(hù)并依據(jù)一定的策略選擇相應(yīng)的回歸測試包。對測試用例庫的維護(hù)通常包括刪除過時的測試用例、改進(jìn)不受控制的測試用例、刪除冗余的測試用例、增添新的測試用例等。在軟件生命周期中，即使一個得到良好維護(hù)測試用例庫也可能變得相當(dāng)大，這使每次回歸測試都重新運(yùn)行完整的測試包變得不切實(shí)際，時間和成本約束可能阻礙運(yùn)行這樣一個測試，又是測試組不得不選擇一個縮減的回歸測試包來完成回歸測試。
上述回歸測試的基本概念說明，修改了舊代碼之后所進(jìn)行的回歸測試不一定要重新運(yùn)行原有測試用例集中仍能運(yùn)行的所有測試用例，可以在其中選擇一個縮減的回歸測試包來完成回歸測試，因此選項(xiàng)D的說法是不正確的，應(yīng)選擇D.
參考答案：D

19. 2010年下半年（11）
● 在幾種不同類型的軟件維護(hù)中，通常情況下（11）所占的工作量最大。
A．更正性維護(hù) B．適應(yīng)性維護(hù) C．完善性維護(hù) D．預(yù)防性維護(hù)
試題分析：
可以將軟件維護(hù)定義為需要提供軟件支持的全部活動。軟件維護(hù)包括如下類型。
•更正性維護(hù)：軟件產(chǎn)品交付后進(jìn)行的修改，已更正發(fā)現(xiàn)的問題。
•適應(yīng)性維護(hù)：軟件產(chǎn)品交付后進(jìn)行的修改，以保持軟件產(chǎn)品能在變化后或變化中的環(huán)境中可以繼續(xù)使用。
•完善性維護(hù)：軟件產(chǎn)品交付后進(jìn)行的修改，以改進(jìn)性能和可維護(hù)性
•預(yù)防性維護(hù)：軟件產(chǎn)品交付后進(jìn)行的修改。
軟件的維護(hù)活動可以分為改正性維護(hù)、適應(yīng)性維護(hù)、完善性維護(hù)和預(yù)防性維護(hù)四類，其中完善性維護(hù)是軟件維護(hù)工作的主要部分。
其中，完善性維護(hù)是軟件維護(hù)的主要類型。根據(jù)對軟件開發(fā)機(jī)構(gòu)調(diào)查的結(jié)果，各類維護(hù)活動所占比重最大的是完善性維護(hù)。因此，應(yīng)選C.
參考答案：C

20. 2010年下半年（17）
● “容器是一個構(gòu)件，構(gòu)件不一定是容器；一個容器可以包含一個或多個構(gòu)件，一個構(gòu)件只能包含在一個容器中”。根據(jù)上述描述，如果用UML 類圖對容器和構(gòu)件之間的關(guān)系進(jìn)行面向?qū)ο蠓治龊徒?，則容器類和構(gòu)件類之間存在（17）關(guān)系。
① 繼承 ②擴(kuò)展 ③聚集 ④ 包含
A．① ② B．② ④
C．① ④ D．① ③
分析
該題的選項(xiàng)是D 。“容器是一個構(gòu)件”暗示容器類和構(gòu)件類之間存在“① 繼承（也叫類屬Generalization）”關(guān)系，“一個容器可以包含一個或多個構(gòu)件”暗示容器類和構(gòu)件類之間存在“③聚集（Aggregation）”關(guān)系。
參考答案：D

21. 2010年下半年（18）
● 面向?qū)ο蠓治雠c設(shè)計技術(shù)中，（18）是類的一個實(shí)例。
A．對象 B．接口
C．構(gòu)件 D．設(shè)計模式
試題分析：對象是由數(shù)據(jù)及其操作構(gòu)成的封裝體，是系統(tǒng)中用來描述客觀事物的一個封裝，是構(gòu)成系統(tǒng)的基本單位。類是現(xiàn)實(shí)世界中實(shí)體的形式化描述，類將該實(shí)體的數(shù)據(jù)和函數(shù)封裝在一起。接口是對操作規(guī)范的說明。模式是一條由三部分組成的規(guī)則，它表示了一個特定環(huán)境、一個問題和一個解決方案之間的關(guān)系。類和對象的關(guān)系可以總結(jié)為：
每一個對象都是某一個類的實(shí)例；
每一個類在某一時刻都有零個或更多的實(shí)例；
類是靜態(tài)的，對象是動態(tài)的；
類是生成對象的模板。
由此可知，對象是類的一個實(shí)例，因此應(yīng)選A。
參考答案： A

22. 2010年上半年上午題（9）
● 以下關(guān)于軟件測試的描述，（9）是正確的。
A．系統(tǒng)測試應(yīng)盡可能在實(shí)際運(yùn)行使用環(huán)境下進(jìn)行
B．軟件測試是在編碼階段完成之后進(jìn)行的一項(xiàng)活動
C．專業(yè)測試人員通常采用白盒測試法檢查程序的功能是否符合用戶需求
D．軟件測試工作的好壞，取決于測試發(fā)現(xiàn)錯誤的數(shù)量
試題分析：軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程，是根據(jù)程序開發(fā)階段的規(guī)格說明及程序內(nèi)部結(jié)構(gòu)和精心設(shè)計的一批測試用例（輸入數(shù)據(jù)及其預(yù)期結(jié)果的集合），并利用這些測試用例去運(yùn)行程序，以發(fā)現(xiàn)程序錯誤的過程。故軟件測試應(yīng)盡可能在實(shí)際運(yùn)行使用環(huán)境下進(jìn)行。
軟件測試不再只是一種僅在編碼階段完成后才開始的活動，而是應(yīng)該包括在整個開發(fā)和維護(hù)過程中的活動，它本身也是實(shí)際產(chǎn)品構(gòu)造的一個組成部分。
基于計算機(jī)的測試可以分為白盒測試和黑盒測試。黑盒測試指根據(jù)軟件產(chǎn)品的功能設(shè)計規(guī)格，在計算機(jī)上進(jìn)行測試，以證實(shí)每個已經(jīng)實(shí)現(xiàn)的功能是否符合要求。白盒測試指根據(jù)軟件產(chǎn)品的內(nèi)部工作工程，在計算機(jī)上進(jìn)行測試，以證實(shí)每種內(nèi)部操作是否符合設(shè)計要求，素有內(nèi)部成分是否已經(jīng)過檢查。故專業(yè)測試人員通常采用黑盒測試檢查程序的功能是否符合用戶需求。
對軟件測試進(jìn)行設(shè)計的目的是想以最少的時間和人力系統(tǒng)的找出軟件中潛在的各種錯誤和缺陷。如果成功的實(shí)施了測試，就能夠發(fā)現(xiàn)軟件中的錯誤。測試的附帶收獲是它能偶證明軟件的功能和性能與需求說明相符。軟件測試工作的好壞，并不取決于測試發(fā)現(xiàn)錯誤的數(shù)量。因此，系統(tǒng)測試應(yīng)盡可能在實(shí)際運(yùn)行使用環(huán)境下進(jìn)行。應(yīng)選擇A。
參考答案：A

23. 2010年下半年（10）
● 軟件的質(zhì)量是指（10）。
A. 軟件的功能性、可靠性、易用性、效率、可維護(hù)性、可移植性
B. 軟件的功能和性能
C. 用戶需求的滿意度
D. 軟件特性的總和，以及滿足規(guī)定和潛在用戶需求的能力
試題分析：軟件“產(chǎn)品評價”國際標(biāo)準(zhǔn)ISO14598和國家標(biāo)準(zhǔn)GB/T16260—1—2006《軟件工程產(chǎn)品質(zhì)量-質(zhì)量模型》給出的“軟件質(zhì)量”的定義是：軟件特性的總和，軟件滿足規(guī)定或潛在用戶需求的能力。其中定義的軟件質(zhì)量包括“內(nèi)部質(zhì)量”、“外部質(zhì)量”和“使用質(zhì)量”三部分。也就是說，“軟件滿足規(guī)定或潛在用戶需求的能力”要從軟件在內(nèi)部、外部和使用中的表現(xiàn)來衡量。軟件質(zhì)量特性是軟件質(zhì)量的構(gòu)成因素，是軟件產(chǎn)品內(nèi)在的或固有的屬性，包括軟件的功能性、可靠性、易用性、效率、可維護(hù)性和可移植性等，每一個軟件質(zhì)量特性又由若干個軟件質(zhì)量子特性組成。
由此可見，軟件質(zhì)量不是某個或幾個軟件質(zhì)量特性或子特性，如功能和性能，也不是用戶需求的滿意程度，而是軟件特性的總和，是軟件滿足規(guī)定或潛在用戶的能力。應(yīng)選擇D。
參考答案：D

24. 2010年下半年（11）
● 在軟件生存周期中，將某種形式表示的軟件轉(zhuǎn)換成更高抽象形式表示的軟件的活動屬于（11）。
A. 逆向工程 B. 代碼重構(gòu)
C. 程序結(jié)構(gòu)重構(gòu) D. 數(shù)據(jù)結(jié)構(gòu)重構(gòu)
試題分析：逆向工程（reverse engineering）有的人也叫反求工程，其大意是根據(jù)已有的東西和結(jié)果，通過分析來推導(dǎo)出具體的實(shí)現(xiàn)方法。
軟件逆向工程的基本原理是抽取軟件系統(tǒng)的主要部分而隱藏細(xì)節(jié)，然后使用抽取出的實(shí)體在高層上描述軟件系統(tǒng)。逆向工程抽取的實(shí)體應(yīng)比源代碼更容易推理和接近應(yīng)用領(lǐng)域，同時在高層上對軟件系統(tǒng)的抽象表示要求簡潔和易于理解。在軟件工程領(lǐng)域，迄今為止沒有統(tǒng)一的逆向工程定義。較為通用的是Elliot Chikafsky和Cross在文獻(xiàn)中定義的逆向工程的相關(guān)術(shù)語。
正向工程：從高層抽象和獨(dú)立于實(shí)現(xiàn)的邏輯設(shè)計到一個系統(tǒng)的物理實(shí)現(xiàn)的傳統(tǒng)開發(fā)過程。
逆向工程：分析目標(biāo)系統(tǒng)，認(rèn)定系統(tǒng)的構(gòu)建及其交互關(guān)系，并且通過高層抽象或其他形式來展現(xiàn)目標(biāo)系統(tǒng)的過程。
與逆向工程相關(guān)的其他術(shù)語包括：
再文檔（Redocumentation）:根據(jù)源代碼，在同一層次上創(chuàng)建或修改系統(tǒng)文檔。
設(shè)計恢復(fù)（Design Recovery）:結(jié)合目標(biāo)系統(tǒng)、領(lǐng)域知識和外部信息認(rèn)定更高層次的抽象。
重構(gòu)（Restructuring）:保持系統(tǒng)外部行為（功能和語義），在同一抽象層次上改變表示形式。
再工程（Reengineering）：結(jié)合逆向工程、重構(gòu)和正向工程對現(xiàn)有系統(tǒng)進(jìn)行審查和改造，將其重組為一種新形式。
體系結(jié)構(gòu)再現(xiàn)：用于從源碼、性能分析信息、設(shè)計文檔及專家知識等現(xiàn)有信息中抽象出一個更高層次表示的技術(shù)和過程。
其中，再文檔、設(shè)計恢復(fù)不改變系統(tǒng)。重構(gòu)改變了系統(tǒng)，但不改變其功能。再工程通常涉及逆向工程與正向工程的聯(lián)合使用，逆向工程解決程序的理解問題，正向工程檢驗(yàn)?zāi)男┕δ苄枰Ａ?、刪除或增加。再工程改變了系統(tǒng)的功能和方向，是最根本和最有深遠(yuǎn)影響的擴(kuò)展。
由此可見，重構(gòu)是指在同一抽象層次上改變系統(tǒng)的表示形式，將某種形式表示的軟件轉(zhuǎn)換成更高抽象形式表示的軟件的活動部屬于重構(gòu)，而屬于軟件的逆向工程。應(yīng)選擇A。
參考答案：A

25. 2009年上半年試題（6）
● （6）的目的是評價項(xiàng)目產(chǎn)品，以確定其對使用意圖的適合性，表明產(chǎn)品是否滿足規(guī)范說明并遵從標(biāo)準(zhǔn)。
A. IT審計 B. 技術(shù)評審 C. 管理評審 D.走查
試題分析：
在GB/T14394計算機(jī)軟件可靠性和可維護(hù)性管理標(biāo)準(zhǔn)中，詳細(xì)設(shè)計評審的內(nèi)容分別為：
各單元可靠性和可維護(hù)性目標(biāo)；
可靠性和可維護(hù)性設(shè)計（如容錯）；
測試文件；
軟件開發(fā)工具。
而測試原理、要求、文件和工具不是計算機(jī)軟件可靠性和可維護(hù)性管理標(biāo)準(zhǔn)中詳細(xì)設(shè)計評審的內(nèi)容。
參考答案：D

26. 2009年上半年試題（7）
●按照規(guī)范的文檔管理機(jī)制，程序流程圖必須在（7）兩個階段內(nèi)完成。
A. 需求分析、概要設(shè)計 B. 概要設(shè)計、詳細(xì)設(shè)計
C. 詳細(xì)設(shè)計、實(shí)現(xiàn)階段 D. 實(shí)現(xiàn)階段、測試階段
試題分析：程序流程圖是詳細(xì)設(shè)計說明書用來表示程序中的操作順序的圖形，根據(jù)國標(biāo)《計算機(jī)軟件產(chǎn)品開發(fā)文件編制指南》（GB8567 - 1988）規(guī)定，詳細(xì)設(shè)計說明書應(yīng)在設(shè)計階段（包括概要設(shè)計、詳細(xì)設(shè)計）完成。
參考答案：B

27. 2009年上半年試題（8）
●信息系統(tǒng)的軟件需求說明書是需求分析階段最后的成果之一，（8）不是軟件需求說明書應(yīng)包含的內(nèi)容。
A. 數(shù)據(jù)描述 B. 功能描述 C. 系統(tǒng)結(jié)構(gòu)描述 D. 性能描述
試題分析：軟件需求分析與定義過程了解客戶需要和用戶的業(yè)務(wù)，為客戶、用戶和開發(fā)者之間建立一個對于待開發(fā)的軟件產(chǎn)品的共同理解，并把軟件需求分析結(jié)果寫到《軟件需求說明書》中。需求分析的任務(wù)是準(zhǔn)確地定義未來系統(tǒng)的目標(biāo)，確定為了滿足用戶的需求待建系統(tǒng)必須做什么，即what to do?，并用需求規(guī)格說明書以規(guī)范的形式準(zhǔn)確地表達(dá)用戶的需求。
讓用戶和開發(fā)者共同明確待建的是一個什么樣的系統(tǒng)，關(guān)注待建的系統(tǒng)要做什么、應(yīng)具備什么功能和性能。
一個典型的、傳統(tǒng)的結(jié)構(gòu)化的需求分析過程形成的軟件需求說明書包括如下內(nèi)容：
1 前言
目的
范圍
定義、縮寫詞、略語
參考資料
2 軟件項(xiàng)目概述
軟件項(xiàng)目概述
軟件產(chǎn)品功能概述
2.1 用戶特點(diǎn)
2.2 一般約束
2.3 假設(shè)和依據(jù)
3 具體需求
3.1 功能需求
3.2 外部接口需求
3.3性能需求
3.4設(shè)計約束
3.5屬性
3.6 其他需求
3.6.1 數(shù)據(jù)庫
3.6.2 操作
3.6.3 場合適應(yīng)性
使用面向?qū)ο蟮姆治龇椒ǖ玫降能浖枨笳f明書內(nèi)容如下：
（1） 引言
（2） 信息描述
（3） 類、對象、類圖、對象圖、用例概覽
（4） 功能描述及用例模型
（5） 行為描述及對象行為模型
（6） 質(zhì)量保證
（7） 接口描述
（8） 其他描述
而對系統(tǒng)結(jié)構(gòu)描述則屬于系統(tǒng)分析的任務(wù)。
參考答案：C

28. 2009年上半年試題（9）
●在GB/T14393計算機(jī)軟件可靠性和可維護(hù)性管理標(biāo)準(zhǔn)中，（9）不是詳細(xì)設(shè)計評審的內(nèi)容。
A. 各單元可靠性和可維護(hù)性目標(biāo) B. 可靠性和可維護(hù)性設(shè)計
C. 測試文件、軟件開發(fā)工具 D. 測試原理、要求、文件和工具
試題分析：在GB/T14394計算機(jī)軟件可靠性和可維護(hù)性管理標(biāo)準(zhǔn)中，詳細(xì)設(shè)計評審的內(nèi)容分別為：
各單元可靠性和可維護(hù)性目標(biāo)；
可靠性和可維護(hù)性設(shè)計（如容錯）；
測試文件；
軟件開發(fā)工具。
而測試原理、要求、文件和工具不是計算機(jī)軟件可靠性和可維護(hù)性管理標(biāo)準(zhǔn)中詳細(xì)設(shè)計評審的內(nèi)容。
參考答案：D

29. 2009年上半年試題（11）
●UML 2.0支持13種圖，它們可以分成兩大類：結(jié)構(gòu)圖和行為圖。（11）說法不正確。
A. 部署圖是行為圖 B. 順序圖是行為圖
C. 用例圖是行為圖 D. 構(gòu)件圖是結(jié)構(gòu)圖
試題分析：UML2.0支持13種圖，它們可以分成兩大類：結(jié)構(gòu)圖和行為圖。結(jié)構(gòu)圖包括類圖、組合結(jié)構(gòu)圖、構(gòu)件圖、部署圖、對象圖和包圖；行為圖包括活動圖、交互圖、用例圖和狀態(tài)機(jī)圖，其中交互圖是順序圖、通信圖、交互概覽圖和時序圖的統(tǒng)稱。
參考答案：A

30. 2009年下半年試題
●常用的信息系統(tǒng)開發(fā)方法中，不包括 （9） 。
A．結(jié)構(gòu)化方法 B．關(guān)系方法 C．原型法 D．面向?qū)ο蠓椒?
試題分析：本題考查信息系統(tǒng)的開發(fā)方法。
《系統(tǒng)集成項(xiàng)目管理工程師教程》的“3.2.2信息系統(tǒng)開發(fā)方法”節(jié)中指出：目前常用的開發(fā)方法有結(jié)構(gòu)化方法、原型法和面向?qū)ο蠓ā?
參考答案：B

31. 2009年下半年試題（11）
●在軟件生命周期中，能準(zhǔn)確地確定軟件系統(tǒng)必須做什么和必須具備哪些功能的階段是 （11） 。
（11）A．概要設(shè)計 B．詳細(xì)設(shè)計 C．可行性分析 D．需求分析
試題分析：本題考查軟件工程中軟件各個生命周期的作用。
軟件生命周期可分為可行性分析、需求分析、概要設(shè)計、詳細(xì)設(shè)計、編碼和單元測試、綜合測試、軟件維護(hù)等階段。其中在需求分析階段要確定為解決該問題，目標(biāo)系統(tǒng)要具備哪些功能；可行性分析階段要確定問題有無可行的解決方案，是否值得解決；概要設(shè)計階段制定出實(shí)現(xiàn)該系統(tǒng)的詳細(xì)計劃；詳細(xì)設(shè)計階段就是把問題的求解具體化，設(shè)計出程序的詳細(xì)規(guī)格說明。
參考答案：D