Unity3D虚拟现实交互制作（拓展） Unity3D虚拟现实交互制作（拓展） 深入了解Unity的情景测试.docx

深入了解Unity的情景测试 此前在 Unity引擎QA流程一文中提到，每个Unity版本在发布前都需要经过一系列的测试。本文中我们将深入讲解其中一项测试：Scenario Test Week（情景测试周，之前的博文称其为FTP v2）。 简单来说，就是通过创建游戏进行测试。我们先创建一系列的情景（游戏项目的一小部分）。例如“3D竞速游戏”、“2D跳台游戏”等。然后，这些参与者将会被分组，而每个团队被指定一个情景，参与团队需要在一周之内根据情景创建游戏。 在测试必威体育精装版的Unity 5.5版本时，我们使用了14个游戏情景。包括测试人员，学生员工和开发人员在内共有53个参与者。 但情景测试不仅仅是游戏创作。它有一个明确的测试目标：在编辑器环境下正常操作的过程中，发现程序错误。我们已经将编辑器功能和平台进行了细分，并映射到了不同的情景中，以尽可能全面的覆盖所有测试内容。通过实现不同的游戏类型情景，来保证功能测试方式的多样化，进而确保功能测试不只涵盖一种情景。 Unity 5.5情景测试周的情景与团队测试范围对照关系表 使用不同的测试方法可以发现不同的问题。Unity有超过60000种自动测试，而且这些自动测试每月会被执行上百万次。我们的手动回归套件（完整测试通路）包含了数以千计的手动测试用例，保证了对Unity各项功能的全面扫描。这些套件的价值无可估量！但一般来说这类测试都是检验独立的功能。有些错误是在结合多种功能以后才会发生的。或者会过一段时间才会出现。有些情况甚至是在前五次工作正常，第六次才会出错。而且，从整体上来说，自动化测试和手动测试用例是在不停重复相同的内容。虽然可以利用自动化测试的内容已经很多了，但是那也仅仅只是理论上Unity的交互方式中的一小部分。 情景测试则可以祢补这些不足。当开发者创建游戏时，不只是单纯的过一遍产品的所有功能。可能会重复某些动作，或者出现某些随机情况，与编辑器的交互方式变得超出功能设计甚至测试集的预测。最重要的是，这是项目中实实在在的去操作Unity编辑器。我们从中也些许感受到了终端用户的欢乐和沮丧。这很有效，因为这能帮助我们更好地了解自己的产品。 Unity 5.5情景测试周中提交的程序错误 这是一个情景测试反馈的例子。其中一个情景是创建一个即时战略游戏（见下方视频）。它的测试范围覆盖了AI、粒子系统和地形。然而，一旦游戏成型，自然会想到添加多人游戏功能。很快团队就遇到了游戏与当前网络系统的适配问题。所幸，他们可以及时将这些问题反馈给网络模块的研发组，而研发组将会据此考虑Unity未来的网络设定。因为特定的游戏类型会引导游戏引擎以特定方式被运用，所以我们能得到了这样的反馈。事实上，网络设置一般不是情景中的需要测试的范围，而自动测试和手动用例测试显然都不会提供这种信息。 3D RTS（3D即时战略）团队规模：4人。目标平台：台式机。专注范畴：AI、粒子系统、地形/SpeedTree整合 当然，我们依然在寻找改进情景测试的方法。我们正考虑在多个情景测试周中重复使用某些情景（例如多种版本的Unity）。目前为止，在每个测试阶段都会重新创建新的游戏。希望不但可以在生产过程中不断升级Unity，而且可以持续为项目服务而非仅制作原型版本。 我们并不指望小小的情景测试可以精确地复制使用Unity创建现实项目的完整经验。但是仍然希望可以进行更多更好的情景测试。不要忘记，这确实是种有趣的测试Unity的方法。 下面是我们在Unity 5.5情景测试周中的一些简单的示例项目。注意，除了每个项目提到的覆盖范围，所有的项目都使用了Unity Collaborate多人协作和Unity Cloud Build云构建。我们还测试了Unity提供的其他服务。资源商城也非常有用，它能让团队在项目中使用高质量的资源。这不仅提升了游戏产品的价值，而且还使用了复杂真实数据及资源进行了测试。 FPS game（射击游戏） 团队规模：4人。目标平台：台式机。专注范畴：音频、图像、材质、后处理 还有VR Museum（VR博物馆）及Slender Man Clone的示例项目演示视频，请点击【阅读原文】进入Unity官方中文社区查看。