1、一、 談?wù)劻私獾臏y試流程及工具一般測試流程：1. 需求分析階段：只要就是對業(yè)務(wù)的學(xué)習(xí)，分析需求點(diǎn)。2. 測試計(jì)劃階段： 測試組長就要根據(jù) SOW開始編寫測試計(jì)劃，其中包括人員， 軟件硬件資源，測試點(diǎn)，集成順序，進(jìn)度安排和風(fēng)險(xiǎn)識(shí)別等內(nèi)容。3. 測試設(shè)計(jì)階段： 測試方案一般由對需求很熟的高資深的測試工程師設(shè)計(jì)， 測試 方案要求根據(jù) SRS上的每個(gè)需求點(diǎn)設(shè)計(jì)出包括需求點(diǎn)簡介，測試思路和詳細(xì) 測試方法三部分的方案。測試方案編寫完成后也需要進(jìn)行評審。4. 測試方案階段：主要是對測試用例和規(guī)程的設(shè)計(jì)。 測試用例是根據(jù)測試方案 來編寫的，通過測試方案階段，測試人員對整個(gè)系統(tǒng)需求有了詳細(xì)的理解。 這時(shí)開始編寫

2、用例才能保證用例的可執(zhí)行和對需求的覆蓋。 測試用例需要包括測 試項(xiàng)，用例級(jí)別，預(yù)置條件，操作步驟和預(yù)期結(jié)果。其中操作步驟和預(yù)期結(jié)果需 要編寫詳細(xì)和明確。 測試用例應(yīng)該覆蓋測試方案， 而測試方案又覆蓋了測試需求 點(diǎn)，這樣才能保證客戶需求不遺漏。同樣，測試用例也需要評審。5. 測試執(zhí)行階段：執(zhí)行測試用例， 及時(shí)提交有質(zhì)量的 Bug和測試日報(bào)，測試報(bào)告 等相關(guān)文檔。流程： 需求分析測試計(jì)劃測試設(shè)計(jì)測試環(huán)境搭建測試執(zhí)行測試記錄缺陷 管理軟件評估 RTM.測試工具：C/S 及 B/S 架構(gòu)相關(guān)的軟件產(chǎn)品， 那么對不同操作系統(tǒng)， 如 Windows系列、unix 、 linux 甚至蘋果 OS等 測試環(huán)境

3、都是必須的 常用的軟件測試工具分為： 開源測試工具 ：開源測試管理工具： Bugfree 、 Bugzilla 、TestLink 、 mantis 開源功能自動(dòng)化測試工具： Watir 、Selenium 、 MaxQ、 WebInject 開源性能自動(dòng)化測試工具： Jmeter 、OpenSTA、DBMonster、TPTEST、Web ApplicationLoadSimulatorTestDirector ：企業(yè)級(jí)測試管理工具， 也是業(yè)界第一個(gè)基于 Web的測試管 理系統(tǒng)。Quality Center ：基于 Web的測試管理工具，可以組織和管理應(yīng)用程序測 試流程的所有階段，包括指定測

4、試需求、計(jì)劃測試、執(zhí)行測試和跟蹤缺陷。QuickTest Professional ：用于創(chuàng)建功能和回歸測試。LoadRunner ：預(yù)測系統(tǒng)行為和性能的負(fù)載測試工具。套題一、選擇 ：1. 從是否需要被執(zhí)行測試軟件的角度，軟件測試可分為哪兩種？（ B）A. 黑、白盒（軟件測試用例設(shè)計(jì)方法角度） B. 靜、動(dòng)態(tài) C. 單、集 （策略和過 程）2. 下列哪一項(xiàng)不是白盒測試？（ C） A.單元測試 B. 集成測試 C. 系統(tǒng)測試 D. 回歸測試3. 計(jì)算機(jī)環(huán)路復(fù)雜度（計(jì)算方法）（重點(diǎn)：選擇 簡答）V（G）=簡單判定節(jié)點(diǎn)數(shù) + 1 ; V（G） = E-N+2 ; V（G）=封閉區(qū)域數(shù) + 1 （記住

5、這三個(gè)公式）4. 屬于黑盒測試的方法？ （C）A.基于基本路徑 B. 控制流 C. 基于用戶需求測試 D. 邏輯覆蓋（ 基于用戶需求的測試 , 功能圖分析方法， 等價(jià)類劃分方法， 邊界值分析方法， 錯(cuò) 誤推測方法， 因果圖方法， 判定表驅(qū)動(dòng)分析方法， 正交實(shí)驗(yàn)設(shè)計(jì)方法和功能圖分 析方法等。 ）5. 測試的報(bào)告由五部分。 答：首頁、引言部分、測試概要、測試結(jié)果及缺陷分析、測試結(jié)論與建議。6. 單元測試環(huán)境由三部分構(gòu)成？ 答：所測模塊和與它相關(guān)的驅(qū)動(dòng)模塊及樁模塊共同構(gòu)成了一個(gè)“測試環(huán)境”7. 單元測試中綜合測試主要是考慮哪些方式？ 答：自頂向下的單元測試策略、自底向上的單元測試策略。8. 不是軟件

6、實(shí)施活動(dòng)的進(jìn)入準(zhǔn)則？ （D） A.需求工件已經(jīng)被基線化 B. 詳細(xì)設(shè)計(jì)工件已經(jīng)被基線化 C. 構(gòu)架工件已經(jīng)被基 線化 D. 項(xiàng)目階段成果及被基線化9. 確定單元測試指導(dǎo)的基本方針？ （） （3 個(gè)，選擇其中不是的）答： 能夠自身編譯的最小程序塊， 單一過程 / 函數(shù)（獨(dú)立） ，由一個(gè)人完成的小規(guī) 模工作10. 對于自動(dòng)化測試成本從高到底的排序 ，下列描述正確的是？ （A）（PPT6 七 章） （進(jìn)行排序 ）A. GUI ，編譯器，用戶圖形11. 軟件測試是軟件開發(fā)的重要環(huán)節(jié)之一。 按照軟件開發(fā)過程可分為： 單元測試、 集成測試、系統(tǒng)測試、域測試等。12. 軟件測試的任務(wù) 發(fā)現(xiàn)、改正軟件錯(cuò)誤（找

