软件缺陷可以分类方法(软件缺陷的分类标准)
1.软件缺陷的分类标准
1.缺陷标识（Identifier）： 缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识。
2.缺陷类型 （Type）： 缺陷类型是根据缺陷的自然属性划分的缺陷种类。
3.缺陷严重程度 （Severity） ：缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
4.缺陷优先级（Priority）： 缺陷的优先级指缺陷必须被修复的紧急程度。
5.缺陷状态（Status） ：缺陷状态指缺陷通过一个跟踪修复过程的进展情况。
6.缺陷起源（Origin） ：缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。
7.缺陷来源（Source）： 缺陷来源指引起缺陷的起因。
8.缺陷根源（Root Cause）： 缺陷根源指发生错误的根本因素。 F- Function ：影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如逻辑，指针，循环，递归，功能等缺陷。
A- Assignment： 需要修改少量代码，如初始化或控制块。如声明、重复命名，范围、限定等缺陷。
I- Interface： 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。
C- Checking： 提示的错误信息，不适当的数据验证等缺陷。
B Build/package/merge ：由于配置库、变更管理或版本控制引起的错误。
D- Documentation： 影响发布和维护，包括注释。
G- Algorithm ：算法错误。
U-User Interface：人机交互特性：屏幕格式，确认用户输入，功能有效性，页面排版等方面的缺陷。
P-Performance：不满足系统可测量的属性值，如：执行时间，事务处理速率等。
N-Norms：不符合各种标准的要求，如编码标准、设计符号等。 软件测试错误严重程度
1.Critical：不能执行正常工作功能或重要功能。或者危及人身安全。
2.Major：严重地影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法）
3.Minor：严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）
4.Cosmetic：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。
5.Other：其它错误。
同行评审错误严重程度
1.Major：主要的，较大的缺陷
2.Minor：次要的，小的缺陷 1.Resolve Immediately：缺陷必须被立即解决。
2.Normal Queue：缺陷需要正常排队等待修复或列入软件发布清单。
3.Not Urgent：缺陷可以在方便时被纠正。 1.Submitted： 已提交的缺陷
2.Open ：确认“提交的缺陷”，等待处理
3.Rejected： 拒绝“提交的缺陷”，不需要修复或不是缺陷
4.Resolved ：缺陷被修复
5.Closed ：确认被修复的缺陷，将其关闭 1.Requirement：在需求阶段发现的缺陷
2.Architecture：在构架阶段发现的缺陷
3.Design：在设计阶段发现的缺陷
4.Code：在编码阶段发现的缺陷
5.Test：在测试阶段发现的缺陷 1.Requirement： 由于需求的问题引起的缺陷
2.Architecture： 由于构架的问题引起的缺陷
3.Design： 由于设计的问题引起的缺陷
4.Code： 由于编码的问题引起的缺陷
5.Test： 由于测试的问题引起的缺陷
6.Integration： 由于集成的问题引起的缺陷
2.软件缺陷包括哪些内容
一般我们都认为测出一个问题就是一个bug，其实这是不对的，假设测试10个问题就10个bug，而修改一出就全解决了，程序员肯定认为冤枉自己。
所有软件是文档，代码等组成的，最初的错误是来自于这些软件错误（software error），如代码中加法写成减法。软件错误导致软件缺陷（software defect），如设计缺陷，代码缺陷等，可用静态测试，如走查，静态检查，测试床（军事软件用的技术）等，软件的缺陷导致一个或多个软件故障 （software fault），故障有内部故障，外部故障，也就是我们所说的bug，软件故障导致了软件在功能操作等方面的失效（software failure）。
我们平时测的bug实际上是软件故障于失效的体现。一旦软件错误得到修改，相应的故障与失效也就解除了。这样分有助于我们定位问题，找到问题。
3.缺陷分析方法具体有哪几种
1、ODC缺陷分析：由IBM 的waston中心推出。
Phontol.com将一个缺陷在生命周期的各环节的属性组织起来，从单维度、多维度来对缺陷进行分析，从不同角度得到各类缺陷的缺陷密度和缺陷比率，从而积累得到各类缺陷的基线值，用于评估测试活动、指导测试改进和整个研发流程的改进；同时根据各阶段缺陷分布得到缺陷去除过程特征模型，用于对测试活动进行评估和预测。Phontol.com上面回答中涉及到的缺陷分布、缺陷趋势等都属于这个方法中的一个角度而已。
2、Gompertz分析：根据测试的累积投入时间和累积缺陷增长情况，拟合得到符合自己过程能力的缺陷增长Gompertz曲线，用来评估软件测试的充分性、预测软件极限缺陷数和退出测试所需时间、作为测试退出的判断依据、指导测试计划和策略的调整； 3、Rayleigh分析：通过生命周期各阶段缺陷发现情况得到缺陷Rayleigh曲线，用于评估软件质量、预测软件现场质量； 4、四象限分析：根据软件内部各模块、子系统、特性测试所累积时间和缺陷去除情况，和累积时间和缺陷去除情况的基线进行比较，得到各个模块、子系统、特性测试分别所位于的区间，从而判断哪些部分测试可以退出、哪些测试还需加强，用于指导测试计划和策略的调整； 5、根本原因分析：利用鱼骨图、柏拉图等分析缺陷产生的根本原因，根据这些根本原因采取措施，改进开发和测试过程； 6、缺陷注入分析：对被测软件注入一些缺陷，通过已有用例进行测试，根据这些刻意注入缺陷的发现情况，判断测试的有效性、充分性，预测软件残留缺陷数。 7、DRE/DRM分析：通过已有项目历史数据，得到软件生命周期各阶段缺陷注入和排除的模型，用于设定各阶段质量目标，评估测试活动。
4.软件缺陷的五种特征
简单说下软件缺陷的最明显的特征吧知
集结（二八定理）
缺陷往往喜欢扎堆，一个模块已经发现的缺陷比别的模块多，
通常不是代表这个模块已经把缺陷暴露完了，而是意味着这
个模块还存在有同样多的缺陷尚未被道发现。这就是著名的二
八定理：80%的缺陷出现在 20%的模块。
缺陷抗药性
测试进行得越多，新缺陷就越难被发现
1. 因为之前一直使用同样的测试思内路，同样的一套测试用
例，没有新的突破。
2. 某些缺陷天然地只有在很特殊或者很极端的情况下才会
被触发
并非所有缺陷都要修改
p有一些原因，使得有容些缺陷我们不修复
1. 修复的风险太大
2. 没有足够的时间
3. 下一版本修复
p 所有未修复的bug都处于“挂起”状态
5.软件缺陷包括哪些内容
一般我们都认为测出一个问题就是一个bug，其实这是不对的，假设测试10个问题就10个bug，而修改一出就全解决了，程序员肯定认为冤枉自己。
所有软件是文档，代码等组成的，最初的错误是来自于这些软件错误（software error），如代码中加法写成减法。软件错误导致软件缺陷（software defect），如设计缺陷，代码缺陷等，可用静态测试，如走查，静态检查，测试床（军事软件用的技术）等，软件的缺陷导致一个或多个软件故障 （software fault），故障有内部故障，外部故障，也就是我们所说的bug，软件故障导致了软件在功能操作等方面的失效（software failure）。
我们平时测的bug实际上是软件故障于失效的体现。一旦软件错误得到修改，相应的故障与失效也就解除了。
这样分有助于我们定位问题，找到问题。
