Art resource testing method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides an art resource testing method and device, electronic equipment and a storage medium. The test method comprises the following steps: acquiring a test case comprising art resources to be tested, wherein the art resources comprise digital graphic assets for presenting a three-dimensional model; automatically distributing the test cases to a plurality of test devices to enable the test devices to execute the test cases; obtaining an execution result returned by the test equipment, wherein the execution result comprises screenshots of a plurality of key view angles of the art resources obtained in the execution process of the test case; calculating the difference degree between the screenshot and the reference image; and generating a test result according to the difference degree. According to the test method disclosed by the invention, full-process automation from test case preparation to result analysis is realized, human resource consumption is remarkably reduced, a traditional subjective evaluation mode depending on human eye recognition is replaced based on objective difference quantitative analysis, standardization and repeatability of a test process are realized, and the test efficiency is improved. And meanwhile, the test coverage rate and accuracy are improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to a method, apparatus, electronic device, and storage medium for testing art resources. Background Technology

[0002] This section is intended to provide background or context for embodiments of the invention as set forth in the claims. The description herein is not an admission that it is prior art simply because it is included in this section.

[0003] With the rapid development of the game industry, the demand for art assets is increasing daily, and the quality requirements for these assets are also becoming more stringent. However, due to the diversity of device configurations (such as different operating systems, resolutions, and hardware performance), the same art asset may exhibit different compatibility issues on different platforms, such as texture blurring and polygon misalignment. Traditional testing methods rely on manual testing and inspection, which is not only inefficient but also easily influenced by subjective factors, leading to inconsistent test results. Summary of the Invention

[0004] In this context, embodiments of the present invention aim to provide a method, apparatus, electronic device, and storage medium for testing art resources, in order to at least partially solve the aforementioned problems existing in the related art.

[0005] In a first aspect of the present invention, a method for testing art resources is provided, comprising: acquiring test cases including the art resources to be tested, the art resources including digital graphic assets for presenting a three-dimensional model; automatically assigning the test cases to multiple test devices to enable the test devices to execute the test cases; acquiring execution results returned by the test devices, the execution results including screenshots of multiple key perspectives of the art resources acquired during the execution of the test cases; calculating the degree of difference between the screenshots and reference images; and generating test results based on the degree of difference.

[0006] In a second aspect of the present invention, a testing apparatus for art resources is provided, comprising: a test case generation module for acquiring test cases including the art resources to be tested, the art resources including digital graphic assets for presenting a three-dimensional model; a test case distribution module for automatically distributing the test cases to multiple testing devices so that the testing devices execute the test cases; a test result collection module for acquiring the execution results returned by the testing devices, the execution results including screenshots of multiple key perspectives of the art resources acquired during the execution of the test cases; an image analysis module for calculating the difference between the screenshots and a reference image; and a test result generation module for generating test results based on the difference.

[0007] In a third aspect of the present invention, an electronic device is provided, comprising: a memory storing computer-executable instructions executable by a processor; and a processor for executing the computer-executable instructions to perform the steps in any of the above-described art resource testing methods.

[0008] In a fourth aspect of the present invention, a computer-readable storage medium is provided storing a computer program, which, when executed by a processor, performs the steps of any of the above-described art resource testing methods.

[0009] The technical solution disclosed herein automates the entire testing process for art assets, from test case preparation to result analysis. By automatically collecting rendering effects of art assets on multiple terminal devices and from different key perspectives, it significantly reduces human resource consumption. Comparative analysis using objective difference measurement algorithms replaces traditional subjective evaluation methods that rely on human visual identification, achieving standardization and repeatability of the testing process while improving test coverage and accuracy. Based on the quantitative difference analysis of this disclosure, compatibility issues can be accurately located, helping development teams quickly identify and prioritize high-risk problems, thereby improving the overall quality and cross-platform compatibility of game art assets and meeting the needs of rapid game iterative development. Attached Figure Description

[0010] The above and other objects, features, and advantages of exemplary embodiments of the present invention will become readily apparent from the following detailed description taken in conjunction with the accompanying drawings. Several embodiments of the invention are illustrated in the drawings by way of example and not limitation, wherein:

[0011] Figure 1 A schematic diagram illustrating the implementation environment of a testing method for art resources provided in this embodiment of the present disclosure;

[0012] Figure 2 A flowchart illustrating a method for testing art resources provided in this embodiment of the disclosure;

[0013] Figure 3 A schematic diagram of the structure of a testing device for art resources provided in an embodiment of this disclosure;

[0014] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure.

[0015] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation

[0016] To enable those skilled in the art to better understand the present disclosure, the technical solutions of the present disclosure will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of the present disclosure, and not all embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present disclosure.

[0017] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0018] The accompanying drawings are schematic illustrations of this disclosure and are not necessarily drawn to scale. Some block diagrams shown in the drawings may be functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in hardware modules or integrated circuits, or in networks, processors, or microcontrollers. Implementations can be carried out in various forms and should not be construed as limited to the examples set forth herein. The features, structures, or characteristics described in this disclosure can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough description of embodiments of this disclosure. However, those skilled in the art will recognize that one or more specific details may be omitted when implementing the technical solutions of this disclosure, or other methods, components, apparatuses, steps, etc., may be used to replace one or more specific details.

[0019] Figure 1A system architecture diagram of the operating environment of this exemplary embodiment is shown. This system architecture may include a terminal device 110 and a server 120. The terminal device 110 may be a mobile phone, tablet computer, personal computer, smart wearable device, game console, etc., and has a display function capable of displaying a graphical user interface, which may include the operating system interface or the application interface. An application, such as a game program, is installed on the terminal device 110. The server 120 generally refers to the backend system providing application services in this exemplary embodiment; it may be a single server or a cluster of multiple servers. For example, a game server program is deployed on the server 120 to perform server-side game data processing. The terminal device 110 and the server 120 can be connected via a wired or wireless communication link for data transmission. The method in one exemplary embodiment of this disclosure can be executed by any one or more of the terminal device 110 and the server 120.

