unity engine_Unity Engine质量检查流程

unity engine

We often get requests to explain how we test the engine before we release it. We have previously blogged about it, but none of these posts give a clear overview of the entire process. It’s a large undertaking to do in just one post and for that reason this will be a series of blog posts.

我们经常会收到要求解释发布引擎之前如何测试引擎的请求。 我们以前曾在博客上发布过 相关文章，但是这些帖子都没有清楚地概述整个过程。 只需一篇帖子，这是一项艰巨的任务，因此，这将是一系列博客文章。

This first post is going to outline the structure of our test efforts and subsequent blog posts will be made to describe details of each individual part, always linking back to this overview. It is also worth noting that every strategy comes from the product and deployment model, so our process on the engine is very different from the process we use on our services. This blog series relates only to the Unity engine itself.

第一篇文章将概述我们测试工作的结构，随后的博客文章将描述每个单独部分的细节，并始终链接到此概述。 还值得注意的是，每种策略都来自产品和部署模型，因此我们在引擎上的流程与我们在服务上使用的流程非常不同。 本博客系列仅涉及Unity引擎本身。

In the simplest form, our releases go through the following lifecycle:

以最简单的形式，我们的发行版经历以下生命周期：

This is what is most obvious to our users, because our version numbering follows the same structure. With this frame we can start exploring what happens at every stage of the product from a QA point of view.

这对我们的用户来说是最显而易见的，因为我们的版本编号遵循相同的结构。 有了这个框架，我们可以从质量检查的角度开始探索产品每个阶段会发生什么。

Before we even get code into trunk where we integrate all the features, we do testing on the feature in a branch based off of our mainline source repo, trunk. This is typically feedback on the usability of the feature and ensuring it doesn’t introduce massive instability. How this is done effectively is a topic for a blog post of its own.

在我们将代码集成到主干中以集成所有功能之前，我们在基于主线源存储库主干的分支中对功能进行测试。 这通常是对功能可用性的反馈，并确保它不会引起巨大的不稳定性。 如何有效地做到这一点是其博客文章的主题。

Once the feature has been tested in-branch, the developers create the initial Pull Request (PR) in which a code review is done on the code, all automation has been executed and proven to pass, a review of the test cases written is done and the Release Manager does a risk assessment before merging it to trunk. A lot of this is automated through our merge queue process, but it can involve 20-30 people to get a big feature into trunk. And remember, this process is done on every single PR going to trunk, not just one time.. All of these are blog topics for later.

在分支中对功能进行测试后，开发人员将创建初始的请求请求(PR)，在该请求中对代码进行代码审查，所有自动化均已执行并证明可通过，对已编写的测试用例进行审查然后发布管理器在将其合并到主干之前进行风险评估。 其中很多是通过我们的合并队列过程自动完成的，但可能需要20到30个人才能将主要功能引入主干。 请记住，此过程是在中继的每个PR上完成的，而不仅仅是一次。.所有这些都是稍后的Blog主题。

In the alpha phase, it is all about integration of all the features done in the branches. Before we send the first alpha to the alpha list, we run our Release Acceptance Test (RAT), which is a smoke test covering the surface of the platforms and the editor to make sure we have human eyes on as many parts as possible before we ship.

在Alpha阶段，所有内容都与分支中完成的所有功能的集成有关。 在将第一个Alpha发送到Alpha列表之前，我们运行发布验收测试(RAT)，该测试是覆盖平台和编辑器表面的烟雾测试，以确保在我们尝试之前尽可能多地观察人眼船。

During the following alphas we get more branches trickling in and we continue our integration testing on the builds. During this time we also get a lot of user feedback on the usability and viability of the features from our alpha users. This sometimes results in a feature being cut completely from the release.

在下面的Alpha中，我们会引入更多分支，并继续在构建上进行集成测试。 在这段时间里，我们还从Alpha用户那里获得了许多用户对功能可用性和可用性的反馈。 有时这会导致功能从发行版中被完全删除。

In the end of the alpha phase we have an Exploratory Test (ET) week. This approach was  covered by Claus in 2013 and the format remains the same today.

在Alpha阶段结束时，我们进行了探索性测试(ET)周。 克劳斯(Claus)在2013年采用了 这种方法， 今天的格式仍然不变。

The beta phase is now fully public, so we ship the builds directly to all users. Creating the engine with our community has been a key part of how we developed Unity through all the years and it is still an integral part of every release.

Beta阶段现已完全公开，因此我们将构建直接发送给所有用户。 多年来，与我们的社区一起创建引擎一直是我们开发Unity的关键部分，并且仍然是每个发行版中不可或缺的一部分。

During the beta phase we do a Full Test Pass (FTP), which is a manual regression test pass of all our manual test cases, which test the various workflows and runtime features, spread across all the supported platforms, so we get as broad a surface as possible with human eyes and brains on all of it.

在测试阶段，我们进行了全面测试通过(FTP)，这是我们所有手动测试用例的手动回归测试通过，测试了各种工作流程和运行时功能，这些功能分布在所有受支持的平台上，因此我们获得了尽可能在人的眼睛和大脑上浮出水面。

