19报告所发现的缺陷.ppt

软件测试方法和技术 - Ch.15报告所发现的软件缺陷 第十五章 报告所发现的软件缺陷 软件缺陷的描述 软件缺陷的基本描述 软件缺陷的描述是软件缺陷报告中测试人员对问题的陈述的一部分并且是软件缺陷报告的基础部分。同时，软件缺陷的描述也是测试人员就一个软件问题与开发小组交流的最初且最好的机会。一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。 软件缺陷的基本描述 缺陷描述 无论何时在登录对话框中输入一串随机字符，软件都开始进行一些奇怪的动作。 软件缺陷的有效描述规则 单一准确 ：每个报告只针对一个软件缺陷，在一个报告中报告多个软件缺陷的弊端常常是只有其中一个软件缺陷得到注意和修复 例 登录对话框不接受大写字母输入的口令或者登录ID号 可以再现 完整统一：提供完整、前后统一的软件缺陷的修复步骤和信息 短小简练：只解释事实和演示、描述软件缺陷必需的细节。 软件缺陷的有效描述规则 特定条件 例：搜索功能在没有找到结果返回时跳转页面不对 补充完善==〉对软件缺陷跟踪到底 从发现软件缺陷的那一刻起，测试员的责任就是保 证它被正确的报告，并且得到应有的重视，继续监 视其修复的全过程。 不做评价 软件缺陷报告是针对产品的，软件缺陷描述不要带 有个人观点，不要对开发人员进行评价 尽快报告软件缺陷 RAID/BMS的基本功能 完整的Bug数据库 整个产品组的中央记录和控制 强大的查询功能，有效地跟踪项目的状态 所有的记录无法删除，对于每个记录只能一直添加内容 丰富的报表功能，为产品发布提供判断标准 软件缺陷类型 缺陷类型：是根据缺陷的自然属性划分缺陷种类。 软件缺陷缺陷严重程度 缺陷严重程度：是指因缺陷引起的故障对软件产品的影响程度，所 谓“严重性”指的是在测试条件下，一个错误在系统中的绝对影响。 软件缺陷缺陷产生的可能性 缺陷产生的可能性：指缺陷在产品中发生的可能性，通常可以用频率来表示。 软件缺陷缺陷产生的优先级 缺陷优先级：指缺陷必须被修复的紧急程度。“优先级”的衡量抓住了在严重性中没有考虑的重要程度因素。 软件缺陷缺陷状态 缺陷状态：指缺陷通过一个跟踪修复过程的进展情况，也就是在软件生命周期中的状态基本定义 软件缺陷起源 缺陷起源：缺陷引起的故障或事件第一次被检测到的阶段 软件开发的基本过程 RAD - V Model (改进) 软件缺陷起源 软件缺陷来源 缺陷来源：指缺陷所在的地方，如文档、代码等 软件缺陷缺陷根源 缺陷根源：指造成上述错误的根本因素，以寻求软件开发流程的改进、管理水平的提高。 分离和再现软件缺陷 假定有一个画图程序的简单测试用例，检查绘画可以使用的所有颜色。如果每次选择红色，程序都用绿色绘画，这就是明显的、通用的和可再现的软件缺陷 分离和再现软件缺陷 为了有效地再现软件缺陷，除了按照软件缺陷的有效描述规则来描述软件缺陷，还要遵循软件缺陷分离和再现的方法。 不要想当然地接受任何假设，确保所有的步骤都被记录。 特定条件和时间。 压力和负荷、内存和数据溢出相关的边界条件。 考虑资源依赖性包括内存、网络和硬件共享的相互作用等。 不能忽视硬件。与软件不同，硬件不按预定方式工作。 分离和再现软件缺陷 如果尽最大努力分离软件缺陷，也无法用简明的步骤再现，那么仍然需要记录软件缺陷，以免跟丢了 软件缺陷的处理和跟踪 缺陷跟踪管理的目标： 确保每个被发现的缺陷都能够被解决，“解决”的意思不一定是被修正，也可能是其他处理方式； 收集缺陷数据并根据缺陷趋势曲线识别测试处于测试过程中的哪个阶段； 决定测试过程是否结束，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。 收集缺陷数据并在其上进行数据分析，作为组织过程改进的财富。 复杂的软件缺陷生命周期 Bugzilla操作流程 Bug的处理流程 测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，通过Email通知项目组长或直接通知开发者。 项目组长根据具体情况，重新reassigned分配给bug所属的开发者。 开发者收到E-Mail信息后，判断是否为自己的修改范围。 A.?若不是，重新reassigned分配给项目组长或应该分配的开发者； B.?若是，进行处理，resolved并给出解决方法。 测试人员查询开发者已修改的bug，进行重新测试。 A.?经验证无误后，修改状态为VERIFIED。待整个产品发布后，修改为CLOSED。 B.??还有问题，REOPENED，状态重新变为“New，并发邮件通知。 如果这个BUG一周内一直没被处理