软件缺陷定义
软件缺陷概述
软件缺陷，通常又被叫做Defect或者Bug，即为软件或程序中存在的某种破坏正常运行能力的问题、错误，其存在会导致软件产品在某种程度上不能满足用户的需要。
从产品内部看，缺陷是软件产品开发或维护过程中存在的问题、错误。
从产品外部看，缺项是系统所需要实现的某种功能的失效或违背。
软件缺陷属性
软件缺陷的属性包括缺陷标识、缺陷类型、缺陷级别（或严重等级）、缺陷产生可能性（或概率）、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷根源（原因）。
以上属性是为了准确描述缺陷而赋予的，这里分别作介绍：
1.缺陷标识：是标记某个缺陷的唯一标识，可以用数字序号表示；
2.缺陷类型：功能、用户界面、文档、软件包、性能、接口、兼容性等；
a)功能：影响了各种系统功能、逻辑的缺陷；
b)用户界面：影响了用户界面、人机交互特性的缺陷；
c)文档：影响发布和维护，包括注释、用户手册、设计文档等的缺陷；
d)软件包：由于软件配置库、变更管理或版本控制引起的错误；
e)性能：不满足系统可测量的属性值，如执行时间、事务处理速率等；
f)接口：与其他组件、模块、调用参数、控制块等不匹配、冲突；
g)兼容性：与工作环境、其他外设，如操作系统、浏览器、网络环境等不匹配、
冲突；
3.缺陷级别：致命、严重、一般、轻微；（举例）
a)致命：系统任何一个主要功能完全失效，用户数据受到破坏，系统崩溃、悬挂、
司机或者危机人身安全；
b)严重：系统的主要功能部分失效，数据不能保存，系统的次要功能完全丧失，
系统所提供的功能或服务受到明显影响；
c)一般：系统的次要功能没有完全实现，但不影响用户的正常使用。如提示信息
不准确或用户界面差、操作时间长等。
d)轻微：使操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别不
影响理解的错别字、排布不整齐等。
4.缺陷产生可能性：必现、通常、有时、很少；
a)必现：按照一定路径必定出现，其产生概率为100%；
b)通常：按照测试用例（即已知步骤），通常情况下回产生这个缺陷，其产生频
率大概是80%；
c)有时：按照测试用例，有时候产生这个缺陷，其产生频率大概是30%；
d)很少：按照测试用例，很少产生这个缺陷，其产生概率大概是1%以下；实际
测试中，仅出现过一次后无法复现的缺陷也划分到此类；
e)缺陷优先级：参见“缺陷级别定义”章节；
5.缺陷状态：打开、已修复、关闭、拒绝、重复、重新打开、推迟、保留、不能重现；
（可根据实际情况增加或减少使用的缺陷状态）
a)打开：问题还没有解决，确认“提交的缺陷”，等待处理，如新报的缺陷；
b)已修复：已被开发人员检查、修复过的缺陷，通过单元测试，认为已经解决但
还没有被测试人员验证；
c)关闭：测试人员验证后，确认缺陷不存在之后的状态；
d)拒绝：开发人员认为不是缺陷；
e)重复：开发人员认为此缺陷与某打开的缺陷重复；
f)重新打开：测试人员验证后，确认缺陷仍然存在后的状态；
g)推迟：这个软件缺陷可以在下一个版本中解决；
h)保留：由于技术原因或者第三方软件的缺陷，开发人员不能修复的缺陷；
i)不能重现：开发人员不能再现这个缺陷，需要测试人员确认缺陷再现的步骤；
6.缺陷的起源：需求、架构、设计、编码、测试、用户；
在软件生命周期中，缺陷所占比例：需求和架构阶段54%、设计阶段25%、编码阶段15%、其他6%；
7.缺陷的来源：需求说明书、设计文档、系统集成接口、数据流（库）、程序代码；
a)需求说明书：需求的错误或不清楚引起的问题；
b)设计文档：设计文档描述不准确，与需求说明书不一致的问题；
c)系统集成接口：系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷；
d)数据流（库）：由于数据字典、数据库中的错误引起的缺陷；
e)程序代码：纯粹由编码引起的缺陷；
8.缺陷的根源：测试策略，过程、工具盒方法，团队/人，缺乏组织和沟通，硬件，
软件，工作环境；
a)测试策略：错误的测试范围，误解测试目标，超越测试能力等；
b)过程、工具和方法：无效的需求收集过程，过失的风险管理过程，不适用的项
目管理方法，无效的变更控制过程等；
c)团队/人：项目团队职责较差，缺乏培训，没有经验的项目团队，缺乏士气等；
d)缺乏组织和沟通：缺乏用户参与，职责不明确、管理失败等；
e)硬件：硬件配置不对、缺乏等；
f)软件：软件配置不对、缺乏，或操作系统错误导致无法释放资源，工具软件错
误，编译器错误等；
g)工作环境：组织机构调整，预算改变，工作环境恶劣等。
缺陷级别定义
按照CMM5，缺陷级别（严重等级）可分为3-5个等级，根据公司实际情况来决定缺陷级别的划分。
这里将缺陷划分为四级：致命、严重、一般、轻微。
如何高效填写软件缺陷报告 测试工程师需要利用对需求的理解、高效的执行力以及严密的逻辑推理能力，迅速找出软件中的潜在缺陷，并以缺陷报告的形式递交给开发团队。缺陷报告是测试工程师与开发工程师交流沟通的重要桥梁，也是测试工程师日常工作的重要输出。作为优秀的测试工程师，最基本的一项技能就是，把发现的缺陷准确无歧义地表达清楚。 “准确无歧义地表达”意味着，开发工程师可以根据缺陷报告快速理解缺陷，并精准定位问题。同时，通过这个缺陷报告，开发经理可以准确预估缺陷修复的优先级、产品经理可以了解缺陷对用户或业务的影响以及严重性。 可见，缺陷报告本身的质量将直接关系到缺陷被修复的速度以及开发工程师的效率，同时还会影响测试工程师的信用、测试与开发人员协作的有效性。 那么，如何才能写出一份高效的缺陷报告呢？或者说，一份好的缺陷报告需要包括哪些具体内容呢？ 你可能觉得这并不是什么难事，毕竟软件企业通常都有缺陷管理系统，比如典型的ALM（以前的Quality Center）、JIRA、Bugzilla、BugFree和Mantis等。当使用这类系统递交缺陷时，会自动生成模板，你只要按照其中的必填字段提供缺陷的详细信息就可以了。
很多时候，你不用想应该提供说明信息，系统会引导你提供相关的信息。但是，你有仔细想过为什么要填写这些字段，这些字段都起什么作用，以及每个字段的内容应该怎么填写吗？ 你必须牢牢记住的是，好的缺陷报告绝对不是大量信息的堆叠，而是以高效的方式提供准确有用的信息。 缺陷标题 缺陷标题通常是别人最先看到的部分，是对缺陷的概括性描述，通常采用“在什么情况下发生了什么问题”的模式。 首先，对“什么问题”的描述不仅要做到清晰简洁，最关键是要足够具体，切忌不能采用过于笼统的描述。描述“什么问题”的同时还必须清楚地表述发生问题时的上下文，也就是问题出现的场景。 “用户不能正常登陆”“搜索功能有问题”和“用户信息页面的地址栏位置不正确”等，这样的描述会给人“说了等于没说”的感觉。这样的描述，很容易引发开发工程师的反感和抵触情绪，从而造成缺陷被拒绝修改（reject）。同时，还会造成缺陷管理上的困难以及过程的低效。 比如，当你发现了一个菜单栏上某个条目缺失的问题，在递交缺陷报告前，通常会去缺陷管理系统搜索一下是否已经有人递交过类似的缺陷。当你以“菜单栏”为关键字搜索时，你可能会得到一堆“菜单栏有问题”的缺陷，如果缺陷标题的描述过于笼统，你就不得不点击进入每个已知缺陷点去看细节描述，这就会大大降低你的工作效率。所以，如果
缺陷严重程度分类的定义： Critical：An observation is defined as“Critical”when any one or more of the following four conditions apply： ● Any non-conformance or non-compliance that will or already has adversely affected product performance meeting specification，safety，therapeutic efficacy，or regulatory requirements。 ● Any non-conformance or non-compliance that if allowed to continue，may result in product rejection，field action，or serious regulatory action(e.g. Warning Letter or similar) ● The observation is a repeat“Critical”or“Major”observation,or relates to failure to meet a commitment made to a regulatory authority。 ● The observation represents the complete absence of one or more quality system elements or system components necessary to meet regulatory requirements. Ma jor:An observation is defined as“Major” when any one or more of the following two conditions apply： ● Any non-conformance or non-compliance that may or may have adversely affected product performance meeting specification，safety，therapeutic efficacy，or regulatory requirements。 ● Any isolated non-compliance in not reporting or reporting late any required regulatory/health authority reports notifications.(Note:frequent occurrences represent a “Critical”observation.)
缺陷严重级别定义: 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.上线前最后一个版本配置管理出现问题
软件缺陷描述 认识软件缺陷，首先要了解软件缺陷的概念，其次是了解软件缺陷的详细特征，最后就是它的属性了，再高一个层次就是学习利用管理软件缺陷的工具了。 1、首先介绍软件缺陷的概念 软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。 2、软件缺陷的详细特征 a、单一准确 b、可以再现（要求软件缺陷具有精确的步骤） c、完整统一 d、短小简练 e、特定条件 f、补充完整 g、不做评价 3、软件缺陷的属性 软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。 下面详细介绍一下以上这些属性： a、缺陷标识：是标记某个缺陷的唯一标识，可以用数字序号表示； b、缺陷类型：功能、用户界面、文档、软件包、性能、系统\模块接口 功能：影响了各种系统功能、逻辑的缺陷； 用户界面：影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输入格式等方面的缺陷； 文档：影响发布和维护，包括注释、用户手册、设计文档； 软件包：由于软件配置库、变更管理或版本控制引起的错误； 性能：不满足系统可测量的属性值，如执行时间、事务处理速率等； 系统\模块接口：与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。 c、缺陷严重程度：致命（Fatal）、严重（Ceritical）、一般（Major）、较小（Minor） 致命：系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机或者危机人身安全； 严重：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响； 一般：系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题； 较小：使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题 d、缺陷产生可能性：总是、通常、有时、很少 总是：总是产生这个软件缺陷，其产生的频率是100%； 通常：按照测试用例，通常情况下会产生这个软件缺陷，其产生的频率大概是80%—90%； 有时：按照测试用例，有时候产生这个软件缺陷，其产生的频率大概是30%—50%；
出生缺陷的定义、分类及危害 一、出生缺陷的定义 出生缺陷又称先天缺陷，是指由于先天性、遗传性和不良环境等原因引起的出生时存在的各种结构性畸形和功能性异常的总称。是导致流产、死胎、死产、新生儿死亡和婴儿夭折的重要原因。 出生缺陷包括形态上的畸形(如脊柱裂)、细胞的异常(如先天性白血病)、染色体异常(如21-三体综合征)、分子的异常(如苯丙酮尿症)等。也包括精神、行为等方面的异常。 二、出生缺陷的分类 根据出生缺陷特点分为变形缺陷，裂解缺陷，发育不良，畸形缺陷四类。 根据出生缺陷的严重程度可将其分为重大和轻微的缺陷两类，前者是指需进行较复杂的内科、外科及矫形处理的出生缺陷，后者则不需进行复杂处理。 根据发生情况出生缺陷可分为三类：①三胚层形成紊乱，多发生在胚胎第15-18天，常见神经管与肠管相通、内脏反位、连体畸胎等三种；②神经管闭合过程紊乱，导致脑、脊髓发育不全，进而引起椎弓、颅骨及邻近皮肤出现异常，常见于无脑畸形、脑膨出、脊柱裂等畸形；③器官系统发生和形成过程中的紊乱，种类多，可分为胚体升高过程紊乱、器官原基发生过程紊乱、器官发生过程后期紊乱、性别决定和分化过程中的紊乱等几类。
在常见的出生缺陷有： 1．神经系统畸形：无脑畸形、脑膨出、脊柱裂、先天性脑积水、小头畸形、脑性瘫痪； 2．头部器官畸形：先天性白内障、小眼畸形、小耳畸形、副耳及耳凹、小下颌； 3．腹壁缺损及疝：腹裂畸形、脐膨出、膀胱外翻、膈疝、脐疝、腹股沟斜疝； 4．消化系统畸形：腭裂、唇裂、食道闭锁、狭窄和食道气管瘘、先天性肥大性幽门狭窄、先天性肠闭锁和先天性肠狭窄、先天性巨结肠、直肠或肛门闭锁； 概论-常见的出生缺陷 5．先天性心脏病：房间隔缺损、室间隔缺损、动脉导管未闭、法洛四联症、完全性大动脉转位、肺动脉狭窄； 6．泌尿生殖系统畸形：尿道下裂、先天性肾囊肿、隐睾、外生殖器两性畸形。 7．四肢畸形：足变形、多指（趾）畸形、并指（趾）畸形、肢体短缺畸形、先天性髋关节脱位； 8．皮肤畸形：血管瘤、色素痣； 9．遗传代谢病及多发畸形：21-三体综合征、苯丙酮尿症、肝糖原累积病、软骨营养障碍。 三、危害 出生缺陷是世界范围内围产儿、婴儿死亡的主要原因，并导致大
软件缺陷描述规范 一、缺陷基本定义 软件缺陷（Software Defect）： 软件缺陷是对软件产品预期属性的偏离现象。它包括检测缺陷和残留缺陷。 缺陷的优先性，分为5级，参考下面的方法确定： 1)最高优先级(Blocker)，例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷，或用户重点关注的问题,缺陷导致系统几乎不能使用或者测试不能继续，需立即修复。 2)较高优先级(Critical)，例如，影响软件功能和性能的一般缺陷, 严重影响测试，需要优先考虑； 3)一般优先级(Major)，例如，本地化软件的某些字符没有翻译或者翻译不准确的缺陷,需要正常排队等待修复； 4)低优先级(Minor)，例如，对软件的质量影响非常轻微或出现几率很低的缺陷,可以在开发人员有时间的时候再被纠正； 5)最低优先级(Trival),例如，属于优化，可以不做修改的问题或暂时无法修复但影响不大的问题。
缺陷描述 软件缺陷的描述是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发工程师交流的最好机会。一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员,因此，正确评估缺陷的严重程度和优先级，是项目组全体人员交流的基础。 缺陷描述的原则： 有效的缺陷描述有以下几个原则： 可以重现：在缺陷的详细描述中提供精确的操作步骤，可以让发人员容易看 懂； 定位准确：缺陷描述准确，不会引起误解和歧义； 描述清晰：对操作步骤的描述清晰，易于理解，应用客观的书面语，避免使 用口语； 完整统一：提供完整、前后统一的软件缺陷的步骤和信息，按照一致的格式 书写全部缺陷报告，有关缺陷的格式参见“缺陷的格式”； 短小简练：通过使用关键词，可以使问题摘要的描述短小简练，又能准确解 释产生缺陷的现象。如“在新建任务窗口中，选择直接下达，负责人收不到 即时消息”中“新建任务窗口”、“直接下达”、“即时消息”等是关键词； 特定条件：许多软件功能在通常情况下没有问题，而是在某种特定条件下会 存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件 （如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原 因的线索。如“网站在和的兼容问题”； 不做评价：在软件缺陷描述不要带有个人观点，对开发软件进行评价。软件 缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以， 不需要任何评价或议论。
有限公司 软件质量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类－一测试建议，由项目经理决定注销或遗留。
审核/日期批准/日期
文档修改记录（Revision Chart） [This chart contains a h istory of this document’s revisions. The entries below are provided solely for purposes of illustration. Entries should be deleted until the revision they refer to has actually been created. The document itself should be stored in revision control, and a brief description of each version should be entered in the revision control system. That brief description can be repeated in this section. Revisions do not need to be described elsewhere in the document except inasmuch as they explain the development plan itself.]
目录 1引言 (1) 1.1 编写目的 (1) 1.2 定义与缩写 (1) 1.3 参考资料 (1) 2软件缺陷分类标准 (1) 2.1 缺陷属性 (1) 2.2 缺陷类型 (1) 2.3 缺陷严重程度 (3) 2.4 缺陷优先级 (4) 2.5 缺陷状态 (4) 2.6 缺陷来源 (4)
1、缺陷定义：线路部（构）件或防护条件在运行中超过本规程第二章规定的运行标准或达不到上级颁发的技术文件（规范）要求，而存在的状态称缺陷。 设备缺陷按其严重程度分为三类：一般缺陷、严重缺陷、危急缺陷。 a、一般缺陷：是指近期安全运行影响不大的缺陷，可列入年、季度检修计划中消除， b、严重缺陷：是指缺陷比较重大，但设备在短期内仍可继续安全运行的缺陷，应在短期内消除，消除前应加强监视； c、危急缺陷：是指严重程度已使设备不能继续安全运行，随时可能导致事故发生的缺陷。必须尽快消除或采取必要的安全技术措施进行临时处理，随后消除。 2、缺陷分类标准 杆塔及基础（危急缺陷） 1、杆塔偏斜超过下表规定 2、塔材连板、塔材及主材包角钢螺丝等大量丢失，随时可能发生倒塔。 3、基础本体严重裂纹、塌陷、有渗透且有涵洞、严重下沉、滑坡及受
洪水冲刷等随时可能发生倒杆者。 严重缺陷 1、杆塔偏斜超过下表规定 2、塔材连板、塔材及主材包角钢螺丝大量丢失，在短期内不致发生倒塔者。 3、基础本体裂纹、塌陷、有水渗透、下沉、滑坡及受洪水冲刷等， 在短期内不致发生倒塔断线者。 4、基础地下金属部件严重腐蚀，铁塔底脚保护帽被破坏，且缺底脚 螺母或螺母松动。 导线和避雷线 危急缺陷 1、避雷线锈蚀或损伤使其截面积减少超过总面积的17%以上者； 2、钢芯铝绞线钢芯断股或损伤程度相当于断股；铝线断股或损伤使 其截面积减少超过铝股总面积的25%以上者； 3、探伤发现爆压管内钢芯烧伤断股，爆压不实者； 4、跳线断股歪扭、严重变形，跳线与杆塔空气间隙达不到最小间隙
要求者； 5、导线、避雷线的压接管有拔出痕迹者；有纵向裂纹者；有因发热而变色者。 6、爆压管有穿孔或有明显裂纹者； 7、引流联板、并沟线夹裂纹、螺栓松动和接触不良使其温度超过90℃或变色者； 8、导线、避雷线悬挂风筝线等异物有可能造成短路者； 9、导线、避雷线的对接管中间缩径者；导线搭接管搭接长度不符合工艺标准者； 10、风筝线连通相间、避雷线、塔身、横担或任何接地物体者； 11、随时可能导致发生事故的其他缺陷。 严重缺陷 1、避雷线锈蚀、损伤截面达到其总面积的10—17%； 导线与地面、建筑物、树木、道路、河流、管道、索道及各种架空线路的距离，应根据最高气温情况或覆冰无风情况求得的最大风偏进行计算。大跨越的导线弧垂应按实际能够到达的最高温度计算。线路与铁路、高速公路、一级公路交叉时，最大弧垂应按导线温度为+70℃
软件测试缺陷(Bug)写作注意点 提供准确、完整、简洁、一致的缺陷报告是体现软件测试的专业性、高质量的主要评价指标。遗憾的是，一些缺陷报告经常包含过少或过多信息，而且组织混乱，难以理解。由此导致缺陷被退回，从而延误及时修正，最坏的情况是由于没有清楚地说明缺陷的影响，开发人员忽略了这些缺陷，使这些缺陷随软件版本一起发布出去。 因此，软件测试工程师必须认识到书写软件缺陷报告是测试执行过程的一项重要任务，首先要理解缺陷报告读者的期望，遵照缺陷报告的写作准则，书写内容完备的软件缺陷报告。本文将阐述软件测试缺陷报告的读者，描述软件缺陷报告的主要组成部分和各部分的书写要求，指出某些常见错误和实用改进方法，最后总结了缺陷报告的写作要点。 1. 缺陷报告的读者对象 在书写软件缺陷报告之前，需要明白谁是缺陷报告的读者对象，知道读者最希望从缺陷报告中获得什么信息。通常，缺陷报告的直接读者是软件开发人员和质量管理人员，除此之外，来自市场和技术支持等部门的人也可能需要查看缺陷情况。每个阅读缺陷报告的人都需要理解缺陷针对的产品和使用的技术。另外，他们不是软件测试人员，可能对于具体软件测试的细节了解不多。 概括起来，缺陷报告的读者最希望获得的信息包括： ?易于搜索软件测试报告的缺陷； ?报告的软件缺陷进行了必要的隔离，报告的缺陷信息更具体、准确； ?软件开发人员希望获得缺陷的本质特征和复现步骤； ?市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度。 软件测试人员的任务之一就是需要针对读者的上述要求，书写良好的软件缺陷报告。 2. 缺陷报告的写作准则 书写清晰、完整的缺陷报告是对保证缺陷正确处理的最佳手段。它也减少了工程师以及其它质量保证人员的后续工作。 为了书写更优良的缺陷报告，需要遵守“5C”准则： ?Correct（准确）：每个组成部分的描述准确，不会引起误解； ?Clear（清晰）：每个组成部分的描述清晰，易于理解； ?Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容； ?Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息； ?Consistent（一致）：按照一致的格式书写全部缺陷报告。 3. 缺陷报告的组织结构 尽管不同的软件测试项目对于缺陷报告的具体组成部分不尽相同，但是基本组织结构都是大同小异的。一个完整的软件缺陷报告通常由下列几部分组成： ?缺陷的标题； ?缺陷的基本信息；
出生缺陷的定义分类和 危害 集团企业公司编码：（LL3698-KKI1269-TM2483-LUI12689-ITT289-
出生缺陷的定义、分类及危害一、出生缺陷的定义 出生缺陷又称先天缺陷，是指由于先天性、遗传性和不良环境等原因引起的出生时存在的各种结构性畸形和功能性异常的总称。是导致流产、死胎、死产、新生儿死亡和婴儿夭折的重要原因。 出生缺陷包括形态上的畸形(如脊柱裂)、细胞的异常(如先天性白血病)、染色体异常(如21-三体综合征)、分子的异常(如苯丙酮尿症)等。也包括精神、行为等方面的异常。 二、出生缺陷的分类 根据出生缺陷特点分为变形缺陷，裂解缺陷，发育不良，畸形缺陷四类。 根据出生缺陷的严重程度可将其分为重大和轻微的缺陷两类，前者是指需进行较复杂的内科、外科及矫形处理的出生缺陷，后者则不需进行复杂处理。 根据发生情况出生缺陷可分为三类：①三胚层形成紊乱，多发生在胚胎第15-18天，常见神经管与肠管相通、内脏反位、连体畸胎等三种；②神经管闭合过程紊乱，导致脑、脊髓发育不全，进而引起椎弓、颅骨及邻近皮肤出现异常，常见于无脑畸形、脑膨出、脊柱裂等畸形； ③器官系统发生和形成过程中的紊乱，种类多，可分为胚体升高过程紊乱、器官原基发生过程紊乱、器官发生过程后期紊乱、性别决定和分化过程中的紊乱等几类。
在常见的出生缺陷有： 1．神经系统畸形：无脑畸形、脑膨出、脊柱裂、先天性脑积水、小头畸形、脑性瘫痪； 2．头部器官畸形：先天性白内障、小眼畸形、小耳畸形、副耳及耳凹、小下颌； 3．腹壁缺损及疝：腹裂畸形、脐膨出、膀胱外翻、膈疝、脐疝、腹股沟斜疝； 4．消化系统畸形：腭裂、唇裂、食道闭锁、狭窄和食道气管瘘、先天性肥大性幽门狭窄、先天性肠闭锁和先天性肠狭窄、先天性巨结肠、直肠或肛门闭锁； 概论-常见的出生缺陷 5．先天性心脏病：房间隔缺损、室间隔缺损、动脉导管未闭、法洛四联症、完全性大动脉转位、肺动脉狭窄； 6．泌尿生殖系统畸形：尿道下裂、先天性肾囊肿、隐睾、外生殖器两性畸形。 7．四肢畸形：足变形、多指（趾）畸形、并指（趾）畸形、肢体短缺畸形、先天性髋关节脱位； 8．皮肤畸形：血管瘤、色素痣； 9．遗传代谢病及多发畸形：21-三体综合征、苯丙酮尿症、肝糖原累积病、软骨营养障碍。 三、危害 出生缺陷是世界范围内围产儿、婴儿死亡的主要原因，并导致大量
设备缺陷范围及分类标准 A.1 设备缺陷管理范围 ——变电站一、二次设备； ——防止电气误操作的闭锁装置； ——通讯、远动、计量系统及其辅助设备； ——变电设备构架、基础、电缆沟道； ——生产性建筑物、照明、给排水、通风、消防、保安系统； ——电力电缆及附件； ——架空线路、架空地线、绝缘子、金具、杆塔、拉线及基础； ——线路防护及交叉跨越； ——防雷保护装置、接地引下线和接地装置； ——配电设备； ——可能影响系统安全运行的其它因素术语和定义。 A.2 设备缺陷的分类 设备紧急缺陷重大缺陷一般缺陷 变电通用部分1.设备瓷件有明显裂缝。 2.设备内部有明显的放电声或 异常声响。 3.主设备与地网连接线断裂。 4.外绝缘有严重放电现象。 5.设备接头发热严重、变红、变 色。 1.35kV及以上电压等级设 备试验超周期且无相应的 批准手续。 2.高、低压室、开关柜防 小动物措施失效。 3.基础下沉。 4.设备接头发热。 1.设备接头温度 超过同类运行设 备的温度（无明显 变化）。 2.其他不影响设 备运行的缺陷 主变压器（消弧线圈、接地变、站用变、电抗器参照执行）1.绝缘油色谱试验重要指标超 标。 2.油中烃类、氢气产气速率超过 10%/月。 3.电气预防性试验主要项目不 合格。 4.套管破损、裂纹，并有严重放 电声。 5.测温装置全部损坏或失灵。 6.主变压器强油循环冷却器全 停。 7.油浸变压器油位异常。 8.有载调压开关动作异常，极限 位置不能闭锁。 9.内部有异常响声。 10.铁芯接地电流超过规定，串 接电阻后仍不能满足运行要求， 并有发展趋势。 12.铁芯或外壳接地不良。 1.引线桩头螺丝松动连接 处发热。 2.绝缘油化学、电气性能 不良，气相色谱数据指示 可能有潜伏故障。 3.温度指示不准确，超温 信号异常（失灵）。 4.基础下沉。 5.冷却设备不全，尚不影 响出力。 6.油位指示与温度监视线 不对应。 7.达不到铭牌或上级批准 的出力，温升及上层油温 超过容许的数值。 8.本体漏油（五分钟内有 油珠垂滴）。 9.铁芯多点接地致使接地 电流超标。 1.变压器渗油。 （1min以上一滴 或未见滴油但油 迹非常大，超过主 变表面积1/10以 上） 2.附件震动大。 3.引线或接线桩 头有严重电晕。 4.预试数据合格， 但与历史数据比 较有明显变化。 5.变压器绕组轻 微变形。 6.其他不影响变 压器运行的缺陷。 7.呼吸器变色达 2/3以上有载调压 开关油室内渗漏
软件缺陷定义
软件缺陷概述 软件缺陷，通常又被叫做Defect或者Bug，即为软件或程序中存在的某种破坏正常运行能力的问题、错误，其存在会导致软件产品在某种程度上不能满足用户的需要。 从产品内部看，缺陷是软件产品开发或维护过程中存在的问题、错误。 从产品外部看，缺项是系统所需要实现的某种功能的失效或违背。 软件缺陷属性 软件缺陷的属性包括缺陷标识、缺陷类型、缺陷级别（或严重等级）、缺陷产生可能性（或概率）、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷根源（原因）。 以上属性是为了准确描述缺陷而赋予的，这里分别作介绍： 1.缺陷标识：是标记某个缺陷的唯一标识，可以用数字序号表示； 2.缺陷类型：功能、用户界面、文档、软件包、性能、接口、兼容性等； a)功能：影响了各种系统功能、逻辑的缺陷； b)用户界面：影响了用户界面、人机交互特性的缺陷； c)文档：影响发布和维护，包括注释、用户手册、设计文档等的缺陷； d)软件包：由于软件配置库、变更管理或版本控制引起的错误； e)性能：不满足系统可测量的属性值，如执行时间、事务处理速率等； f)接口：与其他组件、模块、调用参数、控制块等不匹配、冲突； g)兼容性：与工作环境、其他外设，如操作系统、浏览器、网络环境等不匹配、 冲突； 3.缺陷级别：致命、严重、一般、轻微；（举例） a)致命：系统任何一个主要功能完全失效，用户数据受到破坏，系统崩溃、悬挂、 司机或者危机人身安全； b)严重：系统的主要功能部分失效，数据不能保存，系统的次要功能完全丧失， 系统所提供的功能或服务受到明显影响； c)一般：系统的次要功能没有完全实现，但不影响用户的正常使用。如提示信息 不准确或用户界面差、操作时间长等。 d)轻微：使操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别不
有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等 D类—较小错误的软件缺陷（Minor），使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如错别字、界面不规范（字体大小不统一，文字排列不整齐，可输入区域和只读区域没有明显的区分标志），辅助说明描述不清楚 E类- 建议问题的软件缺陷（Enhancemental）：由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。 常用的软件缺陷的优先级表示方法可分为：立即解决P1、高优先级P2、正常排队P3、低优先级P4。立即解决是指缺陷导致系统几乎不能使用或者测试不能继续，需立即修复；高优先级是指缺陷严重影响测试，需要优先考虑；正常排队是指缺陷需要正常排队等待修复；而低优先级是指缺陷可以在开发人员有时间的时候再被纠正。 正确评估和区分软件缺陷的严重性和优先级，是测试人员和开发人员以及全体项目组人员的一件大事。这既是确保测试顺利进行的要求，也是保证软件质量的重要环节，应该要引起足够的重视。这里介绍三种常用的技术工具供大家参考。 （1）20/80原则 管理学大师彼得杜拉克说过：做事情必须分清轻重缓急。最糟糕的是什么事都做，这必将一事无成。而意大利经济学家柏拉图则更明确提出：重要的少数与琐碎的多数或称20/80的定律。就是80%的有效工作往往是在20%的时间内完成的，而20%的工作是在80%的时间内完成的。因此，为了提高测试质量，必须清晰的认识到哪些软件缺陷是最重要的，哪些软件缺陷是最关键的。不要拣了芝麻，却丢了西瓜。所以，只有抓住了重要的关键缺陷，测试效果才能产生最大的效益，这也是第一个原则---分清轻重缓急，把测试活动用在最有生产力的事情上。 （2）ABC法则
软件缺陷的描述是是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发小组交流的最初且最好的机会。一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员。准确报告软件缺陷是非常重要的，因为： 清晰准确的软件缺陷描述可以减少软件缺陷从开发人员返回的数量。 提高软件缺陷修复的速度，使每一个小组能够有效的工作。 提高测试人员的信任度，可以得到开发人员对清晰的软件缺陷描述有效的响应。 加强开发人员，测试人员和管理人员的协同工作，让他们可以更好的工作。 在多年实践的基础上，我们积累了较多的软件缺陷的有效描述规则，主要是： 1. 单一准确 每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常常会导致缺陷部分被注意和修复，不能得到彻底的修正。 2. 可以再现 提供缺陷的精确操作步骤，使开发人员容易看懂，可以自己再现这个缺陷，通常情况下，开发人员只有再现了缺陷，才能正确地修复缺陷。 3. 完整统一 提供完整、前后统一的软件缺陷的步骤和信息，例如：图片信息，Log文件等。 4. 短小简练
通过使用关键词，可以使软件缺陷的标题的描述短小简练，又能准确解释产生缺陷的现象。如“主页的导航栏在低分辨率下显示不整齐”中“主页”、“导航栏”、“分辨率”等是关键词。 5. 特定条件 许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件(如特定的操作系统、浏览器或某种设置等)，能够提供帮助开发人员找到原因的线索。如“搜索功能在没有找到结果返回时跳转页面不对”。 6. 补充完善 从发现Bug那一刻起，测试人员的责任就是保证它被正确的报告，并且得到应有的重视，继续监视其修复的全过程。 7. 不做评价 在软件缺陷描述不要带有个人观点，对开发人员进行评价。软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。 即：1、单一准确 2、可以再现（要求软件缺陷具有精确的步骤） 3、完整统一 4、短小简练 5、特定条件 6、补充完整 7、不做评价 摘自：软件测试方法和技术作者：朱少民
BUG等级划分方法 一、四级的划分方式： 1.BUG等级划分建议： 目前project上的BUG严重程度分为五个等级，按照CMM5中定义的规范，BUG严重等级可分为3-5个等级，由于我们公司的CMM水平还处于初级阶段，将BUG等级划分过细不符合我们当前的CMM水平，同时也不利于测试人员对BUG等级的精确划分。根据我们公司的情况，同时参照其它中小公司的等级划分标准，建议将BUG等级划分四个等级，分别为致命、严重、一般、提示。 ● 致命(可对应目前BUG体系中的“非常严重”)： 致命性问题主要为：系统无法执行、崩溃或严重资源不足、应用模块无法启动或异常退出、无法测试、造成系统不稳定。 具体基本上可分为： ○严重花屏 ○内存泄漏 ○用户数据丢失或破坏 ○系统崩溃/死机/冻结 ○模块无法启动或异常退出 ○严重的数值计算错误 ○功能设计与需求严重不符 ○其它导致无法测试的错误 ● 严重(可对应目前BUG体系中的“严重”) 严重性问题主要为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。 具体基本上可分为： ○功能未实现 ○功能错误
○系统刷新错误 ○语音或数据通讯错误 ○轻微的数值计算错误 ○系统所提供的功能或服务受明显的影响 ● 一般(可对应于目前BUG体系中的“普通”) 一般性问题主要为：界面、性能缺陷 具体基本上可分为： ○操作界面错误(包括数据窗口内列名定义、含义是否一致) ○边界条件下错误 ○提示信息错误(包括未给出信息、信息提示错误等) ○长时间操作无进度提示 ○系统未优化(性能问题) ○光标跳转设置不好，鼠标(光标)定位错误 ● 提示(可对应于目前BUG体系中的“轻微及建议”) 提示性问题主要为：易用性及建议性问题 具体基本上可分为： ○ 界面格式等不规范 ○ 辅助说明描述不清楚 ○ 操作时未给用户提示 ○ 可输入区域和只读区域没有明显的区分标志 ○ 个别不影响产品理解的错别字
软件缺陷级别定义 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类——测试建议（非缺陷）