金三銀四已經(jīng)到了，想要找工作，或者是想要跳槽的小伙伴們可要做好準(zhǔn)備了，給大家總結(jié)了軟測(cè)面試必問(wèn)的20道面試題，背完面試不用慌！

1. 項(xiàng)目測(cè)試流程你是怎么開(kāi)展的？

【參考回答】

首先，需求分析階段，主要參與需求評(píng)審會(huì)議，閱讀理解業(yè)務(wù)需求，分析需求點(diǎn)。

需求確定后，進(jìn)入測(cè)試計(jì)劃階段，參考軟件需求規(guī)格說(shuō)明書(shū)及項(xiàng)目總體計(jì)劃，進(jìn)行測(cè)試計(jì)劃編寫(xiě)。 明確測(cè)什么，怎么測(cè)，時(shí)間安排、人員任務(wù)分配，風(fēng)險(xiǎn)評(píng)估。

接著，進(jìn)入測(cè)試設(shè)計(jì)階段，依據(jù)需求文檔及原型圖編寫(xiě)測(cè)試用例，并進(jìn)行用例評(píng)審。

第四，進(jìn)入測(cè)試執(zhí)行階段。我們需要搭建測(cè)試環(huán)境，執(zhí)行冒煙測(cè)試，進(jìn)入正式測(cè)試；并且將測(cè)試缺陷進(jìn)行提交及跟蹤。經(jīng)過(guò)多輪回歸測(cè)試，直到測(cè)試版本結(jié)束。

最后，進(jìn)入測(cè)試評(píng)估階段，對(duì)軟件版本質(zhì)量進(jìn)行評(píng)估，輸出測(cè)試報(bào)告，確認(rèn)是否上線。

2. 接口測(cè)試用例的編寫(xiě)要點(diǎn)有哪些？

【參考回答】

第一：考慮接口的正常調(diào)用

第二：業(yè)務(wù)約束規(guī)則驗(yàn)證；包括鑒權(quán)，邏輯約束

第三：考慮請(qǐng)求參數(shù)必填字段；參數(shù)長(zhǎng)度邊界值驗(yàn)證，類(lèi)型異常、null；參數(shù)名錯(cuò)誤、參數(shù)個(gè)數(shù)+1，參數(shù)個(gè)數(shù)-1 情況

第四：參數(shù)組合驗(yàn)證

第五：容錯(cuò)能力。大容量數(shù)據(jù)、頻繁請(qǐng)求、重復(fù)請(qǐng)求（如：訂單）

第六：性能。對(duì)接口模擬并發(fā)測(cè)試，逐步加壓，分析瓶頸點(diǎn)。

第七：安全性。敏感信息是否加密，構(gòu)造惡意的字符請(qǐng)求，SQL 注入等

3. 怎么定位是前端 bug 還是后端 bug？

【參考回答】

第 1，基于經(jīng)驗(yàn)；如果這個(gè) bug 是界面排版布局錯(cuò)誤，像兼容性問(wèn)題，則很明顯是前端 bug；對(duì)于網(wǎng)絡(luò)不穩(wěn)定下導(dǎo)致的 js/css 未加載完全或請(qǐng)求超時(shí)問(wèn)題，也是前端 bug

第 2，對(duì)于數(shù)據(jù)或邏輯處理上的問(wèn)題，則可以通過(guò)抓包工具fiddler、charles，或者查看日志分析

第 1 種通過(guò)抓包工具，檢查請(qǐng)求地址、參數(shù)的正確性，

1）若不正確，則為前端 bug；若正確則進(jìn)一步檢查服務(wù)器返回的響應(yīng)，若響應(yīng)內(nèi)容不正確，則是后端處理出錯(cuò)；

2）若請(qǐng)求、響應(yīng)都正確，那就是前端渲染響應(yīng)的數(shù)據(jù)出錯(cuò)，則前端 bug

