软件缺陷描述规范
软件缺陷描述规范
软件缺陷描述规*一、缺陷基本定义软件缺陷（Software Defect）：软件缺陷是对软件产品预期属性的偏离现象。
它包括检测缺陷和残留缺陷。
缺陷的优先性，分为5级，参考下面的方法确定：1)最高优先级(Blocker)，例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷，或用户重点关注的问题,缺陷导致系统几乎不能使用或者测试不能继续，需立即修复。
2)较高优先级(Critical)，例如，影响软件功能和性能的一般缺陷, 严重影响测试，需要优先考虑；3)一般优先级(Major)，例如，本地化软件的*些字符没有翻译或者翻译不准确的缺陷,需要正常排队等待修复；4)低优先级(Minor)，例如，对软件的质量影响非常轻微或出现几率很低的缺陷,可以在开发人员有时间的时候再被纠正；5)最低优先级(Trival),例如，属于优化，可以不做修改的问题或暂时无法修复但影响不大的问题。
二、缺陷描述软件缺陷的描述是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发工程师交流的最好机会。
一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。
否则，它就会使信息含糊不清，可能会误导开发人员,因此，正确评估缺陷的严重程度和优先级，是项目组全体人员交流的基础。
缺陷描述的原则：有效的缺陷描述有以下几个原则：➢可以重现：在缺陷的详细描述中提供精确的操作步骤，可以让发人员容易看懂；➢定位准确：缺陷描述准确，不会引起误解和歧义；➢描述清晰：对操作步骤的描述清晰，易于理解，应用客观的书面语，避免使用口语；➢完整统一：提供完整、前后统一的软件缺陷的步骤和信息，按照一致的格式书写全部缺陷报告，有关缺陷的格式参见"缺陷的格式”；➢短小简练：通过使用关键词，可以使问题摘要的描述短小简练，又能准确解释产生缺陷的现象。
如"在新建任务窗口中，选择直接下达，负责人收不到即时消息”中"新建任务窗口”、"直接下达”、"即时消息”等是关键词；➢特定条件：许多软件功能在通常情况下没有问题，而是在*种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或*种设置等），能够提供帮助开发人员找到原因的线索。
缺陷等级划分规定
缺陷等级划分规定１．缺陷等级划分规范１．１Bug等级种类及定义:Bug等级可分为:致命,严重,一般的,微小的四种.致命（critical）：致命的错误，造成系统或应用程序崩溃（crash）、死机、系统悬挂、或造成数据丢失、主要功能组完全丧失严重（major）：严重错误，指功能或者特性（feature）没有实现，主要功能丧失，导致严重的问题，或致命的错误声明一般的（normal）：不太严重的错误，这样的缺陷虽然不影响系统的基本使用，但没有很好的实现功能，没有达到预期的效果。
如次要功能丧失，提示信息不太正确，或用户界面太差，操作时间长等微小的（minor）：一些小问题，对功能几乎没有影响，产品及属性仍可使用，如有个别错别字、文字排列不整齐等１．２等级划分步骤:1) 功能方面结合”缺陷发生率”(Exposure Risk)和”影响强度”(Impact Intensity)对Bug进行等级划分.”缺陷发生率”是指在运用产品过程中,出现某个缺陷的频率, 可分为四种:不可避免,经常,偶尔,很少.不可避免(Unaviodable):只要运行系统或应用程序,或者使用软件主要功能,该缺陷就能出现. 经常(Frequent):在使用软件过程中,需要通过几步操作出现,或者是一些不常用的非主要功能的缺陷,或者出现该缺陷的频率在30-70%的.偶尔(Occasional):缺陷出现的前提是通过多次操作或多个步骤,或者缺陷出现的概率在2%-30%.很少(Rare):低频率操作,或者出现的前提是通过N次操作或N个步骤,或者缺陷出现的概率低于2%的.“缺陷影响强度”是指在运用产品过程中,某个缺陷影响产品使用的程度,可分为三种:灾难性,障碍性,干扰性.灾难性(Disastrous):测试执行直接导致系统死机、蓝屏、挂起或是程序非法退出；系统的主要功能或需求没有实现；关键性能指标达不到要求；障碍性(Obstruction):系统的次要功能点或需求点没有实现；数据丢失或损坏。
软件缺陷分类标准
软件缺陷分类标准
软件缺陷可以根据不同的标准进行分类。
以下是一些常见的软件缺陷分类标准：
1. 功能性缺陷：指软件功能无法正常工作或不符合预期要求的问题，如某个功能无法启动、不能正确计算结果等。
2. 易用性缺陷：指软件在用户界面方面存在问题，使用户难以理解、操作或导航。
例如，界面布局混乱、操作流程不直观等。
3. 性能缺陷：指软件在执行过程中出现的性能问题，如响应时间过长、运行速度慢等。
4. 兼容性缺陷：指软件与其他系统、平台或设备之间的兼容性问题，如不能在特定操作系统上运行、与其他软件不兼容等。
5. 安全性缺陷：指软件存在的安全风险和漏洞，可能被黑客攻击或滥用。
例如，密码泄露、权限控制不完善等。
6. 可靠性缺陷：指软件在长时间运行或高负载情况下出现的故障、崩溃或数据丢失等问题。
7. 可维护性缺陷：指软件代码或结构设计方面存在的问题，使软件难以维护、扩展或修改。
例如，代码冗余、缺乏注释或文档等。
8. 其他缺陷分类标准：根据不同的软件类型和行业特点，还可以使用其他分类标准，如移动应用程序中的交互性缺陷、电子商务网站中的支付缺陷等。
对于软件开发团队来说，合理分类和标记缺陷是非常重要的，可以帮助他们更好地理解和解决问题，提高软件质量和用户满意度。
软件测试缺陷的定义、产生原因、缺陷报告格式、缺陷报告
软件测试缺陷的定义、产⽣原因、缺陷报告格式、缺陷报告软件缺陷的定义错误静态存在于说明⽂档中的表述或编码错误缺陷存在于代码中或硬件系统中的错误BUG被测对象实际表现与⽤户显性需求或隐性需求中的差异功能实现错误功能实现遗漏功能实现多余功能实现不好失效因缺陷激发后导致功能的异常，⽆法使⽤的现象（动态的，不⼀定会发⽣）缺陷产⽣的原因1. 需求表达理解、解码过程中⼀起的错误2. 系统设计架构引起的错误3. 开发过程中缺乏有效的沟通及监督4. 程序员编码过程产⽣的错误5. 软件开发⼯具本⾝的问题6. 软件需求、复杂度越来越⾼7. 与⽤户需求不符合，即使本⾝不存在某种意义上的错误缺陷的报告的书写格式缺陷ID：⽤来唯⼀表⽰缺陷的字段，⼀般使⽤阿拉伯数字，缺陷ID不可重复，并且不可服⽤概要描述：概括描述缺陷的表象或存在的形式，便于开发⼈员快速推测缺陷的产⽣原因发现⼈：缺陷的发现⼈员⼀般为测试⼯程师，也有可能是项⽬的开发⼈员，如开发⼈员、项⽬经理、维护⼈员，甚⾄是客户发现时间：缺陷发现的时间修复时间：缺陷修复的时间所属版本：发现缺陷的版本，便于后期统计不同版本之间发现的缺陷数量，以及确定测试版本的发布风险所属模块：缺陷所在的功能或业务模块，便于后期统计每个功能或业务模块的缺陷分布情况，从⽽利于回归测试投⼊确定或研发资源分配缺陷状态缺陷所存在的状态，⼀般分为6种new：缺陷尚未进⼊缺陷管理流程时，定义为new，如新发现或新提交的bugopen：经过确认后确认是BUG，缺陷正式进⼊管理流程，fix：开发⼈员却认为BUG，并且做了修复活动，ciose：缺陷经过校验，确认已被修复或⽆需处理reject：开发⼈员需对open状态的BUG进⾏判断，如果确认是缺陷，则需要进⾏修复活动，如果因需求变化，设计变化等原因导致缺陷已经不存在，则可reject次缺陷reopen：当以fix或close的缺陷未能成功修复或再次发⽣时再次打开缺陷严重度缺陷引发后果的严重程度low：缺陷导致的后果不是很严重，⼀般⽽⾔，仅是使⽤户感觉使⽤不⽅便、界⾯不美观等感受medium：⼀般的错别字，字体错误，显⽰错误，⼦功能实现错误或冗余high：某个具体功能不能正常使⽤，如查询功能错误、排序功能错误等very high：导致⼤⾯积功能⽆法使⽤urgent：⼤⾯积功能不能使⽤，终⽌性错误、初始化错误缺陷的优先级：有开发⼈员确认，决定缺陷修复的先后时间详细描述：对概要描述的补充，说明缺陷产⽣的步骤，测试数据、系统的截图等等下⼀步处理⼈：缺陷接下来由谁处理缺陷的管理⾓⾊定义定义管理流程中所涉及到的⾓⾊、主要职责、⼯作内容、范围等等如测试⼯程师、测试经理、开发⼯程师、开发经理、项⽬经理流程定义定义流程中所有⾓⾊应遵守的规则1. 测试⼯程师发现并提交BUG2. 测试经理进⾏缺陷的过滤1. 缺陷描述是否正确2. 是否是因为对需求不理解⽽造成的误提交3. 描述中是否带有个⼈感情⾊彩的词语4. 缺陷定义级别是否定义合理3.测试经理将缺陷指派给开发经理4.开发经理将缺陷指派给响应的开发⼈员5.开发⼯程师确认缺陷，如果是缺陷，则fix，如果不是缺陷，则reject并给出理由6.如果缺陷状态为fix，则测试⼯程师进⾏确认活动，如果成功，则将缺陷状态改为close，如果没有fix，则将状态改为reopen7.如果开发⼈员认为不是缺陷，测试⼈员应说明认为是缺陷的原因，如果意见不能⼀致，则由项⽬经理协调处理⼯具应⽤采⽤哪种缺陷管理⼯具，如开源（Bugzilla、jira、matins、Excel等）还是商业（QC/ALM、禅道等）模型选择ODC四象限Gompertz。
软件缺陷报告
软件缺陷报告软件缺陷报告报告编号：F2022-001报告日期：2022年10月1日1. 缺陷概述在进行软件版本1.0的测试过程中，发现了以下缺陷问题：- 缺陷名称：用户界面显示异常- 缺陷编号：D001- 缺陷等级：一般- 缺陷描述：在使用软件时，发现在某些分辨率下，用户界面显示异常，图标和文本显示错位，并且影响了用户的正常操作。
- 缺陷重现步骤：1. 在系统分辨率设置为1280x720的情况下启动软件。
2. 进入主界面，观察图标和文本的显示情况。
2. 缺陷影响范围该缺陷主要影响使用分辨率为1280x720的用户，导致用户界面显示异常，影响用户的正常操作。
3. 缺陷原因分析经过初步分析，该缺陷可能是由于软件界面的布局在不同分辨率下没有进行适配造成的。
在低分辨率下，元素的位置计算错误，导致显示异常。
4. 缺陷修复建议为了修复该缺陷问题，建议采取以下措施：- 在软件开发的初期，进行分辨率适配的设计，在不同分辨率下保持界面元素的位置稳定。
- 在软件发布前，进行全面的兼容性测试，确保在不同分辨率下都能正常显示。
5. 缺陷修复计划为了修复该缺陷问题，我们制定了以下修复计划：- 预计修复时间：2022年10月10日- 修复方式：开发团队将对软件界面进行适配调整，修复图标和文本错位的问题。
- 修复验收标准：修复后的软件在分辨率1280x720下应能正常显示，图标和文本位置稳定。
6. 缺陷验证计划为了验证修复效果，我们将进行以下验证计划：- 验证时间：2022年10月11日至2022年10月15日- 验证步骤：1. 设置系统分辨率为1280x720。
2. 安装修复后的软件版本。
3. 进入主界面，观察图标和文本的显示情况。
4. 与修复前的软件对比，确认是否修复成功。
7. 其他建议为了提高软件的稳定性和用户体验，建议开发团队在后续版本迭代中加强对不同分辨率的兼容性测试，避免类似问题的再次出现。
本缺陷报告将在修复后进行关闭，并确认修复效果。
软件缺陷分类标准(最新)
软件缺陷分类标准修订历史记录目录1. 引言 (3)1.1 编写目的 (3)1.2 定义与缩写 (3)1.3 参考资料 (4)2. 软件缺陷分类标准 (4)2.1 问题类型 (4)2.2 缺陷属性 (4)2.3 缺陷类型 (4)2.4 缺陷严重程度 (6)2.5 缺陷优先级 (8)2.6 缺陷状态 (8)2.7 缺陷来源、起源 (9)2.8 缺陷根源 (9)2.9 缺陷产生可能性 (10)1.引言1.1编写目的制定本标准的目的是为软件测试提供确信分类的标准。
本文档说明了问题类型、缺陷属性、确缺陷类型、缺陷严重级别、缺陷优先级、缺陷状态、缺陷修改次数、缺陷原因。
其预期的读者是测试人员、开发人员、开发经理。
1.2定义与缩写1.3参考资料表格1-2 参考资料列表2.软件缺陷分类标准2.1问题类型表格2-1 问题类型表格2.2缺陷属性软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷优先级、缺陷状态、缺2.3缺陷类型2.4缺陷严重程度缺陷严重程度:指因缺陷引起的鼓掌对软件产品的影响程度。
2.5缺陷优先级2.6缺陷状态2.7缺陷来源、起源缺陷来源：缺陷引起的故障或事件第一次被检测的阶段，有需求说明书、设计文档、系统集成接口、数据流（库）、程序代码。
缺陷起源：在团建生命周期中软件缺陷占的比例：需求和构架设计阶段占54%、设计阶2.8缺陷根源缺陷根源：测试策略，过程、工具和方法，团队\人，缺乏组织和通讯，硬件，软件，工作环境等造成上述错误的根本因素，以寻求开发、测试人员可改进的地方。
2.9缺陷产生可能性表2-9 缺陷产生可能性。
软件缺陷管理制度
软件缺陷管理制度软件项目测试组修订历史记录目录软件缺陷管理制度····························································································错误!未定义书签。
修订历史记录····································································································错误!未定义书签。
缺陷管理工具CQ使用规范
11.1 缺陷记录信息对缺陷的描述包含以下的内容：展现层错误、未实现、未容错 控制层错误、未实现、未容错 业务层错误、未实现、未容错 数据层错误、未实现、未容错功能性1 惟一的缺陷 ID ，可以根据该 ID 追踪缺陷 缺陷的状态，分为 11 种(见 3.2.8 节) 对缺陷简单描述缺陷所属类型(见 3.2.1 节)缺陷的严重程度， 普通分为“致命”、 “严重”、 “一 般”、“轻微”和“其它”五种(见 3.2.2 节) 引入缺陷的开辟阶段(见 3.2.3 节) 发现缺陷时所属的阶段(见 3.2.4 节) 重现缺陷的步骤对缺陷的详细描述； 因为对缺陷描述的详细程度直接影 响开辟人员对缺陷的修改，描述应该尽可能详细 发现缺陷时产品的内部版本号发布给客户使用的版本号。
在缺陷提交后，由项目经理/开辟经理指定修复缺陷的 责任人项目经理/开辟经理指定修复缺陷的截止日期缺陷的紧急程度， 修复的优先级， 从 1－3，1 是优先级 最高的等级， 3 是优先级最低的等级(见 3.2.6 节) 对修复内容(将什么改成什么)的描述，如果对代码进行 了修改，要求在此处体现出修改排除缺陷的解决方案类型(见 3.2.7 节) 修复缺陷时所属的阶段(见 3.2.5 节) 估计修复该缺陷所需的工时 修复该缺陷实际使用的工时缺陷关闭后，项目经理/开辟经理评估修复缺陷所花的 工作量和修复缺陷的工作质量项目经理/开辟经理对缺陷修复工作量和工作质量的评 估赋予必要的解释说明缺陷 ID 缺陷状态 标题 缺陷类型严重程度缺陷来源 发现阶段 重现步骤现象描述内部版本号外部(正式)版本号修复责任人修复期限优先级修复描述解决方案 排除阶段 估计工时 实际工时 工作分数 工作量系数 工作质量系数 工作分数评估描述功能实现不完整 功能实现错误 数据不一致数据不完整 数据重复信息填充错误 业务流程操作繁琐 界面布局不合理 操作不习惯 tab 键顺序不合理尽量保证一屏能显示，横向滚动条尽量避免，违反此规范的缺陷提示信息不充分，或者不友好，甚至错误提示 按钮摆放位置不符合正常习惯设计图标，展示不符合常规，给人误解 布局设计不合理(静态页面显示) 风格不统一图片、色调不符合业务系统要求 系统的故障恢复艰难可维护性系统的升级操作艰难 系统的响应时间差 并发处理性能差 过负荷处理处理机制差致命是指系统任何一个主要功能彻底丧失，或者用户数据受到破坏，造成 系统崩溃、悬挂、死机或者危机人身安全。
软件缺陷等级标准
软件缺陷等级标准按照CMM5中定义的规范，BUG一般分致命，严重，一般和提示。
致命是严重影响产品的BUG，比如操作手册的错误，需求的错误等。
严重是产品中使功能无法实现的BUG，比如某个功能无法运行，GUI长时间僵死没有响应。
一般是某个BUG的发生，只影响了一个功能，而其他功能可以正常运行。
提示就是一些GUI的问题，或者友好性的问题。
更为详细的划分如下:A类—严重错误，包括以下各种错误：1．由于程序所引起的死机,非法退出2．死循环3．数据库发生死锁4．因错误操作导致的程序中断5．功能错误6．与数据库连接错误7．数据通讯错误-----------------------------------------------------------B类—较严重错误，包括以下各种错误：1．程序错误2．程序接口错误3．数据库的表、业务规则、缺省值未加完整性等约束条件-----------------------------------------------------------C类—一般性错误，包括以下各种错误：1．操作界面错误（包括数据窗口内列名定义、含义是否一致）2．打印内容、格式错误3．简单的输入限制未放在前台进行控制4．删除操作未给出提示5．数据库表中有过多的空字段-----------------------------------------------------------D类—较小错误，包括以下各种错误：1．界面不规范2．辅助说明描述不清楚3．输入输出不规范4．长操作未给用户提示5．提示窗口文字未采用行业术语6．可输入区域和只读区域没有明显的区分标志 E类—测试建议。
软件测试缺陷管理规范
目录1 背景 (2)1.1 推行目的 (2)1.2 适用范围 (2)1.3 术语定义 (2)2 缺陷分类标准 (2)2.1 缺陷类型 (2)2.2 缺陷严重程度 (3)2.3 缺陷优先级 (3)2.4 缺陷状态 (3)2.5 缺陷来源 (4)2.6 缺陷复现率 (4)3 缺陷提交规范 (4)3.1 缺陷所属 (4)3.2 缺陷标题 (5)3.3 缺陷内容 (5)3.4 缺陷指派 (5)3.5 缺陷类型 (5)3.6 缺陷严重程度和优先级 (6)3.7 缺陷来源 (6)4 缺陷管理规范 (6)4.1 缺陷所属管理 (6)4.2 缺陷时效化 (6)4.3 未关闭缺陷的处理 (6)4.4 非系统测试缺陷的处理 (7)1 背景1.1 推行目的缺陷是产品与规定要求不相符的部分，会存在于软件产品的整个生命周期中，本文规范软件测试过程中的出现的缺陷，通过测试活动及早发现软件系统中的缺陷，并确保缺陷被有效标识、跟踪、和修改，保证软件系统能够达到要求的质量。
1.2 适用范围本文档适用于公司项目研发以及项目运行过程中的缺陷管理。
1.3 术语定义2 缺陷分类标准2.1 缺陷类型2.2 缺陷严重程度2.3 缺陷优先级2.4 缺陷状态2.5 缺陷来源2.6 缺陷复现率3 缺陷提交规范3.1 缺陷所属在提交缺陷时，需要严格按照缺陷所属的产品、项目、版本、模块进行填写，不能不进行填写，此举是为了在后续进行总结时进行缺陷分析。
3.2 缺陷标题注意：在提交一条缺陷前，应检查缺陷库是否已经存在此缺陷，避免重复提交。
缺陷标题应该尽量简洁明了，以最少的文字描述出缺陷结果，标题应该避免长篇大论、文字过多，具体复现步骤和补充说明可以放在缺陷内容描述中。
必要时缺陷标题中可以加入约定好的标签信息，如模块、类别等。
以下为缺陷标题举例：3.3 缺陷内容缺陷内容主要包括操作步骤、实际结果、预期结果。
操作步骤：按照分步的方式描述复现缺陷的操作以及数据、环境等信息。
软件测试-BUG规范
BUG 规范一、BUG编写规范➢BUG的summary描述需简明扼要，例如：“上传文档：输入超长字符，系统出黄页！”（应尽量少出现不肯定的词语，如：是否）。
➢由于输入特殊字符而出现的BUG，BUG的Description或summary中应写明是哪些字符。
➢相同的BUG出现在不同的页面，应在summary中写明哪些页面也出现此问题，不应书写多条BUG（若书写为多条BUG则在前面打上记号如“--”，方便删除）。
➢若不能定位BUG出现的原因，应写明操作时所使用的帐号与操作步骤。
➢在第一次执行测试时尽量写出所有发现问题及建议。
➢若BUG描述不能说明清晰应夹带附件（有附件也应夹带附件），并在BUG的Description中加上文字描述（如：附件１：导出EXCEL前，附件2：导出EXCEL后）。
➢若在测试过程中，不能及时记住BUG的操作步骤，应在记起时将BUG书写完整，并致电告知开发人员使之进行处理。
➢在测试过程中，若遇到严重问题应该致电告知开发人员使之尽早进行处理。
➢对于所发现的问题不太清楚是不是BUG，可打电话与开发人员确认，或者询问测试组负责人或测试跟进人员。
➢在选择BUG的Severity(严重级别)时，应注意根据BUG的严重程度来确定，理清建议与BUG的意义，（建议：可修复也可不修复，修复了会更好，不修复也可以）不应将建议写成BUG，或将BUG写成建议。
——BUG严重级别定义详见附录二、验证BUG➢在验证BUG时，R&D Comments应注明验证时的实际输出结果，方便日后跟踪及统计。
➢在验证BUG时，应查看History，查明BUG修改的时间，避免将刚Fixed的BUG 重新Reopen。
➢在验证BUG时，若原有的BUG未修复，则应该Reopen；若原有的BUG所描述的现象已不存在，则Closed；若由于对原有BUG的修改而引发新的BUG，则应该Open记为新的BUG，不应将原有的BUG再Reopen。
软件缺陷(bug)的概述及书写规范
软件缺陷（bug）的概述及书写规范1、软件缺陷（bug）的定义IEEE（1983）729软件缺陷一个标准的定义：从产品内部看：软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题。
从产品外部看：软件缺陷是系统所需要实现的某种功能的失效或违背。
2、软件缺陷（bug）满足的5个规则至少满足以下5个规则之一，才称为发生一个软件缺陷：–软件未实现产品说明书要求的功能–软件出现了产品说明书指明不应该出现的错误–软件实现了产品说明书未提到的功能–软件未实现产品说明书虽未明确提及但应该实现的目标–软件难以理解，不易使用，运行缓慢或者----最终用户会认为不好3、软件缺陷（bug）生命周期测试人员开发人员测试人员测试人员bug bug为回归测试Y4、软件缺陷（bug）状态Unfixed测试人员新建一个bug，将bug的状态定义为unfixed，开发人员看到的最新的bug状态都是unfixed。
To be fixed开发经理将新建的bug指派给自己或者其他开发人员，将bug的状态置为to be fixed。
Pending由于该bug实现比较难，或者无法修改，开发人员会将bug状态置为pending。
To be verified开发人员已修复bug，将该bug指派给其他开发人员，进行内部测试，此时bug状态为to be verified。
Verified开发人员进行内部测试确认该bug已修复，然后将该bug指派给测试经理，bug状态置为verified。
Integrated测试经理将已修复bug指派给bug提交者，做回归测试，此时将bug状态置为integrated。
Fixed测试人员进行回归测试，确认bug已修复，将bug状态置为fixed。
Close该bug不是bug，或者描述有误，开发经理关闭该bug，此时bug状态为close。
5、软件缺陷（bug）的优先级High（高优先级）–严重花屏–内存泄露–用户数据丢失或破坏–系统崩溃/死机/冻结–模块无法启动或异常退出–严重的数值计算错误–功能设计与需求严重不符–其他导致无法测试的错误Mid（中优先级）–功能问题–系统刷新错误–语音或数据通讯错误–轻微的数值计算错误–界面操作错误–边界条件下错误–系统运行缓慢、等待时间过长–图片按钮显示错误Low（低优先级）–界面格式不规范–操作时未给用户提示–可输入区域和只读区域没有明显的区分标志–个别不影响产品理解的错别字–文字排列不整齐等一些小问题–建议性问题6、软件缺陷报告（Bug）的书写规范Bug描述的目的是尽最大可能帮助开发人员解决bug，所以bug描述要尽可能丰富但切中要害，使开发人员能迅速定位bug产生的原因。
软件缺陷分类标准
草稿终稿公开秘密机密绝密受控不受控文档修改记录*S – START A - ADDED M - MODIFIED D - DELETED目录1 引言 ................................................................... 错误!未定义书签。
1.1 编写目的........................................................... 错误!未定义书签。
1.2 定义与缩写......................................................... 错误!未定义书签。
1.3 参考资料........................................................... 错误!未定义书签。
2 软件缺陷分类标准 ....................................................... 错误!未定义书签。
2.1 缺陷属性........................................................... 错误!未定义书签。
2.2 缺陷类型........................................................... 错误!未定义书签。
2.3 缺陷严重限度....................................................... 错误!未定义书签。
2.4 缺陷优先级......................................................... 错误!未定义书签。
2.5 缺陷状态........................................................... 错误!未定义书签。
软件缺陷管理制度
软件缺陷管理制度软件项目测试组修订历史记录目录软件缺陷管理制度····························································································错误!未定义书签。
修订历史记录····································································································错误!未定义书签。
软件缺陷分类标准(精)
软件缺陷分类标准 Version 1.1分类 :<标准 >使用部门 :<测试人员、项目组 >目录1. 简介 ........................................................................................................................................... ..................... 1 1.1目的 ........................................................................................................................................... ............. 1 1.2范围 ........................................................................................................................................... ............. 1 1.3文档结构 ........................................................................................................................................... ..... 1 1.4词汇表 ........................................................................................................................................... (1)2. 软件缺陷分类标准 (1)2.1缺陷属性 ........................................................................................................................................... ..... 1 2.2缺陷类型(TYPE (2)2.3缺陷严重程度(SEVERITY ................................................................................................................. 2 2.3.1软件测试错误严重程度 ................................................................................................................ 2 2.3.2同行评审错误严重程度 . (2)2.4缺陷优先级(PRIORITY ..................................................................................................................... 3 2.5缺陷状态(STATUS (3)2.6缺陷起源(ORIGIN (3)2.7缺陷来源(SOURCE (3)2.8缺陷根源(R OOT CAUSE (3)2.9缺陷分类适用范围 (4)3. 参考文献 ........................................................................................................................................... . (4)4. 附录 ........................................................................................................................................... (4)软件缺陷分类标准1. 简介1.1 目的本文档的目的是为同行评审、软件测试提供缺陷分类的标准。
软件缺陷管理规范
本文档定义了软件缺陷管理流程和相关规则，确保软件缺陷管理的系统性和规范性，以保证项目研发质量。
合用于部门项目研发过程的缺陷管理，对各阶段的缺陷管理过程进行指导和规范。
3.1 术语缺陷 (Defect)：存在于软件之中偏差，可被激活，以静态形式存在于软件内部。
Bug：缺陷一种表现形态，系统或者程序存在的任何一种破坏正常运转能力的问题。
3.2 缺陷定义(1)软件未达到需求规格说明书的功能；(2)软件浮现了需求规格说明书指明不会浮现的错误；(3)软件功能超出需求规格说明书的范围；(4)软件未达到需求规格说明书未指出但应达到的目标；(5)测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。
4.1 缺陷生命周期图4.2 缺陷状态说明缺陷的初始状态，或者重新被激活的状态。
激活状态的缺陷可以通过编辑来修改缺陷内容，并指派给合适的工程师处理。
缺陷被解决之后的状态。
激活状态的缺陷经过成功修复以后，由开辟工程师操作为解决状态，系统将自动指派回创建者。
解决状态的缺陷在验证通过后关闭，缺陷状态变为关闭，生命周期结束。
如果验证未修复或者新版本又发生，则重新激活，缺陷状态激活状态解决状态关闭状态重新变为激活。
5.1 正常处理过程(1)创建问题在测试管理系统中，所实用户都可以创建新问题，包括需求问题和软件缺陷等。
创建问题时，需要描述清晰，并选择正确的选项，详细请参考5.4和5.5。
(2)指派问题创建问题时，创建者通常要指派给该项目开辟负责人，再由其指派任务，或者直接指派给相应模块的开辟工程师。
如果指派人是错误的，或者需要他人确认或者匡助，则可以重新指派给合适的工程师，写上相关备注。
(3)确认问题通常开辟工程师收到新问题后，需要分析和确认此问题是否为Bug。
如果是Bug，则选择“确认状态”；如果认为非Bug，则注明原因并指派回创建者。
当创建者收到确认指派时，需要进行及时确认。
如果允许为非bug，则及时关闭它；如果不允许，则需要注明理由并指派回相关工程师。
Bug的书写规范
点评: 这里是用表物理名查询，即英文名，不是中文名
•
外部原因(280)
BUG #280::【基本配置】-【指标分组】，由于某些组元代码相同（几点组元代码等于父组元代码），导致删除失 败；
• • • • • • • • • • • •
[步骤] 1.点击【基本配置】-【指标分组】； 2.点击某个分组名称； 3.选择一个组元名称，右键选择“删除节点”； 4.弹出框点击【确定】按钮； . [结果] 无法删除，提示“删除失败” . [期望] 删除成功 .
缺陷报告应避免：1.设计如此 2.重复Bug 3.外部原因 4.无法重现 5.不予解决
173
280 163 19
•
• •
不予解决(19)
BUG #19::【配置作业规则】：配置作业任务中按照"对应表或字段"查询功能未实现
Hale Waihona Puke • • • • • • •
[步骤] 1.打开"质检系统"； 2.点击"系统主菜单"下的"作业管理"； 3.选择作业"Job"的【配置作业规则】按钮； 4.在"第一责任人"中输入"testUser"； 5.在"规则名称"中输入"sj"； 6.在"对应表或字段"中输入"中诚信指数代码对照表"； 7.按Tab键 8.点击【Enter】键； . [结果] 查询结果为空 . [期望] 查询出第一责任人为"testUser"、规则名称包含"sj"、规则对应表是"中诚信指数代码对照表"的规则信息 .
Bug的检查内容
软件开发缺陷管理流程规范
Bug登记流程规范一、规范目标BUG是软件过程中的重要环节，为了提高工作效率,降低沟通及管理成本，引入禅道用于BUG管理。
良好的BUＧ管理也是团队做好知识积累的基础.特制定本规范，以达到以下目标：1、 为BUG流转的整个过程提供指导，每个过程都描述操作的意义、具体方法、要求及关键点。
2、 为版本发布计划提供保证，通过理顺测试流程及特殊情况的处理的方法,为不同情况下发版提供应对方法。
二、执行效果本规范启用后公司所有拥有BUG登记权限者能够根据规范顺利完成BＵG登记流转工作，不需要过多的额外指导.三、ＢＵG的定义在登记BＵG前,根据此定义判断需要提交的问题到底是BUＧ，还是需求。
BUG:系统中已有功能在使用不能完全正常的使用。
需求：系统目前没有的功能,不论大小.建议:用户根据自己的业务需要对系统提出的优化要求，会同时包含BＵG和需求两类信息。
其中BUG 类的如：提示信息看不懂、信息描述不清、错别字、界面缺少按钮、所有的用户看不懂的异常报错;其中需求类的如：功能优化、界面优化、性能优化、新增功能；四、BUＧ登记前准备工作(必须)1、查看已有项目数据进入项目分页中，如下图：点击图中“倒三角"按钮,在下拉列表中查看是否有你要登记BUG所属的项目?如有，可跳过这个准备工作。
如无，则点击“+添加项目"按钮，创建一个你需要的项目(不要添加重复的项目信息）２、项目新增使用项目管理中的“添加项目”按钮，进行项目添加A:填写项目名称，如项目属于XＸX产品的个性化定制商品,则命名规则为:所属产品名称—个性化 商品名称；项目代号为项目简称。
B:如有明确的结束日期，则按实际情况选择，如无则选择“一年”。
C：目前项目均属于【运价系统】这个产品的个性化商品定制，关联产品必须要选择“运价系统”否则无法给项目添加需求。
保存后,弹出设置界面(此操作必须执行,否则新登记的BＵG或需求数据都无法指派给相应人员)选择“设置团队”点击“团队管理”因复制团队功能权限问题暂时不能直接使用，请手动选择上图中所有“研发”及“测试”到团队 中,保存数据。
软件缺陷相关规范
软件缺陷相关规范一、软件缺陷的定义只要软件出现的问题符合下列5种情况的任何一种，就叫做软件缺陷：1）软件未达到产品说明书中标明的功能；2）软件出现了产品说明书中指明的不会出现的错误；3）软件功能超出了产品说明书指明的范围；4）软件未达到产品说明书虽未指出但应达到的目标；5）软件测试人员认为软件难以理解、不易使用、运行速度慢，或最终用户认为不好使用。
二、软件缺陷的严重性和优先级分类测试人员在报告软件缺陷时要对软件缺陷进行分类，以简明扼要的方式指出其影响，以及修改的优先次序。
给软件缺陷与错误划分严重性和优先级的通用原则是：1）严重性表示软件缺陷所造成的危害的恶劣程度；2）优先级表示修复缺陷的重要程度与次序。
按照严重性级别可分为：1）崩溃性：系统崩溃、数据丢失、数据毁坏，该类问题会导致软件无法正确运行，整体功能受到影响；2）严重性：重要功能无法实现且不存在其他替代途径实现该功能，或者操作性错误、错误结果、遗漏功能；3）一般性：功能没有按照预定方法实现，但存在其他合理途径实现该功能；4）提示性：界面不美观、文字不易懂、错别字、使操作者使用不方便等问题，但不影响功能的实现。
按照优先级可分为：1）最高优先级：立即修复，停止进一步测试；2）次高优先级：在产品发布之前必须修复；3）中等优先级：如果时间允许应该修复；4）最低等优先级：可能会修复，但是也能发布。
一般的严重性和优先级的划分用数字1~4表示，有的小数字表示的级别最高，而有的用大数字表示级别高。
同样的错误和缺陷，在不同的开发过程或软件的不同部分，严重性和优先级将有所变化，要具体情况具体分析。
三、软件缺陷跟踪管理1、缺陷跟踪管理为了正确地跟踪每个软件缺陷的处理过程，通常将软件测试发现的每个缺陷作为一条记录输入指定的缺陷跟踪管理系统。
作为一个缺陷跟踪管理系统，需要正确记录缺陷信息和缺陷处理信息的全部内容。
(1）Bug记录信息主要包括以下几项内容：测试软件名称；测试版本号；测试人名称；测试事件；测试软件和硬件配置环境；发现软件缺陷的类型；缺陷的严重等级；详细步骤；必要的附图；测试注释。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件缺陷描述规范一、缺陷基本定义软件缺陷（Software Defect）：软件缺陷是对软件产品预期属性的偏离现象。
它包括检测缺陷和残留缺陷。
缺陷的优先性，分为5级，参考下面的方法确定：1)最高优先级(Blocker)，例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷，或用户重点关注的问题,缺陷导致系统几乎不能使用或者测试不能继续，需立即修复。
2)较高优先级(Critical)，例如，影响软件功能和性能的一般缺陷, 严重影响测试，需要优先考虑；3)一般优先级(Major)，例如，本地化软件的某些字符没有翻译或者翻译不准确的缺陷,需要正常排队等待修复；4)低优先级(Minor)，例如，对软件的质量影响非常轻微或出现几率很低的缺陷,可以在开发人员有时间的时候再被纠正；5)最低优先级(Trival),例如，属于优化，可以不做修改的问题或暂时无法修复但影响不大的问题。
缺陷描述软件缺陷的描述是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发工程师交流的最好机会。
一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。
否则，它就会使信息含糊不清，可能会误导开发人员,因此，正确评估缺陷的严重程度和优先级，是项目组全体人员交流的基础。
缺陷描述的原则：有效的缺陷描述有以下几个原则：可以重现：在缺陷的详细描述中提供精确的操作步骤，可以让发人员容易看懂；定位准确：缺陷描述准确，不会引起误解和歧义；描述清晰：对操作步骤的描述清晰，易于理解，应用客观的书面语，避免使用口语；完整统一：提供完整、前后统一的软件缺陷的步骤和信息，按照一致的格式书写全部缺陷报告，有关缺陷的格式参见“缺陷的格式”；短小简练：通过使用关键词，可以使问题摘要的描述短小简练，又能准确解释产生缺陷的现象。
如“在新建任务窗口中，选择直接下达，负责人收不到即时消息”中“新建任务窗口”、“直接下达”、“即时消息”等是关键词；特定条件：许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原因的线索。
如“网站在和的兼容问题”；不做评价：在软件缺陷描述不要带有个人观点，对开发软件进行评价。
软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。
1.缺陷的格式：提交一条缺陷后，最好能够再检查一遍缺陷格式是否有问题。
常见的格式问题如下：问题摘要中不能有句号；问题摘要后不要有空格，直接填写内容；问题摘要比较长时，可以用“，”分隔；详细描述中序号后面“.”一定是半角的宋体，不是全角符号，并且后面不要再有空格；详细描述中分号一定要使用全角的分号；详细描述中的“->”应统一。
应在英文输入法的半角状态下输入箭头；注意缺陷中不要出现错别字，例如“登陆”应写为“登录”。
2.缺陷描述常见的问题：问题摘要过长，不够简练、准确；问题摘要与详细描述的内容不一致；详细描述不清楚，无法复现；详细描述冗长，不宜于理解；缺陷定位不正确；缺陷等级定位错误；缺陷的类型定位不正确；不是缺陷。
三、 缺陷管理1. 缺陷跟踪缺陷的提交人，实时跟踪缺陷状态，对开发人员提出的疑问，及时作出回答； 及时更新缺陷状态。
缺陷生命周期开发人员项目经理测试人员发现BUG提交BUG判断修复缺陷关闭缺陷回归测试确认缺陷Open AssignReOpenedClosedWon't FixFixed四、缺陷示例缺陷优先级会涉及从Critical到Trivial，严重程度等级会涉及从S1到S5。
一般地，严重程度高的软件缺陷具有较高的优先级，但是严重程度和优先级并不总是一一对应。
有时候严重程度高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重程度低的缺陷却需要及时处理，反而具有较高的优先级。
例如，公司名字和软件产品徽标是重要的，一旦它们误用了，这种缺陷是用户界面的产品缺陷，并不影响用户使用。
但是它影响公司形象和产品形象，因此这也是优先级高的软件缺陷。
通常功能性的缺陷较为严重，具有较高的优先级，而软件界面类缺陷的严重性一般较低，优先级也较低。
但实际上，优先级和严重程度是有联系也有区别。
严重程度高的，必然优先级也要高，但优先级高的，严重程度却并非也一定高。
1.功能性：1）S1级/Critical导致系统崩溃：执行正常操作或者误操作后，导致整个系统，或者大部分模块无法正常使用：问题摘要：为一个子部门设置一个网站签收员，再在人事管理中将该用户删除，导致程序加载不上详细描述：1.组织架构中，新建一个部门，为该部门指定一个网站签收员；2.进入人事“用户后台管理”，找到该用户，并将该用户删除；3.重新登录，系统提示断开，无法登录系统。
导致死机：执行正常操作或者误操作后，导致死机：问题摘要：通过地址簿填写多个收信人时导致所有程序无法响应详细描述：1.建立新邮件，单击“收信人”按钮，查找电子邮件地址；2.双击添加多个联系人地址时，程序无法响应，同时也无法执行其他应用程序，必须重新启动机器。
主业务流程出现断点：业务流程可以分为主业务流程和一般业务流程，是根据功能在流程中的重要程度进行区分的，例如在OA办公系统中，发文后无法收文应该是主业务流程的问题，收文后归档存在问题，则是流程的一个分支，属于一般业务流程：问题摘要：打开公文时，系统报错详细描述：1.公文流转中，选择一个公文双击打开，系统报错：有关调用实时(JIT)调试而不是此对话框的详细信息，请参见此消息的结尾。
************** 异常文本 **************……************** 已加载的程序集 **************出现不可挽救的数据丢失或损坏；内存泄漏；2）S2级/Blocker：发现影响被测模块正确运行的严重问题；导致程序模块丢失或未实现：执行正常操作或者误操作后，导致部分模块丢失，或者某个模块功能未实现：问题摘要：火炬计划中的“项目管理”模块功能未实现详细描述：登录系统，进入火炬计划->项目管理，其页面为“项目（课题）授权管理”的页面，“项目管理”功能未实现。
被测数据处理错误：如果数据处理错误导致模块级的问题，或者对系统的影响重大，例如下例中职工住房补贴重要的数据计算出错，缺陷的等级应该是S2；如果数据错误造成的影响不大，则可以定义为S3；问题摘要：补贴方式为达标、超标的职工的二次职级晋升出错详细描述：1）进入补贴管理->信息维护->职级晋升维护；2）选择补贴方式为达标或超标的职工进行第一次晋升，使级差面积大于0；3）再次进行晋升，查看级差面积，预期结果：级差面积=这次晋升的标准-上次晋升的标准（或最高标准）；实际结果：级差面积=这次晋升的标准-原始的标准。
软件错误导致数据丢失：问题摘要：工作表最大行数的兼容问题详细描述：1.在Office XP工作表中最大行数为65536行，而共创Office 2005的电子表格中工作表最大行数为32000行；2.当用共创Office 2005打开Office XP文档时会自动去掉32000行以后的行数以及数据，造成数据丢失。
用户需求未实现：没有实现用户需求规格说明书或者特定文档中规定的功能：问题摘要：编码管理员不应具有问题管理的权限详细描述：按照《权限角色设定》，编码管理员不应具有“问题管理”模块的权限。
以编码管理员的身份登录系统，可以执行“问题管理”的所有操作。
一般业务流程出现断点：问题摘要：国家重点新产品中无法浏览项目详细信息，造成流程出现断点详细描述：1.登录系统，点击国家重点新产品->新产品申请表；2.点击某记录的“项目名称”，出现页面“Error 404-Not Found”，功能没有实现，造成流程出现断点。
异常退出：执行正常操作或者误操作后，系统异常退出：问题摘要：编辑邮件回复时系统异常退出详细描述：1.打开收件箱中的任意邮件，选择编辑->选中所有文字；2.点击“回复”，系统异常退出。
直接点击“新建”按钮，建新邮件也会出现同样问题。
3）S3级：发现影响被测功能正确实现的问题；功能未实现：某项功能点的功能没有实现，例如点击某个按钮系统没有响应、设置某项功能后无效、无法执行某项操作等等：问题摘要：执行码表管理中“新增码表数据”系统无响应详细描述：1.进入“参数管理模块->码表管理->类型A”；2.点击“新增码表数据”系统无反应，无法实现此功能。
“类型B”页面存在同样问题。
问题摘要：角色授权无效详细描述：1.进入“权限管理模块->角色授权”，授权给角色“sss”以“全部可以查询”的权限；2.在“角色分配”中分配给该角色以人员“1”；3.使用人员“1”登录系统，查看各模块，仍然可以编辑修改信息，不是仅查询的权限。
问题摘要：实时信息中“最新提交报告信息”页面的返回按钮没有效果详细描述：1.进入“决策支持->实时信息服务”，直接显示“最新提交报告信息”页面；2.点击“返回”，系统刷新后仍显示本页面，返回按钮没有效果。
问题摘要：退单受理时无法提交详细描述：1.进入“综合值班->值班事件->退单受理”；2.选择一条退单数据，显示“退单事件修改”；3.点击“完成”，系统提示错误信息“为空或不是对象”，无法提交受理退单。
功能实现不正确；问题摘要：系统配置打印机校准设置的问题详细描述：1.进入系统->系统配置；2.在“打印机校准”方式中选择“启动时自动校准打印机”，点击“确认”；3.重新进入系统配置页面，打印机校准方式并不是刚才保存的“启动时自动校准打印机”，而是“不校准打印机使用操作系统默认值”。
问题摘要：发件箱中按“所属城区”查询错误详细描述：1.进入“测试委办局->发件箱”；2.设置“所属城区”查询条件，查询结果显示“没有符合条件的数据”，而实际存在符合条件的数据。
问题摘要：信息发布中“发布”功能问题详细描述：1.进入“市政基础设施资源管理系统->报表管理->信息发布->内部报表->期末燃气用户拥有量”页面；2.设置“2006”年“3”月，点击“发布”，显示“期末燃气拥有量”表，表中无有效数据，但页面下方的统计图显示效果和图中数据与上表不符。
其它信息发布页面中的“发布”功能存在同样问题。
数据处理错误，但对系统的影响不大；问题摘要：查询发件箱中统计结果不正确详细描述：1.进入“测试委办局->发件箱”；2.设置查询条件，查询后的统计结果比实际结果少一条记录。
问题摘要：班级成绩统计中，某些平均成绩的值没有进行四舍五入详细描述：班级成绩统计中，某些平均成绩的值没有进行四舍五入，例如：1.在“参数设置与库操作”界面中，执行“导入样品数据库”操作；2.在一班中增加两条学生记录，学号39，姓名a，语文75，数学0，物理0，化学0，英语0；学号40，姓名b，语文0，数学0，物理0，化学0，英语0；3.在“班级成绩”界面中，显示班级总人数40人，语文总成绩，平均成绩的值应该为40=，四舍五入后为，但界面中实际结果为，没有进行四舍五入。