如何写一份优秀的软件缺陷报告

没错，任何软件都存在bug,哪怕是我们自己也存在缺陷，因为程序员也是普通人，人是会犯错误的。当有人在使用软件时遇到bug,你需要使用邮件形成一份缺陷bug,发送给开发人员。开发者可以依据该报告定位问题，复现问题，修复问题。

一些事

但是很多时候，开发人员很难理解提交上的缺陷报告，因为发送人并不了解我们需要的是什么，那如何与开发人员沟通以及如何写出一份缺陷报告，在这篇文章，我将教你如何写出一份清晰的缺陷报告能使开发者理解、复现、修复问题，这里下载缺陷报告模板。

一些事

为什么要发送缺陷报告

一些事

缺陷报告可以用很多方式来帮助我们的开发者。一些事

●他们能告知我们没有意识到的问题一些事

●他们能发现我们可能还没想到的新特性互联网的一些事

●他们能帮助我们感受到客户是如何使用我们的软件，以至于我们可以做的更好一些事

没有这些缺陷报告，我们就不知道出错的地方，我们需要它就像你唱歌跳舞时需要有软件的支持一样。一些事

什么时候发送缺陷报告

互联网的一些事

●简单来说就是越快越好，详细来说就是：

yixieshi

●当你看到一个错误消息时就发送错误报告一些事

●当屏幕是空白或者数据缺失就发送报告

yixieshi

●当程序没有出现预期的结果时发送报告一些事

●当程序崩溃、死机、没有响应或者响应很慢时发送报告

yixieshi

●当程序返回错误结果时发送报告yixieshi

●当你得不到想需要的结果时发送报告一些事

●如果你不清楚怎样做时发送报告一些事

●如果你不喜欢软件做的方式，或者软件老打搅你时，发送错报告yixieshi

●如果你想在系统中实现一个变通方案时发送报告

互联网的一些事

缺陷报告需要有哪些内容yixieshi

缺陷报告应该包含很多信息，你提供的信息越多效果越好，对于开发者，就像我，提供一个纯文本文件模板给你填充然后邮件发给我，当然也有表格形式的，但是最期待你自己杜撰一份然后发给我。下面是一些必须包括的部分以及如何写好每部分：

互联网的一些事

标题：创建一个简短的标题，让问题看起来更清晰。"应用崩溃"是一个很恼人的标题因为它没有足够的信息包括在这份报告里面。取而代之的是标题应该包含错误消息和消息码，或者是结果的名称以及失败时你正在做的事情。例如：Error 402:访问拒绝当点击"发送邮件"这个例子就提供了缺陷系统的上下文信息。

yixieshi

差："程序崩溃","报错","Bug" 互联网的一些事

好："从'Kifu'中打印时5C79错误","'Kifu honors'报表为空" 互联网的一些事

产品：用名称标识产品，告知你使用的是哪个版本。绝大部分软件都包含有版本信息。web应用的版本信息通常在页脚。一些事

差："你的应用"

yixieshi

好："Kifu v1.01″

互联网的一些事

平台：告诉我们软件运行在什么平台。尤其是操作系统的名字及版本和游览器名称版本。特别是web应用，这些信息对我们很重要。

yixieshi

差："Windows" 互联网的一些事

好："Windows7,IE9" 一些事

是否能重现：有些恼火的Bug是间歇性的出现，我们想预先知道，如果我们正在处理一个灵异事件或者正逢Bug出现时。

互联网的一些事

差：留空白

互联网的一些事

好："每次","偶然","不重现"

yixieshi

描述：这部分是很多人拿不定的地方，不知道怎么描述问题，在描述中做到包括下面的内容：一些事

●总结：用简洁的语言概括出Bug出现时你正在做的事情。从上下文开始，在操作应用的哪个部分。聚焦在你做的时候软件做了什么？

互联网的一些事

差："系统不能用了"

一些事

好：在"honor report"页面单击"打印按钮",但是报表是空的。一些事

