Smoke testing method and apparatus, electronic device, and storage medium

Abstract

A smoke testing method and apparatus, an electronic device, and a storage medium. The method comprises: in response to a smoke testing trigger event, determining a test branch and a preset test case corresponding to the test branch, wherein the preset test case corresponds to a functionality to be tested of the test branch (S102); establishing communication with a client deployed in the test branch (S104); executing the preset test case to control the client to execute the following operations: on the basis of a binding relationship between a plurality of memory objects, searching the client for a target memory object related to said functionality of the test branch, calling a function bound to the target memory object, and executing said functionality by means of the function (S106); and determining a test result on the basis of data generated by the function executing said functionality (S108). By controlling a client to call a function to execute a functionality to be tested, the function being bound to a memory object related to said functionality, whether said functionality can be normally executed can be determined on the basis of data generated in the execution process, thereby implementing smoke testing of codes.

Description

Smoke testing methods, apparatus, electronic equipment and storage media

[0001] Cross-referencing related applications

[0002] This application claims priority to Chinese Patent Application No. 202410977034.X, filed on July 19, 2024, entitled “Smoke Testing Method, Apparatus, Electronic Device and Storage Medium”, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to the field of testing technology, and more specifically, to a smoke test method, apparatus, electronic device, and storage medium. Background Technology

[0004] In the software development process, after developers submit their code, they need to perform basic verification on the client side to ensure the code can perform fundamental functions. This includes verifying whether the interface is basically correct, or verifying the functionality of basic functions by clicking on the graphical user interface. This type of verification is collectively known as smoke testing. The core purpose of smoke testing is to verify whether the basic functions of the software are working correctly. However, some software code corresponds to complex business functions, making it difficult to use the above-mentioned smoke testing methods, thus failing to verify whether the code can correctly implement the corresponding business functions. Summary of the Invention

[0005] In view of this, the purpose of this disclosure is to provide a smoke testing method, apparatus, electronic device and storage medium for performing smoke testing on code.

[0006] In a first aspect, embodiments of this disclosure provide a smoke testing method, the method comprising: in response to a smoke test triggering event, determining a test branch and a preset test case corresponding to the test branch; the preset test case corresponding to a function to be tested in the test branch; establishing communication with a client deployed on the test branch; wherein the client stores multiple memory objects; executing the preset test case to control the client to perform the following operations: based on the binding relationship between the multiple memory objects, searching for a target memory object related to the function to be tested in the test branch from the client, calling a function bound to the target memory object, and executing the function to be tested through the function; wherein the memory object includes at least one of the following: a user account logged into the client, executable behavior of the user account, virtual resources related to the user account, and virtual scenes related to the user account; and determining a test result based on the data generated by executing the function to be tested.

[0007] Secondly, embodiments of this disclosure provide a smoke testing apparatus, comprising: a test branch determination module configured to determine a test branch and a preset test case corresponding to the test branch in response to a smoke test trigger event; the preset test case corresponds to the function to be tested of the test branch; a communication establishment module configured to establish communication with a client deployed on the test branch; wherein the client stores multiple memory objects; and a client control module configured to execute the preset test case to control the client to perform the following operations: based on the binding relationship between the multiple memory objects, searching for a target memory object related to the function to be tested of the test branch from the client, calling a function bound to the target memory object, and executing the function to be tested through the function; wherein the memory object includes at least one of the following: a user account logged into the client, executable behavior of the user account, virtual resources related to the user account, and virtual scenes related to the user account; and determining the test result based on the data generated by executing the function to be tested.

[0008] Thirdly, embodiments of the present invention provide an electronic device, including a processor and a memory, wherein the memory stores machine-executable instructions that can be executed by the processor, and the processor executes the machine-executable instructions to implement the above-described smoke test method.

[0009] Fourthly, embodiments of the present invention provide a machine-readable storage medium storing machine-executable instructions. When the machine-executable instructions are invoked and executed by a processor, the machine-executable instructions cause the processor to implement the aforementioned smoke test method.

[0010] The embodiments of the present invention bring the following beneficial effects:

[0011] The aforementioned smoke testing method, apparatus, electronic device, and storage medium, in response to a smoke test trigger event, determine a test branch and its corresponding preset test cases; the preset test cases correspond to the functions to be tested within the test branch; establish communication with a client deployed on the test branch; wherein the client stores multiple memory objects; execute the preset test cases to control the client to perform the following operations: based on the binding relationships between the multiple memory objects, locate the target memory object related to the function to be tested in the test branch from the client, call the function bound to the target memory object, and execute the function to be tested through the function; determine the test result based on the data generated by the function execution. In this method, by controlling the client to call the function bound to the memory object related to the function to be tested to execute the function to be tested, and then by using the data generated during execution, it is possible to determine whether the function to be tested can be implemented normally, thus achieving smoke testing of the code.

[0012] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objects and other advantages of this disclosure are realized and obtained through the structures particularly pointed out in the description, claims and drawings.

[0013] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the specific embodiments of this disclosure or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0015] Figure 1 is a flowchart of a smoke test method provided in one embodiment of the present disclosure;

[0016] Figure 2 is a flowchart of another smoke test method provided in one embodiment of the present disclosure;

[0017] Figure 3 is a flowchart of another smoke test method provided in one embodiment of the present disclosure;

[0018] Figure 4 is a functional block diagram of a continuous delivery device based on automated smoke testing provided in one embodiment of this disclosure;

[0019] Figure 5 is a functional block diagram of a continuous integration unit provided in one embodiment of the present disclosure;

[0020] Figure 6 is a functional block diagram of a smoke test unit provided in one embodiment of the present disclosure;

[0021] Figure 7 is a schematic diagram of a smoke testing device provided in one embodiment of the present disclosure;

