<由于本文章是依据微软的产品总结而来,仅供学习交流之用,任何商用都是被禁止的,后果自负!>
在测试中,如果我们发现了产品的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