公司斗争_推动错误斗争

公司斗争

Testing might not be a part of the romantic picture we all have about game development. Often it’s more seen as a dirty job that someone has to do. At Unity we have a growing team of test engineers who really love their job and take pride in achieving excellence, and I’d like to share with you a little bit about how we work. I am guessing that most of you have some kind of interest in us doing our job as good as possible and that you’d like to know what happens when you open the bug reporter and click ‘Submit’.

测试可能不是我们所有人都对游戏开发抱有幻想的一部分。 通常，它被视为某人必须要做的肮脏工作。 在Unity，我们有一支不断壮大的测试工程师团队，他们非常热爱自己的工作，并为实现卓越而感到自豪，我想与您分享一些我们的工作方式。 我猜想你们中的大多数人都对我们尽可能地做好我们的工作感兴趣，并且您想知道当打开错误报告器并单击“提交”时会发生什么。

Incoming When you submit a bug report it goes into our Incoming Bug Queue. From there we do what we call sweeping. We weed out bug reports that contain nothing at all – no description, no information and no attached project, and we weed out the spam.

传入当您提交错误报告时，它将进入我们的传入错误队列。 从那里开始我们所谓的清扫。 我们清除了根本不包含任何内容的错误报告-没有描述，信息和附件项目，并且清除了垃圾邮件。

Investigation All other bugs go into our Investigation Queue. In there we look at each case and simplify it until we get the cleanest scenario possible where the bug happens. If the steps are too unclear for us to reproduce the bug, or if we need a test project, we reply back to you asking for what we need. It’s also often a matter of the user doing something wrong or needing some help. In that case we respond with the assistance needed and add an entry to the documentation or answers.unity3d.com if needed.

调查所有其他错误进入我们的调查队列。 在这里，我们会仔细研究每种情况，并对其进行简化，直到我们找到发生错误的最干净的情况为止。 如果步骤不清楚，我们无法重现该错误，或​​者我们需要测试项目，我们将回复您，询问我们需要什么。 这通常也是用户做错了事或需要帮助的问题。 在这种情况下，我们会以所需的帮助进行回复，并在文档或answer.unity3d.com中添加一个条目(如果需要)。

Test Creation The cases from investigation that are actually real bugs are then moved to our Test Creation Queue. Now what does that mean – didn’t we already test it? Well, it means that we take the simplified reproduction case and implement it in one of our automated test frameworks, depending on where the case fits. We have a few of those including our awesome Regression Rig. When the test is written, it will continuously run on multiple platforms. Whenever new code and functionality is committed, it will be held up against the growing list of tests. In theory this ensures that once a bug has been fixed and added to the automated tests, it will never show it’s ugly face again.

测试创建从调查中发现的实际上是实际错误的案例随后被移至我们的测试创建队列。 现在这意味着什么-我们是否已经对其进行了测试？ 好吧，这意味着我们将采用简化的复制案例，并根据案例适合的情况在一个自动测试框架中实施它。 我们有其中一些，包括我们出色的Regression Rig 。 编写测试时，它将连续在多个平台上运行。 只要提交了新的代码和功能，它将与不断增长的测试列表保持一致。 从理论上讲，这可以确保一旦修复了错误并将其添加到自动化测试中，便永远不会再显示出丑陋的面Kong。

Fixing and verifying From the test creation queue we end up with either writing a test or in some cases where this is not feasible, we make sure that the steps to reproduce the bugs are crystal clear. Then we assign the case to development. One of our highly specialized developers will take the case, fix it and send it back to us for verification. At this point the test written should always pass and the test department also verifies the fix manually. If something is not right, it’s back to the developer until we are sure the bug is really fixed.

修复和验证从测试创建队列开始，我们要么编写测试，要么在某些不可行的情况下，确保重现错误的步骤非常清晰。 然后，我们将案例分配给开发人员。 我们的一位高度专业化的开发人员将处理此案，将其修复并发回给我们进行验证。 在这一点上，书面测试应始终通过，并且测试部门还应手动验证此修复程序。 如果有什么不对劲，则将问题归还给开发人员，直到我们确定该错误已得到真正修复。

It has taken us a long time to hone these processes – Unity has grown immensely since the early days when there wasn’t even a Test department but just a handful of programmers making the product, testing it and providing support. Unity is now vastly bigger in terms of features, users and people working on the product. This also means, that there was a time when our capacity for handling bugs and support cases was lower and we didn’t have the same processes. The test team is bigger now and armed to the teeth with sharpened minds, rockstar programming skills and a work horse mentality.

我们花了很长时间来完善这些流程–自从甚至没有测试部门，但只有少数几个程序员制作产品，对其进行测试并提供支持的Unity以来，Unity取得了长足的发展。 现在，就功能，用户和产品工作人员而言，Unity的功能要大得多。 这也意味着，有时候我们处理错误和支持案例的能力较低，而我们没有相同的流程。 现在，测试团队规模越来越大，并以敏锐的胸怀，摇滚明星的编程技能和勤奋的工作态度武装起来。

Onwards! One of the ways we’re moving along now is drawing a line somewhere in the backlog of cases from when our capacity was lower. We have a bunch of old cases where the majority are duplicates of already fixed cases, cases with no information or cases that are obsolete because of changes in Unity. We will be focusing on the newer bugs, but there will also be something in that old pile that still has relevance. Chances are that these issues will have been reported again with Unity 2.6 or 3.0, but if you are sitting with an old bug report you submitted, that you believe is still relevant then you can help us get to it by submitting it again.

向前！ 我们现在所采取的方法之一是在能力不足的情况下，在积压的案件中划清界限。 我们有一堆旧案例，其中大多数是已经固定的案例的重复案例，没有信息的案例或由于Unity更改而过时的案例。 我们将专注于较新的错误，但是在那堆旧错误中仍然会有一些相关性。 这些问题可能会在Unity 2.6或3.0中再次报告，但是如果您正等待提交的旧错误报告，并且认为仍然存在问题，则可以通过再次提交来帮助我们解决此问题。

We are aiming for a workflow where we process each and every relevant case that gets opened and provide feedback as soon as possible. I hope you’re up for the task of helping us by submitting high quality bug reports and that you will continue to have a little patience and love for the Test Team – cause we love you!

我们的目标是建立一个工作流程，在此流程中，我们将处理每个已打开的相关案例并尽快提供反馈。 我希望您能够通过提交高质量的错误报告来完成帮助我们的任务，并希望您继续对测试团队保持一点耐心和热爱–因为我们爱您！

翻译自: https://blogs.unity3d.com/2010/10/29/moving-the-bug-fight-forward/

公司斗争