[0022] Figure 8 is a schematic diagram of the structure of an electronic device provided in one embodiment of this disclosure. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0024] Continuous delivery is a software development practice where developers frequently integrate code into a code repository to reduce development cycles and risks. The main purpose of continuous delivery is to enable development teams to deliver high-quality software frequently to meet customer needs and respond quickly to feedback. However, as software development teams grow, if a code commit has a problem that affects the normal operation of other software functions, it will inevitably impact the normal development, testing, and acceptance processes of other related technical personnel, affecting the overall efficiency of the team.

[0025] In traditional software development, a common solution is to perform basic verification after developers submit their code. This includes verifying the basic correctness of interfaces or checking the functionality of basic features by clicking on the UI. This type of verification is collectively known as smoke testing. The core purpose of smoke testing is to verify the basic functionality of the software, not to comprehensively test every single feature. Integrating smoke testing into continuous delivery is a common solution to ensure the correctness of basic software functions, but its application in game projects still presents some challenges:

[0026] 1. Traditional software interface smoke tests and UI smoke tests cannot meet the testing requirements of some software's basic functions. Many basic functions cannot be verified by running and verifying them through interface calls and UI clicks.

[0027] 2. The game project involves multiple branch versions, and traditional smoke testing cannot effectively cover the testing needs of all branch versions;

[0028] 3. Traditional smoke testing in continuous delivery only focuses on functional correctness, but when a problem occurs, it is not possible to quickly locate the person responsible for the problem.

[0029] Based on this, the present disclosure provides a smoke testing method, apparatus, electronic device, and storage medium, which can be applied to scenarios requiring smoke testing.

[0030] In one possible implementation, this disclosure provides a smoke test method. As shown in FIG1, the method includes the following steps:

[0031] Step S102: In response to the smoke test trigger event, determine the test branch and the preset test cases corresponding to the test branch; the preset test cases correspond to the functions to be tested in the test branch.

[0032] The smoke test trigger events described above can be of various types. For example, a user can send a test request to the test server via a terminal device, thereby generating a smoke test trigger event. Since smoke tests are typically performed on newly generated code, a user can submit code data to a data storage server that stores the code data and then send a test request for that code data. The test server retrieves the code data from the data storage server and performs a smoke test on the code data.

[0033] The smoke test trigger event mentioned above can also be a code commit event that is detected and confirmed to have been successfully committed. A module for listening to code commit events can be pre-configured on a designated server. Once the designated server detects a code commit event and confirms a successful commit, it sends a notification message to the test server. Upon receiving the notification message from the designated server, the test server determines that a smoke test trigger event has occurred. Users typically commit code to the designated server, thus allowing the server to listen for code commit events.

[0034] The test server needs to update the client based on the submitted code, therefore it needs to retrieve the submitted code. Since the server storing different versions of the code contains a large amount of data and requires high confidentiality, it's difficult to grant access to the test server directly. Therefore, the code to be smoke-tested can be sent to a data storage server. The data storage server can be an open database. The test server retrieves the code to be smoke-tested from the data storage server and then updates the client accordingly.

[0035] In practical applications, software projects typically involve multiple branch versions, such as development branches (also known as "development versions"), test branches (also known as "test versions"), and release branches (also known as "release versions"). Different versions have corresponding code. For different branches, corresponding clients are usually deployed. When smoke testing of code data from a specific branch is required, a server needs to be specified to listen for that version's code data.

[0036] For ease of reference, the version of code data that needs to be monitored is referred to as a test branch. Typically, a test branch is set up on a designated server. When the designated server detects a commit event for the code data on the test branch, and the commit event indicates a successful commit, it sends a notification message to the test server. If the designated server is also the server that stores the code data, the test branch's code data can also be sent to a data storage server. This allows the test server to retrieve the test branch's code data from the data storage server and update the client corresponding to the test branch based on the code data.

[0037] Step S104: Establish communication with the client deployed on the test branch; wherein the client stores multiple memory objects.

[0038] If a smoke test is triggered, communication with the client deployed on the test branch is required. When there are multiple branches and corresponding clients deployed on each branch, the client corresponding to the test branch needs to be identified as the target client, and communication with the target client needs to be established.

[0039] Remote procedure calls can typically be established between the client and the server. When used in a Python environment, Remote Procedure Call (RPC) is supported by rpyc (Remote Python Call). In a RPC, the test server acts as the client, and the client acts as the server.

[0040] Taking game software as an example, in the client, game-related data can be stored using memory objects. Memory objects typically indicate: the user account logged into the client, the user account's executable actions, virtual resources associated with the user account, and virtual scenes associated with the user account. Correspondingly, memory objects can be categorized into user objects, action objects, resource objects, scene objects, etc. Memory objects usually have relationships with each other. Generally, data related to the user account is bound to the corresponding user object in the form of a memory object. When the corresponding data is needed or the corresponding function is called, the search for the required memory object usually starts from the binding relationship of the user object. This data storage method is common in game clients, etc.

[0041] Step S106: Execute preset test cases to control the client to perform the following operations: Based on the binding relationship between multiple memory objects, find the target memory object related to the function to be tested in the test branch from the client, call the function bound to the target memory object, and execute the function to be tested through the function; wherein, the memory object includes at least one of the following: the user account logged into the client, the executable behavior of the user account, the virtual resources related to the user account, and the virtual scene related to the user account.

[0042] It can execute preset test cases and control the client to execute the function under test via remote procedure call communication. The function under test usually involves multiple memory objects. The memory objects involved can be user objects of the logged-in client account, or various other memory objects as described above that are directly or indirectly bound to the user object.

[0043] Memory objects can be bound in various forms, such as linked structures and tree structures. The specific binding method can be configured according to requirements and is not limited here. When locating the target memory object related to the function to be tested in the test branch, the identifier of the target memory object can usually be obtained from the test case. Then, the relevant data of the target memory object can be found through this identifier and the binding relationship of memory objects in the client. After locating the memory object, the function bound to the target memory object needs to be called to execute the function to be tested.

[0044] Step S108: Determine the test results based on the data generated by the function to be tested during function execution.

