經(jīng)典測(cè)試工程師面試題(一)
經(jīng)典測(cè)試工程師面試題(三)
背景
為了擴(kuò)展家里領(lǐng)導(dǎo)的測(cè)試知識(shí)水平和專業(yè)知識(shí)能力提升，以及為以后更好的面試做基礎(chǔ)，特意從眾多測(cè)試相關(guān)題型整理出來，其中的答案僅供參考。
什么是bug？
沒有實(shí)現(xiàn)需求說明書列出的功能，出現(xiàn)了沒有需求說明書提到不該出現(xiàn)的事情；實(shí)現(xiàn)了多的功能；沒有實(shí)現(xiàn)應(yīng)該實(shí)現(xiàn)的邏輯。
開發(fā)人員修復(fù)缺陷后，如何保證不影響其他功能？
重新執(zhí)行測(cè)試用例，并且針對(duì)這個(gè)缺陷影響的相關(guān)點(diǎn)寫新的測(cè)試用例。
為什么選擇測(cè)試這行？
因?yàn)槠渚哂刑魬?zhàn)性和成就感，找一些系統(tǒng)隱藏的邏輯漏洞的時(shí)候，自己就非常的開心。并且測(cè)試需要細(xì)心和耐心，自己可以很快的分析bug的來源。
簡單概述缺陷報(bào)告，并說明包括哪些項(xiàng)？
缺陷描述，缺陷的優(yōu)先級(jí)，缺陷的標(biāo)題，缺陷所屬版本號(hào)，缺陷所屬的功能模塊，操作步驟，預(yù)期效果，缺陷原因，缺陷所屬的開發(fā)人員.
進(jìn)行測(cè)試時(shí)產(chǎn)生了哪些文檔或記錄？
測(cè)試用例，測(cè)試報(bào)告，測(cè)試日?qǐng)?bào)
開發(fā)與測(cè)試的關(guān)系？
沒有開發(fā)就沒有測(cè)試，開發(fā)之后才開始測(cè)試，
當(dāng)測(cè)試過程發(fā)生錯(cuò)誤時(shí)，有哪幾種解決辦法？
1.跳轉(zhuǎn)其他的測(cè)試流程
2.調(diào)用某個(gè)程序能繞過這個(gè)錯(cuò)誤，繼續(xù)后面的流程
什么是兼容性測(cè)試？
兼容性測(cè)試是檢查軟件在不同軟件平臺(tái)，硬件平臺(tái)上是否可以正常運(yùn)行的測(cè)試。
主要查看軟件在不同操作系統(tǒng)、瀏覽器、數(shù)據(jù)庫中是否運(yùn)行正常
軟件的評(píng)審一般由哪些人員參加？其目的是什么？
參加人員：需求業(yè)務(wù)人員、產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理、開發(fā)人員、測(cè)試人員
目的：查看軟件在未正式投入運(yùn)行前是否還存在問題。對(duì)于不同軟硬件平臺(tái)能否正常運(yùn)行，是否有與客戶理解不一致的地方，同時(shí)可以對(duì)一些可以改進(jìn)的地方再多加改進(jìn)。
開發(fā)人員說不是bug時(shí)，你如何應(yīng)付？
首先把自己的理由，并以需求說明書為自己的站點(diǎn)，如果開發(fā)人員還是不認(rèn)同，可以把自己的觀點(diǎn)和理由，提交給產(chǎn)品經(jīng)理，由其去決定是否為一個(gè)bug
軟件測(cè)試項(xiàng)目從什么時(shí)候開始為什么？
需求確認(rèn)開始，因?yàn)樵谛枨箅A段，測(cè)試可以評(píng)審需求并進(jìn)行靜態(tài)測(cè)試，減少開發(fā)過程中的bug
您在以往的測(cè)試工作中都曾經(jīng)具體從事過哪些工作？其中最擅長哪部分工作？
做過web測(cè)試，小程序測(cè)試，H5頁面測(cè)試，后臺(tái)測(cè)試，接口測(cè)試。最擅長接口測(cè)試，自己給公司的業(yè)務(wù)流程寫過一套自動(dòng)化框架，用于回歸業(yè)務(wù)流程
開發(fā)人員老是犯一些低級(jí)錯(cuò)誤怎么解決？
要求開發(fā)人員進(jìn)行自測(cè)，把這些問題在開發(fā)階段就解決好
通過缺陷管理系統(tǒng)對(duì)開發(fā)人員進(jìn)行控制
所有的軟件缺陷都能修復(fù)嗎？所有的軟件缺陷都要修復(fù)嗎？
能修復(fù)，但不一定所有的缺陷都要修復(fù)
為什么盡量不要讓時(shí)間富裕的員工去做一些測(cè)試？
1，非專業(yè)測(cè)試人員，沒有組織性的測(cè)試工作，沒有規(guī)律和針對(duì)性，會(huì)影響到測(cè)試的質(zhì)量和版本更新的速度。
2，專業(yè)測(cè)試人員（但不是這個(gè)項(xiàng)目的測(cè)試員）這些人員不受測(cè)試計(jì)劃的時(shí)候和任務(wù)約定，測(cè)試完畢后評(píng)估測(cè)試小組的工作質(zhì)量，不利于bug管理。
在您以往的工作中，一條軟件缺陷（或者叫Bug）記錄都包含了哪些內(nèi)容？如何提交高質(zhì)量的軟件缺陷（Bug）記錄？
前提條件、測(cè)試環(huán)境、操作步驟、預(yù)期結(jié)果、實(shí)際結(jié)果、嚴(yán)重等級(jí)、版本信息，出現(xiàn)概率
問題描述和操作步驟要盡可能描述詳細(xì)，可以初步分析bug是客戶端的問題還是服務(wù)端的問題
您所熟悉的測(cè)試用例設(shè)計(jì)方法都有哪些？請(qǐng)分別以具體的例子來說明這些方法在測(cè)試用例設(shè)計(jì)工作中的應(yīng)用。
黑盒：
邊界值分析法：如參數(shù)的范圍0-128，輸入128,129,0這些值，查看是否有錯(cuò)誤等
錯(cuò)誤推測(cè)法：導(dǎo)入功能時(shí)，表格為空表格，表格輸入1行，表格輸入10000行等
因果圖方法：組合參數(shù)邏輯圖
場(chǎng)景分析法：根據(jù)用戶操作模擬用戶操作
白盒：
邏輯覆蓋法，基本路徑測(cè)試
不能發(fā)現(xiàn)BUG的測(cè)試用例不是好的測(cè)試用例嗎？
不一定，要看情況，如果測(cè)試用例質(zhì)量高，沒有發(fā)現(xiàn)bug，說明開發(fā)質(zhì)量高。但一般程序都會(huì)有bug，如果沒有發(fā)現(xiàn)BUG，就要思索測(cè)試場(chǎng)景是否有遺漏，需求是否理解沒到位
測(cè)試用例需要哪些人來評(píng)審？
產(chǎn)品經(jīng)理，開發(fā)人員，測(cè)試人員，業(yè)務(wù)需求人員
靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試有什么區(qū)別？
靜態(tài)測(cè)試：不運(yùn)行程序，針對(duì)PRD等檢查代碼，審查代碼，靜態(tài)結(jié)構(gòu)分析，分析代碼質(zhì)量
動(dòng)態(tài)測(cè)試：運(yùn)行程序進(jìn)行黑盒測(cè)試和白盒測(cè)試
什么是內(nèi)存泄漏、Http錯(cuò)誤率、吞吐率。響應(yīng)時(shí)間分別在web端和移動(dòng)端是多少？哪些場(chǎng)景可以證明響應(yīng)超時(shí)？
內(nèi)存泄漏（Memory Leak）是指程序中己動(dòng)態(tài)分配的堆內(nèi)存由于某種原因程序未釋放或無法釋放，造成系統(tǒng)內(nèi)存的浪費(fèi)，導(dǎo)致程序運(yùn)行速度減慢甚至系統(tǒng)崩潰等嚴(yán)重后果
HTTP錯(cuò)誤率（HTTP error rate） 在選定時(shí)間段內(nèi)，HTTP錯(cuò)誤數(shù)量與請(qǐng)求數(shù)量的比率。
吞吐率（Throughput） 是場(chǎng)景運(yùn)行過程中服務(wù)器每秒的吞吐量。其度量單位是字節(jié)，表示每個(gè)請(qǐng)求連接在任何給定的每一秒從服務(wù)器獲得的數(shù)據(jù)量。
web端
當(dāng)用戶在2秒以內(nèi)得到響應(yīng)時(shí)，會(huì)感覺系統(tǒng)的響應(yīng)很快；
當(dāng)用戶在2-5秒之間得到響應(yīng)時(shí)，會(huì)感覺系統(tǒng)的響應(yīng)速度還可以；
而當(dāng)用戶在超過8秒后仍然無法得到響應(yīng)時(shí)，會(huì)感覺系統(tǒng)糟透了，或者認(rèn)為系統(tǒng)已經(jīng)失去響應(yīng)，
場(chǎng)景：請(qǐng)求超時(shí)、頁面加載失敗
什么是接口測(cè)試
接口測(cè)試是測(cè)試系統(tǒng)組件間接口的一種測(cè)試。接口測(cè)試就是測(cè)試不同系統(tǒng)或模塊之間資源交互是否正確
為什么要做接口測(cè)試
因?yàn)樵诖蟛糠窒到y(tǒng)和產(chǎn)品中，資源數(shù)據(jù)都是核心，所以接口是需要要測(cè)試的，并且接口中大部分內(nèi)容都是數(shù)據(jù)，通過數(shù)據(jù)的對(duì)比可以推測(cè)系統(tǒng)和產(chǎn)品的邏輯，測(cè)試接口就是測(cè)試邏輯。所以很必要做接口測(cè)試
什么時(shí)候做接口測(cè)試
1.出現(xiàn)bug,通過接口測(cè)試，清晰找到bug的源頭，是前端還是后端的bug
2.回歸測(cè)試，利用接口測(cè)試原有的接口是否正常，保證之前的業(yè)務(wù)流程沒有受影響
3.接口開發(fā)完成后，可以做接口測(cè)試
接口測(cè)試的工具有哪些
soapUI、postman、jemeter、insomnia、paw
接口測(cè)試的流程是什么？
1.接口的通過性驗(yàn)證：數(shù)據(jù)正確輸入，是否正確返回結(jié)果。測(cè)試接口的正常場(chǎng)景和異常場(chǎng)景
2.邊界測(cè)試：不按照你接口文檔上的要求輸入?yún)?shù)，測(cè)試其邊界情況。比如說必填的參數(shù)不填，輸入整數(shù)類型的正常，超過參數(shù)取值范圍等
3.參數(shù)組合：如果接口中有參數(shù)需要組合用的，兩個(gè)參數(shù)是組合使用，測(cè)試其各種情況
4.異常驗(yàn)證：測(cè)試冪等情況，并發(fā)情況，事務(wù)測(cè)試等異常情況
5.接口安全：繞過驗(yàn)證，敏感信息加密等情況
6.性能測(cè)試：響應(yīng)時(shí)間、并發(fā)數(shù)、吞吐量、服務(wù)器資源利用率
什么是單元測(cè)試、功能測(cè)試、集成測(cè)試？
加分項(xiàng)：單元測(cè)試、功能測(cè)試、集成測(cè)試分別在web端、接口端、移動(dòng)端的定義，你平時(shí)是怎么理解它們的？
單元測(cè)試：是針對(duì)程序模塊來進(jìn)行正確性檢驗(yàn)的測(cè)試工作
功能測(cè)試：在單元測(cè)試的基礎(chǔ)上，測(cè)試某一個(gè)功能點(diǎn)
集成測(cè)試：將所有模塊按照設(shè)計(jì)要求組裝成為子系統(tǒng)或系統(tǒng)，進(jìn)行集成測(cè)試
web端
單元測(cè)試/功能測(cè)試：頁面元素是否正確顯示其有效功能，如提交的action是否正確，搜索點(diǎn)擊是否執(zhí)行
集成測(cè)試：調(diào)用了后端接口的數(shù)據(jù)是否顯示正常，能否滿足需求
接口端：模塊/系統(tǒng)之前的調(diào)用，接口是否與設(shè)計(jì)相符，模塊組合后是否滿足需求
單元測(cè)試：某個(gè)函數(shù)/方法 寫的代碼是否達(dá)到編寫者的預(yù)期
功能測(cè)試：為實(shí)現(xiàn)一個(gè)功能點(diǎn)，調(diào)用幾個(gè)方法/函數(shù)
給定一個(gè)整數(shù)數(shù)組 nums 和一個(gè)目標(biāo)值 target，請(qǐng)你在該數(shù)組中找出和為目標(biāo)值的那 兩個(gè) 整數(shù)，并返回他們的數(shù)組下標(biāo)。
你可以假設(shè)每種輸入只會(huì)對(duì)應(yīng)一個(gè)答案。但是，你不能重復(fù)利用這個(gè)數(shù)組中同樣的元素。
示例:
給定 nums = [2, 7, 11, 15], target = 9
因?yàn)?nums[0] + nums[1] = 2 + 7 = 9
所以返回 [0, 1]
分別用C、Java、Python寫出相關(guān)代碼及測(cè)試用例
Python
def TargetSum(nums,target):
if len(nums) < 2:
return 0
for i in range(0,len(nums)-1):
for j in range (i+1,len(nums)):
if nums[i] + nums[j] == target:
return [i,j]
測(cè)試用例
def test_TargetSum1(self):
assert TargetSum([1,1,3,6,0,2],2) == [0,1]
def test_TargetSum2(self):
assert TargetSum([1],1) == 0
def test_TargetSum3(self):
assert TargetSum([6,2,4,3,1,2],4) == [1,5]
def test_TargetSum4(self):
assert TargetSum([2, 7, 11, 15],9) == [0,1]
Java
public int[] TargetSum(int nums[],int target){
Map<Integer, Integer> map = new HashMap<>();
for(int i=0;i<nums.length;i++){
int temp = target - nums[i];
if(map.containsKey(temp)){
return new int[] { map.get(temp), i };
}
map.put(nums[i],i);
}
return null;
}
