軟件測試相關(guān)試題

1、一、選擇題 ( 每題只有一個選項，將你認為合理的選項填在題前括號內(nèi)，每小題 分)(2分，共 16D )1 、較實用的軟件測試停止標準是 ( ) 測試超產(chǎn)過了預定時間，則停止測試。 根據(jù)單位時間內(nèi)查出故障的數(shù)量決定是否停止測試。 執(zhí)行了所有的測試用例，但并沒有發(fā)現(xiàn)故障，則停止測試。 用圖表示出某個測試階段中單位時間檢查出的故障數(shù)量，通過對圖中曲線的分A、B、C、D、析，確定應(yīng)繼續(xù)測試還是停止測試。C )2 、軟件測試的目的是： 表明軟件是正確的 盡可能發(fā)現(xiàn)軟件中的錯誤 ( ) 不是常見的覆蓋率標準。函數(shù)覆蓋B、數(shù)據(jù)流覆蓋A、C、A )3 、A、覆蓋B、評價軟件質(zhì)量D、判定軟件是否合格C、邏輯覆蓋

2、D功能( 試為(B )4 、將基于功能的和基于實現(xiàn)的測試方法結(jié)合在一起的動態(tài)測試類型，我們稱這種測)。A白盒測試 故障的測試B )5 、下列不隸屬于白盒測試方法的是 ( )A控制流測試B、健壯性測試測試)6B、灰盒測試C、黑盒測試C、數(shù)據(jù)流測試D基于D變異)7)8、項目管理三要素不包括 ( ) 。A、 Programming 、下列選項中，不是 Mercury 公司測試工具的是 ( )A、 LoadRunner 、下面(A因果圖B、 ProcessC、 ProblemD、ProcessD)1( 錯誤的主要原因：)2OC、 TestDirector )方法能夠有效地檢測輸入條件的各種組合可能引起

3、的錯誤。B等價類劃分C邊界值分析B、 WinRunnerD、D、Rebot錯誤推測、通常， ( ) 是在編碼階段進行的測試，它是整個測試工作的基礎(chǔ)。 A系統(tǒng)測試、據(jù)權(quán)威部門統(tǒng)計，軟件錯誤產(chǎn)生的原因分布圖表中，如下B 、確認測試C集成測試D、單元測試選項是導致軟件A、軟件需求規(guī)格說明錯誤B 、設(shè)計錯誤C 、編碼錯誤D 、(C )3 、軟件測試充分性理論是由( ) 最先提出的。A、Deutsch 和 WillisB、 McCall et al.C、Goodenough 和 GerhartD、 Evansh 和 Marciniak(C)4 、軟件測試風險管理包含()和風險控制兩方面內(nèi)容。C風險評估測

4、試錯誤)5)6)7A 風險排序B風險識別、下列不屬于黑盒測試方法的是A等價類劃分B狀態(tài)測試、常見的覆蓋率標準不包括 ( ) A函數(shù)覆蓋、因果圖是( A、SUND、風險分析C、C、邊界值分析數(shù)據(jù)流覆蓋D變異測試B邏輯覆蓋)公司最先發(fā)明并實施的。B、 IBMC、 MicrosoftD功能覆蓋D、 ORACLE( D )8 、針對下面一個程序段：, 以達到測試的目的。D代碼審查D復雜性D路徑覆蓋taxrate=0;taxrate=0.05; taxrate=0.08;)。A、 income=(799, 1500, 1999, 2000)C、 income =(800, 1500, 2000, 200

5、1)B、 income=(799, 1501, 2000, 2001)D、income=(800, 1499, 2000, 2001)if (A>1) && (B = 0) S1;If (A = 2)| (X > 1)S2;其中， S1、S2 均為語句塊?，F(xiàn)在選取測試用例：A=2 B=0 X=3 ，該測試用例滿足了( )。A路徑覆蓋B條件組合覆蓋C判定覆蓋D語句覆蓋( A )1 、下列各測試工具中隸屬于 Mercury 公司產(chǎn)品的是( )A、WinRunnerB、 JUnitC、 PurifyD、 WebStress( D )2 、下面關(guān)于軟件測試的說法，其中正確的

6、是 ( )A、經(jīng)過測試沒有發(fā)現(xiàn)錯誤，說明程序正確B、成功的測試是沒有發(fā)現(xiàn)錯誤的測試C、測試的目標是為了證明程序沒有錯誤D成功的測試是發(fā)現(xiàn)了迄今尚未發(fā)現(xiàn)的錯誤的測試(B)3 、在某種類型會議上，由小組成員閱讀程序，以發(fā)現(xiàn)程序錯誤，同時測試員利用測 試數(shù)據(jù)人工運行程序并得出輸出結(jié)果，然后由參加者對結(jié)果進行審查 這種測試方法是( )。A軟件審查B、代碼走查C技術(shù)評審(C)4 、測試充分性準則內(nèi)容不包括 ( )。A空集不充分性B、單調(diào)性C可靠性( A )5 、控制流覆蓋準則約束最弱的是 ( )。A點覆蓋B、邊覆蓋C 條件覆蓋( C )6 、設(shè)計測試用例時候，( )是用得最多的一種黑盒測試方法。A因果圖