[0045] During the execution of the function being tested, a large amount of data is typically generated. This data can indicate whether errors occurred during the execution of each called function, and whether the relevant parameters of the user object changed after the function execution.

[0046] If an error occurs during function execution and the changes in the relevant parameters of the user object do not conform to expectations, the test result can be considered a failure. If the function executes normally and the changes in the relevant parameters of the user object conform to expectations, the test result can be considered a success.

[0047] To determine whether changes in relevant parameters of a user object meet expectations, test cases can pre-define expected results. These expected results are typically values ​​determined by the testers who wrote the test cases, assuming the function under test will function correctly. When calculating expected results, testers usually use some business data. For example, if the function under test is to upgrade a user, assuming a correlation between user level and user points; the specific function tested by the test case is to upgrade the user to level 5, and a level 5 user should have 50 points. If the data generated during the execution of the function under test indicates that the final user points become 50, then the test is successful. The aforementioned user points of 50 are considered an expected result.

[0048] In some cases, user points for each level may already be stored on the client side as business data. During user upgrades, the client uses this stored business data to determine the upgraded user points. Instead of pre-calculating the expected results, test cases read the user points corresponding to the user level of the function under test from the client and use them as the expected results. This approach does not affect the accuracy of the test results even if there are inconsistencies between the business data obtained by the client and the testers.

[0049] The data generated during the execution of the function under test can be saved and used to generate log files during the execution process. After the function under test is executed, the log files are parsed, and error information is extracted from the parsing results. Based on the error information, the test result is determined. If there is error information, the test result is considered a failure.

[0050] The aforementioned smoke testing method, in response to a smoke test trigger event, determines a test branch and its corresponding preset test cases. The preset test cases correspond to the functionality to be tested within the test branch. Communication is established between the test branch and the client deployed on it. The client stores multiple memory objects. The preset test cases are executed to control the client to perform the following operations: based on the binding relationships between the multiple memory objects, the target memory object related to the functionality to be tested within the test branch is located in the client; the function bound to the target memory object is called; and the functionality to be tested is executed through the function. Based on the data generated during the execution of the functionality to be tested, the test result is determined. This method controls the client to call the function bound to the memory object related to the functionality to be tested, thereby determining whether the functionality to be tested can be implemented correctly through the data generated during execution, thus achieving smoke testing of the code.

[0051] The following examples provide a specific method for establishing communication between a client deployed on a test branch.

[0052] The above method is typically used in test servers. When testing a function, the test server needs to establish a remote procedure call (RPC) with the client. In RPC, the server provides a set of remotely callable functions or procedures, and the client invokes these functions or procedures by sending requests to the server. The server executes the request and returns the result to the client. This mechanism allows the client to invoke functions on a remote server as if they were local functions, without needing to concern itself with the underlying network communication details. In a remote procedure call, the test server acts as the client, and the client acts as the server.

[0053] In some cases, the test server also communicates with a designated server. This designated server listens for commit events of the test branch's code data and sends a notification message to the test server upon successful commit. When the test server receives the notification message from the designated server, it determines that a smoke test has been triggered. Further, the test server needs to obtain the test branch's code data and update the clients deployed on the test branch based on this data. The updated clients can then be used to test the functionality to be tested within the code.

[0054] In practice, the continuous integration tool Jenkins can be used to listen for code commit events. When relevant personnel commit the latest code to the repository, the designated server with Jenkins deployed will automatically pull the latest package from Git (an open-source distributed version control system) / SVN (short for subversion, an open-source version control system), and then redeploy it, so that the latest code can be used during testing.

[0055] The following embodiments provide a specific method for processing response data through a preset first data processing logic if the processing result indicates that the asynchronous request to the target failed to respond.

[0056] The aforementioned memory objects typically refer to the user object of the logged-in client's user account and several other memory objects bound to it. For ease of reference, these other memory objects will be referred to as first memory objects. First memory objects can be behavior objects, resource objects, and scene objects. The user object and multiple first memory objects are bound in a tree structure; the user object is the root node of this tree structure.

[0057] Behavior objects are used to implement business behaviors of user accounts, such as sending remote call requests to the server. Resource objects can store data related to the resources owned by the user account. Scene objects typically store information about virtual scenes that the user can enter or has already entered. This virtual scene could be a virtual business lobby, etc.

[0058] When the client is a game client, behavior objects are typically called component objects, and resource objects are typically called item objects. Component objects are used to implement executable game behaviors for the game account, or for game behaviors that virtual characters controlled by the game account can execute, such as jumping or skill activation. Item objects are used to store data about game items associated with the game account. Scene objects include data about the game scene associated with the game account.

[0059] During the execution of the function to be tested, the user object needs to be located first from the client; then, based on the user object and its tree structure, the target memory object is located from the client using a pre-defined reflection mechanism. There can be multiple target memory objects related to the function under test, or just one; this is not restricted. The Java reflection mechanism allows, at runtime, the invocation of any method and property of any object; this ability to dynamically obtain information and dynamically invoke object methods is called the reflection mechanism of the Java language.

[0060] The following embodiments provide a specific method for processing response data through a preset first data processing logic if the processing result indicates that the asynchronous request to the target failed to respond.

[0061] For example, in game software, the configuration parameters of in-game values, scenes, and items are all controlled through configuration tables. All game configuration tables are converted from raw Excel files into specified Python files, also known as configuration table files. These configuration table files are usually pre-saved on the client side. The data stored in this file is called configuration table data, which indicates the configuration parameters of memory objects. Configuration parameters must indicate at least one of the following: the identifier, attributes, and effects of the memory object. Identifiers can be IDs, names, icon references, etc.; attributes typically indicate the type of memory object; effects typically indicate the impact on user objects when the memory object is applied to them. In some cases, attributes also include effects.

[0062] Since the configuration table data is the actual data applied to the client, directly obtaining the configuration table data is more realistic and reliable than querying configuration parameters and writing them into test cases. Therefore, it is usually necessary to control the client to parse the configuration table file to obtain the configuration table data, and then obtain the configuration parameters of the memory object from the configuration table data.

