項目的測試流程
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) 提交人 負責人 優(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. 元素無法確定唯一性
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. 1xx：請求正常偎行，但是無響應(yīng)，只有在實驗狀態(tài)下使用
2. 2xx：2開頭的表示發(fā)送成功
3. 3xx：3開頭的代表重定向贰拿，常見302
4. 4xx：400代表客戶端發(fā)送的語法有錯誤蛤袒，401代表訪問的頁面沒有授權(quán)，403 無權(quán)限訪問該網(wǎng)頁膨更，404代表沒有這個頁面妙真，415 格式錯誤
5. 5xx：5開頭的代表服務(wù)器異常，500代表服務(wù)器內(nèi)部異常荚守，504代表服務(wù)器超時
cookies和session的區(qū)別
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ā)人員和測試人員惊暴。這種情況在外包公司比較常見
