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