版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)
文檔簡介
1、測試面試題測試面試題1.1.怎么來設(shè)計測試方案怎么來設(shè)計測試方案根據(jù)測試需求(包括功能需求和非功能性需求),識別測試要點(diǎn),識別測試環(huán)境要求,安排測試輪次,根據(jù)項目計劃和開發(fā)計劃做整體的測試安排。被測試的特性:通過對需求規(guī)格說明書進(jìn)行分析,列出本次測試需要進(jìn)行測試的各部分特性(如要測試的功能需求、性能需求、安全性需求等等);不被測試的特性:由于資源、進(jìn)度等方面原因,本次測試不列入測試范圍的特性;測試組網(wǎng)圖:進(jìn)行本次系統(tǒng)測試所需要的軟硬件設(shè)
2、備、配置數(shù)據(jù)已及相互間的邏輯、物理連接。今后測試執(zhí)行時需要依據(jù)這個組網(wǎng)圖來進(jìn)行環(huán)境的搭建。2.2.如果給你一個如果給你一個BSBS系統(tǒng)你怎么來進(jìn)行測試?此題答案還可用于回答測試流程,測試流程題亦可參考系統(tǒng)你怎么來進(jìn)行測試?此題答案還可用于回答測試流程,測試流程題亦可參考1515題。題。?閱讀系統(tǒng)需求,充分理解需求,記錄問題,并與項目需求人員充分溝通。?編寫測試需求,包括系統(tǒng)功能和非功能測試要點(diǎn)、測試類型、測試進(jìn)度質(zhì)量要求等。?制定測試計
3、劃,包括熟悉測試業(yè)務(wù)、設(shè)計測試用例、執(zhí)行測試用例、進(jìn)行測試小結(jié)、編寫測試報告,任務(wù)顆粒度一般應(yīng)小于5人天?編寫測試用例,根據(jù)測試方案設(shè)計用例,即便沒有明確的性能和安全測試要求,也應(yīng)識別進(jìn)行此兩項測試。?執(zhí)行軟件測試,?進(jìn)行測試小結(jié),如果測試持續(xù)時間較長,每個版本間隙總結(jié)本輪測試。?編寫測試報告,總結(jié)測試過程,匯總度量數(shù)據(jù)。3.3.怎么進(jìn)行工作流的測試怎么進(jìn)行工作流的測試把握需求,找準(zhǔn)結(jié)點(diǎn),理清流程,畫出流轉(zhuǎn)圖,弄清節(jié)點(diǎn)間的數(shù)據(jù)流轉(zhuǎn),設(shè)計
4、測試用例的時候必須覆蓋所有可能的流程。工作流:如果問到有沒有做過,根據(jù)對工作流的了解情況回答,如果比較了解,可以把參與的某個項目中說上一些有工作流的,如果不是很了解就說沒有做過,但是學(xué)習(xí)過相關(guān)知識。4.4.在做性能測試的時候都需要關(guān)注哪些參數(shù)?在做性能測試的時候都需要關(guān)注哪些參數(shù)?并發(fā)訪問量,服務(wù)器響應(yīng)時間(最小、平均、最大)并發(fā)性能測試的過程是一個負(fù)載測試和壓力測試的過程,即逐漸增加負(fù)載,直到系統(tǒng)的瓶頸或者不能接收的性能點(diǎn),通過綜合分
5、析交易執(zhí)行指標(biāo)和資源監(jiān)控指標(biāo)來確定系統(tǒng)并發(fā)性能的過程。負(fù)載測試(LoadTesting)是確定在各種工作負(fù)載下系統(tǒng)的性能,目標(biāo)是測試當(dāng)負(fù)載逐漸增加時,系統(tǒng)組成部分的相應(yīng)輸出項,例如通過量、響應(yīng)時間、CPU負(fù)載、內(nèi)存使用等來決定系統(tǒng)的性能。負(fù)載測試是一個分析軟件應(yīng)用程序和支撐架構(gòu)、模擬真實環(huán)境的使用,從而來確定能夠接收的性能過程。壓力測試(StressTesting)是通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點(diǎn),來獲得系統(tǒng)能提供的最大服務(wù)
6、級別的測試。疲勞測試是采用系統(tǒng)穩(wěn)定運(yùn)行情況下能夠支持的最大并發(fā)用戶數(shù),持續(xù)執(zhí)行一段時間業(yè)務(wù),通過綜合分析交易執(zhí)行指標(biāo)和資源監(jiān)控指標(biāo)來確定系統(tǒng)處理最大工作量強(qiáng)度性能的過程。疲勞強(qiáng)度測試可以采用工具自動化的方式進(jìn)行測試,也可以手工編寫程序測試,其中后者占的比例較大。一般情況下以服務(wù)器能夠正常穩(wěn)定響應(yīng)請求的最大并發(fā)用戶數(shù)進(jìn)行一定時間的疲勞測試,獲取交易執(zhí)行指標(biāo)數(shù)據(jù)和系統(tǒng)資源監(jiān)控數(shù)據(jù)。如出現(xiàn)錯誤導(dǎo)致測試不能成功執(zhí)行,則及時調(diào)整測試指標(biāo),例如降低
7、用戶數(shù)、縮短測試周期等。還有一種情況的疲勞測試是對當(dāng)前系統(tǒng)性能的評估,用系統(tǒng)正常業(yè)務(wù)情況下并發(fā)用戶數(shù)為基礎(chǔ),進(jìn)行一定時間的疲勞測試。大數(shù)據(jù)量測試可以分為兩種類型:針對某些系統(tǒng)存儲、傳輸、統(tǒng)計、查詢等業(yè)務(wù)進(jìn)行大數(shù)據(jù)量的獨(dú)立數(shù)據(jù)量測試;與壓力性能測試、負(fù)載性能測試、疲勞性能測試相結(jié)合的綜合數(shù)據(jù)量測試方案。大數(shù)據(jù)量測試的關(guān)鍵是測試數(shù)據(jù)的準(zhǔn)備,可以依靠工具準(zhǔn)備測試數(shù)據(jù)。5.5.如果客戶沒有給你性能指數(shù)時,你怎么來開展性能測試工作?如果客戶沒有給
8、你性能指數(shù)時,你怎么來開展性能測試工作?如果客戶沒有提出明確的性能指標(biāo),可以按照慣例和經(jīng)驗設(shè)置,需要和PM協(xié)商,一般由PM確認(rèn),QA負(fù)責(zé)給出建議。舉例說一個Server端程序,要求峰值時CPU和MEM消耗在75%以下,而一個頁面的訪問響應(yīng)時間一般認(rèn)為用戶的忍耐時間是3-5秒以內(nèi),這些要參考實際的應(yīng)用來確定用戶規(guī)模、操作頻率、同時在線數(shù)等。6.6.有沒有做過接口測試,是如何做的?有沒有做過接口測試,是如何做的?出的一些要求。軟件測試就是在
9、軟件投入運(yùn)行前,對軟件需求分析、設(shè)計規(guī)格說明和編碼的最終復(fù)審,是軟件質(zhì)量保證的關(guān)鍵步驟。軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。軟件測試在軟件生存期中橫跨兩個階段:通常在編寫出每一個模塊之后就對它做必要的測試(稱為單元測試)。編碼和單元測試屬于軟件生命周期中的同一個階段。在結(jié)束這個階段后對軟件系統(tǒng)還要進(jìn)行各種綜合測試,這是軟件生命周期的另一個獨(dú)立階段,即測試階段。華為獨(dú)立外包測試一般包括ST(系統(tǒng)測試)和SDV(詳細(xì)設(shè)計驗證)兩個階段。
10、14.14.缺陷是怎么管理的?缺陷是怎么管理的?答:我們采用了RationalClearQuest來管理缺陷。測試人員執(zhí)行測試,發(fā)現(xiàn)缺陷,錄入CQ,要求填寫項目名稱、子系統(tǒng)名稱、模塊名稱、缺陷標(biāo)題、缺陷描述(描述場景、現(xiàn)象)、缺陷級別、提出人等。狀態(tài):已提交。項目經(jīng)理或開發(fā)組長確認(rèn)缺陷后分配給開發(fā)人員,狀態(tài):已分配。開發(fā)人員修復(fù)缺陷完成后,將修復(fù)缺陷所花費(fèi)的時間填寫的Schedule中,缺陷的產(chǎn)生原因填寫在備注中,因采用UCM模式,所有
11、造成該缺陷的錯誤代碼文件,在UCM視圖中可以統(tǒng)計。狀態(tài):已處理。測試人員復(fù)測,如缺陷已經(jīng)修復(fù),則關(guān)閉缺陷,狀態(tài):已關(guān)閉。如缺陷仍然存在,則修改狀態(tài)為已分配。當(dāng)缺陷存在爭議時,開發(fā)組長或開發(fā)人員可以申請否決,由項目經(jīng)理、技術(shù)經(jīng)理、測試負(fù)責(zé)人、相關(guān)開發(fā)人員和測試人員共同決定缺陷是否可以否決。狀態(tài):已申請否決、已否決。當(dāng)前不能修復(fù),或當(dāng)前版本無法解決的缺陷可以申請延期,狀態(tài):已申請延期、已延期。15.15.介紹一下測試流程。介紹一下測試流程。
12、答:項目啟動后進(jìn)行需求培訓(xùn),測試人員盡早的參與到項目需求的培訓(xùn)和評審,也就是測試工作應(yīng)該從需求階段開始介入。項目經(jīng)理編寫《項目計劃》,開發(fā)人員產(chǎn)出《需求規(guī)格說明書》,這時測試組長就要根據(jù)《項目計劃》開始編寫《測試計劃》,其中包括人員,軟件硬件資源,測試點(diǎn),進(jìn)度安排和風(fēng)險識別等內(nèi)容?!稖y試計劃》編寫完成后需要進(jìn)行評審,參與人員有項目經(jīng)理,測試經(jīng)理。測試組長需要根據(jù)評審意見修改《測試計劃》,并上傳到CC上,由配置管理員管理。待開發(fā)人員把《需
13、求規(guī)格說明書》歸納好并打了基線,測試組長開始組織測試成員編寫《測試方案》,《測試方案》編寫完成后也需要進(jìn)行評審,評審人員包括項目經(jīng)理,開發(fā)人員,測試經(jīng)理,測試組長,測試成員;測試組長組織測試成員修改測試方案,直到評審?fù)ㄟ^后才進(jìn)入下個階段――編寫測試用例。測試用例是根據(jù)《測試方案》來編寫的,通過《測試方案》階段,測試人員對整個系統(tǒng)需求有了詳細(xì)的理解。這時開始編寫用例才能保證用例的可執(zhí)行和對需求的覆蓋。測試用例需要包括測試項,用例級別,預(yù)置
14、條件,操作步驟和預(yù)期結(jié)果。其中操作步驟和預(yù)期結(jié)果需要編寫詳細(xì)和明確。測試用例應(yīng)該覆蓋測試方案,而測試方案又覆蓋了測試需求點(diǎn),這樣才能保證客戶需求不遺漏。同樣,測試用例也需要通過開發(fā)人員,測試人員的評審,測試組長也需要組織測試人員對測試用例進(jìn)行修改,直到評審?fù)ㄟ^。在我們編寫測試用例的階段,開發(fā)人員基本完成代碼的編寫,同時完成單元測試。提交測試中心后根據(jù)《測試計劃》進(jìn)度安排,測試組長組織進(jìn)行多輪次的測試,每輪測試完成后測試組長需要編寫測試報
15、告,其中包括用例執(zhí)行通過情況,缺陷分布情況,缺陷產(chǎn)生原因,測試中的風(fēng)險等等,這時測試人員就修改增加測試用例。待到開發(fā)修改完bug并轉(zhuǎn)來新的測試版本,測試人員開始進(jìn)行第二輪的系統(tǒng)測試,首先回歸完問題單,再繼續(xù)進(jìn)行測試,編寫第二輪的測試報告,如此循環(huán)下去,直到系統(tǒng)測試結(jié)束。16.16.一個關(guān)于測試方案評審的分歧,一個關(guān)于測試方案評審的分歧,我們原本的流程是完成方案包括用例后進(jìn)行評審,華為的建議是,在測試方案(即測試人員總結(jié)出測試重點(diǎn)等)之后
16、,即進(jìn)行評審,不能等全部用例完成。關(guān)于版本缺陷密度的問題:問有沒有統(tǒng)計。如果CQ中正常登記的話,是可以利用工具統(tǒng)計出來。CQ還可以根據(jù)需要定制查詢。關(guān)于測試提交標(biāo)準(zhǔn):我講了公司的標(biāo)準(zhǔn),他說客戶也會有自己的標(biāo)準(zhǔn)。我回復(fù)說是可以依據(jù)客戶標(biāo)準(zhǔn)進(jìn)行調(diào)整,17.17.對UnixUnix系統(tǒng)是否熟識,是否會運(yùn)用系統(tǒng)是否熟識,是否會運(yùn)用InfmixInfmix數(shù)據(jù)庫。數(shù)據(jù)庫。ls列出指定目錄下的文件,缺省目錄為當(dāng)前目錄.pwd顯示當(dāng)前的工作目錄cd回
溫馨提示
- 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. 眾賞文庫僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
評論
0/150
提交評論