[0063] The expected result of a function under test can be determined based on the configuration table data of the target memory object associated with the function under test. For example, if a user object's lifespan is 100, and a virtual item is added to the user object during the execution of the function under test, the user object's lifespan should be added to the lifespan that the virtual item can add when the function works correctly. In the configuration table data, the virtual item can add 50 lifespans, so 100 + 50 = 150, and 150 is the expected result. If the user object's lifespan is 150 after the test case is executed, matching the expected result, the test is considered successful. If the user object's lifespan is any other value, the test is considered a failure. In other words, the test result can be determined based on the data generated by the function execution and the expected result.

[0064] For subsequent data analysis, during the execution of the function under test by the client, the test server acquires the data generated by the execution of the function under test and generates a log file based on the acquired data. This log file is used to store the data generated by the function execution of the function under test. Besides errors in the execution result of the function under test, errors such as interruption or freezing may also occur during the execution of the function under test. When these situations occur, error messages are usually generated. The test server can parse the log file, extract the error messages from the parsing results, and then determine the test result based on the error messages. If no error messages are extracted, it is determined that the aforementioned test errors did not occur.

[0065] This disclosure also provides another smoke testing method. This method is implemented based on the method shown in Figure 1. This method provides a testing approach that can ensure the reliability of game software versions during continuous integration development.

[0066] This method uses a continuous integration unit (CIU) to mark development branch repositories that need monitoring, obtains commit information for each step via SVN hooks, and stores it in Redis. An SVN hook is a script or program automatically invoked after an SVN operation (such as commit, update, merge, etc.) is completed. The CIU listens to the result of each commit. If the commit is successful, it triggers a smoke test task deployed on the Jenkins CIU tool. The smoke test task automatically updates the project repository on the deployment device, and after the update is complete, it starts the smoke test unit (usually set up in the aforementioned "test server"). The smoke test unit automatically starts the client for that branch and completes the login process. The smoke test unit connects to the client via RPYC and executes pre-set test cases. The test cases communicate via RPYC to drive the client code to execute basic functions and record execution logs. After execution, the smoke test unit analyzes the execution logs to obtain error information. If error information is found, the test result is failure; otherwise, it is success. The smoke test unit retrieves commit information from the commit logs in Redis and returns the test results to the CIU. If the smoke test succeeds, the continuous integration tool Jenkins will execute subsequent tasks; if the smoke test fails, the continuous integration unit will notify the submitter of the error message and terminate the Jenkins task.

[0067] The continuous integration unit in the above method is responsible for marking the branch repositories that need to be monitored, obtaining commit information, triggering smoke test tasks, and performing subsequent steps based on the smoke test results. The smoke test unit is responsible for executing pre-set test case sets according to different branch repositories, collecting execution log information, and returning test results.

[0068] The continuous delivery process based on automated smoke testing, as shown in Figure 2, mainly includes the following steps:

[0069] 1. Mark the branch repositories that need to be monitored in the continuous integration unit.

[0070] Large projects typically have different development branches, such as development branches, test branches, and release branches. These branches need to be pre-marked for version reliability monitoring. Branch monitoring is achieved through the SVN hooks plugin. Upon successful branch commit, the plugin's configuration sends the commit information as data to the continuous integration unit (CIU), which then controls the monitoring.

[0071] 2. Monitor the commit status of the continuous integration unit and store the commit information in Redis.

[0072] The continuous integration unit receives commit information from the SVN Hook (also known as the "SVN plugin") plugin, determines whether it is a pre-set branch that needs to be monitored, and if so, stores the branch information in Redis and triggers subsequent steps.

[0073] 3. The continuous integration unit triggers the Jenkins smoke test task.

[0074] The continuous integration unit triggers the smoke test task configured on the continuous integration tool Jenkins and passes the commit information as a startup parameter to the smoke test task.

[0075] 4. The smoke test task is executed to update the committed branch repository.

[0076] Smoke test tasks on Jenkins involve multiple execution steps, specifically including:

[0077] Update the local repository of that branch on the task deployment device based on the submitted commit information;

[0078] The submitted information is used as an execution parameter to start the smoke test unit;

[0079] Collect smoke test results and pass them to the continuous integration unit.

[0080] 5. The smoke test task receives the submission information as the execution parameter and starts the smoke test unit.

[0081] Similar to step 4 above, this is an execution step of the smoke testing task. This step passes the commit message as an execution parameter to the smoke testing unit, thus starting the smoke testing unit. The commit message must contain the commit branch; the smoke testing unit uses the branch to determine and execute test cases.

[0082] 6. The smoke test unit executes the startup of the branch client and logs in.

[0083] After the smoke test unit starts, it will first start the specified branch to deploy the local client in the smoke test unit according to the passed branch information, and then automatically execute the login script to complete the login process.

[0084] 7. The smoke test unit connects to the client via RPYC and executes preset test cases.

[0085] After logging in, the smoke test unit connects to the client via RPYC. RPYC is a Python remote procedure call library that allows different Python processes to communicate and remotely invoke functions. This step requires the client to also have RPYC installed and act as an RPYC server. The smoke test unit then connects to this RPYC server as a client. Once the connection is successful, the smoke test unit will execute a pre-defined set of test cases according to different branches.

[0086] 8. Test cases verify basic functionality using RPYC-driven client code and record execution logs.

[0087] The test cases in the smoke test unit are actually scripts containing a set of client-side code. These scripts execute basic functions according to the pre-defined client-side code. While executing these functions, the test case scripts record execution logs, which are stored in a log file. This log includes successful execution logs and error messages for failed executions.

[0088] 9. Analyze the execution log of the smoke test unit to obtain error information.

[0089] After the test cases are executed, the smoke test unit analyzes the execution logs of the test cases and extracts the error information.

