软件缺陷级别定义
1.缺陷定义
>软件没有达到产品说明书表明的功能
>软件出现了产品说明书中不一致的表现
软件功能超出产品说明书的范围
软件没有达到用户期望的目标
虽然产品说明书中没有要求
测试员或用户认为软件的易用性差
2.不是所有的缺陷都会修改
市场的压力使得产品最终发行有时间限制
测试员错误理解或者不正确操作引出的缺陷
错误的修改影响的模块较多，带来的风险较大
缺陷报告中提出的问题很难重现
修改性价比太低
3. 优先级
o 最高级--导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等.
o 紧急---事件非常重要,并且需要马上给予关注.
o 高级---事件是重要的,并且应该在紧急的事件处理之后尽快得到解决.
o 中级---事件是重要的,但是由于解决问题需要花费一定的时间,所以可以用较长的时间解决.
o 低级---事件不重要,可以在时间和资源允许的情况下再解决.
o 建议性缺陷.
4. 分类标准:
A类——致命错误，
不能执行正常工作功能或重要功能。使系统崩溃或资源严重不足。包括：o 由于程序所引起的死机,非法退出
o 死循环
o 导致数据库发生死锁
o 数据通讯错误
o 严重的数值计算错误
o与数据库连接错误
o 数据通讯错误
B类——严重错误，严重地影响系统要求或基本功能的实现，且没有办法更正（重新安装或重新启动该软件不属于更正办法）。包括：
o 功能不符
o 数据流错误
o 程序接口错误
o 轻微的数值计算错误
C类——一般性错误，严重地影响系统要求或基本功能的实现，但存在合理的
更正办法（重新安装或重新启动该软件不属于更正办法）。包括：
o 界面错误(详细文档)
o 打印内容、格式错误
o 简单的输入限制未放在前台进行控制
o 删除操作未给出提示
D类——较小错误，使操作者不方便或遇到麻烦，但它不影响执行工作或功能
实现。包括：
o 辅助说明描述不清楚
o 显示格式不规范
o 长时间操作未给用户进度提示
o 提示窗口文字未采用行业术语
o 可输入区域和只读区域没有明显的区分标志
o 系统处理未优化
E类——测试建议（非缺陷）
缺陷严重级别定义: o 最高级--导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等. o 紧急---事件非常重要,并且需要马上给予关注. o 高级---事件是重要的,并且应该在紧急的事件处理之后尽快得到解决. o 中级---事件是重要的,但是由于解决问题需要花费一定的时间,所以可以用较长的时间解决. o 低级---事件不重要,可以在时间和资源允许的情况下再解决. o 建议性缺陷. 更为详细的划分如下: A类——严重错误，包括： o 由于程序所引起的死机,非法退出 o 死循环 o 导致数据库发生死锁 o 数据通讯错误 o 严重的数值计算错误 B类——较严重错误，包括： o 功能不符 o 数据流错误 o 程序接口错误 o 轻微的数值计算错误 C类——一般性错误，包括： o 界面错误(详细文档) o 打印内容、格式错误 o 简单的输入限制未放在前台进行控制 o 删除操作未给出提示 D类——较小错误，包括： o 辅助说明描述不清楚 o 显示格式不规范 o 长时间操作未给用户进度提示 o 提示窗口文字未采用行业术语 o 可输入区域和只读区域没有明显的区分标志 o 系统处理未优化 E类——测试建议（非缺陷）
软件公司对软件缺陷级别的定义不尽相同，一般可以分为4种： 1. 致命（fatal）：致命的错误，造成系统或应用程序崩溃（crash）、死机、系统悬挂、或造成数据丢 失、主要功能组完全丧失 2. 严重（critical）：严重错误，指功能或者特性（feature）没有实现，主要功能丧失，导致严重的问 题，或致命的错误声明 3. 一般的（major）：不太严重的错误，这样的缺陷虽然不影响系统的基本使用，但没有很好的实现 功能，没有达到预期的效果。如次要功能丧失，提示信息不太正确，或用户界面太差，操作时间长等 4. 微小的（minor）：一些小问题，对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、 文字排列不整齐等 Bug严重程度定义： 致命(Critical)BUG ： 测试执行直接导致系统死机、蓝屏、挂起或是程序非法退出；系统的主要功能或需求没有实现。 严重(Serious) BUG： 系统的次要功能点或需求点没有实现；数据丢失或损坏。执行软件主要功能的测试用例导致系统出错，程序无法正常继续执行；程序执行过于缓慢或是占用过大的系统资源。 一般(Minor) BUG： 软件的实际执行过程与需求有较大的差异；系统运行过程中偶尔（<10%）有出错提示或导致系统运行不正常。 微小(Information) BUG： 软件的实际执行过程与需求有较小的差异；程序的提示信息描述容易使用户产生混淆。
附件一：缺陷级别定义和优先级定义1、缺陷级别定义
2、缺陷优先级定义
注：当缺陷被Reopen时，建议通过有效途径通知相关人员，特别是严重级别为high和view high。 3、缺陷报告规范 ?在项目执行阶段，发现的所有问题都需要提交缺陷管理库－CQ中相应的Project库中，主要包括软件需求、开发程序缺陷、各种需要审核的文档等方 面的内容； ?缺陷报告的填写，需要将问题的重现步骤写清晰，建议安1、2、3...形式提交，且缺陷的相关外部测试条件需要说明详细，缺陷标题要简明、扼要，不要用过 于笼统和模糊的语言加以描述，根据需要适当的将出现的场景、日志等信息以 附件形式提交； ?对于缺陷的回归，应在CQ中的Comments中注明回归的版本号，并依据问题的严重级别对回归的结果做相应的描述。 ●具体的缺陷提交流程如下(针对测试人员)
在缺陷的管理中，对于新增的Rejected和Suspend的缺陷，需要定期时常整理确认，对于未经项目经理、开发组长、测试组长和产品经理确认的缺陷，开发人员无权Rejected/Suspend，同时对于达成共识的Rejected缺陷一定要将意见写入CQ 库中的comments,对于Suspend状态的缺陷，建议要注明由于什么原因被刮起，在什么时间和条件下在处理等信息。 在测试任务完成以后，缺陷库中的缺陷状态应只以三种状态存在：Closed、经过确认并达成共识的Rejected/Suspend。 4、缺陷跟踪 测试人员对其发现的缺陷有义务和责任进行全程的跟踪。从缺陷的提交一直到缺陷的关闭，在这一整套的过程中，测试人员应该一丝不苟的进行把关，不要让错 误轻易的从手边遛走。要定期的向开发组通报缺陷状态，同时及时的更新缺陷库中 缺陷的状态。在一定的条件和时间内，还要对以关闭的缺陷做回归测试。制定有效 而可行的回归测试时间表，尽可能的减少由回归测试间隙产生的测试逃逸。5、缺陷分析 对于缺陷数据库，测试人员应该经常维护更新，并对缺陷的状态，数量，分布
缺陷等级定义 目录 缺陷等级定义 (1) B/S架构(Web)测试的缺陷等级定义： (1) C/S架构(Client)测试的缺陷等级定义： (2) 服务器及接口测试的缺陷等级定义： (4) B/S架构(Web)测试的缺陷等级定义： A: 致命 1.正常的用户操作导致浏览器崩溃或无响应 2.产品核心功能没有实现或无法使用 3.程序实现与需求严重不符 4.其他导致无法测试的错误 5.严重的数值计算错误 6.存在致命的安全漏洞 7.Bug被重开3次以上含3次 8.上线前最后一个版本配置管理出现问题 B: 严重 1.产品功能实现不正确 2.主业务流程对应的功能未实现，阻碍测试继续进行 3.严重的兼容性问题和页面样式问题，如：页面样式严重错乱，导致页面控件无法正常定 位； 4.正常的用户操作导致浏览器出现偶发类崩溃（偶发概率20%以上） 5.程序实现与需求功能上不符 6.其他导致部分模块无法测试的错误 7.主要数值计算错误 8.严重的功能逻辑错误 9.Bug被重开2次 10.上线前进入最后一轮测试时版本配置管理出现问题 C: 较严重 1.正常的用户操作导致浏览器出现偶发类崩溃（偶发概率10%以下） 2.用户非常规操作导致浏览器崩溃或影响系统性能的问题
3.程序上非主要功能与需求上功能描述不符 4.功能实现错误但不影响主要流程 5.轻微的数值计算错误 6.页面出现JS错误且导致某功能不可用 7.兼容性导致的主要功能问题 8.系统中用户权限实现有误 9.初始化错误 10.Bug被重开1次 11.上线前进入测试时，提交测试的过程版本配置管理出现问题 12.操作界面UI类的严重错误，易造成大量投诉，产生较坏影响力 D: 一般性问题主要为：界面类、容错类缺陷 1.操作界面UI类的一般性错误 2.边界条件下错误 3.提示信息错误（包括未给出信息、信息提示错误等） 4.界面中操作焦点错误（如按Tab键未顺序操作，弹出其他窗口后主界面焦点位置错误等） 5.输入域的相关问题，如：输入框长度判断错误； E:易用性和建议类缺陷 1.界面格式等不规范 2.辅助说明描述不清楚 3.操作时未给用户提示 4.可输入区域和只读区域没有明显的区分标志 5.个别不影响产品理解的错别字 6.文字排列不整齐等一些小问题 7.建议类型的缺陷 C/S架构(Client)测试的缺陷等级定义： A: 致命 1.程序无法运行/模块无法启动/异常退出 2.程序导致操作系统崩溃/死机/蓝屏 3.程序实现与需求严重不符 4.程序实现与技术文档严重不符 5.程序实现与开发规范严重不符 6.导致产品无法继续进行测试的缺陷 7.程序占用资源高（比同类产品高出50%以上） 8.内存、GDI等泄漏 9.Bug被重开3次以上含3次 10.上线前最后一个版本配置管理出现问题
有限公司 软件质量BUG等级定义 版本<1.1>
修订历史记录
1、对Bug严重程度的分级 缺陷级别定义 A类――致命BUG 包括以下各种错误： 1．由于程序所引起的死机,非法退出。 2．程序死循环。 3．数据库发生死锁。 4．与数据库连接错误。 5．主要功能没有实现。 6．因错误操作导致的程序中断。 B类――严重BUG 包括以下各种错误： 1.程序错误但不影响系统和其它程序运行的。 2.程序接口错误。 3.数据库的表、业务规则、缺省值未加完整性等约束条件。 4.次要功能没有实现或间接发生的（经过几步不相关操作后发生的）导致主要需求不 能实现。 5.主要界面的文字错误等。 6.功能错误。 C类—一般性错误 包括以下各种错误： 1．非主要操作界面错误（包括数据窗口内列名定义、含义是否一致） 2．间接发生的（经过几步不相关操作后发生的）导致次要需求不能正常实现。 3．打印内容、格式错误 4．简单的输入限制未放在前台进行控制 D类—较小错误 包括以下各种错误：不影响软件的功能，但影响软件的品质。 1．界面不规范 2．辅助说明描述不清楚 3．输入输出不规范 4．长操作未给用户提示 5．提示窗口文字未采用行业术语 6．可输入区域和只读区域没有明显的区分标志 E类—测试建议 测试人员从测试角度对软件提出的合理化的改进建议，由项目经理决定是否采纳。 2、对Bug现在程度的分级
每次出现：出现概率100%； 经常出现：出现概率大于20%； 很少出现：出现概率小于20%； 出现一次：在整个测试工作中只出现一次。 3、测试人员对软件的评估 测试人员对软件的评估主要依据测试计划中所制定的输出准则和最后遗留的Bug状况。 A类－－致命Bug，一般认为发布的软件中不允许存在。 B类－－严重Bug，每一万行代码中允许遗留2－3条。 C类－一般性Bug，每一万行代码中允许遗留3－6条。 D类－一较小Bug，由项目经理决定注销或遗留。 E类－一测试建议，由项目经理决定注销或遗留。
软件缺陷级别定义 1.缺陷定义 >软件没有达到产品说明书表明的功能 >软件出现了产品说明书中不一致的表现 软件功能超出产品说明书的范围 软件没有达到用户期望的目标 虽然产品说明书中没有要求 测试员或用户认为软件的易用性差 2.不是所有的缺陷都会修改 市场的压力使得产品最终发行有时间限制 测试员错误理解或者不正确操作引出的缺陷 错误的修改影响的模块较多，带来的风险较大 缺陷报告中提出的问题很难重现 修改性价比太低 3. 优先级 o 最高级--导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等. o 紧急---事件非常重要,并且需要马上给予关注. o 高级---事件是重要的,并且应该在紧急的事件处理之后尽快得到解决. o 中级---事件是重要的,但是由于解决问题需要花费一定的时间,所以可以用较长的时间解决. o 低级---事件不重要,可以在时间和资源允许的情况下再解决. o 建议性缺陷. 4. 分类标准: A类——致命错误，
不能执行正常工作功能或重要功能。使系统崩溃或资源严重不足。包括：o 由于程序所引起的死机,非法退出 o 死循环 o 导致数据库发生死锁 o 数据通讯错误 o 严重的数值计算错误 o与数据库连接错误 o 数据通讯错误 B类——严重错误，严重地影响系统要求或基本功能的实现，且没有办法更正（重新安装或重新启动该软件不属于更正办法）。包括： o 功能不符 o 数据流错误 o 程序接口错误 o 轻微的数值计算错误 C类——一般性错误，严重地影响系统要求或基本功能的实现，但存在合理的 更正办法（重新安装或重新启动该软件不属于更正办法）。包括： o 界面错误(详细文档) o 打印内容、格式错误 o 简单的输入限制未放在前台进行控制 o 删除操作未给出提示 D类——较小错误，使操作者不方便或遇到麻烦，但它不影响执行工作或功能 实现。包括： o 辅助说明描述不清楚 o 显示格式不规范 o 长时间操作未给用户进度提示 o 提示窗口文字未采用行业术语 o 可输入区域和只读区域没有明显的区分标志 o 系统处理未优化 E类——测试建议（非缺陷）
软件缺陷定义
软件缺陷概述 软件缺陷，通常又被叫做Defect或者Bug，即为软件或程序中存在的某种破坏正常运行能力的问题、错误，其存在会导致软件产品在某种程度上不能满足用户的需要。 从产品内部看，缺陷是软件产品开发或维护过程中存在的问题、错误。 从产品外部看，缺项是系统所需要实现的某种功能的失效或违背。 软件缺陷属性 软件缺陷的属性包括缺陷标识、缺陷类型、缺陷级别（或严重等级）、缺陷产生可能性（或概率）、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷根源（原因）。 以上属性是为了准确描述缺陷而赋予的，这里分别作介绍： 1.缺陷标识：是标记某个缺陷的唯一标识，可以用数字序号表示； 2.缺陷类型：功能、用户界面、文档、软件包、性能、接口、兼容性等； a)功能：影响了各种系统功能、逻辑的缺陷； b)用户界面：影响了用户界面、人机交互特性的缺陷； c)文档：影响发布和维护，包括注释、用户手册、设计文档等的缺陷； d)软件包：由于软件配置库、变更管理或版本控制引起的错误； e)性能：不满足系统可测量的属性值，如执行时间、事务处理速率等； f)接口：与其他组件、模块、调用参数、控制块等不匹配、冲突； g)兼容性：与工作环境、其他外设，如操作系统、浏览器、网络环境等不匹配、 冲突； 3.缺陷级别：致命、严重、一般、轻微；（举例） a)致命：系统任何一个主要功能完全失效，用户数据受到破坏，系统崩溃、悬挂、 司机或者危机人身安全； b)严重：系统的主要功能部分失效，数据不能保存，系统的次要功能完全丧失， 系统所提供的功能或服务受到明显影响； c)一般：系统的次要功能没有完全实现，但不影响用户的正常使用。如提示信息 不准确或用户界面差、操作时间长等。 d)轻微：使操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别不
软件开发度量及考核方法 一、引言 如果要提高软件开发人员的开发质量，必须有相应的考核制度，有了制度后才能推动开发人员想方设法改善自已的开发质量。虽然目前很多公司有这方面的绩效考核，但是由于软件开发行业的特殊性，大多数公司没有对软件开发的过程进行细粒度的度量，所以不能依据有效的度量数据来考核开发人员的工作绩效，大部份只是凭考核人主观意志来考核，不能形成对被考核人有效的说服力。所以根据以前经验和相关的资料编写了适用于本部门的度量和考核方法。该考核方法是技术支持部软件开发人员和测试人员的试行版本。 二、目的 对软件开发的过程所产生的软件项的质量和过程进行定量的评价，用评价的结果指导软件的开发过程，不断地提高软件开发质量水平，并依据度量记录来考核软件开发人员的工作绩效。 三、考核实施办法 1、定义 1.1 、软件项包括 1）、技术文档："软件工程产品集"所确定的配置项。主要包括：用户需求文档、需求分析文档、概要设计文档、详细设计文档、开发计划、测试文档、用户手册、总结报告等。 2）、计算机程序。 1.2 、度量数据的来源 1）、项目计划：过程度量中及时度考核数据的主要依据。 2）、测试文档：计算机程序质量考核数据主要依据。 3）、软件维护记录：主要是指软件产品投入用户使用后产生的软件维护记录。
2、质量度量 2.1度量指标 主要根据各类软件项检查表的检查指标来确定。例如，详细设计说明书检查表有10个检查指标，则根据具体项目检查侧重点不同，可从中选择相应的检查指标作为度量指标。（本文末尾附了各工作阶段的考核检查指标表） 2.2质量等级 1）软件项的质量等级的确定根据度量综合指标进行。 2）度量综合指标计算公式为： Total =刀QiMi。 3）其中i=1,2,...n 代表指标数量； 4）Q代表度量的指标； 5）M代表度量的指标Q在整个指标体系中所占的权重系数，对不同的开发项目可能不同，此系数根据开发的不同着重点给出。
BUG等级划分方法 一、四级的划分方式： 1.BUG等级划分建议： 目前project上的BUG严重程度分为五个等级，按照CMM5中定义的规范，BUG严重等级可分为3-5个等级，由于我们公司的CMM水平还处于初级阶段，将BUG等级划分过细不符合我们当前的CMM水平，同时也不利于测试人员对BUG等级的精确划分。根据我们公司的情况，同时参照其它中小公司的等级划分标准，建议将BUG等级划分四个等级，分别为致命、严重、一般、提示。 ● 致命(可对应目前BUG体系中的“非常严重”)： 致命性问题主要为：系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。 具体基本上可分为： ○严重花屏 ○内存泄漏 ○用户数据丢失或破坏 ○系统崩溃/死机/冻结 ○模块无法启动或异常退出 ○严重的数值计算错误 ○功能设计与需求严重不符 ○其它导致无法测试的错误 ● 严重(可对应目前BUG体系中的“严重”) 严重性问题主要为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。 具体基本上可分为： ○功能未实现 ○功能错误
○系统刷新错误 ○语音或数据通讯错误 ○轻微的数值计算错误 ○系统所提供的功能或服务受明显的影响 ● 一般(可对应于目前BUG体系中的“普通”) 一般性问题主要为：界面、性能缺陷 具体基本上可分为： ○操作界面错误(包括数据窗口内列名定义、含义是否一致) ○边界条件下错误 ○提示信息错误(包括未给出信息、信息提示错误等) ○长时间操作无进度提示 ○系统未优化(性能问题) ○光标跳转设置不好，鼠标(光标)定位错误 ● 提示(可对应于目前BUG体系中的“轻微及建议”) 提示性问题主要为：易用性及建议性问题 具体基本上可分为： ○ 界面格式等不规范 ○ 辅助说明描述不清楚 ○ 操作时未给用户提示 ○ 可输入区域和只读区域没有明显的区分标志 ○ 个别不影响产品理解的错别字
1.1bug定义表 缺陷等级详细含义： 一级：不能完全满足系统要求，基本功能未完全实现；或者危及人身安全。系统崩溃或挂起等导致系统不能继续运行。 包括以下各种错误： 1.由于程序所引起的死机,非法退出 2.死循环 3.数据库发生死锁 4.因错误操作导致的程序中断 5.重大功能错误 6.与数据库连接错误 7.数据通讯错误 二级：严重地影响系统要求或基本功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题。 包括以下各种错误： 1.程序接口错误 2.因错误操作迫使程序中断
3. 系统可被执行，但操作功能无法执行（含指令） 4. 单项操作功能可被执行，但在此功能中某些功能（含指令参数的使用）无法被执行（对系统非致命的） 5. 在功能项的某些项目（选项）使用无效（对系统非致命的） 6.业务流程不正确 7.功能实现不完整，如删除时没有考虑数据关联 8.功能的实现不正确，如在系统实现的界面上，一些可接受输入的控件点击后无作用；对数据库的操作不能正确实现 9. 报表格式以及打印内容错误（行列不完整，数据显示不在所对应的行列等导致数据显示结果不正确的错误） 三级：严重地影响系统要求或基本功能的实现，但存在合理的更正办法（重新安装或重新启动该软件不属于更正办法）。系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题。 包括以下各种错误： 1.操作界面错误（包括数据窗口内列名定义、含义是否一致） 2.打印内容、格式错误（只影响报表的格式或外观，不影响数据显示结果的错误） 3.简单的输入限制未放在前台进行控制 4.删除操作未给出提示 5.虽然正确性不受影响，但系统性能和响应时间受到影响 6.不能定位焦点或定位有误，影响功能实现 7. 显示不正确但输出正确 8. 增删改功能，在本界面不能实现，但在另一界面可以补充实现。 四级：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方便等小问题或需要完善的问题。 包括以下各种错误： 1.界面不规范 2.辅助说明描述不清楚 3.输入输出不规范
文档名缺陷等级定义说明文档撰写人方杰 缺陷等级定义 目录 缺陷等级定义 (1) B/S架构(Web)测试的缺陷等级定义： (1) C/S架构(Client)测试的缺陷等级定义： (3) 服务器及接口测试的缺陷等级定义： (4) B/S架构(Web)测试的缺陷等级定义： A: 致命 1.正常的用户操作导致浏览器崩溃或无响应 2.产品核心功能没有实现或无法使用：例如博客不能发博文、播放器无法播放视频、邮箱 无法登录、不能收发邮件 3.程序实现与需求严重不符：例如一个程序改版只为了按需求增加统计功能，但程序没有 统计功能或有统计输出但并非是要统计的数据 4.其他导致无法测试的错误：例如没有新功能入口 5.严重的数值计算错误：例如算法设计错误，导致计算结果错误 6.存在致命的安全漏洞：例如密码不匹配也可登录、密码暴露在URL串中、复制最高权限 登录后的页面链接在其他进程浏览器中，无需再次验证即可拥有最高权限 7.Bug被重开次数>=3次，如果原来bug定级为A，则无需改变缺陷级别 8.上线前最后一个版本配置管理出现问题 B: 严重 1.正常的用户操作导致浏览器出现偶发类崩溃（偶发概率20%以上） 2.主业务流程对应的功能没有实现或实现不正确，阻碍测试继续进行 3.程序上主要功能实现与需求不符 4.其他导致部分模块无法测试的错误 5.主要数值计算错误：例如需要统计5类数据，但只有3类数据被统计 6.XSS漏洞等安全性问题 7.1 文档名缺陷等级定义说明文档撰写人方杰 9.主要页面404、502或其他问题 10.严重的功能逻辑错误 11.严重的操作权限错误，对用户数据造成严重影响，如博客的访客可以做删除博文操作等 12.严重的兼容性问题和页面样式问题，如：页面样式严重错乱，导致页面控件无法正常定 位 13.页面下载明显缓慢或接口调用明显缓慢并可能导致功能无法使用等性能问题 C: 较严重 1.正常的用户操作导致浏览器出现偶发类崩溃（偶发概率10%以下） 2.用户非常规操作导致浏览器崩溃或影响系统性能的问题 3.次业务流程对应的功能没有实现或实现错误，但不影响测试继续进行：例如不能修改昵 称等非主要问题 4.程序上主要功能的分支或非主要功能与需求不符 5.轻微的数值计算错误：对于取整类、四舍五入类的计算，异常操作的输出未被计算在内 6.Bug被重开次数=1次，如果原来bug定级为A或B，则无需改变缺陷级别 7.上线前进入测试时，提交测试的过程版本配置管理出现问题 8.初始化错误：如统计中的初始值 9.输入域执行SQL、JS等代码的问题 10.系统中用户权限实现有误 11.兼容性导致的主要功能问题 12.CSS错乱等严重的样式问题 13.页面出现JS错误且导致某功能不可用 D: 一般性问题主要为：界面类、容错类缺陷 1.次要功能的分支与需求不符 2.操作界面UI类错误：例如显示折行、溢出等样式问题 3.边界条件下错误、输入域的边界问题 4.输入域对特殊字符处理的相关问题 5.提示信息错误（包括未给出信息、信息提示错误等） 6.界面中操作焦点错误（如按Tab键未顺序操作，弹出其他窗口后主界面焦点位置错误等） 7.输入域的相关问题，如：输入框长度判断错误 8.非主流浏览器出现的一些可替代的功能异常 E:易用性和建议类缺陷 1.界面格式等不规范 2.一些边角的样式问题 3.需求未定义的一些页面展现，如Title显示不正确等 软件缺陷分类标准 修订历史记录 目录 1. 引言................................................... 1.1编写目的 .......................................... 1.2定义与缩写 ........................................ 1.3参考资料 .......................................... 2.软件缺陷分类标准....................................... 2.1问题类型 .......................................... 2.2缺陷属性 .......................................... 2.3缺陷类型 .......................................... 2.4缺陷严重程度 ...................................... 2.5缺陷优先级 ........................................ 2.6缺陷状态 .......................................... 2.7缺陷来源、起源 .................................... 2.8缺陷根源 .......................................... 2.9缺陷产生可能性 .................................... 1.引言 1.1编写目的 制定本标准的目的是为软件测试提供确信分类的标准。本文档说明了问题类型、缺陷属性、确缺陷类型、缺陷严重级别、缺陷优先级、缺陷状态、缺陷修改次数、缺陷原因。其预期的读者是测试人员、开发人员、开发经理。 1.2定义与缩写 表格1-1 定义与缩写 1.3参考资料 表格1-2 参考资料列表 近日，加拿大达内科技公司、北京大学软件学院与亚信科技(中国)公司、精点科技(中国)公司、迪思杰科技(中国)公司、中通网络产业公司以及中关村科技园区的30多家企业达成定向人才培养计划。从2005年5月8日开始，软件测试时代为这些企业量身培养IT就业市场紧缺的软件测试工程师百余名。经过2个多月的培训，这些软件测试工程师将直接到领测软件测试时代的签约公司就业。 随着中国IT行业的发展，几乎每个中大型IT企业的产品在发布前都需要大量的质量控制、测试和文档工作。由于前些年企业对产品的测试工作重视不够，又加上没有系统地测试培训课程，因此软件测试工程师及系统测试工程师将在短期内出现严重的短缺现象。从近期的企业人才需求和薪金水平来看，测试工程师的年工资有逐年上升的明显迹象。测试工程师这个职位将成为IT就业的新亮点。 测试工程师一般分为以下几个等级：测试工程师、高级测试工程师和资深测试工程师。测试工程师一般承担以下工作：利用软件测试工具按照测试方案和流程对产品进行功能和性能测试，检查产品是否有缺陷，性能是否稳定；高级测试工程师一般的职责是：不但能够编写测试工具，而且能够设计和维护测试系统，编写测试方案，编写测试文档、编写安装和使用手册；资深测试工程师的职责要求更高：不但能够具有初级测试工程师和高级测试工程师的能力，而且能够对测试方案可能出现的问题能够进行分析和评估。今天看到论坛里一个学员在问“到底应该是谁把缺陷状态置为PostPone,Rejected,Duplicate是Developer 还是PM或CCB？”，还有学员对优先级这个字段理解的不够透彻，原话是“优先级的填写要看情况的。因为有时Tester 开的bug 很多，而PM又有好多TESTER，那PM就来不及去一一看那些BUG了，这时Priority就得由tester填写”，而论坛里还有同学找了篇英文的文章来告诉大家“看，老外都是这么做的”。 我觉得有必要给大家解释透这两个概念，这样不至于在日后的工作中做错。 以下粉红色部分是对那篇英文的引用，后面则是我的回答（结合微软的实际例子给大家说明）。 QUOTE: 原帖由rivermen于 2007-3-9 09:12 发表 c) The tester then selects the priority of the defect: Critical - fatal error High - require immediate attention Medium - needs to be resolved as soon as possible but not a showstopper Low - cosmetic error 从这篇文章来看，这段英文描述是有问题的——不能说不对，至少不合理。 优先级不应该给tester指定，这也是很多缺陷流程制定者容易忽略到的地方——很大一部分原因是流程制定者没有做过项目管理的工作或者学习过项目管 理的知识。 软件缺陷管理办法 1.目的 本文档定义了软件缺陷管理流程和相关规则，确保软件缺陷管理的系统性和规范性，以保证项目研发质量。 2.适用范围 适用于部门项目研发过程的缺陷管理，对各阶段的缺陷管理过程进行指导和规范。 3.定义 3.1 术语 缺陷（Defect）：存在于软件之中偏差，可被激活，以静态形式存在于软件内部。 Bug：缺陷一种表现形态，系统或程序存在的任何一种破坏正常运转能力的问题。 3.2 缺陷定义 （1）软件未达到需求规格说明书的功能； （2）软件出现了需求规格说明书指明不会出现的错误； （3）软件功能超出需求规格说明书的范围； （4）软件未达到需求规格说明书未指出但应达到的目标； （5）测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。 4.缺陷生命周期 4.1缺陷生命周期图 4.2 缺陷状态说明 5.缺陷处理过程 5.1 正常处理过程 （1）创建问题 在测试管理系统中，所有用户都可以创建新问题，包括需求问题和软件缺陷等。创建问题时，需要描述清楚，并选择正确的选项，详细请参考5.4和5.5。（2）指派问题 创建问题时，创建者通常要指派给该项目开发负责人，再由其指派任务，或直接指派给相应模块的开发工程师。 如果指派人是错误的，或者需要他人确认或帮助，则可以重新指派给合适的工程师，写上相关备注。 （3）确认问题 通常开发工程师收到新问题后，需要分析和确认此问题是否为Bug。如果是Bug，则选择“确认状态”；如果认为非Bug，则注明原因并指派回创建者。 当创建者收到确认指派时，需要进行及时确认。如果同意为非bug，则及时关闭它；如果不同意，则需要注明理由并指派回相关工程师。 如果问题确认指派次数大于6次时，需要进入“争议处理”流程，详细请参考5.2。 （4）解决问题 此为开发工程师的主要职责，包括Bug的复现、修改和修改验证。 开发工程师需要及时对确认状态Bug进行分析和解决，并自己验证通过，则操作为解决状态，解决方案规则请参考5.4中解决方案定义部分，在缺陷管理系统中解决方案选择相应的选项，解决后系统将自动指派回给创建者。 如果Bug无法解决或修改影响比较大，可申请进入“延期解决”流程，请参考5.2中延期处理部分。 （5）验证问题 创建者需要及时对解决状态的Bug在对应版本上面进行验证。如果验证通过，则可关闭Bug；如果验证不通过，则激活此Bug，系统将自动指派回给解决者。软件缺陷分类标准
软件缺陷定义及分类
软件缺陷管理流程
相关主题
文本预览