第 2 種，可以查看報(bào)錯(cuò)日志、分析日志里面的異常報(bào)錯(cuò)信息，查看數(shù)據(jù)庫(kù)數(shù)據(jù)判斷前端還是后端問(wèn)題

4. 項(xiàng)目上線后發(fā)現(xiàn)的 bug，你們會(huì)怎么處理呢？

【參考回答】

當(dāng)發(fā)現(xiàn)線上的 bug，項(xiàng)目組應(yīng)快速響應(yīng)處理，先積極配合開(kāi)發(fā)重現(xiàn) bug 定位問(wèn)題；如果是嚴(yán)重 bug，則需積極解決，更新版本；若 bug 不是那么嚴(yán)重，一般會(huì)放到下一個(gè)迭代版本中處理。然后，更重要的是經(jīng)驗(yàn)總結(jié)，反思 bug 出現(xiàn)的原因和規(guī)避方案。

總結(jié)一下常見(jiàn)的線上 bug 原因及規(guī)避方案：

第一，測(cè)試用例覆蓋不全面，尤其用戶(hù)不可控的使用場(chǎng)景，導(dǎo)致出現(xiàn)漏測(cè)。 解決方案：優(yōu)化測(cè)試用例，增加用例評(píng)審。

第二，測(cè)試的時(shí)間不充分，導(dǎo)致一些次要功能點(diǎn)在測(cè)試的過(guò)程中被忽略。解決方案：規(guī)劃充分的測(cè)試時(shí)間，嚴(yán)格按照時(shí)間節(jié)點(diǎn)完成測(cè)試工作

第三、測(cè)試的環(huán)境或者測(cè)試的數(shù)據(jù)受限，導(dǎo)致了測(cè)試不到位。解決方案：考慮 mock 測(cè)試，或者在真實(shí)環(huán)境下覆蓋測(cè)試

第四，開(kāi)發(fā)人員修復(fù)其他問(wèn)題時(shí)，引入了新 bug。解決方案：明確測(cè)試范圍，尤其是代碼修改的功能部分?；貧w測(cè)試時(shí)，主流程必須回歸，必須必須一個(gè)完整流程。

5. http 協(xié)議有哪些響應(yīng)狀態(tài)碼？

【參考回答】

常用的狀態(tài)碼有如下幾種：

1xx（臨時(shí)響應(yīng)）：表示臨時(shí)響應(yīng)并需要請(qǐng)求者繼續(xù)執(zhí)行操作的狀態(tài)代碼。

2xx （成功）：表示成功處理了請(qǐng)求的狀態(tài)代碼。

3xx （重定向）：表示要完成請(qǐng)求，需要進(jìn)一步操作。 通常，這些狀態(tài)代碼用來(lái)重定向。

4xx（請(qǐng)求錯(cuò)誤）：這些狀態(tài)代碼表示請(qǐng)求可能出錯(cuò)，妨礙了服務(wù)器的處理。

5xx（服務(wù)器錯(cuò)誤）：這些狀態(tài)代碼表示服務(wù)器在嘗試處理請(qǐng)求時(shí)發(fā)生內(nèi)部錯(cuò)誤。 這些錯(cuò)誤可能是服務(wù)器本身的錯(cuò)誤，而不是請(qǐng)求出錯(cuò)。

6. 說(shuō)一下 TCP 協(xié)議的三次握手過(guò)程？

【參考回答】

TCP 協(xié)議要建立連接的時(shí)候，需要經(jīng)歷三次握手的過(guò)程：

第一次握手： 是客戶(hù)端向服務(wù)器發(fā)起的，用來(lái)申請(qǐng)建立連接的，這個(gè)報(bào)文中的 SYN 標(biāo)志位標(biāo)記為 1，所以我們也叫作SYN 包；

第二次握手：是服務(wù)器回復(fù)客戶(hù)端的，用來(lái)確認(rèn)并接受連接請(qǐng)求的，這個(gè)報(bào)文中的 SYN 位和 ACK 位都標(biāo)記為 1，所以叫做 SYN-ACK 報(bào)文；