The FTPv2 is a special session we carry out to combine the workflows to make actual games with the build. It is a fun and intense way of testing Unity.

FTPv2是一个特殊的会话，我们将其结合起来以结合实际工作流程来制作实际游戏。 这是测试Unity的一种有趣而激烈的方式。

The Asset Store Bash is three days where we go through a list of Asset Store packages compiled from the top 500, upgrade the projects and see if they reveal problems in the builds.

Asset Store Bash为期三天，我们将浏览从前500名编译的Asset Store软件包列表，升级项目并查看它们是否在构建中发现问题。

The documentation bash is a few days where we go through our documentation in order to find bugs and discrepancies between the docs and the actual functionality in the engine.

几天以来，我们一直在浏览文档，以查找文档与引擎中实际功能之间的错误和差异。

We also execute upgrade tests, in which we take large user projects and upgrade them. It is surprisingly difficult to perform this test and we most certainly need a blog post explaining why this is so. We realize it is a source of a lot of user pain, so we invest a lot of effort in this.

我们还执行升级测试，在该测试中，我们将处理大型用户项目并对其进行升级。 进行这项测试非常困难，我们非常需要一个博客文章来解释为什么这样做。 我们意识到这是用户痛苦的根源，因此我们为此付出了很多努力。

The release candidate phase is started off by an RC Test Phase where we do a risk driven pass on the engine. This risk assessment is done by the dev teams involved in each area and we use this to drive a targeted effort to get more comfortable with the state of the product before release.

候选发布阶段由RC测试阶段开始，在该阶段我们对引擎进行风险驱动传递。 该风险评估由各个领域的开发团队完成，我们以此为基础进行有针对性的工作，以使产品在发布前更加满意。

We also run RATs on every one of the RC releases, because they are candidates to be released. As such we treat all of them as the last one.

我们还在每个RC版本中运行RAT，因为它们是要发布的候选对象。 因此，我们将所有这些都视为最后一个。

In the lifetime of a release we are constantly getting bugs reported by our users. Our community and users are the most important asset of Unity and we value this contribution more than anything else in the process of making a Unity version come to life. It is definitely not an easy task and we have posted multiple blog posts about how we handle this flow of bugs. Best place to read about it is The Great Incident Bash of 2015.

在发布的整个生命周期中，我们不断收到用户报告的错误。 我们的社区和用户是Unity的最重要资产，在实现Unity版本的过程中，我们最重视这一贡献。 绝对不是一件容易的事，我们已经发布了多篇有关如何处理此类错误的博客文章。 最好的阅读方法是 2015年的“重大事件重击” 。

Throughout all our releases in the entire lifetime of the release we verify all bugs fixed. During verification we go through the steps to reproduce the bug, look around the immediate area around the fix to find fallout and then close it or reactivate it depending on the result.

在整个发行版的整个发行版中，我们都会验证所有已修复的错误。 在验证过程中，我们将按照步骤进行操作以重现该错误，并在修复程序的周围区域内查找辐射，然后根据结果将其关闭或重新激活。

During the lifetime of the engine, we also run our performance regression test suite multiple times. Sakari made a two part blog post about it two years ago and lots has happened since. It is a tough problem to solve consistently and we have invested a lot of effort into this, so we will make a part three to update you on what is going on these days.

在引擎的生命周期内，我们还会多次运行性能回归测试套件。 Sakari在两年前发表了两部分博客文章 ，此后发生了很多事情。 始终如一地解决这是一个棘手的问题，我们为此付出了很多努力，因此我们将分三部分向您介绍这些天的最新情况。

It’s important to also understand that testing a platform is a separate discipline in itself. We are helped by having lots of our automation be able to run on all our platforms, but there is a lot of custom manual testing needed for each platform because they all have their independent functionality to consider.

同样重要的是要了解，测试平台本身就是一门独立的学科。 我们有很多自动化可以在所有平台上运行，这为我们提供了帮助，但是每个平台都需要进行大量自定义手动测试，因为它们都具有各自独立的功能。

Once a version has been shipped, it goes into sustained engineering (SE) mode. This team was founded two years ago and a lot has happened since. They are responsible for all the patches we send out and we will most certainly create an updated blogpost about how this team is now functioning.

发行版本后，它将进入持续工程(SE)模式。 该团队成立于两年前 ，此后发生了很多事情。 他们负责我们发出的所有补丁程序，我们肯定会创建一个有关该团队现在如何运作的更新博客。

I hope this sheds some light on the overall process of shipping a piece of software as complicated as Unity. We will post a lot more blogs about the details of all these parts. The automation we are doing is such a big part of our process and ability to ship all these platforms, so we will create a similar overview post dedicated to this.

我希望这可以为交付像Unity这样复杂的软件的整体过程提供一些启示。 我们将发布更多有关所有这些部分的详细信息的博客。 我们正在执行的自动化是我们流程的重要组成部分，并且具有交付所有这些平台的能力，因此，我们将为此创建一个类似的概述文章。

翻译自: https://blogs.unity3d.com/2016/05/18/the-unity-engine-qa-process/

unity engine