做测试的小伙伴，缺陷相关的知识是必备的。如下内容通过搜集和筛选（感谢原作者），你必须要掌握，方可迈入测试行列。

软件缺陷定义（BUG）
软件没有实现产品的说明书所描述的功能。
软件实现了产品说明书描述不应有的功能。
软件执行了产品说明书没讲的操作。
软件没有实现产品说明书没描述但应该实现的功能（用户体验相关）。
从软件测试员的角度来看，软件难以理解、不易使用、运行缓慢，或者最终用户认为不对。

常用的缺陷追踪系统
JIRA
Readmine
Bugzilla
禅道 (bugfree 升级版）
mantis

缺陷处理流程（简易版）

提交缺陷一般的必填项
标题：
应保持简短、准确、提供缺陷的本质信息。
尽量以缺陷发生的原因与结果的方式相结合的方式书写；
尽量避免使用模糊不清的词语，例如：“功能中断”、“功能不正确”、“行为不起作用” 等，应该使用具体文字说明缺陷的症状；
为了便于他人理解，尽量避免使用俚语或过分具体的测试细节；

复现步骤：
应该包含如何使用别人很容易理解缺陷的复现步骤。
为了达到这个要求，书写的测试步骤应当是完整的、简洁的、准确的、可复现的；
尽量避免包含过多冗余步骤，且句子结构混淆、可读性差、难以理解；包含的操作步骤过少，缺少必要的复现步骤；

期望结果：
描述应与实际结果的描述方式相同，通常列出产品达到什么样的功能或效果。
附件：对缺陷的补充说明，例如缺陷的截图、测试使用的数据等。

缺陷严重程度

缺陷优先级

缺陷状态

很多测试的小伙伴刚开始会把严重程度和优先级搞混。一般来说，如下的搭配不会有什么大问题：致命缺陷对应紧急，严重缺陷对应优先级高，一般缺陷对应一般优先级，轻微和建议对应低优先级。但是我们也需要知道，这些并不是固定搭配，主要还是看这个缺陷对当前上线版本的影响范围。举个栗子：某个子功能点击后会导致崩溃，这算是致命问题，但是通过线上监控显示，该功能对于用户来说使用率极低，或者使用的交互路径很深，换句话说缺陷触发的情况很低，所以某种程度上来说它并不算是一个紧急优先级，不需要立刻发版解决，可以等到下个迭代版本再修复。我们可以把缺陷定为高优先级。

下面以常用的 jira 系统为例，看一条缺陷包括那些字段信息：

下一期预告（每周一更）：
移动端基础知识（Android）