Test method, device, apparatus, computer-readable storage medium, and computer program product

Abstract

This application provides a testing method, apparatus, device, computer-readable storage medium, and computer program product. The method includes: acquiring a feature map, which includes parameters and parameter values ​​of multiple interactive elements; for each parameter of each interactive element, generating a first test case for the interactive element based on the parameter value, the first test case being used to verify the interaction result of the interactive element under extreme scenarios where the parameter value and the parameter boundary value satisfy approximate conditions; for each interactive element, acquiring a test case template corresponding to the interactive element, and generating a second test case for the interactive element based on the test case template and the parameter value of at least one parameter of the interactive element; during game operation, testing each interactive element using the first and second test cases to obtain a first test result. This application improves the comprehensiveness, accuracy, and efficiency of testing.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to a testing method, apparatus, device, computer-readable storage medium, and computer program product. Background Technology

[0002] Testing game mechanisms refers to the systematic verification and evaluation of the functions, performance, compatibility, and user experience of mechanisms during the game development process, in order to ensure that they are reasonably designed, operate normally, and improve the player experience.

[0003] Testing game mechanics is a crucial step in ensuring game quality, improving user experience, maintaining game balance, and reducing development costs. Systematic testing allows for the identification and resolution of issues in mechanic design and implementation, optimizing their performance and behavior, and ultimately providing players with a smoother, more engaging, and immersive gaming experience.

[0004] However, in related technologies, automated level testing focuses on the process logic of the level and cannot achieve accurate and comprehensive testing of the mechanisms (gameplay) in the level; while manual mechanism testing has problems such as small test coverage, low test accuracy and low test efficiency. Summary of the Invention

[0005] This application provides a testing method, apparatus, device, computer-readable storage medium, and computer program product that can improve the comprehensiveness, accuracy, and efficiency of testing.

[0006] The technical solution of this application embodiment is implemented as follows:

[0007] This application provides a testing method, the method comprising:

[0008] Obtain a feature map, which includes parameters and parameter values ​​of multiple interactive elements;

[0009] For each parameter of each interactive element, a first test case is generated based on the parameter value of the parameter. The first test case is used to verify the interaction result of the interactive element in an extreme scenario where the parameter value and the boundary value of the parameter satisfy an approximate condition.

[0010] For each interactive element, obtain the test case template corresponding to the interactive element, and generate a second test case for the interactive element based on the test case template and the parameter value of at least one parameter of the interactive element.

[0011] During game operation, each interactive element is tested using the first test case and the second test case for each interactive element, and a first test result is obtained.

[0012] This application provides a testing apparatus, the apparatus comprising:

[0013] The first acquisition module is used to acquire a feature map, which includes parameters and parameter values ​​of multiple interactive elements;

[0014] The first generation module is used to generate a first test case for each of the parameters of each interactive element based on the parameter value of the parameter. The first test case is used to verify the interaction result of the interactive element in an extreme scenario where the parameter value and the boundary value of the parameter satisfy an approximate condition.

[0015] The second generation module is used to obtain a test case template corresponding to each interactive element, and generate a second test case for the interactive element based on the test case template and the parameter value of at least one parameter of the interactive element.

[0016] The testing module is used to test each interactive element during game operation using the first test case and the second test case for each interactive element, and obtain a first test result.

[0017] This application provides a computer device, including:

[0018] Memory is used to store executable instructions for a computer;

[0019] The processor, when executing computer-executable instructions stored in the memory, implements the testing method provided in the embodiments of this application.

[0020] This application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the testing method provided in this application.

[0021] This application provides a computer program product, including a computer program or computer executable instructions, which, when executed by a processor, implements the testing method provided in this application.

[0022] The embodiments of this application have the following beneficial effects:

[0023] In this embodiment of the application, for each parameter of each interactive element, a first test case for the interactive element is generated based on the parameter value of the parameter, and the first test case is used to verify the interaction result of the interactive element in extreme scenarios, that is, the first test case in extreme scenarios is automatically generated. Furthermore, test case templates corresponding to interactive elements are obtained, and second test cases are generated based on the test case templates and the parameter values ​​of at least one parameter of the interactive element. Since the second test cases are generated in real time based on the parameter values ​​and the test case templates, they possess real-time characteristics. Moreover, due to the diversity and realism of the parameter values, the second test cases possess high coverage and high accuracy. In other words, this application can automatically generate second test cases that are real-time, highly comprehensive, and highly accurate. Finally, each interactive element is tested using the first and second test cases for each interactive element, obtaining the first test result for each interactive element. Since the testing utilizes both the first test cases under extreme scenarios and the second test cases that are real-time, highly comprehensive, and highly accurate, and since both the first and second test cases are automatically generated, the comprehensiveness and sufficiency of the test can be improved through the first test cases under extreme scenarios, and the real-time performance, coverage, and accuracy of the test can be improved through the second test cases. This achieves automated testing of interactive elements and also improves the comprehensiveness, sufficiency, accuracy, and efficiency of the test. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of a network architecture of the test system 100 provided in an embodiment of this application;

[0025] Figure 2 This is a schematic diagram of the structure of the server 400 provided in the embodiment of this application;

[0026] Figure 3 This is a first flowchart illustrating the testing method provided in the embodiments of this application;

[0027] Figure 4 This is a flowchart illustrating one method for determining a first test case, as provided in an embodiment of this application.

[0028] Figure 5 This is a flowchart illustrating one method for determining a second test case, as provided in an embodiment of this application.

[0029] Figure 6 This is a schematic diagram of the second process of the testing method provided in the embodiments of this application;

[0030] Figure 7 This is a schematic diagram of an implementation framework for generating a second test case provided in an embodiment of this application;

[0031] Figure 8 This is a schematic diagram of an implementation framework for generating extreme scenarios provided in an embodiment of this application;

[0032] Figure 9 This is a schematic diagram of an implementation framework for the testing method provided in this application.

[0033] It should be noted that the terms "first" and "second" are used only to distinguish different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0035] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0036] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0037] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0038] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0039] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0040] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0041] 1) In the gaming field, a level refers to an independent unit or stage in a game, which usually has specific objectives, rules, and challenges. Each level can be regarded as a "scene" or "task" in the game, and players need to complete specific objectives to advance to the next level.

[0042] A level is a separate section of the game, typically with a clear start and end point. Each level has its own unique tasks or objectives that players must complete to advance to the next level. Levels include specific rules and challenges, such as enemies, traps, and puzzles, increasing the game's difficulty and enjoyment.

[0043] The elements of a level include objectives, environment, challenges, and progress. Level designs include linear levels, open-world levels, and multi-path levels.

[0044] By designing diverse levels, the game offers players a rich and varied gaming experience. Challenges and tasks within the levels increase the game's difficulty and fun, allowing players to enjoy the gameplay. Levels are a crucial means of advancing the game's story; players gradually unlock story content by completing levels. Tasks and challenges within levels help characters grow and develop, enhancing player immersion. The game's replay value is increased through multi-path levels and multiple endings. Hidden content and Easter eggs are included in the levels, encouraging players to explore and discover them.

[0045] Levels are a core element of game design, offering players a rich and diverse gaming experience through well-designed levels. Levels are not merely independent units within the game; they are crucial means of advancing the story, increasing challenge, and enhancing gameplay enjoyment. Through diverse level designs, game developers can provide players with immersive, fun, and challenging gaming experiences.

[0046] 2) Gameplay: The various systems and elements in a game used to enhance the player experience, drive the game's progress, or provide challenges. These gameplay elements can be physical, logical, or interactive, and are usually closely integrated with the game's core mechanics, quests, environment, and storyline. Examples include, but are not limited to, doors that open when you approach them, lights that turn on when attacked, and mushrooms that periodically release poison gas.

[0047] Gameplay defines how players interact with mechanisms, including how to trigger mechanisms, how to respond to their reactions, and how to use them to achieve game objectives. Gameplay clarifies the behavioral rules and triggering conditions of mechanisms, such as under what circumstances a mechanism activates and how it affects the game environment or the player character. Gameplay requires players to use strategy and skill to deal with mechanisms, such as puzzle-solving, dodging, and timing.

[0048] Gameplay can refer to how players interact with mechanisms, such as pressing buttons, pulling levers, cracking codes, or avoiding traps. For example, in a puzzle game, players need to rotate gears to activate mechanisms and open doors to the next area. Gameplay can also refer to the conditions under which a mechanism is activated, such as time, location, items, or player actions. For example, a trap mechanism might only trigger when the player steps on a specific floor tile, or a hidden mechanism might require the player to find and insert a specific key. Gameplay can also refer to the effects of triggering a mechanism, such as opening doors, activating traps, releasing rewards, or changing the environment. For example, triggering a mechanism might release a rolling stone trap that the player needs to quickly dodge.

[0049] 3) Feature map: Each gameplay mode is placed on a separate map. Different types of gameplay modes can be placed in different plots of the map. Such a map that combines various gameplay modes in the game is called a feature map.

[0050] Feature maps distribute different types of gameplay (such as traps, combat, exploration, puzzles, etc.) as independent units across different plots of a map, forming a comprehensive map that combines multiple gameplay elements.

[0051] Each gameplay mode is designed as an independent unit, placed within a specific tile on the map. For example, the top left corner of the map might be a puzzle-solving area, while the bottom right corner is a combat area. The gameplay within each tile can operate independently, allowing players to selectively experience different modes. The feature map integrates various gameplay types, such as traps, combat, exploration, puzzles, and collection. Each gameplay mode has its unique design and rules within the map, providing players with a diverse gaming experience. The map is divided into multiple tiles, each corresponding to one type or category of gameplay. Tiles are separated by natural terrain (such as rivers and mountains) or man-made structures (such as doors and bridges). Players can freely choose to enter different tiles to experience different gameplay modes. Players can discover hidden gameplay modes or rewards through exploration.

[0052] Feature maps are a design method that distributes various gameplay elements as independent units across different plots of a map. Through diverse gameplay, clear plot divisions, and a free exploration mechanism, it provides players with a rich, flexible, and exploratory gaming experience, while also offering modular and scalable design concepts for game development.

[0053] 4) Blocks refer to the regions divided in the feature map, each with relatively independent attributes and uses. Blocks are used to carry different types of interactive elements.

[0054] From a functional perspective, blocks are divided based on the function and type of interactive elements. For example, in a large role-playing game's feature map, there might be combat blocks specifically designed with various monsters, dungeons, and other combat-related interactive elements, where players can fight monsters, level up, and challenge virtual objects. There might also be construction blocks where players can build their own homes, manage shops, and develop industries to gain in-game profits and accumulate resources. Each block is designed and laid out around one or more specific interactive elements, providing players with a diverse gaming experience.

[0055] From a design management perspective, for game developers, a block is a convenient unit for designing and managing game content. Developers can independently plan, design, and develop each block, adjusting parameters such as difficulty, resource distribution, and rule settings. This not only improves development efficiency but also allows for the optimization and updating of interactive elements in specific blocks based on player feedback and game operation, without affecting the normal operation of other blocks.

