2020新版軟件測(cè)試常見面試題匯總

軟件測(cè)試常見面試題匯總

項(xiàng)目的測(cè)試流程

1. 拿到需求文檔后，寫測(cè)試用例

2. 審核測(cè)試用例

3. 等待開發(fā)包

4. 部署測(cè)試環(huán)境

5. 冒煙測(cè)試(網(wǎng)頁架構(gòu)圖)

6. 頁面初始化測(cè)試(查看數(shù)據(jù)庫中的數(shù)據(jù)內(nèi)容和頁面展示的內(nèi)容是否一致，并且是否按照某些順序排列)

7 .具體執(zhí)行測(cè)試用例(幾乎所有的功能測(cè)試、流程法、場(chǎng)景法)

8. 發(fā)現(xiàn)缺陷就要再填寫缺陷表

9. 非功能性測(cè)試(sql、js注入、頁面效率、繞過js驗(yàn)證直接添加數(shù)據(jù)到數(shù)據(jù)庫)

10. 書寫最終的測(cè)試報(bào)告

測(cè)試用例設(shè)計(jì)方法

等價(jià)類、邊界值、正交試驗(yàn)法、狀態(tài)遷移法、因果圖、場(chǎng)景測(cè)試法、異常分析法、因果圖、錯(cuò)誤猜測(cè)法、判定表

測(cè)試用例的要素

Id 主題 測(cè)試名稱 創(chuàng)建日期 設(shè)計(jì)者 描述 步驟名 步驟描述 預(yù)期結(jié)果 執(zhí)行狀態(tài)

測(cè)試的優(yōu)先級(jí)

1.先測(cè)試經(jīng)過變更的部分，然后測(cè)試沒有變更的部分

2.先測(cè)試程序的核心功能，然后測(cè)試一般功能

3.先測(cè)試邏輯性的功能，然后測(cè)試業(yè)務(wù)性的功能

4.先測(cè)試常規(guī)情況，然后測(cè)試異常情況

5.先測(cè)試功能，然后測(cè)試性能

測(cè)試報(bào)告包含哪些內(nèi)容

1.寫測(cè)試背景

2.測(cè)試目標(biāo)

3.測(cè)試范圍

4.測(cè)試環(huán)境

5.測(cè)試數(shù)據(jù)

6.測(cè)試標(biāo)準(zhǔn)(重點(diǎn))

7.測(cè)試進(jìn)度

8.測(cè)試結(jié)果

9.測(cè)試結(jié)論有的公司會(huì)采用非標(biāo)準(zhǔn)的測(cè)試報(bào)告

大致會(huì)包含 測(cè)試所用時(shí)間 測(cè)試環(huán)境 測(cè)試人員 測(cè)試發(fā)現(xiàn)bug數(shù)量已修復(fù)bug數(shù)量 遺留bug 遺留bug原因測(cè)試結(jié)果等。

BUG的生命周期

提交--開發(fā)驗(yàn)證--接受--拒絕--開發(fā)解決--測(cè)試人員驗(yàn)證--關(guān)閉--不通過打開

BUG的狀態(tài)

1.NEW：所有提交到開發(fā)對(duì)接的問題狀態(tài)為NEW，表示為未處理

2.OPEN：開發(fā)對(duì)接人初判為需流轉(zhuǎn)問題，指定測(cè)試人員和開發(fā)人員，狀態(tài)為OPEN。

3.REFUSE：開發(fā)對(duì)接人判斷為不需要流轉(zhuǎn)至下環(huán)節(jié)的問題，狀態(tài)為REFUSE，并且填寫原因

4.FIXED：開發(fā)人員完成修復(fù)，待測(cè)試，狀態(tài)為FIXED

5.REOPEN：測(cè)似人員針對(duì)開發(fā)人員的修復(fù)結(jié)果測(cè)試部通過，狀態(tài)為REOPEN

6.CLOSE：測(cè)試人員判斷問題為需求或其他問題，需填寫原因;

缺陷的要素

缺陷標(biāo)題 缺陷狀態(tài) 提交人 負(fù)責(zé)人 優(yōu)先級(jí) 嚴(yán)重程度 缺陷描述 時(shí)間 截圖

缺陷的級(jí)別

致命問題 核心功能不可用或系統(tǒng)崩潰

嚴(yán)重問題 業(yè)務(wù)主要流程無法使用，業(yè)務(wù)主要流程中的某個(gè)功能存在缺陷導(dǎo)致主要流程無法繼續(xù)使用

一般問題 一般性問題，非主要流程上的功能缺陷

輕微問題 界面ui問題，提示不規(guī)范等

