`
lujar
  • 浏览: 496659 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论

第25回 准确报告软件缺陷

阅读更多

        软件缺陷的描述是是软件缺陷报告的基础部分,也是测试人员就一个软件问题与开发小组交流的最初且最好的机会。一个好的描述,需要使用简单的、准确的、专业的语言来抓住缺陷的本质。否则,它就会使信息含糊不清,可能会误导开发人员。准确报告软件缺陷是非常重要的,因为:
  • 清晰准确的软件缺陷描述可以减少软件缺陷从开发人员返回的数量
  • 提高软件缺陷修复的速度,使每一个小组能够有效的工作
  • 提高测试人员的信任度,可以得到开发人员对清晰的软件缺陷描述有效的响应
  • 加强开发人员,测试人员和管理人员的协同工作,让他们可以更好的工作

在多年实践的基础上,我们积累了较多的软件缺陷的有效描述规则,主要是:
  • 单一准确。每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常常会导致缺陷部分被注意和修复,不能得到彻底的修正。
  • 可以再现。提供缺陷的精确操作步骤,使开发人员容易看懂,可以自己再现这个缺陷,通常情况下,开发人员只有再现了缺陷,才能正确地修复缺陷。
  • 完整统一。提供完整、前后统一的软件缺陷的步骤和信息,例如:图片信息,Log文件等。
  • 短小简练。通过使用关键词,可以使软件缺陷的标题的描述短小简练,又能准确解释产生缺陷的现象。如“主页的导航栏在低分辨率下显示不整齐”中“主页”、“导航栏”、“分辨率”等是关键词。
  • 特定条件。许多软件功能在通常情况下没有问题,而是在某种特定条件下会存在缺陷,所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件(如特定的操作系统、浏览器或某种设置等),能够提供帮助开发人员找到原因的线索。如“搜索功能在没有找到结果返回时跳转页面不对”。
  • 补充完善。从发现bug那一刻起,测试人员的责任就是保证它被正确的报告,并且得到应有的重视,继续监视其修复的全过程。
  • 不做评价。在软件缺陷描述不要带有个人观点,对开发人员进行评价。软件缺陷报告是针对产品、针对问题本身,将事实或现象客观地描述出来就可以,不需要任何评价或议论。
      
         软件缺陷属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。

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

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

1软件缺陷类型列表<o:p></o:p>

缺陷类型<o:p></o:p>

描述<o:p></o:p>

功能<o:p></o:p>

影响了各种系统功能、逻辑的缺陷<o:p></o:p>

用户界面<o:p></o:p>

影响了用户界面、人机交互特性,包括屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷<o:p></o:p>

文档<o:p></o:p>

影响发布和维护,包括注释,用户手册,设计文档<o:p></o:p>

软件包<o:p></o:p>

由于软件配置库、变更管理或版本控制引起的错误<o:p></o:p>

性能<o:p></o:p>

不满足系统可测量的属性值,如执行时间,事务处理速率等。<o:p></o:p>

系统/模块接口<o:p></o:p>

与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。<o:p></o:p>

<!---->

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

<o:p></o:p>

2软件缺陷严重等级列表<o:p></o:p>

缺陷严重等级<o:p></o:p>

描述<o:p></o:p>

致命 (Fatal)<o:p></o:p>

系统任何一个主要功能完全丧失、用户数据受到破坏、系统崩溃悬挂、死机,或者危及人身安全<o:p></o:p>

严重 (Critical)<o:p></o:p>

系统的主要功能部分丧失、数据不能保存,系统的次要功能完全丧失系统所提供的功能或服务受到明显的影响<o:p></o:p>

一般 (Major)<o:p></o:p>

系统的次要功能没有完全实现,但不影响用户的正常使用。例如:提示信息不太准确;或用户界面差、操作时间长等一些问题。<o:p></o:p>

较小 (Minor)<o:p></o:p>

使操作者不方便或遇到麻烦,但它不影响功能的操作和执行,如个别的不影响产品理解的错别字、文字排列不对齐等一些小问题。<o:p></o:p>

<o:p> </o:p>
 4. 缺陷产生的可能性:指缺陷在产品中发生的可能性,通常可以用频率来表示,如3所示。


<o:p></o:p><!---->

3 缺陷产生可能性列表<o:p></o:p>

缺陷产生可能性<o:p></o:p>

描述<o:p></o:p>

总是 (Always)<o:p></o:p>

总是产生这个软件缺陷,其产生的频率是100%<o:p></o:p>

通常 (Often)<o:p></o:p>

按照测试用例,通常情况下会产生这个软件缺陷,其产生的频率大概是80-90%<o:p></o:p>

有时 (Occasionally)<o:p></o:p>

按照测试用例,有的时候产生这个软件缺陷,其产生的频率大概是30-50%<o:p></o:p>

很少 (rarely)<o:p></o:p>

按照测试用例,很少产生这个软件缺陷,其产生的频率大概是1-5%<o:p></o:p>

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


<o:p></o:p><!---->

4 软件缺陷优先级列表<o:p></o:p>

缺陷优先级<o:p></o:p>

描述<o:p></o:p>

立即解决(P1)<o:p></o:p>

缺陷导致系统几乎不能使用或测试不能继续,需立即修复<o:p></o:p>

高优先级(P2级)<o:p></o:p>

缺陷严重,影响测试,需要优先考虑<o:p></o:p>

正常排队(P3级)<o:p></o:p>

缺陷需要正常排队等待修复<o:p></o:p>

低优先级(P4级)<o:p></o:p>

缺陷可以在开发人员有时间的时候被纠正。<o:p></o:p>


     一般来讲,缺陷严重等级和缺陷优先级相关性很强,但是,具有低优先级和高严重性的错误是可能的,反之亦然。例如,产品徽标是重要的,一旦它丢失了,这种缺陷是用户界面的产品缺陷,但是它阻碍产品的形象。那么它是优先级很高的软件缺陷。<o:p></o:p>
<o:p> </o:p>
6. 缺陷状态:指缺陷通过一个跟踪修复过程的进展情况,也就是在软件生命周期中的状态基本定义,如表5所示。


<o:p></o:p><!---->

5 软件缺陷状态列表<o:p></o:p>

缺陷状态<o:p></o:p>

描述<o:p></o:p>

激活 打开<o:p></o:p>

Active or Open<o:p></o:p>

问题还没有解决,存在源代码中,确认“提交的缺陷”,等待处理,如新报的缺陷。 <o:p></o:p>

已修正 修复<o:p></o:p>

(Fixed or Resolved)<o:p></o:p>

已被开发人员检查、修复过的缺陷,通过单元测试,认为已解决但还没有被测试人员验证 <o:p></o:p>

关闭或非激活

(Close or Inactive)<o:p></o:p>

测试人员验证后,确认缺陷不存在之后的状态。<o:p></o:p>

重新打开<o:p></o:p>

测试人员验证后,还依然存在的缺陷,等待开发人员进一步修复<o:p></o:p>

推迟<o:p></o:p>

这个软件缺陷可以在下一个版本中解决<o:p></o:p>

保留<o:p></o:p>

由于技术原因或第三者软件的缺陷,开发人员不能修复的缺陷<o:p></o:p>

不能重现<o:p></o:p>

开发不能复现这个软件缺陷,需要测试人员检查缺陷复现的步骤。<o:p></o:p>

需要更多信息<o:p></o:p>

开发能复现这个软件缺陷,但开发人员需要一些信息,例如:缺陷的日志文件,图片等。<o:p></o:p>

  <o:p></o:p> 
7. 缺陷来源指缺陷所在的地方,如文档、代码等,如表6所示。


<!---->

6 软件缺陷来源列表

缺陷来源<o:p></o:p>

描述<o:p></o:p>

需求说明书<o:p></o:p>

需求说明书的错误、或不清楚引起的问题<o:p></o:p>

设计文档<o:p></o:p>

设计文档描述不准确、和需求说明书不一致的问题<o:p></o:p>

系统集成接口<o:p></o:p>

系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷<o:p></o:p>

数据流()<o:p></o:p>

由于数据字典、数据库中的错误引起的缺陷<o:p></o:p>

程序代码<o:p></o:p>

纯粹在编码中的问题所引起的缺陷<o:p></o:p>

<o:p> </o:p>

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


<o:p></o:p><!---->

7 软件缺陷列表<o:p></o:p>

缺陷<o:p></o:p>

描述<o:p></o:p>

测试策略<o:p></o:p>

错误的测试范围,误解了测试目标,超越测试能力等<o:p></o:p>

过程,工具和方法<o:p></o:p>

无效的需求收集过程,过时的风险管理过程,不适用的项目管理方

分享到:
评论

相关推荐

    准确报告软件缺陷

    软件缺陷的描述是是软件缺陷报告的基础部分,也是测试人员就一个软件问题...准确报告软件缺陷是非常重要的,因为:  清晰准确的软件缺陷描述可以减少软件缺陷从开发人员返回的数量  提高软件缺陷修复的速度,使每一个

    软件缺陷报告模板

    严重性(Severity)顾名思义就是软件缺陷对软件质量的破坏程度,即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。 在软件测试中,软件缺陷的严重性的判断应该从软件最终用户的观点做出判断,即判断缺陷的严重...

    软件测试文档缺陷报告

    软件测试报告文档,缺陷报告,软件测试报告模板

    软件缺陷软件缺陷

    软件缺陷软件缺陷软件缺陷

    软件测试缺陷报告实用写作技术

    软件测试缺陷报告实用写作技术,软件测试缺陷报告实用写作技术

    6软件缺陷报告模板.docx

    6软件缺陷报告模板

    软件测试缺陷报告模板

    软件测试缺陷报告模板

    论文研究-软件缺陷报告严重性属性分析.pdf

    软件缺陷报告的严重性对缺陷的解决具有关键作用。随着软件规模的不断扩大,使用开源的软件缺陷跟踪系统成为海量缺陷信息数据的主要处理方法。分析缺陷报告严重性在数据仓库中的作用,是处理软件缺陷的重要内容。通过...

    软件测试缺陷报告 范例

    缺陷报告 范例 样本 缺陷记录 公司缺陷报告相应的信息

    NASA MDP 软件缺陷数据集.zip

    1、NASA MDP 软件缺陷数据集介绍:软件缺陷预测研究中心广泛应用NASA公布的NASA IV&V Facility Metrics Data Program(MDP)数据集。 MDP包括 13个不同的数据集,这些数据均来自NASA 的13个实际软件项目,由最常见的...

    软件缺陷及缺陷报告

    详细的讲述了软件缺陷的具体内容,缺陷产生原因以及识别软件缺陷的方法,同时也写明如何编写缺陷报告。

    软件测试缺陷记录.xls

    缺陷记录及报告

    软件测试——缺陷密度、缺陷数据分析的重要性、缺陷数据分析的数据指标

    缺陷密度 基本的缺陷测量是以每千行代码的缺陷数(个/KLOC)来测量的称为... 根据测试人员报告缺陷的数量和准确性,评估测试有效性和测试技能 根据报告的缺陷修复是否及时,改进软件开发与测试的关系,使测试与开发

    软件缺陷和缺陷报告.ppt

    关于软件测试报告和缺陷的分级优先级,概念等,详细说明的软件测试过程的问题!

    2 软件缺陷.pptx

    √软件缺陷的基本描述 √软件缺陷等级 √软件缺陷生命周期 √软件缺陷处理技巧 ...那么准确有效的定义和描述软件缺陷,可以使软件缺陷得以快速修复,节约了软件测试项目的成本和资源,提高产品质量

    开源软件源代码安全缺陷分析报告

    开源软件源代码安全缺陷分析报告

    软件缺陷模式与测试

    本书主要介绍软件缺陷模式...第1章 软件缺陷与软件缺陷模式 第2章 故障模式 第3章 安全漏洞模式 第4章 疑问及规则模式 第5章 基于缺陷模式的测试技术 第6章 区间运算技术 第7章 路径敏感分析技术 第8章 函数间分析技术

Global site tag (gtag.js) - Google Analytics