●发生了什么：一步一步描述你做的事情当bug出现时，为什么你认为是错误的。事无巨细，打印出菜单的名称，页面标题，点击时的按钮或者链接的名称。做相同的操作是不是出现一样的错误。

yixieshi

差："空白报表" 互联网的一些事

好："点击'File/Save as…','Save'对话空弹出，然后点击'OK'按钮，但是文件没有保存"

一些事

●错误时什么：如果错误消息出现时，拷贝粘贴整个信息，这样更有利于我们跟踪错误。

一些事

差："有个错误，点击它始终读不出" yixieshi

好："Error 403:访问拒绝"

互联网的一些事

●复现的步骤：如果你可以让bug重现，那太好了，这能提供很大的帮助。一步步描述如何重现次bug. 互联网的一些事

差："打印没法使用"

互联网的一些事

好："从'Honors Report'页面，点击'打印按钮'"

yixieshi

●预期结果：描述你预期发生的结果当bug发生时，这部分特别有用如果程序没有按照你期待的结果发生时，因为它很诡异。

差："我期待能正常工作" 互联网的一些事

好："我期待能看到'Honors Reports'的PDF文件" 一些事

真实结果：当bug发生时是怎么发生的，什么错误，为什么有错，或者如果错误抛出，抛出什么错。

一些事

差："没法用"

yixieshi

好："我收到是空的PDF文件，或者'403错误，访问拒绝'" 一些事

●附件：如果你知道怎么截屏，做吧，附上一个简短的错误，截屏可以是错误之前或者发生错误之后，我们的开发者能够看到究竟发生了什么。如果应用有崩溃的日志，同样附上它。

互联网的一些事

●联系方式：附上你的名字和email,我们可以让你提交的报告及时的得到答复，在我

们不理解问题的描述时还能够询问你，如果你忘记附联系方式了，我们也就没法联

系到你，也没法修复bug.。

西安软件测试培训https://www.360docs.net/doc/4616550738.html,

如何高效填写软件缺陷报告

如何高效填写软件缺陷报告测试工程师需要利用对需求的理解、高效的执行力以及严密的逻辑推理能力，迅速找出软件中的潜在缺陷，并以缺陷报告的形式递交给开发团队。缺陷报告是测试工程师与开发工程师交流沟通的重要桥梁，也是测试工程师日常工作的重要输出。作为优秀的测试工程师，最基本的一项技能就是，把发现的缺陷准确无歧义地表达清楚。 “准确无歧义地表达”意味着，开发工程师可以根据缺陷报告快速理解缺陷，并精准定位问题。同时，通过这个缺陷报告，开发经理可以准确预估缺陷修复的优先级、产品经理可以了解缺陷对用户或业务的影响以及严重性。可见，缺陷报告本身的质量将直接关系到缺陷被修复的速度以及开发工程师的效率，同时还会影响测试工程师的信用、测试与开发人员协作的有效性。那么，如何才能写出一份高效的缺陷报告呢？或者说，一份好的缺陷报告需要包括哪些具体内容呢？你可能觉得这并不是什么难事，毕竟软件企业通常都有缺陷管理系统，比如典型的ALM（以前的Quality Center）、JIRA、Bugzilla、BugFree和Mantis等。当使用这类系统递交缺陷时，会自动生成模板，你只要按照其中的必填字段提供缺陷的详细信息就可以了。