建議性問題 根據(jù)自己的經(jīng)驗(yàn)提一些建議性的問題

WEB測(cè)試與APP測(cè)試的區(qū)別

1. 架構(gòu)不同。

web端是b/s架構(gòu)的，b/s架構(gòu)是基于瀏覽器地址訪問的

app端是c/s架構(gòu)的，c/s架構(gòu)是要有客戶端作為載體的

2. 版本發(fā)布的方式和流程不同。

web發(fā)版本，開發(fā)部署新的代碼到對(duì)應(yīng)服務(wù)器地址，就可統(tǒng)一實(shí)現(xiàn)web端的更新

app發(fā)版本，開發(fā)需要打包(apk包和ipa包)，打包之后需要發(fā)布到對(duì)應(yīng)的渠道

3. 兼容性

web，測(cè)試不同瀏覽器的兼容性(ie、chrome、firefox、360、QQ)

app，測(cè)試不同的分辨率、屏幕尺寸、手機(jī)品牌、系統(tǒng)版本

4. 性能方面

web，測(cè)試響應(yīng)的時(shí)間

app，測(cè)試響應(yīng)時(shí)間、流量、耗電量、CPU、GPU、memory

5. 安全性

web，sql注入。xss攻擊等

app，https加密、簽名、加固、密碼加密等

6、app測(cè)試特點(diǎn)

·適配性測(cè)試

·網(wǎng)絡(luò)測(cè)試

·在線升級(jí)測(cè)試

·中斷測(cè)試耗

·電量測(cè)試

·弱網(wǎng)測(cè)試

·安裝卸載測(cè)試

·流量測(cè)試

app測(cè)試的主要內(nèi)容

1.功能測(cè)試

業(yè)務(wù)邏輯正確性的測(cè)試

2.兼容性測(cè)試

·系統(tǒng)版本

·分辨率

·網(wǎng)絡(luò)情況

3.異常測(cè)試

·熱啟動(dòng)

·網(wǎng)絡(luò)切換

·電話信息終端恢復(fù)

4.升級(jí)、安裝、卸載

5.健壯性測(cè)試

·手機(jī)資源消耗

·流量消耗

·電量測(cè)試

·崩潰恢復(fù)

如果一個(gè)bug，開發(fā)認(rèn)為不是一個(gè)bug，怎么處理

1. 將問題提交到缺陷管理庫里面進(jìn)行備案。

2. 獲取判斷的依據(jù)和標(biāo)準(zhǔn)根據(jù)需求說明書、產(chǎn)品說明、設(shè)計(jì)文檔等，確認(rèn)實(shí)際結(jié)果是否與計(jì)劃有不一致的地方，提供缺陷是否確認(rèn)的直接依據(jù);

如果沒有文檔依據(jù)，可以根據(jù)類似軟件的一般特性來說明是否存在不一致的地方，來確認(rèn)是否是缺陷;

根據(jù)用戶的一般使用習(xí)慣，來確認(rèn)是否是缺陷;

與設(shè)計(jì)人員、開發(fā)人員和客戶代表等相關(guān)人員探討，確認(rèn)是否是缺陷;

3. 合理的論述，向測(cè)試經(jīng)理說明自己的判斷的理由，注意客觀、嚴(yán)謹(jǐn)，不參雜個(gè)人情緒。

4. 等待測(cè)試經(jīng)理做出最終決定，如果仍然存在爭(zhēng)議，可以通過公司政策所提供的渠道，向上級(jí)反映，并有上級(jí)做出決定。

常用linux命令

1. ifconfig 查看IP地址

2. cat 用于顯示指定文件的全部?jī)?nèi)容

3. more 用分頁的形式顯示指定文件的內(nèi)容

4. mkdir 創(chuàng)建目錄

5. touch 創(chuàng)建新的文件

6. grep 查找文件里符合條件的字符串

7. find 查找指定的文件

8. tail -f 用于自動(dòng)刷新顯示文件后N行數(shù)據(jù)內(nèi)容

9. kill -9 強(qiáng)制結(jié)束

10. netstat -anp | grep 端口號(hào) 查看端口

11. chmod -R 777 賦予777權(quán)限

什么情況下定位不到元素

1. 代碼寫錯(cuò)

2. 元素未出現(xiàn)(需要元素等待)

3. 元素在iframe中

4. 多窗口

5. 出現(xiàn)彈窗(系統(tǒng)彈窗、JS彈窗)

6. 元素屬性值是動(dòng)態(tài)加載的

7. 元素?zé)o法確定唯一性

8. 只讀屬性(元素不可操作)