[0056] To better understand the testing methods provided in the embodiments of this application, the relevant technologies and their shortcomings are first explained.

[0057] In open-world role-playing games, levels are often used to enrich the game content. Different levels may contain the same gameplay elements. To test all possible scenarios of the gameplay, all levels need to be traversed. This not only makes automated testing too time-consuming, but also makes it easy for automated testing to be interrupted by the failure of preceding test cases due to the complex interaction logic within the levels, making it difficult to expose gameplay-related issues.

[0058] The testing strategy for open-world role-playing games typically involves using automated methods to test the level flow logic, and using manual testing to verify the basic gameplay functions in feature maps.

[0059] When automating the testing of level flow logic, the blueprint controlling the level logic is first parsed. For key blueprint nodes within the blueprint, corresponding atomic operations are encapsulated. Then, after launching the game, the character executes the corresponding logic in the game based on the atomic operations, and finally, the result data is obtained. These key blueprint nodes are generally behavior nodes and detection nodes. Behavior nodes, triggered by event detection results, can trigger a level's logical behavior, such as spawning monsters or the user interface notifying the player of task completion. Detection nodes are used to detect whether a certain goal has been achieved, such as the player achieving a monster kill or a non-player-controlled character reaching a designated location. Unlike behavior nodes, goal nodes save and record their completion.

[0060] In related technologies, in order to verify the basic functions of the gameplay, manual testing is generally used to test all gameplay elements one by one.

[0061] However, running an automated test using relevant technologies involves all levels, resulting in redundant test content for levels with repeated placements, and a single test execution time is lengthy. Furthermore, levels contain a large amount of process logic, and failures in preceding operations often render subsequent test content unexecutable. If every gameplay element is checked in great detail, the success rate of complete verification across the entire level would be very low. Therefore, to ensure a high success rate for level process verification, relevant technologies perform a relatively rough check of the gameplay itself, focusing primarily on triggering critical processes. Each modification to gameplay functionality requires manual verification on the feature map.

[0062] Based on the above-mentioned technologies, it can be seen that the disadvantages of these technologies include at least the following: first, they cannot achieve automated testing of levels; second, the testing coverage and efficiency are low.

[0063] This application provides a testing method, apparatus, computer device, computer-readable storage medium, and computer program product, which can improve the comprehensiveness, accuracy, and efficiency of testing. The exemplary application of the computer device provided in this application is described below. The computer device provided in this application can be implemented as various types of terminals such as laptops, tablets, desktop computers, set-top boxes, smartphones, smart speakers, smartwatches, smart TVs, in-vehicle terminals, and game terminals, or it can be implemented as a server. The exemplary application of the computer device as a server will be described below.

[0064] See Figure 1 , Figure 1This is a schematic diagram of the network architecture of the test system 100 provided in this application embodiment. In order to support a test application, the server 400 is connected to the terminal 200 through the network 300. The network 300 can be a wide area network or a local area network, or a combination of the two.

[0065] Terminal 200 is used to send the parameters and parameter values ​​of interactive elements to server 400. Server 400 receives the parameters and parameter values ​​of interactive elements and performs test processing on each interactive element using the test method provided in this application embodiment to obtain a first test result, and sends the first test result to terminal 200.

[0066] In systems that automate testing based on test cases, testing methods are not only used for testing interactive elements in games, but can also be widely applied to the following scenarios:

[0067] Scenario 1: Application function testing of terminal devices.

[0068] Terminal devices automatically generate test cases to verify whether their application functions as expected, such as user interface operation, data processing, and interaction logic. Terminal devices can automatically generate test cases based on object behavior models to simulate different user operating habits and cover various functional scenarios. For example, in smart home devices, terminal devices automatically generate test cases to verify whether they can correctly respond to voice commands and perform corresponding operations.

[0069] Scenario 2: Testing the server's Application Programming Interface (API).

[0070] The server automatically generates test cases to verify the correctness, performance, and security of its API, including request and response, data format, and error handling. The server can automatically generate test cases based on the API documentation, covering various input parameters and boundary conditions to ensure the robustness of the interface. For example, in an e-commerce platform, the server automatically generates test cases to verify that its order interface can correctly handle different payment methods and delivery addresses.

[0071] Scenario 3: Compatibility testing of terminal devices.

[0072] Terminal devices automatically generate test cases to verify their compatibility and adaptability across different operating systems, browsers, or hardware environments. The terminal device can automatically generate test cases based on the device model and system version to ensure the application runs normally in various environments. For example, in mobile applications, the terminal device automatically generates test cases to test its performance on different phone models or operating systems.

[0073] Scenario 4: Server performance testing.

[0074] Servers automatically generate test cases to simulate high-concurrency requests or large-scale data processing, testing their performance, including response time, throughput, and resource utilization. Servers can automatically generate test cases based on load models to simulate different numbers of users and request frequencies, evaluating the system's performance limits. For example, in a cloud computing platform, servers automatically generate test cases to test their performance when processing large-scale data.

[0075] Scenario 5: Security testing of terminal devices.

[0076] Terminal devices can automatically generate test cases to simulate malicious operations or data breaches, testing the effectiveness of their security mechanisms. Terminal devices can automatically generate test cases based on security vulnerability models to verify their ability to prevent malware or unauthorized access. For example, in mobile payment applications, terminal devices automatically generate test cases to test their effectiveness in preventing payment information theft.

[0077] Scenario 6: Server reliability testing.

[0078] The server automatically generates test cases to simulate extreme conditions (such as network outages and hardware failures) to test its reliability and fault tolerance. The server can automatically generate test cases based on fault models to verify whether it can maintain service continuity under abnormal circumstances. For example, in a financial system, the server automatically generates test cases to test its ability to automatically switch to a backup node in the event of a hardware failure.

[0079] Scenario 7: User experience testing of terminal devices.

[0080] Terminal devices automatically generate test cases to simulate user operation processes and test whether their user experience meets expectations, including response speed, interface layout, and interaction smoothness. Terminal devices can automatically generate test cases based on object behavior data, covering different user operation paths and preferences. For example, in a video playback application, the terminal device automatically generates test cases to test its smoothness and interface response speed when playing high-definition video.

[0081] Scenario 8: Integration testing of server and terminal.

[0082] Servers and terminal devices automatically generate test cases to simulate a complete user operation process, testing the correctness and stability of their collaborative operation. These test cases can be automatically generated based on user scenarios, covering various interactive elements and data transmission processes. For example, in an online education platform, servers and terminal devices automatically generate test cases to test their ability to achieve real-time audio and video transmission and interactive functions.

[0083] Scenario 9: Stress test of terminal equipment.

[0084] Terminal devices can automatically generate test cases to simulate high loads or complex operations, testing their performance, including response speed, memory usage, and battery consumption. Terminal devices can automatically generate test cases based on load models to simulate long-term operation or high-frequency operation, evaluating their performance limits. For example, in mobile games, terminal devices automatically generate test cases to test their performance when running high-quality games for extended periods.

[0085] Scenario 10: Server security testing.

[0086] The server automatically generates test cases to simulate various attack scenarios (such as SQL injection and DDoS attacks) to test the effectiveness of its security protection mechanisms. The server can automatically generate test cases based on attack models to verify its ability to effectively prevent data leaks or system crashes. For example, in social media platforms, the server automatically generates test cases to test its ability to withstand large-scale attacks from malicious users.

[0087] Terminal devices and servers, through automated test case generation and automated testing technologies, can be widely applied to scenarios such as functional testing, compatibility testing, performance testing, security testing, reliability testing, user experience testing, integration testing, and stress testing. These technologies not only improve testing efficiency but also ensure system stability, security, and user experience, making them suitable for numerous fields such as smart homes, e-commerce, finance, cloud computing, mobile payments, and online education.

[0088] In this embodiment of the application, the server 400 generates a first test case for each parameter of each interactive element based on the parameter value of the parameter, and the first test case is used to verify the interaction result of the interactive element under extreme scenarios, that is, automatically generating the first test case under extreme scenarios. Furthermore, test case templates corresponding to interactive elements are obtained, and second test cases are generated based on the test case templates and the parameter values ​​of at least one parameter of the interactive element. Since the second test cases are generated in real time based on the parameter values ​​and the test case templates, they possess real-time characteristics. Moreover, due to the diversity and realism of the parameter values, the second test cases possess high coverage and high accuracy. In other words, this application can automatically generate second test cases that are real-time, highly comprehensive, and highly accurate. Finally, each interactive element is tested using the first and second test cases for each interactive element, obtaining the first test result for each interactive element. Since the testing utilizes both the first test cases under extreme scenarios and the second test cases that are real-time, highly comprehensive, and highly accurate, and since both the first and second test cases are automatically generated, the comprehensiveness and sufficiency of the test can be improved through the first test cases under extreme scenarios, and the real-time performance, coverage, and accuracy of the test can be improved through the second test cases. This achieves automated testing of interactive elements and also improves the comprehensiveness, sufficiency, accuracy, and efficiency of the test.

[0089] In some embodiments, server 400 may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. Terminals and servers can be connected directly or indirectly via wired or wireless communication, which is not limited in this embodiment.

[0090] See Figure 2 , Figure 2 This is a schematic diagram of the structure of the server 400 provided in the embodiment of this application. Figure 2 The server 400 shown includes at least one processor 410, memory 450, at least one network interface 420, and a user interface 430. The various components in server 400 are coupled together via a bus system 440. It is understood that the bus system 440 is used to implement communication between these components. In addition to a data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2The general labeled all buses as Bus System 440.

[0091] The processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0092] User interface 430 includes one or more output devices 431 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0093] The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 450 may optionally include one or more storage devices physically located away from the processor 410.

[0094] The memory 450 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 450 described in this application embodiment is intended to include any suitable type of memory.

[0095] In some embodiments, memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0096] Operating system 451 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks;

[0097] The network communication module 452 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc.

[0098] Presentation module 453 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 431 (e.g., a display screen, a speaker, etc.) associated with user interface 430;

[0099] The input processing module 454 is used to detect and translate one or more user inputs or interactions from one or more input devices 432.

[0100] In some embodiments, the apparatus provided in this application can be implemented in software. Figure 2 A test apparatus 455 stored in memory 450 is shown. This apparatus can be software in the form of programs and plug-ins, and includes the following software modules: a first acquisition module 4551, a first generation module 4552, a second generation module 4553, and a test module 4554. These modules are logically linked and can therefore be arbitrarily combined or further divided according to their implemented functions. The functions of each module will be described below.

[0101] In other embodiments, the apparatus provided in this application can be implemented in hardware. As an example, the apparatus provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the test method provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0102] In some embodiments, the server can implement the testing method provided in this application by running various computer-executable instructions or computer programs. For example, computer-executable instructions can be microprogram-level commands, machine instructions, or software instructions. Computer programs can be native programs or software modules in an operating system; they can be native applications (APPs), i.e., programs that need to be installed in the operating system to run, such as test APPs or functional verification APPs; or they can be applets that can be embedded in any APP, i.e., programs that only need to be downloaded to a browser environment to run. In summary, the aforementioned computer-executable instructions can be any form of instruction, and the aforementioned computer programs can be any form of application, module, or plugin.

