软件缺陷报告

软件缺陷报告1/23分享目录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缺陷报告写作过程中注意事项2/231.软件缺陷1.1软件缺陷含义什么是软件缺陷？ 不满足顾客确定需求 简单说就是存在于软件（文档、数据、程序）之中那些不希望，或不可接收偏差，而造成软件产生质量问题。按照一般定义，只要符合下面5个规则中一种，就叫做软件缺陷。3/23 可称之为软件缺陷五个规则：软件未达成产品说明书标明功能软件出现了产品说明书指明不会出现错误软件功能超出产品说明书指明范围软件未达成产品说明书虽未指出但应达成目标软件测试员以为软件难以理解、不易使用、运行速度迟缓，或者最后顾客以为不好4/23属性名称描述缺陷标识(Identifier)缺陷标识是标识某个缺陷一组符号。每个缺陷必须有一个唯一标识缺陷类型(Type)缺陷类型是根据缺陷自然属性划分缺陷种类。缺陷严重程度(Severity)缺陷严重程度是指因缺陷引发故障对软件产品影响程度。缺陷优先级(Priority)缺陷优先级指缺陷必须被修复紧急程度。缺陷状态(Status)缺陷状态指缺陷通过一种跟踪修复过程进展情况。缺陷起源(Origin)缺陷起源指缺陷引发故障或事件第一次被检测到阶段。缺陷起源(Source)缺陷起源指导起缺陷起因缺陷本源(RootCause)缺陷本源指发生错误主线原因1.2软件缺陷属性5/231.3软件缺陷产生原因工期短，任务大；程序设计错误；文档不完善；需求不停变化；沟通交流不够；软硬件环境不完善；软件复杂性6/231.4软件缺陷分布（主要在于产品描述及说明书）7/231.5如何确认缺陷判断发觉问题是否是缺陷办法通过参照文档来确认缺陷通过理解软件产品行业背景（或参照同类典型软件）来发觉缺陷通过沟通来确认和识别缺陷8/231.6缺陷报告读者

在书写软件缺陷报告之前，需要明白谁是缺陷报告读者对象，懂得读者最希望从缺陷报告中取得什么信息。一般，缺陷报告直接读者是软件开发人员和质量管理人员；来自市场和技术支持等部门人员9/23 读者希望从软件缺陷报告中得到内容易于搜索软件测试报告缺陷；报告软件缺陷进行了必要隔离，报告缺陷信息详细、精确；软件开发人员希望取得缺陷本质特性和复现步骤；市场和技术支持等部门希望取得缺陷类型分布以及对市场和顾客影响程度。10/232.软件缺陷报告2.1衡量缺陷报告质量标准对管理层来说，是清楚明了，尤其是在概要这一级；对于开发部门是有用，主要是给出能够让开发人员高效地调试问题有关信息能够使测试人员很快将bug从“Opened”状态转变成“Closed”状态，减少从开发人员打回差bugreport并造成测试人员返工时间。11/232.2软件缺陷报告准则 Correct（精确）：每个组成部分描述精确，不会引发误解；

Clear（清楚）：每个组成部分描述清楚，易于理解；

Concise（简洁）：只包括必不可少信息，不包括任何多出内容；

Complete（完整）：包括复现该缺陷完整步骤和其他本质信息；

