Bug的基本属性

<由于本文章是依据微软的产品总结而来，仅供学习交流之用，任何商用都是被禁止的，后果自负！>

在测试中，如果我们发现了产品的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 inBuild - Build the problem was discovered inTest Custom - Freeform tagging field for testing

世界杯落下帷幕，“坚持是金”的精神还在继续
魔塔哪个版本最好玩　魔塔那个版本好玩