7、B、等價類劃分C邊界值分析D錯誤推測( B )7 、軟件測試風險管理包含( )和風險控制兩方面內(nèi)容。A風險識別B風險評估C風險排序D風險分析( A )8 、對下面的計算個人所得稅程序中if (income<800)else if (income<=1500) else if (income<2000) else taxrate=0.1;滿足判定覆蓋的測試用例是 (、判斷題(判斷下列題目是否正確，如果正確請打“V”，錯誤請打“X”每小題2分, 共8分)( V)1 、技術(shù)評審即是一種技術(shù)手段，也是一種質(zhì)量管理手段。( X )2 、設(shè)計實現(xiàn)測試，軟件測試是開發(fā)后期的一個階段。( X

8、 )3 、單元測試僅僅證明了被測程序單元做了什么。( X )4 、由于函數(shù)覆蓋率是基于代碼的，所以也可以把函數(shù)覆蓋歸入黑盒測試的范疇。( V )1 、在軟件測試中 , 測試預言是一種檢驗待測系統(tǒng)在特定執(zhí)行下是否正確運行的方 法。( X )2 、在白盒測試中，如果覆蓋率達到 100% ，就基本可以保證把所有的隱藏程序缺 陷都已經(jīng)揭露出來了。(X )3 、軟件測試的目的在于發(fā)現(xiàn)錯誤、改正錯誤。(V )4、由于函數(shù)覆蓋率是基于代碼的，所以也可以把函數(shù)覆蓋歸入白盒測試的范疇。( X )1 、軟件測試等于程序測試。( X )2 、我是個很棒的程序員， 我無需進行單元測試。( V )3 、在白盒測試中，即

9、使覆蓋率達到 100% ，也無法保證所有的隱藏程序缺陷都已 經(jīng)被揭露出來。( X )4 、由于函數(shù)覆蓋率是基于代碼的，所以也可以把函數(shù)覆蓋歸入黑盒測試的范疇。(X)1、軟件故障是導致軟件失效的必要和充分要素。(V)2、同行評審的主要目標在于檢測錯誤、核對與標準的偏離。(V)3、在任何軟件機構(gòu)中，定期、不定期的培訓、再培訓都是必須而且是必要的。(V)4、在整個機構(gòu)中使用基礎(chǔ)設(shè)施防護與改進部件的主要目標是在機構(gòu)積累的SQA經(jīng)驗基礎(chǔ)上消除或至少降低出錯率。(X )5、所有SQA活動和項目里程碑的完成或項目里程碑的檢驗是同時發(fā)生的。(X )6 、 Daniel Galin 等提在 20 世紀 50 年

10、代建立的經(jīng)典質(zhì)量費用模型，提供了一種以 經(jīng)濟學觀點把與產(chǎn)品質(zhì)量保證相關(guān)的費用非類的方法學。(V )7、一旦更改過的 SCI替換了前面的SCI，就認為完成了軟件的一個新版本。( V )8 、軟件質(zhì)量成本是一個投資問題，而不是成本問題 !(X )9、SEI CMM評估標準，ISO 9001 和ISO 9000-3標準是典型的項目過程標準。( V )10 、軟件質(zhì)量保證的獨特性是由軟件產(chǎn)品不同于其他制造產(chǎn)品的本質(zhì)決定的。(V )1、在專業(yè)的軟件開發(fā)、維護中，SQA環(huán)境是建立、執(zhí)行 SQA方法時必須首要考慮的問題。( X )2 、如何看待軟件產(chǎn)品內(nèi)部的缺陷，開發(fā)者和用戶的立場是一致的。( V )3 、

11、專家觀點通過引進補充的外部能力到機構(gòu)內(nèi)部開發(fā)過程中來而支持質(zhì)量評估工 作。( X )4 、質(zhì)量管理標準是專業(yè)標準，它們向開發(fā)組提供方法學指南。(V )5 、軟件生命周期模型強調(diào)的是直接開發(fā)活動，而沒有指示出開發(fā)過程的顧客參與。( X )6 、規(guī)程具有機構(gòu)范圍的適用性，它的執(zhí)行和具體執(zhí)行的人或組織背景有著密切關(guān) 系。(X )7、CAPA的目的在于檢測、處理、改正軟件缺陷。(X )8、項目進展控制 SQA工具有Gatt圖、日歷、數(shù)據(jù)流圖和活動網(wǎng)絡(luò)圖。(V )9、IEEE、ISO、DOD ANSI、EIA都是著名的 SQA標準開發(fā)機構(gòu)。( V )10 、在科學和工程中， 如果沒有度量，對一切都沒有一

12、個定量的了解，那么這種科 學和工程既不是有效的，也不是實際的。(X )1 、在軟件產(chǎn)品制定生產(chǎn)計劃階段，不必進行重大的SQA活動。( V )2 、軟件故障是導致軟件失效的必要，而非充分要素。( X )3 、只有客戶才會有興趣透徹定義它的需求以確保他約定的軟件產(chǎn)品的質(zhì)量。(V )4、軟件質(zhì)量系統(tǒng)之間各不相同，說明機構(gòu)SQA系統(tǒng)構(gòu)建存在固有靈活性。( V )5 、質(zhì)量管理標準指導軟件開發(fā)、維護和基礎(chǔ)設(shè)施的管理。它的重點是需要什么， 但沒有指明如何達到標準要求的努力細節(jié)。(X )6 、通常，檢查表的使用的是強制性的。(X )7、CAPA的執(zhí)行從根本上依賴于正確的指導和經(jīng)常的培訓。( V )8 、軟件

13、質(zhì)量度量面臨的特有困難根植于包含于軟件質(zhì)量度量的測量(參數(shù))中。(V )9、一旦更改過的 SCI替換了前面的SCI，就認為完成了軟件的一個新版本。（ X ）10、SQA項目過程標準如 CMM ISO 9000-3標準。三、填空題（每空1分，共14分；請把答案書寫在相應(yīng)橫線上。）1、 軟件測試過程包含的測試活動有測試計劃，測試設(shè)計，測試實施，測試執(zhí)行，缺陷跟蹤 和測試評估2、 軟件測試策略的確定過程通常經(jīng)歷 確定測試需求 、 評估風險、確定測試策略三個階段組成。3、 變異測試的理論基礎(chǔ)是 程序員能力假設(shè)和組合效應(yīng)假設(shè)。4、 軟件缺陷打開/關(guān)閉圖表 、根本原因圖表 、軟件缺陷關(guān)閉周期表是常用的軟件

14、缺陷跟蹤圖表。5、 軟件測試規(guī)范可以分為 行業(yè)規(guī)范和操作規(guī)范。1、 通常，由人工進行的靜態(tài)測試方法包括 _桌面檢查_、_代碼審查 _、代碼走查 _和 技術(shù)評審。2、 典型的測試設(shè)計活動包括 _測試用例設(shè)計_、_測試過程設(shè)計_、設(shè)計驅(qū)動程序和穩(wěn)定的樁。3、 按照測試的層次和策略，軟件測試可以分為單元測試、_集成測試_、_確認測試_和_系統(tǒng) 測試_。4、 為了考察測試用例的重要性，我們可以從_有效性_、_可重用性_、_易組織性_、 可評估性_、可管理性五方面理解。5、面向?qū)ο蠹蓽y試常見方法包括 _抽樣測試_、_正交矩陣（陣列）測試 _。1、 面向?qū)ο鬁y試充分性三個常用標準是基于狀態(tài)的覆蓋率_、基