7、錯(cuò)，修正）13. 下面哪一項(xiàng)測試步驟中需要進(jìn)行局部數(shù)據(jù)結(jié)構(gòu)測試？（ A） A.單元測試 B. 集成測試 C. 確認(rèn)測試 D. 系統(tǒng)測試14. 白盒測試是根據(jù)程序的（ C）來選設(shè)計(jì)測試用例？A.功能 B. 性能 C. 內(nèi)部邏輯 D. 內(nèi)部數(shù)據(jù)15. 單元測試的終止的標(biāo)準(zhǔn)（ 3 個(gè) ）（ PPT47 三章）1. 硬件資源不足或故障造成軟件運(yùn)行無法運(yùn)行；2. 軟件運(yùn)行后無法正確顯示；3. 所有功能測試均已經(jīng)完成。16. 軟件測試是對系統(tǒng)逆向求證的過程， 集成測試對應(yīng)的過程中單元測試的過程 A.需求設(shè)計(jì) B. 概要設(shè)計(jì) C. 詳細(xì)設(shè)計(jì) D. 編碼實(shí)現(xiàn)17. 單元測試主要測試技術(shù)不包括？（ B）（ PP

8、T12 三章） A.白盒 B. 功能 C. 靜態(tài) D. 以上都不是18. 環(huán)路復(fù)雜度公式哪個(gè)不是？（）V（G）=簡單判定節(jié)點(diǎn)數(shù) + 1 ; V（G） = E-N+2 ; V（G）= 封閉區(qū)域數(shù) + 1 （記住這三 個(gè)公式）19. 如果一個(gè)產(chǎn)品中次嚴(yán)重缺陷基本完成修復(fù)并且通過了復(fù)測， 這個(gè)階段的產(chǎn)品 是（ B）A.阿爾法版 B.beta 版 C.正版 D.以上都不是20. 自底向上方法需要寫 （）A. 驅(qū)動(dòng)程序 樁程序 驅(qū)動(dòng)程序和樁程序 兩個(gè)都不是21. （A）的目的是對最終軟件系統(tǒng)進(jìn)行全面的測試確保最終軟件系統(tǒng)產(chǎn)品滿足 需求。系統(tǒng)測試 集成測試 單元測試 功能測試22. 測試用例的 4 個(gè)關(guān)鍵

9、元素。（1）被測單元模塊初始狀態(tài)聲明， 即測試用例的開始狀態(tài) （僅適用于被測單元維 持了調(diào)用中間狀態(tài)的情況 ） ；（2）被測單元的輸入，包含由被測單元讀入的任何外部數(shù)據(jù)值；（3）該測試用例實(shí)際測試的代碼， 用被測單元的功能和測試用例設(shè)計(jì)中使用的分 析來說明，如：單元中哪一個(gè)決策條件被測試；（4）測試用例的期望輸出結(jié)果（在測試進(jìn)行之前的測試說明中定義）。23. 目前主要的單元測試的方法 （A.基本路徑測試 B. 等價(jià)類劃分 /邊界值分析測 試 C. 覆蓋測試 D. 循環(huán)測試 E. 數(shù)據(jù)流測試 F. 程序插樁測試 G 變異測試）從中 選。24. 哪個(gè)方法根據(jù)輸出輸入依賴關(guān)系設(shè)計(jì)的測試用例？（ C）

10、？ A.路徑 B.等價(jià)類 C.因果圖 D.歸納25. 有一組測試用例使得每一個(gè)被測試用例的分支覆蓋至少被執(zhí)行一次， 它滿足 的覆蓋標(biāo)準(zhǔn)（ B）。（ PPT22 二章）A. 語句覆蓋 B. 判定覆蓋 C. 條件覆蓋 D. 路徑覆蓋二、填空：1. 單元測試中對類進(jìn)行測試有 3 個(gè)“定義引用對”（方法內(nèi)部定義 - 引用對 方法間定義-引用對 類內(nèi)部定義-引用對）。（ PPt37 三章）2. 測試的主要目標(biāo)，不再只是找出其缺陷，而是證明其（性能）。3. 壓力測試又稱強(qiáng)度測試，是在（各種資源超負(fù)荷）情況下，觀察系統(tǒng)的運(yùn)行 情況。4. （缺陷跟蹤工具）是管理工具使用最多的。5. 集成測試劃分為 5 個(gè)階段

11、（制定集成測試的計(jì)劃、設(shè)計(jì)集成測試、實(shí)施集成 測試、執(zhí)行集成測試、評估集成測試）。6. 根據(jù)軟件生命周期中的定義，可以把自動(dòng)化測試工具劃分 3 大類（白盒測試 工具、黑盒測試工具、測試管理工具）。7. 對類進(jìn)行測試時(shí)，類之間的關(guān)系 6 類（關(guān)聯(lián) 泛化 實(shí)現(xiàn) 依賴 聚合 組合）。 每種不同符號(hào)來表示，并分別用（私有的“ - ”、公有的“ +”、保護(hù)的“ #”） 三個(gè)關(guān)鍵字來修飾類。8. 白盒測試工具針對代碼進(jìn)行的工具，測試中發(fā)現(xiàn)的缺陷可以定義到代碼級(jí)， 根據(jù)測試工具原理的不同，又可以分為靜態(tài)測試工具和動(dòng)態(tài)測試工具。9. 黑盒測試工具包括（功能測試工具、性能測試工具）。10. 軟件開發(fā)的基本過程（

12、需求分析、設(shè)計(jì)、實(shí)現(xiàn)、測試、維護(hù)）。11. 單元測試的策略 （自頂向下的單元測試策略、 自底向上的單元測試策略和孤 立的單元測試策略）。12. 集成測試的工作開展更多站在測試工作人員的角度上； 系統(tǒng)測試站在用戶 的角度上。13. 對面向?qū)ο髞碚f，按照集成的粒度不同， 可把集成測試分為（類間集成測試 類內(nèi)集成測試）。14. 類測試用例中， 基于 3 個(gè)標(biāo)準(zhǔn)（基于狀態(tài)的覆蓋率、 基于限制的覆蓋率和基 于代碼的覆蓋率）。（ PPT13 六章）15. 哪一個(gè)不屬于增量式集成？ 答案：大爆炸集成17. 單元測試中對類進(jìn)行三級(jí)測試（方法內(nèi)部測試、方法間測試、類內(nèi)部測試） PPT36 三章18. 目前單元測

