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

软件缺陷基础概念

定义

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

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

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

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

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

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

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

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

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

表现形式

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

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

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

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

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

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

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

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

缺陷产生的原因

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

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

缺陷产生的根源

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

缺陷的修复费用

说明测试应该尽早介入

缺陷报告介绍

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

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

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

缺陷报告有如下作用

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

缺陷报告内容

缺陷的状态

状态变化

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

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

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

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

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

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

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

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

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

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

缺陷的跟踪

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

严重程度

严重程度分为五个等级：

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

说明：严重程度的分级并不统一，有的公司分为三个或者四个等级都是可以的

优先级

表现形式

缺陷报告书写规范

标题

简短，尽量能够体现原因和结果；准确，避免使用模糊不清的词语；便于他人理解，不要使用俚语、方言词汇

原则

完整，他人按照此步骤，即可复现问题

简明，不包含夸张、啰嗦的内容

内容

测试环境描述

步骤（加上编号，一个步骤不要包含太多步骤，可能将多个步骤合而为一，可以包含该步骤后的一个中间结果，可使用短语或短句不需要复杂句式）

实际结果清楚，不笼统

期望结果根据需求文档，应该出现的结果

附件截图、录屏、测试中需要的数据

解决方案、可能的原因（非必填），如果测试人员能够给出解决方案则更好了

常见错误

人称代词不明确；情绪化语言，强调符号；不确定词汇；幽默、梗；不确定：对于缺陷，测试人员至少需要再次操作，来重现缺陷

缺陷统计

通过缺陷统计，我们可能得出以下信息

缺陷分布：找出系统的薄弱环境

缺陷状态：根据变化，检查测试和开发的工作情况

人员水平：开发人员出错的数量，测试人员出错的数量

比较历史：对人员水平有所把握

模块难度：较难的模块出问题的可能较大

修复时间：平均修复缺陷需要的时间，越短越好

未修复的缺陷数目

作用

风险评估：能否在计划内的时间发布

缺陷原因：避免反复出现同类型的缺陷

员工技能提升：根据开发和测试人员表现出来的问题，可有针对性提升

团队配置：根据缺陷修复时间，可知道团队配合强弱

指标

单位时间（天/周）内报告的缺陷数目

单位时间（天/周）内修复的缺陷数目

累计缺陷报告数量

累计缺陷修复数量

不同严重性的缺陷数

模块与缺陷的对应关系

缺陷密度

单位缺陷数量/kloc（kilo ines of code）计算千行代码缺陷数量

总缺陷数量/总代码行数/1000

缺陷报告的原则和重要性

重要性

节省开发和测试人员的沟通时间、提高缺陷修复速度、提高测试人员的声誉、加强协同工作

原则

5C准则

准确：每个组成部分的描述准确不会引起误解

简洁：只包含必不可少的信息，不包含任何多余的内容

清晰：每个组成部分的描述清晰，易于理解

完整：包含复现该缺陷的完整步骤和其他本质信息

一致：按照一致的格式书写全部缺陷报告

2. 一个缺陷一个报告

便于分配、便于验证

常见缺陷的查找方法

UI（非重点）

色彩，大小，布局，图片，字体

时间

网络传输，数据未压缩，解析困难

文字内容

描述不清楚不正确，有语病、错别字，太复杂，乱码

容错处理

性能缺陷

花费时间长，资源占用多，卡顿，开发差，延迟高

缺陷的修复

不是所有的“缺陷”都是缺陷

无法重现或者难以捕捉；缺陷报告中没有复现步骤；缺陷报告无法理解；极少使用的功能，或者不符合用户习惯、惯例；由不受信任的测试人员提出

不是所有的缺陷都会修改

上线时间有限制；不正确的操作；涉及模块太多，可能导致按下葫芦浮起瓢的情况；性价比太低；极难重现

缺陷的管理过程（了解）