金鼎文科技有限公司
第三节 缺陷分类
根据缺陷的定义，将缺陷分为如下列
? 文档缺陷：是指对文档的静态检查过程中发现的缺陷。检查活动包括同行评审、产
品审计等。评审的缺陷要根据被评审对象的类型来确定，被评审的对象包括最终出产物和中间过程产出物，比如需求文档、设计文档、计划、报告、用例等
缺陷分类 描述不完整 不一致 描述 文档内容缺失，或文档应该包括的范围没有涵盖 一致性问题有两类： 一是与源头说明书不一致，比如需求和客户业务需求不一致、设计与需求不一致等 二是上下文或者与前提不一致 描述错误 功能问题 不清楚或有歧义 逻辑错误 接口问题 文档描述是错误的，不可实现或导致错误的输出或结果 该缺陷将会导致用户功能的错误、不满足、不可用 内容的描述不清楚、不能准确表达、或表达的意思有歧义 内容组织逻辑不清楚、逻辑错误 与最终用户接口问题、与外部系统的接口问题、内部子系统或模块的接口问题 输入输出问题 不细化 性能问题 安全性问题 输入输出不完整、不正确、不可测试或验证 内容还需要进一步细化 文档的设计或实现方式存在性能问题 文档的设计或实现方式存在安全性问题
? 代码缺陷：是指对代码进行同行评审、审计或代码走查过程中发现的缺陷
缺陷分类 常量变量定义问题 不满足设计或需求 编写代码不符合规范 描述 金鼎文科技有限公司
条件判断处理 循环处理错误 异常处理 算法逻辑问题 注释问题 代码冗余 性能问题
? 测试缺陷：是指由测试活动发现的测试对象（被测对象一般是指可运行的代码、系
统，不包括静态测试发现的问题）的缺陷，测试活动包括单元测试、集成测试、系统测试、性能测试等
? 过程缺陷：有称为不符合项问题，是指通过过程审计、过程分析、管理评审、质量
评估、质量审核等活动发现的关于过程的缺陷和问题。过程缺陷的发现者一般是测试人员、项目经理等
缺陷类型 功能错误 描述 影响了重要的特性、用户界面、产品接口或全局数据结构，并且设计文档需要争取的变更。如逻辑、循环、递归、功能等缺陷 结构错误 脚本错误 Web应用程序结构化页面无法显示，或者显示错误 Web应用程序当中出现脚本错误，包括客户端对数据进行校验和运算的各种情况下产生的错误 页面链接错误 页面文字错误 Web应用程序页面出现空链接、错误链接、死链接 Web应用程序页面出现的中外文拼写、使用、以及不同语种页面的编码错误 页面图形错误 ALT错误 排版错误 业务逻辑不合理 Web应用程序页面出现图片内容使用不当，或者无法显示 Web应用程序页面当中超文本标识语言、文本标签解释错误 Web应用程序页面排版不符合要求或者不符合使用习惯 应用程序的实现流程和规定业务流程不一致，或者实现流程无法正确完成。包括流程数据的部分并行、争用、同步等操作，引起的流程断金鼎文科技有限公司
裂、死锁、以及其他异常情况 业务逻辑不方便 应用程序实现流程在实际情况下虽然可以完成，但是存在不必要的反复、等待、冗余等影响使用效率的情况 其他错误 建议 其他未分类错误 系统改进建议 第四节 缺陷定义 ? 缺陷等级定义
缺陷的严重程度对以上所述的缺陷类型都是适合的，缺陷的严重程度反映的是对缺陷的发现对象可能造成的影响或后果来定义的。 缺陷等级 缺陷性质 系统中对应的错误分类 一级 致命错误 系统崩溃 系统死锁 导致对被描述的主要对象的理解错误、不可行、不可运转、对业务和整个系统造成重大损失或损害；对使用、维护或保管人员有危险或不安全，以及对产品的基本功能有致命影响的缺陷 二级 严重缺陷 严重错误 对被描述的部分对象的理解或实现错误，部分的模块或系统不可行或不能运转或部分模块和系统缺失，对整个系统有重大影响或可能造成部分的损失或损害；严重影响使用安全 三级 一般缺陷 次要错误 布局不合理 文字错误 系统中部分单元模块或单个功能描述和实现有错误、有偏差、不一致或有缺失，不影响模块的正常运行，或有影响，但可以有替代的办法或避免办法 四级 微小缺陷 微不足道 基本不影响系统的运行和功能的实现。但是与标准、规范和定义不一致 五级 建议缺陷 新特性 不在定义、标准、范围的定义和约束之内，但是从提出者来看是需要完善的建议 描述 ? 缺陷优先级定义 金鼎文科技有限公司
缺陷优先级 特急 加急 高 中 低 需要立刻进行修改 一天到两天之内必须修改 介于中和加急之间 描述 缺陷需要正常排队等待修复或列入软件发布清单 留到组后解决，如果项目的进度跟紧张可以在产品发布以前不解决 ? 缺陷状态定义 缺陷状态 初始状态（New） 描述 测试或开发人员提交一个新的缺陷，等待开发人员或项目经理分配修改负责人 打回（FeedBack） 已分配（Assigned） 已解决（Resolved） 关闭（Closed） 重新打开（Reopen） 遗留（Later） 要求缺陷的报告者再次对缺陷进行说明 是指已经分配给属主，等待修改。 缺陷被属主修改，等待测试人员验证 测试人员验证缺陷已经修复 测试人员验证，缺陷没有修改正确 经项目经理和技术经理验证此缺陷在本版本中不用修改 第五节 缺陷完成度 缺陷完成度 打开（Open） 缺陷没有被解决 描述 已解决（Fixed） 缺陷已经修改 遗留此缺陷步骤本阶段解决 （Suspended） 重新打开重新打开某个缺陷 （Reopen） 不做修改不对这个缺陷进行修改 （Won’t fix） 金鼎文科技有限公司
重复 （Duplicate） 与某个缺陷重复 需求如此 不可重现 经理和开发人员经过需求和设计的核实后决定不需要修改 被指派的开发人员想要再现缺陷进行修改个时候，发现缺陷始终不能再现 第六节 处理机制 退回机制
若在测试过程中发生如下情况，将系统退回到申请部门：
? 经过测试后，发现与需求说明规格说明书中定义的功能项存在较大
的差异
? 单一模块，测试过程中发现缺陷输了较多或者无法继续进行系统其
它功能模块的测试，继续测试无意义 ? 测试过程中，频繁死机或系统崩溃 ? 主业务流程出现断点
异常情况处理机制
非正常情况下，需要进行特别处理的情形，此情况需要主管领导签字确认：
? 上线时间紧急的情况下，未经测试部充分测试就需要部署到用户现场 ? 作为总包时，子商进度明显延迟，尚未进行验收测试就需要上线
报告机制
若出现以下情况，需要及时向部门领导和项目经理汇报的情况： ? 测试后期出现重大逻辑错误，修改测试影响上线时间 ? 测试过程中用户需求出现重大变更 ? 测试负责人定期汇报测试情况
第九章 测试结果分析
第一节 测试完成的标准
被测试出的、在软件错误级别分类中定义的：
? 一级缺陷，致命错误，100%得到修改并且复测通过