2.4缺陷报告的产生过程
组织-重现-隔离-归纳-对比-总结-精简-消除歧义-中立-检查
• 组织Structure：测试人员应该采用深思熟虑的，小心谨慎的方法执 行测试，并且做详尽的记录。这样可以促使他们对测试下的系统有很 好的认识。当错误发生的时候，一个有组织的测试人员能够知道最早 出现问题的地方在哪；
1.软件缺陷
1.1软件缺陷的含义
什么是软件缺陷？ 不满足用户确定需求 简单的说就是存在于软件（文档、数据、程序）之中的那些不希 望，或不可接受的偏差，而导致软件产生的质量问题。按照一般的定 义，只要符合下面5个规则中的一个，就叫做软件缺陷。
可称之为软件缺陷的五个规则： • 软件未达到产品说明书标明的功能 • 软件出现了产品说明书指明不会出现的错误 • 软件功能超出产品说明书指明范围 • 软件未达到产品说明书虽未指出但应达到的目标 • 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终
Word里保存一个文件，你可以要求用户到File菜单并且点击Save子 菜单项。你也可以只说“保存文件”；
• 如果bug是随机出现的，只需在bug report中说一下就可以了。但是 不要忘记归档它；
• 写下问题可以被重现的平台； • 遇到几个问题却有一样的结果，只需写一个bug report； • 截屏
• 检查Review：一旦编写好bug report，作者应该再次阅读，确保 符合缺陷报告的写作准则,然后提交至Bug管理工具中。同时，也可以 在测试人员之间互相检查，完善后再提交。在允许的时间里，测试小 组应该尽可能提交最好的bug report。
2.5缺陷报告写作过程中注意事项
• 标题应该保持简短、准确、易于理解，提供缺陷的本质信息，并且便 于读者搜索查寻；
• 消除歧义Disambiguate：测试人员在精简空话的同时或其之后随 即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量 避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述 事实，清楚的，不会产生争执的词语;
• 中立Neutralize：如同所有的错误总结一样，独立的bug report在 措辞方面应该保持公正。攻击开发人员，指责潜在的错误，企图诙谐 或使用挖苦将引起开发人员的憎恶，并且使注意力从“提高产品质量” 这个大的目标上转移开了。谨慎的测试人员只用Bug report来描述 事实;
2.3怎样有效记录缺陷
• 保证缺陷重现 • 分析故障——使用最少步骤复现故障 • 包含所有重现缺陷的必要步骤 • 方便阅读 • 尽量简单——一个缺陷一个报告 • 注意自己的语气 • 报告随机缺陷
• 不夸大缺陷 • 报告小缺陷 • 及时报告缺陷 • 引用别人报告不要擅自修改 • 缺陷报告中注明姓名和日期
• 归纳Generalize：在测试人员发现了一个已隔离的，可重现的问题 后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他 的地方？同一个故障是否有更加严重的问题;
• 对比Compare：如果测试人员验证过现在出错的测试用例，那么他 就应该检查以前的测试结果以检查相同的条件是否通过以前的测试。 如果是的话， 那么这个问题就象是一个回归的错误。注意由于同一 测试条件有可能出现在多个测试用例中，这个步骤就不仅仅只是检查 一个测试用例在以前的多个结果；
• 使用委婉的说法：“混乱的UI”可以被温和些改为“不正确的UI”； 避免使用： “我（I）”“你(You)” 情绪化的语言和强调符号！！！ “似乎” “看上去可能” 认为比较幽默的内容 不确定的测试问题
• 清楚的列出前提条件； • “可重现的步骤”的流程应该是合乎逻辑的； • “可重现的步骤”应该详尽。例如，如果你想用户在Microsoft
1.4软件缺陷的分布（主要在于产品的描述及说明书）
1.5如何确认缺陷
• 判断发现的问题是否是缺陷的方法 – 通过参考文档来确认缺陷 – 通过了解软件产品的行业背景（或参考同类典型软件）来发现缺 陷
– 通过沟通来确认和识别缺陷
1.6缺陷报告的读者
在书写软件缺陷报告之前，需要明白谁是缺陷报告的读者对象， 知道读者最希望从缺陷报告中获得什么信息。通常，
• 重现Reproduce：测试人员在编写bug report之前必须在检查问题 是否可重现。如果错误不可再重现，仍然应该写下来，但是必须说明 问题的偶然性。一个好的处理原则就是在编写bug report之前反复尝 试3次；
• 隔离Isolate：在尝试编写bug report之前，必须试着隔离错误。可 以采用改变一些变量的方法，如系统的配置，它可能会改变错误的症 状。这些信息可以为开发人员着手调试提供思路；
响程度。
2.软件缺陷报告
2.1衡量缺陷报告质量的标准
• 对管理层来说，是清晰明了的，特别是在概要这一级； • 对于开发部门是有用的，主要是给出能够让开发人员高效地调试问题
的相关信息 • 可以使测试人员很快的将bug从“Opened”状态转变成“Closed”状
态，减少从开发人员打回的差的bug report并导致测试人员返工的时
作用？
文单词长度设置连字符。
段落调整出现错误状态
描述太笼统。不正确的行为 选定两个单词，启动单词“字
是什么？
间距”自动调整后间隔排版错
误。
警告：该命令产生了错误的 没有包含原因与结果信息。 更新位图图像保存到服务器时，
结果。
描述内容太长。
警告：“错误”。
在鼠标点击执行每一个拷贝 没有指明原因与结果，包含 拷贝和复制功能执行效率低。 或复制的编辑功能之后，响 了过分详细的细节信息。 应时间很长。
• 总结Summarize：在bug report的第一行写上错误的总结是非常 关键的。测试人员要思考已发现的错误对客户有何影响。这不仅仅要 求测试人员编写的报告要能够吸引读者，可以和读者沟通清晰，还要 能够帮助设置错误修复的优先级别;
• 精简Condense：在bug report的初稿完成后，测试人员应该反复 阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明 和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要 的步骤而消磨报告欢迎程度的无穷唠叨都不是bug report的目标;
• 缺陷报告的直接读者是软件开发人员和质量管理人员； • 来自市场和技术支持等部门的人员
读者希望从软件缺陷报告中得到的内容 • 易于搜索软件测试报告的缺陷； • 报告的软件缺陷进行了必要的隔离，报告的缺陷信息具体、准确； • 软件开发人员希望获得缺陷的本质特征和复现步骤； • 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影
用户认为不好
1.2软件缺陷的属性
属性名称
缺陷标识(Identifier)
缺陷类型 (Type) 缺陷严重程度 (Severity) 缺陷优先级 (Priority) 缺陷状态(Status) 缺陷起源(Origin)
描述 缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一 个唯一的标识 缺陷类型是根据缺陷的自然属性划分的缺陷种类。 缺陷严重程度是指因缺陷引起的故障对软件产品的影响程 度。
软件缺陷报告
分享目录
• 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缺陷报告写作过程中注意事项
缺陷的优先级指缺陷必须被修复的紧急程度。
缺陷状态指缺陷通过一个跟踪修复过程的进展情况。 缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。
缺陷来源(Source) 缺陷来源指引起缺陷的起因
缺陷根源 (Root Cause)
缺陷根源指发生错误的根本因素
1.3软件缺陷产生的原因
– 工期短，任务大； – 程序设计错误； – 文档不完善； – 需求不断变化； – 沟通交流不够； – 软硬件环境不完善； – 软件的复杂性
间。
2.2软件缺陷报告的准则
Correct（准确）：每个组成部分的描述准确，不会引起误解； Clear（清晰）：每个组成部分的描述清晰，易于理解； Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容； Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息； Consistent（一致）：按照一致的格式书写全部缺陷报告。
截屏是验证的一种方法。在截屏上写上注释以指出问题所在。这将帮 助开发人员一眼就可以马上定位问题；
尽量使用jpg或gif的格式，而不是bmp格式；
为了更好的传递缺陷图像的信息，图片的命名应该尽量与BUG内 容一致。
书写摘要的例子Байду номын сангаас
原始描述 英文单词的连字符不管用
错误原因
改进的标题
描述太笼统。什么时候不起 在行末尾换行时，不能根据英
插入的引号成为特殊符号。
信息没有充分隔离。所有的 在文档中插入一个智能引号成 引号都如此吗？什么类型的 为不可识别的字符串。 引号。