15、于約束的覆蓋率_和基于 代碼的覆蓋率。2、常見的程序分析視角有 句法視角，功能視角、文本視角和計算流視角3、 按照測試用例的設(shè)計方法，軟件測試可以分為白盒測試、黑盒測試和灰盒測試。4、我們可以按照編寫_過程、_執(zhí)行過程和_組織過程三個緯度對測試用例屬性進行 歸類。5、 單元測試內(nèi)容包含如下方面： _模塊接口測試_、_邊界條件測試 _、_錯誤處理測試_、_局 部數(shù)據(jù)結(jié)構(gòu)測試和重要路徑測試。1、軟件質(zhì)量工程包括 _軟件質(zhì)量保證_、_軟件質(zhì)量規(guī)劃_和軟件質(zhì)量控制三大方面。2、 McCall模型產(chǎn)品修改緯度的質(zhì)量因素有 _可維護性_、_可測試性_、靈活性。1.3、面向?qū)ο竽Ｐ筒煌谄渌Ｐ偷闹饕卣魇?/p>

16、_組件的密集重用。4、 有兩種同行評審方法學：_審查_和_走查_。5、 RMA可以劃分成三組類別 內(nèi)部風險管理措施 _、_分包風險管理措施 _和_顧客風 險管理措施_。6、支持性質(zhì)量手段有模板和檢查表_。7、 依據(jù)軟件系統(tǒng)的生命周期和其他階段，軟件質(zhì)量度量劃分為軟件過程度量_和軟件 產(chǎn)品度量_。8、 軟件配置發(fā)布的版本有基線版本、_中間版本、修訂版本。9、 SQA標準被劃分成 軟件質(zhì)量管理標準 _和_軟件項目過程標準兩類。10、 軟件缺陷的固有特征有軟件缺陷的固有性、軟件缺陷的敏感性 _、_軟件缺陷的感染 性_。1、 McCall模型劃分了 _軟件運行_、軟件轉(zhuǎn)移 、軟件修改三個緯度的11個軟

17、件質(zhì)量因素。2、 螺旋模型任何一次迭代都可劃分為制定計劃、_風險分析和化解、工程和顧客評估四個項限。3、 依據(jù)合同評審的目標對合同評審主題進行分類為_建議草案評審主題 _和_合同草案評審 主題_兩種類型。4、 典型的版本方針包括 _嚴格-單一活動版本方針 _、 多版本方針 。2. 5、軟件對屬于各種質(zhì)量因素的需求的符合性是由_軟件質(zhì)量度量 _來測量的。6、 CAPA過程的成功運行包含如下活動：信息收集、_信息分析、解決方案和改進方法的建立、改進方法的執(zhí)行、跟蹤。7、常見的軟件配置演化模型有 _線性演化模型 _和_樹演化模型 _。8、 軟件更改的質(zhì)量保證工作需要 每個更改的SCI的質(zhì)量保證_和_

18、整個新軟件系統(tǒng)版 本的質(zhì)量保證_兩個級別的活動。9、 從內(nèi)容和重點上我們可以把質(zhì)量管理標準劃分成_認證標準 _和評估標準 _兩種類型。10、 _測試人員 、_SQA單位是SQA專職人員。1、 CMM內(nèi)容包含初始級、 可重復級_、_已定義級_、_已管理級_和可優(yōu)化級五個 等級。2、軟件質(zhì)量保證的目標包括 _面向產(chǎn)品的軟件開發(fā) _和_面向過程的軟件維護 _兩大 方面。3、 開發(fā)生命周期階段 SQA部件可以劃分成三類：評審、專家觀點、軟件測試、軟件維護SQA 部件和由第三方/分包商使用的SQA部件。4、 版本方針_和更改方針_是維護方針的主要組成。5、 外部參與方可被分類為 _分包商、COTS軟件和

19、重用軟件模塊的供貨商和 _顧客自身三 組。6、 在任何機構(gòu)中，CAPA要正確發(fā)揮作用需要 CAPA己錄流的跟蹤、CAPA執(zhí)行的跟蹤和CAPA 執(zhí)行結(jié)果的跟蹤三個要的跟蹤任務(wù)。7、 軟件更改的質(zhì)量保證工作需要每個更改的SCI的質(zhì)量保證和_整個新軟件系統(tǒng)版本的質(zhì) 量保證 _兩個級別的活動。&軟件過程度量可以進一步劃分為 軟件過程質(zhì)量度量 _、_軟件過程進度度量和軟件過程生產(chǎn)率度量。9、 從內(nèi)容和重點上我們可以把質(zhì)量管理標準劃分成 認證標準 和評估標準 兩種類型。10、 通常，軟件質(zhì)量的管理部件有 項目進展控制_、軟件質(zhì)量度量、_軟件質(zhì)量費用和可 用于控制軟件維護的工具 SQAW理工具。四、

20、名詞解釋（每小題3分，共18分）1、軟件測試風險軟件測試風險是指軟件測試過程出現(xiàn)的或潛在的問題2、動態(tài)測試技術(shù)通過在抽樣測試數(shù)據(jù)上運行程序來檢驗程序的動態(tài)行為和運行結(jié)果以發(fā)現(xiàn)缺陷。3、確認測試確認測試是驗證軟件的功能和性能及其它特性是否與用戶的要求一致。對軟件的從功能、性能、可靠性、易用性等方面作全面的質(zhì)量檢測，幫助軟件企業(yè)找出產(chǎn)品存在的問題，出具相 應(yīng)的產(chǎn)品質(zhì)量報告。4、條件組合覆蓋條件組合覆蓋是邏輯覆蓋標準的一種，它要求選取足夠多的測試數(shù)據(jù)，使得每個判定表達式中條件的各種可能組合都至少出現(xiàn)一次。5、L10N軟件本地化6、(軟件產(chǎn)品的) FURPSFURPS即軟件系統(tǒng)的功能、可使用性、可靠性