很多时候，你不用想应该提供说明信息，系统会引导你提供相关的信息。但是，你有仔细想过为什么要填写这些字段，这些字段都起什么作用，以及每个字段的内容应该怎么填写吗？你必须牢牢记住的是，好的缺陷报告绝对不是大量信息的堆叠，而是以高效的方式提供准确有用的信息。缺陷标题缺陷标题通常是别人最先看到的部分，是对缺陷的概括性描述，通常采用“在什么情况下发生了什么问题”的模式。首先，对“什么问题”的描述不仅要做到清晰简洁，最关键是要足够具体，切忌不能采用过于笼统的描述。描述“什么问题”的同时还必须清楚地表述发生问题时的上下文，也就是问题出现的场景。 “用户不能正常登陆”“搜索功能有问题”和“用户信息页面的地址栏位置不正确”等，这样的描述会给人“说了等于没说”的感觉。这样的描述，很容易引发开发工程师的反感和抵触情绪，从而造成缺陷被拒绝修改（reject）。同时，还会造成缺陷管理上的困难以及过程的低效。比如，当你发现了一个菜单栏上某个条目缺失的问题，在递交缺陷报告前，通常会去缺陷管理系统搜索一下是否已经有人递交过类似的缺陷。当你以“菜单栏”为关键字搜索时，你可能会得到一堆“菜单栏有问题”的缺陷，如果缺陷标题的描述过于笼统，你就不得不点击进入每个已知缺陷点去看细节描述，这就会大大降低你的工作效率。所以，如果

软件缺陷描述

软件缺陷描述认识软件缺陷，首先要了解软件缺陷的概念，其次是了解软件缺陷的详细特征，最后就是它的属性了，再高一个层次就是学习利用管理软件缺陷的工具了。 1、首先介绍软件缺陷的概念软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。 2、软件缺陷的详细特征 a、单一准确 b、可以再现（要求软件缺陷具有精确的步骤） c、完整统一 d、短小简练 e、特定条件 f、补充完整 g、不做评价 3、软件缺陷的属性软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。下面详细介绍一下以上这些属性： a、缺陷标识：是标记某个缺陷的唯一标识，可以用数字序号表示； b、缺陷类型：功能、用户界面、文档、软件包、性能、系统\模块接口功能：影响了各种系统功能、逻辑的缺陷；用户界面：影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输入格式等方面的缺陷；文档：影响发布和维护，包括注释、用户手册、设计文档；软件包：由于软件配置库、变更管理或版本控制引起的错误；性能：不满足系统可测量的属性值，如执行时间、事务处理速率等；系统\模块接口：与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。 c、缺陷严重程度：致命（Fatal）、严重（Ceritical）、一般（Major）、较小（Minor）致命：系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机或者危机人身安全；严重：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响；一般：系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题；较小：使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题 d、缺陷产生可能性：总是、通常、有时、很少总是：总是产生这个软件缺陷，其产生的频率是100%；通常：按照测试用例，通常情况下会产生这个软件缺陷，其产生的频率大概是80%—90%；有时：按照测试用例，有时候产生这个软件缺陷，其产生的频率大概是30%—50%；

软件缺陷描述规范

软件缺陷描述规范一、缺陷基本定义软件缺陷（Software Defect）：软件缺陷是对软件产品预期属性的偏离现象。它包括检测缺陷和残留缺陷。缺陷的优先性，分为5级，参考下面的方法确定： 1)最高优先级(Blocker)，例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷，或用户重点关注的问题,缺陷导致系统几乎不能使用或者测试不能继续，需立即修复。 2)较高优先级(Critical)，例如，影响软件功能和性能的一般缺陷, 严重影响测试，需要优先考虑； 3)一般优先级(Major)，例如，本地化软件的某些字符没有翻译或者翻译不准确的缺陷,需要正常排队等待修复； 4)低优先级(Minor)，例如，对软件的质量影响非常轻微或出现几率很低的缺陷,可以在开发人员有时间的时候再被纠正； 5)最低优先级(Trival),例如，属于优化，可以不做修改的问题或暂时无法修复但影响不大的问题。

