如何编写一个有效的错误报告?

  • 2023年6月21日
  • 2回答
  • 87的浏览量
IOan
Userlevel 4
徽章 + 3
  • IOan
  • 0.8跨声速
  • 6个回答

嘿ShiftSync社区!

我希望你们都有美好的一天。我最近遇到了一个神奇的视频在YouTube上,讨论了软件测试和bug报告的重要性。188金宝搏官网登录app这是视频的链接:https://www.youtube.com/watch?v=cgkhx7NqXCE&ab_channel=ResterTest。

看后,我意识到,编写一个有效的错误报告是提高软件质量的关键和保证流畅的用户体验。188金宝搏官网登录app我相信这是一个有价值的技巧对我们所有人来说在技术社区,和我很想听听你的想法和建议。

如果你有经验编写bug报告或如果你遇到错误并报告之前,我将非常感谢任何技巧可以分享。这里有几个问题展开对话:

  1. 什么是良好的错误报告的组成部分?
  2. 如何有效地繁殖和描述一个错误在你的报告吗?
  3. 应该包含哪些额外信息,比如系统细节或错误消息吗?
  4. 有任何最佳实践或编写bug报告时避免常见缺陷?
  5. 你如何平衡提供足够的信息和报告保持简洁?

随时分享你的个人经历,你已经找到技巧,任何资源有助于掌握写作的艺术bug报告。让我们利用这个机会互相学习和提高我们的集体知识。

我很激动听到你的见解,进行富有成果的讨论。提前感谢您的输入!

期待您的回复。

Hey ShiftSync Community!<\/p>

I hope you're all having a great day. I recently came across a fantastic video on YouTube that discusses software testing and the importance of bug reports. Here's the link to the video: https:\/\/www.youtube.com\/watch?v=cgkhx7NqXCE&ab_channel=ResterTest<\/a><\/strong>.<\/p>

After watching it, I realized that writing an effective bug report is crucial for improving software quality and ensuring smooth user experiences. I believe it's a valuable skill for all of us in the tech community, and I'd love to hear your thoughts and advice on the matter.<\/p>

If you have experience with writing bug reports or if you've encountered bugs and reported them before, I would greatly appreciate any tips you could share. Here are a few questions to get the conversation started:<\/p>

  1. What are the essential components of a good bug report?<\/li>\t
  2. How do you effectively reproduce and describe a bug in your report?<\/li>\t
  3. What additional information should be included, such as system details or error messages?<\/li>\t
  4. Are there any best practices or common pitfalls to avoid when writing bug reports?<\/li>\t
  5. How do you strike a balance between providing enough information and keeping the report concise?<\/li><\/ol>

    Feel free to share your personal experiences, tips, and any resources you've found helpful in mastering the art of writing bug reports. Let's use this opportunity to learn from each other and enhance our collective knowledge.<\/p>

    I'm excited to hear your insights and engage in a fruitful discussion. Thank you in advance for your input!<\/p>

    Looking forward to your responses.<\/p>","quoteUsername":"IOan","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote & Reply","Share":"Share"}}}">

2回答

一个
Userlevel 5
徽章 + 3

非常好的问题!

什么是良好的错误报告的组成部分?

  • 错误的一个简短的摘要行业务,管理和类似的
  • 重现这个bug的步骤,保证开发人员
  • 描述什么是错误和行为原因+如果必要,为什么你相信一个问题和任何错误消息,代码生成或类似
  • 分类、优先级和严重程度来帮助项目团队决策的风险,如果它应该是固定的(相对于其他bug修复、维护技术债务和新功能的承诺)

应该包含哪些额外信息,比如系统细节或错误消息吗?

  • 任何系统、用户、时间等细节与繁殖有关的问题。即它只出现在一个管理员帐户登录,测试而不是开发或刺激,只有00:00-02:00小时之间。
  • 上面描述的错误消息。我个人不喜欢截图总体上占用的空间后台,需要一个额外的步骤或几个点击打开&很大程度上只是显示相同的有用的错误信息。
  • 是所遇到的日期和时间的问题以及计算机名和用户名如果在使用日志系统,开发人员可以用它来查找事件日志,堆栈跟踪等。

你如何平衡提供足够的信息和报告保持简洁?

经常测试管理工具将为你这样做,通过不同的下拉字段等一切不在1单一文本框并提供一个缺陷的可追溯性链接回一个测试用例步骤重现这个bug的()——所有可以找到减少的细节需要进入一个描述字段。

通过包括尽可能多的细节,你会减少误解的范围向前或向后+你&开发人员之间的沟通可能需要诊断和修复bug。我宁可谨慎&推荐自己太多而不是太少的细节。

但是你可以添加一个总结行对于非开发人员,顶部一行程序描述对于那些不需要所有的细节。这些链接可能会给一些灵感制定这些:

https://hbr.org/2016/11/how-to-write-email-with-military-precision

https://www.linkedin.com/pulse/what-military-can-teach-us-writing-effective-emails-damon-penny/

Really good question!<\/p>