[0103] The testing methods provided in this application will be described in conjunction with exemplary applications and implementations of the server provided in the embodiments of this application.

[0104] The following describes the testing method provided in the embodiments of this application. As mentioned above, the computer device implementing the testing method of the embodiments of this application can be a terminal, a server, or a combination of both. Therefore, the executing entity of each step will not be described again below.

[0105] It should be noted that the test method examples below use interactive elements as examples. Those skilled in the art, based on their understanding of the following text, can apply the test methods provided in this application to the testing of other types of interactive elements, such as characters and non-player characters, items and props, combat systems, quests and storylines, user interfaces, multiplayer games and social functions, environmental and physical effects, sound effects and music. This application can also be applied to various scenarios, including but not limited to games, smart home devices, e-commerce platforms, cloud computing platforms, financial systems, online education, and social platforms.

[0106] See Figure 3 , Figure 3 This is a first flowchart illustrating the testing method provided in the embodiments of this application, which will be combined with... Figure 3 The steps shown illustrate the test method provided in the embodiments of this application. Figure 3 The execution entity is the server.

[0107] In step S101, a feature map is obtained.

[0108] In this embodiment of the application, the feature map includes parameters and parameter values ​​of multiple interactive elements.

[0109] In some embodiments, interactive elements refer to various objects, mechanisms, or systems that players can interact with directly or indirectly during gameplay, and that influence the game's progress, outcome, or experience. These elements are core components of game design, aimed at enhancing player engagement and immersion.

[0110] In some embodiments, interactive elements can be categorized into operable objects, environmental interactions, user interface elements, and non-player character interactions, based on their function and presentation. Operable objects refer to in-game objects or characters that players can directly interact with. Examples include pickable items (such as virtual resources or potions), controllable characters or vehicles, openable doors, chests, or mechanisms. Environmental interactions refer to the player's interaction with the game world environment, typically achieved through exploration or triggering specific events. Examples include destructible walls or obstacles, triggerable traps or hidden areas, dynamic weather, or day / night cycles. User interface elements refer to interface components that allow players to interact with the game system. Examples include menu buttons (such as start, pause, or settings), skill or item bars, maps, or quest locators. Non-player character interactions refer to interactions such as dialogue, trading, or combat between players and non-player characters in the game. Examples include interacting with non-player characters to obtain quests or information, trading items with merchants, or fighting against opponents.

[0111] In some embodiments, interactive elements can be mechanisms. On the one hand, mechanisms can be closely integrated with the game environment and are an important part of environmental interaction. For example, pressing a button opens a hidden door; pulling a lever raises or lowers a bridge; stepping on a pressure plate activates a trap. On the other hand, mechanisms can be considered as operable objects that players need to interact with directly. For example, rotating gears require players to adjust their position to unlock a passage; movable statues require players to push them to a designated position to trigger a mechanism.

[0112] In some embodiments, the parameters of an interactive element can refer to a series of variables or attributes used to define and control the behavior, state, and interaction logic of the mechanism. Parameters may include trigger condition parameters, effect parameters, state parameters, interaction feedback parameters, logic parameters, etc. For example, trigger condition parameters may include pressing a button, repeated activation, or the mechanism taking effect only after a first preset time is met; effect parameters may include opening a door, a trap lasting for a second preset time, etc.

[0113] The parameter values ​​of interactive elements can refer to the numerical values ​​or settings of mechanism parameters. Parameter values ​​are used to precisely control the behavior, state, and interaction logic of the mechanism. Parameter values ​​can be numerical or character. For example, the parameter value for a one-time trigger can be 1; the parameter value for multiple triggers can be 3, indicating that the maximum number of triggers is 3; the aforementioned first preset time is 4, indicating that it takes effect after a 4-second delay after activation; the parameter value for interactivity can be true, indicating that the mechanism is currently interactive.

[0114] In this embodiment of the application, the feature map includes element identifiers of multiple interactive elements, parameters of the interactive elements, and parameter values.

[0115] In some embodiments, the feature map may be created before performing step S101. The creation of the feature map may include: obtaining an initial map, a third relational mapping table, and type information of each interactive element. The initial map includes multiple blocks, and the third relational mapping table stores the mapping relationship between blocks and categories. Based on the third relational mapping table and the type information of each interactive element, the block corresponding to each interactive element is determined. For each interactive element, the element identifier, parameters, and parameter values ​​of the interactive element are determined as the block information of the block to obtain the feature map.

[0116] In some embodiments, the initial map may refer to a map after it has been divided into blocks. This initial map does not include the element identifiers, parameters, or parameter values ​​of the interactive elements. For example, the initial map may be a map including 25 blocks. The type information of the interactive element may refer to the classification and description of the interactive element through attributes such as function, triggering method, effect, interaction complexity, and visual performance. Taking the triggering method as an example, the type information may be triggered by a button, touched, or by an event.

[0117] Continuing the example above, assume that the type information of interactive element 1 is button-triggered, the type information of interactive element 2 is touch-triggered, and the type information of interactive element 3 is event-triggered. The third relational mapping table indicates that block 01 is mapped to button-triggered, block 02 is mapped to touch-triggered, and block 03 is mapped to event-triggered. Based on this, the block corresponding to interactive element 1 is determined to be block 01, the block corresponding to interactive element 2 is determined to be block 02, and the block corresponding to interactive element 3 is determined to be block 03. Finally, the element identifier, parameters, and parameter values ​​of interactive element 1 are determined as the block information of block 01, the element identifier, parameters, and parameter values ​​of interactive element 2 are determined as the block information of block 02, and the element identifier, parameters, and parameter values ​​of interactive element 3 are determined as the block information of block 03. Thus, the initial map is updated using the element identifiers, parameters, and parameter values ​​of the interactive elements to obtain the feature map.

[0118] By constructing a feature map using the above method, the game world is divided into multiple blocks, and detailed interactive element information is stored in each block. This makes the game world information more structured and easier to manage. The initial map divides the game world into multiple blocks, facilitating regional management. A third-party relational mapping table associates blocks with categories, providing context for block information. The feature map integrates detailed information on interactive elements, forming a complete data view of the game world. Through the feature map, information on specific blocks or interactive elements can be quickly queried and retrieved. Based on block information, interactive elements and their parameters within a block can be quickly located. Based on the type information of interactive elements, specific categories of interactive elements can be filtered out. This efficient query capability facilitates development, testing, and debugging. The feature map supports dynamic updates, reflecting changes in the game world in real time. When the parameters or parameter values ​​of interactive elements change, the block information of the corresponding block can be updated. When interactive elements are added or deleted, the structure of the feature map can be adjusted. This dynamic update capability ensures that the feature map always remains consistent with the game world. Therefore, it provides powerful data support for game development, testing, and optimization, improving development efficiency and game quality.

[0119] In some embodiments, interactive elements in the feature map can also be adjusted to obtain an adjusted feature map. Based on this, after creating the feature map as described above, the following can also be performed: in response to an adjustment instruction for an interactive element in the feature map, determining the element to be adjusted, the current block corresponding to the element to be adjusted, and the adjusted block; deleting the element identifier, parameters, and parameter values ​​of the element to be adjusted from the block information of the current block; adding the element identifier, parameters, and parameter values ​​of the element to be adjusted to the block information of the adjusted block to obtain the adjusted feature map.

[0120] In some embodiments, interactive elements in the feature map can be moved based on adjustment or editing instructions. Continuing with the example above, interactive element 1 can be adjusted or moved from block 01 to block 02 by pressing and moving. The element to be adjusted is interactive element 01, the current block is block 01, and the adjusted block is block 02. Based on this, the element identifier, parameters, and parameter values ​​of interactive element 1 are deleted from the block information of block 01; and the element identifier, parameters, and parameter values ​​of interactive element 1 are added to the block information of block 02, thus obtaining the adjusted feature map. In this adjusted map, interactive elements 1 and 2 both correspond to block 02, while interactive element 3 corresponds to block 03.

[0121] Through the above adjustments, dynamic adjustments to the game world are supported, ensuring that the feature map always remains consistent with the actual state of the game world. When the position or parameters of interactive elements change, the feature map can be updated in real time. This dynamic updating capability ensures that developers, testers, and designers always work based on the latest game world data. Updating block information efficiently manages the position and attributes of interactive elements, removing elements to be adjusted from the current block and adding them to the adjusted block, ensuring the accuracy of block information. This management method facilitates developers in quickly locating and adjusting interactive elements. Adjusting the position and block information of interactive elements supports flexible scene design and optimization. Interactive elements can be moved to different blocks as needed, optimizing the game experience and facilitating iterative development and content updates.

[0122] In step S102, for each parameter of each interactive element, a first test case is generated based on the parameter value of the parameter.

[0123] In this embodiment of the application, the first test case is used to verify the interaction result of the interactive element in an extreme scenario where the parameter value and the boundary value of the parameter satisfy the approximate condition.

[0124] In some embodiments, since different parameters can correspond to different scenarios, the corresponding scenario identifier can be determined first based on the parameters. For example, assume that interactive element 1 includes parameters P1 and P2, and parameter P1 corresponds to scenario identifier S1, and parameter P2 corresponds to scenario identifier S2. Then, a first test case is generated based on the scenario identifier and the parameter value. The first test case is used to verify the interaction of the interactive element under extreme scenarios, where extreme scenarios refer to the parameter value and the parameter boundary value satisfying the approximate condition.

[0125] In some embodiments, when the difference between the parameter value and the boundary value is less than the difference threshold, it is determined that the parameter value and the limit value of the parameter satisfy the approximation condition.

[0126] In some embodiments, see Figure 4 The process of "generating the first test case for the interactive element based on the parameter value" in step S102 above may include the following steps S1021 to S1023, which are described in detail below.

[0127] In step S1021, the first relational mapping table is obtained.

[0128] In this embodiment of the application, the first relational mapping table stores the mapping relationship between parameters and scene identifiers.

[0129] In some embodiments, the first relational mapping table can be a mapping table pre-constructed based on experience. For example, the first relational mapping table can store: the scene identifier corresponding to parameter P1 is S1, that is, there is a mapping relationship between parameter P1 and scene identifier S1; the scene identifier corresponding to parameter P2 is S2, that is, there is a mapping relationship between parameter P2 and scene identifier S2.

[0130] In step S1022, the target scene identifier corresponding to the parameter is determined through the first relational mapping table.

[0131] In some embodiments, following the example above, assuming the parameter is P1, S1 is determined as the target scene identifier.

[0132] In step S1023, a first test case is constructed based on the target scene identifier and the parameter values.

[0133] In some embodiments, firstly, effective and ineffective values ​​that satisfy the approximate conditions with the boundary values ​​of the parameters are determined; then, effective test cases can be generated based on the target scenario identifier and the effective values, and ineffective test cases can be generated based on the target scenario identifier and the ineffective values. Finally, the effective test cases and ineffective test cases are jointly determined as the first test case.