[0090] 10. The smoke test unit returns the test results to the continuous integration unit.

[0091] If an error message is present, the smoke test fails, and the smoke test unit returns the error message and execution failure as the result to the continuous integration unit. If no error message is present, the smoke test succeeds, and the smoke test unit returns the execution success message and an empty error message as the result to the continuous integration unit. Simultaneously, the smoke test unit shuts down the client process.

[0092] 11. The continuous integration unit will notify the submitter of the results.

[0093] After receiving the smoke test results, the continuous integration unit notifies the submitter who triggered the task. If the test result is successful, the submitter is notified of a successful submission; if the test result is a failure, the submitter is notified of a submission failure and sent with an error message, which they are responsible for fixing.

[0094] 12. The continuous integration unit performs subsequent steps based on the smoke test results.

[0095] When the smoke test fails, the continuous integration unit terminates the Jenkins task and will not execute subsequent continuous integration tasks; when the smoke test succeeds, subsequent continuous integration tasks will be executed.

[0096] In this invention, SVN hooks plugins are used to detect and obtain commit information from the SVN repository, triggering the execution of a smoke test task via Jenkins. The smoke test unit executes pre-set test cases for different branches based on the commit information, satisfying the different basic functional requirements of each branch. Simultaneously, the smoke test unit uses RPYC to drive client execution, thus performing more thorough, comprehensive, and stable basic functional testing. Through smoke testing, the continuous integration system quickly provides feedback on the verification of basic functions to the committer, effectively ensuring the reliability of the submitted version.

[0097] Figure 3 is a functional block diagram of the continuous delivery device based on automated smoke testing provided by the present invention. The device includes:

[0098] Continuous Integration Unit 201, primarily responsible for the following functions:

[0099] 1. Monitor commits for specified branch repositories and record commit information;

[0100] 2. Start the smoke test unit;

[0101] 3. Based on the smoke test results, notify the submitter to execute or terminate the continuous integration steps.

[0102] The smoke test unit 202 is primarily responsible for the following functions:

[0103] 1. Start and log in to the local client of the specified branch;

[0104] 2. Connect to the client and execute the specified test cases;

[0105] 3. Collect test case execution logs and return the test results to the continuous integration unit.

[0106] Figure 4 is a functional block diagram of the continuous integration unit 201, which includes:

[0107] 2011. SVN Plugin Module: The main function of this module is to enable continuous integration units to detect commits in SVN branch repositories, thereby performing necessary analysis and processing on the current commit. This module's implementation relies on SVN's built-in hook configuration capabilities. Its core function is to provide callbacks before or after SVN commits; by configuring hooks triggered after a commit, we can detect when a commit has occurred in the branch repository.

[0108] 2012, Redis Read / Write Module: The main function of this module is to store commit information, so that various modules in the continuous integration unit can retrieve the required data when needed. Redis, as a widely used in-memory database, has high read and write speeds, which helps the unit quickly complete overall testing tasks.

[0109] 2013, Jenkins Module: The main function of this module is to orchestrate the continuous integration task pipeline, making the entire continuous integration process more organized and controllable. Within the continuous integration unit, the smoke test task is the first stage of all continuous integration pipelines after a branch commit. When the smoke test task fails, we can leverage Jenkins' features to terminate the current task pipeline, preventing subsequent steps from being executed, thereby improving the efficiency of continuous delivery.

[0110] 2014. Information Notification Module: The main function of this module is to collect the results of smoke tests and then notify the responsible person. This module offers many options, such as notifications and alerts via SMS, email, or instant messaging software.

[0111] This method uses the SVN hooks plugin to quickly detect SVN repository commits and stores the commit information in Redis, ensuring the flow of commit information within the unit. The Jenkins module ensures the management of the continuous integration pipeline, making it easy to control the execution and termination of the entire pipeline through the results of smoke tests.

[0112] Figure 5 is a functional block diagram of the smoke test unit 202, which includes:

[0113] 2021. Client Process Management Module: The main function of this module is to manage the start and stop of client processes. When the smoke test unit is started, this module will start the corresponding branch client on the local deployment device according to the passed branch information; when the smoke test ends, it will also shut down the started client.

[0114] 2022. Login Module: The main function of this module is to automatically complete the login process after the game starts. The game client needs to log in to experience the game's content, and different branch environments require logging into different corresponding servers to properly experience the game. Therefore, this module will log in to a pre-set test account and, based on the passed branch information, log in to the specified server to test and verify the functionality.

[0115] 2023. Test Case Management Module: The main functions of this module are to establish an RPYC communication connection with the client, manage test cases, and record test case execution logs. Since different branches focus on different basic functions, they will have different test cases. This module will execute the corresponding preset test cases based on the passed branch information. Simultaneously, this module will record test case execution logs for subsequent smoke test result analysis.

[0116] 2024. Log Analysis Module: The main function of this module is to analyze and collect error information in the logs after the test cases are executed, and return the results of the smoke test to the continuous integration unit based on whether there are error information.

[0117] This method manages and allocates test cases for different branches, satisfying the testing requirements of different branches for different basic functions. Furthermore, by using RPYC to drive client code, it provides more comprehensive and thorough coverage of basic functional testing, making it more suitable for functional verification of game software compared to traditional interface and UI testing.

[0118] Figure 6 is a schematic diagram of the test case management module in the smoke test unit. Since the verification of basic game functions requires testing only a small portion of them through user input (such as movement, skill release, UI clicks, etc.), many other functions cannot be tested through simulated input (such as buff effects, scene changes, unit creation and destruction, etc.). To meet the verification needs of these functions, this solution proposes to establish a test case module that drives the client code based on the characteristics of RPYC cross-process communication. The specific implementation is as follows:

[0119] First, the client acts as the RPYC server during the testing phase, listening on a designated port after the game starts. The test case management module in the smoke test unit acts as the RPYC client, connecting to the game via IP and port. Through this established communication, the smoke test unit can call all modules within the game and execute the corresponding code. However, simply calling in-game code modules does not meet the requirements of functional testing; there are two main issues:

