unity压力测试框架_运行时测试– Unity的运行时API测试框架

unity压力测试框架

Hi, my name is Kasper Amstrup Andersen, and I am leading the Toolsmiths Team here at Unity. The Toolsmiths Team consists of 6 developers, and we work on tools, frameworks, and infrastructure – and then we also spend a great deal of time actually testing Unity. The team is located in Copenhagen (Denmark), Odessa (Ukraine), and Helsinki (Finland). In this blog post I will tell you about one of the frameworks we are currently working on: The Unity Runtime Test Framework.

嗨，我叫Kasper Amstrup Andersen，我在Unity领导Toolsmiths团队。 Toolsmiths团队由6名开发人员组成，我们致力于工具，框架和基础架构的开发，然后我们还花费大量时间来实际测试Unity。 该团队位于哥本哈根(丹麦)，敖德萨(乌克兰)和赫尔辛基(芬兰)。 在此博客文章中，我将向您介绍我们当前正在研究的框架之一：Unity Runtime Test Framework。

At Unity QA our passion is “Quality”. We like testing and we love to be smart about the testing we do. We now have 4 teams of very dedicated and professional testers and developers that spend every day making sure that Unity “just works” for everyone. The teams are: Test Engineers, Test Developers, Toolsmiths, and Student Workers (we have previously written a bit about the teams). A huge challenge when testing Unity is actually breaking down the product in logical components where it can make sense to talk about test coverage. The main headache is Unity’s many platforms which are in many ways (but not all) orthogonal to the core feature set. To give you an example: We have areas and we have platforms, but then we also have platform-specific areas (and features). A testing matrix basically explodes.

在Unity QA，我们的热情是“质量”。 我们喜欢测试，我们喜欢对我们所做的测试保持精明。 现在，我们有4个团队，由高度敬业和专业的测试人员和开发人员组成，每天花费大量时间来确保Unity对所有人“有效”。 这些团队是：测试工程师，测试开发人员，工具匠和学生工作者(我们之前已经对团队进行了一些介绍 )。 测试Unity时面临的巨大挑战实际上是将产品分解为逻辑组件，在这些组件中谈论测试覆盖范围很有意义。 最令人头疼的是Unity的许多平台，这些平台在许多方面(但不是全部)与核心功能集正交。 举一个例子：我们既有区域又有平台，但是我们还有特定于平台的区域(和功能)。 测试矩阵基本上会爆炸。

In our Runtime API Test Framework we treat platforms as being completely orthogonal to features. This assumption allows us to make a specialized framework that gives a lot of coverage with very little effort. You write a test once; the framework will make it run everywhere.

在我们的运行时API测试框架中，我们将平台视为与功能完全正交。 这个假设使我们能够创建一个专门的框架，从而只需很少的努力就可以覆盖很多内容。 您编写一次测试； 该框架将使其在任何地方运行。

Before kicking off, I’ll give you some numbers and quick facts:

在开始之前，我将为您提供一些数字和事实：

运行时测试框架 (The Runtime Test Framework)

We have named our Runtime API Test Framework “Runtime Tests”. So, what is a Runtime Test? It’s basically a test case that verifies some functionality in the Unity Runtime Classes. The Runtime Test Framework allows us to write a test case in C# and then it will run on all platforms without any boiler plating code. The framework is integrated into our build system and developers and testers run all tests in the branches where they are working + in Trunk, our shared code repository, whenever there are changes. Some of the framework’s core features are:

我们将运行时API测试框架命名为“运行时测试”。 那么，什么是运行时测试？ 基本上，这是一个测试用例，用于验证Unity Runtime Classes中的某些功能。 运行时测试框架允许我们用C＃编写测试用例，然后它将在所有平台上运行，而无需任何锅炉代码。 该框架已集成到我们的构建系统中，只要有更改，开发人员和测试人员就会在工作所在的分支+我们的共享代码存储库Trunk中运行所有测试。 该框架的一些核心功能包括：

The Runtime Test Framework consists of the following modules:

运行时测试框架包含以下模块：

• Unity.Automation: Functionality for starting and interacting with the Unity Editor.

  Unity.Automation：用于启动Unity编辑器并与之交互的功能。

The different modules, and how they depend on each other, is shown in the figure below.

下图显示了不同的模块，以及它们如何相互依赖。

The framework consists of runner-side part and a player-side part. The player-side uses a very barebones implementation (no use of interfaces, generics etc.) since it must run on all players (also players we might consider to add in the future).

该框架包括跑步者部分和选手部分。 播放器端使用非常准系统的实现(不使用接口，泛型等)，因为它必须在所有播放器(也可能是我们将来考虑添加的播放器)上运行。

An example of actual test execution is shown in the figure below.

下图显示了实际测试执行的示例。

The runner will load the test assembly (Unity.RuntimeTests) and then pass control to the framework (1, 2). The framework will start a Unity Editor process (3). Then, it will create (or copy in) all assets required to run tests, and start building a scene for each test (4). This is done by invoking saved delegates inside the Editor process. Pre-made assets are stored together with the test assembly. For tests using the WWW class the framework will start a webserver where [request, response] pairs can be saved during setup (5). At runtime a test can then make a www request which will be redirected to the webserver by the framework. Finally, a player is built and started, test results are consumed, and a test report will be generated (6, 7a, 7b, 8).

运行程序将加载测试程序集(Unity.RuntimeTests)，然后将控制权传递给框架(1、2)。 框架将启动Unity编辑器过程(3)。 然后，它将创建(或复制)运行测试所需的所有资产，并开始为每个测试构建场景(4)。 这是通过在编辑器过程中调用保存的委托来完成的。 预制资产与测试组件一起存储。 对于使用WWW类的测试，框架将启动一个Web服务器，在设置过程中可以保存[请求，响应]对(5)。 然后，在运行时，测试可以发出www请求，该请求将由框架重定向到Web服务器。 最后，构建并启动播放器，使用测试结果，并生成测试报告(6、7a，7b，8)。

报告后端 (The reporting backend)

The reporting backend scans the test assembly (Unity.RuntimeTests) and monitors all tests. This allows us to track various metrics. An example is shown below.

报告后端扫描测试程序集(Unity.RuntimeTests)并监视所有测试。 这使我们能够跟踪各种指标。 一个例子如下所示。

This chart shows all Runtime Tests grouped by area. The horizontal axis shows “area” and the vertical axis shows “number of tests”.

该图表显示了按区域分组的所有运行时测试。 横轴表示“面积”，纵轴表示“测试次数”。

而已… (That’s it…)

So, there you have it. That’s our Runtime Tests. We like them and they make writing tests for all Unity players easy and fun. And then they simply give a lot of “test-bang-for-the-buck”. But this is just one of the many things we’re currently working on in the Toolsmiths Team. I look forward to share more in future blog posts.

所以你有它。 那就是我们的运行时测试。 我们喜欢他们，他们使所有Unity玩家的写作测试变得轻松有趣。 然后，他们只是简单地给出了很多“价格低廉的测试方法”。 但这只是我们Toolsmiths团队目前正在从事的众多工作之一。 我期待在以后的博客文章中分享更多。

翻译自: https://blogs.unity3d.com/2013/06/02/runtime-tests-unitys-runtime-api-test-framework/

unity压力测试框架