[0134] In some embodiments, when the parameter is used to characterize the effective range of the interactive element, the implementation process of step S1023 above may include: obtaining the boundary value of the parameter; determining the first effective range of the interactive element based on the boundary value; determining a first value that satisfies the approximate condition with the boundary value; constructing an effective test case based on the target scene identifier and the first value, wherein the difference between the first value and the boundary value is less than the difference threshold and is located within the first effective range; determining a second value that satisfies the approximate condition with the boundary value; constructing a failure test case based on the target scene identifier and the second value, wherein the difference between the second value and the boundary value is less than the difference threshold and is located outside the first effective range; and determining the effective test case and the failure test case as the first test case.

[0135] In some embodiments, the effective range refers to the spatial area or object range that the effect of an interactive element can influence after the interaction occurs. For example, when a button switch is triggered, it only opens doors within 1 meter.

[0136] Continuing with the example above, the boundary value is 1 meter, the first effective interval is [0, 1], and assuming the difference threshold is 0.1 meters, then parameter values ​​greater than 0.9 meters and less than 1.1 meters are determined as parameter values ​​that satisfy the approximation condition of the boundary value. Since 0.95 meters is greater than 0.9 meters and less than 1.1 meters, and 0.95 meters is within [0, 1], 0.95 meters can be determined as the first value that satisfies the approximation condition of the boundary value, which can also be called the effective value. Similarly, since 1.02 meters is greater than 0.9 meters and less than 1.1 meters, and 1.02 meters is outside [0, 1], 1.02 meters can be determined as the second value that satisfies the approximation condition of the boundary value, which can also be called the ineffective value. Based on this, effective test cases are constructed based on the target scene identifier S1 and 0.95, that is, a door is placed at a distance of 0.95 from the interactive element to generate a detection point; failure test cases are constructed based on the target scene identifier S1 and 1.02, that is, a door is placed at a distance of 1.02 from the interactive element to generate another detection point; finally, the effective test cases and failure test cases are jointly determined as the first test cases, so that the number of first test cases is at least two.

[0137] By using the method described above to determine the first test case, and by testing boundary values ​​and their approximations, the behavior of the interactive element within its effective range is ensured to meet expectations. Effective test cases verify the correctness of the interactive element within its effective range. Failure test cases verify the robustness of the interactive element outside its effective range. This comprehensive boundary condition coverage testing method improves the comprehensiveness of the test. By precisely selecting the first and second values, the accuracy of the test cases is ensured. The difference between the first value and the boundary value is less than a difference threshold, ensuring the test case is close to the boundary condition. The second value is outside the effective range, verifying the behavior of the interactive element outside the boundary. This precise selection of test values ​​improves the accuracy of the test. Failure test cases verify the robustness of the interactive element outside its effective range, ensuring that the interactive element does not produce erroneous behavior when outside its effective range. This robustness verification method improves the stability of the interactive element. Therefore, this provides strong support for the testing of interactive elements, improving the comprehensiveness, accuracy, and effectiveness of the test, and ensuring that the behavior of the interactive element within its effective range meets expectations.

[0138] In some embodiments, the implementation process of “constructing effective test cases based on target scenario identifier and first value” may include: obtaining a scenario template corresponding to the target scenario identifier, wherein the scenario template includes a first placeholder for indicating the parameter value to be filled in; replacing the first placeholder in the scenario template with the first value to obtain an interactive effective scenario; and determining the interactive effective scenario and the execution success result as effective test cases.

[0139] In some embodiments, a scene template library can be obtained first, which includes scene identifiers and corresponding scene templates. Based on this, the scene template corresponding to the target scene identifier can be determined from the scene template library. For example, the scene template corresponding to S1 can be "the door at a distance of {distance value} when the player presses the button switch". Next, the position of the first placeholder is determined from the scene template, and based on the position of the first placeholder, the first placeholder in the target scene is replaced with the first value to obtain the interactive effective scene, continuing the example above. The interactive effective scene can be "the door at a distance of 0.95 meters when the player presses the button switch". Finally, the execution success result is "will open". By concatenating the interactive effective scene and the execution success result, an effective test case is obtained. Therefore, "the door at a distance of 0.95 meters when the player presses the button switch will open" can be determined as an effective test case. This effective test case is equivalent to setting a door at a distance of 0.95 meters from the interactive element to form a test point.

[0140] The methods described above for determining effective test cases ensure standardization and normalization of the test case generation process by using scenario templates. Scenario templates provide a unified test case structure, avoiding inconsistencies in test case format. This standardized generation process improves the readability and maintainability of test cases. Automated placeholder replacement rapidly generates test cases, increasing generation efficiency. Placeholders in the scenario template are automatically replaced with their first values, reducing manual intervention and shortening test case writing time. Precise placeholder replacement ensures accuracy and consistency. Accurately replacing placeholders with their first values ​​ensures the test case description matches the actual scenario, enhancing test case effectiveness.

[0141] In some embodiments, the implementation process of “constructing failure test cases based on target scenario identifier and second value” may include: replacing the first placeholder in the scenario template with the second value to obtain an interactive failure scenario; and determining the interactive failure scenario and the execution failure result as failure test cases.

[0142] In some embodiments, following the example above, the interaction failure scenario can be "when the player presses the button switch, the door 1.02 meters away will not open," and the execution failure result is "it will not open." By combining the interaction failure scenario and the execution failure result, a failure test case is obtained. Therefore, "when the player presses the button switch, the door 1.02 meters away will not open" can be identified as a failure test case. This failure test case is equivalent to setting a door 1.02 meters away from the interactive element to form a test point.

[0143] The method described above for determining effective test cases, utilizing scenario templates, avoids the need to write test scenarios from scratch for each failure test case. Scenario templates act as a universal framework; simply replacing the first placeholder with a second value quickly generates new interactive failure scenarios. For example, in game testing, for a scenario template involving player interaction with items, different second values ​​(such as abnormal item attribute values) can quickly generate various interactive failure scenarios, significantly saving test case writing time. Directly identifying interactive failure scenarios and execution failure results as failure test cases simplifies the test case construction process. Testers no longer need to define execution results separately for each build, increasing the speed of failure test case construction and allowing testers to dedicate more time to actual test execution. Because different second values ​​can replace the first placeholder, diverse interactive failure scenarios can be generated. Taking an e-commerce system as an example, for a scenario template involving ordering goods, the second value can be an abnormal inventory value, an abnormal price value, etc., comprehensively covering various situations that may lead to interactive failures, ensuring that testing can uncover more potential problems.

[0144] Through steps S1021 to S1023, the system can quickly determine the target scene identifier based on parameters using the first relational mapping table, reducing a significant amount of manual searching and matching work. For example, in a complex game system, there are numerous parameters and corresponding scenes. Once the target scene identifier is determined, the first test case can be constructed based on it and the parameter values. The entire process can be automated using scripts, greatly improving the speed of test case generation. Taking the product search function test of an e-commerce system as an example, different search parameters (such as keywords, price ranges, etc.) can quickly find the corresponding search scene identifier through the mapping table, thereby automatically generating corresponding test cases, greatly saving the time of test case writing. The first relational mapping table stores the mapping relationship between parameters and scene identifiers, ensuring that each parameter can correspond to the corresponding scene, thus ensuring that test cases can cover various possible scenarios. For example, in the test of a multimedia player, parameters may include video resolution, audio format, etc. The mapping table can determine the playback scene corresponding to these parameters, thereby generating comprehensive test cases to ensure that the player can be tested under various input conditions.

[0145] See also Figure 3 The following will be explained following step S102 above.

[0146] In step S103, for each interactive element, a test case template corresponding to the interactive element is obtained, and a second test case for the interactive element is generated based on the test case template and the parameter value of at least one parameter of the interactive element.

[0147] In some embodiments, each interactive element corresponds to a test case template, and interactive elements of the same type can correspond to the same test case template. The test case template does not include the parameter values ​​of the parameters. Therefore, it is necessary to combine the test case template and the parameter values ​​of the interactive element to generate a second test case. The second test case is generated in real time based on the actual parameter values ​​of the parameters. Therefore, the second test case has real-time performance and authenticity.

[0148] In some embodiments, see Figure 5 The step S103 above, "generating a second test case for the interactive element based on the parameter value of at least one parameter of the test case template and the interactive element", can be achieved through the following steps S1031 to S1033, which are explained in detail below.

[0149] In step S1031, at least one predefined second placeholder is obtained from the use case template.

[0150] In this embodiment of the application, the second placeholder is used to indicate the target parameter value to be filled.

[0151] In some embodiments, the second placeholder is a placeholder set in advance based on experience, and the number of the second placeholder can be 1, 2, 3, etc. For example, assuming the use case template is "When the player presses {button name}, {door name} will open", the second placeholder can include: button name and door name; assuming the use case template is "When the value of {parameter name} is {boundary value}, the behavior of {interactive element} is {expected behavior}", the second placeholder can include: parameter name, boundary value, interactive element, and expected behavior; assuming the use case template is "When the state of {interactive element} is {first state identifier}, {operation} will lead to {expected result}", the second placeholder can include: interactive element, first state identifier, operation, and expected result.

[0152] In step S1032, for each second placeholder, the target parameter value indicated by the second placeholder is obtained from at least one parameter value.

[0153] Continuing with the example above, assuming the parameter values ​​include: button name "Button A" and door name "Door B", then "Button A" will be the target parameter value indicated by {Button Name}, and "Door B" will be the target parameter value indicated by {Door Name}.

[0154] In step S1033, a set of parameter values ​​to be executed is determined based on the target parameter value, and each parameter value to be executed in the set of parameter values ​​to be executed replaces the second placeholder in the test case template to obtain the second test case.

[0155] Continuing from the example above, the set of parameter values ​​to be executed is {Button A, Door B}. Based on this, by replacing {Button Name} and {Door Name} with "Button A" and "Door B" respectively in {Button A, Door B}, the second test case is "When the player presses Button A, Door B will open".

[0156] In some embodiments, the implementation of "determining the set of parameter values ​​to be executed based on the target parameter value" in step S1033 above may include the following two implementation methods, which are described in detail below.

[0157] In the first implementation method, when the target parameter value represents the boundary value of the target parameter, the implementation method of "determining the set of parameter values ​​to be executed based on the target parameter value" may include: determining the second effective interval of the interactive element based on the target parameter value; randomly generating a third value within the second effective interval and randomly generating a fourth value outside the second effective interval; and constructing the set of parameter values ​​to be executed through the third value and the fourth value.

[0158] Continuing the example above, suppose the use case template is "When the value of {parameter name} is {boundary value}, the behavior of {interactive element} is {expected behavior}", where "parameter name" is the player's health, "boundary value" is 0, "interactive element" is the player character, and "expected behavior" is the player character's death. Based on this, "boundary value" represents the boundary value of "parameter name", that is, "0" represents the boundary value of the player's health. Values ​​greater than 0 are defined as the second effective range, therefore 5 can be defined as the third value, and 0 as the fourth value. Finally, 5 and 0 are defined as the set of parameter values ​​to be executed.