缺陷描述软件缺陷的描述是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发工程师交流的最好机会。一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员,因此，正确评估缺陷的严重程度和优先级，是项目组全体人员交流的基础。缺陷描述的原则：有效的缺陷描述有以下几个原则：可以重现：在缺陷的详细描述中提供精确的操作步骤，可以让发人员容易看懂；定位准确：缺陷描述准确，不会引起误解和歧义；描述清晰：对操作步骤的描述清晰，易于理解，应用客观的书面语，避免使用口语；完整统一：提供完整、前后统一的软件缺陷的步骤和信息，按照一致的格式书写全部缺陷报告，有关缺陷的格式参见“缺陷的格式”；短小简练：通过使用关键词，可以使问题摘要的描述短小简练，又能准确解释产生缺陷的现象。如“在新建任务窗口中，选择直接下达，负责人收不到即时消息”中“新建任务窗口”、“直接下达”、“即时消息”等是关键词；特定条件：许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原因的线索。如“网站在和的兼容问题”；不做评价：在软件缺陷描述不要带有个人观点，对开发软件进行评价。软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。

软件缺陷分类标准

审核/日期批准/日期

文档修改记录（Revision Chart） [This chart contains a h istory of this document’s revisions. The entries below are provided solely for purposes of illustration. Entries should be deleted until the revision they refer to has actually been created. The document itself should be stored in revision control, and a brief description of each version should be entered in the revision control system. That brief description can be repeated in this section. Revisions do not need to be described elsewhere in the document except inasmuch as they explain the development plan itself.]

目录 1引言 (1) 1.1 编写目的 (1) 1.2 定义与缩写 (1) 1.3 参考资料 (1) 2软件缺陷分类标准 (1) 2.1 缺陷属性 (1) 2.2 缺陷类型 (1) 2.3 缺陷严重程度 (3) 2.4 缺陷优先级 (4) 2.5 缺陷状态 (4) 2.6 缺陷来源 (4)

软件测试缺陷(Bug)写作注意点

软件测试缺陷(Bug)写作注意点提供准确、完整、简洁、一致的缺陷报告是体现软件测试的专业性、高质量的主要评价指标。遗憾的是，一些缺陷报告经常包含过少或过多信息，而且组织混乱，难以理解。由此导致缺陷被退回，从而延误及时修正，最坏的情况是由于没有清楚地说明缺陷的影响，开发人员忽略了这些缺陷，使这些缺陷随软件版本一起发布出去。因此，软件测试工程师必须认识到书写软件缺陷报告是测试执行过程的一项重要任务，首先要理解缺陷报告读者的期望，遵照缺陷报告的写作准则，书写内容完备的软件缺陷报告。本文将阐述软件测试缺陷报告的读者，描述软件缺陷报告的主要组成部分和各部分的书写要求，指出某些常见错误和实用改进方法，最后总结了缺陷报告的写作要点。 1. 缺陷报告的读者对象在书写软件缺陷报告之前，需要明白谁是缺陷报告的读者对象，知道读者最希望从缺陷报告中获得什么信息。通常，缺陷报告的直接读者是软件开发人员和质量管理人员，除此之外，来自市场和技术支持等部门的人也可能需要查看缺陷情况。每个阅读缺陷报告的人都需要理解缺陷针对的产品和使用的技术。另外，他们不是软件测试人员，可能对于具体软件测试的细节了解不多。概括起来，缺陷报告的读者最希望获得的信息包括： ?易于搜索软件测试报告的缺陷； ?报告的软件缺陷进行了必要的隔离，报告的缺陷信息更具体、准确； ?软件开发人员希望获得缺陷的本质特征和复现步骤； ?市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度。软件测试人员的任务之一就是需要针对读者的上述要求，书写良好的软件缺陷报告。 2. 缺陷报告的写作准则书写清晰、完整的缺陷报告是对保证缺陷正确处理的最佳手段。它也减少了工程师以及其它质量保证人员的后续工作。为了书写更优良的缺陷报告，需要遵守“5C”准则： ?Correct（准确）：每个组成部分的描述准确，不会引起误解； ?Clear（清晰）：每个组成部分的描述清晰，易于理解； ?Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容； ?Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息； ?Consistent（一致）：按照一致的格式书写全部缺陷报告。 3. 缺陷报告的组织结构尽管不同的软件测试项目对于缺陷报告的具体组成部分不尽相同，但是基本组织结构都是大同小异的。一个完整的软件缺陷报告通常由下列几部分组成： ?缺陷的标题； ?缺陷的基本信息；