13、試主要的方法：基于路徑測試，等價(jià)類劃分 / 邊界值分析測試， 覆蓋測試，循環(huán)測試，數(shù)據(jù)流測試，程序插樁測試，變異測試。三、判斷：1. 發(fā)現(xiàn)錯(cuò)誤是軟件測試的目的。 （錯(cuò)）2. 白盒測試可以找出軟件遺漏功能和代碼錯(cuò)誤功能。（ PPT47 二章） （錯(cuò)）3. 在設(shè)計(jì)測試用例時(shí)，應(yīng)包括合理的應(yīng)用條件和不合理的應(yīng)用條件。 （對）4. 軟件缺陷一定是由編碼引起的錯(cuò)誤。 （錯(cuò)）5. Bata 測試是軟件多個(gè)用戶在實(shí)際。多個(gè)測試。 （對）6. 系統(tǒng)測試屬白盒測試。 （黑盒） （錯(cuò)）7. 手工測試可以達(dá)到好的系統(tǒng)化測試。 （對）8. 功能測試屬于白盒測試的技術(shù)范疇。 （錯(cuò)）9. 文檔測試是對系統(tǒng)提交給用戶的文檔

14、進(jìn)行驗(yàn)證，并不是一般性的審查活動(dòng)P35 5 （對）四、大題1. 計(jì)算環(huán)路復(fù)雜度方法哪些 ？ （要求寫成 3 個(gè)公式，一個(gè)公式 2 分）答： V（G）=簡單判定節(jié)點(diǎn)數(shù) + 1 ; V（G） = E-N+2 ; V（G）=封閉區(qū)域數(shù) + 12. 基于狀態(tài)測試的主要步驟？（ PPT32 三章）答： 依據(jù)設(shè)計(jì)文檔，或者通過分析對象數(shù)據(jù)成員的取值空間 （笛卡爾積 ），得 到被測試類的狀態(tài)轉(zhuǎn)移圖；給被測試的類加入用于設(shè)置和檢查對象狀態(tài)的新方法 , 導(dǎo)出對象的邏輯狀態(tài)； 對于狀態(tài)轉(zhuǎn)移圖中的每個(gè)狀態(tài)， 確定該狀態(tài)是哪些方法的合法起始狀態(tài)， 即在 該狀態(tài)時(shí)，對象允許執(zhí)行哪些操作；在每個(gè)狀態(tài)，從類中方法的調(diào)用關(guān)系

15、圖最下層開始，逐一測試類中的方法； 測試每個(gè)方法時(shí)， 根據(jù)對象當(dāng)前狀態(tài)確定出對方法的執(zhí)行路徑有特殊影響的參 數(shù)值，將各種可能組合作為參數(shù)進(jìn)行測試。3. Bug 的種類有哪些？答：需求階段的 BUG，分析設(shè)計(jì)階段的 BUG，設(shè)計(jì)階段的 BUG，實(shí)現(xiàn)階段的 BUG， 配置階段的 BUG，短視將來的 BUG，靜態(tài)文檔的 BUG 。4. 自動(dòng)化測試的缺點(diǎn)？（ 5 點(diǎn)）答： 1、自動(dòng)化測試不能取代手工測試， 測試主要還是要靠人工的。2、新缺陷越多，自動(dòng)化測試失敗的幾率就越大。3、工具本身不具有想象力4、技術(shù)問題、組織問題、腳本維護(hù)5、測試工具與其他軟件的互操作性5. 選擇手動(dòng)和自動(dòng)化測試，為了作出一個(gè)合

16、理的決定，需要做哪些方面假設(shè)？ （7 個(gè)）答： 1 擁有穩(wěn)定的自動(dòng)化測試技術(shù)支持。 2兩種極端的可能性：一種就是無需人工干預(yù)的完全自動(dòng)化測試，另一種就是 只運(yùn)行一次就廢棄的人工測試。3自動(dòng)化測試和手工測試都可行（但事實(shí)并非如此）。 4測試是通過外部接口完成的（黑盒測試）。5不要求必須進(jìn)行自動(dòng)化測試。 6測試已經(jīng)設(shè)計(jì)好之后，再?zèng)Q定是否進(jìn)行自動(dòng)化測試。7有一定的時(shí)間用于完成測試，并且在這段時(shí)間里完全有可能把測試做好。6. 集成測試分析方法有哪些？答：體系結(jié)構(gòu)分析 模塊分析 接口分析 風(fēng)險(xiǎn)分析 可測試性分析 集成測試策略 分析7. 編寫類測試驅(qū)動(dòng)程序的方法有很多種， 以 Java語言為例來說明， 測

17、試驅(qū)動(dòng)程 序設(shè)計(jì)的結(jié)構(gòu)，并簡要說明其優(yōu)缺點(diǎn)。（ PPT15 六章）答：1.在 main方法中寫入需要運(yùn)行的測試用例，即實(shí)現(xiàn) main方法，然后編譯、 執(zhí)行該類。缺點(diǎn)：不利于維護(hù)和復(fù)用，交付時(shí)，逐個(gè)剔除代碼2. 在類中實(shí)現(xiàn)一個(gè)靜態(tài)測試方法， 通過調(diào)用該測試方法來收集每個(gè)測試用例的執(zhí) 行結(jié)果。缺點(diǎn)：同 1.3. 實(shí)現(xiàn)獨(dú)立的測試類，它的職責(zé)是執(zhí)行并收集每個(gè)測試用例的結(jié)果。 優(yōu)點(diǎn)：可復(fù)用，支持回歸測試缺點(diǎn)：必須創(chuàng)建新類，關(guān)注被測試類的變化8. 增量式集成和非增量式集成的概念和舉例。？ 答：非增量式測試： 就是分別對系統(tǒng)中每個(gè)模塊進(jìn)行單元測試， 然后將所有模塊 按照層次結(jié)構(gòu)組裝到一起進(jìn)行測試，最終得到所