[0120] Question 1: How can we determine whether the numerical changes after in-game testing meet expectations? For example, if a character's stats change after acquiring a certain item, how can the test cases determine if this change is correct?

[0121] Question 2: Simply calling in-game code modules to create objects and execute code will not have any actual effect. This is because the functions in the game are bound to the already created memory objects in the form of components. Even if we create new objects, they will not have any effect on the existing memory objects.

[0122] To address these two main problems, the method employs the following approach:

[0123] Regarding question 1 above: Since in-game values, scenes, and items are all controlled through data tables, for example, there are many types of items in the game, each with different names, effects, and types. From a code perspective, an item is actually an item class, with attributes such as name, effect, and type. The specific attributes of a particular item are controlled by the item table. All the game's data tables are converted from original Excel files into specified Python files, containing compressed data table objects. These Python files containing data table objects are referenced in the game as code modules. Therefore, this smoke test unit also uses these data table objects to obtain complete numerical information. One advantage of obtaining data in this way is that the numerical information is always up-to-date, which is more timely and accurate compared to hardcoding values ​​in the test case code.

[0124] After obtaining complete data table information, the test case code compares the numerical changes before and after implementing the test case operation with the results calculated using the data table information. If they match, the numerical changes are as expected; otherwise, a numerical inconsistency error is thrown.

[0125] Regarding question 2 above: Since we need to test specific objects in memory, the primary goal is to locate those objects. In smoke testing, the most crucial objects to locate are the current user object and the current scene object, which are sufficient to meet the basic functional testing requirements. Here, we utilize Python's memory management mechanism. In the Python interpreter, objects are managed through a memory pool, and they are destroyed when no longer referenced. The user object is one of the most fundamental objects in the game, referenced by all bound component objects. As long as the game process exists, this object will not be destroyed and will always exist in the memory pool. In this solution, we locate the player class's memory object in the memory pool, use reflection to locate other related module objects, and then use module object reflection to locate other objects, such as item objects and buff objects.

[0126] After locating the specified test object, the function bound to that object is called to drive the game to perform the specified functions for testing and verification.

[0127] In the test case management module of the smoke test unit, based on RPYC communication, we first obtain the latest data information by reading and parsing the configuration table. Then, we locate the player class object in memory through the memory pool and, based on the tree-like relationship of the object's references in memory, locate other related objects. After locating the memory object required for testing, we call the object's function methods to test the game functionality. By comparing the tested values ​​with the results calculated from the data read from the configuration table, we can verify the correctness of the values. This testing method is more suitable for game testing scenarios than testing based solely on user input.

[0128] Compared to other existing solutions, this method monitors multiple development branches and records commit information for each monitored branch to pinpoint the responsible party. When a commit occurs, the smoke testing unit executes pre-defined test cases according to the branch. These test cases communicate with the client via RPYC to drive the game's execution of functional code, covering fundamental functions that cannot be covered by interface testing or UI testing, thus achieving smoke testing that is more suitable for game software. When a smoke test fails, the responsible party is directly identified based on the commit information, thereby accelerating the fix of the problematic branch version and ensuring version reliability.

[0129] For the above method embodiments, refer to Figure 7 for a smoke testing device, which includes:

[0130] The test branch determination module 702 is configured to determine the test branch and the corresponding preset test cases in response to the smoke test trigger event; the preset test cases correspond to the functions to be tested in the test branch.

[0131] The communication establishment module 704 is configured to establish communication with the client deployed on the test branch; the client stores multiple memory objects.

[0132] The client control module 706 is configured to execute preset test cases to control the client to perform the following operations: based on the binding relationship between multiple memory objects, find the target memory object related to the function to be tested in the test branch from the client, call the function bound to the target memory object, and execute the function to be tested through the function; wherein, the memory object includes at least one of the following: the user account logged into the client, the executable behavior of the user account, the virtual resources related to the user account, and the virtual scene related to the user account;

[0133] The test result determination module 708 is configured to determine the test result based on the data generated by the function execution of the function to be tested.

[0134] The aforementioned smoke testing device, in response to a smoke test trigger event, determines a test branch and its corresponding preset test cases; the preset test cases correspond to the functions to be tested within the test branch; communication is established between the device and a client deployed on the test branch; wherein the client stores multiple memory objects; the preset test cases are executed to control the client to perform the following operations: based on the binding relationships between the multiple memory objects, the target memory object related to the function to be tested within the test branch is located in the client, the function bound to the target memory object is called, and the function to be tested is executed through the function; the test result is determined based on the data generated by the function execution. This method, by controlling the client to call the function bound to the memory object related to the function to be tested to execute the function, allows for the determination of whether the function to be tested can be implemented normally based on the data generated during execution, thus achieving smoke testing of the code.

[0135] The aforementioned memory objects include user objects of the user account logged into the client and multiple first memory objects; the first memory objects are at least one of the following: behavior objects, resource objects, and scene objects; the user objects and multiple first memory objects are bound in a tree structure; the user objects are the root nodes of the tree structure; the client control module is also configured to: search for user objects from the client; and search for target memory objects related to the function to be tested in the test branch from the client based on the user objects and the tree structure through a preset reflection mechanism.

[0136] The aforementioned client stores a configuration file; the configuration file includes configuration data for multiple memory objects; the aforementioned device further includes: a configuration data parsing module, configured to control the client to parse the configuration file to obtain configuration data; the configuration data includes configuration parameters for memory objects; the configuration parameters are used to indicate at least one of the following: the identifier, attributes, and effects of the memory objects.

[0137] The aforementioned test result determination module is also configured to: determine the expected result corresponding to the function under test based on the table data of the target memory object related to the function under test; and determine the test result based on the data generated by the function under test and the expected result.

[0138] The aforementioned apparatus includes a test server; the communication establishment module is further configured to: establish a remote procedure call between the test server and the client; in the remote procedure call, the test server acts as the client and the client acts as the server.

