标签：方式 等级 期望 相关 依据 功能 项目经理 项目 测试
软件缺陷满足的规则（满足其一即可）：
（1）软件未实现产品说明书要求的功能
（2）软件出现了产品说明书指明不应该出现的错误
（3）软件实现了产品说明书未提到的功能
（4）软件未实现产品说明书虽未明确提及但应该实现的目标
（5）软件难以理解、不易使用、运行缓慢或者-从测试员的角度——最终用户认为不好
缺陷的基本信息
（1）缺陷标题，描述缺陷的标题；
（2）缺陷的严重程度，描述缺陷的严重程度。一般分为“致命”、“严重”、“一般”、“建议”4种；
（3）缺陷的紧急程度，描述缺陷的紧急程度。从1~4，1是优先级最高的等级；
（4）缺陷提交人，缺陷提交人的姓名（邮件地址）；
（5）缺陷提交时间；
（6）缺陷所属项目/模块。缺陷所属的项目和模块，最好能较精确地定位至模块
（7）缺陷指定解决人。缺陷指定的解决人，在缺陷“提交”状态为空，在缺陷“分发”状态下由项目经理指定相关开发人员修改；
（8）缺陷指定解决时间。项目经理指定的开发人员修改此缺陷的deadline；
（9）缺陷处理人。最终处理缺陷的处理人；
（10）缺陷处理结果描述。对处理结果的描述，如果对代码进行了修改，要求在此处体现出修改；
（11）缺陷处理时间；
（12）缺陷验证人。对被处理缺陷验证的验证人；
（13）缺陷验证结果描述。对验证结果的描述（通过，不通过）；
（14）缺陷验证时间；
缺陷报告的主要内容
（1）问题报告编号：便于管理，赋予唯一的编号，编号规则可根据需求和管理要求指定；
（2）标题：标题用简明的方式传达缺陷的基本信息，做到简短唯一；
（3）报告人：原始作者；
（4）报告日期：首次报告的日期；
（5）程序（或组件）的名称：可分辨的被测试对象；
（6）版本号：测试可能跨越多个版本，提供版本信息方便进行缺陷管理；
（7）配置：发现缺陷的软硬件配置，操作系统类型，处理器，RAM大小，浏览器载入，运行的其他程序等；
（8）缺陷的类型：如代码错误、设计错误、文档不匹配等；
（9）严重性：描述所报告的缺陷的严重性；
（10）优先级：有开发人员或管理人员进行确认，依据修复这个缺陷的重要性而定；
（11）关键词：便于分类查找缺陷报告，可在任何时候添加关键词；
（12）缺陷描述：详细说明发现问题，描述要深入，简明仍是最重要的。
（13）重现步骤：必须是有限的，并且描述的信息足够读者知道正确地执行就可以重现这个缺陷；
（14）结果对比：在执行重现缺陷步骤后，期望发生什么，实际上又发生了什么。
标签：方式 等级 期望 相关 依据 功能 项目经理 项目 测试
原文地址：https://www.cnblogs.com/jeffrey-yang/p/9821541.html