21、、性能和支持等特性。1、L10N && I18N 軟件本地化和國際化2、軟件測試項目管理軟件測試項目管理就是以測試項目為管理對象， 通過一個臨時性的專門的測試組織， 運用專 門的軟件測試知識、技能、工具和方法，對測試項目進行計劃、組織、執(zhí)行和控制，并在時 間成本、軟件測試質(zhì)量等方面進行分析和管理活動。3、軟件測試文檔測試文檔是對要執(zhí)行的軟件測試及測試的結(jié)果進行描述、定義、 規(guī)定和報告的任何書面或圖示信息。4、測試用例測試用例是為了特定目的而設(shè)計的測試數(shù)據(jù)及相關(guān)測試規(guī)程的一個特定集合，即為有效發(fā)現(xiàn)軟件缺陷的最小測試執(zhí)行單元。5、白盒測試白盒測試是指測試人員根據(jù)程序的內(nèi)部結(jié)構(gòu)特性和

22、與程序路徑相關(guān)的數(shù)據(jù)特性，設(shè)計測試數(shù)據(jù)組成測試用例執(zhí)行程序的一種動態(tài)測試。6、無效等價類 無效等價類是指對于程序的規(guī)格說明來說，不合理的，沒有意義的輸入數(shù)據(jù)的集合。1、軟件測試 軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程?；?軟件測試是根據(jù)軟件開發(fā)各階段的規(guī)格說明和程序的內(nèi)部結(jié)構(gòu)而精心設(shè)計的一批測試用例 (即輸入數(shù)據(jù)及其預期的輸出結(jié)果) ，并利用這些測試用例運行程序， 以及發(fā)現(xiàn)錯誤的過程。2、測試用例的有效性軟件測試用例是測試人員測試過程中的重要參考依據(jù)； 不同測試人員根據(jù)相同測試用例所得 到的輸出應(yīng)該是一致的。3、軟件測試規(guī)范軟件測試規(guī)范是對軟件測試流程的過程化， 并對每一個過程元素進行明確界定

23、， 而形成的完 整的規(guī)范體系。4、條件覆蓋條件覆蓋隸屬控制流覆蓋標準的范疇， 它不僅要求每個語句至少執(zhí)行一次， 而且要求使得判 定表達式中每個條件都取得各種可能的結(jié)果5、TDD測試驅(qū)動開發(fā)( Test Driven Development )6、a測試a測試是由用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內(nèi)部的用戶在模擬實際操作環(huán)境下進行的測試。這是在受控制的環(huán)境下進行的測試。1、Crosby 軟件質(zhì)量的定義系統(tǒng)、部件或過程滿足規(guī)定需求的程度。2、軟件可靠性(IEEE)軟件可靠性是指一個系統(tǒng)或組件在某個特定時期、特定條件下完成所需完成的功能的能力。3、規(guī)程 規(guī)程是完成某件事情或行動的特定方式， 即

24、規(guī)程是為了完成一個任務(wù)， 根據(jù)給定方法所 執(zhí)行的詳細活動或過程。4、開發(fā)風險 軟件開發(fā)風險是軟件開發(fā)任務(wù)或環(huán)境的一種狀態(tài)或性質(zhì)， 如果忽略它， 將增加軟件項目 失敗的可能。5、（軟件工程領(lǐng)域）模板 在軟件工程領(lǐng)域，模板指的是小組或機構(gòu)創(chuàng)建的，用于編輯報告以及其他形式文檔的格式。6、軟件配置管理一個負責應(yīng)用 （ 計算機化的或非計算機化的 ）技術(shù)工具和管理規(guī)程、 使之能夠完成為維護 SCI 和軟件配置版本所需任務(wù)的SQA部1、 Daniel Galin軟件質(zhì)量保證的擴展定義軟件質(zhì)量保證是一個有系統(tǒng)的、 有計劃的行動集合， 它是提供軟件產(chǎn)品開發(fā)、 維護過程符合 其已建立的技術(shù)需求以及跟上計劃安排和在

25、預算限制之內(nèi)進行管理上的需求充分信任所必 需的。2、合同評審合同評審是一個指導評審建議草案和合同文檔的SQA部件。3、規(guī)程 規(guī)程是完成某件事情或行動的特定方式， 即規(guī)程是為了完成一個任務(wù)， 根據(jù)給定方法所執(zhí)行 的詳細活動或過4、4W1HW1H即卩WHAT, WHEN, WHERE, WHO HOW他們具體含義如下：WHAT-What activities have to be performed?WHEN-When Should the activity be performed?WHERE-Where should the activity be performed?WHO-Who shou

26、ld perform the activity?HOW-How should each activity be performed?5、受控文檔受控文檔是那些目前就對軟件系統(tǒng)的開發(fā)、 維護以及與目前和將來顧客關(guān)系的管理重要或可 能變得重要的，并且處于控制狀態(tài)下的文檔。6、軟件質(zhì)量度量 一個項目具有給定質(zhì)量屬性的程度定量測度； 或一個函數(shù)， 其輸入為軟件數(shù)據(jù)、 輸出為單一的數(shù)值， 該值可以被理解為軟件具有給定質(zhì)量屬 性的程度1、Pressman 軟件質(zhì)量的定義 軟件質(zhì)量是符合明確陳述的功能性能需求、 明確文檔化了的開發(fā)標準和所有專業(yè)開發(fā)預期的 隱含特性。2、軟件開發(fā)風險 軟件開發(fā)風險是軟件開發(fā)任