18、要求的軟件。例如：大爆炸集成增量式集成 （ 或組裝） ：先對一個(gè)個(gè)模塊進(jìn)行模塊測試， 然后在組裝過程中邊連接 邊測試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題。例如：自頂向下集成和自底向上集成9. 制定集成測試計(jì)劃時(shí)間，一般安排在概要設(shè)計(jì)評審?fù)ㄟ^后大約一個(gè)星期的時(shí) 候一、計(jì)劃階段 制定集成測試計(jì)劃時(shí)間：一般安排在概要設(shè)計(jì)評審?fù)ㄟ^后大約一個(gè)星期的時(shí)候， 參考需求規(guī)格說明書、概要設(shè)計(jì)文檔、產(chǎn)品開發(fā)計(jì)劃時(shí)間表來制定。二、設(shè)計(jì)階段制定集成測試設(shè)計(jì)時(shí)間： 一般在詳細(xì)設(shè)計(jì)開始時(shí)， 就可以著手進(jìn)行。 可以把需要 規(guī)格說明書、概要設(shè)計(jì)、集成測試計(jì)劃文檔作為參考依據(jù)。10. 列舉出圖中三個(gè)模塊， 寫出全部模塊執(zhí)行路徑， 最后

19、給出其 MM路徑（書 162 頁）1. 源節(jié)點(diǎn)： 程序中的源節(jié)點(diǎn)是指程序執(zhí)行開始或重新開始處的語句片斷。 A：1，5節(jié)點(diǎn) B：1，3節(jié)點(diǎn) C：1節(jié)點(diǎn)2匯節(jié)點(diǎn)： 匯節(jié)點(diǎn)是程序執(zhí)行結(jié)束處的語句片斷。 這里轉(zhuǎn)移控制到其它單元的 節(jié)點(diǎn)也是匯節(jié)點(diǎn)。 A：4，6節(jié)點(diǎn) B：2，4節(jié)點(diǎn) C：5節(jié)點(diǎn)3模塊執(zhí)行路徑 模塊執(zhí)行路徑是以源節(jié)點(diǎn)開始、 以匯節(jié)點(diǎn)結(jié)束的一系列語句， 中間沒有插入?yún)R節(jié) 點(diǎn)。在圖 4-12 中有七條模塊執(zhí)行路徑： 圖 4-12 跨三個(gè)單元的 MM路- 徑 模塊執(zhí)行路徑如下：MEP（A，1）=1，2，3，6MEP（A，2）=1，2，4MEP（A，3）=5，6MEP（B，1）=1，2MEP（B，2

20、）=3，4MEP（C，1）=1，2，4，5MEP（C，1）=1，3，4，54. 消息消息是一種程序設(shè)計(jì)語言機(jī)制， 通過這種機(jī)制可以把控制從一個(gè)單元轉(zhuǎn)移到另一 個(gè)單元。5. MM-路徑（Method Message Path） 是穿插出現(xiàn)模塊執(zhí)行路徑和消息的序列。如 圖 4-12 中的粗線所示， 代表模塊 A 調(diào)用模塊 B，模塊 B 調(diào)用模塊 C，這就是一個(gè) MM路- 徑，可用圖 4-13 表示。 對于傳統(tǒng)軟件來說， MM路- 徑永遠(yuǎn)是從主程序開始， 在主程序中結(jié)束。MM路- 徑如下：11. 設(shè)一個(gè)控制圖如下，請給出其環(huán)路復(fù)雜度和基本路徑 環(huán)路復(fù)雜度： 5基本路徑： 路徑 1：123561213

21、15 路徑 2：1245612 1315 路徑 3：12357813 15 路徑 4：12457813 15 路徑 5：12357910 141315 路徑 6：12457910 141315 路徑 7：12357911 141315 路徑 8：12457911 14131512. 軟件測試活動(dòng)的生命周期測試周期分為計(jì)劃、設(shè)計(jì)、實(shí)現(xiàn)、執(zhí)行、總結(jié)。其中： 計(jì)劃：對整個(gè)測試周期中所有活動(dòng)進(jìn)行規(guī)劃，估計(jì)工作量、風(fēng)險(xiǎn)，安排人力物力 資源，安排進(jìn)度等；設(shè)計(jì)：完成測試方案，從技術(shù)層面上對測試進(jìn)行規(guī)劃； 實(shí)現(xiàn)：進(jìn)行測試用例和測試規(guī)程設(shè)計(jì)； 執(zhí)行：根據(jù)前期完成的計(jì)劃、方案、用例、規(guī)程等文檔，執(zhí)行測試用例。 總

22、結(jié)：記錄測試結(jié)果，進(jìn)行測試分析，完成測試報(bào)告。13. 三明治集成方法答： 1. 確定以哪一層為界來決定使用三明治集成策略（在 4-7 中，我們確定以 B模塊為界）；2. 對模塊 B 及其所在層下面的各層使用自底向上的集成策略；3. 對模塊 B 所在層上面的層次使用自頂向下的集成策略 ;4. 把模塊 B 所在層各模塊同相應(yīng)的下層集成；5. 對系統(tǒng)進(jìn)行整體測試。14. 集成測試可看著是體系結(jié)構(gòu)分析工作基礎(chǔ)之上的細(xì)化。 可從哪幾個(gè)角度進(jìn)行 ?？旆治?。答： 1 ）確定本次要測試的模塊；2）找出與該模塊相關(guān)的所有模塊，并且按優(yōu)先級(jí)對這些模塊進(jìn)行排列；3）從優(yōu)先級(jí)別最高的相關(guān)模塊開始，把被測模塊與其集成到

