測試用例基礎(chǔ)
課程目標：
掌握測試用例的基本項
編寫簡單的測試用例
了解測試用例的寫作注意事項
一、測試用例的作用
1、記錄測試思路
2、標記測試場景與對應(yīng)的預(yù)期結(jié)果
3、判斷測試的覆蓋度和粒度
4、分配測試任務(wù)
5、指導(dǎo)測試執(zhí)行：
指導(dǎo)回歸測試和冒煙測試
不熟悉需求的測試人員
6、測試工作的階段產(chǎn)出物，是質(zhì)量管理規(guī)范的要求
二、基本要求
1、核心內(nèi)容清晰、
2、覆蓋度
三、測試用例八大要素
1、用例編號
唯一性、易識別性
系統(tǒng)測試：ST
集成測試：IT
單元測試：UT
例子：產(chǎn)品編號-ST-測試項名-測試子項名-用例序號
2、測試項目（用例名\測試場景）
3、測試標題
描述用例的關(guān)注點和出發(fā)點
4、重要級別
高：基本功能、核心業(yè)務(wù)、使用頻率高
中：基于高和低之間
低：使用頻率低
例子：
微信-高：注冊、登錄、通訊錄、聊天、朋友圈
微信-中：支付、買電影票、掃碼小程序
微信-低：微信幫助、看一看
5、預(yù)置條件
6、測試輸入
7、操作步驟
8、預(yù)期輸出
四、測試用例評審
1、評審人員
參與人員、測試人員、項目人員、領(lǐng)導(dǎo)
2、評審方式
郵件評審、會議評審
郵件評審：反饋時間外，默認處理結(jié)果
會議評審：
1）評審按用例的優(yōu)先級、功能復(fù)雜程度進行
2）思路清晰，簡潔闡述每個功能點
3）同一個問題的討論不超過5分鐘
3、評審準備
材料提前一天發(fā)，做好準備
4、會議評審測試用例講解
1、覆蓋率
所涉及的業(yè)務(wù)、功能模塊
具體覆蓋的業(yè)務(wù)環(huán)節(jié)、模塊子功能
2、粒度
針對具體業(yè)務(wù)環(huán)節(jié)、子功能涉及用例的數(shù)量
正常場景和異常場景的比例
5、風(fēng)險評估
針對測試用例的講解，項目組成員提出疑問和風(fēng)險
1、列出預(yù)期結(jié)果不明確、業(yè)務(wù)流程不明確等情況--項目組成員互相之間可以提出疑問和解答疑問
2、由用例數(shù)量、執(zhí)行難度反推項目的時間安排、資源投入存在的風(fēng)險
6、評審報告
7、評審反饋
缺陷管理：
缺陷的基本概念：缺陷、故障、失效
任何軟件都存在缺陷，就算是windows操作系統(tǒng)，這樣已經(jīng)非常成熟的軟件，也存在著缺陷。但是，這些缺陷隱藏的很深，一般不會被觸發(fā)，或者可能永遠不會被觸發(fā)。而一旦觸發(fā)了缺陷，則會引起故障，故障是缺陷的外在表現(xiàn)。故障發(fā)生了，卻不一定會引起失效，因為在開發(fā)的時候，開發(fā)人員會考慮到這種情況。例如數(shù)據(jù)丟失，這是一種故障，但不一定會引起失效，因為開發(fā)人員準備了備份的數(shù)據(jù)庫，系統(tǒng)照樣可以正常使用。
一般情況下，缺陷引起故障，故障引起失效。但現(xiàn)實情況卻是，缺陷不一定會被觸發(fā)，就算觸發(fā)了缺陷引起了故障，也不一定會引起失效。
缺陷類型：
遺漏--需求規(guī)格說明書里的需求沒有實現(xiàn)
錯誤--實現(xiàn)了，但是錯誤了
額外實現(xiàn)--沒要求做
改進--界面可以優(yōu)化
缺陷來源：
1、軟件未實現(xiàn)需求規(guī)格說明書要求的功能
2、軟件為實現(xiàn)需求規(guī)格說明書雖為提及但應(yīng)該實現(xiàn)的目標
3、軟件出現(xiàn)了需求規(guī)格說明書要求的功能，但錯誤了
4、軟件出現(xiàn)了需求規(guī)格說明書為要求的功能以外的功能
缺陷報告單：
缺陷跟蹤單
缺陷報告的作用：
1、缺陷能夠得到認可
2、缺陷報告可以作為溝通交流的一種渠道，開發(fā)人員與測試人員對缺陷認識一致
3、可以進行跟蹤和處理
4、可以做缺陷分析
缺陷報告屬性：
1、缺陷編號 自動生成，按照提交時間排列序列號
*2、摘要信息\標題 簡潔說明缺陷的實際問題
3、缺陷提交人
4、缺陷提交時間
*5、缺陷嚴重程度 對使用造成多大影響
致命：無法使用
嚴重：最核心功能可以使用，主要功能用不了
一般嚴重：輔助功能不可以使用
一般：頁面的文字錯誤，排列不整齊
6、缺陷優(yōu)先級： 開發(fā)人員修改缺陷的處理時間先后
非常高：當(dāng)天解決
高：三天解決
中：一周之內(nèi)解決
低：兩周之內(nèi)解決
*7、重現(xiàn) bug至少出現(xiàn)3次
8、測試階段：單元、集成、系統(tǒng)、驗收
9、測試模塊
10、對應(yīng)的測試需求號
11、對應(yīng)的測試用例號
12、測試環(huán)境：硬件儀器型號
13、測試版本
14、測試類型：功能、性能、安全
15、缺陷類型
16、缺陷的重現(xiàn)步驟：發(fā)現(xiàn)這個缺陷的步驟、明確細節(jié)，預(yù)期結(jié)果和實際結(jié)果
17、附件
18、狀態(tài)：缺陷生命周期狀態(tài)
新建、打開、重復(fù)、拒絕、延遲、分配、再次打開、已修復(fù)、關(guān)閉
缺陷報告原則（5c原則）
1、correct 正確的 不要誤報缺陷
2、 concise 簡潔的 簡潔給出出現(xiàn)bug的步驟
3、consistent 一致的 缺陷報告的風(fēng)格一致，不要個性化
4、clear 清晰的 數(shù)據(jù)精準描述
5、complete 完整的 缺陷報告的內(nèi)容都要填寫
測試在提交缺陷時要中立客觀，不要挖苦諷刺幽默，對事不對人
缺陷管理工具：
QC
TD
ALM
Jira
Bugfree
Bugzilla
Mantis
禪道（國產(chǎn)、有免費、有付費，一分錢一分貨）
缺陷填報常見問題：
1、標題描述不夠清晰明白，太長
2、步驟描述太冗長，沒有相關(guān)配圖配合描述；文字為主
3、嚴重程度和優(yōu)先級設(shè)置不合理
缺陷報告寫作要點：
能再現(xiàn)性：
可初步定位：
舉一反三：
|
客服電話
官方微信
