图形化接口自动化测试_图形测试，自动化测试的最后一行

图形化接口自动化测试

There are dozens of platforms you can deploy to with Unity. It can be difficult for us developers at Unity to maintain visual integrity on all of them. Here is a quick peek into how we ensure graphics features don’t get unintentionally broken.

有 几十个平台， 您可以部署与统一。 对于Unity的开发人员来说，要保持所有开发人员的视觉完整性可能很困难。 快速浏览一下我们如何确保图形功能不会意外损坏。

We have a lot of automated tests. There are unit tests, integration tests, system tests inside Unity itself in the form of Editor and Playmode tests and finally we have Graphics tests. Graphics tests set up a scene with specific graphical features turned on or off, builds that scene, runs it on all supported devices and finally renders the output as an image.

我们有很多自动化测试。 Unity本身内部有单元测试，集成测试，系统测试(以Editor和Playmode测试的形式)，最后还有Graphics测试。 图形测试可设置具有打开或关闭特定图形功能的场景，构建该场景，在所有受支持的设备上运行该场景，最后将输出呈现为图像。

The resulting image is then compared with a previously approved reference image for that scene / graphics settings and device. Should any of the resulting images differ from the reference images, we then flag the test as failed and someone needs to manually verify if the fail is the result of some intentional or unintentional change that needs to get fixed.

然后将所得图像与该场景/图形设置和设备的先前批准的参考图像进行比较。 如果任何结果图像与参考图像不同，则我们将测试标记为失败，并且有人需要手动验证失败是否是由于需要修复的某些有意或无意的更改而导致的。

Since it’s not always easy to spot changes from the reference image to the resulting test image (see the example below), we also provide the failed test with a diff image.

由于发现从参考图像到最终测试图像的变化并不总是那么容易(请参见下面的示例)，因此我们还为失败的测试提供了差异图像。

Figure 1. From left to right, the reference image, test result image and finally the diff image.

图1.从左到右，分别是参考图像，测试结果图像和最后的差异图像。

What makes graphics tests a bit more difficult to work with compared to normal tests is that they are brittle. Different platforms, device models and graphics cards will produce slightly different results. So in order to get consistent results from graphics tests, they must be executed on the test farm where we are sure the hardware remains same. This means that the workflow for updating tests or adding a new one is a bit convoluted, the developer has to:

与普通测试相比，使图形测试更难工作的原因是它们很脆。 不同的平台，设备型号和图形卡将产生略有不同的结果。 因此，为了从图形测试中获得一致的结果，必须在测试场中执行它们，我们确定硬件保持不变。 这意味着更新测试或添加新测试的工作流程有些复杂，开发人员必须：

1. Make and push his changes

   做出并推动他的改变

2. Run the graphics tests on all appropriate devices

   在所有适当的设备上运行图形测试

3. Wait the tests to complete and fail

   等待测试完成并失败

4. Download the failed reference images from each of the builds

   从每个版本中下载失败的参考图像

5. Compare each reference image with the resulting image to ensure that the changes made are the expected changes

   将每个参考图像与生成的图像进行比较，以确保所做的更改是预期的更改

6. Copy all the new images that need to be updated into the graphics tests repository

   将所有需要更新的新图像复制到图形测试存储库中

7. Commit and push the changes to the graphics tests repository

   提交更改并将其推送到图形测试存储库

8. Run the graphics tests again

   再次运行图形测试

This entire process can be very time consuming, so to help make the process a bit easier, we made a small Polymer application with an Asp.net Core backend that queries our build statistics system Hoarder and finds all the graphics test on a specific revision. Then it downloads the graphics tests artifacts from the build system for each of the builds and presents the results on a single web page.

整个过程可能非常耗时，因此为了帮助 简化 过程，我们制作了一个 带有Asp.net Core后端 的小型 Polymer 应用程序，该应用程序查询构建统计系统Hoarder并查找特定修订版上的所有图形测试。 然后，它从构建系统中下载每个构建的图形测试工件，并将结果显示在单个网页上。

The developer can then see the failed tests and compare them with the reference images and diff images. However, the changes between two images aren’t always easy to spot, see the two images below:

然后，开发人员可以查看失败的测试，并将其与参考图像和差异图像进行比较。 但是，两个图像之间的变化并不总是很容易发现，请参见下面的两个图像：

So the tool allows the developer to toggle between the test image and reference image and/or the diff image and can now quickly see the changes in the image. This is helpful since it’s not always easy to spot the changes until you can swap back and forth between the two images.

因此，该工具允许开发人员在测试图像和参考图像和/或差异图像之间切换，现在可以快速查看图像中的更改。 这很有用，因为在您可以在两个图像之间来回切换之前，发现更改并不总是那么容易。

The developer can then select the tests he/she wants to update and finally get a command line to automatically download and update the selected images into his or hers graphics tests repository or manually download a combined zip file with the correct directory structure and copy them manually to their graphics tests repository.

然后，开发人员可以选择他/她想要更新的测试，并最终获得一个命令行，以自动将所选图像下载并更新到他或她的图形测试存储库中，或者手动下载具有正确目录结构的组合zip文件并手动复制它们到他们的图形测试库。

With over 13’700 graphics test distributed among 33 build configurations, and several updates every day to the graphics repository, this tool helps to make a developer’s life a bit better and it reduces some of the manual overhead when working with graphics tests.

该工具在33个构建配置中分配了13,700多个图形测试，并且每天对图形存储库进行多次更新，该工具有助于使开发人员的生活更好一些，并且可以减少使用图形测试时的一些手动开销。

翻译自: https://blogs.unity3d.com/2016/12/21/graphics-tests-the-last-line-of-automated-testing/

图形化接口自动化测试