[0159] In other embodiments, the second test case based on the third value (5) can be: when the player's life value is 5, the player character's behavior is to survive; the second test case based on the fourth value (0) can be: when the player's life value is 0, the player character's behavior is to die.

[0160] Using the first implementation method described above, boundary values ​​are often key areas where system problems are prone to occur during testing. Determining the second effective range of interactive elements based on the boundary values ​​of the target parameters clarifies the range within which the parameters function normally. Randomly generating a third value within the second effective range and a fourth value outside the range represent normal and abnormal situations, respectively. For example, in a game, a character's level parameter might have boundary values ​​of a minimum level of 1 and a maximum level of 100; the second effective range would be 1 to 100. Randomly selecting values ​​within this range tests the character's performance at normal levels, while selecting values ​​outside the range tests the system's ability to handle abnormal levels. This comprehensively covers different parameter values, ensuring stable system operation under both normal and abnormal conditions. Randomly generating a fourth value outside the second effective range helps identify potential defects in the system's handling of data exceeding the expected range. Randomly generating test values ​​within and outside the second effective range increases the randomness of the test data. This avoids the incomplete testing problems that might result from using fixed, limited test data.

[0161] In the second implementation method, when the target parameter value represents the current state of the interactive element and the target parameter value is the first state identifier, the implementation method of "determining the set of parameter values ​​to be executed based on the target parameter value" may include: obtaining the second state identifier, wherein the second state identifier is different from the first state identifier; and constructing the set of parameter values ​​to be executed through the first state identifier and the second state identifier.

[0162] Continuing with the example above, suppose the use case template is "When the state of {interactive element} is {first state identifier}, {action} will result in {expected result}", where "interactive element" can be a door, "first state identifier" can be closed, "action" can be pressing button A, and "expected result" is that the door's state changes to open. Based on this, the second state identifier can be open.

[0163] In other embodiments, the second test case based on the first state identifier (closed) can be: when the door is closed, pressing button A will cause the door to change to open; the second test case based on the second state identifier (open) can be: when the door is open, pressing button A will cause the door to change to closed.

[0164] Using the second implementation method described above, testing only the current state (first state identifier) ​​when testing interactive elements is insufficient. By obtaining a second state identifier different from the first state identifier and constructing them together into a set of execution parameter values, it is possible to ensure that test cases cover multiple states of interactive elements. For example, in a strategy game, a character may have multiple states such as "confrontation," "defense," and "rest." If the current character is in the "confrontation" state (first state identifier), by introducing other states such as "defense" (second state identifier), the interaction between the character and other game elements in different states can be tested, avoiding the omission of potential problems due to testing only a single state. The transition between different states is often a point where system problems are prone to occur. Constructing a set of execution parameter values ​​containing different state identifiers allows for specific testing of state transitions. In actual use, interactive elements frequently switch between different states. Including different state identifiers in the set of execution parameter values ​​can better simulate this real-world scenario, making the test results more accurately reflect the system's performance in actual operation.

[0165] Through steps S1031 to S1033, the test case template provides a general framework, avoiding the need to write each test case from scratch. For example, when testing the product search function of an e-commerce system, the test case template already specifies the basic structure such as the search process and interface verification. New test cases can be quickly generated simply by filling in different parameter values, greatly saving time and effort. The automated operation of obtaining the second placeholder and extracting the target parameter value from the parameter values ​​reduces the workload of manually filling in parameters. This significantly improves generation efficiency, especially when dealing with a large number of parameters and test cases. For example, in testing character attributes in a game, there may be multiple characters with different attribute values ​​that need to be tested. This method can quickly generate corresponding test cases for each character. By determining the set of parameter values ​​to be executed and replacing the second placeholder with each parameter value in the set, test cases with various parameter combinations can be generated. This helps to comprehensively cover the performance of interactive elements under various parameter conditions. Based on templates and automated parameter replacement, errors in test case writing caused by human factors are reduced. This avoids the problem of non-standard or inaccurate test cases caused by different testers' writing habits. For example, when filling in the expected results of test cases, following the standardized template can ensure the accuracy and comparability of the results.

[0166] In some embodiments, before obtaining the use case template corresponding to the interactive element in step S103 above, the use case template corresponding to the interactive element can be determined first. Based on this, the implementation method of determining the use case template corresponding to the interactive element may include: obtaining the type information of the interactive element, a second relationship mapping table, and a predefined second use case pool. The second relationship mapping table stores the mapping relationship between type and template identifier. Based on the second relationship mapping table and the type information, the use case template corresponding to the interactive element is determined from the second use case pool.

[0167] In some embodiments, the second relationship mapping table is a pre-set mapping table based on experience, which stores the mapping relationship between types and template identifiers. A predefined second use case pool includes template identifiers and use case templates. Based on this, the target template identifier corresponding to the type information can be determined based on the second relationship mapping table, and the use case template can be determined from the second use case pool based on the target template identifier.

[0168] By defining test case templates, a second relational mapping table stores the mapping relationship between types and template identifiers. This table allows for the rapid retrieval of the corresponding template identifier based on the type information of the interactive element. For example, in a large game testing project, interactive elements include various types such as character skills, item interactions, and scene transitions. Using the second relational mapping table, it's possible to directly locate the test case template matching a specific interactive element type without having to search through each one individually, significantly saving time and effort. A predefined second test case pool contains test case templates for various types of interactive elements. Determining templates from this pool based on mapping relationships avoids redesigning test cases for each new interactive element, fully reusing existing testing resources. For instance, when a new interactive element similar to a previous item interaction method is developed, the corresponding test case template can be directly reused to quickly generate test cases. Using test case templates from the second test case pool ensures that test cases generated for the same type of interactive element have a unified format and structure. This makes test cases more standardized, facilitating communication and collaboration among testing team members. For example, in a multi-person testing project, different members use the same test case template to test the same type of interactive element, and the test results are presented and recorded in a consistent way, which facilitates subsequent review and analysis.

[0169] See also Figure 3 The following explanation will continue from step S103 above.

[0170] In step S104, during the game operation, each interactive element is tested using the first test case and the second test case to obtain the first test result.

[0171] In some embodiments, interactive elements in different feature maps can be tested in parallel; while interactive elements in the same feature map can be tested sequentially, that is, after obtaining the first test result of an interactive element, the test of the next interactive element is performed.

[0172] In some embodiments, for each interactive element, the interactive element is tested by a first test case and a second test case, respectively, to obtain a first test result for the interactive element.

[0173] In some embodiments, see Figure 6 The step S104 above, "testing each interactive element using the first test case and the second test case of each interactive element to obtain the first test result", can be achieved through the following steps S1041 to S1043, which are explained in detail below.

[0174] In step S1041, the first use case pool corresponding to the feature map is obtained.

[0175] In this embodiment of the application, the first test case pool includes an element identifier for each interactive element, a first test case, a second test case, and a test status.

[0176] In some embodiments, assuming the feature map includes 10 interactive elements, the first test case pool includes element identifiers of these 10 interactive elements, a first test case, a second test case, and a test status. The first test case can be generated through step S102, and the second test case can be generated through step S103. The test status is used to characterize whether the interactive element has completed testing. The test status can include an untested state and a tested state. For example, the untested state can be represented by "0", and the tested state can be represented by "1".

[0177] In step S1042, the target identifier corresponding to the test state being untested is determined from each element identifier in the first test case pool.

[0178] In some embodiments, following the example above, the test status of each interactive element is obtained, and the element identifier corresponding to the test status of 0 is determined as the target identifier.

[0179] In step S1043, each target identifier is traversed, and the interactive element corresponding to the target identifier is tested through the first test case and the second test case corresponding to the target identifier to obtain the first test result.

[0180] In some embodiments, the interactive elements corresponding to each target identifier are tested sequentially by traversing the system, thereby achieving the testing of each interactive element.

[0181] In some embodiments, the implementation process of "testing the interactive element corresponding to the target identifier using the first test case and the second test case corresponding to the target identifier to obtain a first test result" in step S1043 above may include: executing the first test case corresponding to the target identifier to obtain a first prediction result; executing the second test case corresponding to the target identifier to obtain a second prediction result; when the first prediction result is the same as the first reference result in the first test case and the second prediction result is the same as the second reference result in the second test case, a first test result indicating successful testing is obtained, and the test status of the interactive element corresponding to the target identifier is updated to the tested status.

[0182] In some embodiments, a first test case corresponding to the target identifier may be executed first to obtain a first prediction result. When the first prediction result is the same as the first reference result in the first test case, a second test case is executed to obtain a second prediction result. When the second prediction result is the same as the second reference result in the second test case, a first test result indicating successful testing is obtained, and the test status of the interactive element corresponding to the target identifier is updated from untested to tested. The first reference result is included in the first test case and is a result pre-set based on experience; the first reference result is either a successful execution result or a failed execution result. The second reference result is included in the second test case and is a result pre-set based on experience; the second reference result is the expected result in the second test case.

[0183] In other embodiments, the second test case may be executed first, and the first test case may be executed only when the second prediction result is the same as the second reference result in the second test case.

[0184] By using the method described above for updating the test status, the first and second test cases are executed separately to test the interactive element from different perspectives. The first and second test cases may be based on different generation methods or consider different test scenarios. Combining them can more comprehensively cover various functions and possible situations of the interactive element. For example, in a game, the first test case may focus on verifying the basic functions of the interactive element, while the second test case may focus on its performance in complex scenarios or abnormal conditions. Executing both test cases allows for a more accurate evaluation of the actual performance of the interactive element. The first predicted result is compared with the first reference result in the first test case, and the second predicted result is compared with the second reference result in the second test case. The reference result is the expected result pre-set when designing the test case. This comparison clearly determines whether the interactive element works as expected. If the predicted result matches the reference result, it indicates that the interactive element performs normally in the current test scenario; otherwise, there may be a problem, thus improving the accuracy of the test.

[0185] In some embodiments, when the first prediction result is different from the first reference result, or the second prediction result is different from the second reference result, a first test result of test failure is obtained; and the test status of the interactive element corresponding to the target identifier is updated to the tested status.

[0186] In some embodiments, when the first test case is executed first and the first prediction result is different from the first reference result, a first test result of test failure is obtained and the second test case is not executed; while when the second test case is executed first and the second prediction result is different from the second reference result, a first test result of test failure is obtained and the first test case is not executed.

[0187] In some embodiments, after obtaining the first test result of test failure, the test status of the interactive element corresponding to the target identifier is also updated from untested to tested.

[0188] By using the aforementioned method of updating the test status and comparing the predicted and reference results, a test failure can be immediately identified upon discrepancy, allowing for the timely discovery of defects in the software or game. For example, in testing interactive elements in a game, if the first test case verifies the dialogue function between the player and NPC, and the reference result is set to display dialogue content correctly, but the actual predicted result is garbled text, identifying this discrepancy can accurately pinpoint potential encoding or data transmission issues in the dialogue function. Even if the test fails, updating the test status of the interactive element to "tested" prevents it from being missed and retested. This avoids problems being left unchecked during subsequent development or testing, ensuring overall software quality. Updating the test status to "tested" quickly identifies problematic interactive elements. Testers or developers can then quickly filter out objects requiring focused attention and handling, avoiding unnecessary repetitive preliminary testing steps on identified problematic elements, concentrating on problem-solving, and improving testing efficiency.

