软件测试缺陷(Bug)写作注意点
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
软件测试缺陷(Bug)写作注意点
提供准确、完整、简洁、一致的缺陷报告是体现软件测试的专业性、高质量的主要评价指标。遗憾的是,一些缺陷报告经常包含过少或过多信息,而且组织混乱,难以理解。由此导致缺陷被退回,从而延误及时修正,最坏的情况是由于没有清楚地说明缺陷的影响,开发人员忽略了这些缺陷,使这些缺陷随软件版本一起发布出去。
因此,软件测试工程师必须认识到书写软件缺陷报告是测试执行过程的一项重要任务,首先要理解缺陷报告读者的期望,遵照缺陷报告的写作准则,书写内容完备的软件缺陷报告。本文将阐述软件测试缺陷报告的读者,描述软件缺陷报告的主要组成部分和各部分的书写要求,指出某些常见错误和实用改进方法,最后总结了缺陷报告的写作要点。
1. 缺陷报告的读者对象
在书写软件缺陷报告之前,需要明白谁是缺陷报告的读者对象,知道读者最希望从缺陷报告中获得什么信息。通常,缺陷报告的直接读者是软件开发人员和质量管理人员,除此之外,来自市场和技术支持等部门的人也可能需要查看缺陷情况。每个阅读缺陷报告的人都需要理解缺陷针对的产品和使用的技术。另外,他们不是软件测试人员,可能对于具体软件测试的细节了解不多。
概括起来,缺陷报告的读者最希望获得的信息包括:
∙易于搜索软件测试报告的缺陷;
∙报告的软件缺陷进行了必要的隔离,报告的缺陷信息更具体、准确;
∙软件开发人员希望获得缺陷的本质特征和复现步骤;
∙市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度。
软件测试人员的任务之一就是需要针对读者的上述要求,书写良好的软件缺陷报告。
2. 缺陷报告的写作准则
书写清晰、完整的缺陷报告是对保证缺陷正确处理的最佳手段。它也减少了工程师以及其它质量保证人员的后续工作。
为了书写更优良的缺陷报告,需要遵守“5C”准则:
∙Correct(准确):每个组成部分的描述准确,不会引起误解;
∙Clear(清晰):每个组成部分的描述清晰,易于理解;
∙Concise(简洁):只包含必不可少的信息,不包括任何多余的内容;
∙Complete(完整):包含复现该缺陷的完整步骤和其他本质信息;
∙Consistent(一致):按照一致的格式书写全部缺陷报告。
3. 缺陷报告的组织结构
尽管不同的软件测试项目对于缺陷报告的具体组成部分不尽相同,但是基本组织结构都是大同小异的。一个完整的软件缺陷报告通常由下列几部分组成:
∙缺陷的标题;
∙缺陷的基本信息;
o测试的软件和硬件环境;
o测试的软件版本;
o缺陷的类型;
o缺陷的严重程度;
o缺陷的处理优先级。
∙复现缺陷的操作步骤;
∙缺陷的实际结果描述;
∙期望的正确结果描述;
∙注释文字和截取的缺陷图像。
对于具体测试项目而言,缺陷的基本信息通常是比较固定的,也是很容易描述的。实际书写软件缺陷报告容易出现问题的地方就是标题、操作步骤、实际结果、期望结果和注释部分。下面针对这些“事故多发地带”具体论述如何提供完整的信息,由于英文是软件开发的主要语言,以下的软件缺陷报告的信息都使用英文书写。
4. 缺陷报告的写作技术
4.1 标题(Title)
标题应该保持简短、准确,提供缺陷的本质信息,并且便于读者搜索查寻。
良好的缺陷标题应该按照下列方式书写:
∙尽量按缺陷发生的原因与结果的方式书写(“执行完A后,发生B,”或者“发生B,当A执行完后”);
∙避免使用模糊不清的词语,例如“功能中断,功能不正确,行为不起作用,”等。应该使用具体文字说明功能如何中断,如何不正确,或如何不起作用;
∙为了方便搜索和查询,请使用关键字;
∙为了便于他人理解,避免使术语、俚语或过分具体的测试细节。
请查看下面的表格,该表格列出了有问题的标题,给出了如何改进的示例。
原始描述错误原因改进的标题
提示
使用"after","when"或"during"等连结词有助于描述缺陷的原因和结果,例如:
∙Application crashes after input any letters in numeric field.
∙Internal error occurs when closing application.
∙Application suspended during email transmission."
4.2 复现步骤(Reproducible Steps)
复现步骤包含如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求,复现步骤的信息必须是完整的、准确的、简明的、可复现的。
但是实际软件测试过程中,总是存在一些不良的缺陷报告,主要的问题在于以下三个方面:
∙复现步骤包含了过多的多余步骤,而且句子结构混乱,可读性很差,难于理解;
∙复现步骤包含了过少的信息,丢失操作的必要步骤。由于提供的步骤不完整,开发人员经常需要种种猜测,努力尝试复现的步骤,浪费了大量时间。由于缺少关键步骤,这些缺陷通常被工程师以“不能复现”为由再次发送给测试人员;
∙测试人员没有对软件缺陷发生的条件和影响区域进行隔离,软件开发人员无法判断该缺陷影响的软件部分,不能进行彻底修正。
为了避免出现这些问题,良好的复现步骤应该包含本质的信息,并按照下列方式书写:
∙提供测试的预备步骤和信息;
o环境变量。例如,如果默认项或预设、调试版本或发布版本等存在问题,请指明使用的操作系统和应用程序的环境变量;
o设置变量:指明哪种打印机、字体或驱动程序是复现Bug所必需的信息;
o复现路径。如果有多种方法触发该缺陷,请在步骤中包含这些方法。同样地,如果某些路径不触发该缺陷,也要包含这些路径。
∙简单地一步一步地引导复现该缺陷;
∙每一个步骤尽量只记录一个操作;
∙每一个步骤前使用数字对步骤编号;
∙尽量使用短语和短句,避免复杂句型和句式;
∙复现的操作步骤要完整,准确,简短;
∙没有缺漏任何操作步骤;
∙每个步骤都是准确无误的;
∙没有任何多余的步骤;