[0020] In one implementation, the above method can be implemented and executed based on a cloud interaction system. The cloud interaction system can be the system architecture described above. Various cloud applications can run under the cloud interaction system, such as cloud gaming. Taking cloud gaming as an example, cloud gaming can be a game mode based on cloud computing. In the cloud gaming operation mode, the game program's execution entity and the game screen presentation entity are separated. The storage and execution of the game's control and interaction methods are completed on the cloud gaming server (such as the aforementioned server 120). The cloud gaming client (such as the aforementioned terminal device 110) is responsible for receiving and sending data and presenting the game screen. For example, the cloud gaming client can be a display device with data transmission capabilities located close to the user, such as a mobile terminal, television, computer, or PDA; while the cloud gaming server in the cloud performs information processing. When playing the game, the user operates the cloud gaming client to send operation commands to the cloud gaming server. The cloud gaming server runs the game according to the operation commands, encodes and compresses the game screen and other data, returns it to the cloud gaming client via the network, and finally, the cloud gaming client decodes and outputs the game screen.

[0021] In one implementation, the method described above can be implemented by the terminal device 110 alone. For example, without deploying the server 120, the terminal device 110 can run the application in a standalone environment to implement the game function and execute the method described above.

[0022] With the rapid development of the game industry, the demand for art assets is increasing, and the requirements for asset quality are also becoming higher. Due to the diversity of terminal devices, the same art asset may exhibit different compatibility issues on different platforms, such as texture blurring and polygon misalignment.

[0023] In related technologies, manual testing methods are primarily relied upon. This method typically uses human visual inspection to determine the display effect of art assets on different devices and platforms, combined with cross-platform testing to evaluate their compatibility and performance quality. In practice, developers need to prepare different versions of the package and submit them to a dedicated testing department for individual testing. Subsequently, the testing department runs these packages on different devices and records and reports issues through manual checks.

[0024] However, this manual testing method suffers from problems such as high subjectivity, low efficiency, and lack of quantitative evaluation. High subjectivity means that test results rely on human visual perception, making them susceptible to visual fatigue, lighting conditions, and individual differences, leading to less objective results. Low efficiency stems from the need to prepare package files individually and run test cases on different devices, a cumbersome and time-consuming process, especially when dealing with a large number of device models and resolutions, where testing efficiency cannot meet the needs of rapid iterative development. Furthermore, the existing solution lacks unified quantitative metrics to measure the compatibility and performance of art assets, resulting in inefficient problem localization and optimization processes.

[0025] Therefore, this disclosure aims to provide an efficient and automated compatibility testing solution that can complete large-scale testing tasks in a short time and accurately detect compatibility issues of art assets on different platforms, thereby improving the overall efficiency and quality of game development.

[0026] See Figure 2 According to one embodiment of this disclosure, a method for testing art resources is provided. The method includes: acquiring test cases comprising the art resources to be tested, the art resources including digital graphic assets for presenting a 3D model; automatically assigning the test cases to multiple testing devices to execute the test cases; acquiring execution results returned by the testing devices, the execution results including screenshots of multiple key perspectives of the art resources acquired during the execution of the test cases; calculating the degree of difference between the screenshots and a reference image; and generating test results based on the degree of difference. Thus, through automation, testing efficiency can be significantly improved, labor costs reduced, and the objectivity and accuracy of test results ensured.

[0027] Optionally, art assets refer to digital graphics assets used to present 3D models in games or interactive applications, including but not limited to character models, scene elements, props, buildings, and special effects. These assets typically consist of multiple components such as geometric data (model meshes), texture maps, material definitions, skeletal rigging, and animation data, which together form the basic elements of the game's visual presentation. On different platforms and devices, due to factors such as display adaptation, differences in hardware performance, and different graphics rendering pipelines, the same art asset may exhibit different visual effects, such as differences in texture clarity, polygon detail, and lighting rendering quality.

[0028] Optionally, test cases can be obtained, including those for the art assets to be tested. Specifically, before testing, testers need to collect the art assets to be tested and generate test cases based on a pre-defined test case template. These art assets can be digital graphic assets added or modified in specific business operations. Testers need to match the IDs of the corresponding assets in the game and modify the `case.py` file to achieve the purpose of test case modification. A test case is an executable test script or program designed to verify the compatibility of art assets on different platforms. It contains key information such as the ID information of the art asset to be tested, test scene configuration, camera angle presets, and screenshot rules. Test cases are usually written by testers based on product requirements and test objectives to guide the execution of automated testing processes. A complete test case should include a series of operation instructions such as initializing the environment, loading art assets, positioning the camera, adjusting the viewpoint, capturing screenshots, and saving results.

[0029] Optionally, automatically distributing test cases to multiple test devices refers to using an automated testing system to package the written test case code and deploy it to multiple pre-configured test devices. This process requires no manual intervention; the system automatically selects devices that meet the testing requirements based on a preset device pool configuration and distributes test tasks in parallel. For example, Jenkins can automatically trigger packaging tasks and distribute the generated test cases to multiple test devices. Jenkins is a commonly used open-source automation server tool used for automated code building and packaging. Test devices can be physical devices, virtual devices, or emulators, covering various combinations of operating systems (iOS, Android, etc.), hardware configurations (high, medium, and low-end processors and graphics chips), screen resolutions, and aspect ratios. The automatic allocation mechanism ensures load balancing of test tasks, optimizes resource utilization efficiency, and supports intelligent task scheduling based on factors such as device priority and test importance. This allows for large-scale compatibility testing to be completed in a short time while ensuring comprehensive test coverage.

[0030] Optionally, the execution result refers to the set of output data generated after the test equipment runs the test cases. This mainly includes screenshots of art assets from different key perspectives, test logs, performance data, and other information. Screenshots are the most crucial part of the execution result, visually recording the actual rendering effect of the art assets on a specific test equipment. In addition to visual images, the execution result may also include metadata information for the screenshots (such as device model, resolution settings, rendering parameters, etc.), as well as auxiliary information such as anomaly records and frame rate statistics during the test. The system will organize these execution results according to a unified data structure for easy subsequent analysis and comparison.

[0031] Optionally, the difference between the screenshot and the reference image can be calculated. Specifically, this involves comparing and detecting differences between the screenshots collected from each device and the reference image using an image comparison algorithm. The reference image can be a screenshot of the same art resource taken at the same viewpoint and resolution after running the same test case on a selected benchmark device (usually a high-performance PC or flagship mobile device). The more similar the comparison results of the two images, the better the compatibility of the art resource; conversely, the greater the difference, the more likely there are compatibility issues. In this way, through quantitative evaluation using image comparison algorithms, the performance differences of art resources on different platforms can be objectively measured, avoiding the bias of subjective human evaluation.

