2009年上半年軟件評測師下午試卷及答案
試題一:閱讀下列說明,回答問題1至問題4,將解答填入答題紙的對應欄內。
[說明]軟件測試的質量決定著被測產品的質量,是企業(yè)關注的重點。
[問題1]請簡要敘述軟件測試質量包括哪些管理要素。
[問題2] 請簡要論述軟件測試質量控制的主要方法。
[問題3] 企業(yè)衡量軟件測試的質量經常采用兩個指標:測試用例覆蓋率和缺陷修復率,請簡述這兩個指標的概念。
[問題4] 企業(yè)內部測試組在測試某辦公自動化系統(tǒng)的過程中,使用60個測試用例進行測試,共發(fā)現了20個問題。
開發(fā)組對軟件修改后,向測試組提交問題修改報告及修改后的軟件。問題修改報告中提出:所發(fā)現問題中的5個問題是用戶所要求的,無需修改,其余15個問題已修改完成。 測試組使用針對上輪測試中發(fā)現的15個問題的36個測試用例進行了回歸測試,確認問題已得到修改,因此測試組做出結論:當前版本可以進入配置管理庫,進行后續(xù)集成工作。
請簡要分析測試組的做法是否存在問題并簡述理由。
此辦公自動化系統(tǒng)提交給用戶之后,用戶在使用過程中發(fā)現了5個問題,測試項目經理打算采用缺陷探測率來對測試人員進行績效評估。請計算此測試項目的缺陷探測率。
試題二(20 分)閱讀下列說明,回答問題1至問題5,將解答填入答題紙的對應欄內。
[說明]某“網站稿件管理發(fā)布系統(tǒng)”是采用J2EE架構開發(fā)的B/S系統(tǒng),Web服務器、應用服務器以及數據庫服務器部署在一臺物理設備上。
系統(tǒng)實現的功能主要包括稿件管理和文檔上傳下載。稿件管理模塊可以對稿件進行增加、查詢、刪除、修改、顯示和批準等操作,批準后的稿件即可在網站上發(fā)布;文檔上傳下載模塊可以將稿件直接以Word文檔的格式進行上傳下載。
系統(tǒng)性能需求如下:
(1)主要功能操作在5秒鐘內完成;
(2)支持50個在線用戶;
(3)稿件管理的主要功能至少支持20個并發(fā)用戶;
(4)在50個用戶并發(fā)的高峰期,稿件管理的主要功能,處理能力至少要達到8trans/s;
(5)系統(tǒng)可以連續(xù)穩(wěn)定運行12小時。
[問題1](3分)簡要敘述“網站稿件管理發(fā)布系統(tǒng)”在生產環(huán)境下承受的主要負載類型。
[問題2](3分)簡要敘述進行“網站稿件管理發(fā)布系統(tǒng)”的性能測試中應測試的關鍵指標。
[問題3](3分)請簡述訪問系統(tǒng)的“在線用戶”和“并發(fā)用戶”的區(qū)別。
[問題4](3)系統(tǒng)性能需求中要求“系統(tǒng)可以連續(xù)穩(wěn)定運行12小時”,若系統(tǒng)連續(xù)運行12小時完成的總業(yè)務量為1000筆,系統(tǒng)能夠提供的最大交易執(zhí)行吞吐量為200筆/小時,試設計測試周期,并說明理由。
[問題5](8分)下圖為并發(fā)50個用戶執(zhí)行“稿件查詢”操作的測試結果。
(1)請判斷結果是否滿足系統(tǒng)性能需求并說明理由。
(2)簡要說明Transactions per Second與Average Transaction Response Time之間的關系。
試題三(14分)閱讀下列說明,回答問題1至問題3,將解答填入答題紙的對應欄內。
[說明]場景法是黑盒測試中重要的測試用例設計方法。目前多數軟件系統(tǒng)都是用事件觸發(fā)來控制業(yè)務流程,事件觸發(fā)時的情景便形成了場景,場景的不同觸發(fā)順序構成用例。場景法通過場景描述業(yè)務流程(包括基本流(基本流程)和備選流(分支流程)),設計用例遍歷軟件系統(tǒng)功能,驗證其正確性。
下面是對網上銀行支付交易系統(tǒng)的基本流和備選流的描述:
注:假定輸入的銀行卡號是正確的;不考慮備選流內循環(huán)情況。
[問題1](6分)使用場景法設計測試用例,指出所涉及到的基本流和備選流;玖饔米帜窤表示,備選流用題干中描述對應編號表示。
[問題2](5分)請針對問題1設計的測試用例,依次將銀行卡號、初次輸入密碼、最終輸入密碼、卡內余額、銀行卡可支付額度等信息填入下述測試用例表中。表中行代表各個測試用例,列代表測試用例的輸入值,用V表示有效數據元素,I表示無效數據元素,n/a表示不適用,例如C01表示“成功支付” 用例。
[問題3](3分 )在上述系統(tǒng)中,假設銀行卡號只能輸入0~9的數字,請參考下表,給出用邊界值法檢查卡號字符合法性的關鍵測試數據(字符或ASCII值)。
試題四(10分)閱讀下列說明,回答問題1至問題3,將解答填入答題紙的對應欄內。
[說明]邏輯覆蓋是通過對程序邏輯結構的遍歷實現程序的覆蓋,是設計白盒測試用例的主要方法之一。以下代碼由C語言書寫,請按要求回答問題。
void cal( int n )
{
int g, s, b, q;
if ( ( n > 1000 ) && ( n < 2000 ) )
{
g = n % 10;
s = n % 100 / 10;
b = n / 100 % 10;
q = n / 1000;
if( ( q + g ) == ( s + b ) )
{
printf("%-5d", n);
}
}
printf("\n");
return;
}
[問題1](3分 )請找出程序中所有的邏輯判斷語句。
[問題2](4分)請分析并給出分別滿足100%DC(判定覆蓋)和100%CC(條件覆蓋)時所需的邏輯條件。
[問題3](3分)假設n的取值范圍是0 < n < 3000,請用邏輯覆蓋法為n的取值設計測試用例,使用例集滿足基本路徑覆蓋標準。
試題 五(13分)閱讀下列說明,回答問題1至問題3,將解答填入答題紙的對應欄內。
[說明]某企業(yè)信息中心委托系統(tǒng)集成單位開發(fā)了企業(yè)網站,將應用服務器、Web服務器和數據庫服務器都部署在信息中心機房,系統(tǒng)集成工作完成后,集成單位對網段、防火墻、入侵檢測系統(tǒng)、防病毒系統(tǒng)等進行了全面的安全檢查,向信息中心提交了安全測評報告。
信息中心主管認為該測評報告不夠全面,要求盡可能提供系統(tǒng)的、多層次的、深入的安全測評報告。
[問題1] (5分)請簡述系統(tǒng)的安全防護體系包括的層次。
[問題2](4分)對于服務器操作系統(tǒng)的安全,應當從哪些方面進行測評?
[問題3](4分))安全日志是軟件被動防范的措施,是重要的安全功能,軟件的安全日志應當記錄哪些信息?在安全測試中應當檢查安全日志的哪些方面?
試題一
[問題1]
[問題2]
V(G)=6
[問題3]
用例編號 | temp取值 |
1 | >= |
2 | > |
3 | == |
4 | <= |
5 | < |
6 | 除>=、>、==、<=、<之外的字符組合 |
試題二
[問題1]響應時間是系統(tǒng)完成事務執(zhí)行準備后所采集的時間戳和系統(tǒng)完成待執(zhí)行事務后所采集的時間戳之間的時間間隔,是衡量特定類型應用事務性能的重要指標,標志了用戶執(zhí)行一項操作大致需要多長時間。
[問題2]系統(tǒng)能夠承受的并發(fā)用戶登錄的最大數量為50
題中指出"通常情況下,交易操作合理的響應時間為5秒以內"。此案例中,登錄響應時間隨虛擬并發(fā)用戶數增加而增長。在50個虛擬并發(fā)用戶的負載下,登錄響應時間達到5秒(注意圖形中響應時間指標的比例為10)。當負載超過50個虛擬并發(fā)用戶,響應時間超過5秒。所以此案例中最合理的并發(fā)用戶數為50。
[問題3]服務器CPU資源使用率是合理的。
2M帶寬是系統(tǒng)處理業(yè)務的瓶頸。
理由是對比"4M帶寬登錄"案例,4M帶寬下,系統(tǒng)每秒處理完成的登錄個數固定在13.5個左右,登錄響應時間隨虛擬用戶數增加而增長。在60個虛擬用戶的壓力下,登錄響應時間在4.2秒左右(注意圖形中響應時間指標的比例為10)。在80個虛擬用戶的壓力下,登錄響應時間在5.8秒左右,所以在合理登錄響應時間(5秒)內預計同時登錄用戶數是70左右。服務器CPU使用率成為系統(tǒng)處理的瓶頸。說明隨著帶寬的提高,系統(tǒng)的處理能力進一步提高,同時高吞吐量造成了系統(tǒng)資源的緊張,帶來了新的系統(tǒng)性能瓶頸。
[問題4]服務器CPU資源使用率不合理,其平均值超過85%。
4M帶寬的網絡測試環(huán)境與2M帶寬的網絡測試環(huán)境相比,帶來了新的系統(tǒng)瓶頸(CPU資源使用率平均值超過85%),所以增加帶寬不是提高系統(tǒng)性能的有效方法。在此基礎上,繼續(xù)提高帶寬,系統(tǒng)的處理能力將進一步提高,高的處理能力會使服務器的資源瓶頸進一步加重,帶來更加嚴重的后果。
[問題5]當CPU資源使用成為系統(tǒng)瓶頸時的解決方案可以概括為:
1. 增加CPU的個數;
2. 提高CPU的主頻;
3. 將web服務器與數據庫服務器分開部署;
4. 調整軟件的設計與開發(fā);
當帶寬成為系統(tǒng)瓶頸時的解決方案可以概括為:
1. 增加帶寬;
2. 壓縮傳輸數據。
試題三
[問題1]
場景1:A
場景2:A、B
場景3:A、C
場景4:A、D
場景5:A、E
測試用例ID號 | 場景 | 帳號 | 是否黑名單卡 | 輸入油量 | 帳面金額 | 加油機油黑 | 預期結果 |
C02. | 場景2:卡無效 | 1 | n/a | n/a | n/a | n/a | 退卡 |
C03. | 場景3:黑名單卡 | V | V | n/a | n/a | n/a | 吞卡 |
C04. | 場景4:金額不足 | V | I | V | I | V | 提示錯誤,重新輸入加油量 |
C05. | 場景5:油量不足 | V | I | V | V | I | 提示錯誤,重新輸入加油量 |
[問題3]
1. 0升
2. 250升
3. 251升
[問題4]
DDP=Bugstester(Bugstester+ Bugscustomer)=(20+100)(20+100+30)=80%(0.8)
其中,Bugstester為測試者發(fā)現的錯誤數;
Bugscustomer為客戶發(fā)現并反饋技術支持人員進行修復的錯誤數。
試題四
[問題1]
評估安裝手冊
安裝的自動化測試
安裝選項和設置的測試
安裝過程的中斷測試
安裝順序測試
多環(huán)境安裝測試
安裝正確性測試
修復安裝與卸載測試
[問題2]
界面整體測試:規(guī)范性測試、合理性測試、一致性測試和界面定制性測試
界面元素測試:窗口測試、菜單測試、圖標測試、鼠標測試和文字測試。
[問題3]
文本的準確性
與程序的接口
幫助索引的檢查
超鏈接的正確性
鏈接的意義
風格應簡潔
試題五
[問題1]
單元測試
集成測試
確認測試(系統(tǒng)測試)
驗收測試
[問題2]
知識點包括:
軟件測試過程的關鍵活動:
測試需求分析
制定測試計劃
測試設計
測試執(zhí)行
測試分析與總結
質量保證手段:
制定質量保證計劃、質量體系建立
測試活動審核、測試文檔評審
測試過程數據的收集、度量與分析
相關推薦:
北京 | 天津 | 上海 | 江蘇 | 山東 |
安徽 | 浙江 | 江西 | 福建 | 深圳 |
廣東 | 河北 | 湖南 | 廣西 | 河南 |
海南 | 湖北 | 四川 | 重慶 | 云南 |
貴州 | 西藏 | 新疆 | 陜西 | 山西 |
寧夏 | 甘肅 | 青海 | 遼寧 | 吉林 |
黑龍江 | 內蒙古 |