19 软件测试技术与测试实训教程讲座(19 ) 第19章 软件缺陷测试和测试评估 v1 2学时.ppt

19 软件测试技术与测试实训教程讲座(19 ) 第19章 软件缺陷测试和测试评估 v1 2学时.ppt

  1. 1、本文档共54页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
软件测试技术与测试实训教程 黎连业 王华 李龙 黎照 北京:机械工业出版社 2012.05 第19讲:第19章 软件缺陷测试和测试评估 在程序中存在的软件缺陷如文档缺陷、代码缺陷、测试缺陷、过程缺陷,软件缺陷导致系统或部件不能实现其功能,引起系统的失效。对软件缺陷测试和测试评估是不可缺少的、相当重要的。本章重点讨论以下内容: ★ 软件缺陷的概述; ★ 软件缺陷的生命周期; ★ 软件缺陷的跟踪管理; ★ 软件测试的评估。 19.1 软件缺陷的概述 19.1.1 软件缺陷的定义 缺陷(bug)是指程序中存在的错误如语法错误、拼写错误或者是一个不正确的程序语句,缺陷可能出现在设计中,甚至在需求、规格说明或其他的文档中。软件缺陷导致系统或部件不能实现其功能,引起系统的失效。缺陷定义为: ★ 软件没有达到产品说明书表明的功能; 程序中存在语法错误; 程序中存在拼写错误; ★ 程序中存在不正确的程序语句; 软件出现了产品说明书中不一致的表现; 软件功能超出产品说明书的范围; 软件没有达到用户期望的目标; 测试员或用户认为软件的易用性差。 按照定义,将缺陷分为文档缺陷、代码缺陷、测试缺陷、过程缺陷。 ★ 文档缺陷 文档缺陷是指对文档的静态检查过程中发现的缺陷,通过测试需求分析、文档审查对被分析或被审查的文档发现的缺陷; ★ 代码缺陷 代码缺陷是指对代码进行同行评审、审计或代码走查过程中发现的缺陷; ★ 测试缺陷  测试缺陷是指由测试执行活动发现的被测对象(被测对象一般是指可运行的代码、系统,不包括静态测试发现的问题)的缺陷,测试活动主要包括内部测试、连接测试、系统集成测试、用户验收测试,测试活动中发现的缺陷为测试缺陷; ★ 过程缺陷  过程缺陷是指通过过程审计、过程分析、管理评审、质量评估、质量审核等活动发现的关于过程的缺陷和问题。过程缺陷的发现者一般是质量经理、测试经理、管理人员。 19.1.2软件缺陷的特征 软件缺陷的特征主要有如下7点内容: ★单一准确 每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常常会导致缺陷部分被注意和修复,不能得到彻底的修正。 ★可以再现(要求软件缺陷具有精确的步骤) 提供缺陷的精确操作步骤,容易看懂再现这个缺陷。 ★完整统一 提供完整、前后统一的软件缺陷的步骤和信息如:图片信息,Log文件等。 ★短小简练 通过使用关键词,使软件缺陷的标题的描述简练,准确解释产生缺陷的现象。如 “主页”、“导航栏”、“分辨率”等关键词。 ★特定条件 软件功能在通常情况下没有问题,而是在某种特定条件下会存在缺陷,所以软件缺陷描述不要忽视特定条件如特定的操作系统、浏览器或某种设置等。 ★补充完整 测试人员发现bug 要保证它被正确的报告,并且得到应有的重视,继续监视其修复的全过程。 ★不做评价 在软件缺陷描述不要带有个人观点对开发人员进行评价。软件缺陷报告是针对产品、针对问题本身,将事实或现象客观地描述出来就可以,不需要任何对开发人员评价或议论。 19.1.3 软件缺陷的类型 软件缺陷的类型分为:功能类、性能类、系统/模块接口类、用户界面类、数据处理类、流程类、提示信息类 软件包类、建议类、常识类、文档。软件缺陷类型如表19-1所示。 19.1.4 BUG 状态 缺陷状态是指缺陷通过一个跟踪修复过程的进展情况。???BUG 状态分为: ★ 激活或打开(Active or Open):问题还没有解决,存在源代码中,确认“提交的缺陷”,等待处理,如新报的缺陷。 ★ 已提交:测试员发现 BUG 后提交到 BUG 管理系统中的状态(初始状态)。 ★? 已修改(Fixed or Resolved):已被程序员检查、修复过的缺陷,通过单元测试,认为已解决但还没有被测试人员验证提交到 BUG 管理系统中的状态。 ★? 不修改(保留):程序员或项目经理根据需求分析、概要设计、详细设计说明书等上的要求经过考虑后决定对 BUG 不进行修改(由于技术原因或第三者软件的缺陷,开发人员不能修复的缺陷),其 BUG 的状态为不修改。 ★ 延迟:根据目前项目进程或计划等情况,暂时延期的状态,缺陷可以在下一个版本中解决。 ★ 待讨论:需要进行讨论后才能决定是否需要修改的 BUG 的状态。 ★? 已验证:已经解决的并经过测试员复测的 BUG 的状态。 ★? 关闭:完全解决了,只供以后备查的状态 ★ 重新打开:测试人员验证后,还依然存在的缺陷,等待开发人员进一步修复,重新打开以前关闭的 bug 状态?? (在 bug 工具中,可以自己定制适合项目的状态项目,比如废除,拒绝等 ) 。 19.1.5 BUG 的等级划分与优先级

文档评论(0)

word.ppt文档 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档