- 相關(guān)推薦
軟件測試試題庫
一、單選題（2分/題，共30分）
二、多選題（1分/題，共10分）
三、名字解釋題（3分/題，共9個(gè)）
試題一 (http://xiaolifang84.blog.163.com/blog/#m=0)
一、判斷正誤題
1. 測試是調(diào)試的一個(gè)部分 （ ╳ ）
2. 軟件測試的目的是盡可能多的找出軟件的缺陷。（ √ ）
3. 程序中隱藏錯(cuò)誤的概率與其已發(fā)現(xiàn)的錯(cuò)誤數(shù)成正比（ √ ）
4. Beta 測試是驗(yàn)收測試的一種。 （ √ ）
5. 測試人員要堅(jiān)持原則，缺陷未修復(fù)完堅(jiān)決不予通過。（ √ ）
6. 項(xiàng)目立項(xiàng)前測試人員不需要提交任何工件。（ ╳ ）
7. 單元測試能發(fā)現(xiàn)約80%的軟件缺陷。（ √ ）
8. 測試的目的是發(fā)現(xiàn)軟件中的錯(cuò)誤。（ √ ）
9. 代碼評(píng)審是檢查源代碼是否達(dá)到模塊設(shè)計(jì)的要求。（ √ ）
10. 自底向上集成需要測試員編寫驅(qū)動(dòng)程序。（ √ ）
二、選擇題
1、實(shí)施缺陷跟蹤的目的是：（ ABCD ）
A、軟件質(zhì)量無法控制 B、問題無法量化 C、重復(fù)問題接連產(chǎn)生
D、解決問題的知識(shí)無法保留 E、確保缺陷得到解決
F、使問題形成完整的閉環(huán)處理
2、使用軟件測試工具的目的：（ ABCDF ）
A、幫助測試尋找問題 B、協(xié)助問題的診斷 C、節(jié)省測試時(shí)間
D、提高Bug的發(fā)現(xiàn)率 E、更好的控制缺陷提高軟件質(zhì)量
F、更好的協(xié)助開發(fā)人員
3、編寫測試計(jì)劃的目的是：（ ABC ）
A、使測試工作順利進(jìn)行 B、使項(xiàng)目參與人員溝通更舒暢
C、使測試工作更加系統(tǒng)化 D、軟件工程以及軟件過程的需要
E、軟件過程規(guī)范化的要求 F、控制軟件質(zhì)量
4、選出屬于黑盒測試方法的選項(xiàng)（ B ）
A、測試用例覆蓋 B、輸入覆蓋 C、輸出覆蓋
D、分支覆蓋 E、語句覆蓋 F、條件覆蓋
5、以測試的形態(tài)分測試可以分為：（ ABC ）
A、建構(gòu)性測試 B、系統(tǒng)測試 C、專項(xiàng)測試
D、單元測試 E、組件測試 F、集成測試
6、進(jìn)行軟件質(zhì)量管理的重要性有：（ ）
A、維護(hù)降低成本 B、法律上的要求 C、市場競爭的需要
D、質(zhì)量標(biāo)準(zhǔn)化的趨勢 E、軟件工程的需要 F、CMM過程的一部分
G、方便與客戶進(jìn)一步溝通為后期的實(shí)施打好基礎(chǔ)
7、在GB/T17544中，軟件包質(zhì)量要求包括三部分，即產(chǎn)品描述要求、(
據(jù)要求。
A．用戶文檔要求 B．系統(tǒng)功能要求
C．設(shè)計(jì)要求說明 D．軟件配置要求
8、典型的瀑布模型的四個(gè)階段是：（ ABCD ）
A )、程 序和數(shù)
A、分析 B、設(shè)計(jì) C、編碼
D、測試 E、需求調(diào)研 F、實(shí)施
9、( )可以作為軟件測試結(jié)束的標(biāo)志。
A．使用了特定的測試用例 B．錯(cuò)誤強(qiáng)度曲線下降到預(yù)定的水平
C．查出了預(yù)定數(shù)目的錯(cuò)誤 D．按照測試計(jì)劃中所規(guī)定的時(shí)間進(jìn)行了測試
10、導(dǎo)致軟件缺陷的原因有很多，A—D是可能的原因，其中最主要的原因包括( ABCD )。
A．軟件需求說明書編寫的不全面，不完整，不準(zhǔn)確，而且經(jīng)常更改
B．軟件設(shè)計(jì)說明書
C．軟件操作人員的水平
D．開發(fā)人員不能很好的理解需求說明書和溝通不足
三、名詞解釋
1. Beta測試：Beta測試是從用戶角度進(jìn)行的測試，是由軟件的多個(gè)用戶在一個(gè)或多個(gè)用戶的實(shí)際使用環(huán)境下進(jìn)行的測試。它是在開發(fā)者無法控制的軟件環(huán)境下進(jìn)行的軟件現(xiàn)場應(yīng)用。
2. 負(fù)載測試：負(fù)載測試是一個(gè)通過分析軟件應(yīng)用程序和支撐架構(gòu)，模擬真實(shí)環(huán)境的使用，來確定能夠接受的性能的過程。
3. 軟件測試活動(dòng)生命周期：是指軟件從進(jìn)入測試到退出測試的過程中，所要經(jīng)歷的引入程序錯(cuò)誤、通過測試發(fā)現(xiàn)錯(cuò)誤和清除程序錯(cuò)誤的幾個(gè)階段。
4. 改進(jìn)的三明治集成：利用較高的并行度彌補(bǔ)三明治集成中不能充分測試中間層的缺點(diǎn)。但根據(jù)中間層選擇是否恰當(dāng)，可能增加驅(qū)動(dòng)模塊和樁模塊設(shè)計(jì)的工作量。
5. 驅(qū)動(dòng)模塊相當(dāng)于所測模塊的主程序。它接收測試數(shù)據(jù)，把這些數(shù)據(jù)傳送給所測模塊，最后再輸出實(shí)際測試結(jié)果。
四、簡答題
軟件的缺陷等級(jí)應(yīng)如何劃分？
致命的：致命的錯(cuò)誤，造成系統(tǒng)或應(yīng)用程序崩潰、死機(jī)、系統(tǒng)懸掛，或造成數(shù)據(jù)丟失、主要功能完全喪失等。
嚴(yán)重的：嚴(yán)重錯(cuò)誤，指功能或特性沒有實(shí)現(xiàn)，主要功能部分喪失，次要功能完全喪失，或致命的錯(cuò)誤聲明。
一般的：不太嚴(yán)重的錯(cuò)誤，這樣的軟件缺陷雖然不影響系統(tǒng)的基本使用，但沒有很好地實(shí)現(xiàn)功能，沒有達(dá)到預(yù)期效果。如次要功能喪失，提示信息不太準(zhǔn)確，或用戶界面差，操作時(shí)間長等。
微小的：一些小問題，對(duì)功能幾乎沒有影響，產(chǎn)品及屬性仍可使用，如有個(gè)別錯(cuò)別字、文字排列不整齊等。
階段評(píng)審與同行評(píng)審。
同行評(píng)審是一種重要而有效的工程方法，在軟件產(chǎn)品工程中調(diào)用此方法，可通過法根式審查、結(jié)構(gòu)化走查或者一些其他的學(xué)院式的評(píng)審方法加以實(shí)施。其目的是及早和高效地去除軟件工作中的缺陷，必然結(jié)果是增強(qiáng)對(duì)軟件工作產(chǎn)品和可預(yù)防缺陷的了解。
階段評(píng)審是利用在需求分析階段所選擇并制定的標(biāo)準(zhǔn)、規(guī)范以及計(jì)劃的安排，對(duì)軟件工程各階段的進(jìn)展、完成質(zhì)量及出現(xiàn)的問題進(jìn)行正式評(píng)審，確保過程計(jì)劃并遵守標(biāo)準(zhǔn)和規(guī)范執(zhí)行，然后形成報(bào)告。當(dāng)發(fā)現(xiàn)問題是，要準(zhǔn)尋逐級(jí)解決的原則，將處理結(jié)果通知相關(guān)人員，記錄解決過程及結(jié)果以作日后改進(jìn)重要參考資料。
兩者都是有關(guān)軟件質(zhì)量管理和保證的重要內(nèi)容，二者相輔相成，缺一不可。
安全性測試屬于軟件測試的哪個(gè)階段？并試闡述安全測試的概念和用以評(píng)判系統(tǒng)安全性性能的主要指標(biāo)。
是系統(tǒng)測試的一種類型，
安全性測試就是要驗(yàn)證系統(tǒng)內(nèi)的保護(hù)機(jī)制能否抵御入侵者的攻擊。安全性測試的測試人員需要在測試活動(dòng)中，撒氣不同的入侵方式來攻擊系統(tǒng)的安全機(jī)制，想盡一切辦法來獲取系統(tǒng)內(nèi)的保密信息。
系統(tǒng)安全性性能的指標(biāo)：有效性：啟動(dòng)嚴(yán)格的安全性性能所花費(fèi)的時(shí)間占啟動(dòng)整個(gè)系統(tǒng)所花費(fèi)時(shí)間的比例。生存性：當(dāng)錯(cuò)誤發(fā)生時(shí)，系統(tǒng)對(duì)緊急操作的支持，對(duì)錯(cuò)誤的補(bǔ)救措施以及恢復(fù)到正常操作的能力，即系統(tǒng)的抗挫能力。精確性：衡量系統(tǒng)安全性控制的精度指標(biāo)，圍繞所出現(xiàn)的錯(cuò)誤數(shù)量、發(fā)生頻率及其嚴(yán)重性判斷。反應(yīng)時(shí)間：出錯(cuò)時(shí)系統(tǒng)響應(yīng)速度的快慢，一個(gè)安全性較強(qiáng)的系統(tǒng)要具備快速的反應(yīng)速度。吞吐量：用戶和服務(wù)請(qǐng)求的峰值和平均值。 單元測試策略主要有哪些？并試描述這些策略？
單元測試策略主要有三種方式：
1.自頂向下的單元測試策略：從頂層調(diào)用的單元做成樁模塊；對(duì)第二層測試，使用上面已測試的單元做驅(qū)動(dòng)模塊；依次類推，直到全部單元測試結(jié)束。
2.自底向上的單元測試策略：先對(duì)模塊調(diào)用的最底層模塊進(jìn)行測試，模擬調(diào)用該模塊的模塊為驅(qū)動(dòng)模塊；其次，對(duì)上一層模塊進(jìn)行單元測試，用已經(jīng)被測試過的模塊做樁模塊，依次類推，直到全部單元測試結(jié)束。
3.孤立測試的單元測試策略：無需考慮每個(gè)模塊與其他模塊之間的關(guān)系，分別為每個(gè)模塊單獨(dú)設(shè)計(jì)樁模塊和驅(qū)動(dòng)模塊，逐一完成所有單元模塊的測試。
測試結(jié)束的標(biāo)準(zhǔn)是什么？
試題二
一、判斷正誤題（每小題1分，共10分）
1. 測試是證明軟件正確的方法。（ ╳ ）
2. 負(fù)載測試是驗(yàn)證要檢驗(yàn)的系統(tǒng)的能力最高能達(dá)到什么程度。（ √ ）
3. 測試中應(yīng)該對(duì)有效和無效、期望和不期望的輸入都要測試。（ √ ）
4. 對(duì)于連鎖型分支結(jié)構(gòu)，若有n個(gè)判定語句，則有2n條路徑。（√ ）
5. 驗(yàn)收測試是由最終用戶來實(shí)施的。（ √ ）
6. GOTO語句概念簡單，使用方便，在某些情況下，保留GOTO語句反能使寫出的程序更加簡潔。（ √ ）
7. 測試人員要堅(jiān)持原則，缺陷未修復(fù)完堅(jiān)決不予通過。（ √ ）
8. 黑盒測試也稱為結(jié)構(gòu)測試。（ ╳ ）
9. 代碼評(píng)審員一般由測試員擔(dān)任。（ ╳ ）
10. 集成測試計(jì)劃在需求分析階段末提交。（ ╳ ）
二、不定項(xiàng)選擇題（每題可能有一個(gè)或多個(gè)選項(xiàng)應(yīng)選，每題2分，共20分。多選不得分，少選僅得１分。）
1．軟件驗(yàn)收測試的合格通過準(zhǔn)則是：（ AD ）
A． 軟件需求分析說明書中定義的所有功能已全部實(shí)現(xiàn)，性能指標(biāo)全部達(dá)到要求。
B． 所有測試項(xiàng)沒有殘余一級(jí)、二級(jí)和三級(jí)錯(cuò)誤。
C． 立項(xiàng)審批表、需求分析文檔、設(shè)計(jì)文檔和編碼實(shí)現(xiàn)一致。
D． 驗(yàn)收測試工件齊全。
2．軟件測試計(jì)劃評(píng)審會(huì)需要哪些人員參加？（ ABCD ）
A．項(xiàng)目經(jīng)理
B．SQA 負(fù)責(zé)人
C．配置負(fù)責(zé)人
D．測試組
3．下列關(guān)于alpha 測試的描述中正確的是：（ A D ）
A．a(chǎn)lpha 測試需要用戶代表參加
B．a(chǎn)lpha 測試不需要用戶代表參加
C．a(chǎn)lpha 測試是系統(tǒng)測試的一種
D．a(chǎn)lpha 測試是驗(yàn)收測試的一種
4．測試設(shè)計(jì)員的職責(zé)有：（ BC ）
A．制定測試計(jì)劃
B．設(shè)計(jì)測試用例
C．設(shè)計(jì)測試過程、腳本
D．評(píng)估測試活動(dòng)
5．軟件實(shí)施活動(dòng)的進(jìn)入準(zhǔn)則是：（ ABC ）
A．需求工件已經(jīng)被基線化
B．詳細(xì)設(shè)計(jì)工件已經(jīng)被基線化
C．構(gòu)架工件已經(jīng)被基線化
D．項(xiàng)目階段成果已經(jīng)被基線化
6、典型的瀑布模型的四個(gè)階段是：（ ABCD ）
A、分析 B、設(shè)計(jì) C、編碼
D、測試 E、需求調(diào)研 F、實(shí)施
7． 下面的哪一項(xiàng)測試步驟中需要進(jìn)行局部數(shù)據(jù)結(jié)構(gòu)測試： （ A ）
A、單元測試
B、集成測試
C、確認(rèn)測試
D、系統(tǒng)測試
8． 從是否需要執(zhí)行被測軟件的角度，軟件測試技術(shù)可劃分的類型是：（AC ）。
A、 靜態(tài)測試
B、 黑盒測試
C、 動(dòng)態(tài)測試
D、 白盒測試
9． 從測試階段角度，測試結(jié)束的正確順序是：（ B ）
A、 單元測試、集成測試、系統(tǒng)測試、確認(rèn)測試
B、 單元測試、系統(tǒng)測試、集成測試、確認(rèn)測試
C、 確認(rèn)測試、集成測試、系統(tǒng)測試、單元測試
D、 確認(rèn)測試、系統(tǒng)測試、集成測試、單元測試
10．軟件的六大質(zhì)量特性包括： （ A ）
A. 功能性、可靠性、可用性、效率、可維護(hù)、可移植
B. 功能性、可靠性、可用性、效率、穩(wěn)定性、可移植
C. 功能性、可靠性、可擴(kuò)展性、效率、穩(wěn)定性、可移植
D. 功能性、可靠性、兼容性、效率、穩(wěn)定性、可移植
1. 什么是軟件測試
2. 試述軟件測試活動(dòng)的生命周期？
3. 集成測試策略主要有哪些？并試描述３個(gè)以上的具體策略？
答：1、大爆炸集成（P153）：屬于非增值式集成的一種方法，也稱為一次性組裝或整體拼裝。這種集成策略的做法就是把所有通過單元測試的模塊一次性集成到一起進(jìn)行測試，不考
慮組件之間的互相依賴性及可能存在的風(fēng)險(xiǎn)。2、三明治集成（P158）：一種混合增量式測試策略，綜合了自頂向下和自底向上兩種集成方法的優(yōu)點(diǎn)，因此也屬于基于功能分解的集成。這種方法樁和開發(fā)工作都比較小，但增加了定位缺陷的難度。3、自頂向下集成：就是按照系統(tǒng)層次結(jié)構(gòu)圖，以主程序模塊為中心，自上而下按照深度優(yōu)先或者廣度優(yōu)先策略，對(duì)各個(gè)模塊一邊組裝一邊進(jìn)行測試。又可分為深度優(yōu)先集成和廣度優(yōu)先集成兩種方式。4、自底向上集成：從依賴性最小的底層模塊開始，按照層次結(jié)構(gòu)圖，逐層向上集成，驗(yàn)證系統(tǒng)的穩(wěn)定性。5、高頻集成：高頻集成測試是指同步于軟件開發(fā)過程，每隔一段時(shí)間對(duì)開發(fā)團(tuán)隊(duì)的現(xiàn)有代碼進(jìn)行一次集成測試。6、分層集成、分布式集成、基于路徑、功能、進(jìn)度、風(fēng)險(xiǎn)、事件、使用等的集成等13種。
4. 恢復(fù)性測試屬于軟件測試的哪個(gè)階段？并試闡述恢復(fù)性測試的概念和進(jìn)行恢復(fù)性測試分析時(shí)主要應(yīng)考慮的問題。
答：恢復(fù)性測試使系統(tǒng)測試階段的一種方法，也叫容錯(cuò)測試，用來檢查系統(tǒng)的容錯(cuò)能力。通常若計(jì)算機(jī)系統(tǒng)出現(xiàn)錯(cuò)誤，就必須在一定時(shí)間內(nèi)從錯(cuò)誤中恢復(fù)過來，修正錯(cuò)誤并重新啟動(dòng)系統(tǒng)。在進(jìn)行恢復(fù)性測試時(shí)，要考慮的主要問題有：恢復(fù)期間的安全性過程�；謴�(fù)處理日志方面的能力。當(dāng)出現(xiàn)供電問題時(shí)的恢復(fù)能力�；謴�(fù)操作后系統(tǒng)性能是否下降。 常用的恢復(fù)測試用例的設(shè)計(jì)方法：規(guī)范導(dǎo)出法、錯(cuò)誤猜測法、基于故障的測試。
5. 請(qǐng)簡述單元測試進(jìn)入的準(zhǔn)則？
答：包括要素和判斷準(zhǔn)則：要素是詳細(xì)說明書和單元測試用例，判斷準(zhǔn)則是經(jīng)過審查=獲得批準(zhǔn)和進(jìn)入配置庫。
試題三：
一、判斷題（每題1分，12 分，正確的√，錯(cuò)誤的╳）
1．軟件測試的目的是盡可能多的找出軟件的缺陷。（）
軟件測試的目的就是為了發(fā)現(xiàn)軟件中的缺陷，從這個(gè)意義上面說上面的這個(gè)論斷是正確的。不少人會(huì)認(rèn)為軟件測試可以保證軟件的質(zhì)量，其實(shí)這個(gè)觀點(diǎn)是錯(cuò)誤，測試只是軟件質(zhì)量控制中的一個(gè)角色，其活動(dòng)并不能達(dá)成軟件質(zhì)量保證的效果。所以不要認(rèn)為一個(gè)公司里面如果有了軟件測試人員，產(chǎn)品的質(zhì)量就會(huì)好起來。
2．Beta 測試是驗(yàn)收測試的一種。（╳）
Beat測試和驗(yàn)收測試是兩種不同的測試。驗(yàn)收測試的目的是為了以發(fā)現(xiàn)”未實(shí)現(xiàn)的需求”為目的，以評(píng)估”適合使用”為目標(biāo)，該類測試的不是以發(fā)現(xiàn)缺陷為主要目的。beta測試是一模擬真實(shí)的使用環(huán)境從而發(fā)現(xiàn)缺陷的一種測試。所以兩者之間的是非包容關(guān)系。
3．驗(yàn)收測試是由最終用戶來實(shí)施的。（）
上面說到了驗(yàn)收測試的目的和目標(biāo)，所以驗(yàn)收測試也可是是軟件生產(chǎn)的企業(yè)內(nèi)部人員來實(shí)施。例如產(chǎn)品經(jīng)理。當(dāng)軟件以項(xiàng)目的形式出現(xiàn)，那么驗(yàn)收測試由最終用戶來實(shí)施的情況是比較長見的。但是對(duì)于產(chǎn)品形式的軟件，生產(chǎn)企業(yè)內(nèi)部的驗(yàn)收測試會(huì)更多。
4．項(xiàng)目立項(xiàng)前測試人員不需要提交任何工件。（）
應(yīng)該說這道題目沒有明確的答案，在項(xiàng)目立項(xiàng)前測試人員是不是要把一些準(zhǔn)備工作以工件的形式給記錄下來是完全取決于該企業(yè)的軟件開發(fā)過程的要求。同時(shí)不同企業(yè)，立項(xiàng)前要達(dá)成的一些必要條件也是大相徑庭的。應(yīng)該說這一題目出的不是很好，如果你是出題人這家企業(yè)的測試工程師，那么就應(yīng)該有一個(gè)明確的答案。
5．單元測試能發(fā)現(xiàn)約80%的軟件缺陷。（）
同樣這一題目也沒有標(biāo)準(zhǔn)答案。因?yàn)樵摂?shù)據(jù)的來源和其統(tǒng)計(jì)的方法，樣本都沒有一個(gè)工業(yè)標(biāo)準(zhǔn)。這樣出來的數(shù)據(jù)同樣不具有權(quán)威性。這里我可以說一個(gè)簡單的例子，在用ASP,php這類
腳本語言開發(fā)網(wǎng)頁的時(shí)候是根本沒有復(fù)雜的單元測試。那么這樣的數(shù)字應(yīng)用在網(wǎng)站開發(fā)上面是否有意義，還是值得商榷的。所以這道題目出的不好，沒有明確的答案
6．代碼評(píng)審是檢查源代碼是否達(dá)到模塊設(shè)計(jì)的要求。（）
代碼審查是一種靜態(tài)技術(shù)，從這個(gè)意義上說代碼復(fù)查是需要和其他的一些動(dòng)態(tài)測試技術(shù)配合才能檢查代碼是否符合設(shè)計(jì)的要求
7．自底向上集成需要測試員編寫驅(qū)動(dòng)程序。（）
這道題目大家看下top-down 和 down-top的集成測試示意圖就能得出明確的答案。這里需要了解的是什么是驅(qū)動(dòng)測試程序，什么是樁程序。如果集成組件數(shù)量眾多，多關(guān)系層次，那么不論是什么類型的集成測試。驅(qū)動(dòng)程序和樁程序都是需要開發(fā)的。
8．負(fù)載測試是驗(yàn)證要檢驗(yàn)的系統(tǒng)的能力最高能達(dá)到什么程度。（）
關(guān)于負(fù)載測試和壓力測試在論壇中的帖子中有詳細(xì)的解釋，大家可以去看一下就能得出正確的答案
9．測試人員要堅(jiān)持原則，缺陷未修復(fù)完堅(jiān)決不予通過。（）
同樣，這一題沒有正確的答案。缺陷是否修復(fù)是需要聽取測試人員的意見，但測試人員的意見非決定性。所以還是要看一個(gè)企業(yè)賦予測試人員有多大的權(quán)力。
10．代碼評(píng)審員一般由測試員擔(dān)任。（）
如果測試員有這個(gè)水平，那么當(dāng)然是可以參加的。不過大多數(shù)的企業(yè)不會(huì)讓普通的測試人員參與代碼的評(píng)審。
11．我們可以人為的使得軟件不存在配置問題。（）
首先大家先搞清楚什么是配置管理什么是軟件配置，從這道題目中看不出出題人想問的是關(guān)鍵工程中的配置管理還是單純的軟件配置。但是可以肯定的是不論是何種情況，答案均是否定的。
12．集成測試計(jì)劃在需求分析階段末提交。（）
集成測試計(jì)劃在開發(fā)人員完成軟件集成計(jì)劃之后就可以開始進(jìn)行了。所以在需求分析階段之后提交是不現(xiàn)實(shí)的事情，應(yīng)該在軟件的設(shè)計(jì)階段后，編碼前。
二、不定項(xiàng)選擇題（每題2 分，10分）
1．軟件驗(yàn)收測試的合格通過準(zhǔn)則是：（）
A． 軟件需求分析說明書中定義的所有功能已全部實(shí)現(xiàn)，性能指標(biāo)全部達(dá)到要求。
B． 所有測試項(xiàng)沒有殘余一級(jí)、二級(jí)和三級(jí)錯(cuò)誤。
C． 立項(xiàng)審批表、需求分析文檔、設(shè)計(jì)文檔和編碼實(shí)現(xiàn)一致。
D． 驗(yàn)收測試工件齊全。
回答這道題，你必須是這家企業(yè)的員工。前面說到了驗(yàn)收測試的目的和目標(biāo)，一個(gè)是需求必須實(shí)現(xiàn)，二是證明軟件是適合使用的。這樣能滿足這兩個(gè)通用標(biāo)準(zhǔn)就可以了。當(dāng)然有些軟件企業(yè)會(huì)對(duì)驗(yàn)收測試標(biāo)準(zhǔn)做一些調(diào)整。
2．軟件測試計(jì)劃評(píng)審會(huì)需要哪些人員參加？（）
A．項(xiàng)目經(jīng)理
B．SQA 負(fù)責(zé)人
C．配置負(fù)責(zé)人
D．測試組
上面的4種角色都需要參與
3．下列關(guān)于alpha 測試的描述中正確的是：（）
A．a(chǎn)lpha 測試需要用戶代表參加
B．a(chǎn)lpha 測試不需要用戶代表參加
C．a(chǎn)lpha 測試是系統(tǒng)測試的一種
D．a(chǎn)lpha 測試是驗(yàn)收測試的一種
首先大家需要知道alpha測試是系統(tǒng)級(jí)別的測試，該測試是在一個(gè)受控的環(huán)境中進(jìn)行的。用戶需要直接參與進(jìn)來。所以答案應(yīng)該是AD
4．測試設(shè)計(jì)員的職責(zé)有：（）
A．制定測試計(jì)劃
B．設(shè)計(jì)測試用例
C．設(shè)計(jì)測試過程、腳本
D．評(píng)估測試活動(dòng)
合理的答案的是BC，同時(shí)要看軟件企業(yè)對(duì)該類人員的職責(zé)是如何定義。
5．軟件實(shí)施活動(dòng)的進(jìn)入準(zhǔn)則是：（）
A．需求工件已經(jīng)被基線化
B．詳細(xì)設(shè)計(jì)工件已經(jīng)被基線化
C．構(gòu)架工件已經(jīng)被基線化
D．項(xiàng)目階段成果已經(jīng)被基線化
先要了解一下什么是基線。這個(gè)是軟件配置管理中一個(gè)重要的概念。工作產(chǎn)品必須納入到一定的基線里面。所以選擇ABC是必定的，至于是否選擇D要看這家企業(yè)自身的標(biāo)準(zhǔn)了 填空題（每空1分，24 分）
1．軟件驗(yàn)收測試包括___、___、____三種類型。
軟件驗(yàn)收測試包括正式驗(yàn)收測試、alpha測試、beta測試三種測試。
2．系統(tǒng)測試的策略有功能測試、、、、易用性測試、、、、、、、、
、、等15 種方法。
系統(tǒng)測試的策略有很多種的，我知道的有性能測試、負(fù)載測試、強(qiáng)度測試、易用性測試、安全測試、配置測試、安裝測試、文檔測試、故障恢復(fù)測試、用戶界面測試、恢復(fù)測試、分布測試、可用性測試。。。
3．設(shè)計(jì)系統(tǒng)測試計(jì)劃需要參考的項(xiàng)目文檔有、和迭代計(jì)劃。
設(shè)計(jì)系統(tǒng)測試計(jì)劃需要參考的項(xiàng)目文檔有軟件測試計(jì)劃、軟件需求工件、和迭代計(jì)劃。
4．對(duì)面向過程的系統(tǒng)采用的集成策略有___、___兩種。
5．通過畫因果圖來寫測試用例的步驟為___、___、___、___及把因果圖轉(zhuǎn)換為狀態(tài)圖共五個(gè)步驟。
利用因果圖生成測試用例的基本步驟是：
§ 分析軟件規(guī)格說明描述中，哪些是原因（即輸入條件或輸入條件的等價(jià)類），哪些是結(jié)果（即輸出條件），并給每個(gè)原因和結(jié)果賦予一個(gè)標(biāo)識(shí)符。
§ 分析軟件規(guī)格說明描述中的語義，找出原因與結(jié)果之間，原因與原因之間對(duì)應(yīng)的是什么關(guān)系? 根據(jù)這些關(guān)系，畫出因果圖。
§ 由于語法或環(huán)境限制，有些原因與原因之間，原因與結(jié)果之間的組合情況不可能出現(xiàn)。為表明這些特殊情況，在因果圖上用一些記號(hào)標(biāo)明約束或限制條件。
§ 把因果圖轉(zhuǎn)換成判定表。
§ 把判定表的每一列拿出來作為依據(jù)，設(shè)計(jì)測試用例。
重點(diǎn)復(fù)習(xí)
軟件測試技術(shù)*重點(diǎn)復(fù)習(xí)（帶測試案例分析題）
一、 判斷題（10分）
? 負(fù)載測試（P189）：
負(fù)載測試是一個(gè)通過分析軟件應(yīng)用程序和支撐架構(gòu)，模擬真實(shí)環(huán)境的使用，來確定能夠接受的性能的過程。
負(fù)載測試的目標(biāo)是：確定在各種工作負(fù)載下系統(tǒng)的性能，主要是測試當(dāng)負(fù)載逐漸增加時(shí)，系統(tǒng)組成部分的相應(yīng)輸出項(xiàng)（如通過量、響應(yīng)時(shí)間、CPU負(fù)載、內(nèi)在的使用等）來決定系統(tǒng)的性能。
? 判定語句：
? 路徑：
? 驗(yàn)收測試（P200）：
驗(yàn)收測試是將程序與其最初的需求及最終用戶當(dāng)前的需要進(jìn)行比較的過程。 驗(yàn)收測試是軟件產(chǎn)品質(zhì)量的最后一關(guān)。測試主要從用戶角度著手。
參與者主要是用戶和少量的程序開發(fā)人員。
? 黑盒測試：
（亦功能測試、行為測試、數(shù)據(jù)驅(qū)動(dòng)測試、基于規(guī)格說明的測試）
是一種從用戶觀點(diǎn)出發(fā)的測試。這種方法把程序當(dāng)作一個(gè)黑盒，忽略其內(nèi)部結(jié)構(gòu)特性。測試者只知道輸入與輸出之間的關(guān)系或程序功能，依靠程序功能需求說明書，確定測試用例和推斷測試結(jié)果的正確性。測試用例的設(shè)計(jì)基于產(chǎn)品的功能、目的是檢查程序各個(gè)功能是否實(shí)現(xiàn)，并檢查其中的功能錯(cuò)誤。
黑盒測試所要發(fā)現(xiàn)的外部行為錯(cuò)誤：
1) 功能不正確或不完整;
2) 接口錯(cuò)誤;
3) 接口所使用的數(shù)據(jù)結(jié)構(gòu)錯(cuò)誤;
4) 行為或性能錯(cuò)誤;
5) 初始化和終止錯(cuò)誤;
? 代碼評(píng)審員：
? 集成測試：
集成測試（是對(duì)已測試過的模塊進(jìn)行組裝）就是對(duì)集成到一起的軟件組件和硬件組件進(jìn)行的測試，用于評(píng)估這些組件之間能否進(jìn)行正確的交互。
目的主要是：檢驗(yàn)與軟件設(shè)計(jì)相關(guān)的程序結(jié)構(gòu)問題、檢查各種組件之間的接口。 集成測試的完成方法：黑盒測試。
? β測試：
Beta測試是從用戶角度進(jìn)行的測試，是由軟件的多個(gè)用戶在一個(gè)或多個(gè)用戶的實(shí)際使用環(huán)境下進(jìn)行的測試。它是在開發(fā)者無法控制的軟件環(huán)境下進(jìn)行的軟件現(xiàn)場應(yīng)用。 兩種不同的途徑：公共β測試和私有β測試。
二、 不定項(xiàng)選擇題（20分）
? 驗(yàn)收測試通過的準(zhǔn)則：
? 跟蹤缺陷的定義：
? 軟件測試工具的使用（目的是什么）：
A、幫助測試尋找問題
B、協(xié)助問題的診斷
C、節(jié)省測試時(shí)間
? 軟件測試評(píng)審會(huì)的組成人員：
? 測試計(jì)劃的目的：
A. 使測試工作順利進(jìn)行
B. 使項(xiàng)目參與人員溝通更舒暢
C. 使測試工作更加系統(tǒng)化
? α測試是什么：
Alpha測試是由選定的用戶在可控的環(huán)境下進(jìn)行的產(chǎn)品早期性測試。
在此測試中，確定并記錄要研究的功能和業(yè)務(wù)任務(wù)，但沒有可以遵循的特定測試用例。測試內(nèi)容由各測試員決定。這種驗(yàn)收測試方法不像正式驗(yàn)收測試那樣組織有序，而且更為主觀。大多數(shù)情況下，非正式驗(yàn)收測試是由最終用戶組織執(zhí)行的。
? 黑盒測試具體有哪些方法：
1) 邊界值分析法
2) 等價(jià)類劃分法
3) 因果圖法
4) 決策表法
5) 功能圖分析法
6) 錯(cuò)誤推測法
7) 判定表驅(qū)動(dòng)分析法
8) 正交試驗(yàn)設(shè)計(jì)法
9) 狀態(tài)轉(zhuǎn)換測試
10) 分支測試
? 測試設(shè)計(jì)人員的職責(zé)：
1) 確定并描述相應(yīng)的測試技術(shù)。
2) 確定相應(yīng)的測試支持工具
3) 定義并維護(hù)測試自動(dòng)化架構(gòu)。
4) 詳述和驗(yàn)證需要的測試環(huán)境配置。
5) 驗(yàn)證與評(píng)估測試途徑
? 測試按形態(tài)怎么分類：
A. 建構(gòu)性測試
B. 系統(tǒng)測試
C. 專項(xiàng)測試
? 瀑布模型的階段：
A. 分析
B. 設(shè)計(jì)
C. 編碼
D. 測試
? 軟件質(zhì)量包括的內(nèi)容：
1) 軟件產(chǎn)品的質(zhì)量，即滿足使用要求的程度。
2) 軟件開發(fā)過程的質(zhì)量，即能否滿足開發(fā)所帶來的成本、時(shí)間和風(fēng)險(xiǎn)等要求。
3) 軟件在其商業(yè)環(huán)境中所表現(xiàn)的質(zhì)量。
? 什么叫局部數(shù)據(jù)結(jié)構(gòu)測試：
局部數(shù)據(jù)結(jié)構(gòu)測試：設(shè)計(jì)測試用例檢查數(shù)據(jù)類型說明、初始化、默認(rèn)值等方面的問題，還要查清全程數(shù)據(jù)對(duì)模塊的影響。
? 軟件測試結(jié)束的標(biāo)志是什么：
? 測試的階段有哪些：
1) 需求規(guī)格說明、設(shè)計(jì)、編碼階段為引入程序錯(cuò)誤階段;
2) 測試階段為發(fā)現(xiàn)錯(cuò)誤階段;
3) 缺陷分類、缺陷分離、缺陷排除階段為清除程序錯(cuò)誤階段;
? 導(dǎo)致軟件缺陷的原因：
1) 技術(shù)問題
2) 算法錯(cuò)誤。
3) 語法錯(cuò)誤。
4) 計(jì)算和精度問題。
5) 系統(tǒng)結(jié)構(gòu)不合理，造成系統(tǒng)性能問題。
6) 接口參數(shù)不匹配出現(xiàn)問題。
? 六大質(zhì)量特性有哪些：
1) 功能性
2) 可靠性
3) 易用性
4) 效率性
5) 可維護(hù)性
6) 可移植性
三、 名詞解釋（25分／5題）
? α測試、β測試、負(fù)載測試、壓力測試（強(qiáng)度測試）：
α測試：Alpha測試是由選定的用戶進(jìn)行的產(chǎn)品早期性測試，這個(gè)測試一般在可控的環(huán)境下進(jìn)行。
β測試(P29)：Beta測試是從用戶角度進(jìn)行的測試，是由軟件的多個(gè)用戶在一個(gè)或多個(gè)用戶的實(shí)際使用環(huán)境下進(jìn)行的測試。它是在開發(fā)者無法控制的軟件環(huán)境下進(jìn)行的軟件現(xiàn)場應(yīng)用。 強(qiáng)度測試：
也稱壓力測試、負(fù)載測試。強(qiáng)度測試是要破壞程序，檢測非正常的情況系統(tǒng)的負(fù)載能力。 強(qiáng)度測試模擬實(shí)際情況下的軟硬件環(huán)境和用戶使用過程的系統(tǒng)負(fù)荷，長時(shí)間或超負(fù)荷地運(yùn)行測試軟件來測試系統(tǒng)，以檢驗(yàn)系統(tǒng)能力的最高限度，從而了解系統(tǒng)的可靠性、穩(wěn)定性等。 ? 邏輯覆蓋、路徑覆蓋：
邏輯覆蓋：是以程序內(nèi)部的邏輯結(jié)構(gòu)為基礎(chǔ)的設(shè)計(jì)測試用例的技術(shù)。它屬于白盒測試。
路徑覆蓋：路徑覆蓋是在組件中被測試執(zhí)行到的路徑的百分比。要求設(shè)計(jì)若干測試用例，執(zhí)行被測試程序時(shí)，能夠覆蓋程序中所有的可能路徑。
? 軟件測試活動(dòng)生命周期：
軟件測試活動(dòng)生命周期：是指軟件從進(jìn)入測試到退出測試的過程中，所要經(jīng)歷的引入程序錯(cuò)誤、通過測試發(fā)現(xiàn)錯(cuò)誤和清除程序錯(cuò)誤的幾個(gè)階段。
? 樁模塊、驅(qū)動(dòng)模塊：
樁模塊（P105）：用于代替所測模塊調(diào)用的子模塊。樁模塊可以進(jìn)行少量的數(shù)據(jù)操作，不需要實(shí)現(xiàn)子模塊的所有功能，但要根據(jù)需要來實(shí)現(xiàn)或代替子模塊的一部分功能。
驅(qū)動(dòng)模塊（P105）：相當(dāng)于所測模塊的主程序。它接收測試數(shù)據(jù)，把這些數(shù)據(jù)傳送給所測模塊，最后再輸出實(shí)際測試結(jié)果。
? 大爆炸集成、三明治集成、改進(jìn)的三明治集成、高頻集成：
大爆炸集成（P153）：屬于非增值式集成的一種方法，也稱為一次性組裝或整體拼裝。這種集成策略的做法就是把所有通過單元測試的模塊一次性集成到一起進(jìn)行測試，不考慮組件之間的互相依賴性及可能存在的風(fēng)險(xiǎn)。
三明治集成（P158）：一種混合增量式測試策略，綜合了自頂向下和自底向上兩種集成方法的優(yōu)點(diǎn)，因此也屬于基于功能分解的集成。這種方法樁和開發(fā)工作都比較小，但增加了定位缺陷的難度。
改進(jìn)的三明治集成（P160）：利用較高的并行度彌補(bǔ)三明治集成中不能充分測試中間層的缺點(diǎn)。但根據(jù)中間層選擇是否恰當(dāng)，可能增加驅(qū)動(dòng)模塊和樁模塊設(shè)計(jì)的工作量。
高頻集成（P165）：高頻集成測試是指同步于軟件開發(fā)過程，每隔一段時(shí)間對(duì)開發(fā)團(tuán)隊(duì)的現(xiàn)有代碼進(jìn)行一次集成測試。該集成測試方法頻繁地將新代碼加入到一個(gè)已經(jīng)穩(wěn)定的基線中，以免集成故障難以發(fā)現(xiàn)，同時(shí)控制可能出現(xiàn)的基線偏差。
四、 簡答題（30分／6題）
? 軟件測試和軟件測試結(jié)束的標(biāo)準(zhǔn)：
（可能考法：什么是軟件測試，軟件測試分為哪幾個(gè)階段）
軟件測試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程�；蛘哒f，軟件測試是根據(jù)軟件開發(fā)各階段的規(guī)格說明和程序的內(nèi)部結(jié)構(gòu)而精心設(shè)計(jì)一批測試用例（即輸入數(shù)據(jù)及其預(yù)期的輸出結(jié)果），并利用這些測試用例去運(yùn)行程序，以發(fā)現(xiàn)程序錯(cuò)誤的過程。
軟件測試過程按各測試階段的先后順序可分為單元測試、集成測試、確認(rèn)（有效性）測試、系統(tǒng)測試和驗(yàn)收（用戶）測試5個(gè)階段
軟件測試退出標(biāo)準(zhǔn)為：完成測試需求中列出的所有功能及測試過程中發(fā)現(xiàn)缺陷的回歸測試。 ? 軟件缺陷等級(jí)：
1) 致命的：致命的錯(cuò)誤，造成系統(tǒng)或應(yīng)用程序崩潰、死機(jī)、系統(tǒng)懸掛，或造成數(shù)據(jù)丟失、主要功能完全喪失等。
2) 嚴(yán)重的：嚴(yán)重錯(cuò)誤，指功能或特性沒有實(shí)現(xiàn)，主要功能部分喪失，次要功能完全喪失，或致命的錯(cuò)誤聲明。
3) 一般的：不太嚴(yán)重的錯(cuò)誤，這樣的軟件缺陷雖然不影響系統(tǒng)的基本使用，但沒有很好地實(shí)現(xiàn)功能，沒有達(dá)到預(yù)期效果。如次要功能喪失，提示信息不太準(zhǔn)確，或用戶界面差，操作時(shí)間長等。
4) 微小的：一些小問題，對(duì)功能幾乎沒有影響，產(chǎn)品及屬性仍可使用，如有個(gè)別錯(cuò)別字、文字排列不整齊等。
? 階段評(píng)審和同行評(píng)審：
同行評(píng)審是一種重要而有效的工程方法，在軟件產(chǎn)品工程中調(diào)用此方法，可通過法根式審查、結(jié)構(gòu)化走查或者一些其他的學(xué)院式的評(píng)審方法加以實(shí)施。其目的是及早和高效地去除軟件工作中的缺陷，必然結(jié)果是增強(qiáng)對(duì)軟件工作產(chǎn)品和可預(yù)防缺陷的了解。
階段評(píng)審是利用在需求分析階段所選擇并制定的標(biāo)準(zhǔn)、規(guī)范以及計(jì)劃的安排，對(duì)軟件工程各階段的進(jìn)展、完成質(zhì)量及出現(xiàn)的問題進(jìn)行正式評(píng)審，確保過程計(jì)劃并遵守標(biāo)準(zhǔn)和規(guī)范執(zhí)行，然后形成報(bào)告。當(dāng)發(fā)現(xiàn)問題是，要準(zhǔn)尋逐級(jí)解決的原則，將處理結(jié)果通知相關(guān)人員，記錄解決過程及結(jié)果以作日后改進(jìn)重要參考資料。
兩者都是有關(guān)軟件質(zhì)量管理和保證的重要內(nèi)容，二者相輔相成，缺一不可。 ? ※單元測試策略（特別注意退出的原則）和集成測試的策略（P106）：
單元測試策略主要有三種方式：
1) 自頂向下的單元測試策略：
2) 自底向上的單元測試策略：
3) 孤立測試的單元測試策略：
單元測試退出的標(biāo)準(zhǔn)：
1) 單元測試用例設(shè)計(jì)已經(jīng)通過評(píng)審
2) 核心代碼100％ 經(jīng)過Code Review
3) 單元測試功能覆蓋率達(dá)到100％
4) 單元測試代碼行覆蓋率不低于80％
5) 所有發(fā)現(xiàn)缺陷至少60％都納入缺陷追蹤系統(tǒng)且各級(jí)缺陷修復(fù)率達(dá)到標(biāo)準(zhǔn)
6) 不存在A、B類缺陷
7) C、D、E類缺陷允許存在
8) 按照單元測試用例完成了所有規(guī)定單元的測試
9) 軟件單元功能與設(shè)計(jì)一致
集成測試的策略：
1) 大爆炸集成
2) 自頂向下集成
3) 自底向上集成
4) 三明治集成
5) 高頻集成
6) 分層集成
7) 分布式集成
8) 基于路徑、功能、進(jìn)度、風(fēng)險(xiǎn)、事件、使用等的集成等等
? 恢復(fù)性測試和安全性測試：
恢復(fù)性測試
也叫容錯(cuò)測試，用來檢查系統(tǒng)的容錯(cuò)能力。通常若計(jì)算機(jī)系統(tǒng)出現(xiàn)錯(cuò)誤，就必須在一定時(shí)間內(nèi)從錯(cuò)誤中恢復(fù)過來，修正錯(cuò)誤并重新啟動(dòng)系統(tǒng)。
恢復(fù)測試是通過各種手段，讓軟件強(qiáng)制性地出錯(cuò)，使其不能正常工作，從而檢驗(yàn)系統(tǒng)的恢復(fù)能力。
在進(jìn)行恢復(fù)性測試時(shí)，要考慮的主要問題有：
1) 恢復(fù)期間的安全性過程。
2) 恢復(fù)處理日志方面的能力。
3) 當(dāng)出現(xiàn)供電問題時(shí)的恢復(fù)能力。
4) 恢復(fù)操作后系統(tǒng)性能是否下降。
常用的恢復(fù)測試用例的設(shè)計(jì)方法：規(guī)范導(dǎo)出法、錯(cuò)誤猜測法、基于故障的測試。 安全性測試就是要驗(yàn)證系統(tǒng)內(nèi)的保護(hù)機(jī)制能否抵御入侵者的攻擊。
安全性測試的測試人員需要在測試活動(dòng)中，撒氣不同的入侵方式來攻擊系統(tǒng)的安全機(jī)制，想盡一切辦法來獲取系統(tǒng)內(nèi)的保密信息。
通常需要模擬的活動(dòng)有：
1) 獲取系統(tǒng)密碼
2) 破壞保護(hù)客戶信息的軟件
3) 獨(dú)占整個(gè)系統(tǒng)資源，使別人無法使用
4) 使得系統(tǒng)癱瘓，企圖在恢復(fù)系統(tǒng)階段獲得利益等
? 判斷系統(tǒng)安全性性能的指標(biāo)：
1) 有效性：啟動(dòng)嚴(yán)格的安全性性能所花費(fèi)的時(shí)間占啟動(dòng)整個(gè)系統(tǒng)所花費(fèi)時(shí)間的比例。
2) 生存性：當(dāng)錯(cuò)誤發(fā)生時(shí)，系統(tǒng)對(duì)緊急操作的支持，對(duì)錯(cuò)誤的補(bǔ)救措施以及恢復(fù)到正常操作的能力，即系統(tǒng)的抗挫能力。
3) 精確性：衡量系統(tǒng)安全性控制的精度指標(biāo)，圍繞所出現(xiàn)的錯(cuò)誤數(shù)量、發(fā)生頻率及其嚴(yán)重性判斷。
4) 反應(yīng)時(shí)間：出錯(cuò)時(shí)系統(tǒng)響應(yīng)速度的快慢，一個(gè)安全性較強(qiáng)的系統(tǒng)要具備快速的反應(yīng)速度。
5) 吞吐量：用戶和服務(wù)請(qǐng)求的峰值和平均值。
五、 設(shè)計(jì)案例（15分／2題）
? 怎樣制定有效等價(jià)類、無效等價(jià)類（作業(yè)1）：
測試場景：
一個(gè)程序讀入3個(gè)整數(shù)，把這三個(gè)數(shù)值看作一個(gè)三角形的3條邊的長度值。這個(gè)程序要打印出信息，說明這個(gè)三角形是不等邊的、是等腰的、還是等邊的
? 設(shè)三角形的3條邊分別為A，B，C。如果它們能夠構(gòu)成三角形的3條邊，必須滿足： ? A>0，B>0，C>0，且A+B>C，B+C>A，A+C>B；
? 如果是等腰的，還要判斷A=B，或B=C，或A=C；
? 如果是等邊的，則需判斷是否A=B，且B=C，且A=C。
? 根據(jù)程序畫出程序流程圖（作業(yè)2）：
程序流程圖
↓
控制流圖（已經(jīng)給出）
↓
圈復(fù)雜度
↓
獨(dú)立路徑
↓
測試用例
?
? 程序：
1 main ()
2 {
3 int num1=0, num2=0, score=100;
4 int i;
5 char str;
6 scanf (“%d, %c\n”, &i, &str);
7 while (i
8 {
9 if (str=?T?)
10 num1++;
11 else if (str=?F?)
12 {
13 score=score-10;
14 num2 ++;
15 }
16 i++;
17 }
18 printf (“num1=%d, num2=%d, score=%d\n”, num1, num2, score);
19 }
(一) 根據(jù)程序畫出控制流圖：
控制流圖G
(二) 根據(jù)控制流圖計(jì)算圈復(fù)雜度：
根據(jù)程序環(huán)形復(fù)雜度的計(jì)算公式，求出程序路徑集合中的獨(dú)立路徑數(shù)目。
公式1：V(G)=10-8+2，其中10是控制流圖G中邊的數(shù)量，8是控制流圖中節(jié)點(diǎn)的數(shù)目。 公式2：V(G)=3+1，其中3是控制流圖G中判斷節(jié)點(diǎn)的數(shù)目。
公式3：V(G)=4，其中4是控制流圖G中區(qū)域的數(shù)目。
因此，控制流圖G的環(huán)形復(fù)雜度是4。就是說至少需要4條獨(dú)立路徑組成基本路徑集合，并由此得到能夠覆蓋所有程序語句的測試用例。
(三) 確定基本路徑集合（即獨(dú)立路徑集合）：
一條獨(dú)立路徑是至少包含有一條在其它獨(dú)立路徑中從未有過的邊的路徑。
根據(jù)上面環(huán)形復(fù)雜度的計(jì)算結(jié)果，源程序的基本路徑集合中有4條獨(dú)立路徑： path1：7->18
path2：7->9->10->16->7->18
path3：7->9->11->15->16->7->18
path4：7->9->11->13->14->15->16->7->18
(
(一) 判斷：
判定語句：對(duì)于連鎖型分支結(jié)構(gòu)，若有n個(gè)判定語句，則有2n條路徑。
黑盒測試：用黑盒法測試時(shí)，測試用例是根據(jù)產(chǎn)品的功能設(shè)計(jì)的。
(二) 選擇：
? 軟件測試的目的是（發(fā)現(xiàn)軟件的錯(cuò)誤）。
? 為了提高測試的效率，應(yīng)該（ 選擇發(fā)現(xiàn)錯(cuò)誤的可能性大的數(shù)據(jù)作為測試數(shù)據(jù) ）。 ? 使用白盒測試方法時(shí)，確定測試數(shù)據(jù)應(yīng)根據(jù)（ 程序的內(nèi)部邏輯）和指定的覆蓋標(biāo)準(zhǔn)。 ? 與設(shè)計(jì)測試數(shù)據(jù)無關(guān)的文檔是（ 項(xiàng)目開發(fā)計(jì)劃 ）。
? 軟件的工作最好由（不屬于該軟件開發(fā)組的軟件設(shè)計(jì)人員）承擔(dān)，以提高集成測試的效果。
測試真正的目的是使我們通過對(duì)軟件錯(cuò)誤的原因和分布進(jìn)行歸納，來發(fā)現(xiàn)并排除當(dāng)前軟件產(chǎn)品的缺陷，對(duì)在需求和設(shè)計(jì)過程中存在的問題查缺補(bǔ)漏，從而確保軟件產(chǎn)品的質(zhì)量。
常見軟件測試工程師面試題
1. 你如何在pocket pc 上TEST 你的程序. 你考慮了哪些方面.
2. 如果將你的程序的語言擴(kuò)展到非英語,例如中文, 你如何測試.
3. 給你一個(gè)COCAN, 你如何測試(解釋說就是罐裝的可口可樂).
4. 當(dāng)你的程序遇到BUG的時(shí)候，你選擇怎樣處理.
5. 你如何isolation 你程序里的BUG.
軟件測試工程師筆試試題答案
我認(rèn)為那些面試題不同的人會(huì)有不同的答案
下面是部分答案
一、判斷題（每題1分，12 分，正確的√，錯(cuò)誤的╳）
1．軟件測試的目的是盡可能多的找出軟件的缺陷。（） 軟件測試的目的就是為了發(fā)現(xiàn)軟件中的缺陷，從這個(gè)意義上面說上面的這個(gè)論斷是正確的。不少人會(huì)認(rèn)為軟件測試可以保證軟件的質(zhì)量，其實(shí)這個(gè)觀點(diǎn)是錯(cuò)誤，測試只是軟件質(zhì)量控制中的一個(gè)角色，其活動(dòng)并不能達(dá)成軟件質(zhì)量保證的效果。所以不要認(rèn)為一個(gè)公司里面如果有了軟件測試人員，產(chǎn)品的質(zhì)量就會(huì)好起來。
2．Beta 測試是驗(yàn)收測試的一種。（） Beat測試和驗(yàn)收測試是兩種不同的測試。驗(yàn)收測試的目的是為了以發(fā)現(xiàn)”未實(shí)現(xiàn)的需求”為目的，以評(píng)估”適合使用”為目標(biāo)，該類測試的不是以發(fā)現(xiàn)缺陷為主要目的。beta測試是一模擬真實(shí)的使用環(huán)境從而發(fā)現(xiàn)缺陷的一種測試。所以兩者之間的是非包容關(guān)系。
3．驗(yàn)收測試是由最終用戶來實(shí)施的。（） 上面說到了驗(yàn)收測試的目的和目標(biāo)，所以驗(yàn)收測試也可是是軟件生產(chǎn)的企業(yè)內(nèi)部人員來實(shí)施。例如產(chǎn)品經(jīng)理。當(dāng)軟件以項(xiàng)目的形式出現(xiàn)，那么驗(yàn)收測試由最終用戶來實(shí)施的情況是比較長見的。但是對(duì)于產(chǎn)品形式的軟件，生產(chǎn)企業(yè)內(nèi)部的驗(yàn)收測試會(huì)更多。
4．項(xiàng)目立項(xiàng)前測試人員不需要提交任何工件。（） 應(yīng)該說這道題目沒有明確的答案，在項(xiàng)目立項(xiàng)前測試人員是不是要把一些準(zhǔn)備工作以工件的形式給記錄下來是完全取決于該企業(yè)的軟件開發(fā)過程的要求。同時(shí)不同企業(yè)，立項(xiàng)前要達(dá)成的一些必要條件也是大相徑庭的。應(yīng)該說這一題目出的不是很好，如果你是出題人這家企業(yè)的測試工程師，那么就應(yīng)該有一個(gè)明確的答案。
5．單元測試能發(fā)現(xiàn)約80%的軟件缺陷。（） 同樣這一題目也沒有標(biāo)準(zhǔn)答案。因?yàn)樵摂?shù)據(jù)的來源和其統(tǒng)計(jì)的方法，樣本都沒有一個(gè)工業(yè)標(biāo)準(zhǔn)。這樣出來的數(shù)據(jù)同樣不具有權(quán)威性。這里我可以說一個(gè)簡單的例子，在用ASP,php這類腳本語言開發(fā)網(wǎng)頁的時(shí)候是根本沒有復(fù)雜的單元測試。那么這樣的數(shù)字應(yīng)用在網(wǎng)站開發(fā)上面是否有意義，還是值得商榷的。所以這道題目出的不好，沒有明確的答案
6．代碼評(píng)審是檢查源代碼是否達(dá)到模塊設(shè)計(jì)的要求。（） 代碼審查是一種靜態(tài)技術(shù)，從這個(gè)意義上說代碼復(fù)查是需要和其他的一些動(dòng)態(tài)測試技術(shù)配合才能檢查代碼是否符合設(shè)計(jì)的要求
7．自底向上集成需要測試員編寫驅(qū)動(dòng)程序。（） 這道題目大家看下top-down 和 down-top的集成測試示意圖就能得出明確的答案。這里需要了解的是什么是驅(qū)動(dòng)測試程序，什么是樁程序。如果集成組件數(shù)量眾多，多關(guān)系層次，那么不論是什么類型的集成測試。驅(qū)動(dòng)程序和樁程序都是需要開發(fā)的。
8．負(fù)載測試是驗(yàn)證要檢驗(yàn)的系統(tǒng)的能力最高能達(dá)到什么程度。（） 關(guān)于負(fù)載測試和壓力測試在論壇中的帖子中有詳細(xì)的解釋，大家可以去看一下就能得出正確的答案
9．測試人員要堅(jiān)持原則，缺陷未修復(fù)完堅(jiān)決不予通過。（） 同樣，這一題沒有正確的答案。缺陷是否修復(fù)是需要聽取測試人員的意見，但測試人員的意見非決定性。所以還是要看一個(gè)企業(yè)賦予測試人員有多大的權(quán)力。
10．代碼評(píng)審員一般由測試員擔(dān)任。（） 如果測試員有這個(gè)水平，那么當(dāng)然是可以參加的。不過大多數(shù)的企業(yè)不會(huì)讓普通的測試人員參與代碼的評(píng)審。
11．我們可以人為的使得軟件不存在配置問題。（） 首先大家先搞清楚什么是配置管理什么是軟件配置，從這道題目中看不出出題人想問的是關(guān)鍵工程中的配置管理還是單純的軟件配置。但是可以肯定的是不論是何種情況，答案均是否定的。
12．集成測試計(jì)劃在需求分析階段末提交。（） 集成測試計(jì)劃在開發(fā)人員完成軟件集成計(jì)劃之后就可以開始進(jìn)行了。所以在需求分析階段之后提交是不現(xiàn)實(shí)的事情，應(yīng)該在軟件的設(shè)計(jì)階段后，編碼前。
二、不定項(xiàng)選擇題（每題2 分，10分）
1．軟件驗(yàn)收測試的合格通過準(zhǔn)則是：（）
A． 軟件需求分析說明書中定義的所有功能已全部實(shí)現(xiàn)，性能指標(biāo)全部達(dá)到要求。
B． 所有測試項(xiàng)沒有殘余一級(jí)、二級(jí)和一
C． 立項(xiàng)審批表、需求分析文檔、設(shè)計(jì)文檔和編碼實(shí)現(xiàn)一致。
D． 驗(yàn)收測試工件齊全。 回答這道題，你必須是這家企業(yè)的員工。前面說到了驗(yàn)收測試的目的和目標(biāo)，一個(gè)是需求必須實(shí)現(xiàn)，二是證明軟件是適合使用的。這樣能滿足這兩個(gè)通用標(biāo)準(zhǔn)就可以了。當(dāng)然有些軟件企業(yè)會(huì)對(duì)驗(yàn)收測試標(biāo)準(zhǔn)做一些調(diào)整。
2．軟件測試計(jì)劃評(píng)審會(huì)需要哪些人員參加？（）
A．項(xiàng)目經(jīng)理
B．SQA 負(fù)責(zé)人
C．配置負(fù)責(zé)人
D．測試組 上面的4種角色都需要參與
3．下列關(guān)于alpha 測試的描述中正確的是：（）
A．a(chǎn)lpha 測試需要用戶代表參加
B．a(chǎn)lpha 測試不需要用戶代表參加
C．a(chǎn)lpha 測試是系統(tǒng)測試的一種
D．a(chǎn)lpha 測試是驗(yàn)收測試的一種 首先大家需要知道alpha測試是系統(tǒng)級(jí)別的測試，該測試是在一個(gè)受控的環(huán)境中進(jìn)行的。用戶需要直接參與進(jìn)來。所以答案應(yīng)該是AD
轉(zhuǎn)貼請(qǐng)注明 : http://www.pghome.net 志遠(yuǎn)工作室
4．測試設(shè)計(jì)員的職責(zé)有：（）
A．制定測試計(jì)劃
B．設(shè)計(jì)測試用例
C．設(shè)計(jì)測試過程、腳本
D．評(píng)估測試活動(dòng) 合理的答案的是BC，同時(shí)要看軟件企業(yè)對(duì)該類人員的職責(zé)是如何定義。
5．軟件實(shí)施活動(dòng)的進(jìn)入準(zhǔn)則是：（）
A．需求工件已經(jīng)被基線化
B．詳細(xì)設(shè)計(jì)工件已經(jīng)被基線化
C．構(gòu)架工件已經(jīng)被基線化
D．項(xiàng)目階段成果已經(jīng)被基線化 先要了解一下什么是基線。這個(gè)是軟件配置管理中一個(gè)重要的概念。工作產(chǎn)品必須納入到一定的基線里面。所以選擇ABC是必定的，至于是否選擇D要看這家企業(yè)自身的標(biāo)準(zhǔn)了
填空題（每空1分，24 分）
1．軟件驗(yàn)收測試包括___、___、____三種類型。 軟件驗(yàn)收測試包括正式驗(yàn)收測試、alpha測試、beta測試三種測試。
2．系統(tǒng)測試的策略有功能測試、、、、易用性測試、、、、、、、、 、、等15 種方法。 系統(tǒng)測試的策略有很多種的，我知道的有性能測試、負(fù)載測試、強(qiáng)度測試、易用性測試、安全測試、配置測試、安裝測試、文檔測試、故障恢復(fù)測試、用戶界面測試、恢復(fù)測試、分布測試、可用性測試。。。
3．設(shè)計(jì)系統(tǒng)測試計(jì)劃需要參考的項(xiàng)目文檔有、和迭代計(jì)劃。 設(shè)計(jì)系統(tǒng)測試計(jì)劃需要參考的項(xiàng)目文檔有軟件測試計(jì)劃、軟件需求工件、和迭代計(jì)劃。
4．對(duì)面向過程的系統(tǒng)采用的集成策略有___、___兩種。 5．通過畫因果圖來寫測試用例的步驟為___、___、___、___及把因果圖轉(zhuǎn)換為狀態(tài)圖共五個(gè)步驟。 利用因果圖生成測試用例的基本步驟是： § 分析軟件規(guī)格說明描述中，哪些是原因（即輸入條件或輸入條件的等價(jià)類），哪些是結(jié)果（即輸出條件），并給每個(gè)原因和結(jié)果賦予一個(gè)標(biāo)識(shí)符。 § 分析軟件規(guī)格說明描述中的語義，找出原因與結(jié)果之間，原因與原因之間對(duì)應(yīng)的是什么關(guān)系? 根據(jù)這些關(guān)系，畫出因果圖。 § 由于語法或環(huán)境限制，有些原因與原因之間，原因與結(jié)果之間的組合情況不可能出現(xiàn)。為表明這些特殊情況，在因果圖上用一些記號(hào)標(biāo)明約束或限制條件。 § 把因果圖轉(zhuǎn)換成判定表。 § 把判定表的每一列拿出來作為依據(jù)，設(shè)計(jì)測試用例。
常見的軟件測試面試題
1. 等價(jià)類劃分
常見的軟件測試面試題劃分等價(jià)類: 等價(jià)類是指某個(gè)輸入域的子集合.在該子集合中,各個(gè)輸入數(shù)據(jù)對(duì)于揭露程序中的錯(cuò)誤都是等效的.并合理地假定:測試某等價(jià)類的代表值就等于對(duì)這一類其它值的測試.因此,可以把全部輸入數(shù)據(jù)合理劃分為若干等價(jià)類,在每一個(gè)等價(jià)類中取一個(gè)數(shù)據(jù)作為測試的輸入條件,就可以用少量代表性的測試數(shù)據(jù).取得較好的測試結(jié)果.等價(jià)類劃分可有兩種不同的情況:有效等價(jià)類和無效等價(jià)類.
2. 邊界值分析法
邊界值分析方法是對(duì)等價(jià)類劃分方法的補(bǔ)充。測試工作經(jīng)驗(yàn)告訴我,大量的錯(cuò)誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內(nèi)部.因此針對(duì)各種邊界情況設(shè)計(jì)測試用例,可以查出更多的錯(cuò)誤.
使用邊界值分析方法設(shè)計(jì)測試用例,首先應(yīng)確定邊界情況.通常輸入和輸出等價(jià)類的邊界,就是應(yīng)著重測試的邊界情況.應(yīng)當(dāng)選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù),而不是選取等價(jià)類中的典型值或任意值作為測試數(shù)據(jù).
3. 錯(cuò)誤推測法
基于經(jīng)驗(yàn)和直覺推測程序中所有可能存在的各種錯(cuò)誤, 從而有針對(duì)性的設(shè)計(jì)測試用例的方法.
錯(cuò)誤推測方法的基本思想: 列舉出程序中所有可能有的錯(cuò)誤和容易發(fā)生錯(cuò)誤的特殊情況,根據(jù)他們選擇測試用例. 例如, 在單元測試時(shí)曾列出的許多在模塊中常見的錯(cuò)誤. 以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯(cuò)誤等, 這些就是經(jīng)驗(yàn)的總結(jié)。還有, 輸入數(shù)據(jù)和輸出數(shù)據(jù)為0的情況。輸入表格為空格或輸入表格只有一行. 這些都是容易發(fā)生錯(cuò)誤的情況�？蛇x擇這些情況下的例子作為測試用例.
4. 因果圖方法
前面介紹的等價(jià)類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯(lián)系, 相互組合等. 考慮輸入條件之間的相互組合,可能會(huì)產(chǎn)生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價(jià)類,他們之間的組合情況也相當(dāng)多. 因此必須考慮采用一種適合于描述對(duì)于多種條件的組合,相應(yīng)產(chǎn)生多個(gè)動(dòng)作的形式來考慮設(shè)計(jì)測試用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是判定表. 它適合于檢查程序輸入條件的各種組合情況.
5. 正交表分析法
有時(shí)候，可能因?yàn)榇罅康膮?shù)的組合而引起測試用例數(shù)量上的激增，同時(shí)，這些測試用例并沒有明顯的優(yōu)先級(jí)上的差距，而測試人員又無法完成這么多數(shù)量的測試，就可以通過正交表來進(jìn)行縮減一些用例，從而達(dá)到盡量少的用例覆蓋盡量大的范圍的可能性。
6. 場景分析方法
指根據(jù)用戶場景來模擬用戶的操作步驟，這個(gè)比較類似因果圖，但是可能執(zhí)行的深度和可行性更好。
您認(rèn)為做好測試用例設(shè)計(jì)工作的關(guān)鍵是什么？
白盒測試用例設(shè)計(jì)的關(guān)鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏輯結(jié)果
黑盒法用例設(shè)計(jì)的關(guān)鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時(shí)間內(nèi)發(fā)現(xiàn)最多的問題
詳細(xì)的描述一個(gè)測試活動(dòng)完整的過程。
1. 項(xiàng)目經(jīng)理通過和客戶的交流，完成需求文檔，由開發(fā)人員和測試人員共同完成需求文檔的評(píng)審，評(píng)審的內(nèi)容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實(shí)現(xiàn)的功能的地方。項(xiàng)目經(jīng)理通過綜合開發(fā)人員，測試人員以及客戶的意見，完成項(xiàng)目計(jì)劃。然后SQA進(jìn)入項(xiàng)目，開始進(jìn)行統(tǒng)計(jì)和跟蹤
2. 開發(fā)人員根據(jù)需求文檔完成需求分析文檔，測試人員進(jìn)行評(píng)審，評(píng)審的主要內(nèi)容包括是否有遺漏或者雙方理解不同的地方。測試人員完成測試計(jì)劃文檔，測試計(jì)劃包括的內(nèi)容上面有描述。
3. 測試人員根據(jù)修改好的需求分析文檔開始寫測試用例，同時(shí)開發(fā)人員完成概要設(shè)計(jì)文檔，詳細(xì)設(shè)計(jì)文檔。此兩份文檔成為測試人員撰寫測試用例的補(bǔ)充材料。
4. 測試用例完成后，測試和開發(fā)需要進(jìn)行評(píng)審。
5. 測試人員搭建環(huán)境
6. 開發(fā)人員提交第一個(gè)版本，可能存在未完成功能，需要說明。測試人員進(jìn)行測試，發(fā)現(xiàn)BUG后提交給BugZilla。
7. 開發(fā)提交第二個(gè)版本，包括Bug Fix以及增加了部分功能，測試人員進(jìn)行測試。
8. 重復(fù)上面的工作，一般是3-4個(gè)版本后BUG數(shù)量減少，達(dá)到出貨的要求。
9. 如果有客戶反饋的問題，需要測試人員協(xié)助重現(xiàn)以及回歸測試。
以往是否曾經(jīng)從事過性能測試工作？請(qǐng)盡可能的詳細(xì)描述您以往的性能測試工作的完整過程。
曾經(jīng)做過一套網(wǎng)管系統(tǒng)的性能測試，主要測試該軟件在同時(shí)管理大量終端的情況下，在響應(yīng)時(shí)間，CPU/磁盤/內(nèi)存等參數(shù)是否滿足要求。
也曾經(jīng)做過軟交換系統(tǒng)的呼叫性能測試，主要是測試軟交換系統(tǒng)在有大量呼叫的情況下，響應(yīng)時(shí)間，呼叫成功率，CPU/磁盤/內(nèi)存等參數(shù)是否滿足設(shè)計(jì)要求。
您在從事性能測試工作時(shí)，是否使用過一些測試工具？如果有，請(qǐng)?jiān)囀鲈摴ぞ叩墓ぷ髟�，并以一個(gè)具體
的工作中的例子描述該工具是如何在實(shí)際工作中應(yīng)用的。
測試網(wǎng)管系統(tǒng)中，使用的Mimic來模擬終端，能夠大量的節(jié)省成本。
測試軟交換系統(tǒng)的時(shí)候，使用的Prolab來模擬終端并發(fā)送呼叫軟交換，他完成了同時(shí)數(shù)百人才能完成的摘機(jī)撥號(hào)工作，主要工作原理是產(chǎn)生一些符合要求的IP包并發(fā)送給軟交換系統(tǒng)，同時(shí)對(duì)軟交換系統(tǒng)的回應(yīng)進(jìn)行處理，決定下一步動(dòng)作。
您認(rèn)為性能測試工作的目的是什么？做好性能測試工作的關(guān)鍵是什么？
主要是保障在大量用戶的情況下，服務(wù)能正常使用。
在您以往的工作中，一條軟件缺陷（或者叫Bug）記錄都包含了哪些內(nèi)容？如何提交高質(zhì)量的軟件缺陷（Bug）記錄？
1. 在傳統(tǒng)的BugZilla中，BUG描述應(yīng)該包括以下的信息
2. 和BUG產(chǎn)生對(duì)應(yīng)的軟件版本
3. 開發(fā)的接口人員
4. BUG的優(yōu)先級(jí)
5. BUG的嚴(yán)重程度
6. BUG可能屬于的模塊，如果不能確認(rèn)，可以用開發(fā)人員來判斷
7. BUG標(biāo)題，需要清晰的描述現(xiàn)象
8. BUG描述，需要盡量給出重新Bug的步驟
9. BUG附件中能給出相關(guān)的日志和截圖。
高質(zhì)量的BUG記錄就是指很容易理解的BUG記錄，所以，對(duì)于描述的要求高，能提供的信息多且準(zhǔn)確，很好的幫助開發(fā)人員定位。
02.您是否了解以往所工作的企業(yè)的軟件測試過程？如果了解，請(qǐng)?jiān)囀鲈谶@個(gè)過程中都有哪些工作要做？分別由哪些不同的角色來完成這些工作？
測試計(jì)劃->測試設(shè)計(jì)(測試用例，測試數(shù)據(jù))->測試執(zhí)行(單元測試，集成測試，系統(tǒng)測試，回歸測試) 03. 您所熟悉的軟件測試類型都有哪些？請(qǐng)?jiān)囍謩e比較這些不同的測試類型的區(qū)別與聯(lián)系（如功能測試、性能測試……）
易用性測試-界面的友好性，操作方便性等。
功能測試-系統(tǒng)中功能性需求的滿足
安全性測試-系統(tǒng)是否存在安全隱患和漏洞
性能測試-系統(tǒng)在大并發(fā)下的響應(yīng)速度和健壯性
04.請(qǐng)?jiān)囍容^一下黑盒測試、白盒測試、單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試的區(qū)別與聯(lián)系。 黑盒/白盒:主要區(qū)別在是否了解系統(tǒng)或程序的內(nèi)部結(jié)構(gòu)和代碼
單元測試:關(guān)注某一個(gè)單元，函數(shù)，模塊的正確性，一般需要編寫相關(guān)測試代碼。
集成測試:模塊或模塊直接的集成接口測試，單個(gè)模塊測試
系統(tǒng)測試:一個(gè)完整功能的完全測試。
05.測試計(jì)劃工作的目的是什么？測試計(jì)劃工作的內(nèi)容都包括什么？其中哪些是最重要的？
提前安排出測試工具選擇，測試類型選擇，人員需求，保證和項(xiàng)目開發(fā)協(xié)調(diào)一致，保證測試工作順利進(jìn)行。 06.您認(rèn)為做好測試計(jì)劃工作的關(guān)鍵是什么？
了解項(xiàng)目或系統(tǒng)的業(yè)務(wù)需求
和項(xiàng)目經(jīng)理協(xié)調(diào)好，了解項(xiàng)目的進(jìn)度計(jì)劃安排情況
07.您所熟悉的測試用例設(shè)計(jì)方法都有哪些？請(qǐng)分別以具體的例子來說明這些方法在測試用例設(shè)計(jì)工作中的應(yīng)用。
邊界值/等價(jià)類/業(yè)務(wù)流程圖分析和狀態(tài)轉(zhuǎn)換分析/業(yè)務(wù)邏輯分析
08.您認(rèn)為做好測試用例設(shè)計(jì)工作的關(guān)鍵是什么？
對(duì)業(yè)務(wù)和軟件需求非常清楚，可以根據(jù)需求不同選擇不同的測試用例設(shè)計(jì)
09.您以往的工作中是否曾開展過測試用例的評(píng)審工作？如果有，請(qǐng)描述測試用例評(píng)審的過程和評(píng)審的內(nèi)容。
評(píng)審計(jì)劃->預(yù)審->評(píng)審;
評(píng)審內(nèi)容主要是測試用例對(duì)軟件需求的覆蓋程度，對(duì)于相關(guān)邊界是否考慮，是否針對(duì)復(fù)雜流程準(zhǔn)備多套測試數(shù)據(jù)，是否有專門針對(duì)非功能性需求的測試。
10.您以往是否曾經(jīng)從事過性能測試工作？如果有，請(qǐng)盡可能的詳細(xì)描述您以往的性能測試工作的完整過程。
制訂計(jì)劃->選擇測試功能->選擇測試工具->錄制腳本->運(yùn)行測試->分析結(jié)果
11.您在從事性能測試工作時(shí)，是否使用過一些測試工具？如果有，請(qǐng)?jiān)囀鲈摴ぞ叩墓ぷ髟�，并以一個(gè)具體的工作中的例子描述該工具是如何在實(shí)際工作中應(yīng)用的。
微軟WAS,LoadRunner
12.您認(rèn)為性能測試工作的目的是什么？做好性能測試工作的關(guān)鍵是什么？
關(guān)鍵是測試腳本的錄制，測試時(shí)候測試環(huán)境的干凈。
13.在您以往的工作中，一條軟件缺陷（或者叫Bug）記錄都包含了哪些內(nèi)容？如何提交高質(zhì)量的軟件缺陷（Bug）記錄？
缺陷名詞/描述/缺陷等級(jí)/嚴(yán)重程度/發(fā)現(xiàn)模塊/發(fā)現(xiàn)步驟和過程/是否可以重現(xiàn)
14.您以往所從事的軟件測試工作中，是否使用了一些工具來進(jìn)行軟件缺陷（Bug）的管理？如果有，請(qǐng)結(jié)合該工具描述軟件缺陷（Bug）跟蹤管理的流程。
CQ，也可以使用BugFree等免費(fèi)工具。
15.您如何看待軟件過程改進(jìn)？在您曾經(jīng)工作過的企業(yè)中，是否有一些需要改進(jìn)的東西呢？您期望的理想的測試人員的工作環(huán)境是怎樣的？
將先進(jìn)的經(jīng)驗(yàn)或思想固化到過程中，通過過程改進(jìn)和能力提高來改進(jìn)軟件質(zhì)量。
軟件測試:微軟測試工程師面試題
1. 你如何在pocket pc 上TEST 你的程序. 你考慮了哪些方面.
2. 如果將你的程序的語言擴(kuò)展到非英語,例如中文, 你如何測試.
3. 給你一個(gè)COCAN, 你如何測試(解釋說就是罐裝的可口可樂).
4. 當(dāng)你的程序遇到BUG的時(shí)候，你選擇怎樣處理.
5. 你如何isolation 你程序里的BUG.
6. 給你一個(gè)產(chǎn)品有10個(gè)functionality,如果時(shí)間緊迫, 只能測其中的5個(gè), 你如何選擇. 其它相關(guān)：
如果別人問我這些題目，我想我會(huì)大致這樣回答，各位從事軟件測試的同志們幫我看看回答的怎么樣。
01. 為什么要在一個(gè)團(tuán)隊(duì)中開展軟件測試工作？
答：軟件測試在整個(gè)一個(gè)團(tuán)隊(duì)中占有非常重要的地位，具體來說就是測試是一個(gè)發(fā)現(xiàn)軟件錯(cuò)誤的過程，執(zhí)行軟件測試會(huì)以最少的人力和時(shí)間，系統(tǒng)的找到軟件存在的缺陷和錯(cuò)誤，建立起開發(fā)人員和使用者對(duì)軟件的信心。
02. 您是否了解以往所工作的企業(yè)的軟件測試過程？如果了解，請(qǐng)?jiān)囀鲈谶@個(gè)過程中都有哪些工作要做？分別由哪些不同的角色來完成這些工作？
答：軟件測試部門配合系統(tǒng)分析人員軟件需求分析討論，并根據(jù)需求說明書制定《項(xiàng)目測試計(jì)劃》，編寫測試用例，建立測試環(huán)境。
軟件測試人員負(fù)責(zé)軟件開發(fā)部門的新產(chǎn)品測試及原有產(chǎn)品的升級(jí)測試，負(fù)責(zé)軟件問題解決過程跟蹤，負(fù)責(zé)軟件開發(fā)文檔開發(fā)工作的規(guī)范化及管理開發(fā)部門的產(chǎn)品文檔，制作用戶手冊(cè)及操作手冊(cè)，負(fù)責(zé)產(chǎn)品的上線測試，監(jiān)督軟件開發(fā)過程的執(zhí)行，提高產(chǎn)品質(zhì)量。
03. 您是否了解以往所工作的企業(yè)的軟件開發(fā)過程？如果了解，請(qǐng)?jiān)囀鲆粋�(gè)完整的開發(fā)過程需要完成哪些工作？分別由哪些不同的角色來完成這些工作？（對(duì)于軟件測試部分，可以簡述）
答：需求人員連同系統(tǒng)分析人員&測試人員開會(huì)討論需求。系統(tǒng)分析人員寫出需求分析說明，并連同系統(tǒng)分析人員&測試人員&需求人員開會(huì)討論可行性。系統(tǒng)分析人員寫出詳細(xì)設(shè)計(jì)說明書，程式人員編碼，給出系統(tǒng)流程圖。交與測試人員，測試人員給出Bug統(tǒng)計(jì)表。 04. 您在以往的測試工作中都曾經(jīng)具體從事過哪些工作？其中最擅長哪部分工作？ 答：從事過write test plan，creation of test case，進(jìn)行功能測試，性能測試，編寫測試工具，文檔的管理等，比較擅長與寫測試用例和進(jìn)行功能測試。
05. 您所熟悉的軟件測試類型都有哪些？請(qǐng)?jiān)囍謩e比較這些不同的測試類型的區(qū)別與聯(lián)系（如功能測試、性能測試……）
答：有功能測試，性能測試，可靠性測試，安全性測試，負(fù)載測試，壓力測試，安裝/卸載測試，啟動(dòng)/停止測試，兼容性測試，互連測試，文檔測試，恢復(fù)測試，回歸測試，可使用性測試，容量測試。
功能測試只對(duì)軟件的功能是否滿足用戶需求來做測試。性能測試需要和壓力和負(fù)載測試聯(lián)合起來。
06. 請(qǐng)?jiān)囍容^一下黑盒測試、白盒測試、單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試的區(qū)別與聯(lián)系。
黑盒測試：把測試對(duì)象當(dāng)成一個(gè)黑盒子，測試人員完全不考慮邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程式的需求說明書來檢查程式的功能是否滿足它的功能說明。
白盒測試：把測試對(duì)象當(dāng)成一個(gè)透明的盒子，允許測試人員利用程序內(nèi)部邏輯結(jié)構(gòu)及相關(guān)信息，設(shè)計(jì)或選擇測試用例，對(duì)程式所有邏輯路徑進(jìn)行測試。
單元測試：白盒測試的一種，對(duì)軟件設(shè)計(jì)中的單元模塊進(jìn)行測試。
集成測試：在單元測試的基礎(chǔ)上，對(duì)單元模塊之間的連接和組裝進(jìn)行測試。 系統(tǒng)測試：在所有都考慮的情況下，對(duì)系統(tǒng)進(jìn)行測試。
驗(yàn)收測試：第三方進(jìn)行的確認(rèn)軟件滿足需求的測試。
常見軟件測試工程師面試題
01. 為什么要在一個(gè)團(tuán)隊(duì)中開展軟件測試工作？
答：軟件測試在整個(gè)一個(gè)團(tuán)隊(duì)中占有非常重要的地位，具體來說就是測試是一個(gè)發(fā)現(xiàn)軟件錯(cuò)誤的過程，執(zhí)行軟件測試會(huì)以最少的人力和時(shí)間，系統(tǒng)的找到軟件存在的缺陷和錯(cuò)誤，建立起開發(fā)人員和使用者對(duì)軟件的信心。
02. 您是否了解以往所工作的企業(yè)的軟件測試過程？如果了解，請(qǐng)?jiān)囀鲈谶@個(gè)過程中都有哪些工作要做？分別由哪些不同的角色來完成這些工作？
答：軟件測試部門配合系統(tǒng)分析人員軟件需求分析討論，并根據(jù)需求說明書制定《項(xiàng)目測試計(jì)劃》，編寫測試用例，建立測試環(huán)境。
軟件測試人員負(fù)責(zé)軟件開發(fā)部門的新產(chǎn)品測試及原有產(chǎn)品的升級(jí)測試，負(fù)責(zé)軟件問題解決過程跟蹤，負(fù)責(zé)軟件開發(fā)文檔開發(fā)工作的規(guī)范化及管理開發(fā)部門的產(chǎn)品文檔，制作用戶手冊(cè)及操作手冊(cè)，負(fù)責(zé)產(chǎn)品的上線測試，監(jiān)督軟件開發(fā)過程的執(zhí)行，提高產(chǎn)品質(zhì)量。
03. 您是否了解以往所工作的企業(yè)的軟件開發(fā)過程？如果了解，請(qǐng)?jiān)囀鲆粋�(gè)完整的開發(fā)過程需要完成哪些工作？分別由哪些不同的角色來完成這些工作？（對(duì)于軟件測試部分，可以簡述）
答：需求人員連同系統(tǒng)分析人員&測試人員開會(huì)討論需求。系統(tǒng)分析人員寫出需求分析說明，并連同系統(tǒng)分析人員&測試人員&需求人員開會(huì)討論可行性。系統(tǒng)分析人員寫出詳細(xì)設(shè)計(jì)說明書，程式人員編碼，給出系統(tǒng)流程圖。交與測試人員，測試人員給出Bug統(tǒng)計(jì)表。
04. 您在以往的測試工作中都曾經(jīng)具體從事過哪些工作？其中最擅長哪部分工作？ 答：從事過write test plan，creation of test case，進(jìn)行功能測試，性能測試，編寫測試工具，文檔的管理等，比較擅長與寫測試用例和進(jìn)行功能測試。
05. 您所熟悉的軟件測試類型都有哪些？請(qǐng)?jiān)囍謩e比較這些不同的測試類型的區(qū)別與聯(lián)系（如功能測試、性能測試……）
答：有功能測試，性能測試，可靠性測試，安全性測試，負(fù)載測試，壓力測試，安裝/卸載測試，啟動(dòng)/停止測試，兼容性測試，互連測試，文檔測試，恢復(fù)測試，回歸測試，可使用性測試，容量測試。
功能測試只對(duì)軟件的功能是否滿足用戶需求來做測試。性能測試需要和壓力和負(fù)載測試聯(lián)合起來。
06. 請(qǐng)?jiān)囍容^一下黑盒測試、白盒測試、單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試的區(qū)別與聯(lián)系。
黑盒測試：把測試對(duì)象當(dāng)成一個(gè)黑盒子，測試人員完全不考慮邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程式的需求說明書來檢查程式的功能是否滿足它的功能說明。
白盒測試：把測試對(duì)象當(dāng)成一個(gè)透明的盒子，允許測試人員利用程序內(nèi)部邏輯結(jié)構(gòu)及相關(guān)信息，設(shè)計(jì)或選擇測試用例，對(duì)程式所有邏輯路徑進(jìn)行測試。
單元測試：白盒測試的一種，對(duì)軟件設(shè)計(jì)中的單元模塊進(jìn)行測試。
集成測試：在單元測試的基礎(chǔ)上，對(duì)單元模塊之間的連接和組裝進(jìn)行測試。 系統(tǒng)測試：在所有都考慮的情況下，對(duì)系統(tǒng)進(jìn)行測試。
驗(yàn)收測試：第三方進(jìn)行的確認(rèn)軟件滿足需求的測試。
07. 測試計(jì)劃工作的目的是什么？測試計(jì)劃工作的內(nèi)容都包括什么？其中哪些是最重要的？
答：測試計(jì)劃工作是對(duì)測試工作內(nèi)容的一個(gè)有效的組織和規(guī)劃，能保證測試工作有效的展開。測試計(jì)劃工作包括測試目標(biāo)，測試范圍的定義，測試方法的選擇，測試進(jìn)度里程碑，測試資源的有效配置和管理。
測試計(jì)劃工作也稱為測試策略，主要描述測試工程的總體方法和目標(biāo)，描述目前在進(jìn)行那一階段的測試（單元測試，集成測試，系統(tǒng)測試）以及每一階段內(nèi)進(jìn)行的測試種類（功能測試，性能測試等）確定測試范圍，生成測試數(shù)據(jù)等。
其中軟件計(jì)劃中的測試目標(biāo)最重要，他的軟件測試的所需要達(dá)成的最終結(jié)果。 08. 您認(rèn)為做好測試計(jì)劃工作的關(guān)鍵是什么？
答：1. 明確測試的目標(biāo)，增強(qiáng)測試計(jì)劃的實(shí)用性
2. 堅(jiān)持“5W”規(guī)則，明確內(nèi)容與過程，'what''why''when''where''how'
3. 采用評(píng)審和更新機(jī)制，保證測試計(jì)劃滿足實(shí)際需求
4. 分別創(chuàng)建測試計(jì)劃與測試詳細(xì)規(guī)格、測試用例
09. 您所熟悉的測試用例設(shè)計(jì)方法都有哪些？請(qǐng)分別以具體的例子來說明這些方法在測試用例設(shè)計(jì)工作中的應(yīng)用。
答：有黑盒和白盒兩種測試種類，黑盒有等價(jià)類劃分法，邊界分析法，因果圖法和錯(cuò)誤猜測法。白盒有邏輯覆蓋法，循環(huán)測試路徑選擇，基本路徑測試。
例子：在一次輸入多個(gè)條件的完整性查詢中。利用等價(jià)類劃分法則和邊界分析法則，首先利用等價(jià)類劃分法，可以一個(gè)或多個(gè)結(jié)果是OK的測試用例，然后確認(rèn)多個(gè)NG的測試用例，然后利用邊界值分析法，可以對(duì)結(jié)果分別是OK和NG的測試用例進(jìn)行擴(kuò)展和補(bǔ)充。
10. 您認(rèn)為做好測試用例設(shè)計(jì)工作的關(guān)鍵是什么？
答：測試用例設(shè)計(jì)工作的關(guān)鍵是對(duì)可行的和不可行的都要考慮。
1，輸入 2，詳細(xì)的操作步驟 3，預(yù)期輸出 4，實(shí)際輸出。
11. 請(qǐng)以您以往的實(shí)際工作為例，詳細(xì)的描述一次測試用例設(shè)計(jì)的完整的過程。
12. 您以往的工作中是否曾開展過測試用例的評(píng)審工作？如果有，請(qǐng)描述測試用例評(píng)審的過程和評(píng)審的內(nèi)容。
13. 您以往是否曾經(jīng)從事過性能測試工作？如果有，請(qǐng)盡可能的詳細(xì)描述您以往的性能測試工作的完整過程。
14. 您在從事性能測試工作時(shí)，是否使用過一些測試工具？如果有，請(qǐng)?jiān)囀鲈摴ぞ叩墓ぷ髟恚⒁砸粋�(gè)具體的工作中的例子描述該工具是如何在實(shí)際工作中應(yīng)用的。
答：有使用過LoadRunner,該工具能夠錄制測試人員的操作步驟，然后對(duì)這個(gè)操作步驟模擬出多個(gè)用戶來播放出來。
1。Visural User Genertor創(chuàng)建腳本，選擇協(xié)議，錄制操作，編輯操作。
2。中央控制器（Controller）調(diào)度虛擬用戶。創(chuàng)建場景，選擇腳本，建立虛擬用戶，設(shè)計(jì)shedual，設(shè)置ip spoofer。
3。運(yùn)行腳本。分析shedual。
4。分析測試結(jié)果。
15. 您認(rèn)為性能測試工作的目的是什么？做好性能測試工作的關(guān)鍵是什么？
答：性能測試工作的目的是檢查系統(tǒng)是否滿足在需求說明書中規(guī)定的性能，性能測試常常需要和強(qiáng)度測試結(jié)合起來，并常常要求同時(shí)進(jìn)行軟件和硬件的檢測。
性能測試主要的關(guān)注對(duì)象是響應(yīng)時(shí)間，吞吐量，占用內(nèi)存大�。ㄝo助存儲(chǔ)區(qū)），處理精度等。
16. 在您以往的工作中，一條軟件缺陷（或者叫Bug）記錄都包含了哪些內(nèi)容？如何提交高質(zhì)量的軟件缺陷（Bug）記錄？
答：檢測時(shí)間，系統(tǒng)環(huán)境，硬體環(huán)境，嚴(yán)重程度，程式版本，確認(rèn)人，功能模塊，問題描述，詳細(xì)操作步驟，是否會(huì)重現(xiàn)。
問題描述和詳細(xì)操作步驟要盡可能的詳細(xì)。Bug應(yīng)該盡量用書面語，對(duì)與嚴(yán)重程度比較高的缺陷要在相同環(huán)境下在測試一遍。
在C/S模式下，如果條件滿足可以使用替換法來確認(rèn)是client端的問題還是server端的問題。
http://www.spasvo.com/html/ceshi/20090918-1114.html
1. 你如何在pocket pc 上TEST 你的程序. 你考慮了哪些方面.
2. 如果將你的程序的語言擴(kuò)展到非英語,例如中文, 你如何測試.
3. 給你一個(gè)COCAN, 你如何測試(解釋說就是罐裝的可口可樂).
4. 當(dāng)你的程序遇到BUG的時(shí)候，你選擇怎樣處理.
5. 你如何isolation 你程序里的BUG.
6. 給你一個(gè)產(chǎn)品有10個(gè)functionality,如果時(shí)間緊迫, 只能測其中的5個(gè), 你如何選擇.
其它相關(guān)：
如果別人問我這些題目，我想我會(huì)大致這樣回答，各位從事軟件測試的同志們幫我看看回答的怎么樣。
01. 為什么要在一個(gè)團(tuán)隊(duì)中開展軟件測試工作？
答：軟件測試在整個(gè)一個(gè)團(tuán)隊(duì)中占有非常重要的地位，具體來說就是測試是一個(gè)發(fā)現(xiàn)軟件錯(cuò)誤的過程，執(zhí)行軟件測試會(huì)以最少的人力和時(shí)間，系統(tǒng)的找到軟件存在的缺陷和錯(cuò)誤，建立起開發(fā)人員和使用者對(duì)軟件的信心。
02. 您是否了解以往所工作的企業(yè)的軟件測試過程？如果了解，請(qǐng)?jiān)囀鲈谶@個(gè)過程中都有哪些工作要做？分別由哪些不同的角色來完成這些工作？
答：軟件測試部門配合系統(tǒng)分析人員軟件需求分析討論，并根據(jù)需求說明書制定《項(xiàng)目測試計(jì)劃》，編寫測試用例，建立測試環(huán)境。
軟件測試人員負(fù)責(zé)軟件開發(fā)部門的新產(chǎn)品測試及原有產(chǎn)品的升級(jí)測試，負(fù)責(zé)軟件問題解決過程跟蹤，負(fù)責(zé)軟件開發(fā)文檔開發(fā)工作的規(guī)范化及管理開發(fā)部門的產(chǎn)品文檔，制作用戶手冊(cè)及操作手冊(cè)，負(fù)責(zé)產(chǎn)品的上線測試，監(jiān)督軟件開發(fā)過程的執(zhí)行，提高產(chǎn)品質(zhì)量。
03. 您是否了解以往所工作的企業(yè)的軟件開發(fā)過程？如果了解，請(qǐng)?jiān)囀鲆粋�(gè)完整的開發(fā)過程需要完成哪些工作？分別由哪些不同的角色來完成這些工作？（對(duì)于軟件測試部分，可以簡述）
答：需求人員連同系統(tǒng)分析人員&測試人員開會(huì)討論需求。系統(tǒng)分析人員寫出需求分析說明，并連同系統(tǒng)分析人員&測試人員&需求人員開會(huì)討論可行性。系統(tǒng)分析人員寫出詳細(xì)設(shè)計(jì)說明書，程式人員編碼，給出系統(tǒng)流程圖。交與測試人員，測試人員給出Bug統(tǒng)計(jì)表。
04. 您在以往的測試工作中都曾經(jīng)具體從事過哪些工作？其中最擅長哪部分工作？
答：從事過write test plan，creation of test case，進(jìn)行功能測試，性能測試，編寫測試工具，文檔的管理等，比較擅長與寫測試用例和進(jìn)行功能測試。
軟件測試工程師試題
【軟件測試試題庫】相關(guān)文章：
軟件測試實(shí)習(xí)日記08-05
軟件測試個(gè)人總結(jié)01-25
軟件測試實(shí)習(xí)心得11-08
軟件測試面試經(jīng)驗(yàn)03-13
軟件測試個(gè)人總結(jié)05-19
軟件測試實(shí)習(xí)日記09-26
軟件測試的個(gè)人總結(jié)01-10
軟件測試培訓(xùn)心得04-26
軟件測試報(bào)告05-01
軟件測試個(gè)人總結(jié)04-25