第三次握手：仍然是客戶(hù)端發(fā)給服務(wù)器的，用來(lái)確認(rèn)服務(wù)器的回復(fù)消息，這個(gè)報(bào)文中的 ACK 標(biāo)志位標(biāo)記為 1，所以我們也叫作 ACK 包。

這就是 TCP 協(xié)議的三次握手過(guò)程。

7. 項(xiàng)目頁(yè)面無(wú)法訪問(wèn)，如何定位問(wèn)題？

【參考回答】

首先我會(huì)判斷一下這個(gè)頁(yè)面的域名是都可以正常解析到，避免域名解析的問(wèn)題；

然后，可以用 ping 命令判斷一下服務(wù)器是否可達(dá)；如果不可達(dá)，可以用 tranceroute 命令，查看一下是哪個(gè)節(jié)點(diǎn)出的問(wèn)題；

如果不是網(wǎng)絡(luò)的問(wèn)題，再去后臺(tái)服務(wù)器查看服務(wù)進(jìn)程有無(wú)開(kāi)啟，數(shù)據(jù)庫(kù)服務(wù)有沒(méi)有開(kāi)啟。

這樣子，基本可以找到問(wèn)題所在。

8. 給你一個(gè)產(chǎn)品你是怎么開(kāi)展測(cè)試的？

【參考回答】

首先拿到項(xiàng)目后，要先熟悉需求、原型圖，了解被測(cè)功能和各個(gè)功能的業(yè)務(wù)邏輯；

針對(duì)以上需要測(cè)試的內(nèi)容進(jìn)行大概的測(cè)試規(guī)劃，然后逐個(gè)細(xì)化去設(shè)計(jì)測(cè)試用例。

整個(gè)過(guò)程中存在疑問(wèn)的及時(shí)跟開(kāi)發(fā)產(chǎn)品溝通確認(rèn)。

開(kāi)發(fā)提測(cè)后，按照用例執(zhí)行測(cè)試，提交 bug，并有效進(jìn)行回歸測(cè)試完成 bug 跟蹤；

測(cè)試完畢后，及時(shí)匯報(bào)測(cè)試結(jié)果，輸出測(cè)試報(bào)告

9. 編寫(xiě)測(cè)試用例的流程

【參考回答】

1、熟悉并分析項(xiàng)目業(yè)務(wù)需求

2、依據(jù)功能模塊劃分，使用等價(jià)類(lèi)、邊界值、場(chǎng)景法等用例設(shè)計(jì)方法，先整理功能正常的用例，再到功能中每一個(gè)操作的異常用例的覆蓋，補(bǔ)充業(yè)務(wù)約束，及功能交互項(xiàng)、數(shù)據(jù)驗(yàn)證項(xiàng)等

3、每個(gè)功能模塊分別寫(xiě)完用例后，從項(xiàng)目的業(yè)務(wù)流程考慮，是否都進(jìn)行了用例的覆蓋，沒(méi)有進(jìn)行用例補(bǔ)充

4、另外還補(bǔ)充到界面測(cè)試用例

5、編寫(xiě)完成后，提交評(píng)審

10. 講下你印象中最深刻的 bug 吧？

【參考回答】

這個(gè)問(wèn)題面試前需要提前準(zhǔn)備好。確實(shí)一時(shí)想不起來(lái)，可以跟面試官說(shuō)容我思考一下，然后從以下方面切入：

首先、找一個(gè)自己工作中很熟悉的項(xiàng)目，

然后、思考下如何對(duì)這個(gè)項(xiàng)目進(jìn)行測(cè)試的，

比如，在某一個(gè)功能測(cè)試中，發(fā)現(xiàn)了什么 bug，主要講清楚測(cè)試過(guò)程，排查過(guò)程和驗(yàn)證過(guò)程，中間多講講怎么幫助研發(fā)排查問(wèn)題的就可以了。

11. 怎么判斷一個(gè)接口是否有 bug

【參考回答】

