軟件測試面試題.pdf_第1頁
軟件測試面試題.pdf_第2頁
軟件測試面試題.pdf_第3頁
軟件測試面試題.pdf_第4頁
軟件測試面試題.pdf_第5頁
已閱讀5頁,還剩4頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

軟件測試面試題軟件測試面試題 20082008年年 1212月月 2424 日分類日分類 致富小項目致富小項目 評論評論 0 0 瀏覽瀏覽 問題一 為什么要在一個團隊中開展軟件測試工作 任何軟件在開發(fā)過程中都會留下缺陷 帶有缺陷的軟件產(chǎn)品如果提交出去 可 能會給公司帶來不可估量的損失 我們必須在客戶之前發(fā)現(xiàn)盡可能多的問題 從而保障客戶滿意 而發(fā)現(xiàn)問題的這個過程稱之為測試 問題二 簡述你在以前的工作中做過哪些事情 比較熟悉什么 此問題每個人都不一樣 我自己的答案如下 我主要的工作是系統(tǒng)測試和自動化測試 也曾少量涉及性能測試 在系統(tǒng)測試 中 主要是對 BOSS 系統(tǒng)的業(yè)務(wù)邏輯功能 以及軟交換系統(tǒng)的 Class 5 特性進行 測試 性能測試中 主要是進行的壓力測試 在各個不同數(shù)量請求的情況下 獲取系統(tǒng)響應(yīng)時間以及系統(tǒng)資源消耗情況 自動化測試主要是通過自己寫腳本 以及一些第三方工具的結(jié)合來測試軟交換的特性測試 問題三 你所了解的的軟件測試類型都有哪些 簡單介紹一下 1 基本功能驗證 主要是對發(fā)布的版本進行一些最主要功能的測試 英文常見 叫法是 Smoking Test Basic Verification Test 或者 Sanity Check 2 功能測試 主要是依據(jù)需求或者需求分析文檔 對所發(fā)布的版本進行測試 看看是否滿足需求 是否出現(xiàn)了不必要的功能 3 單元測試 是開發(fā)人員進行的測試之一 一般是開發(fā)人員對很小的模塊 比 如函數(shù)進行測試 一般來說 開發(fā)人員還需要開發(fā)相應(yīng)的測試樁來進行此類測 試 4 集成測試 在大型的開發(fā)過程中 軟件是模塊化進行開發(fā)的 將不同的模塊 揉合在一起的話 需要進行的測試就是集成測試 5 系統(tǒng)測試 當(dāng)軟件提交給測試組后 是對整個系統(tǒng)的所有功能進行測試 一 般來說 功能測試是系統(tǒng)測試的一個部分 6 壓力測試 主要是在很大性能的情況下 這個性能已經(jīng)接近了系統(tǒng)的極限 看看系統(tǒng)運轉(zhuǎn)的情況 7 負載測試 主要是用各種不同的性能去檢測系統(tǒng) 采集各個數(shù)據(jù)在這些性能 情況下的數(shù)據(jù) 8 黑盒測試 指系統(tǒng)對你來說是完全不透明的 只給你留下了輸入和最終輸 出 這個是功能測試的方法之一 9 灰盒測試 指在了解部分系統(tǒng)內(nèi)部工作機制的情況下 對于系統(tǒng)進行的覆蓋 性測試 10 白盒測試 主要是在單元測試和集成測試的情況下 開發(fā)人員已知代碼 對這一段的代碼進行全路徑的覆蓋測試 11 界面測試 主要是看用戶界面的友好性和易用性 是否有文字或者排版錯 誤 是否有輸入限制等等 12 回歸測試 一般是系統(tǒng)發(fā)現(xiàn) BUG 開發(fā)人員修改后 和 BUG 直接相關(guān)以及 可能相關(guān)的功能進行的測試 13 安裝和卸載的測試 14 恢復(fù)測試 主要是一個系統(tǒng)在發(fā)生了災(zāi)難的情況下 從錯誤中是否容易恢 復(fù) 15 兼容性測試 一個系統(tǒng)在不同的語言 操作系統(tǒng)下的系統(tǒng)測試 16 安全測試 系統(tǒng)在遇到攻擊或者類似情況下的表現(xiàn) 17 Alpha 測試 系統(tǒng)在給最終用戶前 測試人員在實驗室中模擬最終用戶的 測試 18 Beta 測試 由部分最終用戶通過使用來進行的測試 19 比較測試 和其他具有相同或者類似功能的系統(tǒng)進行對比的測試 20 驗收測試 一般是最終用戶在接受產(chǎn)品前 依據(jù)自己所提出的要求進行的 測試 很多情況下 驗收測試可能委托第三方機構(gòu)完成 問題四 測試計劃工作的目的是什么 測試計劃文檔的內(nèi)容應(yīng)該包括什么 其 中哪些是最重要的 軟件測試計劃是指導(dǎo)測試過程的綱領(lǐng)性文件 包含了產(chǎn)品概述 測試策略 測試方法 測試區(qū)域 測試配置 測試周期 測 試資源 測試交流 風(fēng)險分析等內(nèi)容 借助軟件測試計劃 參與測試的項目成 員 尤其是測試管理人員 可以明確測試任務(wù)和測試方法 保持測試實施過程 的順暢溝通 跟蹤和控制測試進度 應(yīng)對測試過程中的各種變更 測試計劃和測試詳細規(guī)格 測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系 測試計劃主要 從宏觀上規(guī)劃測試活動的范圍 方法和資源配置 而測試詳細規(guī)格 測試用例 是完成測試任務(wù)的具體戰(zhàn)術(shù) 所以其中最重要的是測試測試策略和測試方法 最好是能先評審 問題五 你認為做好測試計劃工作的關(guān)鍵是什么 1 明確測試的目標 增強測試計劃的實用性 編寫軟件測試計劃得重要目的就是使測試過程能夠發(fā)現(xiàn)更多的軟件缺陷 因此 軟件測試計劃的價值取決于它對幫助管理測試項目 并且找出軟件潛在的缺 陷 因此 軟件測試計劃中的測試范圍必須高度覆蓋功能需求 測試方法必須 切實可行 測試工具并且具有較高的實用性 便于使用 生成的測試結(jié)果直 觀 準確 2 堅持 5W 規(guī)則 明確內(nèi)容與過程 5W 規(guī)則指的是 What 做什么 Why 為什么做 When 何時 做 Where 在哪里 How 如何做 利用 5W 規(guī)則創(chuàng)建軟 件測試計劃 可以幫助測試團隊理解測試的目的 Why 明確測試的范圍和內(nèi) 容 What 確定測試的開始和結(jié)束日期 When 指出測試的方法和工具 How 給出測試文檔和軟件的存放位置 Where 3 采用評審和更新機制 保證測試計劃滿足實際需求 測試計劃寫作完成后 如果沒有經(jīng)過評審 直接發(fā)送給測試團隊 測試計劃內(nèi) 容的可能不準確或遺漏測試內(nèi)容 或者軟件需求變更引起測試范圍的增減 而 測試計劃的內(nèi)容沒有及時更新 誤導(dǎo)測試執(zhí)行人員 4 分別創(chuàng)建測試計劃與測試詳細規(guī)格 測試用例 應(yīng)把詳細的測試技術(shù)指標包含到獨立創(chuàng)建的測試詳細規(guī)格文檔 把用于指導(dǎo)測 試小組執(zhí)行測試過程的測試用例放到獨立創(chuàng)建的測試用例文檔或測試用例管理 數(shù)據(jù)庫中 測試計劃和測試詳細規(guī)格 測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系 測 試計劃主要從宏觀上規(guī)劃測試活動的范圍 方法和資源配置 而測試詳細規(guī) 格 測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù) 問題六 常見的測試用例設(shè)計方法都有哪些 請分別以具體的例子來說明這些 方法在測試用例設(shè)計工作中的應(yīng)用 1 等價類劃分 劃分等價類 等價類是指某個輸入域的子集合 在該子集合中 各個輸入數(shù)據(jù)對 于揭露程序中的錯誤都是等效的 并合理地假定 測試某等價類的代表值就等于 對這一類其它值的測試 因此 可以把全部輸入數(shù)據(jù)合理劃分為若干等價類 在每 一個等價類中取一個數(shù)據(jù)作為測試的輸入條件 就可以用少量代表性的測試數(shù)據(jù) 取得較好的測試結(jié)果 等價類劃分可有兩種不同的情況 有效等價類和無效等價 類 2 邊界值分析法 邊界值分析方法是對等價類劃分方法的補充 測試工作經(jīng)驗告訴我 大量的 錯誤是發(fā)生在輸入或輸出范圍的邊界上 而不是發(fā)生在輸入輸出范圍的內(nèi)部 因 此針對各種邊界情況設(shè)計測試用例 可以查出更多的錯誤 使用邊界值分析方法設(shè)計測試用例 首先應(yīng)確定邊界情況 通常輸入和輸出 等價類的邊界 就是應(yīng)著重測試的邊界情況 應(yīng)當(dāng)選取正好等于 剛剛大于或剛剛 小于邊界的值作為測試數(shù)據(jù) 而不是選取等價類中的典型值或任意值作為測試數(shù) 據(jù) 3 錯誤推測法 基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤 從而有針對性的設(shè) 計測試用例的方法 錯誤推測方法的基本思想 列舉出程序中所有可能有的錯誤和容易發(fā)生錯 誤的特殊情況 根據(jù)他們選擇測試用例 例如 在單元測試時曾列出的許多在模 塊中常見的錯誤 以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯誤等 這些就是經(jīng)驗的總結(jié) 還有 輸入數(shù)據(jù)和輸出數(shù)據(jù)為 0 的情況 輸入表格為空格或輸入表格只有一行 這些都是容易發(fā)生錯誤的情況 可選擇這些情況下的例子作為測試用例 4 因果圖方法 前面介紹的等價類劃分方法和邊界值分析方法 都是著重考慮輸入條件 但未考 慮輸入條件之間的聯(lián)系 相互組合等 考慮輸入條件之間的相互組合 可能會產(chǎn) 生一些新的情況 但要檢查輸入條件的組合不是一件容易的事情 即使把所有 輸入條件劃分成等價類 他們之間的組合情況也相當(dāng)多 因此必須考慮采用一種 適合于描述對于多種條件的組合 相應(yīng)產(chǎn)生多個動作的形式來考慮設(shè)計測試用例 這就需要利用因果圖 邏輯模型 因果圖方法最終生成的就是判定表 它適 合于檢查程序輸入條件的各種組合情況 5 正交表分析法 有時候 可能因為大量的參數(shù)的組合而引起測試用例數(shù)量上的激增 同時 這 些測試用例并沒有明顯的優(yōu)先級上的差距 而測試人員又無法完成這么多數(shù)量 的測試 就可以通過正交表來進行縮減一些用例 從而達到盡量少的用例覆蓋 盡量大的范圍的可能性 6 場景分析方法 指根據(jù)用戶場景來模擬用戶的操作步驟 這個比較類似因果圖 但是可能執(zhí)行 的深度和可行性更好 問題七 您認為做好測試用例設(shè)計工作的關(guān)鍵是什么 白盒測試用例設(shè)計的關(guān)鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏輯結(jié)果 黑盒法用例設(shè)計的關(guān)鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口 不可 能做到完全測試 以最少的用例在合理的時間內(nèi)發(fā)現(xiàn)最多的問題 問題八 詳細的描述一個測試活動完整的過程 1 項目經(jīng)理通過和客戶的交流 完成需求文檔 由開發(fā)人員和測試人員共同完 成需求文檔的評審 評審的內(nèi)容包括 需求描述不清楚的地方和可能有明顯沖 突或者無法實現(xiàn)的功能的地方 項目經(jīng)理通過綜合開發(fā)人員 測試人員以及客 戶的意見 完成項目計劃 然后 SQA 進入項目 開始進行統(tǒng)計和跟蹤 2 開發(fā)人員根據(jù)需求文檔完成需求分析文檔 測試人員進行評審 評審的主要 內(nèi)容包括是否有遺漏或者雙方理解不同的地方 測試人員完成測試計劃文檔 測試計劃包括的內(nèi)容上面有描述 3 測試人員根據(jù)修改好的需求分析文檔開始寫測試用例 同時開發(fā)人員完成概 要設(shè)計文檔 詳細設(shè)計文檔 此兩份文檔成為測試人員撰寫測試用例的補充材 料 4 測試用例完成后 測試和開發(fā)需要進行評審 5 測試人員搭建環(huán)境 6 開發(fā)人員提交第一個版本 可能存在未完成功能 需要說明 測試人員進行 測試 發(fā)現(xiàn) BUG 后提交給 BugZilla 7 開發(fā)提交第二個版本 包括 Bug Fix 以及增加了部分功能 測試人員進行測 試 8 重復(fù)上面的工作 一般是 3 4 個版本后 BUG 數(shù)量減少 達到出貨的要求 9 如果有客戶反饋的問題 需要測試人員協(xié)助重現(xiàn)以及回歸測試 問題九 以往是否曾經(jīng)從事過性能測試工作 請盡可能的詳細描述您以往的性 能測試工作的完整過程 曾經(jīng)做過一套網(wǎng)管系統(tǒng)的性能測試 主要測試該軟件在同時管理大量終端的情 況下 在響應(yīng)時間 CPU 磁盤 內(nèi)存等參數(shù)是否滿足要求 也曾經(jīng)做過軟交換系統(tǒng)的呼叫性能測試 主要是測試軟交換系統(tǒng)在有大量呼叫 的情況下 響應(yīng)時間 呼叫成功率 CPU 磁盤 內(nèi)存等參數(shù)是否滿足設(shè)計要求 問題十 您在從事性能測試工作時 是否使用過一些測試工具 如果有 請試 述該工具的工作原理 并以一個具體的工作中的例子描述該工具是如何在實際 工作中應(yīng)用的 測試網(wǎng)管系統(tǒng)中 使用的 Mimic 來模擬終端 能夠大量的節(jié)省成本 測試軟交換系統(tǒng)的時候 使用的 Prolab 來模擬終端并發(fā)送呼叫軟交換 他完成 了同時數(shù)百人才能完成的摘機撥號工作 主要工作原理是產(chǎn)生一些符合要求的 IP 包并發(fā)送給軟交換系統(tǒng) 同時對軟交換系統(tǒng)的回應(yīng)進行處理 決定下一步動 作 問題十一 您認為性能測試工作的目的是什么 做好性能測試工作的關(guān)鍵是什 么 主要是保障在大量用戶的情況下 服務(wù)能正常使用 問題十二 在您以往的工作中 一條軟件缺陷 或者叫 Bug 記錄都包含了哪 些內(nèi)容 如何提交高質(zhì)量的軟件缺陷 Bug 記錄 1 在傳統(tǒng)的 BugZilla 中 BUG 描述應(yīng)該包括以下的信息 2 和 BUG 產(chǎn)生對應(yīng)的軟件版本 3 開發(fā)的接口人員 4 BUG 的優(yōu)先級 5 BUG 的嚴重程度 6 BUG 可能屬于的模塊 如果不能確認 可以用開發(fā)人員來判斷 7 BUG 標題 需要清晰的描述現(xiàn)象 8 BUG 描述 需要盡量給出重新 Bug 的步驟 9 BUG 附件中能給出相關(guān)的日志和截圖 高質(zhì)量的 BUG 記錄就是指很容易理解的 BUG 記錄 所以 對于描述的要求高 能提供的信息多且準確 很好的幫助開發(fā)人員定位 問題十二 BUG 管理工具的跟蹤過程 用 BugZilla 為例子 測試人員發(fā)現(xiàn)了 BUG 提交到 Bugzilla 中 狀態(tài)為 new BUG 的接受者為開發(fā) 接口人員 開發(fā)接口將 BUG 分配給相關(guān)的模塊的開發(fā)人員 狀態(tài)修改為已分配 開發(fā)人員和測試確認 BUG 如果是本人的 BUG 則設(shè)置為接收 如果是別的開發(fā) 人員的問題 則轉(zhuǎn)發(fā)出去 由下一個開發(fā)人員來進行此行為 如果認為不是問 題 則需要大家討論并確認后 拒絕這個 BUG 然后測試人員關(guān)閉此問題 如果開發(fā)人員接受了 BUG 并修改好以后 將 BUG 狀態(tài)修改為已修復(fù) 并告知 測試在哪個版本中可以測試 測試人員在新版本中測試 如果發(fā)現(xiàn)問題依然存在 則拒絕修改 如果已經(jīng)修 復(fù) 則關(guān)閉 BUG 問題十二 您認為在測試人員同開發(fā)人員的溝通過程中 如何提高溝通的效率 和改善溝通的效果 維持測試人員同開發(fā)團隊中其他成員良好的人際關(guān)系的關(guān) 鍵是什么 盡量能有面對面的溝通 如果做不到 那么盡量能直接通過電話溝通 如果只 能通過 Email 等非及時溝通工具的話 強調(diào)必須對特性的理解深刻以及能表達 清楚 一是真誠 二是團隊精神 三是在專業(yè)上有共同語言 當(dāng)然也可以通過直接指 出一些小問題 而不是進入 BUG Tracking System 來增加對方的好感 問題十三 在您以往的測試工作中 最讓您感到不滿意或者不堪回首的事情是 什么 您是如何來對待這些事情的 某次性能測試覆蓋不足 造成系統(tǒng)崩潰 問題十四 你對測試最大的興趣在哪里 為什么 最大的興趣就是測試有難度 有挑戰(zhàn)性 做測試越久越能感覺到做好測試有多 難 曾經(jīng)在無憂測試網(wǎng)上看到一篇文章 是關(guān)于如何做好一名測試工程師 一 共羅列了 11 12 點 有部分是和人的性格有關(guān) 有部分需要后天的努力 但除 了性格有關(guān)的 1 2 點我沒有把握 其他點我都很有信心做好它 剛開始進入測試行業(yè)時 對測試的認識是從無憂測試網(wǎng)上了解到的一些資料 當(dāng)時是沖著做測試需要很多技能才能做的好 雖然入門容易 但做好很難 比 開發(fā)更難 雖然當(dāng)時我很想做開發(fā) 學(xué)校專業(yè)課我基本上不缺席 因為我喜歡 我的專業(yè) 但看到測試比開發(fā)更難更有挑戰(zhàn)性 想做好測試的意志就更堅定 了 我覺得做測試整個過程中有 2 點讓我覺得很有難度 對我來說 有難度的東西 我就非常感興趣 第一是測試用例的設(shè)計 因為測試的精華就在測試用例的 設(shè)計上了 要在版本出來之前 把用例寫好 用什么測試方法寫 也就是測 試計劃或測試策略 如果你剛測試一個新任務(wù)時 你得花一定的時間去消化 業(yè)務(wù)需求和技術(shù)基礎(chǔ) 業(yè)務(wù)需求很好理解 多和產(chǎn)品經(jīng)理和開發(fā)人員溝通就能 達到目的 而技術(shù)基礎(chǔ)可就沒那么簡單了 這需要你自覺的學(xué)習(xí)能力 比如 說網(wǎng)站吧 最基本的技術(shù)知識你要知道網(wǎng)站內(nèi)部是怎么運作的的 后臺是怎么 響應(yīng)用戶請求的 測試環(huán)境如何搭建 這些都需要最早的學(xué)好 至少在開始測 試之前能做好基本的準備 可能會遇到什么難題 需求細節(jié)是不是沒有確定 好 這些問題都能在設(shè)計用例的時候發(fā)現(xiàn) 第二是發(fā)現(xiàn) BUG 的時候了 這應(yīng)該是測試人員最基本的任務(wù)了 一般按測試用 例開始測試就能發(fā)現(xiàn)大部分的 bug 還有一部分 bug 需要測試的過程中更了解 所測版本的情況獲得更多信息 補充測試用例 測試出 bug 還有如何發(fā)現(xiàn) bug 這就需要在測試用例有效的情況下 通過細心和耐心去發(fā)現(xiàn) bug 了 每個 用例都有可能發(fā)現(xiàn) bug 每個地方都有可能出錯 所以測試過程中思維要清晰 測試過程數(shù)據(jù)流及結(jié)果都得看仔細了 bug 都在里面發(fā)現(xiàn)的 如何描述 bug 也很有講究 bug 在什么情況下會產(chǎn)生 如果條件變化一點點 就不會有這個 bug 以哪些最少的操作步驟就能重現(xiàn)這個 bug 這個 bug 產(chǎn)生的規(guī)律是什么 如果你夠厲害的話 可以幫開發(fā)人員初步定位問題 問題十五 你的測試職業(yè)發(fā)展目標是什么 測試經(jīng)驗越多 測試能力越高 所以我的職業(yè)發(fā)展是需要時間累積的 一步步 向著高級測試工程師奔去 而且我也有初步的職業(yè)規(guī)劃 前 3 年累積測試經(jīng) 驗 按如何做好測試工程師的 11 12 點要求自己 不斷的更新自己改正自己 做好測試任務(wù) 問題十六 你自認為測試的優(yōu)勢在哪里 有韌性 有能力面對挑戰(zhàn) 有信心做好每一件事情 有比較好的教育背景 從以前的經(jīng)理處都得到了很好的評價表明我做的很好 問題十七 當(dāng)開發(fā)人員說不是 BUG

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論