软件缺陷报告.pptVIP

软件缺陷报告;分享目录;1.软件缺陷 1.1软件缺陷的含义 什么是软件缺陷？ 不满足用户确定需求 简单的说就是存在于软件（文档、数据、程序）之中的那些不希 望，或不可接受的偏差，而导致软件产生的质量问题。按照一般的定 义，只要符合下面5个规则中的一个，就叫做软件缺陷。; 可称之为软件缺陷的五个规则： 软件未达到产品说明书标明的功能 软件出现了产品说明书指明不会出现的错误 软件功能超出产品说明书指明范围 软件未达到产品说明书虽未指出但应达到的目标 软件测试???认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好;属性名称;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的第一行写上错误的总结是非常关键的。测试人员要思考已发现的错误对客户有何影响。这不仅仅要求测试人员编写的报告要能够吸引读者，可以和读者沟通清晰，还要能够帮助设置错误修复的优先级别; ;精简Condense：在bug report的初稿完成后，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是bug report的目标; 消除歧义Disambiguate：测试人员在