软件测试缺陷Bug写作注意点.doc

软件测试缺陷Bug写作注意点.doc

《软件测试缺陷Bug写作注意点.doc》由会员分享，可在线阅读，更多相关《软件测试缺陷Bug写作注意点.doc（6页珍藏版）》请在冰豆网上搜索。

软件测试缺陷（Bug）写作注意点

提供准确、完整、简洁、一致的缺陷报告是体现软件测试的专业性、高质量的主要评价指标。

遗憾的是，一些缺陷报告经常包含过少或过多信息，而且组织混乱，难以理解。

由此导致缺陷被退回，从而延误及时修正，最坏的情况是由于没有清楚地说明缺陷的影响，开发人员忽略了这些缺陷，使这些缺陷随软件版本一起发布出去。

因此，软件测试工程师必须认识到书写软件缺陷报告是测试执行过程的一项重要任务，首先要理解缺陷报告读者的期望，遵照缺陷报告的写作准则，书写内容完备的软件缺陷报告。

本文将阐述软件测试缺陷报告的读者，描述软件缺陷报告的主要组成部分和各部分的书写要求，指出某些常见错误和实用改进方法，最后总结了缺陷报告的写作要点。

1.缺陷报告的读者对象

在书写软件缺陷报告之前，需要明白谁是缺陷报告的读者对象，知道读者最希望从缺陷报告中获得什么信息。

通常，缺陷报告的直接读者是软件开发人员和质量管理人员，除此之外，来自市场和技术支持等部门的人也可能需要查看缺陷情况。

每个阅读缺陷报告的人都需要理解缺陷针对的产品和使用的技术。

另外，他们不是软件测试人员，可能对于具体软件测试的细节了解不多。

概括起来，缺陷报告的读者最希望获得的信息包括：

·易于搜索软件测试报告的缺陷；

·报告的软件缺陷进行了必要的隔离，报告的缺陷信息更具体、准确；

·软件开发人员希望获得缺陷的本质特征和复现步骤；

·市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度。

软件测试人员的任务之一就是需要针对读者的上述要求，书写良好的软件缺陷报告。

2.缺陷报告的写作准则

书写清晰、完整的缺陷报告是对保证缺陷正确处理的最佳手段。

它也减少了工程师以及其它质量保证人员的后续工作。

　为了书写更优良的缺陷报告，需要遵守“5C”准则：

·Correct（准确）：

每个组成部分的描述准确，不会引起误解；

·Clear（清晰）：

每个组成部分的描述清晰，易于理解；

·Concise（简洁）：

只包含必不可少的信息，不包括任何多余的内容；

·Complete（完整）：

包含复现该缺陷的完整步骤和其他本质信息；

·Consistent（一致）：

按照一致的格式书写全部缺陷报告。

3.缺陷报告的组织结构

尽管不同的软件测试项目对于缺陷报告的具体组成部分不尽相同，但是基本组织结构都是大同小异的。

一个完整的软件缺陷报告通常由下列几部分组成：

·缺陷的标题；

·缺陷的基本信息；

o测试的软件和硬件环境；

o测试的软件版本；

o缺陷的类型；

o缺陷的严重程度；

o缺陷的处理优先级。

·复现缺陷的操作步骤；

·缺陷的实际结果描述；

·期望的正确结果描述；

·注释文字和截取的缺陷图像。

对于具体测试项目而言，缺陷的基本信息通常是比较固定的，也是很容易描述的。

实际书写软件缺陷报告容易出现问题的地方就是标题、操作步骤、实际结果、期望结果和注释部分。

下面针对这些“事故多发地带”具体论述如何提供完整的信息，由于英文是软件开发的主要语言，以下的软件缺陷报告的信息都使用英文书写。

4.缺陷报告的写作技术

4.1标题（Title）

标题应该保持简短、准确，提供缺陷的本质信息，并且便于读者搜索查寻。

良好的缺陷标题应该按照下列方式书写：

·尽量按缺陷发生的原因与结果的方式书写（“执行完A后，发生B，”或者“发生B，当A执行完后”）；

·避免使用模糊不清的词语，例如“功能中断，功能不正确，行为不起作用，”等。

应该使用具体文字说明功能如何中断，如何不正确，或如何不起作用；

·为了方便搜索和查询，请使用关键字；

·为了便于他人理解，避免使术语、俚语或过分具体的测试细节。

请查看下面的表格，该表格列出了有问题的标题，给出了如何改进的示例。

原始描述错误原因改进的标题

原始描述

错误原因

改进的标题

Hyphenationdoesnotwork

描述太笼统。

什么时候不起作用？

Textbreaksatline'send,butnohyphenappears

Incorrectbehaviorwithparagraphalignment

描述太笼统。

不正确的行为是什么？

Justifiedalignmentleavesgapsintextcompositionwhentrackingisalsoapplied

Assert:

CmdAssertHereInsertSomethingBad-Happens

没有包含原因与结果信息。

断言（Assert）太长。

Assert,"SomethingBad"whenattemptingtoupdatelinkedbitmapstoredonserver

Aftereachlaunchthenclickingeditandthencopy/paste,thereistoomuchdelay

没有指明原因与结果，包含了过分详细的细节信息。

Performanceslowsnoticeablyafter?