27、務(wù)或環(huán)境的一種狀態(tài)或性質(zhì)， 如果忽略它， 將增加軟件項目失敗 的可能。3、合同評審合同評審是一個指導評審建議草案和合同文檔的SQA部件。4、質(zhì)量記錄質(zhì)量記錄是一種特殊類型的受控文檔。 它是面向顧客的文檔， 用于證實同顧客需求的全面符 合性以及貫穿于開發(fā)和維護全過程的軟件質(zhì)量保證系統(tǒng)的有效運行5、軟件可靠性管理軟件可靠性管理指通過一個程序使軟件的可靠性得到最優(yōu)化的過程。 此程序著重于軟件防錯 （ software error prevention），發(fā)現(xiàn)并清除 fault ；此程序著重于采用一定措施并根據(jù)諸如資源，進度表及性能的約束條件使可靠性最大化。6、軟件配置版本 軟件配置版本是指在給定時間

28、點上組成軟件系統(tǒng)的、已批準而且文檔化的 SCI 版本的集合。五、問答題 （每小題 4分，共 20分）2、談?wù)勀銓ψ儺悳y試原理的理解。（1）使用變異算子對被測程序做微小的合乎語法的變動，每個新程序稱為一個變異體；（2）根據(jù)已有的測試數(shù)據(jù)運行變異體；（3）比較變異體和原程序的運行結(jié)果：如果兩者不同就稱該測試數(shù)據(jù)將該變異體殺死了； 否則稱該變異體是活的。2、請闡述軟件測試的原則。（1）盡早的和不斷的測試應(yīng)作為軟件開發(fā)人員的座右銘。（2）測試用例應(yīng)當由測試數(shù)據(jù)和與之對應(yīng)的預期結(jié)果組成。（3）測試用例應(yīng)包括合理的輸入條件和不合理的輸入條件。（4）嚴格執(zhí)行測試計劃，排除測試的隨意性。（5）充分注意測試當中

29、的群體現(xiàn)象。（6）要對每一個測試結(jié)果作全面的檢查 。（7）保存測試計劃、測試用例、出錯統(tǒng)計和最終分析報告，為維護工作提供充分的資料。3、測試用例設(shè)計的考慮因素有哪些？（1）測試用例必須具有代表性、典型性；1 分（2）測試用例要濃縮系統(tǒng)設(shè)計； 1 分（3）測試用例既要考慮正確的輸入，也需要考慮錯誤或異常的輸入，以及促使這些錯誤、 異常發(fā)生的條件； 1 分 （4）用戶測試用例設(shè)計需要考慮用戶實際使用場景。1 分 4、集成測試策略中， 漸增式與非漸增式集成策略各有何優(yōu)、 缺點？為什么通常采用漸增式？ 非漸增式集成策略是將所有的模塊一次連接起來， 簡單、 易行，節(jié)省機時，但測試過程中難 于查錯，發(fā)現(xiàn)錯

30、誤也很難定位，測試效率低。 1 分 漸增式集成策略是將模塊一個一個地連入系統(tǒng)，每連入一個模塊，都要對新系統(tǒng)進行測試。 這種組裝測試方案比較非漸增式， 容易查出錯誤及進行錯誤定位， 有利于查出模塊接口部分 的錯誤，因此測試效率高。但漸增式較費機時。 2 分 比較兩種集成策略，顯然漸增式有利于實現(xiàn)測試的目標，故通常采用漸增式進行組裝測試。1 分 5、請評價白盒測試？（1）2 分 優(yōu)點 迫使測試人員去仔細思考軟件的實現(xiàn) ; 可以檢測代碼中的每條分支和路徑 ; 揭示隱藏在代碼中的錯誤 ;對代碼的測試比較徹底 ;最優(yōu)化。（2）2 分 缺點昂貴 ;無法檢測代碼中遺漏的路徑和數(shù)據(jù)敏感性錯誤 ; 白盒測試不驗

31、證規(guī)格的正確性。3、黑盒測試的特點有哪些？（1）不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性；1 分 （2）測試人員只需知道該程序輸入和輸出之間的關(guān)系或功能；1 分 （3）設(shè)計測試用例的依據(jù)是需求規(guī)格說明書或用戶手冊；1 分 （4）尤其適合于一些第三方軟件測試，由于無法得到源程序，無法用其它方法進行測試。 1 分 4、等價類劃分的步驟如何？（1）根據(jù)輸入條件把數(shù)目極多的輸入數(shù)據(jù)劃分成若干有效等價類和若干無效等價類；2 分 （2）設(shè)計一個測試用例，使其覆蓋盡可能多的尚未被覆蓋的有效等價類，重復該步驟，直 至所有有效等價類均被覆蓋； 1 分 （3）設(shè)計一個測試用例，使其覆蓋一個的尚未被覆蓋的無效等價類，重復該步驟

32、，直至所 有無效等價類均被覆蓋。 1 分3、談?wù)勀銓Α俺掷m(xù)的軟件測試”的理解。 持續(xù)的軟件測試有兩方面的含義：（1）完整的軟件測試工作應(yīng)該貫穿整個軟件生存周期存周期2 分 （2）軟件開發(fā)不同階段都有軟件測試工作，即軟件測試工作的各個步驟分布在整個軟件生 存周期中。 2 分 4、一般的軟件項目管理與軟件測試項目管理之間的區(qū)別由那些？（1）對于一般的軟件項目管理，成本和進度控制是最重要的；2 分 （2）而在軟件測試項目管理中，質(zhì)量第一是基本點，所有測試項目管理工作都要圍繞提高 產(chǎn)品質(zhì)量展開，最終保證在合理的成本、進度下滿足用戶需求或期望。2 分5、與桌面檢查相比，代碼審查與代碼走查有哪些優(yōu)點？（1

33、）桌面檢查即程序員自己檢查自己的程序。通常，由于程序員思維定勢、心理因素的限 制，使得桌面檢查效率不高。 2 分 （2）代碼走查、代碼審查采用成組方式進行，一旦發(fā)現(xiàn)錯誤就知道了錯誤的位置和性質(zhì)， 從而大大降低了調(diào)試費用和成本； 另外代碼走查、 代碼審查可以一次發(fā)現(xiàn)一批錯誤， 錯誤發(fā) 現(xiàn)效率較高。 2 分 1、請比較白盒測試與黑盒測試方法？（1）白盒測試只考慮測試軟件產(chǎn)品 , 它不保證完整的需求規(guī)格是否被滿足。 而黑盒測試只考 慮測試需求規(guī)格 , 它不保證實現(xiàn)的所有部分是否被測試到。1 分 （2）黑盒測試會發(fā)現(xiàn)遺漏的缺陷 , 指出規(guī)格的哪些部分沒有被完成。 而白盒測試會發(fā)現(xiàn)代理 方面的缺陷 ,