23、一起；4）然后依次集成其他模塊。三、性能測試需要注意的問題性能測試即測試軟件處理事務(wù)的速度，一是為了檢驗(yàn)性能是否符合需求， 二是為了得到某些性能數(shù)據(jù)供人們參考（例如用于宣傳）。有時(shí)人們關(guān)心測試的“絕對值”， 如數(shù)據(jù)送輸速率是每秒多少比特。 有時(shí) 人們關(guān)心測試的“相對值”，如某個(gè)軟件比另一個(gè)軟件快多少倍。 在獲取測試的“絕對值”時(shí)， 我們要充分考慮并記錄運(yùn)行環(huán)境對測試的影 響。例如網(wǎng)絡(luò)環(huán)境、 計(jì)算機(jī)主頻， 總線結(jié)構(gòu)和外部設(shè)備都可能影響軟件的 運(yùn)行速度。性能測試的一些注意事項(xiàng)：不要試圖讓人拿著鐘表去測時(shí)間， 應(yīng)當(dāng)編寫一段程序用于計(jì)算時(shí)間以及 相關(guān)數(shù)據(jù)。應(yīng)當(dāng)測試軟件在標(biāo)準(zhǔn)配置和最低配置下的性能。為了

24、排除干擾， 應(yīng)當(dāng)關(guān)閉那些消耗內(nèi)存、 占用 CPU的其它應(yīng)用軟件 （如 殺毒軟件）。不同的輸入情況會(huì)得到不同的性能數(shù)據(jù)， 應(yīng)當(dāng)分檔記錄。 例如傳輸文件 的容量從 100K到 1M可以分成若干等級(jí)。由于環(huán)境的波動(dòng)， 同一種輸入情況在不同的時(shí)間可能得到不同的性能數(shù) 據(jù)，可以取其平均值。四、健壯性測試是什么？目的是什么？健壯性是指在異常情況下， 軟件還能正常運(yùn)行的能力。 健壯性有兩層含義： 一是 容錯(cuò)能力，二是恢復(fù)能力。容錯(cuò)性測試通常構(gòu)造一些不合理的輸入來引誘軟件出錯(cuò)，例如：（1）輸入錯(cuò)誤的數(shù)據(jù)類型。如“猴”年“馬”月。（2）輸入定義域之外的數(shù)值。如上海人常說的“十三點(diǎn)” 粗暴一些方式俗稱“大猩猩”測

25、試法。 除了不能拳打腳踢嘴咬外， 什么招術(shù)都可 以使出來。例如在測試客戶機(jī)服務(wù)器模式的軟件時(shí)， 把網(wǎng)絡(luò)線拔掉， 造成通信 異常中斷?；謴?fù)測試重點(diǎn)考察一下幾項(xiàng)：（1）系統(tǒng)能否重新運(yùn)行；（2）有無重要的數(shù)據(jù)丟失；（3）是否毀壞了其它相關(guān)的軟件硬件。五、接口與路徑測試都包括哪些內(nèi)容？數(shù)據(jù)一般通過接口輸入和輸出， 所以接口測試是白盒測試的第一步。 每個(gè) 接口可能有多個(gè)輸入?yún)?shù)， 每個(gè)參數(shù)有“典型值”、 “邊界值”、 “異常 值”之分， 所以輸入的組合數(shù)可能并不少。 根據(jù)接口的定義， 可以推斷某 種輸入應(yīng)當(dāng)產(chǎn)生什么樣的輸出。 輸出包括函數(shù)的返回值和輸出參數(shù)。 如果 實(shí)際輸出與期望的輸出不一致， 那么說明

26、程序有錯(cuò)誤。 白盒方式的接口測 試和黑盒方式的功能測試，其方法十分相似。 一個(gè)函數(shù)體內(nèi)的語句可能只有十幾條， 但邏輯路徑可能有成千上萬條。 想 遍歷測試幾乎是不可能的，不測試或者胡亂找?guī)讞l路徑測試卻又不行。 對于非嚴(yán)格系統(tǒng)而言， 在分析路徑方面化費(fèi)很多精力是不值得的。 我認(rèn)為 在構(gòu)造接口測試的同時(shí)已經(jīng)建立了測試路徑。 因?yàn)槊恳环N輸入將產(chǎn)生唯一 的輸出，輸入與輸出之間的路徑也是唯一的。 由于接口測試中的輸入是有 代表性的， 因此相應(yīng)的路徑也具有代表性， 不用得著費(fèi)煞苦心地去找測試 路徑。路徑測試的檢查表 數(shù)據(jù)類型、變量值、邏輯判斷、循環(huán)、內(nèi)存管理、文件 I/O 、錯(cuò)誤處理 由于接口測試是枚舉的，

27、 有可能漏掉某些狀況， 導(dǎo)致一些重要的路徑?jīng)]有 被測試。預(yù)防措施有： 觀察是否有程序語句從來沒有被執(zhí)行過。 如果發(fā)生在這種情況， 要么是程 序有錯(cuò)誤，存在無用的代碼；要么是接口測試不充分，漏掉了一些路徑。 要特別留意函數(shù)體內(nèi)的錯(cuò)誤處理程序塊 （如果存在的話） ，這是最易被人 疏忽的路徑，隱患最多。六、有了“黑盒”測試，為什么還要白盒測試呢？黑盒測試只能觀察軟件的外部表現(xiàn)， 即使軟件的輸入輸出都是正確的， 卻并不能 說明軟件就是正確的。 因?yàn)槌绦蛴锌赡苡缅e(cuò)誤的運(yùn)算方式得出正確的結(jié)果， 例如 “負(fù)負(fù)得正，錯(cuò)錯(cuò)得對”，只有白盒測試才能發(fā)現(xiàn)真正的原因。白盒測試能發(fā)現(xiàn)程序里的隱患，象內(nèi)存泄漏、誤差累計(jì)問

