- 1、本文档共23页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
软件缺陷报告 分享目录 1.软件缺陷 1.1软件缺陷的含义 1.2软件缺陷的属性 1.3软件缺陷产生的原因 1.4软件缺陷的分布 1.5如何确认缺陷 1.6软件缺陷的读者 1.6.1读者希望从软件缺陷报告中得到的内容 2.软件缺陷报告 2.1衡量缺陷报告质量的标准 2.2软件缺陷的写作准则 2.3怎样有效记录缺陷 2.4缺陷报告的产生过程 2.5缺陷报告写作过程中注意事项 1.软件缺陷 1.1软件缺陷的含义 什么是软件缺陷? 不满足用户确定需求 简单的说就是存在于软件(文档、数据、程序)之中的那些不希 望,或不可接受的偏差,而导致软件产生的质量问题。按照一般的定 义,只要符合下面5个规则中的一个,就叫做软件缺陷。 可称之为软件缺陷的五个规则: 软件未达到产品说明书标明的功能 软件出现了产品说明书指明不会出现的错误 软件功能超出产品说明书指明范围 软件未达到产品说明书虽未指出但应达到的目标 软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好 1.2软件缺陷的属性 1.3软件缺陷产生的原因 工期短,任务大; 程序设计错误; 文档不完善; 需求不断变化; 沟通交流不够; 软硬件环境不完善; 软件的复杂性 1.4软件缺陷的分布(主要在于产品的描述及说明书) 1.5如何确认缺陷 判断发现的问题是否是缺陷的方法 通过参考文档来确认缺陷 通过了解软件产品的行业背景(或参考同类典型软件)来发现缺陷 通过沟通来确认和识别缺陷 1.6缺陷报告的读者 在书写软件缺陷报告之前,需要明白谁是缺陷报告的读者对象,知道读者最希望从缺陷报告中获得什么信息。通常, 缺陷报告的直接读者是软件开发人员和质量管理人员; 来自市场和技术支持等部门的人员 读者希望从软件缺陷报告中得到的内容 易于搜索软件测试报告的缺陷; 报告的软件缺陷进行了必要的隔离,报告的缺陷信息具体、准确; 软件开发人员希望获得缺陷的本质特征和复现步骤; 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度。 2.软件缺陷报告 2.1衡量缺陷报告质量的标准 对管理层来说,是清晰明了的,特别是在概要这一级; 对于开发部门是有用的,主要是给出能够让开发人员高效地调试问题的相关信息 可以使测试人员很快的将bug从“Opened”状态转变成“Closed”状态,减少从开发人员打回的差的bug report并导致测试人员返工的时间。 2.2软件缺陷报告的准则 Correct(准确):每个组成部分的描述准确,不会引起误解; Clear(清晰):每个组成部分的描述清晰,易于理解; Concise(简洁):只包含必不可少的信息,不包括任何多余的内容; Complete(完整):包含复现该缺陷的完整步骤和其他本质信息; Consistent(一致):按照一致的格式书写全部缺陷报告。 2.3怎样有效记录缺陷 保证缺陷重现 分析故障——使用最少步骤复现故障 包含所有重现缺陷的必要步骤 方便阅读 尽量简单——一个缺陷一个报告 注意自己的语气 报告随机缺陷 不夸大缺陷 报告小缺陷 及时报告缺陷 引用别人报告不要擅自修改 缺陷报告中注明姓名和日期 2.4缺陷报告的产生过程 组织-重现-隔离-归纳-对比-总结-精简-消除歧义-中立-检查 组织Structure:测试人员应该采用深思熟虑的,小心谨慎的方法执行测试,并且做详尽的记录。这样可以促使他们对测试下的系统有很好的认识。当错误发生的时候,一个有组织的测试人员能够知道最早出现问题的地方在哪; 重现Reproduce:测试人员在编写bug report之前必须在检查问题是否可重现。如果错误不可再重现,仍然应该写下来,但是必须说明问题的偶然性。一个好的处理原则就是在编写bug report之前反复尝试3次; 隔离Isolate:在尝试编写bug report之前,必须试着隔离错误。可以采用改变一些变量的方法,如系统的配置,它可能会改变错误的症状。这些信息可以为开发人员着手调试提供思路; 归纳Generalize:在测试人员发现了一个已隔离的,可重现的问题后,应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的地方?同一个故障是否有更加严重的问题; 对比Compare:如果测试人员验证过现在出错的测试用例,那么他就应该检查以前的测试结果以检查相同的条件是否通过以前的测试。如果是的话, 那么这个问题就象是一个回归的错误。注意由于同一测试条件有可能出现在多个测试用例中,这个步骤就不仅仅只是检查一个测试用例在以前的多个结果; 总结Summarize:在bug report的第一行写上错误的总结是非常关键的。测试人员要思考已发现的错误对客户有何影响。这不仅仅要求测试人员编写的报告要能够吸引读者,可
文档评论(0)