软件缺陷定义

软件缺陷概述软件缺陷，通常又被叫做Defect或者Bug，即为软件或程序中存在的某种破坏正常运行能力的问题、错误，其存在会导致软件产品在某种程度上不能满足用户的需要。从产品内部看，缺陷是软件产品开发或维护过程中存在的问题、错误。从产品外部看，缺项是系统所需要实现的某种功能的失效或违背。软件缺陷属性软件缺陷的属性包括缺陷标识、缺陷类型、缺陷级别（或严重等级）、缺陷产生可能性（或概率）、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷根源（原因）。以上属性是为了准确描述缺陷而赋予的，这里分别作介绍： 1.缺陷标识：是标记某个缺陷的唯一标识，可以用数字序号表示； 2.缺陷类型：功能、用户界面、文档、软件包、性能、接口、兼容性等； a)功能：影响了各种系统功能、逻辑的缺陷； b)用户界面：影响了用户界面、人机交互特性的缺陷； c)文档：影响发布和维护，包括注释、用户手册、设计文档等的缺陷； d)软件包：由于软件配置库、变更管理或版本控制引起的错误； e)性能：不满足系统可测量的属性值，如执行时间、事务处理速率等； f)接口：与其他组件、模块、调用参数、控制块等不匹配、冲突； g)兼容性：与工作环境、其他外设，如操作系统、浏览器、网络环境等不匹配、冲突； 3.缺陷级别：致命、严重、一般、轻微；（举例） a)致命：系统任何一个主要功能完全失效，用户数据受到破坏，系统崩溃、悬挂、司机或者危机人身安全； b)严重：系统的主要功能部分失效，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显影响； c)一般：系统的次要功能没有完全实现，但不影响用户的正常使用。如提示信息不准确或用户界面差、操作时间长等。 d)轻微：使操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别不

软件缺陷的基本描述

软件缺陷的描述是是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发小组交流的最初且最好的机会。一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员。准确报告软件缺陷是非常重要的，因为：清晰准确的软件缺陷描述可以减少软件缺陷从开发人员返回的数量。提高软件缺陷修复的速度，使每一个小组能够有效的工作。提高测试人员的信任度，可以得到开发人员对清晰的软件缺陷描述有效的响应。加强开发人员，测试人员和管理人员的协同工作，让他们可以更好的工作。在多年实践的基础上，我们积累了较多的软件缺陷的有效描述规则，主要是： 1. 单一准确每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常常会导致缺陷部分被注意和修复，不能得到彻底的修正。 2. 可以再现提供缺陷的精确操作步骤，使开发人员容易看懂，可以自己再现这个缺陷，通常情况下，开发人员只有再现了缺陷，才能正确地修复缺陷。 3. 完整统一提供完整、前后统一的软件缺陷的步骤和信息，例如：图片信息，Log文件等。 4. 短小简练

通过使用关键词，可以使软件缺陷的标题的描述短小简练，又能准确解释产生缺陷的现象。如“主页的导航栏在低分辨率下显示不整齐”中“主页”、“导航栏”、“分辨率”等是关键词。 5. 特定条件许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件(如特定的操作系统、浏览器或某种设置等)，能够提供帮助开发人员找到原因的线索。如“搜索功能在没有找到结果返回时跳转页面不对”。 6. 补充完善从发现Bug那一刻起，测试人员的责任就是保证它被正确的报告，并且得到应有的重视，继续监视其修复的全过程。 7. 不做评价在软件缺陷描述不要带有个人观点，对开发人员进行评价。软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。即：1、单一准确 2、可以再现（要求软件缺陷具有精确的步骤） 3、完整统一 4、短小简练 5、特定条件 6、补充完整 7、不做评价摘自：软件测试方法和技术作者：朱少民

