软件测试基础----缺陷定义：缺陷产生的原因：缺陷类型：缺陷严重程度：缺陷修复优先级：缺陷状态：缺陷来源：缺陷识别：缺陷识别：缺陷建立标准：缺陷描述规则：缺陷严重程度与优先级是什么关系
缺陷定义：产品说明书出现在软件未实现产品说明书要求的功能软件中，表明不应该发生。 软件没有提到产品说明书没有实现功能软件产品说明书虽然明确提到了，但是认为应该实现的目标软件难以理解、使用困难、动作缓慢或者(从测试的角度)最终用户不好
软件实现了产品规格说明所要求的功能等，但由于性能的限制而没有考虑可移植性问题，这并不是软件的缺陷。
出现缺陷的原因：需求不完善定义客户—开发人员对通信失败软件需求故意偏离逻辑设计的错误编码错误文档编写和编码规定测试流程不足规程错误文档编写错误缺陷类型： (常见的是)功能、接口、文档
缺陷严重程度：(不同公司采用的专业名词可能基本原理不同
根据《软件测试》第2版)
致命的
很严重
普通的
很小
修复缺陷的优先顺序：不同企业采用的名词可能不同
立即解决
高优先级
正常排列
优先级低
缺陷状态：激活/开放确认修复/修复/修复关闭/取消激活无法恢复保留，需要更多信息重复的是软件规格书而不是缺陷。 缺陷的状态通过跟踪缺陷修复过程的进度来定义，开发人员在修复错误后将状态更改为已修复或等待验证的状态。
缺陷来源：需求说明书设计文档系统集成接口数据库(流)程序代码缺陷来源：测试策略流程、工具和方法团体/人短缺组织和通信硬件运行环境缺陷识别：依据：需求分析、设计文档、产品产品
缺陷报告：缺陷编号示例： bug _项目名称_模块名称_功能名称_0001所属模块优先级重要性缺陷摘要：一句话说明缺陷情况缺陷描述：缺陷再现步骤预期结果和实际结果提交人评论：一般出现该缺陷的特殊情况或bug
缺陷处理的优先级是软件缺陷报告的属性。
创建缺陷的指导方针：准确
明确地
简洁
完全
一致
缺陷描述规则：当前
不做评价
缺陷的严重程度和优先顺序是什么关系？ 答：没有直接关系
不要认为严重缺陷修复的优先级很高
遇到轻重缓急的缺陷也是偶然的
常用缺陷管理工具：
开源(Bugzilla、jira、matins、Excel等)业务；QC/ALM、禅道等)。
软件中的缺陷不一定都会导致程序崩溃。
严重缺陷，指功能模块或特性没有实现，主要功能部分丧失，次要功能全部丧失，或致命的错误声明。
文字、界面错误属于严重程度较低的缺陷。
实施缺陷跟踪的原因是软件质量无法控制、问题无法量化、重复问题接连产生、解决问题的知识无法保留。
良好的复现步骤应该包含本质的信息，按照下列方式书写
提供测试先决条件和测试环境
如果有多种方法导致此缺陷，请包括在步骤中；
引导简单一步一步地再现这个缺陷，每个步骤尽量只记录一个操作；
尽量使用短语和短文，避免复杂的句型和句法；
再现的操作步骤必须完整、准确、简单；
只记录每个操作步骤是什么，不要包括执行每个操作步骤后的结果；
将一般步骤合并为较少的步骤。