軟件測試實踐（三）（總分：88.00,做題時間：90分鐘）一、{{B}}選擇題{{/B}}（總題數：32,分數：64.00）實踐證明，與開發過程緊耦合而又相對獨立的測試過程，可以 。?A.盡早發現大量軟件缺陷?B.降低軟件開發成本?C.使基于復雜開發模型的測試管理工作更清晰?D.以上全部（分數：2.00）A.B.C.V解析：［解析］測試實踐中，常見的測試過程有兩種：一種是與開發過程緊耦合的軟件企業內部產品的測試過程，該測試過程是依據“獨立和迭代”的測試理念，在測試過程中，測試活動的組織可以依據項目開發的進度來規劃。實踐證明，該方法可以盡早發現大量軟件缺陷、降低軟件開發成本，還可以使基于復雜開發模型的測試管理工作更清晰明了。另一種是與開發過程松耦合的第三方軟件測試過程。下列關于軟件測試過程說法正確的是 。?A.與開發過程松耦合的第三方軟件測試過程也可以按照傳統的測試活動順序開展B.與開發過程緊耦合的軟件企業內部產品的測試過程不必進行迭代，只需安排好第一輪的測試之后的回歸測試就可以了?C.與開發過程松耦合的第三方軟件測試過程依據獨立與迭代的測試理念D.與開發過程緊耦合的軟件企業內部產品的測試過程可以發現大量缺陷，但同時也提高了軟件開發的成本（分數：2.00）VB.C.D.解析：［解析］與開發過程緊耦合的軟件企業內部產品的測試過程依據獨立與迭代的測試理念，測試過程進行獨立的策劃，找岀測試準備就緒點，在就緒點及時開展測試，實踐也證明，該方法不僅可以發現大量缺陷，同時也降低了軟件開發的成本；而與開發過程松耦合的第三方軟件測試過程則不必進行迭代，只需安排好第一輪的測試之后的回歸測試就可以了，該測試過程也是可以按照傳統的測試計劃、測試設計、測試執行和測試總結活動順序開展。測試項目實踐中，測試策劃活動的目標是 。A.確定測試范圍B.劃分測試任務C.編寫測試計劃文檔D.組織測試團隊（分數:2.00）A.B.VD.解析：［解析］在實際的測試項目實踐中，測試策劃活動的目標是編寫測試計劃文檔。測試計劃文檔中最主要的內容就是確定測試的范圍、戈卩分測試的任務、確定測試日程表和組織測試團隊等核心問題，同時也要考慮測試過程如何控制、測試質量如何保證和相關風險如何規避等問題。對軟件系統開展第三方測試，一般在測試執行中規劃 次粗測和 次細測，并規劃至少一次回歸測試和一次最終回歸測試才可。? A.1次，至少2次? B.1次，1次?C.至少2次，至少2次?D.不一定（分數：2.00）A.VC.D.解析：［解析］測試執行的主要任務就是執行測試用例，具體應根據被測系統的模塊開發進度和質量要求來規劃測試任務。若是對軟件系統開展第三方測試，一般在測試執行中規劃 1次粗測和1次細測?并在此基礎上規劃至少一次回歸測試和一次最終回歸測試才可。對于那些軟件企業內部測試團隊開展的軟件測試，最適合采用 來組織測試。?A.H模型B.V模型?C.W模型D.X模型（分數：2.00）VB.C.D.解析：［解析］假如是軟件企業內部測試團隊開展的軟件測試，由于軟件測試介入較早，在測試開始時被測系統很可能是不完整的，會不斷有新的系統模塊加入到系統中，因此最適合采用 H模型來組織測試，可以為每一個新增的系統模塊設計一次系統測試。下列日期與測試日程表有關的是 。?A.測試任務的規劃周期B.測試啟動的預期日期C.測試完成的預期日期D.以上全部（分數:2.00）A.B.C.V解析：［解析］確定測試日程表是測試計劃中的核心問題，具體的測試日程表與測試任務的規劃周期、測試啟動的預期日期和測試完成的預期日期相關。關于測試策略說法不正確的是 。?A.測試策略活動可以和測試設計活動并行開展?B.測試設計活動也可以和測試執行活動并行開展?C.在測試的最后階段里，測試總結和測試執行通常并行開展?D.在實際測試過程中，要不得不將一些測試活動并行開展，主要是因為時間原因（分數：2.00）A.B.VD.解析：［解析］一般的測試過程是按測試策劃、測試設計、測試執行和測試總結 4個測試活動順序開展的但實際測試項目中，由于時間緊迫，有時不得不將一些測試活動并行開展，如可以將測試策劃和測試設計活動并行開展，測試設計活動也可以和測試執行活動并行開展， 但測試總結和測試執行一般不會并行開展，但可以提前編寫相應的文字內容。測試質量監控機制主要關注的是 。A.測試任務的執行進度與質量B.測試交付物的質量C.及時發現和處理問題D.以上全部（分數：2.00）A.B.C.V解析：［解析］為提高測試過程質量，可以建立質量監控機制，它主要關注測試過程中各個測試任務的執行進度和質量，以及測試交付物的質量，并及時發現和處理問題。對于商業軟件系統的黑盒測試，其風險和控制主要是 。?A.測試用例完備性風險與控制B.時間、技術文檔資料風險與控制C.責任劃分、人員變動風險與控制D.以上全部（分數：2.00）A.B.C.V解析：［解析］對于業界常見的商業軟件系統的黑盒測試，其風險和控制詳見左欄內容。測試過程中發現的軟件缺陷首先在測試組內進行評估， 確保所匯報缺陷的有效性，這是軟件質量控制的 監控機制。?A.軟件測試用例評審機制?B.軟件缺陷校驗機制?C.軟件測試覆蓋檢查機制?D.測試組狀態報告機制（分數：2.00）A.VC.D.解析：［解析］質量監控機制主要關注測試過程中，各個測試任務的執行進度和質量，以及測試交付物的質量，并及時發現和處理問題。其中軟件缺陷校驗機制是指在測試過程中發現的軟件缺陷首先在測試組內進行評估，確保所匯報缺陷的有效性。測試過程質量控制的把握需求階段是依據 原則。A.盡早測試B.全面測試C.盡早測試和全面測試?D.全過程測試（分數：2.00）A.B.VD.解析：［解析］在軟件系統開發過程中，需求的獲取和完善貫穿于每個階段，測試過程質量控制的把握需求階段是依據“盡早測試”和“全面測試”原則，在需求獲取階段，測試人員參與到對需求的討論中，有助于加深測試人員對需求的把握和理解，同時也可提高需求文檔的質量。下面有關測試設計的敘述，說法不正確的是 。?A.測試用例的設計是一項技術性強、智力密集型的活動B.在測試用例設計時，只設計覆蓋正常流程和操作的測試用例即可C.在開展測試用例設計前，必須將測試需求進行詳細展開D.在一般的測試組織內，測試用例的評審可能不是正式的評審會（分數：2.00）A.VC.D.解析：［解析］在測試用例設計時，不能只設計覆蓋正常流程和操作的測試用例，而必須強制覆蓋錯誤輸入處理、邊界值處理等場景，以確保被測軟件系統投入使用時具備較強的容錯能力。 在開展測試用例設計前,必須將測試需求進行詳細展開，以便盡可能準確、完整地覆蓋被測軟件的功能、性能和安全等各方面的測試需求。測試用例的設計是一項技術性強、智力密集型的活動。在一般的測試組織內，測試用例的評審可能不是正式的評審會，因此要建立一種評審機制來提高測試用例的設計質量。軟件設計一般包括外部設計和內部設計。外部設計通常是指 。?A.用戶界面設計?B.結構設計?C.數據設計?D.邏輯設計（分數：2.00）VB.C.D.解析：［解析］外部設計主要是設計用戶界面。在設計前對任務和用戶進行分析。測試用例評審工作最好的負責者是 。A.軟件開發人員B.測試人員4 C.測試骨干人員D.專門評審人員（分數：2.00）A.B.VD.解析：［解析］在一般的測試組織內?測試用例的評審可能不是正式的評審會，因此要建立一種評審機制來提高測試用例的設計質量，建議由一組測試骨干人員來負責測試用例的評審工作。測試骨干人員將審閱各個模塊測試用例的編寫質量、測試場景的覆蓋情況，并客觀評價是否有必要增加測試項或測試用例來提高測試覆蓋率。測試用例在執行過程中的狀態有 。A.就緒B.執行中和執行通過C.執行失敗和執行受阻D.以上全部（分數：2.00）A.B.C.V解析：［解析］測試用例在執行過程中也有多種執行狀態，一般分為：就緒、執行中、執行通過、執行失敗和執行受阻等狀態。統計測試用例執行情況、測試用例在測試各個周期的執行情況統計是在 。?A.測試項目概述中?B.測試用例執行情況總結中?C.軟件缺陷報告總結中?D.被測軟件評價中（分數：2.00）A.VC.D.解析：［解析］測試總結是測試過程的最后一個活動，在測試報告中的內容包括：①測試項目概述；②測試用例執行情況總結；③軟件缺陷報告總結；④被測軟件評價。其中在測試用例執行情況總結中，主要是統計測試用例執行情況、測試用例在測試各個周期的執行情況，并將全部的測試用例文檔和測試執行記錄作為測試報告的附件提交。下列有關軟件缺陷報告的編寫中，哪個是錯誤的 。?A.—個軟件缺陷報告中只應記錄一個不可再劃分的軟件缺陷?B.軟件缺陷報告的標題應該能夠最簡潔表達一個軟件缺陷C.軟件缺陷報告中應提供全面的有關該軟件缺陷再現的信息D.同一個軟件缺陷可以被重復報告（分數：2.00）A.B.C.V解析：［解析］軟件缺陷報告的編寫應該遵循以下原則：（1）軟件缺陷報告是測試人員和開發人員交流的紐帶，最重要的原則是一定要將問題說明白，讓不能和測試人員直接交流的開發人員可以依據描述理解和再現所發現的軟件缺陷。（2）—個軟件缺陷報告中只應記錄一個不可再劃分的軟件缺陷。 （3）軟件缺陷報告的標題應該能夠最簡潔表達一個軟件缺陷。 （4）再現該軟件缺陷的步驟應該是最簡化的，應剔除其他不相關的步驟或因素。（5）依據一系列的程序執行步驟和測試輸入來再現軟件缺陷。 （6）應提供全面的有關軟件缺陷再現的信息。（7）不要填寫重復的軟件缺陷。當一個缺陷是被報告過的，那么就不可以再填寫另外一個報告，否則會造成質量保證人員和開發人員的額外負擔與資源浪費。 A、B、C均符合以上規則，D的說法與最后一條規則相違背。軟件過程管理最起碼的要求是 。?A.管理好軟件缺陷報告B.管理好軟件測試用例C.管理好測試過程工具D.管理好測試說明文檔（分數:2.00）A.VB.C.D.解析：［解析］軟件缺陷報告是軟件測試過程中的核心測試產品之一，也是重要的測試產品，因此管理好軟件缺陷報告是軟件過程管理最起碼的要求。不用紙張、缺陷單等來管理軟件缺陷報告的方式的主要原因是 。?A.無法滿足軟件缺陷的需求? B.無法滿足快速存儲軟件缺陷的需求? C.無法滿足軟件缺陷的需求? D.以上全部（分數：2.00）A.B.C.V解析：［解析］目前測試組織在早期使用紙張、缺陷單或者 Excel電子表格文檔等來管理軟件缺陷報告的方式已經被淘汰，其主要原因是目前軟件系統規模日益增大，測試過程發現軟件缺陷數量多，參與測試人員眾多，而這些傳統的手段已經無法滿足快速存儲、處理、共享軟件缺陷的需求。在QESuiteWebVersion1.0 中，軟件缺陷報告與軟件問題報告概念的關系是 。A.軟件問題報告包含了軟件缺陷報告B.軟件缺陷報告包含了軟件問題報告? C.軟件缺陷報告與軟件問題報告概念相同?D.軟件缺陷報告與軟件問題報告概念完全不同（分數：2.00）A.B.VD.解析：［解析］軟件缺陷（問題）報告的概念：是指測試組織描述被測軟件系統所存在軟件缺陷 （問題）的報告文檔。軟件問題和軟件缺陷概念上的差異：測試方在測試中所發現的均為軟件問題，在經過開發方確認后才是軟件缺陷。因此在概念上軟件問題實際上包含了軟件缺陷。但在 QESuiteWebVersion1.0中，軟件缺陷報告與軟件問題報告概念是相同的。不在當前版本修復，在本項目的下一個新版本修復的缺陷是 。A.NewMoreInfoB.Deferred-NextBuildC.Diferred-NextMainReleaseD.Declined-Duplicated(分數:2.00)A.VC.D.解析：［解析］定義軟件缺陷的狀態如下：?新錯誤(New) 測試中新報告的軟件缺陷。 ?更多新信息(NewMoreInfo)――開發工程師認為報告的缺陷信息不完整，要求缺陷報告者添加更準確的缺陷信息。?打開(Open)――缺陷被確認并分配給相關開發工程師處理。 ?拒絕(Declined)――拒絕修改缺陷。?修正(Fixed)――開發工程師已完成修正，等待測試人員驗證。 ?重新打開(Reopen)――沒有正確修復的缺陷，需要進一步修復。 ?延期(Deferred) 不在當前版本修復的缺陷，以后的版本修復，包括兩種情況： ①延期-下個版本(Deferred-NextBuild) 本項目的下一個新版本修復； ②延期-下個主要版本(Deferred-NextMainRelease) 本項目不修復，本軟件下一個項目的版本修復。 ?關閉(Closed) 缺陷已被修復。在軟件缺陷處理中，測試人員查詢狀態為 Fixed的缺陷，驗證其是否已修復，若已經修復，則設置缺陷狀態為 ，若沒有解決，設置缺陷狀態為 。?A.CIosed,ReopenB.Closed,PendingC.Resolved,PendingD.Resolved,Reopen(分數：2.00)VB.C.D.解析：［解析］在軟件缺陷的處理流程中，測試人員首先會查詢狀態為 Fixed的缺陷，然后驗證缺陷是否已修復，若已經修復，則設置缺陷狀態為 Closed，若沒有解決，設置缺陷狀態為 Reopen。在軟件問題生命周期中的不同階段，參與協調測試過程的人員主要是 。A.測試人員B.開發人員C.管理人員D.以上全部(分數：2.00)A.B.C.V解析：［解析］軟件問題在生命周期中經歷了數次的審閱和狀態變化，最終由測試人員關閉 /解決軟件問題來結束一個軟件問題的生命周期。軟件生命周期中的不同階段是測試人員、開發人員和管理人員共同參與協調測試的過程。軟件問題一旦發現，但進入測試人員、開發人員和管理人員的嚴密監控中，直至軟件問題生命周期結束。在軟件測試的生命周期模型中建立測試腳本任務的階段應是 。?A.制定測試計劃?B.測試設計?C.實施測試?D.評估測試（分數:2.00）A.B.VD.解析：［解析］在軟件測試的生存周期模型中，建立測試腳本的階段是實施測試階段。測試計劃的要素有 。?A.測試人員和環境、版本定義?B.測試需求定義與劃分?C.測試任務劃分和測試日程安排?D.以上全部（分數：2.00）A.B.C.TOC\o"1-5"\h\zV解析：［解析］測試計劃的要素有：測試需求定義與劃分、測試人員定義、測試環境定義、測試版本定義、測試任務劃分和測試日程安排。 QESuiteWebVersion1.0 提供了一系列的文檔和配套視圖系統來管理這些要素。在QESuiteWebVersion1.0 中，下列狀態不屬于活動狀態的是 。A.“解決”B.“待驗”C.“打開”■D.“新建”TOC\o"1-5"\h\z（分數：2.00）VB.C.D.解析：［解析］QESuiteWebVersion1.0中，軟件問題的主狀態有：“新建”、"打開”、"待驗”、"解決”和“關閉”，其中“新建”、“打開”、“待驗”為軟件問題的活動狀態，“關閉”和“解決”為軟件問題的非活動狀態。在QESuiteWebVersion1.0 提供的功能中，下列不是輔助管理員控制測試過程運行的是 A.監控測試用例執行文檔的執行過程B.支持對被測功能點的深度管理? C.監控軟件問題報告處理過程和軟件系統各模塊軟件問題分布狀況? D.使用輔助統計功能，了解當前開發測試進展（分數：2.00）A.VC.D.解析：［解析］QESuiteWebVersion1.0提供一系列的功能來輔助測試管理人員控制測試過程的運行:控測試用例執行文檔的執行過程； ?監控軟件問題報告處理過程和軟件系統各模塊軟件問題分布狀況；?使用輔助統計功能，了解當前開發測試進展。白盒測試又稱為 。?A.程序結構測試? B.功能測試? C.靜態分析? D.數據流結構測試（分數：2.00）VB.C.D.解析：［解析］白盒測試又稱為程序結構測試，它主要進行程序邏輯結構的覆蓋測試。實際上，在進行白盒測試的同時，往往還要伴隨著對程序進行靜態分析和復雜性度量。靜態分析全局變量和局部變量的聲明、賦值和使用的位置屬于 。A.程序結構分析B.程序數據流分析C.可視化分析D.程序執行頻度分析（分數：2.00）A.VC.D.解析：［解析］白盒測試工具的主要功能之一一一程序數據流分析，主要指靜態分析全局變量和局部變量的聲明、賦值和使用的位置；動態跟蹤變量值的變化情況，包括該變量的初始值、最小值和最大值。而選項A程序結構分析，主要提供整個項目中的所有函數之間的調用關系圖。選項 C是針對面向對象的軟件，供整個項目中的所有類之間的關系圖。選項 D程序執行頻度分析是統計所有條件分支、多岀口跳轉、多岀口調用的各分支、出口的執行關系圖。用QESAT/C工具進行軟件分析與測試時，以下說法錯誤的是 。A.白盒測試又稱為程序結構測試，它主要進行程序邏輯結構的覆蓋測試B.在進行測試之前，必須先建立以.prj為后綴的測試項目被測源文件可放在任意目錄下進行軟件靜態分析不必運行被測程序（分數:2.00）A.VC.D.解析：［解析］白盒測試又稱為程序結構測試，它主要進行程序邏輯結構的覆蓋測試。用 QESAT/C工具進行測試之前，首先應定義項目文件，用以描述被測程序的組成，該項目文件通常以 .pjt作為擴展名的。用QESAT/C工具進行軟件分析與測試時，被測源文件可放在任意目錄下。進行軟件靜態分析不必運行被測程序，便可得到程序的結構信息及程序的復雜度信息，將被測程序運行后才得到的信息就是動態測試信息。下列屬于動態測試過程步驟的是 。?A.設定待測試的配置、編譯相關的源程序?B.設定需插裝的函數?C.運行源程序、合并動態運行的結果D.以上全部（分數：2.00）A.B.C.V解析：［解析］動態測試信息是指：將被測程序運行后才能獲得的測試信息。做動態測試之前必須先通過靜態分析，動態測試過程的步驟如下： ?設定待測試的配置 ?設定需插裝的函數 ?編譯相關的源程序?運行源程序?合并動態運行的結果待測試的配置包括項目編譯運行所需的 。A.源文件路徑B.編譯參數C.鏈接參數D.以上全部（分數：2.00）A.B.C.V解析：［解析］動態測試過程的第一步就是要設定待測試的配置，該配置包括項目編譯運行所需的源文件路徑、編譯參數、鏈接參數等。二、{{B}}論述題{{/B}}（ 總題數：2,分數：24.00）已知C源程序如下：/*分數運算fsys.c*/ineludevstdio.h>intmain(){longinta,b,c,d,i,x,y,z;charop;/n");printf("兩分數b/a,d/c 作+、-、*、/四則運算，結果為分數/n");printf(請輸入分數運算式:b/aopd/c/n");scanf("%ld/%ld%c%ld/%ld",&b,&a,&op,&d,&c);if(a==0||c==0){printf("分母為0，輸入錯誤!/n");return(0);}if(op=='+'){y=b*c+d*a;x=a*c;/*運算結果均為y/x*/}if(op=="-'){y=b*c-d*a;x=a*c;}if(op=='*'){y=b*c;x=a*d;}z=x;if(x>y)z=y;i=z;while(i>1){if(x%i==0&&y%i==0){x=x/i;y=y/i;continue;}i--;}printf("%ld/%ld%c%ld/%ld=%ld/%ld./n",b,a,op,d,c,y,x);

return0;｝（分數:12.00）（1）.畫出程序中main函數的控制流程圖。（分數： 4.00）正確答案：（main函數的控制流程圖：［*］）解析：（2）.設計一組測試用例，是該程序所有函數的語句覆蓋率和分支覆蓋率均能達到 100%如果認為該程序的語句覆蓋率或分支覆蓋率無法達到 100%,需說明為什么。（分數：4.00）正確答案：（測試用例用例1：輸入：2/0+3/1；輸出：分母為0，輸出錯誤！返回；用例1:輸入：2/1+3/0；輸出：分母為0，輸出錯誤！返回；用例1:輸入：2/1+3/1;輸出：2/1+3/1=5/1 ;正常；返回；用例1:輸入：3/1-2/1;輸出：3/1-2/1=1/1 ;正常；返回；用例1:輸入：3/1*2/1 ;輸出：2/1*3/1=6/1 ;正常；返回；用例1:輸入：3/1/2/1 ;輸出：3/1/2/1=3/2 ;正常；返回；用例1:輸入：1/5+3/5;輸出：1/5+3/5=4/5;正常；返回；用例1:輸入：2/8+6/8;輸出：2/8+6/8=1/1;正常；返回； 結論：利用上面的測試用例，即可使該程序的語句覆蓋率或分支覆蓋率達到 100%）解析：（3）.已知張明在功能區域“我的安全區 /導入和導岀”下發現一個軟件問題， 下表中時該軟件問題的操作歷史信息，請依據QESuiteWebVersion1.0 的軟件問題生命周期定義和題中所述的相關人員分配和測試版本信息，假設下表中“執行操作”的信息均正確，請找岀表中的錯誤，并說明理由。功能區域功能區域測試人員開發人員安裝李鳴郁離我的安全區本地安全區李鳴鄭軍導入與導出李鳴鄭軍服務端安全區張明陳劍鋒性能并發傳輸響應能力李曉軍張然已知張明在功能區域“我的安全區/導入和導岀”下發現一個軟件問題，下表中時該軟件問題的操作歷史信息，請依據QESuiteWebVersion1.0 的軟件問題生命周期定義和題中所述的相關人員分配和測試版本信息，假設下表中“執行操作”的信息均正確，請找岀表中的錯誤，并說明理由。QESuiteWebVersion1.0 中，已知某安全文檔管理系統測試項目的部分信息如下：?在測試過程中先后產生4個測試版本，按日期排序分別為 SEDM1.0_101009SEDM1.0_101025SEDM1.0_101103SEDM1.0_101106?功能分類視圖中部分待測區域及人員分配定義如下表所示：操作序號操作者執行操作操作后的問題狀態測試版本1張明新建打開SEDM1.01010092李曉軍校驗/再現打開/再現SEDM1.01010253鄭軍修復/修復檢驗/修復SEDM1.01011034李鳴驗證/同意解決/不修復SEDM1.01011035李鳴重新打開待驗/修復SEDM1.0101025（分數：4.00）正確答案：（操作操作者執行操作后的測試版本

操作操作者執行操作后的測試版本序號操作問題狀態1張明新建新建 SEDM1.0__1010092李鳴校驗/再現打開/再現SEDM1.0_1010253鄭軍修復/修復檢驗/修復SEDM1.0__1011034李鳴驗證/同意解決/修復SEDM1.0__1011065李鳴重新打開打開/再現SEDM1.0_101106理由如下：題中說產生4個版本，應該把4個版本都考慮進去。還有最后一個要用最新的版本進行測試。 如果用“解決”以前的版本進行測試，并不能反映真實的情況。用最新的版本進行測試，有問題的話，才修改狀態為“打開/再現”，證明這個錯誤并沒有真正解決。操作序號1中一般測試人員只能提交新的軟件問題入庫， 并將其狀態置為“新建”，該行“操作后問題狀態”應為“新建”。操作序號4中測試人員查詢狀態為“待驗”的軟件問題，驗證是否修復， 如果已修復，則置軟件問題狀態為“解決”，如果沒有解決則置狀態為“打開”，該行“操作后的問題狀態”應為“解決 /修復”。操作序號5中在以后的測試版本中，如果該問題重新岀現，測試人員應該重新打開此問題， 并將問題狀態更改為“打開/再現”。)解析：某測試項目中的測試執行階段按計劃在 3天后結束，將進入測試總結階段。(分數：12.00)(1).測試管理人員通過QESuiteWebversion1.0 測試過程管理工具觀察到部分測試用例的設計狀況和執行狀況如下表，請從測試用例設計和測試用例執行兩個方面說明觀察到的問題和需要盡快開展的相關測試工作。子系統功能區域測試用例編寫數量測試用例執行狀況登錄與退出-66個未執行即時消息個人設置82個執行通過6個未執行發送/接收消息5全部執行通過邀請多人參與5全部執行通過音視頻交互5全部執行通過客戶端容量-0-客戶端性能-55個執行通過客戶端強度-42個執行通過2個執行失敗(分數：4.00)正確答案：(根據該表可以發現存在下列問題：子系統客戶端容量沒有設計相關的測試用例，需要補上。登錄與退岀的測試用例全部沒有被執行，需要執行。即時消息的個人設置功能的測試用例沒有執行完全，只執行了兩個且通過，還有6個未執行。總體來說，存在的問題有：測試用例設計也存在問題，功能區域劃分不詳細。用例覆蓋面不全，客戶端容量的測試用例沒有覆蓋到。還有就是存在未執行的用例。 )解析：

（2）.該項目當前的軟件問題處理狀況如下： 測試項目當前剩余處在“待驗”狀態的軟件問題有 105個，處在“新建”狀態的軟件問題有 14個，處在“打開”狀態的軟件問題有 151個。已知該測試組的軟件問題日常處理能力是90個軟件問題/工作日，開發組日常修復軟件問題的能力是 40個軟件問題/工作日。請說明軟件問題報告處理方面說明存在的問題和需要盡快開展的相關開發和測試工作。（分數： 4.00）正確答案：（根據題意，開發組中要修改的問題數是 14