28、題。在這方面，黑盒 測試存在嚴(yán)重的不足。七、alpha 測試和 beta 測試的區(qū)別定義： alpha 測試是在用戶組織模擬軟件系統(tǒng)的運(yùn)行環(huán)境下的一種驗(yàn)收測試，由 用戶或第三方測試公司進(jìn)行的測試， 模擬各類用戶行為對即將面市的軟件產(chǎn)品進(jìn) 行測試，試圖發(fā)現(xiàn)并修改錯(cuò)誤。Beta測試是用戶公司組織各方面的典型終端用戶在日常工作中實(shí)際使用 beta 版 本，并要求用戶報(bào)告異常情況，提出批評意見。區(qū)別：兩者的主要區(qū)別是測試的場所不同。 Alpha 測試是指把用戶請到開發(fā)方的 場所來測試， beta 測試是指在一個(gè)或多個(gè)用戶的場所進(jìn)行的測試。 Alpha 測試的 環(huán)境是受開發(fā)方控制的，用戶的數(shù)量相對比較少

29、，時(shí)間比較集中。而 beta 測試 的環(huán)境是不受開發(fā)方控制的， 誰也不知道用戶如何折磨軟件， 用戶數(shù)量相對比較 多，時(shí)間不集中。一般地， alpha 測試先于 beta 測試執(zhí)行。通用的軟件產(chǎn)品需 要較大規(guī)模的 beta 測試，測試周期比較長。 如果產(chǎn)品通過了 beta 測試，那么就 可以正式發(fā)行了。八、回歸測試的概念及過程回歸測試：是指軟件系統(tǒng)被修改或擴(kuò)充 （如系統(tǒng)功能增強(qiáng)或升級(jí)） 后重新進(jìn)行的測試， 是為 了保證對軟件所做的修改沒有引入新的錯(cuò)誤而重新進(jìn)行的測試?；貧w測試過程：識(shí)別出軟件中被修改的部分從原基線測試用例庫 T 中，排除所有不再適用的測試用例， 確定對新版本依然有 效的測試用例，

30、建立新的基線測試用例庫 TN依據(jù)一定的策略從 TN中選擇測試用例測試被修改的軟件如果必要，生成新的測試用例集 T1，用于測試 TN無法充分測試的軟件部分用 T1 執(zhí)行修改后的軟件 第 2 和第 3 步測試驗(yàn)證修改是否破壞了現(xiàn)有的功能， 第 4 和第 5 步測試驗(yàn)證修改 工作本身回歸測試的一些觀念：回歸測試是指重復(fù)以前的全部或部分的相同測試。新加入測試的模組，可能對其他模組產(chǎn)生副作用， 故須進(jìn)行某些程度的回歸測試。回歸測試的重心，以關(guān)鍵性模組為核心。九、系統(tǒng)驗(yàn)收測試的內(nèi)容1）系統(tǒng)驗(yàn)收測試是在在系統(tǒng)測試完成后，項(xiàng)目最終交付前進(jìn)行。2）系統(tǒng)驗(yàn)收測試不是對系統(tǒng)的全面覆蓋，而是針對用戶的核心業(yè)務(wù)流程進(jìn)行

31、測 試。3）驗(yàn)收測試的執(zhí)行人員不是開發(fā)方的測試組成員， 是由用戶方的使用人員完成。4）驗(yàn)收可以由第三方專業(yè)化全覆蓋型技術(shù)測試團(tuán)隊(duì)測試。十、系統(tǒng)測試的定義及內(nèi)涵系統(tǒng)測試定義：系統(tǒng)測試是將通過集成測試的軟件，作為整個(gè)基于計(jì)算機(jī)系統(tǒng) 的一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素 結(jié)合在一起，在實(shí)際或者模擬運(yùn)行（使用）環(huán)境下，對計(jì)算機(jī)系統(tǒng)進(jìn)行一系列測 試。系統(tǒng)測試包含：功能測試、性能測試、壓力測試、容量測試、安全性測試、 GUI測試、 可用性測試（也叫易用性測試）、安裝測試、配置測試、異常測試 , 備份測試、 健壯性測試、文檔測試、在線幫助測試、網(wǎng)絡(luò)測試、穩(wěn)定性測試。十一、測

32、試人員在軟件開發(fā)過程中的任務(wù)？軟件測試目的1、測試的最終目的是為了避免錯(cuò)誤的發(fā)生， 確保應(yīng)用程序能夠正常高效的運(yùn)行；2、好的測試用例在于發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯(cuò)誤；3、成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯(cuò)誤的測試；4、好的測試工程師應(yīng)該做到不僅發(fā)現(xiàn)問題，還能夠幫助開發(fā)人員分析問題；測試人員在軟件開發(fā)過程中的任務(wù)：1、盡可能早的找出系統(tǒng)中的 Bug；2、避免軟件開發(fā)過程中缺陷的出現(xiàn)；3、衡量軟件的品質(zhì)，保證系統(tǒng)的質(zhì)量；4、關(guān)注用戶的需求，并保證系統(tǒng)符合用戶需求 軟件測試的原則：1、應(yīng)把“盡早和不斷地進(jìn)行軟件測試”作為軟件開發(fā)者的座右銘，實(shí)踐證明單 元測試能夠盡早發(fā)現(xiàn)問題，減少后期測試的錯(cuò)誤量。2、測試用例

33、應(yīng)由測試輸入數(shù)據(jù)、測試執(zhí)行步驟和與之對應(yīng)的預(yù)期輸出結(jié)果三部 分組成。3、應(yīng)當(dāng)避免由程序員檢查自己的程序。（指后期系統(tǒng)測試階段，不包括單元測 試）4、測試用例的設(shè)計(jì)要確保能覆蓋所有可能路徑。在設(shè)計(jì)測試用例時(shí)，應(yīng)當(dāng)包括 合理的輸入條件和不合理的輸入條件。不合理的輸入條件是指異常的，臨界的， 可能引起問題的輸入條件。5、充分注意測試中的群集現(xiàn)象。經(jīng)驗(yàn)表明，測試后程序殘存的錯(cuò)誤數(shù)目與該程 序中已發(fā)現(xiàn)的錯(cuò)誤數(shù)目或檢錯(cuò)率成正比。應(yīng)該對錯(cuò)誤群集的程序段進(jìn)行重點(diǎn)測 試。6、嚴(yán)格執(zhí)行測試計(jì)劃，排除測試的隨意性。測試計(jì)劃應(yīng)包括：所測軟件的功能，輸入和輸出，測試內(nèi)容，各項(xiàng)測試的進(jìn)度安 排，資源要求，測試資料，測試工