一般呢，先確認(rèn)自己傳參時(shí)的接口地址，請(qǐng)求方式，請(qǐng)求頭和請(qǐng)求體是否是正確的，如果是正確的，那么就查看返回結(jié)果，和接口文檔做對(duì)比，一致則繼續(xù)判斷數(shù)據(jù)庫(kù)中的數(shù)據(jù)是有問(wèn)題。都沒(méi)有那么就說(shuō)明接口是 OK 的

如果接口返回是結(jié)果和文檔不一致，就是有 bug。并且數(shù)據(jù)庫(kù)存儲(chǔ)如果也有問(wèn)題，那也是 bug

12. fiddler 如何構(gòu)造弱網(wǎng)測(cè)試？

【參考回答】

1 、 在 Fiddler 中 Rules 右 鍵 Customize Rules ， 打 開(kāi)CustomRules.js 文檔；

2、修改文檔中，每上傳或下載 1kb 數(shù)據(jù)需要的時(shí)間來(lái)模擬弱網(wǎng)場(chǎng)景(剪輯右圖)

3 、 然 后 Rules->Performance-> 點(diǎn) 擊 Simulate ModemSpeeds，開(kāi)啟弱網(wǎng)模擬。

通過(guò)以上 3 步就可以實(shí)現(xiàn)弱網(wǎng)測(cè)試場(chǎng)景的構(gòu)造。

另外呢，像騰訊的 Qnet 也可以構(gòu)造各種網(wǎng)絡(luò)場(chǎng)景進(jìn)行測(cè)試，也可以去補(bǔ)充下了解。

13. https 協(xié)議比 http 安全，是如何實(shí)現(xiàn)的呢?

【參考回答】

https 協(xié)議通過(guò) SSL 協(xié)議外殼來(lái)實(shí)現(xiàn)它的安全性，主要體現(xiàn)在三個(gè)方面：

第一： 數(shù)據(jù)是加密的，SSL 協(xié)議通過(guò)非對(duì)稱(chēng)秘鑰分發(fā)的方式完成秘鑰的協(xié)商，然后通過(guò)對(duì)稱(chēng)秘鑰的加密方式完成數(shù)據(jù)的加密；

第二：會(huì)驗(yàn)證對(duì)方身份。服務(wù)端和客戶(hù)端雙方會(huì)需要向 CA機(jī)構(gòu)申請(qǐng)證書(shū)，再 SSL 握手階段會(huì)驗(yàn)證雙方證書(shū)是否可信，從而驗(yàn)證雙方的身份，防止第三方冒充；

第三：保證數(shù)據(jù)的完整性。每次的數(shù)據(jù)都會(huì)加上 MAC 摘要并簽名，接收的數(shù)據(jù)和發(fā)送的數(shù)據(jù)這個(gè)摘要信息一致的，就表示數(shù)據(jù)沒(méi)有被篡改過(guò)。

14. 如果讓你單獨(dú)負(fù)責(zé)一個(gè)項(xiàng)目，需要注意什么呢?

【參考回答】

1.首先，評(píng)估項(xiàng)目的測(cè)試范圍和周期，能否單獨(dú)完成，若不能，及時(shí)反饋并協(xié)調(diào)人手

2.做好測(cè)試策略和計(jì)劃安排，盡量保證每個(gè)環(huán)節(jié)按時(shí)完成

3.在上手測(cè)試前，梳理大致的測(cè)試點(diǎn)，先做冒煙

4.測(cè)試中，盡量通過(guò)一些技術(shù)手段提升測(cè)試效率

5.項(xiàng)目中，若碰到自己解決不了問(wèn)題，要及時(shí)向外拋出并積極尋求解決方案

6.及時(shí)對(duì) bug 進(jìn)行追蹤，推動(dòng)開(kāi)發(fā)盡快解決 bug

7.把控發(fā)布標(biāo)準(zhǔn)，測(cè)試報(bào)告中標(biāo)明上線風(fēng)險(xiǎn)

