其他
Unity引擎QA流程
本文将介绍引擎测试概况,后续的文章则会分别详细讲解其中的原理,并提供与这篇总览相关的分析。当然,我们的策略都是基于产品和开发模型的,所以在对引擎的处理流程上与其它服务比有很大不同。而本系列文章将只围绕Unity引擎来展开。
简单来说,我们的发布流程如下:
用户通常都很熟悉这一套流程,因为我们的版本命名规则也是以此而来。基于这个框架,我们将会从QA的角度来探索其中的每一个阶段,并讨论各个阶段中发生的事情。
在接下来的Alpha测试中,我们还会陆续整合各个功能代码分支,并且继续对版本进行集成测试。这个时候我们还会收到来自Alpha版用户关于新功能的实用性和可行性反馈。有时会导致某个功能被彻底从发布版本中移除。
Alpha阶段的最后,我们花一周进行探索测试(Exploratory Test,ET),形式与之前介绍过的一样保持不变。
Beta阶段,我们会进行一次全面测试(Full Test Pass, FTP),即手动回归测试并通过所有人工测试用例,该步骤用来测试不同工作流和运行时功能,测试涉及到所有支持的平台,这样我们就能尽可能多地关注到引擎的各方各面。
FTPv2测试比较特别,我们会整合所有的工作流,用最新的版本制作实际的游戏。这是一种有趣而紧张的测试Unity的方式。
资源商店测试耗时三天,我们会使用资源商店最流行的500个包进行测试,即使用最新测试版本升级这些包的工程,查看是否会遇到问题。
文档测试耗时数日,我们会检查文档,寻找可能的Bug以及和新版本引擎功能相悖的条目。
我们还会进行升级测试,选择一些用户基数大的工程,对它们进行升级。这一步骤通常会遇到很大困难,我们将在另外一篇文章里对其进行详细讲解。我们意识到这也是很多用户遇到问题的根源,因此我们会更加关注这一层面。
我们还会为每个RC发布进行RAT测试。它们都是候选发布版本,因此它们都会被看作是发布前的最后一个版本。
在整个发布周期中,我们会验证查看所有的Bug是否均已被修复。验证步骤中,我们会根据报告试图重现已知的Bug,查看与Bug修复相关的所有功能,检查该修复是否产生了其他的Bug,最后关闭掉这个Bug的修复进程,或根据结果重新启动修复工作。
引擎发展生命周期中,我们还会多次运行性能回归测试套件。两年前Sakari对此发表过两篇文章,其中提及的很多情况已经发生。这个问题并不容易解决,我们为此作出了很多努力,后续还将发表第三篇文章,让您了解最近一段时间发生的事情。
同样需要强调的是,为某个特定平台做测试本质上完全是一门独立的课题。尽管为了让引擎能运行在所有支持的平台上我们做了很多自动化的工作也受益颇丰,但我们仍然需要针对每个平台进行大量的人工测试,因为要顾及很多平台独有的功能。
希望这篇文章可以或多或少地阐述清楚如何发布像Unity这样复杂的软件,我们还会发布更多文章,详细讲解所有发布细节。目前我们使用的自动化测试流程占据了整个体系的很大一部分,也正因有它们我们才可以顺利地交付面向各个平台的软件,后续我们还会专门发布一篇类似的文章来简单介绍该流程。
为了更好地为大家提供本地化的服务,进一步了解大家使用Unity以及相关服务的情况,我们将正式开展本年度第一次《Unity问卷调查》(点击蓝字参与)。所有填写完整并提交的参与者,将有机会获得我们赠送的Unity官方纪念礼品。
问卷调查地址:https://www.wenjuan.com/s/zaEZVv/
我们还会分享更多Unity引擎相关的内容在Unity官方中文论坛(forum.china.unity3d.com),请保持关注!