软件实现了产品规格说明所要求等功能但因受性能限制而未考虑可移植性问题不属于软件缺陷。
（常见的有）功能、 界面 、 文档、 软件包、 性能、接口 等等
（不同公司采用的专业名词可能不同 基本原理相同
根据《软件测试》第二版 分为）
致命
严重
一般
较小
不同企业采用的名词可能不同
立即解决
高优先级
正常排队
低优先级
缺陷状态是通过跟踪缺陷修复过程的进展情况而定义的，开发人员修复Bug后，会将状态改为已修复，也就是待验证状态。
依据：需求分析、设计文档、产品原型、测试用例都为客观的依据 同行业的类似成熟软件
缺陷报告的基本信息包括：缺陷标题、测试环境、复现环境（操作步骤）、实际结果、预期结果、注释。
缺陷处理优先级，属于软件缺陷报告的属性。
准确
清晰
简洁
完整
一致
可以在现
不做评价
答：没有任何直接关系
不要认为严重的缺陷 修复优先级就高
如果碰到优先级和严重程度都高的缺陷 也只是偶然
常用缺陷管理工具：
如开源（Bugzilla、jira、matins、Excel等）商业（QC/ALM、禅道等）。
软件中的缺陷不一定都会导致程序崩溃。
严重缺陷，指功能模块或特性没有实现，主要功能部分丧失，次要功能全部丧失，或致命的错误声明。
文字、界面错误属于严重程度较低的缺陷。
实施缺陷跟踪的原因是软件质量无法控制、问题无法量化、重复问题接连产生、解决问题的知识无法保留。
良好的复现步骤应该包含本质的信息，按照下列方式书写：
提供测试的前提条件和测试环境；
如果有多种方法触发该缺陷，请在步骤中包含；
简单地一步一步地引导复现该缺陷，每个步骤尽量只记录一个操作；
尽量使用短语和短句，避免复杂句型和句式；
复现的操作步骤要完整、准确、简短；
只记录各个操作步骤是什么，不要包含每个操作步骤执行后的结果；
将常见的步骤合并为较少的步骤。
