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)缺陷可以在方便時被糾正蜒什。