[0032] Optionally, test cases can be generated and managed using a version control system, such as Git. After testers verify the code locally, they can create a temporary branch for testing using Git and commit the updated test code to the version control system. This ensures more standardized and efficient version management of test cases, avoiding testing problems caused by version inconsistencies.

[0033] Optionally, the screenshot process includes multiple verification steps. Immediately after image capture, basic verification is performed: checking image integrity (not a black screen / distorted image), model center position, and resolution. For screenshots that fail verification, camera parameters are automatically adjusted and the image is retaken, with a maximum number of retries set as needed. This rigorous quality control process ensures the accuracy of subsequent analysis.

[0034] Optionally, in terms of test extensions, it not only supports testing of static art assets but can also be extended to verify dynamic effects, such as character animations, particle effects, and scene transitions. For testing dynamic effects, the system will design logic in the test cases to continuously capture multiple frames, and then analyze these frame sequences to evaluate the consistency and smoothness of the dynamic effects on different devices.

[0035] Optionally, collecting art assets for testing specifically includes newly added or modified 3D model assets selected by testers from the game development asset library. These assets typically contain elements such as textures, materials, and mesh data, and each asset has a unique asset ID. The collection process needs to ensure that the asset version matches the current testing requirements to avoid testing deviations caused by version inconsistencies. In this way, the accuracy and representativeness of the test sample are guaranteed from the source.

[0036] In an optional implementation, obtaining test cases that include the art assets to be tested includes: collecting the art assets to be tested; generating test cases that include the art assets to be tested according to a preset test case template; and submitting the test cases, after local process verification, to the version control system. This ensures the standardization and reliability of the test cases, improves the overall efficiency and quality of the testing process, and enables effective management and tracking of test cases through the version control system, facilitating team collaboration and problem backtracking.

[0037] Optionally, collecting art assets to be tested refers to the testers needing to determine the specific target resource scope for this test before execution, including but not limited to various 3D art assets such as character models, scene elements, props, and special effects. These resources can be newly developed art assets or existing assets that have been modified or optimized. The preset test case template is a pre-designed standardized testing framework containing core elements such as test scene configuration, camera parameters, and execution steps. When generating test cases, testers need to map the art asset ID to the corresponding field in the template and configure parameters such as test angle and resolution. The template is implemented using Python scripts, and test case customization is completed by modifying the resource reference relationships in the case.py file. This improves test case generation efficiency while ensuring the standardization of the testing process.

[0038] Optionally, local process verification refers to simulating the entire process of executing test cases in the development environment. Verification content includes key aspects such as the correctness of art resource loading, the smoothness of camera perspective switching, and the integrity of screenshot saving. Verification pass criteria include: all preset angle screenshots are generated completely, images have no abnormal noise, and models have no clipping issues. This allows for the early identification and resolution of basic configuration problems, avoiding unnecessary resource consumption from ineffective testing.

[0039] Optionally, the version control system uses the Git distributed management tool. The commit operation includes: creating a new branch based on the art asset test branch, pushing the modified test scripts to the remote repository, and generating a commit record containing change descriptions. The system automatically triggers a code review process to ensure that the commits comply with specifications. This achieves collaborative management and change traceability of test code.

[0040] Optionally, during the art asset collection phase, the system supports multiple resource classification and management methods. Art assets can be categorized and organized according to type (e.g., character models, scene elements, special effects), development stage (e.g., concept design, preliminary modeling, final optimization), or priority (high, medium, low). Testers can use the system's resource browser to directly select the art assets to be tested from the game asset library. The system automatically extracts the metadata information of these resources, such as creator, last modified time, and version number, and associates this information with test cases, providing a basis for subsequent issue tracking and version comparison. Furthermore, the system allows testers to add custom tags and annotations to each art asset, marking special testing requirements or concerns, such as "high-polygon," "complex lighting and reflection," and "transparent materials." These tags will be used for subsequent test result analysis and report generation.

[0041] In an optional implementation, key viewpoints include: front view, left side view, right side view, back view, top view, and bottom view of the art asset. This multi-angle, comprehensive testing allows for a complete evaluation of the rendering effect of the art asset under different viewpoints, improving the comprehensiveness and accuracy of the test.

[0042] Optionally, the frontal view of an art asset refers to the perspective from which the virtual camera is positioned directly in front of the art asset model, facing its main orientation. The frontal view is typically the most frequently observed perspective for art assets and is one of the most important perspectives in user experience; therefore, it is the first perspective captured and analyzed during testing. In games, the rendering effect of art assets from the frontal view directly impacts the user's first impression; therefore, the test results for the frontal view are often given high weight.

[0043] Optionally, the left-side and right-side views refer to the camera angles taken from approximately 45° to 90° to the left and right of the art asset model, respectively. These two views typically showcase the model's side profile and details, and are important for evaluating the model's three-dimensionality and the quality of its side textures. In many game scenarios, players frequently observe characters or objects from the side, making the rendering quality of side views equally crucial. When acquiring side views, the system rotates the virtual camera horizontally by a specific angle from the frontal view position to ensure that side features are fully captured.

[0044] Optionally, the back view refers to the perspective taken by a virtual camera positioned directly behind the art asset model. The back view is typically used to evaluate the texture quality, geometric details, and rendering effects of the model's back, elements that will also be observed by the player during gameplay. Especially in third-person games, the character's back is often the perspective from which players observe for the longest time, making back view testing particularly important.

[0045] Optionally, the top-down view refers to the perspective taken by the virtual camera positioned directly above the art asset model, looking down from above. The top-down view is primarily used to evaluate the texture quality, geometry, and rendering effects of the top of the model, which is particularly important in certain game genres (such as strategy games and top-down games).

[0046] Optionally, the bottom view refers to the perspective taken by the virtual camera positioned directly below the art asset model, looking upwards. The bottom view is used to evaluate the texture quality, geometric details, and rendering effects of the model's bottom. Although players rarely observe models from this angle during normal gameplay, it remains important in some special scenarios (such as flight games and climbing scenes).

