更新時間:2020-07-29 來源:黑馬程序員 瀏覽量:
項目的測試流程
1. 拿到需求文檔后，寫測試用例
2. 審核測試用例
3. 等待開發(fā)包
4. 部署測試環(huán)境
5. 冒煙測試(網(wǎng)頁架構(gòu)圖)
6. 頁面初始化測試(查看數(shù)據(jù)庫中的數(shù)據(jù)內(nèi)容和頁面展示的內(nèi)容是否一致，并且是否按照某些順序排列)
7 .具體執(zhí)行測試用例(幾乎所有的功能測試、流程法、場景法)
8. 發(fā)現(xiàn)缺陷就要再填寫缺陷表
9. 非功能性測試(sql、js注入、頁面效率、繞過js驗證直接添加數(shù)據(jù)到數(shù)據(jù)庫)
10. 書寫最終的測試報告
測試用例設(shè)計方法
等價類、邊界值、正交試驗法、狀態(tài)遷移法、因果圖、場景測試法、異常分析法、因果圖、錯誤猜測法、判定表
測試用例的要素
Id 主題 測試名稱 創(chuàng)建日期 設(shè)計者 描述 步驟名 步驟描述 預(yù)期結(jié)果 執(zhí)行狀態(tài)
測試的優(yōu)先級
1.先測試經(jīng)過變更的部分，然后測試沒有變更的部分
2.先測試程序的核心功能，然后測試一般功能
3.先測試邏輯性的功能，然后測試業(yè)務(wù)性的功能
4.先測試常規(guī)情況，然后測試異常情況
5.先測試功能，然后測試性能
測試報告包含哪些內(nèi)容
1.寫測試背景
2.測試目標
3.測試范圍
4.測試環(huán)境
5.測試數(shù)據(jù)
6.測試標準(重點)
7.測試進度
8.測試結(jié)果
9.測試結(jié)論有的公司會采用非標準的測試報告
大致會包含 測試所用時間 測試環(huán)境 測試人員 測試發(fā)現(xiàn)bug數(shù)量已修復(fù)bug數(shù)量 遺留bug 遺留bug原因測試結(jié)果等。
BUG的生命周期
提交--開發(fā)驗證--接受--拒絕--開發(fā)解決--測試人員驗證--關(guān)閉--不通過打開
BUG的狀態(tài)
1.NEW：所有提交到開發(fā)對接的問題狀態(tài)為NEW，表示為未處理
2.OPEN：開發(fā)對接人初判為需流轉(zhuǎn)問題，指定測試人員和開發(fā)人員，狀態(tài)為OPEN。
3.REFUSE：開發(fā)對接人判斷為不需要流轉(zhuǎn)至下環(huán)節(jié)的問題，狀態(tài)為REFUSE，并且填寫原因
4.FIXED：開發(fā)人員完成修復(fù)，待測試，狀態(tài)為FIXED
5.REOPEN：測似人員針對開發(fā)人員的修復(fù)結(jié)果測試部通過，狀態(tài)為REOPEN
6.CLOSE：測試人員判斷問題為需求或其他問題，需填寫原因;
缺陷的要素
缺陷標題 缺陷狀態(tài) 提交人 負責(zé)人 優(yōu)先級 嚴重程度 缺陷描述 時間 截圖
缺陷的級別
致命問題 核心功能不可用或系統(tǒng)崩潰
嚴重問題 業(yè)務(wù)主要流程無法使用，業(yè)務(wù)主要流程中的某個功能存在缺陷導(dǎo)致主要流程無法繼續(xù)使用
一般問題 一般性問題，非主要流程上的功能缺陷
輕微問題 界面ui問題，提示不規(guī)范等
建議性問題 根據(jù)自己的經(jīng)驗提一些建議性的問題
WEB測試與APP測試的區(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ā)部署新的代碼到對應(yīng)服務(wù)器地址，就可統(tǒng)一實現(xiàn)web端的更新
app發(fā)版本，開發(fā)需要打包(apk包和ipa包)，打包之后需要發(fā)布到對應(yīng)的渠道
3. 兼容性
web，測試不同瀏覽器的兼容性(ie、chrome、firefox、360、QQ)
app，測試不同的分辨率、屏幕尺寸、手機品牌、系統(tǒng)版本
4. 性能方面
web，測試響應(yīng)的時間
app，測試響應(yīng)時間、流量、耗電量、CPU、GPU、memory
5. 安全性
web，sql注入。xss攻擊等
app，https加密、簽名、加固、密碼加密等
6、app測試特點
·適配性測試
·網(wǎng)絡(luò)測試
·在線升級測試
·中斷測試耗
·電量測試
·弱網(wǎng)測試
·安裝卸載測試
·流量測試
app測試的主要內(nèi)容
1.功能測試
業(yè)務(wù)邏輯正確性的測試
2.兼容性測試
·系統(tǒng)版本
·分辨率
·網(wǎng)絡(luò)情況
3.異常測試
·熱啟動
·網(wǎng)絡(luò)切換
·電話信息終端恢復(fù)
4.升級、安裝、卸載
5.健壯性測試
·手機資源消耗
·流量消耗
·電量測試
·崩潰恢復(fù)
如果一個bug，開發(fā)認為不是一個bug，怎么處理
1. 將問題提交到缺陷管理庫里面進行備案。
2. 獲取判斷的依據(jù)和標準根據(jù)需求說明書、產(chǎn)品說明、設(shè)計文檔等，確認實際結(jié)果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據(jù);
如果沒有文檔依據(jù)，可以根據(jù)類似軟件的一般特性來說明是否存在不一致的地方，來確認是否是缺陷;
根據(jù)用戶的一般使用習(xí)慣，來確認是否是缺陷;
與設(shè)計人員、開發(fā)人員和客戶代表等相關(guān)人員探討，確認是否是缺陷;
3. 合理的論述，向測試經(jīng)理說明自己的判斷的理由，注意客觀、嚴謹，不參雜個人情緒。
4. 等待測試經(jīng)理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，并有上級做出決定。
常用linux命令
1. ifconfig 查看IP地址
2. cat 用于顯示指定文件的全部內(nèi)容
3. more 用分頁的形式顯示指定文件的內(nèi)容
4. mkdir 創(chuàng)建目錄
5. touch 創(chuàng)建新的文件
6. grep 查找文件里符合條件的字符串
7. find 查找指定的文件
8. tail -f 用于自動刷新顯示文件后N行數(shù)據(jù)內(nèi)容
9. kill -9 強制結(jié)束
10. netstat -anp | grep 端口號 查看端口
11. chmod -R 777 賦予777權(quán)限
什么情況下定位不到元素
1. 代碼寫錯
2. 元素未出現(xiàn)(需要元素等待)
3. 元素在iframe中
4. 多窗口
5. 出現(xiàn)彈窗(系統(tǒng)彈窗、JS彈窗)
6. 元素屬性值是動態(tài)加載的
7. 元素?zé)o法確定唯一性
8. 只讀屬性(元素不可操作)
GET請求和POST請求的區(qū)別
1. GET使用URL或Cookies傳參，POST將數(shù)據(jù)放在BODY中
2. GET的URL會有長度上的限制，POST的數(shù)據(jù)則可以非常大
3. POST比GET安全，因為在地址欄不可見
4. 一般GET用來獲取數(shù)據(jù)，POST用來發(fā)送數(shù)據(jù)
為什么要做接口測試
1. 越底層發(fā)現(xiàn)BUG，修復(fù)成本越低
2. 前端發(fā)生變化時，后端接口可以不用變
3. 檢查系統(tǒng)的安全性、穩(wěn)定性，前端傳參不可信
接口測試是怎么做的
由于我們項目前后端調(diào)用主要是基于http協(xié)議的接口，所以測試接口時主要是通過工具或代碼模擬http請求的發(fā)送與接收。工具有很多如：postman、jmeter、soupUI等。
也可以用 接口自動化來實現(xiàn)，就是用代碼實現(xiàn)，框架和UI自動化差不多，發(fā)送請求用斷言來判斷。
接口測試的重點
1. 檢查接口返回的數(shù)據(jù)是否與預(yù)期的結(jié)果一致
2. 檢查接口的容錯性，加入傳遞的類型錯誤時是否可以處理
3. 接口測試的邊界值
4. 接口的性能
5. 接口的安全性
http狀態(tài)碼
1. cookies數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務(wù)器上;
2. cookies不是很安全，別人可以分析存放在本地的cookies并進行cookies欺騙考慮到安全應(yīng)當使用 session;
3. session會在一定時間內(nèi)保存在服務(wù)器上，當訪問增多，會比較占用，你服務(wù)器的性能考慮到減輕服務(wù)器性能方面，應(yīng)當使用cookies。
常用的adb命令
1. adb start-server 啟動adb服務(wù)
2. adb kill-server 關(guān)閉adb服務(wù)
3. adb devices 查看設(shè)備號
4. adb push 電腦 手機
5. adb pull 手機 電腦
6. adb logcat | grep 包名(unix)
7. adb logcat | findstr 包名 (win)
8. adb shell 進入shell命令行
9. adb install 安裝app到手機上
10. adb uninstall 卸載app到手機上
11. adb logcat > 文件名 輸出log到文件
12. adb shell top 測試app的資源消耗命令
產(chǎn)品的業(yè)務(wù)流程
解析
問你簡歷上寫的某個項目整體的業(yè)務(wù)流程比如電商項目中的注冊功能，從開始注冊到注冊成功的整個過程
版本符合上線的標準是什么
驗收標準
(1) 軟件需求分析說明書中定義的所有功能已全部實現(xiàn)，性能指標全部達到要求。
(2) 在驗收測試中發(fā)現(xiàn)的錯誤已經(jīng)得到修改，各級缺陷修復(fù)率達到標準
(3) 所有測試項沒有殘余緊急、嚴重級別錯誤。
(4) 需求分析文檔、設(shè)計文檔和編碼實現(xiàn)一致。
(5) 驗收測試工件齊全(測試計劃、測試用例、測試日志、測試通知單、測試分析報告，待驗收的軟件安裝程序。)
缺陷修復(fù)率標準
(1) 緊急、嚴重級別錯誤修復(fù)率應(yīng)達到100%;
(2) 普通級別錯誤修復(fù)率應(yīng)達到95%以上;
(3) 優(yōu)化級別錯誤修復(fù)率應(yīng)達到60%以上; 注：項目緊急時，普通級別錯誤修復(fù)率達60% 以上;優(yōu)化級別錯誤修復(fù)率達20% 即可。
服務(wù)器運行狀態(tài)響應(yīng)指標
(1) cpu% 并發(fā)期間最大使用率應(yīng)不超過70-80%，如有集合點并發(fā)可允許短暫接近或到達100& 但大部分不應(yīng)查過95%; (2) memery 測試期間保證內(nèi)存充足可用內(nèi)存不少于20%;
(3) disk 監(jiān)控硬盤是否有讀寫不超過40%;
(4) cpu load average 不應(yīng)超過cpu 核心數(shù)*2 或者不超過cpu 核心數(shù)。
測試用例評審過程及相關(guān)參與人員
1:評審的過程
A:開始前做好如下準備
(1)確定需要評審的原因
(2)確定進行評審的時機
(3)確定參與評審人員
(4)明確評審的內(nèi)容
(5)確定評審結(jié)束標準
(6)提前至少一天將需要評審的內(nèi)容以郵件的形式發(fā)送給評審會議相關(guān)人員。并注明詳審時間、地點及償參與人員等。
(7)在郵件中提醒評審會議相關(guān)人員至少簡讀一遍評審內(nèi)容，并記錄相關(guān)的疑問，以便在評審會議上提出。
(8)會議主持者(一般為用例編寫人員)應(yīng)在會議前整理相關(guān)疑問，以便在會議上提出。
B：開始評審
(1)召開評審會議。與會者在設(shè)計人員講解之后給出意見和建議，同時進行詳細的評審記錄。
(2)通用郵件與相關(guān)人員溝通
(3)通用IM工具直接與相關(guān)人員交流
(4)根據(jù)評審內(nèi)容進行評審
2：評審內(nèi)容
(1)用例設(shè)計的結(jié)構(gòu)安排是否清晰、合理，是否利于高效對需求進行覆蓋。
(2)優(yōu)先極安排是否合理。
(3)是否覆蓋測試需求上的所有功能點。
(4)用例是否具有很好可執(zhí)行性。例如用例的前提條件、執(zhí)行步驟、輸入數(shù)據(jù)和期待結(jié)果是否清晰、正確;期待結(jié)果是否有明顯的驗證方法。
(5)是否已經(jīng)刪除了冗余的用例。
(6)是否包含充分的負面測試用例。充分的定義，如果在這里使用2&8法則，那就是4倍于正面用例的數(shù)量，畢竟一個健壯的軟件，其中80%的代碼都是在“保護”20%的功能實現(xiàn)。
(7)是否從用戶層面來設(shè)計用戶使用場景和使用流程的測試用例。
(8)是否簡潔，復(fù)用性強。例如，可將重復(fù)度高的步驟或過程抽取出來定義為一些可復(fù)用標準步驟。
3：參與評審人員(這里會分為多個級別進行評審)
(1)部門評審，測試部門全體成員參與的評審。
(2)公司評審，這里包括了項目經(jīng)理、需求分析人員、架構(gòu)設(shè)計人員、開發(fā)人員和測試人員。
(3)客戶評審，包括了客戶方的開發(fā)人員和測試人員。這種情況在外包公司比較常見。
猜你喜歡：
JavaEE
鴻蒙應(yīng)用開發(fā)
集成電路應(yīng)用開發(fā)
人工智能開發(fā)
AI+Linux云計算運維
Python+大數(shù)據(jù)開發(fā)
AI+設(shè)計
軟件測試
新媒體+短視頻
HTML&JS+前端
科列表頁面右側(cè)廣告圖.jpg)
科列表頁面右側(cè)廣告圖230x148.jpg)
據(jù)學(xué)科列表頁右側(cè).png)
科列表頁面右側(cè)廣告圖.jpg)
.jpg)