34、指出哪些實現(xiàn)部分是錯誤的。 1 分（3）白盒測試比黑盒測試成本要高得多。 它需要在測試可被計劃前產(chǎn)生源代碼 , 并且在確定 合適的數(shù)據(jù)和決定軟件是否正確方面需要花費更多的工作量。 1 分 （4）一個白盒測試的失敗會導致一次修改, 這需要所有的黑盒測試被重復執(zhí)行并且重新決定白盒測試路徑。 1 分 5、測試項目中，主要的測試文檔有哪些？ 測試計劃、測試設(shè)計規(guī)格說明、測試用例說明、測試規(guī)程規(guī)格說明、測試執(zhí)行報告、測試日 志、測試缺陷報告、測試總結(jié)報告等3、談?wù)勀銓Α败浖y試的必要性”的理解。軟件測試的必要性主要體現(xiàn)在如下方面： 程序代碼最終體現(xiàn)了軟件的質(zhì)量； 軟件測試力爭發(fā)現(xiàn)更多的缺陷盡量減少殘留的

35、缺陷； 軟件測試提高軟件的正確性； 軟件測試建立對軟件的信心； 軟件測試掌握軟件的質(zhì)量水平； 軟件測試是軟件質(zhì)量保證的重要手段。4、請闡述測試用例在代碼走查中的作用。（1）代碼走查中， 測試用例并不是關(guān)鍵， 也并不是僅想驗證這幾個測試用例運行是否正確， 人腦畢竟比計算機慢太多；（2）這里測試用例是作為懷疑程序邏輯與計算錯誤的啟發(fā)點，在隨測試實例游歷程序邏輯 時，在懷疑程序的過程中發(fā)現(xiàn)錯誤。5、測試覆蓋準則的作用如何？ 1）定量地規(guī)定軟件測試需求，指導測試數(shù)據(jù)的選擇； （2）度量測試數(shù)據(jù)集，揭示軟件特定特征的能力；（3）對測試結(jié)果和軟件可靠性評估具有重要影響。1、專業(yè)軟件開發(fā)的 SQA環(huán)境有哪些

36、特征？遵守合同約定； 服從顧客供貨商關(guān)系； 需要協(xié)同工作； 需要同其他開發(fā)組的合作和協(xié)調(diào)； 同其它軟件系統(tǒng)的接口； 項目組有變化時項目繼續(xù)進行； 需要持續(xù)維護軟件系統(tǒng)若干年。2、請指出走查、審查這兩種同行評審方法的不同？走查和審查的區(qū)別是其正式性的等級。其中，審查是兩者之中更為正式。2 分走查的發(fā)現(xiàn)限于被評審文檔的意見，而審查的發(fā)現(xiàn)還同改進開發(fā)方法自身的工作相結(jié) 合。所以和走查相比，審查對一般的SQA做出了更大貢獻。3、請詳細描述軟件質(zhì)量費用的經(jīng)典模型？ 在經(jīng)典軟件質(zhì)量費用模型中，軟件質(zhì)量費用可以劃分為控制費用、控制失效費用。 其中，控制費用被進一步細化為預防費用和評價費用； 控制失效費用進一

37、步細化為內(nèi)部失效 費用、外部失效費用。（1 ） 預防費用包括建立軟件質(zhì)量基礎(chǔ)設(shè)施、更新并改進基礎(chǔ)設(shè)施以及完成其運行所需的 常規(guī)活動的投資。（2）評價費用花在特定項目或軟件系統(tǒng)中軟件錯誤的檢測上。（3）內(nèi)部失效費用是指改正在顧客現(xiàn)場安裝軟件之前實施設(shè)計評審、軟件測試及驗收測 試時檢測到的錯誤而產(chǎn)生的費用。（4）外部失效費用限定為改正由顧客或維護組在顧客現(xiàn)場安裝軟件系統(tǒng)之后檢測到的失效 的費用。4、認證標準和評估標準的主要區(qū)別？認證標準的重點是外部的 - 支持供貨商顧客關(guān)系 2 分 ，而評估標準的重點是內(nèi)部的。因為 評估標準關(guān)注的是軟件過程改進 2 分 。5、CCB的決策機制有哪些種類？你認為其中

38、那種決策機制更實用？（1）最普遍的方法是投票決定。每個代表都投票，采用少數(shù)服從多數(shù)的方式。這種民主的做法能夠充分調(diào)動 CCE成員的機機性；但是少數(shù)服從多數(shù)含義模糊，該決策模式也容易產(chǎn)生一些政見。（2）極端的做法是所有決策都交給一個人，這種安排鼓勵在決策中靈活考慮各種意見，但 壓抑了 CCB其他成員的積極性；（3 ）第三種可行的決策機制是尋求CCE成員的一致意見，同時提供合理的跳出機制。綜合考慮上述三種不同 CCB決策機制，第三種策略最為實用。6、傳統(tǒng)質(zhì)量成本和現(xiàn)代質(zhì)量成本的主要區(qū)別有哪些？ 傳統(tǒng)的質(zhì)量成本集中在與失效有關(guān)的事件和活動， 如損壞、 缺陷等。 傳統(tǒng)質(zhì)量成本通常以報 廢、返工、返修等