[0047] Optionally, during actual testing, the system can dynamically adjust the specific angles of key viewpoints based on the characteristics of the art assets and testing requirements. For example, for models with special structures or important details, additional intermediate viewpoints (such as 45°, 135°, 225°, and 315° angles) can be added for testing to more comprehensively cover all aspects of the model. This flexible angle adjustment can be configured automatically or manually based on the complexity and importance of the art assets, ensuring that the testing process provides optimal test coverage for different types of art assets. For some highly asymmetric models or models with special observation requirements, the system can also support the configuration of custom viewpoints, allowing testers to specify additional special viewpoints in test cases according to specific needs. In this way, the testing process can more flexibly adapt to the needs of various complex art assets, improving the relevance and effectiveness of the testing.

[0048] Optionally, the system also supports perspective optimization strategies for specific art asset types. For example, for character models, the system will pay extra attention to facial details and may add close-up facial views; for weapon and equipment assets, the system will focus on testing the rendering effects in a first-person perspective; for scene assets, the system will add multiple distant and mid-range perspective tests. These perspective optimization strategies for different types of art assets are encapsulated in test case templates. Testers only need to specify the type of art asset, and the system will automatically apply the corresponding perspective testing strategy. Simultaneously, the system also allows testers to override the default strategy and add or remove specific perspectives when necessary. In practical applications, this flexible perspective optimization strategy can greatly improve the relevance and efficiency of testing, ensuring that system resources are used for the most critical test points. Thus, through targeted perspective testing strategies, the utilization efficiency of test resources can be optimized while ensuring comprehensive testing.

[0049] In an optional implementation, screenshots of multiple key perspectives of the art assets are obtained by: in response to the test case running to the virtual scene where the art assets are displayed; acquiring screenshots of multiple key perspectives of the art assets captured by a virtual camera in the virtual scene adjusted to different key perspective directions of the art assets. This simulates the actual scene of a user observing art assets in the game, ensuring that the test results accurately reflect the actual display effect of the art assets in the game.

[0050] Optionally, when test cases run to the virtual scene showcasing art assets, a series of predefined test scripts will be automatically triggered. These scripts are responsible for navigating to the virtual scene showcasing art assets and ensuring that the execution environment of the test cases is consistent with expectations. For example, the test scripts will automatically load the game scene containing the art assets to be tested and ensure that all elements in the scene have been loaded correctly. This avoids deviations in test results caused by incomplete or incorrect scene loading, ensuring the reliability and accuracy of the tests.

[0051] Optionally, a virtual scene refers to a specialized environment created in a game or other 3D application to showcase art assets. This environment typically features a neutral background, uniform lighting conditions, and appropriate spatial dimensions to clearly display and evaluate various aspects of the art assets. A virtual scene can be a simple gray or white environment or a scenario specifically designed based on the type of art asset; for example, character models might be placed on a flat surface, while architectural models may require a larger display space. By showcasing art assets in standardized virtual scenes, the interference of external environmental factors on test results can be eliminated, ensuring the objectivity and comparability of the evaluation results. In this way, the test results can more accurately reflect the quality and compatibility issues of the art assets themselves, rather than being obscured by environmental factors.

[0052] Optionally, a virtual camera refers to a software component that simulates the function of a real camera in a 3D virtual environment, used to control the user's perspective and observation method in the virtual world. In games or 3D applications, the virtual camera determines the content and perspective that the player or user can see. It has attributes similar to a real camera, such as position, orientation, field of view (FOV), focal length, and depth of field. In the testing system, the control of the virtual camera is automated, capturing different angles and details of art assets through preset parameters and paths.

[0053] Optionally, adjusting the virtual camera to different key viewpoints of the art asset refers to controlling the position and orientation of the virtual camera through code written in the test case, allowing it to observe the target art asset from multiple predefined angles in sequence. These predefined angles typically include, but are not limited to, key viewpoints such as front, left, right, back, top, and bottom.

[0054] Optionally, when capturing a frontal screenshot, the virtual camera will be automatically positioned at an appropriate distance directly in front of the model to ensure that the entire model is fully displayed within the field of view and that the model is centered in the image to obtain the best testing results.

[0055] Optionally, a screenshot of the left-side view is typically taken by rotating the camera counterclockwise by approximately 45° to 90° from the front view, while a screenshot of the right-side view is taken by rotating the camera clockwise by approximately 45° to 90°.

[0056] Optionally, when capturing a screenshot from the rear view, the virtual camera will be rotated horizontally by 180° from the front view position to ensure that all details of the model's rear are fully captured. In practice, the camera distance and height from the rear view will be automatically adjusted to ensure that the model's rear is displayed completely and centered in the screenshot, avoiding any incomplete or offset images of the model.

[0057] Optionally, when capturing a screenshot from the top view, the virtual camera will be moved vertically upwards to an appropriate height directly above the model, and the camera angle will be adjusted to shoot vertically downwards. During actual testing, the system dynamically adjusts the camera height based on the size and shape of the model to ensure the entire top surface is captured. For models with special shapes, such as tall buildings or models with complex top structures, the system will use a combination of multiple top-view angles to ensure comprehensive coverage.

[0058] Optionally, when capturing a screenshot from the bottom view, the virtual camera will be moved vertically downwards to an appropriate position directly below the model, and the camera angle will be adjusted to shoot vertically upwards. In practice, for models close to the ground, the system will use a special cropping method to ensure that the details of the bottom of the model are clearly captured without being obscured by the ground. Simultaneously, to ensure the effectiveness of the bottom view test, the system will adjust the lighting conditions to ensure sufficient brightness in the bottom area for detecting potential problems.

[0059] Optionally, in practice, virtual camera control can be achieved through APIs provided by the game engine or a custom camera control system. For example, in games developed using the Unity engine, the position and orientation of the virtual camera can be precisely controlled using the `Camera.transform.position` and `Camera.transform.rotation` properties. The camera's movement path can be pre-calculated and stored in a configuration file, or dynamically calculated at runtime based on the size and position of the art assets. To ensure screenshot consistency, the system may need to wait several frames after each camera position adjustment to ensure all rendering effects (such as dynamic shadows, reflections, etc.) have been fully loaded and stabilized. Simultaneously, to obtain more comprehensive visual information, the system can also capture screenshots under different lighting conditions (such as daytime and nighttime scenes) to evaluate the performance of art assets in various environments. In this way, through a comprehensive and precise camera control strategy, the system can acquire the most representative visual data, improving the comprehensiveness of the test and the reliability of the results.

