准确报告软件缺陷-UML软件工程组织-火龙果软件

UML软件工程组织

准确报告软件缺陷

作者：KerryZhu 来源：中国软件

软件缺陷的描述是是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发小组交流的最初且最好的机会。一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员。准确报告软件缺陷是非常重要的，因为：

清晰准确的软件缺陷描述可以减少软件缺陷从开发人员返回的数量
提高软件缺陷修复的速度，使每一个小组能够有效的工作
提高测试人员的信任度，可以得到开发人员对清晰的软件缺陷描述有效的响应
加强开发人员，测试人员和管理人员的协同工作，让他们可以更好的工作

在多年实践的基础上，我们积累了较多的软件缺陷的有效描述规则，主要是：

单一准确。每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常常会导致缺陷部分被注意和修复，不能得到彻底的修正。

可以再现。提供缺陷的精确操作步骤，使开发人员容易看懂，可以自己再现这个缺陷，通常情况下，开发人员只有再现了缺陷，才能正确地修复缺陷。

完整统一。提供完整、前后统一的软件缺陷的步骤和信息，例如：图片信息，Log文件等。

短小简练。通过使用关键词，可以使软件缺陷的标题的描述短小简练，又能准确解释产生缺陷的现象。如“主页的导航栏在低分辨率下显示不整齐”中“主页”、“导航栏”、“分辨率”等是关键词。

特定条件。许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原因的线索。如“搜索功能在没有找到结果返回时跳转页面不对”。

补充完善。从发现bug那一刻起，测试人员的责任就是保证它被正确的报告，并且得到应有的重视，继续监视其修复的全过程。

不做评价。在软件缺陷描述不要带有个人观点，对开发人员进行评价。软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。

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

1. 缺陷标识：是标记某个缺陷的唯一的表示，可以使用数字序号表示。

2. 缺陷类型：是根据缺陷的自然属性划分缺陷种类，如表1所示

表1软件缺陷类型列表

缺陷类型	描述
功能	影响了各种系统功能、逻辑的缺陷
用户界面	影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷
文档	影响发布和维护，包括注释，用户手册，设计文档
软件包	由于软件配置库、变更管理或版本控制引起的错误
性能	不满足系统可测量的属性值，如执行时间，事务处理速率等。
系统/模块接口	与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。

3. 缺陷严重程度：是指因缺陷引起的故障对软件产品的影响程度，所谓“严重性”我指的是在测试条件下，一个错误在系统中的绝对影响。如表2所示

表2软件缺陷严重等级列表

缺陷严重等级	描述
致命 (Fatal)	系统任何一个主要功能完全丧失、用户数据受到破坏、系统崩溃、悬挂、死机，或者危及人身安全
严重 (Critical)	系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响
一般 (Major)	系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确；或用户界面差、操作时间长等一些问题。
较小 (Minor)	使操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别的不影响产品理解的错别字、文字排列不对齐等一些小问题。

4. 缺陷产生的可能性：指缺陷在产品中发生的可能性，通常可以用频率来表示，如表3所示。

表3 缺陷产生可能性列表

缺陷产生可能性	描述
总是 (Always)	总是产生这个软件缺陷，其产生的频率是100%
通常 (Often)	按照测试用例，通常情况下会产生这个软件缺陷，其产生的频率大概是80-90%
有时 (Occasionally)	按照测试用例，有的时候产生这个软件缺陷，其产生的频率大概是30-50%
很少 (rarely)	按照测试用例，很少产生这个软件缺陷，其产生的频率大概是1-5%

5. 缺陷优先级：指缺陷必须被修复的紧急程度。“优先级”的衡量抓住了在严重性中没有考虑的重要程度因素，如表4所示。

表4 软件缺陷优先级列表

缺陷优先级	描述
立即解决(P1级)	缺陷导致系统几乎不能使用或测试不能继续，需立即修复
高优先级(P2级）	缺陷严重，影响测试，需要优先考虑
正常排队(P3级）	缺陷需要正常排队等待修复
低优先级(P4级）	缺陷可以在开发人员有时间的时候被纠正。

一般来讲，缺陷严重等级和缺陷优先级相关性很强，但是，具有低优先级和高严重性的错误是可能的，反之亦然。例如，产品徽标是重要的，一旦它丢失了，这种缺陷是用户界面的产品缺陷，但是它阻碍产品的形象。那么它是优先级很高的软件缺陷。

6. 缺陷状态：指缺陷通过一个跟踪修复过程的进展情况，也就是在软件生命周期中的状态基本定义，如表5所示。

表5 软件缺陷状态列表

缺陷状态	描述
激活或打开（Active or Open）	问题还没有解决，存在源代码中，确认“提交的缺陷”，等待处理，如新报的缺陷。
已修正或修复 (Fixed or Resolved)	已被开发人员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证
关闭或非激活 (Close or Inactive)	测试人员验证后，确认缺陷不存在之后的状态。
重新打开	测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复
推迟	这个软件缺陷可以在下一个版本中解决
保留	由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷
不能重现	开发不能复现这个软件缺陷，需要测试人员检查缺陷复现的步骤。
需要更多信息	开发能复现这个软件缺陷，但开发人员需要一些信息，例如：缺陷的日志文件，图片等。

7. 缺陷来源：指缺陷所在的地方，如文档、代码等，如表6所示。

表6 软件缺陷来源列表

缺陷来源	描述
需求说明书	需求说明书的错误、或不清楚引起的问题
设计文档	设计文档描述不准确、和需求说明书不一致的问题
系统集成接口	系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷
数据流(库)	由于数据字典、数据库中的错误引起的缺陷
程序代码	纯粹在编码中的问题所引起的缺陷

8. 缺陷根源：指造成上述错误的根本因素，以寻求软件开发流程的改进、管理水平的提高，如表7所示。

表7 软件缺陷根源列表

缺陷根源	描述
测试策略	错误的测试范围，误解了测试目标，超越测试能力等
过程，工具和方法	无效的需求收集过程，过时的风险管理过程，不适用的项目管理方法，没有估算规程，无效的变更控制过程等。
团队/人	项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气和动机不纯等。
缺乏组织和通讯	缺乏用户参与，职责不明确，管理失败等。
硬件	硬件配置不对、缺乏，或处理器缺陷导致算术精度丢失，内存溢出等
软件	软件设置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误，2000 千年虫问题等。
工作环境	组织机构调整，预算改变，工作环境恶劣，如噪音过大。