1. 測試流程
1）測試需求分析階段：閱讀需求，理解需求，主要就是對業(yè)務(wù)的學(xué)習(xí)澎办，分析需求點，參與需求評審會議金砍。
2）測試計劃階段：主要任務(wù)就是編寫測試計劃局蚀，參考軟件需求規(guī)格說明書，項目總體計劃恕稠，內(nèi)容包括測試范圍（來自需求文檔）琅绅，進度安排，人力物力的分配鹅巍，整體測試策略的制定千扶。風(fēng)險評估與規(guī)避措施有一個制定骆捧。
3）測試設(shè)計階段：主要是編寫測試用例澎羞，會參考需求文檔（原型圖），概要設(shè)計敛苇，詳細設(shè)計等文檔妆绞，用例編寫完成之后會進行評審。
4）測試執(zhí)行階段：搭建環(huán)境枫攀，執(zhí)行冒煙測試（預(yù)測試）-然后進入正式測試括饶，bug管理直到測試結(jié)束。
5）測試評估階段：出測試報告来涨，確認是否可以上線图焰。
- 測試前準備-》需求分析-》測試設(shè)計-》執(zhí)行測試-》提交bug-》測試總結(jié)
2. 測試計劃的編寫要素
why-為什么要進行這些測試
what-測試哪些方面，不同階段的工作內(nèi)容
when-測試不同階段的起止時間
where-相應(yīng)文檔蹦掐，缺陷的存放位置技羔，測試環(huán)境等
who-項目有關(guān)人員組成驰徊，安排哪些測試人員進行測試
how-如何去做，使用哪些測試工具以及測試方法進行測試
3. 測試原則
1）應(yīng)當(dāng)把“盡早的和不斷的進行軟件測試”作為軟件開發(fā)者的座右銘
2）測試用例應(yīng)由測試輸入數(shù)據(jù)和對應(yīng)的預(yù)期輸出結(jié)果兩部分組成
3）程序員應(yīng)該避免檢查自己的程序
4）在設(shè)計測試用例時堕阔，應(yīng)包括合理的輸入條件和不合理的輸入條件
5）充分注意測試中的群集現(xiàn)象棍厂，經(jīng)驗表明，測試后程序中殘有的錯誤數(shù)目與該程序中已發(fā)現(xiàn)的錯誤數(shù)目成正比
6）嚴格執(zhí)行測試計劃超陆，排除測試的隨意性
7）應(yīng)當(dāng)對每一個測試結(jié)果做全面檢查
8）妥善保存測試計劃牺弹，測試用例，出錯統(tǒng)計和最終分析報告时呀，為維護提供方便
4. 測試方法
黑盒：等價類劃分法张漂、邊界分析法、因果圖法和錯誤推測法谨娜、正交法航攒、場景法
白盒：邏輯覆蓋法、循環(huán)測試路徑選擇趴梢、基本路徑測試
5. 測試分類
1）按階段劃分：單元測試漠畜、集成測試、系統(tǒng)測試坞靶、驗收測試
2）按是否運行劃分：靜態(tài)測試憔狞、動態(tài)測試
3）按是否查看代碼劃分：白盒測試、黑盒測試彰阴、灰盒測試
4）其他：回歸瘾敢、冒煙、隨機測試
5）功能測試：界面尿这、業(yè)務(wù)邏輯功能簇抵、兼容性、易用性射众、安全性碟摆、安裝測試
6）性能測試：性能、負載责球、壓力焦履、容量、并發(fā)雏逾、配置嘉裤、可靠性、失敗測試
6. 測試模型
7. 開發(fā)流程
需求分析-〉概要設(shè)計-〉詳細設(shè)計-〉編碼-〉測試-〉軟件交付-〉驗收-〉維護-〉升級-〉再測試-〉逐步淘汰
8. 黑盒和白盒的區(qū)別
黑盒測試：把測試對象當(dāng)成一個黑盒子栖博，測試人員完全不考慮邏輯結(jié)構(gòu)和內(nèi)部特性屑宠， 只依據(jù)程式的需求說明書來檢查程式的功能是否滿足它的功能說明。
白盒測試：把測試對象當(dāng)成一個透明的盒子仇让，允許測試人員利用程序內(nèi)部邏輯結(jié)構(gòu)及 相關(guān)信息典奉，設(shè)計或選擇測試用例躺翻，對程式所有邏輯路徑進行測試。
9. 測試計劃都有哪些
測試背景卫玖，測試目標公你，測試范圍，測試輸出文檔假瞬，測試策略陕靠，測試規(guī)模，工作量分析脱茉，測試進程剪芥，測試進度及時間安排，測試資源琴许，人力税肪，設(shè)備，風(fēng)險管理
10. 測試用例包含哪些
用例編號榜田、所屬模塊益兄、執(zhí)行條件、測試輸入串慰、預(yù)期結(jié)果偏塞、實際結(jié)果、用例是否通過邦鲫、測試人、版本
11. 測試用例需要詳細到什么程度才是合格的
首先根據(jù)需求文檔神汹、概要設(shè)計庆捺、測試計劃、測試方案細分出各功能模塊的測試項屁魏，再根據(jù)各測試項滔以，按照概要設(shè)計，詳細設(shè)計以及測試方案中測試的覆蓋率細分出測試子項氓拼，最后根據(jù)測試用例的設(shè)計方案來寫測試方法
12. 缺陷報告包含哪些
缺陷的標題你画、簡要描述、缺陷的類型桃漾、缺陷的詳細步驟描述坏匪、缺陷的實際結(jié)果、期望結(jié)果撬统、有的缺陷需要上傳截圖适滓、日志結(jié)算、缺陷的等級恋追、缺陷指派給開發(fā)
13. 測試評審：（評審分類 評審內(nèi)容 評審結(jié)束）
1）評審分類：部門凭迹、公司罚屋、客戶評審
2）評審內(nèi)容：
[1]用例設(shè)計的結(jié)構(gòu)安排是否清晰合理，是否利用高效對需求進行覆蓋
[2]優(yōu)先級安排是否合理
[3]是否覆蓋測試上的所有功能點
[4]用例是否具有很好執(zhí)行
[5]是否已經(jīng)刪除了冗余的用例
[6]是否包含充分的負面測試用例
[7]是否從用戶層面來設(shè)計用戶使用場景和使用流程的測試用例
[8]是否簡潔 嗅绸，復(fù)用性強
3）評審結(jié)束：
在評審活動中會收集到用例的反饋信息脾猛，在此基礎(chǔ)上進行用例更新，直接通過評審
14. 水杯 電梯 朋友圈點贊 視頻播放 支付的測試用例的設(shè)計點有哪些
15. 測試發(fā)現(xiàn)bug開發(fā)不認為是bug的時候
說法一：
1鱼鸠、首先明確開發(fā)說不是bug的理由尖滚。
2、如果是需求變更瞧柔， 那就找產(chǎn)品經(jīng)理確認是否是需求變更漆弄。
3、如果開發(fā)說測試環(huán)境問題造锅， 讓他說明清楚測試環(huán)境問題是什么撼唾，按照他說的驗證一遍， 如果確實如他所說哥蔚， 關(guān)閉bug倒谷，但是不是他說的那樣，繼續(xù)激活bug給開發(fā)解決糙箍，確保產(chǎn)品質(zhì)量渤愁。
4、如果開發(fā)說用戶不存在這種使用場景深夯， 但是我們不認可他說的抖格，把這個bug 知會到測試經(jīng)理，讓測試經(jīng)理去判定咕晋。
說法二：
1.告知開發(fā)bug的判斷依據(jù)雹拄，同時明確開發(fā)說不是bug的理由。
2.對開發(fā)的理由進行校驗掌呜，校驗依據(jù)1.參照需求文檔滓玖，2.跟產(chǎn)品經(jīng)理進行溝通確認。
校驗結(jié)果不是bug质蕉，關(guān)閉bug势篡，如果是bug提交給開發(fā)進行處理，確保產(chǎn)品質(zhì)量
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ā)去修復(fù)BUG-->回歸驗證BUG-->是否通過驗證-->關(guān)閉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ù)或列入軟件發(fā)布清單拦英。
3.不緊急（Not Urgent）缺陷可以在方便時被糾正蜒什。