[0060] Optionally, to more accurately evaluate the quality and compatibility of art assets, more complex virtual camera movement paths can be implemented. In addition to static key-view screenshots, dynamic camera paths can be executed, such as 360-degree surround shots around the art asset or zoom-in shots from far to near, capturing detailed changes when viewing the art asset from different distances. For specific types of art assets, such as animated character models, a series of screenshots can be captured while the model performs key animations (such as walking, jumping, or attacking), evaluating the rendering effect in dynamic states. Furthermore, additional screenshots can be taken from extreme perspectives (such as observing texture details at extremely close range or viewing the model from uncommon angles), as these extreme cases often more easily expose rendering problems. Thus, through rich and diverse camera paths and screenshot strategies, the performance of art assets under various conditions can be more comprehensively evaluated, improving the test coverage and problem detection capabilities.

[0061] Optionally, to improve screenshot quality and analysis accuracy, adaptive screenshot parameter adjustments can be implemented. Before capturing a screenshot, the brightness distribution, contrast, and sharpness of the current scene are analyzed, and then screenshot parameters (such as exposure value, contrast, and color saturation) are dynamically adjusted to obtain optimal image quality. For certain art assets requiring special attention to detail (such as surfaces with complex textures or subtle geometric structures), a high-resolution screenshot mode can be automatically enabled to capture image data with a higher resolution than that of a standard screen. Furthermore, an intelligent judgment mechanism can be implemented to automatically detect the presence of temporary UI elements, debugging information, or other interfering factors in the screenshot. If such interference is detected, the screenshot will be automatically recaptured. In this way, through intelligent and adaptive screenshot strategies, the highest quality and analytical value of the acquired visual data can be ensured, further improving the accuracy and reliability of the test results.

[0062] In an optional implementation, the execution results also include screenshots of the art assets at different resolutions from multiple key perspectives; different resolutions correspond to different display resolutions of the test device. Thus, by acquiring screenshots of the art assets at different resolutions, the adaptability of the art assets on various display devices can be comprehensively evaluated, compatibility issues that only occur at specific resolutions can be effectively detected, and the comprehensiveness and accuracy of the test can be improved.

[0063] Optionally, screenshots at different resolutions refer to images captured during testing from the same perspective of the same artwork resource, but at different screen resolution settings. These resolutions are typically categorized into four levels according to industry standards: high, medium, low, and ultra-high definition, corresponding to different levels of terminal device display capabilities. For example, low resolution might be 1280×720 pixels (HD), medium resolution is 1920×1080 pixels (Full HD), high resolution is 2560×1440 pixels (QHD), and ultra-high definition resolution is 3840×2160 pixels (4K UHD). The testing device will automatically select the closest standard level based on its own hardware capabilities, while maintaining the original aspect ratio. For devices with special aspect ratios (such as 18:9 full-screen displays), appropriate black borders will be intelligently added or a safe area will be cropped.

[0064] Optionally, screenshots at different resolutions can be used to evaluate the cross-platform compatibility of art assets. For example, some art assets may perform well at high resolutions on certain platforms, but may exhibit compatibility issues at the same resolution on other platforms. By comparing screenshots of the same art asset on devices with the same logical resolution but different physical resolutions (such as the performance of 1080p on mobile phones and VR headsets), and analyzing the impact of platform-specific factors such as projection distortion and field-of-view differences on the art effects, these cross-platform compatibility issues can be identified, thus providing developers with more comprehensive optimization suggestions. Furthermore, screenshots at different resolutions can also be used to evaluate the performance of art assets on different devices. For instance, some assets may require higher computing resources at high resolutions on certain devices, leading to a decrease in device performance. Multi-resolution testing can identify these issues and provide a basis for optimization.

[0065] Optionally, specific technical implementations for resolution adaptation include: obtaining the GPU's maximum texture size and available video memory through a device query interface, and intelligently selecting the optimal testing scheme. For memory-constrained devices, texture streaming and asset sub-packaging mechanisms are automatically enabled. Video memory usage is monitored in real time during testing, and automatically downgrades to a more conservative testing configuration when the threshold is exceeded.

[0066] Optionally, testing at multiple resolutions can simulate the display effects of art assets on terminal devices with different display resolutions or in different resolution display modes on the same terminal device, ensuring that the test covers various screen configurations. Certain specific compatibility issues may only appear at specific resolutions or during specific resolution changes, such as texture stretching, pixelation, or UI element misalignment. By testing on representative devices with different resolutions, the adaptability and stability of art assets can be comprehensively evaluated. This allows the development team to identify and resolve resolution-related adaptation issues early, improving the game's compatibility and user experience.

[0067] Optionally, to ensure the consistency and comparability of test results, all other rendering parameters are kept constant when acquiring screenshots at different resolutions. These parameters include, but are not limited to: lighting conditions, camera FOV (field of view), material quality settings, anti-aliasing level, and post-processing effects. These parameters are strictly controlled through configuration files to ensure that resolution is the only variable affecting the rendering results. Furthermore, the hardware specifications and driver versions of the test devices are recorded to account for potential hardware differences in subsequent analysis. In extreme cases, such as insufficient device memory to support rendering at a specific resolution, the test at that resolution level is automatically skipped and clearly marked in the report to avoid misleading test results. In this way, by strictly controlling the test environment and conditions, highly reliable and repeatable test data can be generated, providing a scientific basis for evaluating the resolution compatibility of art assets.

[0068] Optionally, the game's rendering resolution can be dynamically adjusted during testing to simulate the display capabilities of different terminal devices. This process is achieved through the game engine's built-in resolution scaling function, simulating rendering effects at different resolutions without changing the physical resolution of the test device. Specifically, the game's rendering resolution is set sequentially according to a predefined resolution sequence (e.g., 720p, 1080p, 1440p, 4K). After capturing screenshots of all key perspectives at each resolution, the test is switched to the next resolution level. During resolution switching, the game engine is ensured to be fully loaded and rendered stably before screenshots are taken, avoiding inaccurate test results due to unstable rendering during the transition phase. In this way, through a procedural resolution switching and screenshot process, the test can efficiently obtain comprehensive resolution adaptation data, providing reliable support for cross-platform adaptation of art assets.

[0069] In an optional implementation, the method further includes: creating a corresponding folder for each test device; and saving screenshots of multiple key perspectives of each art asset in the corresponding test device's folder according to a unified naming convention. This standardized file management mechanism ensures the orderly storage and rapid retrieval of massive amounts of test data, providing structured data support for subsequent analysis.

