软件缺陷描述

软件缺陷描述

《如何编写高质量的缺陷描述》

作为一名测试人员，提交缺陷是我们必须做的功课。

缺陷描述也是一门“艺术”，它影射了一个人的测试经验，测试深度。

缺陷描述能否做好，直接影响了我们的测试效率，更确切的说是影响了开发人员修改缺陷的效率。

一份高质量的缺陷描述让开发人员看的时候是一种享受，可以提高他们的工作效率；而一份让人费解的缺陷描述，不仅会让开发感到无从下手，还会降低对测试人员的信任度。

一份好的缺陷描述，体现了一个测试人员的基本素质。

1.根据自己的经验进行测试；

2.站在用户的角度去测试；

3.发现规律。

------------------------------------------------------------------------------------------------- 认识软件缺陷，首先要了解软件缺陷的概念，其次是了解软件缺陷的详细特征，最后就是它的属性了，再高一个层次就是学习利用管理软件缺陷的工具了。

1、首先介绍软件缺陷的概念

软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。

2、软件缺陷的详细特征

a、单一准确

b、可以再现（要求软件缺陷具有精确的步骤）

c、完整统一

d、短小简练

e、特定条件

f、补充完整

g、不做评价

3、软件缺陷的属性

软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。

下面详细介绍一下以上这些属性：

a、缺陷标识：是标记某个缺陷的唯一标识，可以用数字序号表示（缺陷编号）；

b、缺陷类型：功能、用户界面、文档、软件包、性能、系统\模块接口缺陷

功能：影响了各种系统功能、逻辑的缺陷；

用户界面：影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输入格式等方面的缺陷；

文档：影响发布和维护，包括注释、用户手册、设计文档；

软件包：由于软件配置库、变更管理或版本控制引起的错误；

性能：不满足系统可测量的属性值，如执行时间、事务处理速率等；

系统\模块接口：与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。

c、缺陷严重程度：致命（Fatal）、严重（Ceritical）、一般（Major）、较小（Minor）

致命：系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机或者危机人身安全；

严重：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响；

一般：系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题；

较小：使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题

d、缺陷产生可能性：总是、通常、有时、很少

总是：总是产生这个软件缺陷，其产生的频率是100%；

通常：按照测试用例，通常情况下会产生这个软件缺陷，其产生的频率大概是80%—90%；

有时：按照测试用例，有时候产生这个软件缺陷，其产生的频率大概是30%—50%；

很少：按照测试用例，很少产生这个软件缺陷，其产生的频率大概是1%—5%.

e、缺陷的优先级：立即解决、高优先级、正常排队、低优先级

立即解决：缺陷导致系统几乎不能使用或者测试不能继续，需立即修复；

高优先级：缺陷严重，影响测试，需要优先考虑；

正常排队：缺陷需要正常排队等待修复；

低优先级：缺陷可以再开发人员有时间的时候被纠正。

f、缺陷状态：激活或打开、已修正或修复、关闭或非激活、重新打开、推迟、保留、不能重现、需要更多信息

激活或打开：问题还没有解决，存在源代码中，确认“提交的缺陷”，等待处理，如新报的缺陷；

已修正或修复：已被开发人员检查、修复过的缺陷，通过单元测试，认为已经解决但还没有被测试人员验证；

关闭或非激活：测试人员验证后，确认缺陷不存在之后的状态；

重新打开：测试人员验证后，确认缺陷不存在之后的状态；

推迟：这个软件缺陷可以在下一个版本中解决；

保留：由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷；

不能重现：开发不能再现这个软件缺陷，需要测试人员检查缺陷再现的步骤；

需要更多信息：开发能再现这个软件缺陷，但开发人员需要一些信息，例如缺陷的日志文件、图片等。

g、软件缺陷的起源：需求、构架、设计、编码、测试、用户

在团建生命周期中软件缺陷占的比例：需求和构架设计阶段占54%、设计阶段占25%、编码阶段占15%、其他占6%.

