很多人都很好奇我们发布新版本前的测试流程。我们也发布过相关的文章，但这些文章基本上都描述得不够清晰。想用一篇文章就说明这个过程还是比较有挑战性的，所以后续我们会发布一系列文章来讨论这个话题。今天为大家分享第一篇。

本文将介绍引擎测试概况，后续的文章则会分别详细讲解其中的原理，并提供与这篇总览相关的分析。当然，我们的策略都是基于产品和开发模型的，所以在对引擎的处理流程上与服务比有很大不同。而本系列文章将只围绕Unity引擎来展开。

简单来说，我们的发布流程如下：



用户通常都很熟悉这一套流程，因为我们的版本命名规则也是以此而来。基于这个框架，我们将会从QA的角度来探索其中的每一个阶段，并讨论各个阶段中发生的事情。



在将所有功能代码分支合并之前，我们会在主代码仓库的分支上对新功能进行测试。这是关于可用性的例行测试，确保新功能不会导致系统不稳定。关于如何高效地完成该测试步骤，敬请期待后续的文章。



新功能测试通过后，开发者发送代码推送请求（Pull Request, PR)，表示该部分的特性检查已完成，所有自动化流程测试完毕，测试用例报告也已经写好。此时发布经理（Release Manger）就会在合并到主分支前对代码进行一次风险评估。合并流程中还会有很多次类似这样的自动化测试，不过在涉及到某些重要功能时还是会需要约20～30个人帮助测试。需要注意的是，每次发起推送请求到主分支时都会进行一次这样的流程。这些相关的详细介绍也会在后续的文章中分享。



在Alpha阶段，需要做的工作基本上就是将所有已完成的新功能进行整合。在将第一个Alpha版本发布到Alpha列表之前，我们会进行一次发布验收测试（Release Acceptanc Test, RAT），即冒烟测试，包括测试各个平台的外部表现以及编辑器，确保我们在发布前顾及到尽可能多的功能。

在接下来的Alpha测试中，我们还会陆续整合各个功能代码分支，并且继续对版本进行集成测试。这个时候我们还会收到来自Alpha版用户关于新功能的实用性和可行性反馈。有时会导致某个功能被彻底从发布版本中移除。

Alpha阶段的最后，我们花一周进行探索测试（Exploratory Test，ET），形式与之前介绍过的一样保持不变。



Beta阶段测试完全公开，对所有用户开放。借助社区的力量来开发引擎是我们开发Unity以来一直遵循的准则，也是发布正式版本必不可少的一部分。
Beta阶段，我们会进行一次全面测试（Full Test Pass, FTP），即手动回归测试并通过所有人工测试用例，该步骤用来测试不同工作流和运行时功能，测试涉及到所有支持的平台，这样我们就能尽可能多地关注到引擎的各方各面。

FTPv2测试比较特别，我们会整合所有的工作流，用最新的版本制作实际的游戏。这是一种有趣而紧张的测试Unity的方式。

资源商店测试耗时三天，我们会使用资源商店最流行的500个包进行测试，即使用最新测试版本升级这些包的工程，查看是否会遇到问题。

文档测试耗时数日，我们会检查文档，寻找可能的bug以及和新版本引擎功能相悖的条目。

我们还会进行升级测试，选择一些用户基数大的工程，对它们进行升级。这一步骤通常会遇到很大困难，我们将在另外一篇文章里对其进行详细讲解。我们意识到这也是很多用户遇到问题的根源，因此我们会更加关注这一层面。



候选发布阶段以RC测试阶段开始，该测试会对引擎进行风险驱动测试。风险评估由各个部分的开发团队一起完成，我们以此进行有针对性的努力让产品在发布前达到更稳定的状态。

我们还会为每个RC发布进行RAT测试。它们都是候选发布版本，因此它们都会被看作是发布前的最后一个版本。



在发布周期中，我们会持续不断地收到用户反馈的Bug。我们的社区和用户是Unity的重要组成部分，同时也在发布Unity新版本中扮演着重要的角色。处理这些Bug并不容易，我们已经发布了一系列文章，讲述处理这些bug的方式。可查看2015大事记阅读相关内容。

在整个发布周期中，我们会验证查看所有的Bug是否均已被修复。验证步骤中，我们会根据报告试图重现已知的Bug，查看与Bug修复相关的所有功能，检查该修复是否产生了其他的Bug，最后关闭掉这个Bug的修复进程，或根据结果重新启动修复工作。

引擎发展生命周期中，我们还会多次运行性能回归测试套件。两年前Sakari对此发表过两篇文章，其中提及的很多情况已经发生。这个问题并不容易解决，我们为此作出了很多努力，后续还将发表第三篇文章，让您了解最近一段时间发生的事情。

同样需要强调的是，为某个特定平台做测试本质上完全是一门独立的课题。尽管为了让引擎能运行在所有支持的平台上我们做了很多自动化的工作也受益颇丰，但我们仍然需要针对每个平台进行大量的人工测试，因为要顾及很多平有的功能。



一旦某个版本正式发布后，该版本就会进入持续性工程模式（Sustained engineering mode, SE mode）。我们在两年前成立了一个小组做了非常多的事情，他们负责所有发布的补丁版本。关于这个小组的职责，我们将在后续的文章中详细讲解。

希望这篇文章可以或多或少地阐述清楚如何发布像Unity这样复杂的软件，我们还会发布更多文章，详细讲解所有发布细节。目前我们使用的自动化测试流程占据了整个体系的很大一部分，也正因有它们我们才可以顺利地交付面向各个平台的软件，后续我们还会专门发布一篇类似的文章来简单介绍该流程。


原文链接：http://blogs.unity3d.com/2016/05/18/the-unity-engine-qa-process/
原文作者：THOMAS PETERSEN
感谢Unity官方中文社区翻译组成员：“E.A.S” 对本文翻译所做的贡献。
转载请注明来源：Unity官方中文社区 (forum.china.unity3d.com)。请勿私自更改任何版权说明信息。


Unity, 测试

锐亚教育 锐亚科技 unity unity教程