[0070] Optionally, creating a corresponding folder for each test device means establishing a separate file directory for each participating terminal device within the test storage structure, based on its device identifier (such as device name, device ID, or device model). This storage method completely isolates test data generated by different devices, preventing data confusion and overwriting. For example, folders can be named in the format "DeviceID_DeviceModel_Resolution," such as "Device001_iPhoneX_2436x1125," "Device002_SamsungS20_3200x1440," etc., clearly identifying the basic information of each test device. The folder structure can be further subdivided into multiple subfolders, such as categorized by test date, test batch, or art resource type, forming a hierarchical storage structure. This allows testers to quickly locate test data for specific devices, improving the efficiency of data retrieval and analysis.

[0071] Optionally, saving screenshots of multiple key perspectives for each art asset according to a unified naming convention means using a consistent file naming standard for all screenshots. This ensures that screenshots of the same art asset from the same perspective can be accurately identified and matched across different devices. The naming convention typically includes key elements such as the art asset ID, perspective information, resolution information, and timestamp. For example, it could use the naming format "AssetID_ViewAngle_Resolution_Timestamp.png". Here, AssetID represents the unique identifier of the art asset; ViewAngle indicates the perspective from which the screenshot was captured, such as "Front", "Left", "Right", "Back", "Top", and "Bottom"; Resolution indicates the resolution of the screenshot, such as "1920x1080"; and Timestamp indicates the time the screenshot was captured, in the format "YYYYMMDD_HHMMSS". This naming method allows for automatic matching of screenshots captured under the same conditions on different devices, providing a foundation for subsequent image comparison and analysis.

[0072] Optionally, multiple key perspective screenshots refer to capturing the rendering effects of art assets from different angles by controlling a virtual camera. These screenshots typically include six standard perspectives: front, left, right, back, top, and bottom, to comprehensively evaluate the performance of the art assets from various angles. In practical applications, more intermediate or close-up perspectives, such as "left front 45 degrees" or "right front 45 degrees," can be added based on the characteristics of the art assets and testing needs to more comprehensively evaluate the rendering quality of the art assets. For certain special types of art assets (such as models with complex textures or special lighting effects), dedicated detailed perspective screenshots can also be added to more accurately detect potential problems.

[0073] Optionally, storing screenshots in the corresponding test device's folder means categorizing and storing them by device, ensuring that all test data generated by each device is concentrated in its dedicated folder. Within each device folder, subfolders are further created according to the art asset ID, organizing screenshots from different perspectives of the same art asset together. This hierarchical storage structure allows the testing team to easily compare the rendering effects of the same art asset on different devices, or analyze the overall performance of all art assets on a specific device. Simultaneously, this storage method also facilitates batch processing and automated analysis; by traversing the folder structure, paired screenshots can be automatically identified and processed for image comparison analysis.

[0074] Optionally, an automated folder creation mechanism can be implemented during testing. When assigning test tasks to various devices, the system first checks if the corresponding device folder already exists in storage. If it doesn't exist, a new device folder is automatically created; if it already exists, it determines whether a new test batch subfolder needs to be created. This automated folder management mechanism reduces manual intervention and avoids data management chaos caused by inconsistent folder structures. Simultaneously, storage space usage is checked regularly, and test administrators are reminded to archive or clean up historical data when necessary, ensuring the stable operation of the test environment. In this way, the testing team doesn't need to worry about infrastructure maintenance details and can focus their efforts on test content and quality assessment.

[0075] Optionally, besides creating separate folders for each test device and saving screenshots according to a unified naming convention, a version control mechanism can be introduced to ensure version management of test results. For example, suppose a certain art asset generates multiple key perspective screenshots in different versions of the test. These screenshots can be stored in separate folders and named according to a unified naming convention. A version control mechanism, such as Git, can be introduced to manage the screenshots for each version. This allows testers to quickly find the required screenshots in different versions of the test for comparative analysis. Furthermore, a version control mechanism can help testers quickly revert to the test results of a specific version. For example, if the test results of a certain version need to be re-verified, testers can quickly find the corresponding screenshots through the version control mechanism and retest. This allows testers to manage and revert test results more efficiently, improving testing efficiency.

[0076] In an optional implementation, calculating the difference between a screenshot and a reference image includes: acquiring a reference image, which is a screenshot of a key viewpoint of an art resource obtained by executing test cases on a benchmark testing device; calculating the peak signal-to-noise ratio (PSNR) between the screenshot returned by the testing device from the same viewpoint of the same art resource and the screenshot of the reference image; and determining the degree of difference between screenshots of different art resources and the reference image based on the calculated PSNR. In this way, by comparing differences using objective mathematical algorithms, the differences in the rendering effects of art resources on different devices can be quantitatively evaluated, improving the accuracy and reliability of the test results.

[0077] Optionally, the selection of benchmark testing equipment needs to consider factors such as equipment performance, display accuracy, and stability. Typically, mainstream equipment with mid-to-high-end configurations is chosen as the benchmark to ensure that its rendering effects represent the actual experience of most users. The determination of benchmark equipment requires a rigorous screening and verification process, including hardware performance testing, display effect evaluation, and long-term stability monitoring. This ensures the quality and representativeness of the reference images, providing a reliable foundation for subsequent difference calculations.

[0078] Optionally, acquiring reference images is a crucial step in ensuring the reliability of test results. Reference images are standard screenshots of key perspectives of art assets obtained after the benchmark equipment executes the test cases. Furthermore, the screenshots of the art assets on the benchmark equipment are reviewed and verified by testers to ensure that the reference images themselves are free of quality issues. This establishes a high-quality reference standard, guaranteeing the accuracy of the test results.

[0079] Optionally, the difference between the screenshot and the reference image is calculated using the PSNR algorithm. PSNR (Peak Signal-to-Noise Ratio) is a widely used image quality assessment metric that quantifies image quality loss by calculating the mean square error between the original and distorted images. In practice, both the screenshot and the reference image are converted to grayscale, and then the difference value is calculated pixel by pixel. A higher PSNR value indicates better image quality. When the PSNR value is below a preset threshold, the system automatically marks the screenshot as having a compatibility issue. This allows for an objective and accurate assessment of the differences in display effects of art resources on different devices.