[0139] The aforementioned apparatus includes a test server and a designated server; the test server and the designated server are connected in communication; the designated server is configured to: listen for commit events of code data in the test branch, and send a notification message to the test server after the commit event results in a successful commit; the aforementioned apparatus further includes: a smoke test determination module, configured to determine that a smoke test trigger event has occurred in response to the test server receiving the notification message sent by the designated server; and a client update module, configured to allow the test server to obtain the code data of the test branch and update the client deployed on the test branch based on the code data.

[0140] The aforementioned test result determination module is also configured to: acquire data generated during the execution of the function to be tested on the client side, generate a log file based on the acquired data, parse the log file, extract error information from the parsing results, and determine the test result based on the error information.

[0141] This embodiment also provides an electronic device, including a processor and a memory. The memory stores machine-executable instructions that can be executed by the processor. The processor executes the machine-executable instructions to implement the above-described smoke test method, for example:

[0142] In response to the smoke test trigger event, determine the test branch and its corresponding preset test cases; the preset test cases correspond to the functions to be tested in the test branch; establish communication with the client deployed on the test branch; wherein, the client stores multiple memory objects; execute the preset test cases to control the client to perform the following operations: based on the binding relationship between the multiple memory objects, find the target memory object related to the function to be tested in the test branch from the client, call the function bound to the target memory object, and execute the function to be tested through the function; determine the test result based on the data generated by the function execution of the function to be tested.

[0143] The above method controls the client to call the function bound to the memory object related to the function under test to execute the function under test. Then, the data generated during the execution can be used to determine whether the function under test can be implemented normally, thus realizing smoke testing of the code.

[0144] Optionally, the aforementioned memory objects include a user object representing a user account logged into the client and multiple first memory objects; the first memory objects are at least one of the following: behavior objects, resource objects, and scene objects; the user object and multiple first memory objects are bound in a tree structure; the user object is the root node of the tree structure; the step of searching for the target memory object related to the function to be tested in the test branch from the client based on the binding relationship between the multiple memory objects includes: searching for the user object from the client; and searching for the target memory object related to the function to be tested in the test branch from the client based on the user object and the tree structure using a preset reflection mechanism.

[0145] Optionally, the client saves a configuration file; the configuration file includes configuration data for multiple memory objects; the method further includes: controlling the client to parse the configuration file to obtain configuration data; the configuration data includes configuration parameters for memory objects; the configuration parameters are used to indicate at least one of the following: the identifier, attributes, and effects of the memory object.

[0146] Optionally, the steps for determining the test result based on the data generated by the function execution of the function to be tested include: determining the expected result corresponding to the function to be tested based on the table data of the target memory object related to the function to be tested; and determining the test result based on the data generated by the function execution of the function to be tested and the expected result.

[0147] Optionally, the above method includes a test server; the step of establishing communication between the test server and the client deployed on the test branch includes: the test server establishing a remote procedure call with the client; in the remote procedure call, the test server acts as the client and the client acts as the server.

[0148] Optionally, the above method includes a test server and a designated server; the test server and the designated server communicate with each other; the designated server is used to: listen for commit events of code data in the test branch, and send a notification message to the test server after the commit result of the commit event is successful; the method further includes: the test server responding to the notification message sent by the designated server to determine that a smoke test trigger event has occurred; the test server obtaining the code data of the test branch and updating the client deployed on the test branch based on the code data.

[0149] Optionally, the steps for determining the test result based on the data generated by the function execution of the function to be tested include: obtaining the data generated by the execution of the function to be tested during the process of the client executing the function to be tested based on the function, generating a log file based on the obtained data; parsing the log file and extracting error information from the parsing results; and determining the test result based on the error information.

[0150] Referring to Figure 8, the electronic device includes a processor 100 and a memory 101. The memory 101 stores machine-executable instructions that can be executed by the processor 100. The processor 100 executes the machine-executable instructions to implement the smoke test method described above.

[0151] Furthermore, the electronic device shown in Figure 8 also includes a bus 102 and a communication interface 103, with the processor 100, the communication interface 103, and the memory 101 connected via the bus 102.

[0152] The memory 101 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 103 (which can be wired or wireless), such as the Internet, wide area network, local area network, or metropolitan area network. The bus 102 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only a single bidirectional arrow is used in Figure 8, but this does not indicate that there is only one bus or one type of bus.

[0153] The processor 100 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 100 or by instructions in software form. The processor 100 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this disclosure can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 101, and the processor 100 reads the information in memory 101 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments.

[0154] This embodiment also provides a machine-readable storage medium storing machine-executable instructions. When the machine-executable instructions are called and executed by the processor, the machine-executable instructions cause the processor to implement the above-described smoke test method.

[0155] The smoke testing method, apparatus, and electronic device provided in this disclosure include a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments, for example:

[0156] In response to the smoke test trigger event, determine the test branch and its corresponding preset test cases; the preset test cases correspond to the functions to be tested in the test branch; establish communication with the client deployed on the test branch; wherein, the client stores multiple memory objects; execute the preset test cases to control the client to perform the following operations: based on the binding relationship between the multiple memory objects, find the target memory object related to the function to be tested in the test branch from the client, call the function bound to the target memory object, and execute the function to be tested through the function; determine the test result based on the data generated by the function execution of the function to be tested.

[0157] The above method controls the client to call the function bound to the memory object related to the function under test to execute the function under test. Then, the data generated during the execution can be used to determine whether the function under test can be implemented normally, thus realizing smoke testing of the code.

[0158] Optionally, the aforementioned memory objects include a user object representing a user account logged into the client and multiple first memory objects; the first memory objects are at least one of the following: behavior objects, resource objects, and scene objects; the user object and multiple first memory objects are bound in a tree structure; the user object is the root node of the tree structure; the step of searching for the target memory object related to the function to be tested in the test branch from the client based on the binding relationship between the multiple memory objects includes: searching for the user object from the client; and searching for the target memory object related to the function to be tested in the test branch from the client based on the user object and the tree structure using a preset reflection mechanism.