GET請(qǐng)求和POST請(qǐng)求的區(qū)別

1. GET使用URL或Cookies傳參，POST將數(shù)據(jù)放在BODY中

2. GET的URL會(huì)有長(zhǎng)度上的限制，POST的數(shù)據(jù)則可以非常大

3. POST比GET安全，因?yàn)樵诘刂窓诓豢梢?/p>

4. 一般GET用來獲取數(shù)據(jù)，POST用來發(fā)送數(shù)據(jù)

為什么要做接口測(cè)試

1. 越底層發(fā)現(xiàn)BUG，修復(fù)成本越低

2. 前端發(fā)生變化時(shí)，后端接口可以不用變

3. 檢查系統(tǒng)的安全性、穩(wěn)定性，前端傳參不可信

接口測(cè)試是怎么做的

由于我們項(xiàng)目前后端調(diào)用主要是基于http協(xié)議的接口，所以測(cè)試接口時(shí)主要是通過工具或代碼模擬http請(qǐng)求的發(fā)送與接收。工具有很多如：postman、jmeter、soupUI等。

也可以用 接口自動(dòng)化來實(shí)現(xiàn)，就是用代碼實(shí)現(xiàn)，框架和UI自動(dòng)化差不多，發(fā)送請(qǐng)求用斷言來判斷。

接口測(cè)試的重點(diǎn)

1. 檢查接口返回的數(shù)據(jù)是否與預(yù)期的結(jié)果一致

2. 檢查接口的容錯(cuò)性，加入傳遞的類型錯(cuò)誤時(shí)是否可以處理

3. 接口測(cè)試的邊界值

4. 接口的性能

5. 接口的安全性

http狀態(tài)碼

1. cookies數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務(wù)器上;

2. cookies不是很安全，別人可以分析存放在本地的cookies并進(jìn)行cookies欺騙考慮到安全應(yīng)當(dāng)使用 session;

3. session會(huì)在一定時(shí)間內(nèi)保存在服務(wù)器上，當(dāng)訪問增多，會(huì)比較占用，你服務(wù)器的性能考慮到減輕服務(wù)器性能方面，應(yīng)當(dāng)使用cookies。

常用的adb命令

1. adb start-server 啟動(dòng)adb服務(wù)

2. adb kill-server 關(guān)閉adb服務(wù)

3. adb devices 查看設(shè)備號(hào)

4. adb push 電腦 手機(jī)

5. adb pull 手機(jī) 電腦

6. adb logcat | grep 包名(unix)

7. adb logcat | findstr 包名 (win)

8. adb shell 進(jìn)入shell命令行

9. adb install 安裝app到手機(jī)上

10. adb uninstall 卸載app到手機(jī)上

11. adb logcat > 文件名 輸出log到文件

12. adb shell top 測(cè)試app的資源消耗命令

產(chǎn)品的業(yè)務(wù)流程

解析

問你簡(jiǎn)歷上寫的某個(gè)項(xiàng)目整體的業(yè)務(wù)流程比如電商項(xiàng)目中的注冊(cè)功能，從開始注冊(cè)到注冊(cè)成功的整個(gè)過程

版本符合上線的標(biāo)準(zhǔn)是什么

驗(yàn)收標(biāo)準(zhǔn)

(1) 軟件需求分析說明書中定義的所有功能已全部實(shí)現(xiàn)，性能指標(biāo)全部達(dá)到要求。

(2) 在驗(yàn)收測(cè)試中發(fā)現(xiàn)的錯(cuò)誤已經(jīng)得到修改，各級(jí)缺陷修復(fù)率達(dá)到標(biāo)準(zhǔn)

(3) 所有測(cè)試項(xiàng)沒有殘余緊急、嚴(yán)重級(jí)別錯(cuò)誤。

(4) 需求分析文檔、設(shè)計(jì)文檔和編碼實(shí)現(xiàn)一致。

(5) 驗(yàn)收測(cè)試工件齊全(測(cè)試計(jì)劃、測(cè)試用例、測(cè)試日志、測(cè)試通知單、測(cè)試分析報(bào)告，待驗(yàn)收的軟件安裝程序。)

缺陷修復(fù)率標(biāo)準(zhǔn)

(1) 緊急、嚴(yán)重級(jí)別錯(cuò)誤修復(fù)率應(yīng)達(dá)到100%;

(2) 普通級(jí)別錯(cuò)誤修復(fù)率應(yīng)達(dá)到95%以上;