软件缺陷分类标准

软件缺陷分类标准修订历史记录目录 1. 引言................................................... 1.1编写目的 .......................................... 1.2定义与缩写 ........................................ 1.3参考资料 .......................................... 2.软件缺陷分类标准....................................... 2.1问题类型 .......................................... 2.2缺陷属性 .......................................... 2.3缺陷类型 .......................................... 2.4缺陷严重程度 ...................................... 2.5缺陷优先级 ........................................ 2.6缺陷状态 .......................................... 2.7缺陷来源、起源 ....................................

2.8缺陷根源 .......................................... 2.9缺陷产生可能性 .................................... 1.引言 1.1编写目的制定本标准的目的是为软件测试提供确信分类的标准。本文档说明了问题类型、缺陷属性、确缺陷类型、缺陷严重级别、缺陷优先级、缺陷状态、缺陷修改次数、缺陷原因。其预期的读者是测试人员、开发人员、开发经理。 1.2定义与缩写表格1-1 定义与缩写 1.3参考资料表格1-2 参考资料列表

软件缺陷(bug)的概述及书写规范

软件缺陷（bug）的概述及书写规范 1、软件缺陷（bug）的定义 IEEE（1983）729软件缺陷一个标准的定义：从产品内部看：软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题。从产品外部看：软件缺陷是系统所需要实现的某种功能的失效或违背。 2、软件缺陷（bug）满足的5个规则至少满足以下5个规则之一，才称为发生一个软件缺陷： –软件未实现产品说明书要求的功能 –软件出现了产品说明书指明不应该出现的错误 –软件实现了产品说明书未提到的功能 –软件未实现产品说明书虽未明确提及但应该实现的目标 –软件难以理解，不易使用，运行缓慢或者----最终用户会认为不好 3、软件缺陷（bug）生命周期测试人员开发人员测试人员测试人员 bug bug为回归测试Y

4、软件缺陷（bug）状态 Unfixed测试人员新建一个bug，将bug的状态定义为unfixed，开发人员看到的最新的bug状态都是unfixed。 To be fixed开发经理将新建的bug指派给自己或者其他开发人员，将bug 的状态置为to be fixed。 Pending由于该bug实现比较难，或者无法修改，开发人员会将bug 状态置为pending。 To be verified开发人员已修复bug，将该bug指派给其他开发人员，进行内部测试，此时bug状态为to be verified。 Verified开发人员进行内部测试确认该bug已修复，然后将该bug指派给测试经理，bug状态置为verified。 Integrated测试经理将已修复bug指派给bug提交者，做回归测试，此时将bug状态置为integrated。 Fixed测试人员进行回归测试，确认bug已修复，将bug状态置为 fixed。 Close该bug不是bug，或者描述有误，开发经理关闭该bug，此时bug状态为close。 5、软件缺陷（bug）的优先级 High（高优先级） –严重花屏 –内存泄露 –用户数据丢失或破坏 –系统崩溃/死机/冻结 –模块无法启动或异常退出 –严重的数值计算错误

软件缺陷描述

