一，測試流程相關(guān)也是面試常問的，常見問法有：

1，發(fā)布流程是什么樣的，或者公司測試流程，工作是怎么開展的

產(chǎn)品那邊會提需求，進(jìn)行需求評審，針對需求有不明確的地方及時跟產(chǎn)品開發(fā)溝通，還要注意與其他模塊或功能會不會有沖突，注意細(xì)節(jié)，之后呢會對這個需求進(jìn)行下拆分，工時的預(yù)估，然后把任務(wù)分配好，開始寫測試用例，測試用例評審，評審?fù)ㄟ^后就會準(zhǔn)備一些測試素材，數(shù)據(jù)之類的，開發(fā)完成后產(chǎn)品會先簡單看一下功能是否符合預(yù)期，可以的話就會提測，測試這邊先冒煙一下，流程跑通了就按照測試用例開始測試，然后發(fā)現(xiàn)bug記錄在平臺上，設(shè)置合理的優(yōu)先級和嚴(yán)重程度，分配給對應(yīng)開發(fā)，跟蹤bug情況，回歸問題，一輪測試完成后會提交到release環(huán)境，進(jìn)行二輪測試，確保新功能不影響之前的功能，測試通過，整理測試報告，部署到線上，測試會進(jìn)行線上的一個簡單的配合測試，確保功能都在，上線成功，之后就可以對外公布，發(fā)布成功了，最新版本號，更新的主要內(nèi)容這些和相關(guān)人員同步，相關(guān)人員確認(rèn)后，就可以把用戶賬號切入新版本，發(fā)布過程中如果有問題，可能需要開發(fā)來做一個緊急修復(fù)，那如果在一定時間比如兩個小時還是不能處理好的話，那就撤掉有影響的這個功能或者設(shè)置開關(guān)發(fā)布，如果是線上問題的話，就安排進(jìn)行版本回滾

2，延期怎么處理，測試怎么趕進(jìn)度：

我們一般在第一輪測試完成后如果bug比較多的情況下，就會考慮延期風(fēng)險，告知項目中的成員，調(diào)整進(jìn)度。如果在臨近上線時候，嚴(yán)重等級高的bug還沒有解決完，那就會考慮延期。

測試能夠做的是提前預(yù)防吧，合理的進(jìn)度規(guī)劃是項目如期推進(jìn)的一個前提，

項目的延期也有各種可能性，：第一個呢就是需求范圍模糊，任務(wù)拆解不合理，導(dǎo)致預(yù)估工時與實(shí)際出現(xiàn)偏差，第二個呢有可能是多項目并行或者臨時插入其他任務(wù)，導(dǎo)致資源沖突，第三個呢就是需求頻繁的變更，團(tuán)隊溝通不及時，第四個呢，需求復(fù)雜，需要跟其他項目組進(jìn)行聯(lián)調(diào)，等接口等，兩邊排期需要協(xié)調(diào)

那么針對不同的情況我們能做的就是在需求評審階段，細(xì)心仔細(xì)，有不明確的地方要及時提出疑問，可能會影響其他模塊的改動也要提出影響范圍，還有工時的確定也要在會上進(jìn)行討論，項目進(jìn)行中有問題的話也要及時溝通調(diào)整，需要跟其他項目聯(lián)調(diào)的需求也提前規(guī)劃好，測試中發(fā)現(xiàn)的問題排好優(yōu)先級，先處理影響流程的，避免block住。然后處理嚴(yán)重程度高的，一些比如界面顯示這類的或者優(yōu)化類的p4bug，影響范圍可控，實(shí)在來不及緩緩也可以

3，你在項目中的角色，重要性體現(xiàn)在哪里？

穩(wěn)定性對于軟件來說還是很重要的，那么測試就是盡可能的去提高測試覆蓋率，減少后期問題的發(fā)生，而且測試工作也是貫穿在整個項目流程中的，比如需求評審階段，產(chǎn)品，開發(fā)，測試考慮問題的切入點(diǎn)都會有差別，從測試思維的話我們就能夠去補(bǔ)充一些沒有考慮到的場景，或者是跟其他模塊功能的沖突這些，完善需求。再者我們寫測試用例，進(jìn)行評審，這個過程也會給開發(fā)補(bǔ)充一下思路，還會標(biāo)注自測用例，這樣開發(fā)在提測前自己簡單跑一下，可以提高功能的質(zhì)量。然后線上bug，測試也能先篩選一下，判斷是用戶操作問題，前端問題，后端問題，幫助開發(fā)節(jié)省時間，快速定位問題

4，版本迭代周期，一個版本寫多少測試用例，有多少個bug