[0189] In some embodiments, after obtaining the first test result of test failure described above, the following may also be performed: identifying the interactive element as an anomalous element; generating a first prompt message for extreme scenario anomalies when the first prediction result differs from the first reference result; and outputting the element identifier of the anomalous element and the first prompt message. When the second prediction result differs from the second reference result, obtaining the set of parameters to be executed included in the second test case; generating a second prompt message based on the set of parameters to be executed, and outputting the element identifier of the anomalous element and the second prompt message.

[0190] In some embodiments, if the first prediction result differs from the first reference result, a first alert message for extreme scenario anomalies is generated. For example, the first alert message could be: "An anomaly has occurred in the extreme scenario." Based on this, assuming the element identifier of the anomaly element is AE01, the output first alert message could be: "AE01 has encountered an anomaly in the extreme scenario."

[0191] In other embodiments, if the second prediction result differs from the second reference result, the set of parameters to be executed included in the second test case is obtained. For example, the set of parameters to be executed can be {interactive element 02, controlled object}. Based on this, the second prompt message can be "an exception occurred when the interactive element was controlling the controlled object". At this time, the interactive element 02 is the exception element. Assuming that the element identifier of the interactive element 02 is AE02, the output second prompt message can be: AE02 has encountered an exception when controlling the controlled object.

[0192] By outputting the first or second prompt message and marking interactive elements as anomalous, problematic interactive elements can be quickly identified. After a test fails, the system automatically marks the interactive element as anomalous, reducing manual troubleshooting time. The anomalous element's identifier and prompt message directly point to the source of the problem, facilitating rapid location and repair by developers. Based on the difference between the predicted and reference results, different types of prompt messages are generated to help distinguish the specific type of anomaly. When the first predicted result differs from the first reference result, an extreme scenario anomaly prompt message is generated, indicating that the interactive element has a problem under extreme conditions. When the second predicted result differs from the second reference result, a prompt message related to the set of parameters to be executed is generated, indicating that the interactive element has a problem under specific parameter conditions. This distinction helps developers analyze the cause of the problem more accurately. By outputting the anomalous element's identifier and prompt message, detailed anomaly information is provided, facilitating problem analysis and repair. The anomalous element's identifier clearly points to the specific problem; the prompt message describes the type of anomaly and contextual information, such as extreme scenarios, providing developers with a clear direction for repair. By generating prompt messages and outputting exception information, the system supports subsequent automated repair processes. These prompt messages can serve as input for automated repair tools, such as automatically generating repair code or adjusting parameters. The identification of exception elements and prompt messages can be integrated into the problem localization system, facilitating task allocation and progress tracking. This allows for the efficient identification, analysis, and repair of exceptions in interactive elements, improving the efficiency and quality of the testing process and ultimately ensuring that the game's functionality and logic meet design goals.

[0193] Through steps S1041 to S1043, the test cases for all interactive elements are centrally managed through the first test case pool, ensuring an orderly and localizable testing process. The first test case pool records the identifier, test case, and test status of each interactive element, facilitating unified management and updates. Recording the test status (e.g., "Untested," "Tested") helps testers quickly locate the targets that need testing. The first and second test cases cover different scenarios and boundary conditions for the interactive elements. The second test case typically targets common scenarios, verifying the basic functionality of the interactive element. The first test case typically targets boundary conditions or special scenarios, verifying the robustness of the interactive element. The combination of both ensures that the interactive element functions correctly under various conditions. By traversing target identifiers and executing test cases, automated testing processes are supported. The system can automatically identify target identifiers in untested states and execute the corresponding test cases. Automated testing reduces manual operations, improves testing efficiency, and reduces human error. Through this execution process, interactive elements can be verified efficiently and comprehensively, ensuring that the game's functionality and logic meet design goals, improving the overall quality of the game and the player experience.

[0194] Through steps S101 to S104 above, for each parameter of each interactive element, a first test case for the interactive element is generated based on the parameter value of the parameter, and the first test case is used to verify the interaction result of the interactive element in extreme scenarios, that is, the first test case in extreme scenarios is automatically generated. Furthermore, test case templates corresponding to interactive elements are obtained, and second test cases are generated based on the test case templates and the parameter values ​​of at least one parameter of the interactive element. Since the second test cases are generated in real time based on the parameter values ​​and the test case templates, they possess real-time characteristics. Moreover, due to the diversity and realism of the parameter values, the second test cases possess high coverage and high accuracy. In other words, this application can automatically generate second test cases that are real-time, highly comprehensive, and highly accurate. Finally, each interactive element is tested using the first and second test cases for each interactive element, obtaining the first test result for each interactive element. Since the testing utilizes both the first test cases under extreme scenarios and the second test cases that are real-time, highly comprehensive, and highly accurate, and since both the first and second test cases are automatically generated, the comprehensiveness and sufficiency of the test can be improved through the first test cases under extreme scenarios, and the real-time performance, coverage, and accuracy of the test can be improved through the second test cases. This achieves automated testing of interactive elements and also improves the comprehensiveness, sufficiency, accuracy, and efficiency of the test.

[0195] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0196] In the testing method provided in this application embodiment, all gameplay verifications are consolidated into a single feature map, supporting the automatic generation of extreme test scenarios, i.e., automatically generating the first test case. Test cases for all gameplays are dynamically generated through the combination of parameter values ​​and test case groups, i.e., dynamically generating the second test case. Here, gameplay can be mechanisms, and gameplay corresponds to interactive elements in other embodiments.

[0197] In some embodiments, the process of dynamically generating a second test case is as follows: Figure 7 As shown, the feature map includes N blocks. Block 1 includes a joystick switch 701 and a button switch 702, and block N includes a destructible wooden box 703 and an elemental destruction ball 704. First, the test case group corresponding to each block can be determined, that is, the test case template corresponding to each block can be determined. For example, test case group 1 corresponds to block 1, and test case group 2 corresponds to block N. Then, combining the parameter values ​​of the gameplay, the parameters of the joystick switch 701 and the button switch 702 are input into test case group 1 respectively, resulting in test case group 1 for the joystick switch 701 and test case group 1 for the button switch 702. The parameters of the destructible wooden box 703 and the elemental destruction ball 704 are input into test case group 2 respectively, resulting in test case group 2 for the destructible wooden box 703 and test case group 2 for the elemental destruction ball 704, thereby realizing the conversion of test case group 1 and test case group 2. Through test case conversion, gameplay test cases can be obtained, which are equivalent to the second test cases in other embodiments.

[0198] The key technologies in this application's embodiments include: feature map scene generation, dynamic generation of gameplay use cases based on use case groups, and a two-layer framework for use case reuse and execution status pass-through.

[0199] In some embodiments, it is possible to customize the scene of the feature map and automatically generate extreme test scenes for the gameplay.

[0200] This application embodiment allows for the placement of different gameplay modes on different plots within a feature map. This enables developers or testers to customize the feature map content according to specific needs, associating complex gameplay modes for testing in various scenarios. This flexibility helps to better simulate diverse game environments and conditions. The plots in this embodiment correspond to blocks in other embodiments.

[0201] This application's embodiments can automatically generate extreme test scenarios based on gameplay parameters in a feature map. For example, for a flamethrower, a stake can be automatically generated both inside and outside its control range. When the flamethrower sprays virtual flames, the expected results may include: the stake within the flamethrower's control range will be burned, and its health will decrease; while the stake outside the flamethrower's control range will not be burned, and its health will remain unchanged. In this way, the system can quickly create extreme situations that may lead to game crashes or serious vulnerabilities, thereby improving the comprehensiveness and effectiveness of the test.

[0202] In some embodiments, the testing system can dynamically create test cases for all gameplay modes based on gameplay parameter values ​​and test case groups, i.e., dynamically create second test cases. Here, a test case group is a pre-defined set of checks for a specific type of gameplay. During execution, the testing system dynamically assembles test cases based on the gameplay type and parameters. This improves test coverage and efficiency, and simplifies the test maintenance process.

[0203] In some embodiments, a single feature map can contain all gameplay elements. Extracting and processing gameplay elements from levels allows for the rapid traversal of all gameplay testing content, simplifying the verification process and improving testing efficiency. This decoupling also facilitates the quick identification of problems inherent in the gameplay elements themselves.

[0204] This application separates the gameplay logic from the specific level design, allowing gameplay to be tested and verified independently of the levels. This approach enables comprehensive testing of all gameplay elements in a short time, ensuring that the test results for each gameplay element under different conditions meet expectations. This efficient testing process significantly shortens the development cycle.

[0205] In some embodiments, when a problem arises, the decoupled design allows for faster identification of specific gameplay issues without having to search for problems within complex level logic. This helps improve problem-solving efficiency.

[0206] The testing method proposed in this application is a lightweight automated verification solution for open-world level gameplay based on feature maps. It consolidates the verification of all gameplay into a single feature map, supports the automatic generation of extreme test scenarios, and dynamically generates test cases for all gameplay by combining parameter values ​​with test case groups, reducing the manpower and time investment in maintenance and testing. At the same time, this system separates the functional verification of gameplay from the levels, simplifying the verification process, improving the verification efficiency of gameplay, and facilitating the localization of problems in the gameplay itself.

[0207] Taking the application scenario of game business as an example, the testing method provided in the embodiments of this application may include the following steps one to three, and the testing method may be executed by the server.

[0208] Step 1: Select the feature map for the test execution. The feature map can be either a manually created set of gameplay maps or a map of extreme test scenarios dynamically generated based on the parsed gameplay parameters.

[0209] Step two: Obtain each gameplay instance from the feature map, extract the parameter values, and input them into the corresponding test case group. These parameters can include numerical values ​​(such as damage, speed), status (such as whether it is available, whether it is active), etc.

[0210] Step three involves detecting events (which may include player input, changes in game state, updates to the user interface, etc.) and collecting memory data (which may include character state, environmental changes, and the execution results of game logic, etc.) to determine whether the automated test for each gameplay mode has passed. If the actual result matches the expected result, the test passes; otherwise, it is recorded as a failure and a corresponding report is generated.

[0211] The testing method provided in this application is applicable to open-world role-playing games.

[0212] In some embodiments, the testing method provided in this application may include the following steps one to four:

[0213] Step 1: Load the feature map and generate extreme test scenarios. First, load the feature map using a preset input source, obtain the gameplay within each plot of the feature map, and generate extreme test scenarios based on the gameplay parameters, such as... Figure 8 As shown, the generation from parameters to extreme scenes is achieved through a mapping relationship. For example, for a range parameter with a value of M, detection points are generated both inside and outside M, centered on the gameplay. This mapping relationship corresponds to the first relationship mapping table in other embodiments.

