软件测试知识(3)--缺陷

基本概述

• 没有实现产品说明书要求的功能
• 出现了不该出现的功能
• 实现了说明书没有提到的功能
• 没有实现说明书未提及但是应该实现的目标
• 软件不易使用，难以理解，运行缓慢

属性

类型

功能，界面，文档，软件包，性能，接口

• 需求分析、设计阶段，文档类型的缺陷多，
• 集成测试阶段，接口缺陷多，
• 系统测试阶段，功能界面类型多，
• 验收测试，性能缺陷，
• 实施过程，软件包缺陷

严重程度

致命，严重，一般，较小

优先级

立即解决，高优先级，正常排队，低优先级

严重程度和优先级没有直接关系

状态

• 激活、打开：问题还没有解决，确认提交的缺陷，等待处理
• 确认：确认提交的缺陷是一个真实有效的缺陷
• 已修复：开发人员对缺陷进行了修复
• 关闭：缺陷修复后，测试人员测试通过
• 重新打开：缺陷修复后，测试人员测试没有通过，继续修复
• 推迟：此版本或此迭代不进行修复，需要与开发人员等确认
• 保留：暂时无法修复的缺陷
• 不能重现：使用上报的复现步骤无法复现。偶发性，系统问题
• 需要更多信息：开发人员根据上报文件无法复现
• 重复：已经提交的缺陷
• 不是缺陷：！不能出现！
• 需要修改需求：需求问题造成的缺陷

来源

需求说明书、设计文档、接口、数据库、程序代码

根源

发生错误的根本因素
测试策略，过程、工具、方法，团队，缺乏组织和沟通，硬件，软件，工作环境

生命周期

发现–提交–确认–分配–修复–验证

识别

识别依据

• 测试用例的预期结果
• 需求说明文档
• 用户手册等文档
• 同类成熟商业软件
• 开发人员沟通
• 有经验的测试人员
• 同行业隐式需求

报告

编号，模块，优先级，严重程度，缺陷概述，详细描述，提交人，备注（复现过程，数据等）

编写目的

• 易于搜索
• 更具体准确的缺陷描述
• 开发人员获得特征和复现步骤
• 市场或其他部门获得缺陷类型分布和影响程度

准则

准确，清晰，简洁，完整，一致

缺陷描述准则

单一准确，可以复现，完整统一，短小精炼，特定条件，补充完善，不做评价