处理错误报告

No software releases without bugs. And while our QA is working hard to find as many bugs as possible, some of them still go under the radar. It might be because it only happens in some very specific configurations – looking at you, double SLI Titan owner ;) – or because we were focusing on a more risky area, or just because we plainly missed it. This happens in most software companies. However, those bugs still reach you and in order to fix them we need your bug reports. (Of course, if they’re already in the issue tracker, it means we know about them.)

没有错误，不会发布任何软件。 尽管我们的质量检查人员正在努力寻找尽可能多的错误，但其中一些错误仍然存​​在。 可能是因为它仅在某些非常特定的配置中发生–看着您，SLI Titan的双重所有者；)–或者是因为我们专注于风险更大的领域，或者仅仅是因为我们完全错过了它。 大多数软件公司都会发生这种情况。 但是，这些错误仍然可以找到您，为了修复它们，我们需要您的错误报告。 (当然，如果它们已经在问题跟踪器中 ，则意味着我们知道它们。)

If you ever sent us a bug report and never got a reply, you might have wondered why. In this post I’ll try to explain why that happens and what we’re doing to try and fix this as well.

如果您曾经向我们发送错误报告但从未得到答复，您可能想知道为什么。 在这篇文章中，我将尝试解释为什么会发生这种情况，以及我们在尝试如何解决此问题。

First of all, let’s look at how many bug reports you are sending us:

首先，让我们看一下您发送给我们的错误报告：

Each column in this chart is a month. As we can see, for almost two years (and actually, for quite a long while even before that) we have been hovering at around 5k bug reports every month. Now, to clarify, this is 5k times the bug reporter was used to send us a bug report each month, of which only a very small amount are actual bugs. We call these reports incidents; they become bugs once we confirm internally that they are bugs.

此图表中的每一列都是一个月。 正如我们所看到的，将近两年(实际上，甚至在那之前很长一段时间)，我们一直徘徊在每个月大约5,000个bug报告上。 现在澄清一下，这是错误报告者每月向我们发送错误报告的5000倍，其中只有很少一部分是实际错误。 我们称这些为报告事件； 一旦我们内部确认它们是错误，它们就会变成错误。

We have a student worker team located in Vilnius and Kaunas who work on verifying incidents on our end and either turning them into bugs, or looking for some other resolution (finding a duplicate bug, finding that the issue is actually not a bug, etc).

我们在维尔纽斯和考纳斯设有一个学生团队，他们负责验证我们的事件并将其转变为错误，或者寻找其他解决方案(查找重复的错误，发现问题实际上不是错误，等等)。 。

Each student takes one of these incidents and tries to reproduce it on their machine using all the information supplied. If they succeed, we have a new bug report (barring it being a duplicate). If they can’t reproduce it they will write back to you asking for more information.

每个学生都会发生这些事件之一，并尝试使用提供的所有信息在其计算机上重现该事件。 如果他们成功了，我们将收到一个新的错误报告(除非重复)。 如果他们无法复制它，他们会写信给您，要求更多信息。

Anyways, here’s how many incident reports we have handled monthly since the beginning of 2016:

无论如何，以下是自2016年初以来我们每月处理的事件报告：

Combining these two charts together, we can see the delta of incidents every month. We want this to be at 0 (or above 0, as we’d rather handle everything and some of the old ones too).

将这两个图表结合在一起，我们可以看到每个月的事件增量。 我们希望它为0(或大于0，因为我们也希望处理所有内容和一些旧的内容)。

The spikes in June and August happened because of some mass closings of old cases.

由于一些旧案大量结案，因此在6月和8月出现了峰值。

Everything was going great until September came around. You see a lot of students lowered their work hours since a new semester began and they need more time for their learning efforts. 500 cases piled up since then but we are actively working on them and bringing down the pile by 100 cases each week!

一切都进行得很好，直到九月来临。 您会发现，自新学期开始以来，许多学生减少了工作时间，他们需要更多时间进行学习。 从那以后堆积了500箱，但我们一直在积极地努力，每周减少100箱！

This is huge – once we have a complete hang of this process it means that you’ll be able to rely on us to give you a timely response to your bug reports.

这是巨大的-一旦我们完全掌握了该过程，这意味着您将能够依靠我们对您的错误报告做出及时的响应。

---

---

订阅我们的Beta新闻 (Sign up for our beta newsletter)

Help us make Unity even better and get a sneak peek of what’s coming up in future versions of Unity. Sign up for our beta newsletter to get notified when there is a new beta version available.

帮助我们使Unity变得更好，并简要了解Unity的未来版本中的功能。 订阅我们的Beta新闻，以在有新Beta版本可用时得到通知。

()

First Name: Last Name: Email Address:

名字： 姓： 电子邮件地址：

翻译自: https://blogs.unity3d.com/2017/10/24/handling-your-bug-reports/