【正文】 應(yīng)當(dāng)對(duì)每一個(gè)測試結(jié)果做全面的檢查。 ? 為了達(dá)到最佳的測試效果，應(yīng)該由獨(dú)立的第三方來從事測試工作。從 測試 是否針對(duì)系統(tǒng)的內(nèi)部結(jié)構(gòu)和具體實(shí)現(xiàn)算法的角度來看，可分為白盒 測試 和黑盒 測試 。 動(dòng)態(tài) 測試 是指通過運(yùn)行被測程序，檢查運(yùn)行結(jié)果與預(yù)期結(jié)果的差異，并分析運(yùn)行效率和健壯性等性能 。黑盒測試的方法有 若測試規(guī)劃基于產(chǎn)品的內(nèi)部結(jié)構(gòu)進(jìn)行測試，檢查內(nèi)部操作是否按規(guī)定執(zhí)行，軟件各個(gè)部分功能是否得到充分使用，則這種測試方法稱為白盒測試 (Whitebox Testing)方法。 1軟件測試項(xiàng)目從什么時(shí)候開始？為什么？ 軟件測試應(yīng)該在需求分析階段就介入 ,因?yàn)闇y試的對(duì)象不僅僅是程序編碼 ,應(yīng)該對(duì)軟件開發(fā)過程中產(chǎn)生的所有產(chǎn)品都測試 ,并且軟件缺陷存在放大趨勢 .缺陷發(fā)現(xiàn)的越晚 ,修復(fù)它所花費(fèi)的成本就越大 . 1 需求分析 的任務(wù)是什么？ 有什么作用？需求分析的過程和意 義？ 需求分析的 任務(wù) ： ? 深入描述軟件的功能和性能 ? 確定軟件設(shè)計(jì)的約束和軟件同其它系統(tǒng)元素的接口細(xì)節(jié) ? 定義軟件的其它有效性需求 需求分析的作用： 確定系統(tǒng)必須完成哪些工作，也就是對(duì)目標(biāo)系統(tǒng)提出完整、準(zhǔn)確、清晰、具體的要求。 (3) 編制需求分析階段的文檔 ? 軟件需求說明書 ? 數(shù)據(jù)要求說明書 ? 初步的用戶手冊(cè) ? 修改、完善與確定軟件開發(fā)實(shí)施計(jì)劃 (4) 需求分析評(píng)審 ? 系統(tǒng)定義的目標(biāo)是否與用戶的要求一致 。 ? 被開發(fā)項(xiàng)目的數(shù)據(jù)流與數(shù)據(jù)結(jié)構(gòu)是否足夠，確定 。 ? 開發(fā)的技術(shù)風(fēng)險(xiǎn)是什么 。 需求分析的意義： 軟件工程理論認(rèn)為，在軟件生命周期中，需求分析（ Requirements Analysis）是最重要的一個(gè)階段。（ 8 分） 測試需求 測試計(jì)劃 測試用例設(shè)計(jì) 執(zhí)行測試用例 結(jié)果分析 缺陷解決 回歸測試 1試敘述對(duì)一個(gè)軟件項(xiàng)目測試的全過程。測試人員完成測試計(jì)劃文檔，測試計(jì)劃包括的內(nèi)容上面有描述。 (5)測試人員搭建環(huán)境 (6)開發(fā)人員提交第一個(gè)版本，可能存在未完成功能，需要說明。 (9)如果有客戶反饋的問題，需要測試人員協(xié)助重現(xiàn)以及回歸測試。 黑盒測試 驗(yàn)收測試 Acceptance Testing 向用戶表明系統(tǒng)能夠按照預(yù)定要求那樣工作， 使系統(tǒng)最終可以正式發(fā)布或向用戶提供服務(wù)。 （ 1）單元測試：是指對(duì)軟件中的最小可測試單元進(jìn)行檢查和驗(yàn)證。 （ 4）系統(tǒng)測試： 指 的是將整個(gè)軟件系統(tǒng)看做一個(gè)整體進(jìn)行測試，包括對(duì)功能、性能，以及軟件所運(yùn)行軟件測試工程師面試寶典 15 的軟硬件環(huán)境進(jìn)行的測試。解決日期 ○15確認(rèn)內(nèi)容、結(jié)果及確認(rèn)人員簽字 /日期 ○ 16 遺留問題 ○ 17 測試總結(jié)和改進(jìn)建議 ○ 18 BUG 附件（給出相關(guān)的日志和截圖） ○ 19 備注 《 測試 總結(jié)報(bào)告 》 內(nèi)容包括： ? 引言 ： 編寫目的 、 背景 、 用戶群 、 參考資料 、 測試對(duì)象 、 測試階段 、 測試工具 ? 測試概要 ? 測試環(huán)境 軟硬件配置 、 網(wǎng)絡(luò)拓?fù)浞桨? ? 測試結(jié)果及發(fā)現(xiàn) 功能測試 ： 版本走勢 、 模塊分布 、 嚴(yán)重程度分布 、 BUG 引入階段分析 、 BUG 狀態(tài)分布圖 、 BUG 修改人分布圖 性能測試 ? 測試結(jié)論 ： 功能 、 易用性 、 效率 、 兼容性 ? 分析摘要 ： 能力 、 遺留缺陷的影響 、 建議 、 評(píng)價(jià) ? 度量 ： 資源消耗 、 缺陷密度 2按照瀑布模型軟件開發(fā)都分哪幾個(gè)階段？對(duì)應(yīng)的測試環(huán)節(jié)又分哪幾個(gè)階段？ 隨著全 面質(zhì)量管理思想在軟件開發(fā)領(lǐng)域的應(yīng)用，軟件測試也由最初的只針對(duì)軟件成品擴(kuò)展到了針對(duì)軟件半成品與過程產(chǎn)品的全過程測試。 2測試生命周期、測試過程分為幾個(gè)階段，以及各階段的含義？ 測試生命周期： 測試計(jì)劃、測試設(shè)計(jì) 、測試開發(fā)、測試執(zhí)行、缺陷跟蹤、測試評(píng)估 測試計(jì)劃 ：由測試經(jīng)理或測試組長根據(jù)《需求規(guī)格說明書》或界面原型來編寫測試計(jì)劃，生成《測試計(jì)劃》文檔。 缺陷跟蹤 ： 或稱 Bug 管理 ， 是產(chǎn)品開發(fā) (尤其是軟件開發(fā) )和維護(hù)過程中重要的輔助工具 ,用于跟蹤記錄產(chǎn)品的缺陷、需求變更等 ,作為溝通開發(fā)人員與測試人員、客戶的溝通的橋梁 ,保障產(chǎn)品軟件測試工程師面試寶典 16 開發(fā)流程更加協(xié)調(diào)。 （ 1） 單元測試 ：是指對(duì)軟件中的最小可測試單元進(jìn)行檢查和驗(yàn)證。 （ 4） 系統(tǒng)測試 ： 指的是將整個(gè)軟件系統(tǒng)看做一個(gè)整體進(jìn)行測試，包括對(duì)功能、性能，以及軟件所運(yùn)行的軟硬件環(huán)境進(jìn)行的測試。 （ 2） 集成測試 ：是單元測試的下一個(gè)階段，是指將通過測試的單元模塊組裝成系統(tǒng)或子系統(tǒng)，再進(jìn)行測試，重點(diǎn)測試不同模塊的接口部分， 主要注重接口的覆蓋 。相對(duì)的，對(duì)于產(chǎn)品類的軟件，就不要驗(yàn)收測試。 2你認(rèn)為軟件測試最關(guān)鍵的是哪個(gè)階段 ？ 使用過的測試方法有哪些 ？ 一般來講， 軟件測試分為 單元測試 、 集成測試 、系 統(tǒng)測試 、驗(yàn)收測試四個(gè)階段 ， 其中 單元測試是軟件測試的基礎(chǔ) 和關(guān)鍵 。 （ 2） 測試效果 ：根據(jù)以往的測試經(jīng)驗(yàn)來看，單元測試的效果是非常明顯的，首先它是測試階段的基礎(chǔ)，做好了單元測試，在做后期的集成測試和系統(tǒng)測試時(shí)就很順利。比如在單元測試時(shí)發(fā)現(xiàn) 1 個(gè)問題需要 1 個(gè)小時(shí)，則在集成測試時(shí)發(fā)現(xiàn)該問題需要 2 個(gè)小時(shí)，在系統(tǒng)測試時(shí)發(fā)現(xiàn)則需要 3 個(gè)小時(shí)，同理還有定位問題和解決問題的費(fèi)用也是成倍數(shù)上升的，這就是我們要盡可能早的排除盡可能多的 bug 來減少后期成本的因素之一。從 測試 是否針對(duì)系統(tǒng)的內(nèi)部結(jié)構(gòu)和具體實(shí)現(xiàn)算法的角度來看，可分為白盒 測試 和黑盒 測試 。 2什么是測試評(píng)估，測試評(píng)估的范圍是什么？ 測試評(píng)估 ： 是指對(duì)測試過程中的各種測試現(xiàn)象和結(jié)果進(jìn)行記錄、分析和評(píng)價(jià)的活動(dòng)。 工作版本由一個(gè)或多個(gè)構(gòu)件（通常為可執(zhí)行構(gòu)件）構(gòu)成，一 般都是通過編譯和鏈接源代碼的處理過程從其他構(gòu)件中構(gòu)建的 ， 其目在于交付一個(gè)運(yùn)行時(shí)功能和系統(tǒng)性能的可測試子集。 工作版本既可以是系統(tǒng)的可操作版本，也可以是具有最終產(chǎn)品部分功能的系統(tǒng)組成部分。包含了產(chǎn)品概述、測試策略、測試方法、測試區(qū)域、測試配置、測試周期、測試資源、測試交流、風(fēng)險(xiǎn)分析等內(nèi)容。 在軟件測試過程中，測試腳本通常以文本形式存在，由測試腳本組織用戶所施加的一系列軟件執(zhí)行動(dòng)作， 即一個(gè)測試腳本可以實(shí)現(xiàn)一個(gè)或多個(gè)測試用例的操作。 編寫 測試用例 的依據(jù) ： 軟件需求 即用戶對(duì)軟件的實(shí)際操作和業(yè)務(wù)流程 無疑是派生測試用例重要來源，測試人員根據(jù)《需求規(guī)格說明書》或是界面原型來設(shè)計(jì) 《 測試用例》 ， 但許多情形下這還不夠，項(xiàng)目風(fēng)險(xiǎn)、有關(guān)約束、特定技術(shù)、變更請(qǐng)求（發(fā)現(xiàn)的缺陷或錯(cuò)誤）等都可能是開發(fā)測試用例的參考依據(jù)。 ? 邊界值分析方法 是對(duì)等價(jià)類劃分方法的補(bǔ)充，也是一種黑盒測試方法，長期的測試工作經(jīng)驗(yàn)得知，大量的錯(cuò)誤是發(fā)生在輸入或輸出的邊界上。 (2) 分析軟件規(guī)格說明描述中的語義 .找出原因與結(jié)果之間 , 原因與原因之間對(duì)應(yīng)的關(guān)系 . 根據(jù)這些關(guān)系 ,畫出因果圖 。 ? 路徑分析法 ① 將系統(tǒng)運(yùn)行過程中所涉及到的各種流程圖表化，完成 所有路徑的設(shè)定。 ② 生成從初始狀態(tài)到最后狀態(tài)的測試路徑。測試工作經(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ò)誤的情況 . 可 選擇這些情況下的例子作為測試用例 . (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á)到盡量少的用例覆蓋盡量大的范圍的可能性。不可能做到完全測試，以最少的用例在合理的時(shí)間內(nèi)發(fā)現(xiàn)最多的問題 3測試用例設(shè)計(jì)的原則是什么？ ? 測試用例的代表性：能夠代表并覆蓋各種合理的和不合理、合法的和非法的、邊界的和越界的、以及極限的輸入數(shù)據(jù)、操作和環(huán)境設(shè)置等 。 ③ 由誰來寫測試用例 一般測試用例是由測試設(shè)計(jì)人員來編寫，由測試執(zhí)行人員來執(zhí)行，這就要求測試設(shè)計(jì)人員有一定 的用例設(shè)計(jì)經(jīng)驗(yàn)，并對(duì)被測試的系統(tǒng)有深入的了解。 ②正確性： 每一項(xiàng)需求都必 須準(zhǔn)確地陳述其要開發(fā)的功能。 ⑥健壯性： 需求的說明中是否對(duì)可能出現(xiàn)的異常進(jìn)行了分析，并且對(duì)這些異常進(jìn)行了容錯(cuò)處理。 ⑨可修改性： 每項(xiàng)需求只應(yīng)在 S R S 中出現(xiàn)一次。 3請(qǐng)以您以往的實(shí)際工作 為例，詳細(xì)的描述一次測試用例設(shè)計(jì)的完整的過程。 容量測試： 容量測試目的是通過測試預(yù)先分析出反映軟件系統(tǒng)應(yīng)用特征的某項(xiàng)指標(biāo)的極限值（如最大并發(fā)用戶數(shù)、數(shù)據(jù)庫記錄數(shù)等），系統(tǒng)在其極限值狀態(tài)下沒有出現(xiàn)任何軟件故障或還能保持主要功能正常運(yùn)行。 壓力測試、 容量測試和性能測試的關(guān)系： 壓力測試可以看作是容量測試、性能測試和可靠性測試的一軟件測試工程師面試寶典 21 種手段，不是直接的測試目標(biāo)。容量測試的目的是使系統(tǒng)承受超額的數(shù)據(jù)容量來發(fā)現(xiàn)它是否能夠正確處理。 區(qū)別方面： 負(fù)載測試 是 性能測試的一種，通常是指讓被測系統(tǒng)在其能忍受的壓力的極限范圍之內(nèi)連續(xù)運(yùn)行，來測試系統(tǒng)的穩(wěn)定性。另外，使用目錄表、索引和相互參照列表方法將使軟件需求規(guī)格說明書更容易修改。要使每項(xiàng)需求都能回溯至某項(xiàng)客戶的輸入 ，如 Use Case 或別的來源。 ④可行性： 每一項(xiàng)需求都必須是在已知系統(tǒng)和環(huán)境的權(quán)能和限制范圍內(nèi)可以實(shí)施的。這就需要我們 根據(jù)不斷調(diào)整變化的用戶需求，來修改和維護(hù)我們已經(jīng)寫好的測試用例 。 ? 測試結(jié)果的可再現(xiàn)性：即對(duì)同樣的測試用例，系統(tǒng)的執(zhí)行結(jié)果應(yīng)當(dāng)是相同的。 3您認(rèn)為做好測試用例設(shè)計(jì)工作的關(guān)鍵是什么？ 關(guān)鍵是對(duì)系統(tǒng)的熟悉程度，需求的理解，設(shè)計(jì)文檔的了解情況 。 ? 正交表 ① 分 析變量和變量的取值 ② 選擇一個(gè)合適的正交表 ，并 把變量的值映射到表中 ③ 把每一行的各因素水平的組合做為一個(gè)測試用例 ? 場景設(shè)計(jì)方法 對(duì)于 每一個(gè)場景，采用矩陣或決策表來確定和管理測試用例， 其中各行代表各個(gè)測試用例，而各列則代表測試用例的信息。 ③ 為每條路徑選取測試數(shù)據(jù)，構(gòu)造測試用例。 (4) 把因果圖轉(zhuǎn)換為判定表 。 ? 錯(cuò)誤 推測法 基于經(jīng)驗(yàn)和直覺列舉出程序中所有可能有的錯(cuò)誤和容易發(fā)生錯(cuò)誤的特殊情況 ，從而有針對(duì)性的設(shè)計(jì)測試用例。 ? 等價(jià)類劃分 是一種典型的黑盒測試方法。 3測試用例包括哪些內(nèi)容？ 軟件測試工程師面試寶典 18 《 測試用例 》 指的是在測試執(zhí)行之前設(shè)計(jì)的一套詳細(xì)的測試方案，包括測試環(huán)境、測試步驟、測試數(shù)據(jù)和預(yù)期結(jié)果。 什么是測試用例？什么是測試腳本？兩者的關(guān)系是什么？ 測試用例 ：指對(duì)一項(xiàng)特定的軟件產(chǎn)品進(jìn)行測試任務(wù)的描述，體現(xiàn)測試方案、方法、技術(shù)和策略的文檔；內(nèi)容包括測試目 標(biāo)、測試環(huán)境、輸入數(shù)據(jù)、測試步驟、預(yù)期結(jié)果、測試腳本等。每一工作版本一經(jīng)推出，它們都可以用來對(duì)產(chǎn)品進(jìn)行先期檢查，幫助發(fā) 現(xiàn)集成問題 。它們代表正在進(jìn)行的嘗試活動(dòng)，目的是展示最新開發(fā)的功能。 評(píng)估的 范圍 ：測試執(zhí)行過程中發(fā)生的情況 、 測試執(zhí)行期間發(fā)生并需要進(jìn)一步調(diào)查的一切事件 、 與測試設(shè)計(jì)、說明等有關(guān)的測試活動(dòng) 。 2產(chǎn)品測試到什么時(shí)候就算是足夠了 ?測試結(jié)束的標(biāo)準(zhǔn)是什么？ 從微觀上來說，在測試計(jì)劃中定義，比如系統(tǒng)在一定性能下平穩(wěn)運(yùn)行 72 小時(shí)，目前 Bug Tracking System中，本版本中沒有一般嚴(yán)重的 BUG，普通 BUG 的數(shù)量在 3 以下， BUG 修復(fù)率 90%以上等等參數(shù)，然后由開發(fā)經(jīng)理，測試經(jīng)理，項(xiàng)目經(jīng)理共同簽字認(rèn)同版本 Release。 綜上所述，單元測試是構(gòu)筑產(chǎn)品質(zhì)量的基石，我們不要因?yàn)楣?jié)約單元測試的時(shí)間不做單元測試或隨便做而讓我們?cè)诤笃诶速M(fèi)太多的不值得的時(shí)間