15. 給你一個(gè)微信上一個(gè)聊天的窗口你是怎么測(cè)試的？

【參考回答】

微信聊天框的主要功能就是發(fā)送消息和接收別人發(fā)過(guò)來(lái)的消息。

消息的分類(lèi)：純文字，圖片，文件，表情，語(yǔ)音、視頻，文字+表情

聊天的特殊功能：@符號(hào)，撤回功能，加好友功能，消息重發(fā)，發(fā)紅包，轉(zhuǎn)賬，發(fā)送位置信息、發(fā)送名片、群聊等功能

16. 偶發(fā)性 bug，作為測(cè)試該怎么處理？

【參考回答】

a.首先，在遇到復(fù)現(xiàn)率低的 bug，一定要提 bug，描述清楚當(dāng)時(shí)出現(xiàn)問(wèn)題的步驟、操作環(huán)境、賬號(hào)及測(cè)試數(shù)據(jù)、及必要的日志信息。

b.在發(fā)現(xiàn) bug 時(shí)，要分析產(chǎn)生的原因，盡量多嘗試可能出現(xiàn)的步驟，排除環(huán)境和自己電腦配置的原因，比如瀏覽器的版本等。甚至可以讓開(kāi)發(fā)對(duì)相應(yīng)地方的代碼進(jìn)行檢查，看一下是否可以通過(guò)代碼層面檢查問(wèn)題。

c.如果未復(fù)現(xiàn)，在接下來(lái)的測(cè)試中，時(shí)刻保持關(guān)注，每次執(zhí)行同樣或者相近的步驟的時(shí)候，看下是否能夠復(fù)現(xiàn)之前的 bug。

d.那些一直未能復(fù)現(xiàn)的 bug，需要測(cè)試經(jīng)理定期將這些 bug 匯總，選擇優(yōu)先級(jí)高的缺陷，組織開(kāi)發(fā)人員和測(cè)試人員專(zhuān)門(mén)投入到復(fù)現(xiàn)問(wèn)題。如果經(jīng)過(guò)這樣的專(zhuān)門(mén)復(fù)現(xiàn)依然不能復(fù)現(xiàn)，可以降低問(wèn)題的優(yōu)先級(jí)。

e、另外，項(xiàng)目發(fā)布后，跟蹤至少 3 個(gè)版本，及時(shí)關(guān)注用戶(hù)的使用反饋，如果仍然無(wú)復(fù)現(xiàn)，可以暫時(shí)關(guān)閉該bug，備注說(shuō)明并不是因?yàn)樾迯?fù)關(guān)閉，而是經(jīng)過(guò) n 個(gè)版本后不復(fù)現(xiàn)了。

17. 你們公司版本上線標(biāo)準(zhǔn)是怎樣的？

【參考回答】

1、測(cè)試用例是否執(zhí)行完成。對(duì)于覆蓋產(chǎn)品需求點(diǎn)的用例要達(dá)到 100%執(zhí)行，若不能全部執(zhí)行，需要標(biāo)明未執(zhí)行原因，例如時(shí)間原因或優(yōu)先級(jí)比較低的易用性測(cè)試用例；

2、剩余 bug 的數(shù)量和嚴(yán)重等級(jí)要達(dá)到標(biāo)準(zhǔn)。

①? 不存在 1、2 級(jí)嚴(yán)重等級(jí)的 bug

②遺留的 3、4 級(jí) bug 數(shù)量需要經(jīng)過(guò)產(chǎn)品經(jīng)理和測(cè)試經(jīng)理協(xié)同決定可遺漏數(shù)量

3、上線前的最后一輪回歸測(cè)試是否完成。最后一個(gè)版本也就是上線的版本一定要經(jīng)過(guò)一輪完整的回歸。

以上是公司規(guī)定的上線標(biāo)準(zhǔn)，不同的公司規(guī)定不同標(biāo)準(zhǔn)不同，不同項(xiàng)目也會(huì)依據(jù)實(shí)際情況，對(duì)以上 3 個(gè)上線標(biāo)準(zhǔn)存在靈活的調(diào)整