h、软件缺陷的来源：需求说明书、设计文档、系统集成接口、数据流（库）、程序代码

需求说明书：需求说明书的错误或不清楚引起的问题；

设计文档：设计文档描述不准确。和需求说明书不一致的问题；

系统集成接口：系统个模块参数不匹配、开发组之间缺乏协调引起的缺陷；

数据流（库）：由于数据字典、数据库中的错误引起的缺陷；

程序代码：纯粹在编码中的问题所引起的缺陷。

i、缺陷根源：测试策略，过程、工具和方法，团队\人，缺乏组织和通讯，硬件，软件，工作环境

测试策略：错误的测试范围，误解测试目标，超越测试能力等；

过程、工具和方法：无效的需求收集过程，果实的风险管理过程，不使用的项目管理方法，没有估算规程，无效的变更控制过程等；

团队\人：项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气和动机不纯等；

缺乏组织和通讯：缺乏用户参与，职责不明确、管理失败等；

硬件：硬件配置不对、缺乏、或处理器缺陷导致算术精度丢失，内存溢出等；

软件：软件设置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误，千年虫问题等；

工作环境：组织机构调整，预算改变，工作环境恶劣，如噪音过大。

-------------------------------------------------------------------------------- 下面是一个关于资产财务月报折旧数据不对的缺陷，各个测试人员提交的内容。

人员缺陷描述

测试员1 资产财务月报折旧数据不对。

测试员2 资产财务月报折旧数据跟资产台账明细的折旧数据之和不等，差287.53元。

测试员3 资产财务月报折旧数据不对，zc_zjjl（资产折旧记录）和zc_yjjl（资产月结记录）折旧额不等。

测试员4 只要出现资产重置，资产财务月报折旧数据跟资产台账明细的折旧数据之和就不等。

测试员5 资产财务月报折旧数据不对，经查发现资产重置以后，资产月结的时候和zc_yjjl（资产月结记录）的重置金额未更新，折旧金额还是按照重置前的金额计算，造成资产月报数据不对。月结处理算法不对，请修改。

从上面的例子可以看出，一个缺陷竟然出现5种说法，如果你是开发人员你想看哪位测试人员的缺陷？？？

肯定是第5位了。不仅清晰的描述出了系统存在的缺陷，还直接帮开发人员找到的缺陷的根源。可能你还会想，不管怎样，我已经把系统中存在的问题描述出来了，开发总会找到原因的，下面，我们再来看一下，开发对于这5个缺陷的回复。

人员开发人员回复

测试员1 我这里测了一下，折旧数据是对的，不是缺陷。

测试员2 我这里测了一下，折旧数据是对的，不是缺陷。

测试员3 我开发库里的这两张表数据是对，请再确认一下。

测试员4 晕，我查了两个小时，我的财务报表是对，是张三的月结处理的算法是错的，请提交给张三。

测试员5 张三回复：兄弟辛苦了，中午一起吃饭。

可能有些调侃，不过这些情况在大家的工作中一定都遇到过。对于一些，描述不清或不准确的缺陷，往往都被开发拒绝掉。对于这些，总结了几点：

一、追根溯源。缺陷也存在表面现象和真正原因，我们不仅仅应该看到它在系统中表现出的表面现象，还应该通过一步步的分析，找出缺陷产生的真正原因。有时可能通过多个测试用例才能发现，有时可能还要在多个表中查找才能查出。作为一名测试员，我们应该本着认真负责的态度，去发现任何细小缺陷的真正根源。

二、面面俱到。详细的描述缺陷产生的真实情况。作为测试人员，我们对于业务要比开发人员熟悉太多。有时候，对于一个缺陷的产生过程，总以为简单描述就可以，殊不知开发人员对你”跳跃性“的步骤，往往是一头雾水。因此，我们在描述时，要尽可能的详细。

三、简明扼要。可能听起来和第二点有些矛盾，可这确实是我们应该注意的地方。开发的周期都是相当紧凑的。我们应该用最简单的语言描述缺陷，可多用短句，保证逻辑上的清晰。