What are the essential components of a good bug report?<\/strong><\/p>

  • A short summary line of the bug for business, management and similar<\/li>\t
  • Steps which are guaranteed to reproduce the bug for developers<\/li>\t
  • A description of what the bug is and the behaviour it causes + if necessary, why you believe it a problem & any error messages, codes or similar generated<\/li>\t
  • Categorisation, priority and severity to aid decisions by the project team on risk, if and when it ought to be fixed (in relation to other bug fixes, maintenance, technical debt and new feature promises)<\/li><\/ul>

    \u00a0<\/p>

    What additional information should be included, such as system details or error messages?<\/strong><\/p>

    • Any system, user, timing etc. details relevant for reproducing the issue. I.e. does it only appear when an Admin account is logged in, on TEST but not DEV or PROD and only between the hours of 00:00-02:00.<\/li>\t
    • Error messages stated above. I\u2019m personally not a fan of screenshots on the whole as they take up backend space, require an extra step or few clicks to open & largely just show the same useful error message anyhow.\u00a0<\/li>\t
    • The date and time the bug was encountered as well as the computer name and user name if a logging system is in use which the developers can use to lookup event logs, stack traces etc.<\/li><\/ul>

      \u00a0<\/p>

      How do you strike a balance between providing enough information and keeping the report concise?<\/strong><\/p>

      Often the test management tools will do this for you, by means of different dropdown fields etc. so everything isn\u2019t in 1 single textbox and providing traceability linking of a defect back to a test case where the steps to follow (to reproduce the bug) can be found - all reducing the amount of detail needed to be entered into a description field.<\/p>

      \u00a0<\/p>

      By including as much detail as possible, you\u2019re reducing the scope of misunderstanding or backwards + forwards communication between you & the developers who need to troubleshoot & potentially fix the bug. I\u2019d err on the side of caution & recommend too much rather than too little detail myself.\u00a0<\/p>

      \u00a0<\/p>

      However you could add a summary line for non-developers, a one-liner description at the top for those who don\u2019t need all the details. These links might give some inspiration for formulating those:<\/p>

      https:\/\/hbr.org\/2016\/11\/how-to-write-email-with-military-precision<\/a><\/p>

      https:\/\/www.linkedin.com\/pulse\/what-military-can-teach-us-writing-effective-emails-damon-penny\/<\/a><\/p>","quoteUsername":"alex_read","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote & Reply","Share":"Share"}}}">

mmario.ffrohlich
Userlevel 2
徽章 + 2

这是一个例子如何结构bug报告。请记住,实际的报告,应该使用/还取决于你工作的公司制定的流程和规定。

测试人员:用户执行的细节

日期:测试时的日期执行

浏览器:测试期间使用的浏览器

严重程度:低,中,高,关键,杀杀杀…

标题(X > Y > Z):短而简洁的描述问题

(X > > Z一部分表示应用程序的一部分的路径发现问题)

描述:这部分是用来解释何时何地被发现的问题。它也可以被用来大纲相关的任何细节问题

重现步骤:

1。一步X

2。一步Y

1。一步Z

预期结果:

在X步:

  • 预期要发生的事情,在任何给定的步骤

实际结果:

在X步:

  • 事情发生不同形式的预期结果

验收标准:

  • 满足某些标准,为了机票被认为是成功完成

附件:

  • 包括与明确的标志图像观察问题
  • 包括网络细节从谷歌控制台(或任何其他浏览器使用)
  • 视频重现问题的步骤和观察到的问题(我个人尝试包括这些尽我所能)
这是一个我,马里奥!
This is an example on how i structure bug reports. Please keep in mind that the actual report that should\/is used also depends on the processes and regulations set by the company you work for.<\/p>

\u00a0<\/p>

Tester:<\/strong> details of the user performing<\/p>

Date: <\/strong>date when the testing was performed<\/p>

Browser:<\/strong> browser that was used during testing<\/p>

Severity:<\/strong> low, mid, high, critical, blocker\u2026<\/p>

\u00a0<\/p>

Title<\/strong>: [ X > Y > Z] short and concise\u00a0description of the issue <\/em><\/p>

(the X>Y>Z <\/em>part denotes the path to the part of the application where the issue was found)<\/p>

\u00a0<\/p>

Description: <\/strong>this part is used to explain when and where the issue was found. It can also be used to outline any details that are relevant to the issue<\/p>

\u00a0<\/p>

Steps to reproduce:<\/strong><\/p>

1. Step X<\/p>

2. Step Y<\/p>

\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 1. Step Z<\/p>

\u00a0<\/p>

Expected results:<\/strong><\/p>

At step X: <\/u><\/em><\/p>

  • Something-something that is expected to happen at any given step<\/li><\/ul>

    Actual results:<\/strong><\/p>

    At step X: <\/u><\/em><\/p>

    • Something-something that is happening that is different form the expected results<\/li><\/ul>

      Acceptance criteria:<\/strong><\/p>

      • some criteria that has to be met in order for the ticket to be considered successfully finished<\/li><\/ul>

        Attachments:<\/strong><\/p>

        • include images with clearly marked issue observed<\/li>\t
        • include network details from the google console (or any other browser that you use)<\/li>\t
        • video showing steps to reproduce the issue and the issue observed (personally, I try to include these as much as I can)<\/li><\/ul>","quoteUsername":"mmario.ffrohlich","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote & Reply","Share":"Share"}}}">

回复


Learn more about our cookies.<\/a>","cookiepolicy.button":"Accept cookies","cookiepolicy.button.deny":"Deny all","cookiepolicy.link":"Cookie settings","cookiepolicy.modal.title":"Cookie settings","cookiepolicy.modal.content":"We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.<\/a>","cookiepolicy.modal.level1":"Basic
Functional","cookiepolicy.modal.level2":"Normal
Functional + analytics","cookiepolicy.modal.level3":"Complete
Functional + analytics + social media + embedded videos"}}}">

金宝搏app官网下载
Baidu