18. 測(cè)試進(jìn)行不下去的時(shí)候，怎么辦？

【參考回答】

這個(gè)就需要分析一下是什么原因?qū)е聹y(cè)試工作進(jìn)行不下去

1、如果因?yàn)?bug 導(dǎo)致測(cè)試阻塞的話(huà)，需要將 bug 及時(shí)反饋給開(kāi)發(fā)并協(xié)助解決，且需及時(shí)向領(lǐng)導(dǎo)匯報(bào)測(cè)試阻斷原因。

2、如果是測(cè)試時(shí)間緊張導(dǎo)致的話(huà)，也需及時(shí)匯報(bào)領(lǐng)導(dǎo)，是否調(diào)配人手或通過(guò)自動(dòng)化手段提高效率，不要一個(gè)人盲目的承擔(dān)。

3、因?yàn)闇y(cè)試數(shù)據(jù)不好造導(dǎo)致的，可以通過(guò)數(shù)據(jù)庫(kù)或者接口去制造測(cè)試數(shù)據(jù)，實(shí)在是太難的可以請(qǐng)求開(kāi)發(fā)的幫助。

4、若是因?yàn)闇y(cè)試環(huán)境導(dǎo)致的，及時(shí)排查環(huán)境原因，且及時(shí)向領(lǐng)導(dǎo)反饋問(wèn)題

19. 你講一下登錄功能，你會(huì)考慮哪些測(cè)試點(diǎn)呢？

【參考回答】

功能測(cè)試：檢查系統(tǒng)登錄功能是否滿(mǎn)足需求。

界面測(cè)試：檢查登錄界面元素、風(fēng)格是否符合需求，有沒(méi)有分辨率不清晰、頁(yè)面錯(cuò)亂或遮擋等情況。

性能測(cè)試：檢查系統(tǒng)響應(yīng)時(shí)間，大數(shù)據(jù)并發(fā)響應(yīng)時(shí)間。

本地化測(cè)試：系統(tǒng)需要支持多種語(yǔ)言或多個(gè)國(guó)家上線時(shí)，切換語(yǔ)言時(shí)系統(tǒng)功能穩(wěn)定性。

兼容性測(cè)試：對(duì)不同操作系統(tǒng)、瀏覽器是否可以正常工作。

可用性測(cè)試：檢查系統(tǒng)的有效性、效率、易用性以及容錯(cuò)能力。

安全測(cè)試：輸入框是否屏蔽sql注入、xss攻擊、輸入錯(cuò)誤密碼次數(shù)限制等。

20. 怎么保證測(cè)試用例的覆蓋率？

【參考回答】

測(cè)試用例的覆蓋率，可以從分析-編寫(xiě)-執(zhí)行 3 個(gè)部分來(lái)講

1.從需求階段開(kāi)始，盡量理清楚產(chǎn)品的大致功能及功能模塊的聯(lián)系，同時(shí)參考同類(lèi)型已成熟的產(chǎn)品，去熟悉需求細(xì)節(jié)，把需求,不明確的部分及時(shí)跟產(chǎn)品及開(kāi)發(fā)溝通；

2.需求確定后，時(shí)間緊張的話(huà)，按功能模塊去整理測(cè)試點(diǎn)，運(yùn)用科學(xué)合理的用例設(shè)計(jì)方法比如等價(jià)類(lèi)、邊界值、場(chǎng)景法、決,策表來(lái)進(jìn)行設(shè)計(jì)；整理完成后，我們測(cè)試內(nèi)部會(huì)進(jìn)行測(cè)試點(diǎn)的評(píng)審，進(jìn)而保證對(duì)于需求覆蓋的完整性；

3.按照測(cè)試用例測(cè)試執(zhí)行過(guò)程中，難免出現(xiàn)用例覆蓋不到的，會(huì)做好用例補(bǔ)充；

除此之外還有更多的高頻面試題，可以留言獲取哦