兩周一個版本，周四發(fā)版，一個版本有十多需求，每個需求一般20-30條用例，可能有的模塊相對簡單一些就會少點(diǎn)兒,業(yè)務(wù)邏輯復(fù)雜的話，可能70-80條也是有的，整個版本比較好的情況下大概也就二十來個bug，問題比較多的時候5，60個也是有的，這樣的情況下跟蹤bug以及回歸測試的工作量就比較大了

5，你覺得你們公司流程中不好的地方

我上家公司秉持最好的流程就是以客戶為導(dǎo)向，這也不是不好吧，畢竟公司生存的補(bǔ)給來源都是來自客戶,沒有客戶的維系不會有有任何一家公司可實(shí)現(xiàn)正常的運(yùn)轉(zhuǎn)，但這確實(shí)是給流程中帶來了很多壓力，比如有時候會臨時加需求什么的，很考驗團(tuán)隊的應(yīng)急應(yīng)變能力。遇到這種情況，一般產(chǎn)品那邊先梳理出需求，拉上大家評審，完善下影響范圍，如果項目中有不太緊急的需求就更換一下排期，如果不行的話就只能大家緊急趕工，測試這邊就列下功能要點(diǎn)直接測試，過程中有疑問的也會直接跟產(chǎn)品開發(fā)溝通，測試完成后上線，發(fā)布緊急版本，

6，怎么保證測試覆蓋率

現(xiàn)場環(huán)境總是會比我們的測試場景要復(fù)雜的多的，所以說不可能進(jìn)行完全測試的，我們只能說是盡可能的提高測試覆蓋率：

第一從需求階段開始，盡量理清楚功能，有不明確的地方及時跟產(chǎn)品開發(fā)溝通，還要注意與其他模塊或功能會不會有沖突，注意細(xì)節(jié)

第二測試用例設(shè)計科學(xué)，覆蓋面廣一些，設(shè)計完之后要進(jìn)行用例評審，產(chǎn)品開發(fā)他們從不同的角度考慮問題，有補(bǔ)充的點(diǎn)及時加上

第三就是在測試執(zhí)行的時候要認(rèn)真，特別是回歸的時候，要注意下bug的修復(fù)會不會對前面已經(jīng)測過相關(guān)的功能點(diǎn)的影響

7，緊急需求怎么處理

因為我們的項目直接面向客戶，所以難免會有用戶設(shè)計師或者合作方突然有很緊急的需求，那么一般先由產(chǎn)品經(jīng)理去梳理出大致需求，然后向上發(fā)郵件和OA呈批項目經(jīng)理，通過的話就會馬上加急處理這個需求，測試完成直接上線，發(fā)布緊急版本，當(dāng)然緊急需求的弊端就是很容易需求設(shè)計不完善，或者測試場景覆蓋不全，那我們只能說盡量仔細(xì)，但最好還是提前規(guī)劃好時間或者調(diào)整下項目中其他需求的排期，保證系統(tǒng)穩(wěn)定性。

8，敏捷測試，敏捷開發(fā)

敏捷測試其實(shí)就是“ 快速迭代 ”。敏捷測試就是持續(xù)地對軟件質(zhì)量問題進(jìn)行及時地反饋?？梢栽陧椖块_始時就開始進(jìn)行,而開發(fā)和測試之間會不斷進(jìn)行集成，也就是說是連續(xù)的。測試驅(qū)動產(chǎn)品，開發(fā)，提前預(yù)防缺陷，而不是等開發(fā)完成了才發(fā)現(xiàn)很多問題，從而盡快地交付高質(zhì)量的軟件，這就是質(zhì)量內(nèi)建。

9，上家公司的上線標(biāo)準(zhǔn)

第一，測試用例執(zhí)行完成，第二，剩余bug數(shù)量和嚴(yán)重等級，要達(dá)到一定的標(biāo)準(zhǔn)，比如說不能存在一二級嚴(yán)重程度的bug，遺留的3，4級bug數(shù)量，影響范圍小或者是優(yōu)化類的，當(dāng)然這需要產(chǎn)品去協(xié)同判斷決定，第三，上線前回歸測試，確保不影響之前的功能

?

二，測試文檔方面考察較少，若考察到問的也會比較淺

①測試計劃

內(nèi)容：

測試目標(biāo)，測試范圍，測試環(huán)境的說明，測試方法，測試工具，模塊的劃分，測試負(fù)責(zé)人，測試執(zhí)行的時間安排，測試風(fēng)險

其中模塊的劃分 需要根據(jù)測試人員對于業(yè)務(wù)的熟悉程度以及個人能力進(jìn)行分配，工作量的估算也需要根據(jù)以往的項目經(jīng)驗，結(jié)合本項目的需求情況進(jìn)行評估

②測試報告

內(nèi)容：

測試用例的覆蓋率，用例執(zhí)行情況，功能實(shí)現(xiàn)清單，bug分布情況，bug遺留清單，缺陷分析，測試風(fēng)險