软件缺陷描述《如何编写高质量的缺陷描述》作为一名测试人员，提交缺陷是我们必须做的功课。缺陷描述也是一门“艺术”，它影射了一个人的测试经验，测试深度。缺陷描述能否做好，直接影响了我们的测试效率，更确切的说是影响了开发人员修改缺陷的效率。一份高质量的缺陷描述让开发人员看的时候是一种享受，可以提高他们的工作效率；而一份让人费解的缺陷描述，不仅会让开发感到无从下手，还会降低对测试人员的信任度。一份好的缺陷描述，体现了一个测试人员的基本素质。 1.根据自己的经验进行测试； 2.站在用户的角度去测试； 3.发现规律。 ------------------------------------------------------------------------------------------------- 认识软件缺陷，首先要了解软件缺陷的概念，其次是了解软件缺陷的详细特征，最后就是它的属性了，再高一个层次就是学习利用管理软件缺陷的工具了。 1、首先介绍软件缺陷的概念软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。 2、软件缺陷的详细特征 a、单一准确 b、可以再现（要求软件缺陷具有精确的步骤） c、完整统一 d、短小简练 e、特定条件 f、补充完整 g、不做评价 3、软件缺陷的属性软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。下面详细介绍一下以上这些属性： a、缺陷标识：是标记某个缺陷的唯一标识，可以用数字序号表示（缺陷编号）； b、缺陷类型：功能、用户界面、文档、软件包、性能、系统\模块接口缺陷功能：影响了各种系统功能、逻辑的缺陷；用户界面：影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输入格式等方面的缺陷；文档：影响发布和维护，包括注释、用户手册、设计文档；软件包：由于软件配置库、变更管理或版本控制引起的错误；性能：不满足系统可测量的属性值，如执行时间、事务处理速率等；系统\模块接口：与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。 c、缺陷严重程度：致命（Fatal）、严重（Ceritical）、一般（Major）、较小（Minor）致命：系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机或者危机人身安全；严重：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响；一般：系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题；

用英文描述软件bug (defect, 缺陷)++

一、缺陷基本定义软件缺陷（Software Defect）：软件缺陷是对软件产品预期属性的偏离现象。它包括检测缺陷和残留缺陷。缺陷的优先性，分为5级，参考下面的方法确定： 1)最高优先级(Blocker)，例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷，或用户重点关注的问题,缺陷导致系统几乎不能使用或者测试不能继续，需立即修复。 2)较高优先级(Critical)，例如，影响软件功能和性能的一般缺陷, 严重影响测试，需要优先考虑； 3)一般优先级(Major)，例如，本地化软件的某些字符没有翻译或者翻译不准确的缺陷,需要正常排队等待修复； 4)低优先级(Minor)，例如，对软件的质量影响非常轻微或出现几率很低的缺陷,可以在开发人员有时间的时候再被纠正； 5)最低优先级(Trival),例如，属于优化，可以不做修改的问题或暂时无法修复但影响不大的问题。

二、缺陷描述软件缺陷的描述是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发工程师交流的最好机会。一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员,因此，正确评估缺陷的严重程度和优先级，是项目组全体人员交流的基础。缺陷描述的原则：有效的缺陷描述有以下几个原则：可以重现：在缺陷的详细描述中提供精确的操作步骤，可以让发人员容易看懂；定位准确：缺陷描述准确，不会引起误解和歧义；描述清晰：对操作步骤的描述清晰，易于理解，应用客观的书面语，避免使用口语；完整统一：提供完整、前后统一的软件缺陷的步骤和信息，按照一致的格式书写全部缺陷报告，有关缺陷的格式参见“缺陷的格式”；短小简练：通过使用关键词，可以使问题摘要的描述短小简练，又能准确解释产生缺陷的现象。如“在新建任务窗口中，选择直接下达，负责人收不到即时消息”中“新建任务窗口”、“直接下达”、“即时消息”等是关键词；特定条件：许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原因的线索。如“网站在IE7.0和IE8.0的兼容问题”；不做评价：在软件缺陷描述不要带有个人观点，对开发软件进行评价。软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。

软件缺陷的基本概念

