软件测试---缺陷、缺陷报告

软件缺陷基础概念

定义

从内部看，软件确认是产品开发或者维护过程中存在的错误、毛病等各种问题

从外部看，软件缺陷是系统所需要实现的某种功能的失效或者违背

总的来说，缺陷就是问题，最终表现为所需要的功能没有完全实现，没有满足用户的需求

具体包含（程序、数据、文档）

未达到需求规格说明书中的功能

出现了需求规格说明书中指明不会出现的错误

功能超出了需求规格说明书的范围

未达到需求规格说明书中虽然没有指明，但应该到达的目标

测试人员或者用户认为软件难以理解、不易使用、运行速度慢或最终用户认为不好

表现形式

功能、特性没有实现或者部分实现

设计不合理、功能特性不明确、逻辑不清楚或者存在矛盾

产品实际结果和所期望的结果不一致

没有达到需求规格说明书所规定的性能指标

运行出错、中断、崩溃、界面混乱

数据不正确、精度不够、不完整、格式不统一

用户不能接受的其他问题，超时、界面丑陋

硬件或者系统软件上存在的其他问题

缺陷产生的原因

缺陷不可避免，主要原因如下：

需求解释或者记录错误，用户需求定义错误，需求说明存在错误，编码说明、程序代码有误，硬件或者系统存在错误，文档错误、内容不正确、拼写错误

缺陷产生的根源

交流不充分、软件的复杂性、开发任务的错误、需求的变化、进度压力

缺陷的修复费用

说明测试应该尽早介入

缺陷报告介绍

在测试后，如果发现缺陷，则应该进行缺陷报告

缺陷报告的一些字段及说明

缺陷ID：唯一的缺陷ID，可以根据该ID追踪缺陷
缺陷状态：缺陷状态指缺陷通过一个跟踪修复过程的进展情况
缺陷标题：描述缺陷的标题
缺陷的严重程度：对软件产品的影响程度，分致命、较严重、严重、一般、低
缺陷的优先级：缺陷修复的先后顺序，即那些缺陷优先修正，哪些稍后
缺陷的所属模块：缺陷所属的项目和模块，要能较精确的定位至模块
缺陷记录着：提交缺陷的人员姓名
缺陷提交时间：缺陷提交的时间
缺陷处理人：处理缺陷的处理人
处理结果描述：对处理结果的描述，描述处理情况和代码修改说明
缺陷处理时间：缺陷处理的时间
缺陷验证人：对被处理缺陷验证的验证人（回测者）
验证结果描述：对验证结果的描述（通过、不通过）
缺陷详细描述：缺陷的复现步骤
缺陷环境说明：对测试环境的描述
必要的附件：如涉及到附件的或错误现象的图片等

缺陷报告有如下作用

记录测试结果、方便开发人员进行缺陷的定位、为后期统计缺陷提供依据

缺陷报告内容

缺陷的状态

状态变化

new：测试人员发现缺陷
assigned：由开发经理或者其他人员，将修复职责指定为某位开发人员
开发人员阅读缺陷报告，可能得到如下结果

open：测试人员是正确的，准备修复

dupllcate：与其他bug为同一原因，修正好一个后，这个也就修复了

reject：测试人员理解错误，其实这不是bug

flxed：经过一段时间开发人员修复了bug，就会标记为此状态

postpone：小问题，目前没有时间修复

4. 测试人员检验缺陷状态

closed：再次测试，发现错误已经修复

closed reject的错误，经过沟通核实后，确认无需修复

reopen：原来修复后的缺陷，经过回归测试后又出现了，标记原先的缺陷为此状态

缺陷的跟踪

要点：缺陷从测试人员开始，也应该由测试人员结束

严重程度

严重程度分为五个等级：

fatal致命的缺陷：造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题
critical严重错误的软件缺陷：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，问题局限在本模块，导致模块功能失效或异常退出。如系统自愿占用过大，功能没有做完
majoe一般的软件缺陷：次要功能没有完全实现但是不影响使用。如：提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等
minor较小的软件缺陷：较小错误的软件缺陷，使操作者不方便或遇到麻烦，但它不影响功能性的操作和执行，例如：对话框弹出位置，步骤较多，输入项太麻烦
enhancemental建议问题：由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。例如：错别字、颜色、按钮大小