rstlaunchandcopy/paste

Quotesappearassymbolswhentheyareimported

信息没有充分隔离。

所有的引号都如此吗？

什么类型的符号？

ImportedsmartquotesfromWordappearasunrecognizedcharacters

提示

　　使用"after"，"when"或"during"等连结词有助于描述缺陷的原因和结果，例如：

·Applicationcrashesafterinputanylettersinnumericfield.

·Internalerroroccurswhenclosingapplication.

·Applicationsuspendedduringemailtransmission."

4.2复现步骤（ReproducibleSteps）

复现步骤包含如何使别人能够很容易的复现该缺陷的完整步骤。

为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。

但是实际软件测试过程中，总是存在一些不良的缺陷报告，主要的问题在于以下三个方面：

·复现步骤包含了过多的多余步骤，而且句子结构混乱，可读性很差，难于理解；

·复现步骤包含了过少的信息，丢失操作的必要步骤。

由于提供的步骤不完整，开发人员经常需要种种猜测，努力尝试复现的步骤，浪费了大量时间。

由于缺少关键步骤，这些缺陷通常被工程师以“不能复现”为由再次发送给测试人员；

·测试人员没有对软件缺陷发生的条件和影响区域进行隔离，软件开发人员无法判断该缺陷影响的软件部分，不能进行彻底修正。

为了避免出现这些问题，良好的复现步骤应该包含本质的信息，并按照下列方式书写：

·提供测试的预备步骤和信息；

o环境变量。

例如，如果默认项或预设、调试版本或发布版本等存在问题，请指明使用的操作系统和应用程序的环境变量；

o设置变量：

指明哪种打印机、字体或驱动程序是复现Bug所必需的信息；

o复现路径。

如果有多种方法触发该缺陷，请在步骤中包含这些方法。

同样地，如果某些路径不触发该缺陷，也要包含这些路径。

·简单地一步一步地引导复现该缺陷；

·每一个步骤尽量只记录一个操作；

·每一个步骤前使用数字对步骤编号；

·尽量使用短语和短句，避免复杂句型和句式；

·复现的操作步骤要完整，准确，简短；

·没有缺漏任何操作步骤；

·每个步骤都是准确无误的；

·没有任何多余的步骤；

·将常见步骤合并为较少步骤，例如：

1.Createtextframe.

2.Addtext.

可以简单的合并成一步：

1.Createanewtextframeandaddtext.

·只记录各个操作步骤是什么，不要包括每个操作步骤执行后的结果

需要再次引起注意的是，缺陷报告的读者对技术有基本的了解，但是对软件测试的细节可能所知有限。

因此，一方面，没有必要在缺陷报告中告诉启动产品或者如何打开一个文件等简单操作方法。

另一方面，不要包含软件测试过分详细的技术细节，除非这些是缺陷至关重要的信息。

4.3实际结果（Actualresult）

实际结果是执行复现步骤后软件的现象和产生的行为。

实际结果的描述很像缺陷的标题，是标题信息的再次强调，要列出具体的表现行为，而不是简单的指出“不正确”或“不起作用”。

如果一个动作产生彼此不同的多个缺陷结果。

为了易于阅读，这些结果应该使用数字列表分隔开来。

例如：

Actualresult:

　1.Assert“CmdLineofCodeHere…”

　　2.Assert“AlsoBrokenHere…”

　有时，一个动作将产生一个结果，而这个结果又产生另一个结果。

这种情况可能难以清晰、简洁地总结。

例如：

ActualResult：

　1.Assert:

“CmdLineofCodeBlahBlah…”

　　2.Whenthisassertisdismissed,appbecomesactivebutalltextisunrecognizable.

　　3.Afterselectingthetextbydraggingthetexttool,thetextappearsnormallyonceagain.

对于这些较难处理的情况，有多种使之易于阅读的解决方法：

·尽可能将缺陷分解成多个缺陷报告，并使用交叉引用说明彼此之间的联系。

这些动作的结果通常比较相似但缺陷不同。

首先进行更多的隔离测试，缩小产生缺陷的范围，查看是否产生多个缺陷；

·在实际结果部分，仅列出缺陷的一到两个表现特征。

使用注释（Notes）部分列出缺陷的其它问题；

·在缺陷的第一个表现特征后，将随后的步骤和缺陷表现特征移到注释部分。

重要的信息几乎总是包含在第一个断言或错误里，其它错误都是第一个错误的变种。

4.4期望结果（Expectedresult）

期望结果的描述应该与实际结果的描述方式相同。

通常需要列出期望结果的应该是什么，并且给出期望结果的原因，可能是引用的规格说明书、前一版本的表现行为、客户一般需求、排除杂乱信息的需要等等。

为了更清楚地理解良好的期望结果应该包含什么信息，请看下面的例子：

Expectedresult：

Thetextthatappearsshouldbefullyhighlightedsothatiftheuserwishestomakechanges,theydon'thavetomanuallyhighlightandthentype（asinMacOS10.xandWindowsbehavior.）

为什么说这个例子很好呢？

因为它包含了如下内容：

·应该产生的正确现象：

Thetextthatappearsshouldbefullyhighlighted

·为什么应该产生：

…sothatiftheuserwishestomakechanges,theydon'thavetomanuallyhighlightandthentype.