[0080] Optionally, "same viewpoint for the same art asset" refers to screenshots obtained on different test devices by controlling a virtual camera to capture the same art asset from the exact same viewpoint. To ensure viewpoint consistency, test cases precisely control the virtual camera's position coordinates, rotation angle, and field of view parameters to ensure that the art asset is captured from the same angle and distance on each test device. For example, when capturing a frontal view of the art asset, the virtual camera on each test device will be precisely positioned at the same coordinates directly in front of the art asset, maintaining the same camera parameter settings. Furthermore, the test results will record parameters such as ambient lighting conditions, shadow rendering settings, and post-processing effects during each viewpoint capture, ensuring that rendering comparisons are performed on each device under identical conditions. In this way, the PSNR value will only decrease when the rendering effect of the art asset itself differs on different devices, thus accurately reflecting compatibility issues of the art asset across different platforms.

[0081] Optionally, comparisons of the same art asset from the same viewpoint ensure the comparability and consistency of test results. The system strictly follows naming rules and storage paths to match corresponding screenshots and reference images, ensuring that the compared objects are indeed renderings of the same art asset from the same viewpoint. During the comparison process, the system first performs image alignment and size normalization to eliminate the impact of device resolution differences. This eliminates interfering factors, allowing the system to focus on evaluating the compatibility of the art asset itself.

[0082] Optionally, the degree of difference can be determined based on a preset multi-level evaluation standard. Differences can be categorized into multiple levels according to pre-set PSNR thresholds, such as highly similar (PSNR ≥ 40dB), good similarity (30dB ≤ PSNR < 40dB), acceptable difference (25dB ≤ PSNR < 30dB), significant difference (20dB ≤ PSNR < 25dB), and severe difference (PSNR < 20dB). These thresholds are determined based on statistical analysis of a large amount of art asset test data, and specific threshold adjustments may be made for different types of art assets (such as character models, scene models, UI elements, etc.). Quantitative grading of differences helps the testing team quickly identify and prioritize serious compatibility issues, improving testing efficiency and resource utilization. Simultaneously, historical test data can be recorded, and trend analysis can help determine the severity and urgency of problems. This provides the development team with a more comprehensive and accurate basis for problem assessment.

[0083] Optionally, during the acquisition of reference images, the system not only acquires reference images from a single benchmark device but also establishes a reference image library containing rendering results from multiple high-end devices. These reference images are categorized according to device platform type (e.g., iOS, Android, PC), allowing for comparison of the optimal reference image for each platform during testing. The reference image library is continuously updated and improved as testing progresses; when a better rendering effect is found on a particular platform, it can be added or replaced as a new reference standard. Furthermore, the reference image library also saves historical versions of reference images to track the changing trends of art assets across different version iterations. For newly added art assets, the system automatically marks their initial test results as temporary references and incorporates them into the official reference image library after confirmation by the art team. This allows for the construction of a dynamically evolving and continuously improving reference standard system, enhancing the adaptability and accuracy of testing.

[0084] Optionally, to further improve the accuracy of PSNR calculation, a region-weighted PSNR calculation method can be implemented. This method assigns different weight coefficients to different regions of the screenshot based on the importance of different parts of the art asset. For example, for character models, the facial region is usually more important than the limbs, so the system assigns higher weight to pixel differences in the facial region. This weighted calculation method requires the art team to predefine an importance map for each type of art asset, marking high-attention areas, secondary areas, and background areas. In the actual calculation process, the system applies different weight coefficients to the MSE values ​​of different regions based on this region division information, ultimately calculating a weighted PSNR value that better reflects human visual perception. In addition, the system also records the PSNR value of high-attention areas separately as a key indicator for judging the compatibility of art assets. In this way, the test results can more closely reflect the actual user experience, improving the effectiveness of the test.

[0085] Optionally, when determining the degree of difference between art resource screenshots and reference images, the system considers not only PSNR values ​​but also multiple image comparison algorithms such as Structural Similarity Index (SSIM) and color histogram differences to comprehensively evaluate the differences in rendering effects. The SSIM algorithm, compared to PSNR, better aligns with the perceptual characteristics of the human visual system, evaluating image similarity from three dimensions: brightness, contrast, and structure. The system dynamically adjusts the weighting of each algorithm in the final difference score based on the characteristics of different types of art resources. For example, for scene resources with complex textures, structural information is more important, and the weight of SSIM will be increased accordingly; while for UI elements with rich colors, the weight of color histogram comparison will increase. Furthermore, the system records and analyzes whether the evaluation results of different algorithms are consistent. When significant deviations occur (such as a high PSNR value but a low SSIM value), this situation will be marked as a special case requiring manual review. In this way, through a multi-dimensional difference evaluation method, compatibility issues of various art resources on different platforms can be identified more comprehensively and accurately.

[0086] Optionally, the PSNR calculation results of screenshots from different key perspectives can be weighted and summed based on the game type, game scene, or attributes of the art assets to serve as the overall test result for a specific art asset. For example, in third-person perspective games, the back of the character is often the perspective from which players observe for the longest time, so the calculation results of the back view can be given higher weight. In certain game types (such as strategy games and top-down perspective games), it is more important to evaluate the texture quality, geometry, and rendering effects of the top of the model, and the corresponding calculation results of the top view can be given higher weight.

[0087] Corresponding to the above method embodiments, this invention provides a testing device for art resources, see [link to relevant documentation]. Figure 3 The device includes a test case generation module for acquiring test cases that include art assets to be tested, which include digital graphic assets used to present 3D models; a test case distribution module for automatically allocating test cases to multiple test devices so that the test devices can execute the test cases; a test result collection module for acquiring the execution results returned by the test devices, which include screenshots of multiple key perspectives of the art assets acquired during the execution of the test cases; an image analysis module for calculating the difference between the screenshots and reference images; and a test result generation module for generating test results based on the difference.

[0088] In an optional implementation, the test case generation module includes a resource collection unit for collecting art resources to be tested; a test case generation unit for generating test cases including the art resources to be tested according to a preset test case template; and a submission unit for submitting the test cases after local process verification to the version control system.

[0089] In optional implementations, key perspectives include the front view, left side view, right side view, back view, top view, and bottom view of the art assets.

[0090] In an optional implementation, the test result collection module includes a scene response unit for responding to the test case running to the virtual scene of the art resource display; and a screenshot acquisition unit for acquiring screenshots of multiple key perspectives of the art resource captured by the virtual camera in the virtual scene being adjusted to different key perspective directions of the art resource.

[0091] In an optional implementation, the execution results also include screenshots of the art assets at different resolutions from multiple key perspectives, with the different resolutions corresponding to different display resolutions of the test device.