Consistent（一致）：按照一致格式书写所有缺陷报告。12/232.3如何有效统计缺陷确保缺陷重现分析故障——使用最少步骤复现故障包括所有重现缺陷必要步骤方便阅读尽可能简单——一种缺陷一种报告注意自己语调报告随机缺陷13/23不夸张缺陷报告小缺陷及时报告缺陷引用他人报告不要私自修改缺陷报告中注明姓名和日期14/232.4缺陷报告产生过程 组织-重现-隔离-归纳-对比-总结-精简-消除歧义-中立-检查15/23组织Structure：测试人员应当采取深思熟虑，小心谨慎办法执行测试，并且做详尽统计。这样能够促使他们对测试下系统有较好结识。当错误发生时候，一种有组织测试人员能够懂得最早出现问题地方在哪；重现Reproduce：测试人员在编写bugreport之前必须在检查问题是否可重现。假如错误不可再重现，仍然应当写下来，不过必须说明问题偶尔性。一种好处理标准就是在编写bugreport之前反复尝试3次；隔离Isolate：在尝试编写bugreport之前，必须试着隔离错误。能够采取变化某些变量办法，如系统配备，它也许会变化错误症状。这些信息能够为开发人员着手调试提供思绪；16/23归纳Generalize：在测试人员发觉了一种已隔离，可重现问题后，应当对问题进行归纳。同一种问题是否出目前其他模块或其他地方？同一种故障是否有愈加严重问题;对比Compare：假如测试人员验证过目前犯错测试用例，那么他就应当检查此前测试成果以检查相同条件是否通过此前测试。假如是话，那么这个问题就象是一种回归错误。注意由于同一测试条件有也许出目前多种测试用例中，这个步骤就不但仅只是检查一种测试用例在此前多种成果；总结Summarize：在bugreport第一行写上错误总结是非常关键。测试人员要思考已发觉错误对客户有何影响。这不但仅要求测试人员编写报告要能够吸引读者，能够和读者沟通清楚，还要能够帮助设置错误修复优先级别;17/23精简Condense：在bugreport初稿完成后，测试人员应当反复阅读它，集中剔除那些没有关系步骤或词语。隐含或含糊说明和那些由于对没有任何关系细节或者那些在重现错误过程中不需要步骤而消磨报告欢迎程度无穷唠叨都不是bugreport目标;消除歧义Disambiguate：测试人员在精简空话同步或其之后随后应当再认真检查报告是否有会产生误解地方。测试人员应当尽可能避免使用含糊，会产生歧义和主观词语。目标是使用能够表述事实，清楚，不会产生争执词语;中立Neutralize：犹如所有错误总结同样，独立bugreport在措辞方面应当保持公正。袭击开发人员，指责潜在错误，企图诙谐或使用讽刺将引发开发人员憎恶，并且使注意力从“提升产品质量”这个大目标上转移开了。谨慎测试人员只用Bugreport来描述事实;18/23检查Review：一旦编写好bugreport，作者应当再次阅读，确保符合缺陷报告写作准则,然后提交至Bug管理工具中。同步，也能够在测试人员之间互相检查，完善后再提交。在允许时间里，测试小组应当尽也许提交最佳bugreport。19/232.5缺陷报告写作过程中注意事项

标题应当保持简短、精确、易于理解，提供缺陷本质信息，并且便于读者搜索查寻；使用委婉说法：“混乱UI”能够被温和些改为“不正确UI”；避免使用：“我（I）”“你(You)” 情绪化语言和强调符号！！！ “似乎” “看上去也许” 以为比较风趣内容 不确定测试问题20/23清楚列出前提条件；“可重现步骤”流程应当是合乎逻辑；“可重现步骤”应当详尽。例如，假如你想顾客在MicrosoftWord里保存一种文献，你能够要求顾客到File菜单并且点击Save子菜单项。你也能够只说“保存文献”；假如bug是随机出现，只需在bugreport中说一下就能够了。不过不要忘掉归档它；写下问题能够被重现平台；遇到几个问题却有同样成果，只需写一种bugreport；截屏 截屏是验证一种办法。在截屏上写上注释以指出问题所在。这将帮助开发人员一眼就能够立即定位问题；

21/23尽可能使用jpg或gif格式，而不是bmp格式；为了更加好传递缺陷图像信息，图片命名应当尽可能与BUG内容一致。22/23书写摘要例子原始描述错误原因改善标题英文单词连字符无论用描述太笼统。什么时候不起作用？在行末尾换行时，不能根据英文单词长度设置连字符。段落调整出现错误状态描述太笼统。不正确行为是什么？选定两个单词，启动单词“字间距”自动调整后间隔排版错误。警告：该命令产生了