[0214] See Figure 8 Block 1 includes gameplay 801 and gameplay 802. Gameplay 801 includes parameters P1 and P2, and gameplay 802 includes parameters P1 and P3. Block 2 includes gameplay 801 and gameplay 803, and gameplay 803 includes parameters P4 and P5. Based on this, the parameter set {P1, P2, P3, P4, P5} for gameplay 1, gameplay 2, and gameplay 3 is determined. Then, based on the mapping relationship between parameters and extreme scenarios, the scenario identifier corresponding to each parameter is determined, resulting in scenario identifier S1 for parameter P1, S2 for parameter P2, S3 for parameter P3, S4 for parameter P4, and S5 for parameter P5. Finally, the extreme scenario for each gameplay is generated based on the scenario identifiers.

[0215] Step two, obtain the instance list. Extract all relevant instances from the loaded feature map to form a gameplay instance list. Each instance represents an independent object in the feature map for subsequent processing.

[0216] Step 3: Iterate through the instances to generate executable test cases. Iterate through the obtained list of gameplay instances, inputting the instance parameter values ​​into the corresponding test case group to obtain executable test cases. These executable test cases correspond to the second test case in other embodiments. Parameters may include instance attributes, status, or other characteristic information. Specific check operations for different parameters are associated in the test case group.

[0217] Step four: Execute extreme scenarios and executable test cases and output the test results. Test case execution is carried out on a case-by-case basis, with each test case as the smallest unit. The execution result is then passed to the test case group. The test case group processes the test case results and updates the status to the map pool corresponding to the feature map in order to execute the next set of test cases.

[0218] In some embodiments, a gameplay use case is equivalent to a set of use cases for specific operations or tests performed on a gameplay instance under specific conditions, which can be used to verify the effectiveness and feasibility of the gameplay and its impact on user experience.

[0219] This application's embodiments, through a systematic approach, efficiently process instances in the feature map, ensuring that each instance and its parameters are tested, thus improving test accuracy. Simultaneously, the fundamental characteristics of each gameplay element in the feature map determine that gameplay elements are decoupled from each other, and their execution results do not interfere with each other, thereby improving overall processing efficiency. This parameter method can be widely applied to open-world games and other similar game genres.

[0220] In the above process, there are two nested traversal operations. The key points are the reuse of the underlying basic atoms and the two-layer pass-through of the execution state. For example... Figure 9 As shown, the system's execution pool and execution phase can be considered as the core components of the automated testing framework. The execution pool can include a map pool 901, a gameplay pool 902, and a general test case pool 903. The map pool 901 corresponds to the first test case pool in other embodiments, and the general test case pool 903 corresponds to the second test case pool in other embodiments.

[0221] In some embodiments, map pool 901 is an execution pool containing all gameplay test case groups. Each gameplay test case group is an object within the map pool. Map pool 901 iterates through all test case groups, performing checks and executions; it is responsible for associating each gameplay test case group with corresponding parameter values. At the start of the test, the map pool is initialized and all test case groups are iterated through to ensure that each test case group is executed correctly.

[0222] In some embodiments, the gameplay pool 902 is a specific set of test cases, which combines gameplay parameter values ​​as input. Each test case originates from a general test case pool 903. The gameplay pool 902 processes test cases related to preset gameplay, ensuring that test cases can be dynamically adjusted based on input parameters; it also allows for centralized management and execution of tests on preset gameplay. When testing a preset gameplay is required, the gameplay pool 902 is populated with the corresponding test cases and executed based on the input parameters.

[0223] In some embodiments, the general test case pool 903 contains all basic test cases, from which test execution for any object can obtain executable test cases. The general test case pool 903 provides basic, reusable test cases, reducing repetitive code and test case writing; it ensures that all test cases can be invoked in different execution pools. When creating the gameplay pool 902 or map pool 901, the required basic test cases can be extracted from the general test case pool 903 for testing.

[0224] Each of the above execution pools can be divided into two execution phases: initialization and execution update.

[0225] In some embodiments, the initialization phase refers to the integration of execution content and the binding of event detection at the start of the corresponding execution pool; initializing objects in the execution pool to prepare the environment and state required for execution; binding event detectors so that events (such as errors, state changes, etc.) can be captured and processed during execution; and ensuring that all test cases and environments are ready before the test begins so that subsequent execution can proceed smoothly.

[0226] In some embodiments, the execution update phase refers to checking the state of objects in its own pool and updating the execution results. This involves periodically checking the state of test cases in the execution pool, updating test results and status information, and handling any exceptions and errors that may occur during execution to ensure test stability. During test execution, the execution status of test cases is continuously monitored to provide timely feedback on execution results and status changes.

[0227] Through the design of these three execution pools and two execution phases, the system can efficiently manage and execute test cases. Each execution pool has a clearly defined function and use case, making the testing process more modular and flexible. Meanwhile, the design of the initial phase and execution update phase ensures the stability and locatability of the tests. This structured design not only improves testing efficiency but also enhances the system's maintainability and scalability.

[0228] See Figure 9When combining execution actions (execution reuse), the process flows from map pool 901 to general use case pool 903. The execution actions in map pool 901 are composed of use case groups from each gameplay use case pool 902; this process is called gameplay use case action combination, which can be denoted as ActionCombiner(GP). The gameplay use cases here are obtained from gameplay pool 902, and the detection content of gameplay pool 902 is composed of general use cases; this process is called general use case action combination, which can be denoted as ActionCombiner(Common Case). For the lowest-level use cases, this includes the specific operations to be performed and the specific events to be detected.

[0229] During execution status pass-through, the process flows from the general test case pool 903 to the map pool 901. After executing its defined action, the general test case determines the result of the action execution (e.g., in progress, successful execution, failed execution, timeout, no response, etc.) based on detected events and acquired memory object data. This result is then passed through when updating the gameplay pool 902. The gameplay pool 902 updates its own status based on the result of this atomic execution. Then, the map pool 901, after querying the gameplay test case status during the update process, can determine whether to proceed to the next gameplay test.

[0230] The testing method provided in this application uses a feature map that incorporates the minimum gameplay elements for automated testing. This reduces the testing workload from the entire project's map to individual, lightweight maps. The automated verification supports rapid response self-testing and release verification, improving timeliness. The feature map can generate corresponding extreme test scenarios based on gameplay parameter characteristics, ensuring thorough testing of the gameplay. The decoupling of gameplay and levels in the feature map allows for independent output of problems, directly pinpointing detailed parameter issues specific to the gameplay. Furthermore, generating test cases through the mapping relationship between parameters and atomic operations significantly reduces test case maintenance costs. This mapping relationship corresponds to the second mapping table in other embodiments.

[0231] For issues requiring rapid response and precise location of problems arising from adjustments to basic functions, the testing methods provided in this application's embodiments can be used. This application also proposes a combined testing method integrating levels and gameplay. This combined testing method utilizes an automated level testing process to automate the testing of level flow logic; and an automated gameplay testing process to automate the testing of gameplay functions. The automated gameplay testing process corresponds to the testing methods in other embodiments. Therefore, for issues arising from coupling relationships in actual projects, the combined testing method can be used to simultaneously achieve automated and comprehensive testing of both levels and gameplay.

[0232] It is understood that the embodiments of this application involve data related to feature maps, first mapping relationship tables, boundary values ​​of parameters, scene templates, second state identifiers, first use case pools, type information, initial maps, third relationship mapping tables, etc. The collection, use and processing of such data must comply with relevant laws, regulations and standards.

[0233] The following description continues to illustrate the exemplary structure of the test apparatus 455 provided in the embodiments of this application as a software module. In some embodiments, such as... Figure 2 As shown, the software modules stored in the test device 455 in the memory 450 may include:

[0234] The first acquisition module 4551 is used to acquire a feature map, which includes parameters and parameter values ​​of multiple interactive elements; the first generation module 4552 is used to generate a first test case for each of the parameters of each interactive element based on the parameter value, wherein the first test case is used to verify the interaction result of the interactive element in an extreme scenario where the parameter value and the boundary value of the parameter satisfy an approximate condition; the second generation module 4553 is used to acquire a test case template corresponding to each interactive element, and generate a second test case for each interactive element based on the test case template and the parameter value of at least one parameter of the interactive element; the testing module 4554 is used to test each interactive element during game operation using the first test case and the second test case for each interactive element to obtain a first test result.

[0235] In some embodiments, the first generation module 4552 is further configured to: obtain a first relational mapping table, the first relational mapping table storing a mapping relationship between parameters and scene identifiers; determine the target scene identifier corresponding to the parameter through the first relational mapping table; and construct the first test case based on the target scene identifier and the parameter value of the parameter.

[0236] In some embodiments, when the parameter is used to characterize the effective range of the interactive element, the first generation module 4552 is further configured to: obtain the boundary value of the parameter; determine a first effective range of the interactive element based on the boundary value; determine a first value that satisfies the approximation condition with the boundary value; construct an effective test case based on the target scene identifier and the first value, wherein the difference between the first value and the boundary value is less than a difference threshold and is located within the first effective range; determine a second value that satisfies the approximation condition with the boundary value; construct a failure test case based on the target scene identifier and the second value, wherein the difference between the second value and the boundary value is less than a difference threshold and is located outside the first effective range; and determine the effective test case and the failure test case as the first test case.

[0237] In some embodiments, the first generation module 4552 is further configured to: obtain a scene template corresponding to the target scene identifier, wherein the scene template includes a first placeholder for indicating the parameter value to be filled in; replace the first placeholder in the scene template with the first value to obtain an interactive effective scene; and determine the interactive effective scene and the execution success result as effective test cases.

[0238] In some embodiments, the first generation module 4552 is further configured to replace the first placeholder in the scene template with the second value to obtain an interactive failure scene; and to determine the interactive failure scene and the execution failure result as failure test cases.

[0239] In some embodiments, the second generation module 4553 is further configured to: obtain at least one predefined second placeholder in the test case template, the second placeholder being used to indicate the target parameter value to be filled; for each second placeholder, obtain the target parameter value indicated by the second placeholder from at least one of the parameter values; determine a set of parameter values ​​to be executed based on the target parameter values, and replace the second placeholder in the test case template with each parameter value to be executed in the set of parameter values ​​to be executed to obtain a second test case.

[0240] In some embodiments, when the target parameter value represents the boundary value of the target parameter, the second generation module 4553 is further configured to: determine the second effective interval of the interactive element based on the target parameter value; randomly generate a third value within the second effective interval and randomly generate a fourth value outside the second effective interval; and construct the set of parameter values ​​to be executed using the third value and the fourth value.

[0241] In some embodiments, when the target parameter value represents the current state of the interactive element and the target parameter value is a first state identifier, the second generation module 4553 is further configured to obtain a second state identifier, wherein the second state identifier is different from the first state identifier; and construct the set of parameter values ​​to be executed through the first state identifier and the second state identifier.

[0242] In some embodiments, the testing module 4554 is further configured to: obtain a first test case pool corresponding to the feature map, wherein the first test case pool includes an element identifier, a first test case, a second test case, and a test state for each interactive element; determine, from each element identifier in the first test case pool, a target identifier corresponding to the untested state; traverse each target identifier, and test the interactive element corresponding to the target identifier using the first test case and the second test case corresponding to the target identifier, to obtain a first test result.

