易于理解的缺陷报告可以有效地消除应用程序中的错误。如果缺陷报告不清晰,修复方案可能会引入更多错误。
软件开发的效率可以提高质量、按时交付和更满意的客户。大部分效率依赖于成功修复错误,高质量的缺陷报告可以帮助开发人员快速修复错误。
编写缺陷报告时,测试人员可以通过添加详细准确的重现步骤来提供帮助。重现步骤必须包括期望结果和实际结果。团队还可以包含屏幕截图和视频附件,以帮助理解有问题的缺陷。
缺陷报告应包含的详细信息
大多数缺陷跟踪工具都包含默认模板,测试人员可以根据需要更新模板以包含其他字段。或者,如果团队使用电子表格或其他文档方法跟踪,测试人员可以创建大纲或模板。模板提供团队定义为修复缺陷有用的标准信息。下载缺陷报告模板。
缺陷报告中写入的详细信息可以帮助开发人员理解错误的深度和广度,并找出受影响的代码。在复杂的代码库中定位损坏的代码不是一件容易的任务,特别是当开发人员同时工作在多个项目上时。缺陷报告者添加的详细信息越多,错误越容易重现、定位和修复。对缺陷的理解越透彻,团队修复它的可能性越大——而且不会产生新的相关错误。
可理解的缺陷报告所需的详细信息包括:
1.跟踪的唯一 ID。这使测试人员能够通过 ID 查找缺陷。
2. 报告者姓名。有疑问时的姓名和联系信息。
3. 应用程序和代码版本。如果有不同,请包括应用程序和代码版本。
4. 服务器或环境。定义测试地点。
5. 浏览器和操作系统(如果适用)。包括操作系统版本,或者浏览器和版本。
6.可重现=是/否。通常,缺陷是可重现的;然而,有时用户的 PC 设置、浏览器设置或配置设置会生成其他情况下不会出现的缺陷。如果在测试过程中使用任何特殊设置,请说明它们的功能。
7.频率=始终随机。知道错误重现的频率很重要。许多错误是随机的。知道错误不总是重现,可以帮助定义它来自何处以及为何仅随机出现。
8. 测试用例的链接或名称(如果适用)。在测试执行期间检测到错误时,包含测试用例的链接或名称。
9. 重现步骤、日志文件或错误的屏幕截图或视频文件。浏览器开发工具日志或其他日志文件可以帮助开发人员理解缺陷。包括错误动作的视频或屏幕截图以帮助视觉理解。
10. 配置设置(如果适用)。列出任何非标准或特定的配置设置。
11. 预期结果/行为和实际结果/行为。开发人员可能不知道应用程序的端到端工作原理,因为他们倾向于编码特定功能。包括预期结果——而不仅仅是实际结果——提供找到错误的关键信息。
12. 严重性/优先级。该缺陷的严重性如何?产品或开发可能会更改此值,但根据错误对用户体验的影响由报告者设置。
13. 故障排除笔记。包括任何对故障排除步骤、数据库查询或错误日志查找的笔记。
缺陷报告的质量依赖于测试人员包含的详细信息的准确性。增加任何故障排除都有助于开发人员找到错误的根本原因而不是单一症状。
用重现步骤描述缺陷
缺陷必须包含描述问题的具体重现步骤。多次运行步骤以确保没有遗漏任何操作。由于假设了采取的操作,很容易跳过步骤。确保所有点击、页面更改和选择都是准确的。
重现步骤的质量因人和角色而异。开发人员欣赏完整的描述与所有相关详细信息,以便他们可以重现缺陷。没有正确或完整步骤编写的缺陷报告会被忽略或存回系统作为技术债务。
下面显示高质量和易于理解的重现步骤,以医护专业人士的患者信息应用程序为例:
使用有效的用户名、密码和双因子认证代码登录移动医生应用程序作为具有医生角色的护士:
开发服务器 A 用户名=护士 AP
密码=PTarmi$88gan7
发送到测试电子邮件的双因子认证代码:
发送到的 SMS 代码:<770-123-4567>(开发服务器 A 的测试电话)
通过选择右上角的“患者”选项卡导航到患者页面。
通过点击“添加药物”按钮向2个月以下的新生儿患者添加药物过敏史:
验证配置设置打开,以警报新生儿患者的药物过敏。
注:配置设置位于“配置”选项卡>“患者”>“新生儿”>“过敏”下
验证新生儿患者定义为:<= 60 天(1-60 天)
保存。
向三名患者添加药物处方:
2 个月的患者
< 2 个月的患者
= 3-6 个月的患者
患者 B 出现以下错误:
患者 B 符合新生儿患者的定义,但没有出现错误消息警告用户由于存在过敏,操作将被忽略。
用户可以添加患者过敏的药物而没有出现错误。
预期结果:医生用户不能向新生儿患者添加药物。系统会生成弹出错误消息,指示由于现有过敏,不能添加药物。
实际结果:医生用户可以成功向新生儿患者添加过敏药物。系统错误消息指示由于过敏无法添加药物不会弹出。
以下是一个对同一用例不太有效的重现步骤示例:
当患者添加现有过敏的药物时,用户不会收到弹出错误。
预期结果:医生用户不能向新生儿患者添加药物。系统会生成弹出错误消息,指示由于患者过敏,不能添加药物。
实际结果:医生用户可以成功向新生儿患者添加过敏药物。警告医生过敏的系统错误消息不会弹出。
开发人员可能不知道如何添加过敏或新生儿患者的药物,更不用说选择患者了。步骤是正确的,但它们假定应用程序工作流程和配置知识,被指派的开发人员可能没有。包括明确的详细信息,以便开发人员可以重现缺陷。
期望结果/行为与实际结果/行为的重要性
期望结果部分表示开发人员执行重现步骤时会发生什么。使预期结果具体和明确。不要假定读者完全理解会发生什么。在前面的示例中,期望结果表明错误消息会在窗口中弹出。考虑添加弹出窗口的屏幕截图或错误消息的完整文本。
许多应用程序在可访问位置生成错误日志。当它显示错误或无法显示预期窗口时,包括错误日志。如果应用程序本身不生成错误日志,请使用浏览器的开发人员工具尝试捕获错误。控制台、网络和元素选项卡在运行时显示应用程序错误,这些错误可能不会在应用程序 UI 中可见。包括关于特定窗口和错误的详细信息可以帮助开发人员找到正确的窗口或错误。
实际结果描述错误或缺陷。在前面的示例中,实际结果表明,尽管患者对其过敏,但医生仍然可以添加药物。此外,没有错误消息窗口告诉用户为什么不能添加药物或阻止他们这样做。
这里的实际结果描述了两个缺陷症状:一个是缺失的错误窗口,另一个是应拒绝的药物条目。在创建实际结果时,解释问题的全部细节,以便清楚地说明实际结果与预期结果之间的差异,或者为什么结果是有缺陷的。
附件增进理解
只有当它们显示问题或清楚地表明缺陷时,才添附视频、图像和错误日志文件。附件必须是有用的,并清楚地显示问题。
确保视频文件准确地描绘了采取的每一步,并与重现步骤相匹配。缺失的步骤通常是开发人员无法重现错误的原因。请记住,视频消耗数据存储空间,所以只有在屏幕截图不能表明缺陷时才使用它们。屏幕截图图像或屏幕录制器文件对于问题的视觉证明和可能表明代码位置很有用。
只包括有意义和可操作的附件——如果它无用或不显示缺陷,请勿包括它。附加错误日志或开发人员工具生成的错误可以帮助减少定位缺陷的时间。确保文件以可读格式打开;否则,将它们作为屏幕截图附加。
总之,高质量的缺陷报告取决于测试人员包含的详细准确信息。增加任何故障排除都有助于开发人员找到错误的根本原因,而不仅仅是一个单一的症状。描述缺陷的步骤要具体而详尽,同时要附带有意义的附件,这样可以最大限度地增进开发人员对缺陷的理解,提高修复的成功率和质量。
