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