[0159] Optionally, the client saves a configuration file; the configuration file includes configuration data for multiple memory objects; the method further includes: controlling the client to parse the configuration file to obtain configuration data; the configuration data includes configuration parameters for memory objects; the configuration parameters are used to indicate at least one of the following: the identifier, attributes, and effects of the memory object.

[0160] Optionally, the steps for determining the test result based on the data generated by the function execution of the function to be tested include: determining the expected result corresponding to the function to be tested based on the table data of the target memory object related to the function to be tested; and determining the test result based on the data generated by the function execution of the function to be tested and the expected result.

[0161] Optionally, the above method includes a test server; the step of establishing communication between the test server and the client deployed on the test branch includes: the test server establishing a remote procedure call with the client; in the remote procedure call, the test server acts as the client and the client acts as the server.

[0162] Optionally, the above method includes a test server and a designated server; the test server and the designated server communicate with each other; the designated server is used to: listen for commit events of code data in the test branch, and send a notification message to the test server after the commit result of the commit event is successful; the method further includes: the test server responding to the notification message sent by the designated server to determine that a smoke test trigger event has occurred; the test server obtaining the code data of the test branch and updating the client deployed on the test branch based on the code data.

[0163] Optionally, the steps for determining the test result based on the data generated by the function execution of the function to be tested include: obtaining the data generated by the execution of the function to be tested during the process of the client executing the function to be tested based on the function, generating a log file based on the obtained data; parsing the log file and extracting error information from the parsing results; and determining the test result based on the error information.

[0164] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0165] Furthermore, in the description of the embodiments of this disclosure, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this disclosure based on the specific circumstances.

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

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

[0168] Finally, it should be noted that the above embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.

Claims

1. A smoking test method, comprising: determining a test branch and a preset test case corresponding to the test branch in response to a smoking test trigger event; the preset test case corresponding to a function to be tested of the test branch; establishing communication with a client deployed with the test branch; wherein the client stores a plurality of memory objects; executing the preset test case to control the client to perform the following operations: based on the binding relationship between the plurality of memory objects, finding a target memory object related to the function to be tested of the test branch from the client, calling a function bound to the target memory object, and executing the function to perform the function to be tested; wherein the memory object comprises at least one of the following: a user account logged into the client, an executable behavior of the user account, a virtual resource related to the user account, and a virtual scene related to the user account; determining a test result based on data generated by executing the function to perform the function to be tested.

2. The method of claim 1, wherein, The memory object includes a user object of a user account logged into the client and a plurality of first memory objects; the first memory object is at least one of the following: a behavior object, a resource object, and a scene object; the user object and the plurality of first memory objects are bound in a tree structure; the user object is the root node of the tree structure; based on the binding relationship between the plurality of memory objects, finding a target memory object related to the function to be tested of the test branch from the client, comprising: finding the user object from the client; finding the target memory object related to the function to be tested of the test branch from the client based on the user object and the tree structure through a preset reflection mechanism.

3. The method of claim 1, wherein, The client stores a configuration file; the configuration file includes configuration data of the plurality of memory objects; The method further comprises: controlling the client to parse the configuration file to obtain configuration data; the configuration data includes configuration parameters of the memory object; the configuration parameters are used to indicate at least one of the following: the identifier, the attribute, and the effect of the memory object.

4. The method of claim 3, wherein, Based on the data generated by executing the function to perform the function to be tested, determining a test result, comprising: determining an expected result corresponding to the function to be tested based on the configuration data of the target memory object related to the function to be tested; determining a test result based on the data generated by executing the function to perform the function to be tested and the expected result.

5. The method of claim 1, wherein, The method comprises a test server; The step of establishing communication with the client deployed with the test branch comprises: the test server establishes a remote procedure call with the client; in the remote procedure call, the test server acts as a client, and the client acts as a server.

6. The method of claim 1, wherein, The method comprises a test server and a designated server; the test server and the designated server are communicatively connected; the designated server is configured to: listen to a submission event of code data of a test branch, and send a notification message to the test server after a submission result of the submission event is submission success. The method further comprises: The test server determines that a smoke test triggering event occurs in response to receiving the notification message sent by the specified server; The test server acquires code data of the test branch, and updates the client deployed by the test branch based on the code data.

7. The method of claim 1, wherein, The step of determining the test result based on the data generated by executing the function of the to-be-tested function comprises: In the process of executing the to-be-tested function by the client based on the function, data generated by executing the to-be-tested function is acquired, and a log file is generated based on the acquired data; The log file is parsed, and error information is extracted from the parsed result; The test result is determined based on the error information.

8. A smoke test device, the device comprising: A test branch determination module configured to determine a test branch and a preset test case corresponding to the test branch in response to a smoke test triggering event; The preset test case corresponds to a to-be-tested function of the test branch; A communication establishment module configured to establish communication with a client deployed by the test branch; wherein the client stores a plurality of memory objects; A client control module configured to execute the preset test case to control the client to perform the following operations: Based on the binding relationship between the plurality of memory objects, a target memory object related to the to-be-tested function of the test branch is searched from the client, a function bound to the target memory object is called, and the to-be-tested function is executed through the function; wherein the memory object at least includes one of the following: a user account logged into the client, executable behaviors of the user account, virtual resources related to the user account, and virtual scenes related to the user account; A test result determination module configured to determine a test result based on data generated by executing the function of the to-be-tested function.

9. An electronic device comprising a processor and a memory, the memory storing machine executable instructions executable by the processor, and the processor executes the machine executable instructions to implement the smoke test method of any one of claims 1-7.

10. A machine readable storage medium storing machine executable instructions, the machine executable instructions, when invoked and executed by a processor, cause the processor to implement the smoke test method of any one of claims 1-7.

Images