[0092] In an optional implementation, the system also includes a folder creation module for creating a corresponding folder for each test device; and a screenshot saving module for saving screenshots of multiple key perspectives of each art asset in the corresponding test device's folder according to a unified naming convention.

[0093] In an optional implementation, the image analysis module includes a reference image acquisition unit for acquiring a reference image, which is a screenshot of a key viewpoint of an art resource obtained by a benchmark testing device executing test cases; a peak signal-to-noise ratio (PSNR) calculation unit for calculating the PSNR between the screenshot returned by the testing device and the screenshot of the reference image from the same viewpoint of the same art resource; and a difference determination unit for determining the degree of difference between the screenshots of different art resources and the reference image based on the calculated PSNR.

[0094] The aforementioned art resource testing device significantly reduces human resource consumption by automatically collecting the rendering effects of art resources on multiple terminal devices and from different key perspectives. It also replaces the traditional subjective evaluation method that relies on human eye recognition by using an objective difference measurement algorithm for comparative analysis. This achieves standardization and repeatability of the testing process, while improving test coverage and accuracy.

[0095] The art resource testing device provided in this disclosure has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the device embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0096] It should be noted that although several units / modules or sub-units / modules of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of the present invention, the features and functions of two or more units / modules described above can be embodied in one unit / module. Conversely, the features and functions of one unit / module described above can be further divided and embodied by multiple units / modules.

[0097] This invention also provides an electronic device, such as... Figure 4 The electronic device includes a processor and a memory. The memory stores computer-executable instructions that can be executed by the processor. The processor executes the computer-executable instructions to implement the testing method for any art resource according to the embodiments of this disclosure. For specific implementation methods and the resulting technical effects, please refer to the method embodiments, which will not be repeated here.

[0098] Figure 4 This is a schematic diagram of the structure of an electronic device. The electronic device 1100 includes a processor 1101 with one or more processing cores, a memory 1102 with one or more computer-readable storage media, and a computer program stored in the memory 1102 and executable on the processor. The processor 1101 and the memory 1102 are electrically connected. Those skilled in the art will understand that the electronic device structure shown in the figure does not constitute a limitation on the electronic device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0099] The processor 1101 is the control center of the electronic device 1100. It connects various parts of the electronic device 1100 through various interfaces and lines. By running or loading software programs and / or modules stored in the memory 1102, and calling data stored in the memory 1102, it executes various functions of the electronic device 1100 and processes data, thereby performing overall monitoring of the electronic device 1100.

[0100] Optionally, the electronic device 1100 further includes: a touch display screen 1103, a radio frequency circuit 1104, an audio circuit 1105, an input unit 1106, and a power supply 1107. The processor 1101 is electrically connected to the touch display screen 1103, the radio frequency circuit 1104, the audio circuit 1105, the input unit 1106, and the power supply 1107. Those skilled in the art will understand that... Figure 4 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0101] This invention also provides a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute, when run by a processor, a test method for any art resource of this disclosure. For specific implementation methods and the resulting technical effects, please refer to the method embodiments, which will not be repeated here.

[0102] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal device, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0103] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0104] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present invention, which are used to illustrate the technical solutions of the present invention, rather than to limit them. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the above-described embodiments, those skilled in the art should understand that any person skilled in the art can modify or easily conceive of changes to the technical solutions described in the above-described embodiments within the technical scope disclosed by the present invention, or replace some of the technical features therein with equivalents. Such modifications, changes, or replacements do not deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be subject to the scope of protection of the claims.

Claims

1. A method for testing art resources, characterized in that, include: Obtain test cases that include art assets to be tested, said art assets including digital graphic assets used to render 3D models; The test cases are automatically assigned to multiple test devices so that the test devices execute the test cases. Obtain the execution results returned by the test device, the execution results including screenshots of multiple key perspectives of the art resources obtained during the execution of the test cases; Calculate the degree of difference between the screenshot and the reference image; Test results are generated based on the degree of difference.

2. The test method as described in claim 1, characterized in that, The test cases that acquire the art resources to be tested include: Collect the art assets to be tested; Test cases are generated based on a preset test case template, which includes the art resources to be tested. Submit the test cases, after local process verification, to the version control system.

3. The test method as described in claim 1, characterized in that, The key perspectives include: front view, left side view, right side view, back view, top view, and bottom view of the art resources.

4. The test method as described in claim 1, characterized in that, Screenshots of multiple key perspectives of the art assets were obtained through the following methods: In response to the test case running to the virtual scene displaying the art resources; Capture screenshots of multiple key perspectives of the art resource by adjusting the virtual camera in the virtual scene to different key perspective directions of the art resource.

5. The test method as described in claim 1, characterized in that, The execution results also include screenshots of the art resources at different resolutions from multiple key perspectives; the different resolutions correspond to the different display resolutions of the test device.

6. The test method as described in claim 1, characterized in that, Also includes: Create a corresponding folder for each test device; as well as Following a unified naming convention, screenshots of multiple key perspectives for each art asset were saved in the corresponding folder on the test device.

7. The test method as described in claim 1, characterized in that, The calculation of the difference between the screenshot and the reference image includes: Obtain a reference image, which is a screenshot of the key perspective of the art resource obtained by the benchmark testing device executing the test case; Calculate the peak signal-to-noise ratio (PSNR) between the screenshot returned by the test device and the screenshot of the reference image from the same viewpoint of the same art resource; and The degree of difference between screenshots of different art resources and reference images is determined based on the calculated peak signal-to-noise ratio.

8. A testing device for art resources, characterized in that, include: The test case generation module is used to obtain test cases including art assets to be tested, wherein the art assets include digital graphic assets used to render 3D models. The test case distribution module is used to automatically distribute the test cases to multiple test devices so that the test devices can execute the test cases; The test result collection module is used to obtain the execution results returned by the test device. The execution results include screenshots of multiple key perspectives of the art resources obtained during the execution of the test cases. The image analysis module is used to calculate the difference between the screenshot and the reference image; The test result generation module is used to generate test results based on the degree of difference.

9. An electronic device, characterized in that, include: Memory stores computer-executable instructions that can be executed by a processor; A processor for executing the computer-executable instructions to implement the method as claimed in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The device contains a computer program that, when executed by a processor, implements the method as described in any one of claims 1-7.

Images