39、形式出現(xiàn)； 2 分現(xiàn)代的質(zhì)量成本的目的則在于通過預防和評估活動中的適當投入，減少與失效有關(guān)的活動。2 分1、 Crosby, Juran, Pressman軟件質(zhì)量定義的比較。（1）Crosby 的定義指的是寫好的軟件符合由顧客和它的專業(yè)組編制的規(guī)格說明書的程度。 這也意味著包含在規(guī)格說明中的錯誤是不予考慮的，也不降低軟件質(zhì)量顯然這是不足的。1 分（ 2） Juran 的定義旨在達到顧客滿意度，這就要求對檢查改正顧客的需求規(guī)格書投入大量 工作。但該定義的主要缺點是免除了顧客對軟件規(guī)格書準確性、完備性的責任。1 分（3）Pressman定義為SQA提出了要由開發(fā)者滿足的三個要求：特定功能需求，它

40、主要是指 軟件系統(tǒng)的輸出； 在合同中提出的軟件質(zhì)量標準； 反映當今水平的專業(yè)方法的良好軟件工程 方法的發(fā)展水平。實際上， Pressman 定義提供了測試滿足需求程度的操作方向。2、談?wù)勀銓贤u審過程的理解？合同評審是一個指導評審建議草案和合同文檔的SQA部件。其過程分為兩個階段進行：1分（1 ）第一階段提交給可能顧客之前的建議草案評審；1 分（2） 第二階段簽約前的合同草案評審 , 該階段在建議和合同談判期達成的理解基礎(chǔ)上評審 合同草案。 1 分 每個評審階段完成后，要求建議組與法律部進行必要的修改、補充和改正。1 分3、 請列舉典型的軟件質(zhì)量基礎(chǔ)設(shè)施SQA部件?（不少于5個） 規(guī)程與工作

41、條例、支持性質(zhì)量手段、員工培訓與認證、改正性和預防性措施、配置管理、文 檔編制控制4、請指出軟件質(zhì)量費用擴展模型對軟件質(zhì)量費用經(jīng)典模型的擴展。 仔細考察經(jīng)典軟件質(zhì)量費用模型的考察， 我們將發(fā)現(xiàn)經(jīng)典軟件質(zhì)量費用模型沒有能夠涵蓋管 理以及管理性失效導致的軟件質(zhì)量費用。 2 分 軟件質(zhì)量費用擴展模型拓展了經(jīng)典軟件質(zhì)量費用模型， 以涵蓋管理人員對軟件質(zhì)量總費用的 貢獻' 軟件質(zhì)量的擴展模型： 相對經(jīng)典軟件質(zhì)量費用， 軟件質(zhì)量費用擴展模型添加了管 理性準備與控制費用和管理性失效費用。 2 分（管理性準備與控制費用同實施的預防性管理失效或減少這些這些失效的預期出現(xiàn)的活動 相關(guān)聯(lián)；）5、請描述 IS

42、O 9000-3 質(zhì)量管理系統(tǒng)的基本原理（1）顧客關(guān)注。機構(gòu)依靠它們的顧客，所以應(yīng)當理解當前的與未來的顧客需要；（2）領(lǐng)導 - 建立并維護一個積極的內(nèi)部環(huán)境中行使領(lǐng)導權(quán)，以實現(xiàn)機構(gòu)的目標；（3）人們的投入。人是機構(gòu)之本，他們在各機構(gòu)層次的全身心投入使得他們的能力能用于為機構(gòu)謀益；（4）過程方法 - 當把活動與資源作為過程管理的時候，就更有效地達到理想的結(jié)果；（5）管理理的系統(tǒng)方法 - 把過程作為一個系統(tǒng)管理；（6）持續(xù)改進 - 對全面性能正在進行的改進應(yīng)當在機構(gòu)的日程上優(yōu)先；（7）決策制定的實在方法。有效決策是建立在信息分析的基礎(chǔ)上的；（8）相互支持的供貨商關(guān)系。一個機構(gòu)和它的供貨商是互相依賴

43、時，相互支持的供貨由關(guān) 系增強雙方創(chuàng)造增加值的能力6、傳統(tǒng)質(zhì)量成本和現(xiàn)代質(zhì)量成本的主要區(qū)別有哪些？ 傳統(tǒng)的質(zhì)量成本集中在與失效有關(guān)的事件和活動， 如損壞、 缺陷等。 傳統(tǒng)質(zhì)量成本通常以報 廢、返工、返修等形式出現(xiàn)； 現(xiàn)代的質(zhì)量成本的目的則在于通過預防和評估活動中的適當投入，減少與失效有關(guān)的活動。1、在軟件產(chǎn)品與其他工業(yè)產(chǎn)品之間的區(qū)別主要有哪些？并描述這些不同？ 軟件產(chǎn)品和其他工業(yè)產(chǎn)品的主要區(qū)別有如下幾點：（1）產(chǎn)品的復雜性； 產(chǎn)品的復雜性能夠用產(chǎn)品許可的操作方式的數(shù)目來度量 : 工業(yè)產(chǎn)品，即使是高級機器，也不 允許由其不同的機器組合建立的幾千種以上的操作方式； 一個典型的軟件， 人們可以發(fā)現(xiàn)上

44、 百萬種軟件操作的可能。（2）產(chǎn)品的可見性； 工業(yè)產(chǎn)品是可見的， 而軟件產(chǎn)品是不可見的。 工業(yè)產(chǎn)品的大多數(shù)缺陷可在制造過程中檢測出 來；然而軟件產(chǎn)品的缺陷是不可見的，軟件包中的組件可能從一開始就缺失了。（3）產(chǎn)品開發(fā)和制造過程的特殊性。同工業(yè)產(chǎn)品相比， 軟件產(chǎn)品不能在生產(chǎn)過程的所有三個階段檢測缺陷。 能夠檢測缺陷的唯一 階段是開發(fā)階段。2、高度螺旋模型每次迭代必需的活動包含哪些？ 顧客的需求規(guī)格說明、意見與更改要求； 開發(fā)者的計劃制定活動； 開發(fā)者的風險分析與化解；開發(fā)者設(shè)計活動； 開發(fā)者關(guān)于編碼、測試、發(fā)布的構(gòu)造活動； 顧客的評價3、請從SQA勺角度，闡述分別編寫用戶需求文檔和系統(tǒng)需求文檔的