[0243] In some embodiments, the testing module 4554 is further configured to: execute a first test case corresponding to the target identifier to obtain a first prediction result; execute a second test case corresponding to the target identifier to obtain a second prediction result; when the first prediction result is the same as the first reference result in the first test case and the second prediction result is the same as the second reference result in the second test case, a first test result indicating successful testing is obtained, and the test status of the interactive element corresponding to the target identifier is updated to the tested status.

[0244] In some embodiments, the software module in the testing apparatus 455 may further include:

[0245] The first determining module is used to obtain a first test result indicating test failure when the first prediction result is different from the first reference result, or the second prediction result is different from the second reference result; the first updating module is used to update the test status of the interactive element corresponding to the target identifier to the tested status.

[0246] In some embodiments, the software module in the testing apparatus 455 may further include:

[0247] The second determining module is used to determine the interactive element as an abnormal element; the third generating module is used to generate a first prompt message for extreme scenario abnormality when the first prediction result is different from the first reference result; the first output module is used to output the element identifier of the abnormal element and the first prompt message.

[0248] In some embodiments, the software module in the testing apparatus 455 may further include:

[0249] The second acquisition module is used to acquire the set of parameters to be executed included in the second test case when the second prediction result is different from the second reference result; the fourth generation module is used to generate a second prompt message based on the set of parameters to be executed, and output the element identifier of the abnormal element and the second prompt message.

[0250] In some embodiments, the software module in the testing apparatus 455 may further include:

[0251] The third acquisition module is used to acquire the type information of the interactive element, the second relationship mapping table, and the predefined second use case pool. The second relationship mapping table stores the mapping relationship between type and template identifier. The third determination module is used to determine the use case template corresponding to the interactive element from the second use case pool based on the second relationship mapping table and the type information.

[0252] In some embodiments, the software module in the testing apparatus 455 may further include:

[0253] The fourth acquisition module is used to acquire an initial map, a third relation mapping table, and type information of each interactive element. The initial map includes multiple blocks, and the third relation mapping table stores the mapping relationship between blocks and categories. The fourth determination module is used to determine the block corresponding to each interactive element based on the third relation mapping table and the type information of each interactive element. The fifth determination module is used to determine the element identifier, parameters, and parameter values ​​of each interactive element as the block information of the block, thereby obtaining the feature map.

[0254] In some embodiments, the software module in the testing apparatus 455 may further include:

[0255] The sixth determining module is used to determine the element to be adjusted, the current block corresponding to the element to be adjusted, and the adjusted block in response to the adjustment instruction for the interactive element in the feature map; the deletion module is used to delete the element identifier, parameters, and parameter values ​​of the element to be adjusted from the block information of the current block; and the adding module is used to add the element identifier, parameters, and parameter values ​​of the element to be adjusted to the block information of the adjusted block to obtain the adjusted feature map.

[0256] This application provides a computer program product or computer program that includes computer-executable instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the computer device to perform the test method described in this application.

[0257] This application provides a computer-readable storage medium storing computer-executable instructions. When these computer-executable instructions are executed by a processor, they cause the processor to execute the test method provided in this application. For example, ... Figure 3 The test method is shown.

[0258] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0259] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0260] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0261] As an example, computer-executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0262] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A testing method, characterized in that, The method includes: Obtain a feature map, which includes parameters and parameter values ​​of multiple interactive elements; For each parameter of each interactive element, a first test case is generated based on the parameter value of the parameter. The first test case is used to verify the interaction result of the interactive element in an extreme scenario where the parameter value and the boundary value of the parameter satisfy an approximate condition. For each interactive element, obtain the test case template corresponding to the interactive element, and generate a second test case for the interactive element based on the test case template and the parameter value of at least one parameter of the interactive element. During game operation, each interactive element is tested using the first test case and the second test case for each interactive element, and a first test result is obtained.

2. The method according to claim 1, characterized in that, The generation of a first test case for the interactive element based on the parameter values ​​of the parameters includes: Obtain the first relationship mapping table, which stores the mapping relationship between parameters and scene identifiers; The target scene identifier corresponding to the parameter is determined by the first relationship mapping table; The first test case is constructed based on the target scene identifier and the parameter values.

3. The method according to claim 2, characterized in that, When the parameter is used to characterize the effective range of the interactive element, constructing the first test case based on the target scene identifier and the parameter value includes: Obtain the boundary values ​​of the parameters, and determine the first effective range of the interactive element based on the boundary values; A first value that satisfies the approximation condition with the boundary value is determined, and an effective test case is constructed based on the target scene identifier and the first value. The difference between the first value and the boundary value is less than the difference threshold and is located within the first effective interval. A second value that satisfies the approximation condition with the boundary value is determined, and a failure test case is constructed based on the target scenario identifier and the second value. The difference between the second value and the boundary value is less than the difference threshold and is located outside the first effective interval. The effective test case and the ineffective test case are determined as the first test case.

4. The method according to claim 3, characterized in that, The construction of effective test cases based on the target scene identifier and the first value includes: Obtain the scene template corresponding to the target scene identifier, wherein the scene template includes a first placeholder for indicating the parameter value to be filled in the parameter; Replace the first placeholder in the scene template with the first value to obtain an interactive scene. The interactive effective scenarios and successful execution results are identified as effective test cases.

5. The method according to claim 4, characterized in that, The construction of failure test cases based on the target scenario identifier and the second value includes: Replace the first placeholder in the scene template with the second value to obtain an interaction failure scene; The interactive failure scenarios and execution failure results are identified as failure test cases.

6. The method according to claim 1, characterized in that, The generation of a second test case for the interactive element based on the parameter value of at least one parameter of the test case template and the interactive element includes: Obtain at least one predefined second placeholder from the use case template, the second placeholder being used to indicate the target parameter value to be filled; For each of the second placeholders, obtain the target parameter value indicated by the second placeholder from at least one of the parameter values; Based on the target parameter value, a set of parameter values ​​to be executed is determined, and each parameter value to be executed in the set of parameter values ​​to be executed replaces the second placeholder in the test case template to obtain the second test case.

7. The method according to claim 6, characterized in that, When the target parameter value represents the boundary value of the target parameter, determining the set of parameter values ​​to be executed based on the target parameter value includes: Based on the target parameter value, determine the second effective range of the interactive element; A third value is randomly generated within the second effective interval, and a fourth value is randomly generated outside the second effective interval; The set of parameter values ​​to be executed is constructed using the third and fourth values.

8. The method according to claim 6, characterized in that, When the target parameter value represents the current state of the interactive element, and the target parameter value is a first state identifier, determining the set of parameter values ​​to be executed based on the target parameter value includes: Obtain a second status identifier, wherein the second status identifier is different from the first status identifier; The set of parameter values ​​to be executed is constructed using the first status identifier and the second status identifier.

9. The method according to any one of claims 1 to 8, characterized in that, The step of testing each interactive element using the first test case and the second test case to obtain a first test result includes: Obtain the first test case pool corresponding to the feature map. The first test case pool includes the element identifier, first test case, second test case, and test status of each interactive element. From each element identifier in the first use case pool, determine the target identifier corresponding to the test state being untested; Each target identifier is traversed, and the interactive element corresponding to the target identifier is tested using the first test case and the second test case corresponding to the target identifier to obtain the first test result.

10. The method according to claim 9, characterized in that, The step of testing the interactive elements corresponding to the target identifier using the first and second test cases to obtain a first test result includes: Execute the first test case corresponding to the target identifier to obtain the first prediction result; Execute the second test case corresponding to the target identifier to obtain the second prediction result; When the first prediction result is the same as the first reference result in the first test case, and the second prediction result is the same as the second reference result in the second test case, a first test result indicating successful testing is obtained, and the test status of the interactive element corresponding to the target identifier is updated to the tested status.

11. The method according to claim 9, characterized in that, The method further includes: When the first prediction result is different from the first reference result, or the second prediction result is different from the second reference result, a first test result of test failure is obtained; Update the test status of the interactive element corresponding to the target identifier to the tested status.

12. The method according to claim 11, characterized in that, After obtaining the first test result indicating test failure, the method further includes: The interactive element was identified as an abnormal element. When the first prediction result differs from the first reference result, a first alert message indicating an extreme scenario anomaly is generated. Output the element identifier of the abnormal element and the first prompt message.

13. The method according to claim 12, characterized in that, The method further includes: When the second prediction result differs from the second reference result, obtain the set of parameters to be executed included in the second test case; A second prompt message is generated based on the set of parameters to be executed, and the element identifier of the abnormal element and the second prompt message are output.

14. The method according to any one of claims 1 to 8, characterized in that, Before obtaining the use case template corresponding to the interactive element, the method further includes: Obtain the type information of the interactive element, a second relationship mapping table, and a predefined second use case pool. The second relationship mapping table stores the mapping relationship between type and template identifier. Based on the second relationship mapping table and the type information, the use case template corresponding to the interaction element is determined from the second use case pool.

15. The method according to any one of claims 1 to 8, characterized in that, Before obtaining the feature map, the method further includes: Obtain the initial map, the third relationship mapping table, and the type information of each interactive element. The initial map includes multiple blocks, and the third relationship mapping table stores the mapping relationship between blocks and categories. Based on the third relation mapping table and the type information of each interactive element, the block corresponding to each interactive element is determined; For each interactive element, the element identifier, parameters, and parameter values ​​of the interactive element are determined as the block information of the block, thus obtaining the feature map.

16. The method according to any one of claims 1 to 8, characterized in that, The method further includes: In response to an adjustment instruction for an interactive element in the feature map, the element to be adjusted, the current block corresponding to the element to be adjusted, and the adjusted block are determined. Remove the element identifier, parameters, and parameter values ​​of the element to be adjusted from the block information of the current block; The element identifier, parameters, and parameter values ​​of the element to be adjusted are added to the block information of the adjusted block to obtain the adjusted feature map.

17. A testing apparatus, characterized in that, The device includes: The first acquisition module is used to acquire a feature map, which includes parameters and parameter values ​​of multiple interactive elements; The first generation module is used to generate a first test case for each of the parameters of each interactive element based on the parameter value of the parameter. The first test case is used to verify the interaction result of the interactive element in an extreme scenario where the parameter value and the boundary value of the parameter satisfy an approximate condition. The second generation module is used to obtain a test case template corresponding to each interactive element, and generate a second test case for the interactive element based on the test case template and the parameter value of at least one parameter of the interactive element. The testing module is used to test each interactive element during game operation using the first test case and the second test case for each interactive element, and obtain a first test result.

18. A computer device, characterized in that, The computer device includes: Memory is used to store executable instructions for a computer; A processor, when executing computer-executable instructions stored in the memory, implements the test method according to any one of claims 1 to 16.

19. A computer-readable storage medium storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed by a processor, they implement the test method according to any one of claims 1 to 16.

20. A computer program product comprising a computer program or computer-executable instructions, characterized in that, When the computer program or computer-executable instructions are executed by a processor, the test method according to any one of claims 1 to 16 is implemented.

Images