认识软件缺陷，首先要了解软件缺陷的概念，其次是了解软件缺陷的详细特征，最后就是它的属性了，再高一个层次就是学习利用管理软件缺陷的工具了。 1、首先领测国际介绍软件缺陷的概念软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。 2、软件缺陷的详细特征 a、单一准确 b、可以再现（要求软件缺陷具有精确的步骤） c、完整统一 d、短小简练 e、特定条件 f、补充完整 g、不做评价 3、软件缺陷的属性软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。下面详细介绍一下以上这些属性： a、缺陷标识：是标记某个缺陷的唯一标识，可以用数字序号表示； b、缺陷类型：功能、用户界面、文档、软件包、性能、系统\模块接口功能：影响了各种系统功能、逻辑的缺陷；用户界面：影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输入格式等方面的缺陷；文档：影响发布和维护，包括注释、用户手册、设计文档；软件包：由于软件配置库、变更管理或版本控制引起的错误；性能：不满足系统可测量的属性值，如执行时间、事务处理速率等；系统\模块接口：与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。 c、缺陷严重程度：致命（Fatal）、严重（Ceritical）、一般（Major）、较小（Minor）致命：系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机或者危机人身安全；严重：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响；一般：系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题；较小：使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题 d、缺陷产生可能性：总是、通常、有时、很少总是：总是产生这个软件缺陷，其产生的频率是100%；通常：按照测试用例，通常情况下会产生这个软件缺陷，其产生的频率大概是80%—90%；有时：按照测试用例，有时候产生这个软件缺陷，其产生的频率大概是30%—50%；很少：按照测试用例，很少产生这个软件缺陷，其产生的频率大概是1%—5%. e、缺陷的优先级：立即解决、高优先级、正常排队、低优先级立即解决：缺陷导致系统几乎不能使用或者测试不能继续，需立即修复；高优先级：缺陷严重，影响测试，需要优先考虑；

软件缺陷管理流程图

软件缺陷管理办法 1.目的本文档定义了软件缺陷管理流程和相关规则，确保软件缺陷管理的系统性和规范性，以保证项目研发质量。 2.适用范围适用于部门项目研发过程的缺陷管理，对各阶段的缺陷管理过程进行指导和规范。 3.定义 3.1 术语缺陷（Defect）：存在于软件之中偏差，可被激活，以静态形式存在于软件内部。 Bug：缺陷一种表现形态，系统或程序存在的任何一种破坏正常运转能力的问题。 3.2 缺陷定义（1）软件未达到需求规格说明书的功能；（2）软件出现了需求规格说明书指明不会出现的错误；（3）软件功能超出需求规格说明书的范围；（4）软件未达到需求规格说明书未指出但应达到的目标；（5）测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。 4.缺陷生命周期 4.1 缺陷生命周期图

4.2 缺陷状态说明 5. 缺陷处理过程 5.1 正常处理过程（1）创建问题在测试管理系统中，所有用户都可以创建新问题，包括需求问题和软件缺陷等。创建问题时，需要描述清楚，并选择正确的选项，详细请参考5.4和5.5。（2）指派问题创建问题时，创建者通常要指派给该项目开发负责人，再由其指派任务，或直接指派给相应模块的开发工程师。如果指派人是错误的，或者需要他人确认或帮助，则可以重新指派给合适的工程师，写上相关备注。（3）确认问题通常开发工程师收到新问题后，需要分析和确认此问题是否为Bug。如果是Bug，则选择“确认状态”；如果认为非Bug，则注明原因并指派回创建者。当创建者收到确认指派时，需要进行及时确认。如果同意为非bug，则及时关闭它；如果不同意，则需要注明理由并指派回相关工程师。如果问题确认指派次数大于6次时，需要进入“争议处理”流程，详细请参考5.2。（4）解决问题此为开发工程师的主要职责，包括Bug的复现、修改和修改验证。开发工程师需要及时对确认状态Bug进行分析和解决，并自己验证通过，则操作为解决状态，解决方案规则请参考5.4中解决方案定义部分，在缺陷管理系统中解决方案选择相应的选项，解决后系统将自动指派回给创建者。如果Bug无法解决或修改影响比较大，可申请进入“延期解决”流程，请参考5.2中延期处理部分。（5）验证问题创建者需要及时对解决状态的Bug在对应版本上面进行验证。如果验证通过，则可关闭Bug；如果验证不通过，则激活此Bug，系统将自动指派回给解决者。