34、具，測試用例的選擇， 測試的控制方法和過程， 系統(tǒng)的配置方式， 跟蹤規(guī)則，調(diào)試規(guī)則，以及回歸測試的規(guī)定等等以及評價(jià)標(biāo)準(zhǔn)。7、應(yīng)當(dāng)對每一個(gè)測試結(jié)果做全面的檢查。8、妥善保存測試計(jì)劃，測試用例，出錯(cuò)統(tǒng)計(jì)和最終分析報(bào)告，為維護(hù)提供方便。軟件測試過程開始是單元測試， 集中對用源代碼實(shí)現(xiàn)的每一個(gè)程序單元進(jìn)行測試， 檢查各個(gè)程 序模塊是否正確地實(shí)現(xiàn)了規(guī)定的功能。集成測試把已測試過的模塊組裝起來， 主要對與設(shè)計(jì)相關(guān)的軟件體系結(jié)構(gòu)的構(gòu)造 進(jìn)行測試。確認(rèn)測試則是要檢查已實(shí)現(xiàn)的軟件是否滿足了需求規(guī)格說明中確定了的各種需 求，以及軟件配置是否完全、正確。系統(tǒng)測試把已經(jīng)經(jīng)過確認(rèn)的軟件納入實(shí)際運(yùn)行環(huán)境中， 與其它系統(tǒng)成

35、份組合在一 起進(jìn)行測試。十二、如何盡快找出軟件中的 bug1. 盡快熟悉軟件的需求和業(yè)務(wù)，只有熟悉了產(chǎn)品的業(yè)務(wù)流程、你才能迅速找出 軟件中存在的一些重要的缺陷2. 把自己當(dāng)成用戶，把自己當(dāng)成是用戶去使用該系統(tǒng)，比如在使用該系統(tǒng)過程 中是這樣操作的嗎？3. 善于懷疑，不要開發(fā)人員的能力4. 不要讓程序開發(fā)人員的觀點(diǎn)：“用戶不會(huì)進(jìn)行這樣的操作”而說服自己5. 使用完整的流程去測試軟件系統(tǒng)，有些子流程在單獨(dú)測試時(shí)沒有問題，但按 流程走的時(shí)候問題就可能出來了。十三、性能測試問題1. 如果 web服務(wù)器、數(shù)據(jù)庫以及網(wǎng)絡(luò)都正常，問題會(huì)出在哪里？ 這個(gè)問題可以在系統(tǒng)本身，還是在應(yīng)用服務(wù)器中的代碼。2. 如何

36、發(fā)現(xiàn) web服務(wù)器的相關(guān)問題？ 利用網(wǎng)絡(luò)資源的監(jiān)控， 我們可以找到的 Web服務(wù)器的性能。 利用這些監(jiān)測分析吞 吐量我們可以在 Web服務(wù)器上，點(diǎn)擊數(shù)每秒期間發(fā)生的情況下，一些 HTTP響應(yīng)每秒下載的人數(shù)頁每秒。3. 如何發(fā)現(xiàn)數(shù)據(jù)庫的相關(guān)問題？運(yùn)行“數(shù)據(jù)庫”的監(jiān)督和幫助下， “數(shù)據(jù)資源圖”我們可以找到數(shù)據(jù)庫有關(guān)的 問題。例如您可以指定您想要的資源來衡量的， 然后再運(yùn)行控制器和比你可以看 到數(shù)據(jù)庫的有關(guān)問題4. 解釋所有 web 錄制配置？5. 解釋一下覆蓋圖和關(guān)聯(lián)圖的區(qū)別？ 覆蓋圖：它覆蓋的內(nèi)容，這兩個(gè)圖表有著共同的 X軸。左 Y 軸的圖表顯示，合并 后的當(dāng)前圖的價(jià)值和權(quán)利 Y 軸顯示的價(jià)值，

37、 Y 軸的圖表是合并。關(guān)聯(lián)圖：圖的 Y軸的兩個(gè)圖表互相對抗。積極圖表的 Y軸成為 X - 軸的合并圖。 Y軸的圖表合并成為合并后的圖 Y 軸。34. 你如何設(shè)計(jì)負(fù)載？標(biāo)準(zhǔn)是什么？ 負(fù)荷試驗(yàn)計(jì)劃，以決定用戶數(shù)量，什么樣的機(jī)器，我們要使用和從那里運(yùn)行。它 是基于兩個(gè)重要文件， 工作分布圖和交易資料。 任務(wù)分布圖給我們的信息的用戶 人數(shù)為特定的交易和時(shí)間上的負(fù)荷。在高峰使用和場外的使用是決定從這個(gè)圖。 交易的個(gè)人資料給我們提供了一個(gè)有關(guān)交易的名字和他們的優(yōu)先級(jí)6. Vuser_init 中包括什么內(nèi)容？業(yè)務(wù)初始化內(nèi)容 Vuser_init action contains procedures to

38、login to a server.7. Vuser_end 中包括什么內(nèi)容？業(yè)務(wù)執(zhí)行場景 Vuser_end section contains log off procedures8. 什么是 think time ？ think_time 有什么用？“Think Time”顧名思義思考時(shí)間。 它效仿真實(shí)用戶在實(shí)際操作過程中的等待 時(shí)間。我們做性能測試，很多時(shí)候就要模擬這種狀態(tài)。例如：某系統(tǒng)，要求滿足 100 用戶同時(shí)在線操作，響應(yīng)時(shí)間在 5 秒。如果不設(shè)置 Think Time ，我覺得，你的 測試是失敗的。大家想想為什么？設(shè)置 Think Time 有兩種方式，一種是使用 Record

