1. 測試流程
1）測試需求分析階段：閱讀需求，理解需求，主要就是對業(yè)務的學習，分析需求點，參與需求評審會議。
2）測試計劃階段：主要任務就是編寫測試計劃，參考軟件需求規(guī)格說明書，項目總體計劃，內容包括測試范圍（來自需求文檔），進度安排，人力物力的分配，整體測試策略的制定。風險評估與規(guī)避措施有一個制定。
3）測試設計階段：主要是編寫測試用例，會參考需求文檔（原型圖），概要設計，詳細設計等文檔，用例編寫完成之后會進行評審。
4）測試執(zhí)行階段：搭建環(huán)境，執(zhí)行冒煙測試（預測試）-然后進入正式測試，bug管理直到測試結束。
5）測試評估階段：出測試報告，確認是否可以上線。
- 測試前準備-》需求分析-》測試設計-》執(zhí)行測試-》提交bug-》測試總結
2. 測試計劃的編寫要素
why-為什么要進行這些測試
what-測試哪些方面，不同階段的工作內容
when-測試不同階段的起止時間
where-相應文檔，缺陷的存放位置，測試環(huán)境等
who-項目有關人員組成，安排哪些測試人員進行測試
how-如何去做，使用哪些測試工具以及測試方法進行測試
3. 測試原則
1）應當把“盡早的和不斷的進行軟件測試”作為軟件開發(fā)者的座右銘
2）測試用例應由測試輸入數(shù)據和對應的預期輸出結果兩部分組成
3）程序員應該避免檢查自己的程序
4）在設計測試用例時，應包括合理的輸入條件和不合理的輸入條件
5）充分注意測試中的群集現(xiàn)象，經驗表明，測試后程序中殘有的錯誤數(shù)目與該程序中已發(fā)現(xiàn)的錯誤數(shù)目成正比
6）嚴格執(zhí)行測試計劃，排除測試的隨意性
7）應當對每一個測試結果做全面檢查
8）妥善保存測試計劃，測試用例，出錯統(tǒng)計和最終分析報告，為維護提供方便
4. 測試方法
黑盒：等價類劃分法、邊界分析法、因果圖法和錯誤推測法、正交法、場景法
白盒：邏輯覆蓋法、循環(huán)測試路徑選擇、基本路徑測試
5. 測試分類
1）按階段劃分：單元測試、集成測試、系統(tǒng)測試、驗收測試
2）按是否運行劃分：靜態(tài)測試、動態(tài)測試
3）按是否查看代碼劃分：白盒測試、黑盒測試、灰盒測試
4）其他：回歸、冒煙、隨機測試
5）功能測試：界面、業(yè)務邏輯功能、兼容性、易用性、安全性、安裝測試
6）性能測試：性能、負載、壓力、容量、并發(fā)、配置、可靠性、失敗測試
6. 測試模型
7. 開發(fā)流程
需求分析-〉概要設計-〉詳細設計-〉編碼-〉測試-〉軟件交付-〉驗收-〉維護-〉升級-〉再測試-〉逐步淘汰
8. 黑盒和白盒的區(qū)別
黑盒測試：把測試對象當成一個黑盒子，測試人員完全不考慮邏輯結構和內部特性， 只依據程式的需求說明書來檢查程式的功能是否滿足它的功能說明。
白盒測試：把測試對象當成一個透明的盒子，允許測試人員利用程序內部邏輯結構及 相關信息，設計或選擇測試用例，對程式所有邏輯路徑進行測試。
9. 測試計劃都有哪些
測試背景，測試目標，測試范圍，測試輸出文檔，測試策略，測試規(guī)模，工作量分析，測試進程，測試進度及時間安排，測試資源，人力，設備，風險管理
10. 測試用例包含哪些
用例編號、所屬模塊、執(zhí)行條件、測試輸入、預期結果、實際結果、用例是否通過、測試人、版本
11. 測試用例需要詳細到什么程度才是合格的
首先根據需求文檔、概要設計、測試計劃、測試方案細分出各功能模塊的測試項，再根據各測試項，按照概要設計，詳細設計以及測試方案中測試的覆蓋率細分出測試子項，最后根據測試用例的設計方案來寫測試方法
12. 缺陷報告包含哪些
缺陷的標題、簡要描述、缺陷的類型、缺陷的詳細步驟描述、缺陷的實際結果、期望結果、有的缺陷需要上傳截圖、日志結算、缺陷的等級、缺陷指派給開發(fā)
13. 測試評審：（評審分類 評審內容 評審結束）
1）評審分類：部門、公司、客戶評審
2）評審內容：
[1]用例設計的結構安排是否清晰合理，是否利用高效對需求進行覆蓋
[2]優(yōu)先級安排是否合理
[3]是否覆蓋測試上的所有功能點
[4]用例是否具有很好執(zhí)行
[5]是否已經刪除了冗余的用例
[6]是否包含充分的負面測試用例
[7]是否從用戶層面來設計用戶使用場景和使用流程的測試用例
[8]是否簡潔 ，復用性強
3）評審結束：
在評審活動中會收集到用例的反饋信息，在此基礎上進行用例更新，直接通過評審
14. 水杯 電梯 朋友圈點贊 視頻播放 支付的測試用例的設計點有哪些
15. 測試發(fā)現(xiàn)bug開發(fā)不認為是bug的時候
說法一：
1、首先明確開發(fā)說不是bug的理由。
2、如果是需求變更， 那就找產品經理確認是否是需求變更。
3、如果開發(fā)說測試環(huán)境問題， 讓他說明清楚測試環(huán)境問題是什么，按照他說的驗證一遍， 如果確實如他所說， 關閉bug，但是不是他說的那樣，繼續(xù)激活bug給開發(fā)解決，確保產品質量。
4、如果開發(fā)說用戶不存在這種使用場景， 但是我們不認可他說的，把這個bug 知會到測試經理，讓測試經理去判定。
說法二：
1.告知開發(fā)bug的判斷依據，同時明確開發(fā)說不是bug的理由。
2.對開發(fā)的理由進行校驗，校驗依據1.參照需求文檔，2.跟產品經理進行溝通確認。
校驗結果不是bug，關閉bug，如果是bug提交給開發(fā)進行處理，確保產品質量
16. Linux命令 15個
17. Adb命令 15個 查看日志 （日志級別）
18. Monkey命令 和日志區(qū)別
19. 查看日志的前10行后5行的命令
# head -n 10/etc/profile
# tail -n 50/etc/profile
20. Bug生命周期
發(fā)現(xiàn)BUG-->提交BUG-->指派BUG-->研發(fā)確認BUG-->研發(fā)去修復BUG-->回歸驗證BUG-->是否通過驗證-->關閉BUG
如果待驗的BUG在驗證時沒有解決好，我們需要重新打開--指派—已解決—待驗，循環(huán)這個過程
21. Bug的狀態(tài)和優(yōu)先級
第一級（blocker）: 引起喜歡作系統(tǒng)“掛起”或“崩潰”的錯誤；
第二級（critical）: 引起軟件本身“掛起”或“崩潰”的錯誤；
第三級（major）: 不能完成軟件說明書定義的功能的錯誤；
第四級（normal）: 程序所完成的功能與軟件說明書定義不符的錯誤；
第五級（minor） : 顯示方面的錯誤；
第六級（trivial） : 其它“輕微”的錯誤（如文本差錯）；
第七級（enhancement）：增強或者改進。
優(yōu)先級：
1.立即解決（Resolve Immediately）缺陷必須被立即解決。
2.正常排隊（Normal Queue）缺陷需要正常排隊等待修復或列入軟件發(fā)布清單。
3.不緊急（Not Urgent）缺陷可以在方便時被糾正。