(3) 優(yōu)化級(jí)別錯(cuò)誤修復(fù)率應(yīng)達(dá)到60%以上; 注：項(xiàng)目緊急時(shí)，普通級(jí)別錯(cuò)誤修復(fù)率達(dá)60% 以上;優(yōu)化級(jí)別錯(cuò)誤修復(fù)率達(dá)20% 即可。

服務(wù)器運(yùn)行狀態(tài)響應(yīng)指標(biāo)

(1) cpu% 并發(fā)期間最大使用率應(yīng)不超過70-80%，如有集合點(diǎn)并發(fā)可允許短暫接近或到達(dá)100& 但大部分不應(yīng)查過95%; (2) memery 測(cè)試期間保證內(nèi)存充足可用內(nèi)存不少于20%;

(3) disk 監(jiān)控硬盤是否有讀寫不超過40%;

(4) cpu load average 不應(yīng)超過cpu 核心數(shù)*2 或者不超過cpu 核心數(shù)。

測(cè)試用例評(píng)審過程及相關(guān)參與人員

1:評(píng)審的過程

A:開始前做好如下準(zhǔn)備

(1)確定需要評(píng)審的原因

(2)確定進(jìn)行評(píng)審的時(shí)機(jī)

(3)確定參與評(píng)審人員

(4)明確評(píng)審的內(nèi)容

(5)確定評(píng)審結(jié)束標(biāo)準(zhǔn)

(6)提前至少一天將需要評(píng)審的內(nèi)容以郵件的形式發(fā)送給評(píng)審會(huì)議相關(guān)人員。并注明詳審時(shí)間、地點(diǎn)及償參與人員等。

(7)在郵件中提醒評(píng)審會(huì)議相關(guān)人員至少簡(jiǎn)讀一遍評(píng)審內(nèi)容，并記錄相關(guān)的疑問，以便在評(píng)審會(huì)議上提出。

(8)會(huì)議主持者(一般為用例編寫人員)應(yīng)在會(huì)議前整理相關(guān)疑問，以便在會(huì)議上提出。

B：開始評(píng)審

(1)召開評(píng)審會(huì)議。與會(huì)者在設(shè)計(jì)人員講解之后給出意見和建議，同時(shí)進(jìn)行詳細(xì)的評(píng)審記錄。

(2)通用郵件與相關(guān)人員溝通

(3)通用IM工具直接與相關(guān)人員交流

(4)根據(jù)評(píng)審內(nèi)容進(jìn)行評(píng)審

2：評(píng)審內(nèi)容

(1)用例設(shè)計(jì)的結(jié)構(gòu)安排是否清晰、合理，是否利于高效對(duì)需求進(jìn)行覆蓋。

(2)優(yōu)先極安排是否合理。

(3)是否覆蓋測(cè)試需求上的所有功能點(diǎn)。

(4)用例是否具有很好可執(zhí)行性。例如用例的前提條件、執(zhí)行步驟、輸入數(shù)據(jù)和期待結(jié)果是否清晰、正確;期待結(jié)果是否有明顯的驗(yàn)證方法。

(5)是否已經(jīng)刪除了冗余的用例。

(6)是否包含充分的負(fù)面測(cè)試用例。充分的定義，如果在這里使用2&8法則，那就是4倍于正面用例的數(shù)量，畢竟一個(gè)健壯的軟件，其中80%的代碼都是在“保護(hù)”20%的功能實(shí)現(xiàn)。

(7)是否從用戶層面來設(shè)計(jì)用戶使用場(chǎng)景和使用流程的測(cè)試用例。

(8)是否簡(jiǎn)潔，復(fù)用性強(qiáng)。例如，可將重復(fù)度高的步驟或過程抽取出來定義為一些可復(fù)用標(biāo)準(zhǔn)步驟。

3：參與評(píng)審人員(這里會(huì)分為多個(gè)級(jí)別進(jìn)行評(píng)審)

(1)部門評(píng)審，測(cè)試部門全體成員參與的評(píng)審。

(2)公司評(píng)審，這里包括了項(xiàng)目經(jīng)理、需求分析人員、架構(gòu)設(shè)計(jì)人員、開發(fā)人員和測(cè)試人員。

(3)客戶評(píng)審，包括了客戶方的開發(fā)人員和測(cè)試人員。這種情況在外包公司比較常見。


猜你喜歡：

最全的軟件測(cè)試面試題(含答案)

2019年互聯(lián)網(wǎng)企業(yè)軟件測(cè)試面試題(常考)

軟件測(cè)試面試必看寶典(含面試題和筆試題)

全套軟件測(cè)試面試筆試題(附答案)

78道軟件測(cè)試面試題匯總(包含答案)

軟件測(cè)試培訓(xùn)課程