45、理由？（1）很自然人們會想到只有客戶才會有興趣透徹定義它的需求以確保他約定的軟件產(chǎn)品的 質(zhì)量。他編制的需求文檔是對低質(zhì)量的基礎(chǔ)防護；（2）然而我們對各種軟件質(zhì)量因素的分析表明，開發(fā)者可以添加代表它自身利益的需求， 例如可重用性需求、 可驗證性需求等； 許多情況下， 某些沒有包括在典型客戶需求文檔中的 質(zhì)量因素確是開發(fā)者感興趣的。而，諸如可移植性、可重用性、可驗證性等質(zhì)量因素，客戶 很少感興趣。這也就是人們?yōu)楹畏謩e編制客戶需求文檔和系統(tǒng)需求文檔的理由。4、主要的SQA維護基礎(chǔ)設(shè)施工具有哪些？主要的SQAt護基礎(chǔ)設(shè)施工具有軟件維護規(guī)程和工作條例、支持性軟件質(zhì)量手段、維護組的培訓和認證、預防性和改正

46、性措施、軟件配置管理、軟件維護文檔和質(zhì)量記錄等5、軟件質(zhì)量度量過程模型包含哪些活動？（1）軟件質(zhì)量需求的定義；（2）軟件質(zhì)量度量和評估的準備；（3）軟件質(zhì)量度量的執(zhí)行、分析和確認6、傳統(tǒng)質(zhì)量成本和現(xiàn)代質(zhì)量成本的主要區(qū)別有哪些？（1）2分傳統(tǒng)的質(zhì)量成本集中在與失效有關(guān)的事件和活動，如損壞、缺陷等。傳統(tǒng)質(zhì)量 成本通常以報廢、返工、返修等形式出現(xiàn)；（2）2分現(xiàn)代的質(zhì)量成本的目的則在于通過預防和評估活動中的適當投入，減少與失效 有關(guān)的活動。六、應(yīng)用題（每小題8分，共24分）1、某軟件需求規(guī)格說明中包含如下要求：第一列字符必須是A或B,第二列字符必須是一個數(shù)字，在此情況下進行文件修改。但是，如果第一列字

47、符不正確，則輸出信息L;如果第二列字符不是數(shù)字，則給出信息M請采用因果圖進行分析，并繪制出該軟件需求規(guī)格說明對應(yīng)的因果圖。（1）4分識別出所有原因和所有結(jié)果，并給出原因、結(jié)果元的編號如下：編號原因1第一列字符為A2第一列字符為B3第二列字符為一個數(shù)字11中間原因21修改文件22給出信息L23給出信息M（2）4分識別所有原因與原因之間，原因與結(jié)果之間，結(jié)果與結(jié)果之間的關(guān)系，再次接 觸上繪制出因果圖如下圖所示。2、某程序模塊功能描述如下：用戶輸入分別合乎規(guī)則輸入年、月、日程序即給出相應(yīng)日 期的下一天。假設(shè)限定該模塊年份在區(qū)間1840 , 3000，月份、日規(guī)定滿足公歷約束。試分別選取測試數(shù)據(jù)對年進

48、行（1）基本邊界值測試和（2）健壯性測試。假設(shè)該模塊的輸入：年、月、日分別使用變量year, mo nth, day 表示。（1）4分基本邊界值測試的測試數(shù)據(jù)year值在有效取值區(qū)間內(nèi)取極值，其他變量取正常值。依據(jù)基本邊界值測試基本原理，測 試數(shù)據(jù)選擇如下：組別測試數(shù)據(jù)1year=1840, month=1, day=122year=1841, month=2, day=203year=2002, mo nth=9, day=14year=2999, month=11,day=1O5year=3000, mon th=3, day=30(2)4分健壯性測試的測試數(shù)據(jù)year值在整個取值區(qū)間內(nèi)取

49、極值，其他變量取正常值。依據(jù)健壯性測試基本原理，數(shù)據(jù)選 擇如下：組別測試數(shù)據(jù)1year=1840, month=1, day=122year=1841, month=2, day=203year=2002, mo nth=9, day=14year=2999, mon th=11,day=105year=3000, mon th=3, day=306year=1839, month=4, day=197year=3001, mon th=8, day=223、某程序模塊如下，其中， S1, S2均為語句塊：if (A>1) AND (B=0)S1；if (A=2) OR (X>1)

50、S2;(1)請把上述代碼轉(zhuǎn)換成程序流程圖分別選擇測試數(shù)據(jù)使得(2)判定覆蓋、(3 )條件組合覆蓋標準都能夠得到滿足。(1) 2分程序流程圖(2) ( 2)2分判定覆蓋標準A=2, B=0, X=3 ；A=1, B=1, X=1(3) 4分條件組合覆蓋A=2, B=0, X=3 ;A=1, B=1, X=1 ;A=2, B=1, X=1A=1, B=0, X=21、閱讀如下C程序:int lsLeap(i nt year)if(year % 4 =0)if(year % 100 =0) if(year %400 != 0)leap=1;else leap=O;elseleap=1;else le

51、ap =0;要求：(1) 請繪制出左邊代碼對應(yīng)的流圖；(2) 計算所得流圖的環(huán)形復雜度V(G);(3) 假設(shè)輸入的取值范圍為(1000， 20001),請用基本路徑測試方法為變量year設(shè)計測試用例，使其滿足基本路徑測試的要求。retur n leap;(1)3分流圖(2) 1 分V(G)=e-n+2=14-12+2=判定點數(shù) +仁區(qū)域數(shù)=4(3) 4分問題3要求設(shè)計滿足基本路徑覆蓋的測試用例，而且輸入的取值范圍(1000， 2001 )。所選擇的測試數(shù)據(jù)只要使得獨立路徑數(shù)量得到滿足即可。典型的測試數(shù)據(jù)為：測試用例編號測試數(shù)據(jù)預期執(zhí)行結(jié)果測試路徑1year=1001leap=01-2-3-11-122year=1004leap=11-2-4-5-10-11-123year=1100leap=01-2-4-6-7-9-10-11-124year=2000leap=11-2-4-6-8-10-11-122、被測程序段為:begin可供選擇的測試數(shù)據(jù)組合