39、think time 在錄制過程中根 據(jù)實(shí)際等待時(shí)間自動(dòng)的寫入腳本。另一種是在腳本錄制結(jié)束后手動(dòng)加入到腳本 中。接下來我們詳細(xì)介紹。 思考時(shí)間是真實(shí)用戶在 action 之間等待的時(shí)間。 例 如：當(dāng)一個(gè)用戶從服務(wù)器接收到數(shù)據(jù)時(shí)， 用戶可能需要在響應(yīng)之前等待幾分鐘回 顧數(shù)據(jù)，這種推遲被稱為思考時(shí)間。9. 標(biāo)準(zhǔn)日志和擴(kuò)展日志的區(qū)別是什么？Standard Log Option ：選擇標(biāo)準(zhǔn)日志時(shí)，就會(huì)在腳本執(zhí)行過程中，生成函數(shù)的 標(biāo)準(zhǔn)日志并且輸出信息，供調(diào)試用。大型負(fù)載測試場景不用啟用這個(gè)選項(xiàng)。 擴(kuò)展日志包括警告和其他信息。 大型負(fù)載測試不要啟用該選項(xiàng)。 用擴(kuò)展日志選項(xiàng)， 可以指定哪些附加信息需要加

40、到擴(kuò)展日志中十四、測試用例在軟件測試中的作用？1、指導(dǎo)測試的實(shí)施。測試用例主要適用于集成測試、系統(tǒng)測試和回歸測試。2、規(guī)劃測試數(shù)據(jù)的準(zhǔn)備3、編寫測試腳本的”設(shè)計(jì)規(guī)格說明書”4、評估測試結(jié)果的度量基準(zhǔn)。 完成測試實(shí)施后需要對測試結(jié)果進(jìn)行評估， 并且 編制測試報(bào)告。 判斷軟件測試是否完成、 衡量測試質(zhì)量需要一些量化的結(jié)果。 例： 測試覆蓋率是多少、測試合格率是多少、重要測試合格率是多少，等等。5、分析缺陷的標(biāo)準(zhǔn)十五、套題一簡答題 （每道題 10）1. 測試的目標(biāo) ?：是為了盡可能多的發(fā)現(xiàn)程序中的缺陷。2. 測試的步驟？：單元測試 （模塊測試 ）. 集成測試. 系統(tǒng)測試. 調(diào)試. 系統(tǒng)的轉(zhuǎn)換與交付使

41、用3. 您認(rèn)為做好測試用例設(shè)計(jì)工作的關(guān)鍵是什么？白盒測試用例設(shè)計(jì)的關(guān)鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏輯結(jié)果 黑盒法用例設(shè)計(jì)的關(guān)鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。 不可能 做到完全測試，以最少的用例在合理的時(shí)間內(nèi)發(fā)現(xiàn)最多的問題 4您所熟悉的測試用例設(shè)計(jì)方法都有哪些？請分別以具體的例子來說明這些方 法在測試用例設(shè)計(jì)工作中的應(yīng)用。1）等價(jià)類劃分2）邊界值分析法3）錯(cuò)誤推測法4）因果圖方法5測試人員的職業(yè)素質(zhì)要求是什么？1）責(zé)任感2）溝通能力3）獨(dú)立的判斷和自學(xué)習(xí)能力4）耐心、自我督促5）團(tuán)隊(duì)精神 二選擇題（單選題）（每道題 5 分） 1軟件驗(yàn)收測試的合格通過準(zhǔn)則是：（） A軟件需

42、求分析說明書中定義的所有功能已全部實(shí)現(xiàn)， 性能指標(biāo)全部達(dá)到要求。 B 所有測試項(xiàng)沒有殘余一級(jí)、二級(jí)和三級(jí)錯(cuò)誤。C 立項(xiàng)審批表、需求分析文檔、設(shè)計(jì)文檔和編碼實(shí)現(xiàn)一致。D 驗(yàn)收測試工件齊全。答：B2軟件測試計(jì)劃評審會(huì)需要哪些人員參加？（）A項(xiàng)目經(jīng)理BSQA 負(fù)責(zé)人C配置負(fù)責(zé)人D測試組答：A3下列關(guān)于 alpha 測試的描述中正確的是：（）Aalpha 測試需要用戶代表參加Balpha 測試不需要用戶代表參加Calpha 測試是系統(tǒng)測試的一種Dalpha 測試是驗(yàn)收測試的一種答：D4測試設(shè)計(jì)員的職責(zé)有：（）A制定測試計(jì)劃B設(shè)計(jì)測試用例C設(shè)計(jì)測試過程、腳本D評估測試活動(dòng)答：C5軟件實(shí)施活動(dòng)的進(jìn)入準(zhǔn)則是

43、：（） A需求工件已經(jīng)被基線化B詳細(xì)設(shè)計(jì)工件已經(jīng)被基線化C構(gòu)架工件已經(jīng)被基線化 D項(xiàng)目階段成果已經(jīng)被基線化 答： C6關(guān)于軟件測試 ,以下（） 是正確的:A 測試只能證明缺陷 , 不能證明缺陷不存在B 開發(fā)人員測試自己的程序后 , 可作為該程序已經(jīng)通過測試的依據(jù)C 80%的缺陷聚集在 20%的模塊中 , 經(jīng)常出錯(cuò)的模塊改錯(cuò)后還會(huì)經(jīng)常出錯(cuò) 答：C三選擇題（多選題）（每道題 5 分）1. 測試的依據(jù)A. 需求說明 B. 技術(shù)規(guī)范 C. 安全規(guī)范 D. 個(gè)人能力答： A, B, C2. 軟件缺陷都包括什么？A. 軟件未達(dá)到客戶需求的功能和性能B. 軟件超出客戶需求的范圍C. 軟件出現(xiàn)客戶需求不能容忍的錯(cuò)誤D. 軟件的使用未能符合客戶的習(xí)慣和工作環(huán)境答： A,B,C,D3. 請對以下測試計(jì)劃做排序。A. 系統(tǒng)測試計(jì)劃 B. 驗(yàn)收測試計(jì)劃 C. 單元測試計(jì)劃 D. 回歸測試策略 （ 適用 的）E. 集成測試計(jì)劃答： C,E,A,B,D4. 缺陷度量分析包括以下哪種？A.缺陷分析 B. 缺陷數(shù)據(jù)統(tǒng)計(jì) C. 缺陷預(yù)防 D. 缺陷控制答：B,C十六、