缺陷管理 1.缺陷定义 缺陷（Defect或Bug）是软件开发过程中的"副产品"。通常，缺陷会导致软件产品在某种程度上不能满足用户的需要。每一个软件组织都知道必须妥善处理软件中的缺陷。这是关系到软件组织生存、发展的质量根本。可遗憾的是（在中国），并非所有的软件组织都知道如何有效地管理自己软件中的缺陷。（这几年，新技术，区块链，5g，人工智能。。）
早在1947年9月9日，Bug（英文译文“臭虫”或“虫子”）一词，由美国海军的编程员，编译器的发明者格蕾斯·哈珀（GraceHopper）提出，他发现计算机死机的问题，竟然是一只飞蛾导致的。她小心地用镊子将蛾子夹出来，用透明胶布帖到“事件记录本”中，并注明“第一个发现虫子的实例”。从此以后，人们将计算机的错误统称为Bug。 2.缺陷管理概念 缺陷管理/软件缺陷管理（Defect Management）是在软件生命周期中识别、管理、沟通，解决任何缺陷的过程（从缺陷的识别到缺陷的解决关闭），确保缺陷被跟踪管理而不丢失。一般的，需要跟踪管理工具来帮助进行缺陷全流程管理。 3.缺陷管理的意义
软件的缺陷是软件开发过程中的重要属性，它提供了许多信息。不同成熟度的软件组织采用不同的方式管理缺陷。低成熟度的软件组织会记录缺陷，并跟踪缺陷纠正过程。高成熟度的软件组织，还会充分利用缺陷提供的信息，建立组织过程能力基线，实现量化过程管理，并可以此为基础，通过缺陷预防实现过程的持续性优化。
4.BUG分类（重点） 4.1.按照严重程度分: 一般分为4个等级:（优先处理）
系统崩溃/致命（app崩溃，闪退，web网页404）严重 （功能性问题，逻辑问题，接口数据问题）一般 （显示问题，少了字，掉了ui）次要（ui问题）4.2.按优先级分:
Low(低) --时间和资源允许的情况下修复（暂时不方便解决，时间问题，或资源问题）Medium(中) --不会延迟发布,会在以后修复High(高) --会制约开发和测试的进行,需要在发布之前修复Urgent(急) --导致系统几乎不可用（登陆进不去了，网络数据问题） 4.3.Bug定级示例 缺陷级别定义 1级，系统崩溃 定义：严重阻碍测试和开发工作 对应优先级：急 具体可分为： 1.功能完全没有实现出现报错 2.应用闪退/崩溃无法运行 3.其他导致功能无法测试的问题 2级，严重 定义：非阻碍用例执行的严重问题 对应优先级：高 具体可分为： 1.核心功能实现逻辑覆盖不全面(下单支付) 2.数据丢失 3.严重影响系统自身功能无法运行 4.严重数值计算错误 5.数据库损坏或无法保存配置（涉及不多） 6.安全性问题（包括数据加密等）（接口测试中测试数据） 4级，一般 定义：对应用熟悉度高才能感知到的问题，对应用基本功能实现无影响 对应优先级：中 具体可分为： 1.轻微数值计算错误(999.0999.00)（金融行业，计算的错误是重点） 2.用户简单操作，即可明显感知的UI问题 3.边界条件显示错误 4.提示信息和界面效果展示错误（包括未给出信息、信息提示错误等） 5.复现率低于5%的闪退/崩溃 （复现的bug出现次数不多，不是必现） 6.插件兼容和性能未优化问题 7.非正常操作导致UI显示异常 4级，建议，设计需求改进，开发改进，ui设计改进 定义：对于产品的意见或者建议 对应优先级：低 具体可分为： 1.对于产品设计方面的意见和建议 2.对于产品界面优化方面的意见和建议 3.对于产品需要优化增强用户体验方面的意见和建议5.软件缺陷分类 缺陷类型 内容说明 备注 系统缺陷 1 由于程序所引起的死机，异常退出 2 程序死循环（弹窗不断重复跳出来） 3 程序错误 不能执行正常工作或重要功能，使系统崩溃或资源不足 数据缺陷 1 数据计算错误 2 数据约束错误 3 数据输入、输出错误 严重的影响系统要求或基本功能的实现 数据库缺陷（了解） 1 数据库发生死锁（lock） 2 数据库的表、缺省值未加约束条件 3 数据库连接错误 4 数据库的表有过多的空字段 接口缺陷 1 数据通信错误 2 程序接口错误 功能缺陷 1 功能无法实现 2 功能实现错误 登录注册，分类，购物车，订单 安全性缺陷 1 用户权限无法实现 2 超出限制错误 3 访问控制错误 4 加密错误 权限 数据安全 兼容性缺陷 与需求规定配置兼容性不配合 硬件，软件（当做优化） 性能缺陷 1 未达到预期的性能目标 2 性能测试中出错，导致无法进行测试 界面缺陷 1 操作界面错误 2 打印内容，格式错误 3 删除操作未给出提示 4 长时间操作未给出提示 5 界面不规范 建议 1 功能建议 2 操作建议 建议性的改进
6.常见缺陷的查找 Ui用户界面 色彩 色彩的搭配无序、混乱是软件图形界面设计的大忌,图形界面应尽量设计得温和些。这类缺陷主观类强,个人主观占据主动，所提交的缺陷一般严重程度不可定得太高。 例如: 整体界面色彩单调,无变化,仅使用一种色彩,且篇幅较大，可以提交建议性的缺陷,即使是简单的界面,宁可采用无色，不可使用鲜艳的单色，如紅色,黄色、绿色等。 背景色与将界面字体色相近,不能清晰区分,色彩搭配太乱、复杂,且不符合软件标准。 功能结构布局 功能结构布局主要从界面的功能区域划分来考虑.相同的、类似的功能应该放在邻近的区域。 例如: 记录添加功能界面,添加按钮未放在醒目的位置; 导航功能位于界面的右则; 整体功能区域分布混乱。 图片 图片选用不合理,与当前软件类型不符,无法正确体现当前界面功能性含义，图片不规范，不清晰。 例如： 图片色彩过于艳丽或黯淡,模湖不清; 图片变形; 图片不符合当前界面的主题,图片与描述性文字不符。 页面大小 在B/S结构的软件系统中,当一个页面元素太多，未做精简时,在打开该页面时可能需要较长的加载时间,这对于软件性能是一个不小的影响,既增加了服务器的压力,又容易引起用户的反感。 例如: 图片未经压缩、格式不正确,比如采用BMP(位图) 代码冗余,存在太多无用代码 页面元素太多,太过复杂 字体： 字体在软件界面中尤其重要，字体的使用要符合软件开发的规范 例如： 字体过大，与其他页面信息脱节，无法形成主体 字体过小，无法看清内容 字体不符合当前界面风格 窗体大小 窗体的设计要有层次感,父窗口,子窗口应该有所区别，窗口不应该有太多空白处,功能区城充实。 例如: 窗口太大,功能按钮分散,间隔太大; 窗口太小,功能按钮过于集中,间隔太小,或空间会显示不全 弹出窗口未能定于屏幕居中位置, 界面文字 页面信息描述不清楚，有语病，错别字，简单语言复杂化，描述不正确，不符合当前页面，错误的帮助信息，乱码等。
容错处理(功能缺陷) 容错处理在软件系统中占据十分重要的地位,所谓容错,就是容忍错误的能力.当用户在使用软件过程中发生错误后:软件应该能给出引导信息,指引用户进行正确的操作。（app出现一些问题，不影响功能，流程） 例如: 用户输入错误,系统无提示，用户不能清楚知道系统不处理的原因; 给出信息提示,用户接受后无法继续操作:不给用户一个改过自新的机会; 用户输入不合法的信息后,系统进行提示, 用户确定后,系统仍能处理错误的信息。 取消功能不能取消,比如删除,系统给出提示，是否确定删除，用户否认后仍执行了删除.
数据转换（后台，数据库） 软件中的功能主体一般由增加,修改,删除,查询等组成。 例如： 无法增加记录,比如点击新增,页面自动关闭 增加记录后无显示,但提示增加成功 增加记录后显示不正确,显示为乱码,信息显示不全 增加记录后多出记录 无法修改记录 修改后不能自动更新,需手工更新 无法删除记录,无法全部删除 删除不成动,但相应的记录已被删除 无法查询,查询的结果错误
性能缺陷 这里所说的性能问题不需专业的工具就能发现的问题,这类问题在平常做黑盒测试的时候就能发现。 例如: 打开文档, 10秒应该可以完成的,却用了3分钟 启动软件, CPU长时间100%,内存消耗过多. 5个用户可以正常使用,20个用户使用时系统崩溃了，并发的问题 打开一个登录页面花了1分钟;（初始化数据） 完成一个查询功能,花了2分钟, 7.按照解决方案分类
8.Bug生命周期 新建(测试)，确认(负责人)，分配，修复，重新验证，关闭，重新打开，修复/遗留
公司处理bug的流程: // 可能场景是开发人员粉饰了bug,或者一下一个版本中的环境发生改变了
9.缺陷报告(缺陷描述) 需要包含下面15项就可以,每一个bug都要有一个bug报告
编号 属性名称 描述 1 缺陷ID 唯一的id，确保根据ID追踪缺陷 2 缺陷状态 进展情况，关闭，打开，修复 3 缺陷标题 描述缺陷的标题 4 缺陷的严重程度 致命，严重，一般，低 5 缺陷的优先级 缺陷修复的先后顺序，哪些优先修正，哪些稍后修正 6 缺陷的所属模块 缺陷所属的项目模块 7 缺陷记录者 提交缺陷的测试人员 8 缺陷提交时间 缺陷的提交时间 9 缺陷处理人 处理缺陷的处理人 10 处理结果描述（开发） 对处理结果的描述，描述处理情况和代码修改说明 11 缺陷验证人 对被处理缺陷验证的验证人（回测者）1 12 验证结果描述 对验证结果的描述（通过，不通过） 13 缺陷详细描述 缺陷的重现步骤 14 缺陷环境说明 对测试环境的描述 15 必要的附件 如涉及到附件或者错误现象的图片等
10.Bug的处理流
