<由於本文章是依據微軟的產品總結而來,僅供學習交流之用,任何商用都是被禁止的,後果自負!>
在測試中,如果我們發現了產品的Defect,我們就要報Bug,那麼Bug都有哪些基本屬性呢?在微軟是這樣定義的。
對於一個Bug,以下的屬性是必須的:
- General
- ID - 對於每個Bug來說都是唯一的,一旦一個新Bug被File成功,那麼系統將自動產生一個獨一無二的ID。
- Title - 就是對Bug的簡單描述,如果Developer通過Title就能明白Bug到底是什麼意思,那麼這個Title就是好Title。
- Area Path - 在何處發現了該Bug,或者說該Bug屬於哪一個Component,XML, QP, QE, AM, TS等等。
- Iteration Path - 在何時發現了該Bug,CTP1, CTP2, RC, RTM等等。
- History - 一切對Bug的更改都反映在History中,包括何時何人做了何事。
- Description - 對Bug的詳細描述,也是對Title描述的一種補充。
- Repro - 既然報的是Bug,就必須提供重現步驟給Dev,讓他們能按照你所提供的Repro Step去重現Bug。
- Attachments - 很多測試都有Log,可以把錯誤時的Log資訊Attach上去,讓Dev能更方便更深入地研究問題所在。
- Status
- Assigned To - 該Bug是給誰的,或者說該Bug應該有哪個Dev來Fix。
- State - Bug當前的狀態,包括Active和Resolved。
- Issue Type - 主要有Code, Test兩種,也可以包括其他,比如Design, Specification, DCR等等。
- Impact - 該Bug影響了哪些方面,包括Functionality, Test, Localizaion, Logo, UI等等。
- Severity(數字越小,嚴重性越大)
- (1)- System crash, data loss, incorrect results
- (2)- Major functionality or other severe problems; product crashes in obscure cases
- (3)- Fit and finish issues
- (4)- Typos, incorrect wording in obscure areas of the product
- Priority(數字越小,優先順序越高)
- (0)- Blocking: BVT, Autobuilder, build break, unusable
- (1)- Key scenario: embarrassing, PSS involved
- (2)- Important scenario: before any release
- (3)- Some customers: no PSS or newsgroups; before RTM
- (4)- May fix if not destabilizing
- Created
- Created Date - 系統自動提供,File Bug時的時間。
- Created By - 系統自動提供,File Bug的那個人的名字。
- Source - Who discovered it? Test Team, Dev Team, 還是Location Team等等。
- How Found - How the problem was discovered? Automation testing, Ad Hoc testing, 還是Bug Bash等等。
- Resolved
- Resolved Date - 系統自動提供,Resolve該Bug時的時間。
- Resolved By - 系統自動提供,Resolve該Bug的人。
- Resolution - 解決方案是什嗎?By Design, Duplicate, External, Fixed, Not Repro還是Won't fix。
- Test ID - 哪一個Test Case發現的該Bug。
- Misc
- Branch - Branch the problem was discovered in
- Build - Build the problem was discovered in
- Test Custom - Freeform tagging field for testing