Smoking test method and device, electronic equipment and storage medium

Abstract

The invention provides a smoking test method and device, electronic equipment and a storage medium, and the method comprises the steps: 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 corresponds to a to-be-tested function of the test branch; establishing communication with the client deployed by the test branch; executing the preset test case to control the client to execute the following operations: searching a target memory object related to a to-be-tested function of the test branch from the client based on a binding relationship among the plurality of memory objects, calling a function bound by the target memory object, and executing the to-be-tested function through the function; and determining a test result based on data generated by executing the to-be-tested function by the function. In the mode, the client is controlled to call the function bound with the memory object related to the to-be-tested function to execute the to-be-tested function, so that whether the to-be-tested function can be normally realized or not can be determined through the data generated in the execution process, and the smoking test of the code is realized.

Description

Technical Field

[0001] The present disclosure relates to the field of testing technology, and in particular to a smoke testing method, device, electronic equipment and storage medium. Background Art

[0002] In the software development process, after the developer submits the code, it is necessary to perform basic verification on whether the client can execute basic functions through the code, such as verifying whether the interface is basically correct, or verifying whether the basic functions are normal by clicking on the graphical user interface. This type of verification is collectively referred to as smoke testing. The core purpose of smoke testing is to verify whether the basic functions of the software are normal. However, the business functions corresponding to the code of some software are more complex, and it is difficult to test them using the above-mentioned smoke testing method, so it is impossible to verify whether the code can normally implement the corresponding business functions. Summary of the invention

[0003] In view of this, an object of the present disclosure is to provide a smoke test method, device, electronic device and storage medium to implement smoke testing of code.

[0004] In a first aspect, an embodiment of the present disclosure provides a smoke test method, the method comprising: in response to a smoke test trigger event, determining a test branch and a preset test case corresponding to the test branch; the preset test case corresponds to a function to be tested of the test branch; establishing communication with a client deployed with the test branch; wherein the client saves multiple memory objects; executing the preset test case to control the client to perform the following operations: based on a binding relationship between multiple memory objects, searching the client for a target memory object related to the function to be tested of the test branch, 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 of logging into the client, executable behavior of the user account, virtual resources related to the user account, and virtual scenes related to the user account; determining the test result based on data generated by the function executing the function to be tested.

[0005] In a second aspect, an embodiment of the present disclosure provides a smoke test device, which includes: a test branch determination module, which is used 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, which is used to establish communication with a client deployed with the test branch; wherein the client saves multiple memory objects; a client control module, which is used to execute the preset test case to control the client to perform the following operations: based on the binding relationship between multiple memory objects, search the client for a target memory object related to the function to be tested of the test branch, 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: a user account of logging into the client, executable behavior of the user account, virtual resources related to the user account, and virtual scenes related to the user account; based on the data generated by the function executing the function to be tested, determine the test result.

[0006] In a third aspect, an embodiment of the present invention provides 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-mentioned smoke test method.

[0007] In a fourth aspect, an embodiment of the present invention provides a machine-readable storage medium, which stores machine-executable instructions. When the machine-executable instructions are called and executed by a processor, the machine-executable instructions prompt the processor to implement the above-mentioned smoke test method.

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

[0009] The above-mentioned smoke test method, device, electronic device and storage medium, in response to a smoke test triggering event, determine a test branch and a preset test case corresponding to the test branch; the preset test case corresponds to the function to be tested of the test branch; establish communication with the client deployed with the test branch; wherein the client saves multiple memory objects; executes the preset test case to control the client to perform the following operations: based on the binding relationship between multiple memory objects, search the client for the target memory object related to the function to be tested of the test branch, 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 executing the function to be tested. In this method, the smoke test of the code is realized 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 the data generated during the execution process can be used to determine whether the function to be tested can be implemented normally.

[0010] Other features and advantages of the present disclosure will be described in the following description, and partly become apparent from the description, or understood by practicing the present disclosure. The purpose and other advantages of the present disclosure are realized and obtained by the structures particularly pointed out in the description, claims and drawings.

[0011] In order to make the above-mentioned objectives, features and advantages of the present disclosure more obvious and easy to understand, preferred embodiments are specifically cited below and described in detail with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the specific embodiments of the present disclosure or the technical solutions in the prior art, the drawings required for use in the specific embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without paying any creative work.

[0013] Figure 1 A flow chart of a smoke test method provided by an embodiment of the present disclosure;

[0014] Figure 2 A flow chart of another smoke test method provided by an embodiment of the present disclosure;

[0015] Figure 3 A flow chart of another smoke test method provided by an embodiment of the present disclosure;

[0016] Figure 4 A functional module diagram of a continuous delivery device based on automated smoke testing provided by an embodiment of the present disclosure;

[0017] Figure 5 A functional module diagram of a continuous integration unit provided by an embodiment of the present disclosure;

[0018] Figure 6 A functional module diagram of a smoke test unit provided in an embodiment of the present disclosure;

[0019] Figure 7 A schematic diagram of the structure of a smoke test device provided in an embodiment of the present disclosure;

[0020] Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0021] In order to make the purpose, technical solution and advantages of the embodiments of the present disclosure clearer, the technical solution of the present disclosure will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the described embodiments are part of the embodiments of the present disclosure, rather than all of the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present disclosure.

[0022] Continuous delivery is a software development practice in which software developers reduce development cycles and risks by frequently integrating code into the code repository. The main purpose of continuous delivery is to enable the development team to frequently deliver high-quality software to meet customer needs and respond quickly to feedback. As the software development team expands, once there is a problem with a code submission that affects the normal operation of other software functions, it will inevitably affect the normal development, testing, acceptance and other links of other related technical personnel, affecting the overall efficiency of the team.

[0023] In the traditional software development process, the common solution is to perform basic verification after the developer submits the code, such as verifying the basic correctness of the interface, or verifying whether the basic functions are normal by clicking the UI. This type of verification is collectively called smoke testing. The core purpose of smoke testing is to verify whether the basic functions of the software are normal, and it does not fully and deeply test every function. Integrating smoke testing into continuous delivery is a common solution to ensure the correctness of basic software functions, but there are still some problems when using it in game projects:

[0024] 1. The interface smoke and UI smoke of traditional software cannot meet the test of basic functions of some software. Many basic functions cannot be run and verified through interface calls and UI clicks;

[0025] 2. Game projects involve multiple branch versions, and traditional smoke testing cannot effectively cover the testing requirements of all branch versions;

[0026] 3. The smoke test in traditional continuous delivery only focuses on functional correctness, but when a problem occurs in the function, it is impossible to quickly locate the person responsible for the problem.

[0027] Based on this, the embodiments of the present disclosure provide a smoke test method, device, electronic device and storage medium, and the technology can be applied to scenarios where smoke testing is required.

[0028] In a possible implementation, the present disclosure provides a smoke test method.

[0029] like Figure 1 As shown, the method comprises the following steps:

[0030] Step S102, 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 corresponds to a function to be tested of the test branch.

[0031] The smoke test triggering event can be of various types. For example, a user can send a test request to a test server through a terminal device, thereby generating a smoke test triggering event. Since smoke testing is usually performed on newly generated code, a user can submit code data to a data storage server for storing code data and then send a test request for the code data. The test server obtains the code data from the data storage server, thereby performing a smoke test on the code data.

[0032] The above-mentioned smoke test trigger event can also be generated after monitoring the submission event of the code data and confirming that the submission is successful. A module for monitoring code submission events can be set in advance in the designated server, and after the designated server monitors the code submission event and the submission result of the submission event is successful submission, a notification message is sent to the test server. After receiving the notification message sent by the designated server, the test server determines that a smoke test trigger event has occurred. Users usually submit code to the designated server, so the designated server can monitor the code submission event.

[0033] The test server needs to update the client based on the submitted code, so it needs to obtain the submitted code. Since the server that stores different versions of the code has a lot of data and high confidentiality, it is difficult to open access rights to the test server. Therefore, the code that needs to be smoke tested can be sent to the data storage server. The data storage server can be an open database. The test server obtains the code that needs to be smoke tested from the data storage server and updates the client.

[0034] In actual applications, software projects usually involve multiple branch versions, such as development branches (also called "development versions"), test branches (also called "test versions"), and release branches (also called "release versions"), etc. Different versions have corresponding codes. For different branches, corresponding clients are usually deployed. When it is necessary to perform smoke testing on the code data of a branch, it is necessary to specify a server to listen to the code data of that version.

[0035] For the convenience of writing, the version of the code data that needs to be monitored is called a test branch. Usually, the test branch that needs to be monitored is set in the designated server. When the designated server monitors the submission event of the code data of the test branch, and the result of the submission event is a successful submission, a notification message is sent to the test server. If the designated server is a server that stores code data, the code data of the test branch can also be sent to the data storage server to facilitate the subsequent test server to obtain the code data of the test branch from the data storage server, and update the client corresponding to the test branch based on the code data.

[0036] Step S104, establishing communication with a client deployed in the test branch; wherein the client stores a plurality of memory objects.

[0037] If a smoke test trigger event occurs, communication with the client deployed in the test branch is required. When there are multiple branches in advance and corresponding clients are deployed for multiple branches, the client corresponding to the test branch needs to be determined as the target client and communication with the target client needs to be established.

[0038] Usually, a remote procedure call can be established with the client. When a remote procedure call (RPC) needs to be applied in a Python environment, it is implemented through rpyc (Remote Python Call) support. In a remote procedure call, the test server acts as a client and the client acts as a server.

[0039] Taking game software as an example, in the client, game-related data can be saved in the form of memory objects. Memory objects are usually used to indicate: the user account that logs in to the client, the executable behavior of the user account, the virtual resources related to the user account, and the virtual scenes related to the user account. Correspondingly, memory objects can be divided into user objects, behavior objects, resource objects, scene objects, etc. There is usually an association relationship between memory objects. Generally speaking, the data related to the user account will be bound to the user object corresponding to the user account in the form of the corresponding annual memory object. When the corresponding data needs to be used or the corresponding function needs to be called, the required memory object is usually found starting from the binding relationship of the user object. The above data storage method is common in game clients, etc.

[0040] Step S106, execute the preset test case to control the client to perform the following operations: based on the binding relationship between multiple memory objects, search for the target memory object related to the function to be tested of 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 of logging 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.

[0041] The preset test cases can be executed, and the client can be controlled to execute the function to be tested through the communication mode of remote procedure call. The function to be tested usually involves multiple memory objects. The memory objects involved can be the user object of the account logged in to the client, or can be other various memory objects as mentioned above that are directly or indirectly bound to the user object.

[0042] Memory objects can be bound in a variety of forms, such as chain structures, tree structures, and other bindings. The specific settings can be made according to the needs and are not limited here. In the process of searching for the target memory object related to the function to be tested of the test branch, the identifier of the target memory object can usually be obtained from the test case, and then the relevant data of the target memory object can be found from the identifier and the binding relationship of the memory object in the client. After finding the memory object, it is necessary to call the function bound to the target memory object and execute the function to be tested through the function.

[0043] Step S108, determining the test result based on the data generated by the function execution of the function to be tested.

[0044] During the execution of the function to be tested, a large amount of data is usually generated. This data can indicate whether errors occur during the execution of each function called, and whether the relevant parameters of the user object change after the function is executed.

[0045] If an error occurs during the execution of the function and the changes in the relevant parameters of the user object do not meet expectations, the test result can be judged as a failure. If the function is executed normally and the changes in the relevant parameters of the user object meet expectations, the test result can be judged as a success.

[0046] In order to determine whether the changes in the relevant parameters of the user object are in line with expectations, the test case can give the expected result in advance. The expected result is usually the value determined by the tester who writes the test case assuming that the function to be tested is implemented normally. When the tester calculates the expected result, some business data is usually used. For example, the function to be tested is to upgrade the user. It is assumed that the user level has a corresponding relationship with the user points; the specific function tested by the test case is to upgrade the user to level 5, and the user points corresponding to the level 5 user should be 50. If the data generated by executing the function to be tested indicates that the user points finally become 50, the test is successful. The above user points of 50 are regarded as an expected result.

[0047] In some cases, the user points of each level may have been stored in the client as business data. When the client upgrades the user, it uses the stored business data to determine the user points after the upgrade. The test case can pre-calculate the expected result, but read the user points corresponding to the user level of the function to be tested from the client and use it as the expected result. This method will not affect the accuracy of the test results when there may be inconsistencies between the business data obtained by the client and the tester.

[0048] The data generated during the execution of the function to be tested can be saved and a log file can be generated during the execution of the function to be tested. After the function to be tested is executed, the log file is parsed, and error information is extracted from the parsing result; based on the error information, the test result is determined. If there is error information, the test result is considered to be a failure.

[0049] The above-mentioned smoke test method, in response to a smoke test triggering event, determines a test branch and a preset test case corresponding to the test branch; the preset test case corresponds to the function to be tested of the test branch; establishes communication with a client deployed with the test branch; wherein the client saves multiple memory objects; executes the preset test case to control the client to perform the following operations: based on the binding relationship between multiple memory objects, searches the client for a target memory object related to the function to be tested of the test branch, calls the function bound to the target memory object, and executes the function to be tested through the function; determines the test result based on the data generated by the function executing the function to be tested. In this method, the smoke test of the code is realized 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 the data generated during the execution process can be used to determine whether the function to be tested can be implemented normally.

[0050] The following embodiment provides a specific method for establishing communication with a client deployed in a test branch.

[0051] The above method is usually applied to test servers. When the function to be tested needs to be tested, the test server needs to establish a remote procedure call with the client. In RPC, the server provides a set of remotely callable functions or procedures, and the client calls 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 call functions on the remote server just like calling local functions without having to worry about the underlying network communication details. In the remote procedure call, the test server acts as the client and the client acts as the server.

[0052] In some cases, the test server is also connected to a designated server. The designated server is used to monitor the submission event of the code data of the test branch, and send a notification message to the test server after the submission result of the submission event is successful. When the test server receives the notification message sent by the designated server, it determines that a smoke test trigger event has occurred; further, the test server needs to obtain the code data of the test branch, and update the client deployed in the test branch based on the code data, and further test the function to be tested of the code through the updated client.

[0053] In the specific implementation, the continuous integration tool Jenkins can be used to monitor code submission events. When the relevant personnel submit the latest code to the version library, the designated server deployed with Jenkins will automatically pull the latest package from Git (an open source distributed version control system) / SVN (the abbreviation of subversion, an open source version control system) and redeploy it, so that the latest code can be used during the test process.

[0054] The following embodiment provides a specific method for processing response data by using a preset first data processing logic if the processing result indicates that the response to the target asynchronous request fails.

[0055] The above-mentioned memory objects are usually the user objects of the user account of the logged-in client and multiple other memory objects bound to it. For the convenience of writing, the other memory objects are referred to as first memory objects. The first memory object can be a behavior object, a resource object, and a scene object. Among them, the user object and multiple first memory objects are bound in the form of a tree structure; the user object is the root node of the tree structure.

[0056] The behavior object is used to implement the business behavior of the user account, such as sending a remote call request to the server. The resource object can save the relevant data of the resources owned by the user account. The scene object usually saves the relevant information of the virtual scene that the user can enter or has entered. The virtual scene can be a virtual business hall, etc.

[0057] When the client is a game client, the behavior object is usually called a component object, and the resource object is usually called a prop object. Among them, the component object is used to implement the executable game behavior of the game account, or the executable game behavior of the virtual character controlled by the game account, such as jumping, skill release, etc. The prop object is used to save the data of the game props related to the game account. The scene object includes the data of the game scene related to the game account.

[0058] In the process of executing the function to be tested, it is necessary to first find the user object from the client; then, through the preset reflection mechanism, based on the user object and the tree structure, find the target memory object from the client. The target memory objects related to the function to be tested can be multiple or one, and there is no restriction here. Among them, the Java reflection mechanism is that in the running state, for any object, any method and attribute of it can be called; this function of dynamically obtaining information and dynamically calling object methods is called the reflection mechanism of the Java language.

[0059] The following embodiment provides a specific method for processing response data by using a preset first data processing logic if the processing result indicates that the response to the target asynchronous request fails.

[0060] For example, for game software, the configuration parameters of the numerical values, scenes, and props in the game are all controlled by tables. All the game tables will be converted from the original Excel file to a specified Python file, also called a table file. Table files are usually saved in advance in the client. The data saved in this file is called table data, which is used to indicate the configuration parameters of the memory object. The configuration parameters are used to indicate at least one of the following: the identification, attributes, and effects of the memory object. The identification can be an ID, name, icon reference information, etc.; the attributes are usually used to indicate the type of memory object; the effect is usually used to indicate what effect the memory object will have on the user object if it is applied to the user object. In some cases, attributes also include effects.

[0061] Since the table configuration data is the data actually applied to the client, directly obtaining the table configuration data is more authentic and reliable compared to querying the configuration parameters and writing test cases. Therefore, it is usually necessary to control the client to parse the table configuration file, obtain the table configuration data, and then obtain the configuration parameters of the memory object from the table configuration data.

[0062] The expected result corresponding to the function to be tested can be determined based on the table data of the target memory object related to the function to be tested. For example, the life value of the user object is 100. When executing the function to be tested, a virtual prop is added to the user object. When the function can be implemented normally, the life value of the user object needs to be added to the life value that can be added by the virtual prop. In the table data, the life value that can be added by the virtual prop is 50. Calculating 100+50=150, 150 is the expected result. If the life value of the user object is 150 after the test case is executed, which is the same as the expected result, the test result is judged to be successful. If the life value of the user object is other values, the test result is judged to be failed. That is, the test result can be determined based on the data generated by the function execution of the function to be tested and the expected result.

[0063] For subsequent data analysis, when the client executes the function to be tested based on the function, the test server will obtain the data generated by the execution of the function to be tested, and generate a log file based on the obtained data. The log file is used to save the data generated by the function executing the function to be tested. In addition to the situation where there is an error in the execution result of the function to be tested, there may also be errors such as interruption and freezing of the execution process of the function to be tested. When the above situation occurs, an error message is usually generated. The test server can parse the log file, extract the error information from the parsing result, and then determine the test result based on the error information. If the error information cannot be extracted, it is determined that the above test error did not occur.

[0064] The present disclosure also provides another smoke test method. Figure 1 The method is implemented on the basis of the method shown. The method provides a testing method that can ensure the reliability of the game software version in the continuous integration development link.

[0065] The method uses the continuous integration unit to mark the development branch repository that needs to be monitored, obtains each submission information through the SVN Hook, and stores it in redis. Among them, SVN hook refers to the script or program that is automatically called after the SVN operation (such as submission, update, merge, etc.) is completed. The continuous integration unit monitors the result of each submission. If the submission is successful, it triggers the smoke test task deployed on the continuous integration tool Jenkins; the smoke test task automatically updates the project repository on the deployment device, and starts the smoke test unit after the update is completed (usually set in the above-mentioned "test server"). The smoke test unit automatically starts the client of the branch and completes the login process; the smoke test unit connects to the client through RPYC and executes the pre-set test cases; the test cases communicate through RPYC, drive the client code to execute basic functions, and record the execution log; after the execution is completed, the smoke test unit analyzes the execution log and obtains the error information. If there is an error message, the test result is failure, otherwise it is success; the smoke test unit obtains the submission information from the submission log in redis and returns the test result to the continuous integration unit. When the smoke test succeeds, the continuous integration tool Jenkins executes subsequent tasks; when the smoke test fails, the continuous integration unit will notify the submitter of the error message and terminate the Jenkins task.

[0066] The function of the continuous integration unit in the above method is to mark the branch repository to be monitored, obtain submission information, trigger the smoke test task, and perform subsequent steps based on the smoke test results; the function of the smoke test unit is to execute a preset set of use cases according to different branch repositories, collect execution log information, and return the test results.

[0067] like Figure 2 The continuous delivery process based on automated smoke testing shown in the figure mainly includes the following steps:

[0068] 1 The continuous integration unit marks the branch repository that needs to be monitored.

[0069] Since large projects may have different development branches, such as development branches, test branches, and release branches, it is necessary to pre-mark the branches for version reliability monitoring. Branch monitoring is implemented through the SVN hooks plug-in. When a branch is successfully submitted, the submission information will be used as data according to the configuration of the plug-in, and a request will be sent to the continuous integration unit, which will control the monitoring.

[0070] 2. The continuous integration unit monitors the submission status and stores the submission information in redis.

[0071] The continuous integration unit receives the commit information sent by the SVN Hook (also called "SVN plug-in") plug-in, 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.

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

[0073] 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.

[0074] 4 The smoke test task executes the update submitted branch repository.

[0075] The smoke test task on Jenkins contains multiple execution steps, including:

[0076] Update the local warehouse of the branch warehouse on the task deployment device according to the incoming submission information;

[0077] Use the submission information as the execution parameter to start the smoke test unit;

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

[0079] 5 The smoke test task passes in the submission information as the execution parameter to start the smoke test unit.

[0080] Like step 4 above, this is an execution step of the smoke test task. This step will pass the submission information as an execution parameter to the smoke test unit to start the smoke test unit. The submission information must include the submitted branch, and the smoke test unit determines and executes the test case based on the branch.

[0081] 6 The smoke test unit starts the branch client and logs in.

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

[0083] 7 The smoke test unit connects to the client through RPYC and executes the preset use cases.

[0084] After logging in, the smoke test unit will connect to the client through RPYC. RPYC is a Python remote call library that allows different Python processes to communicate and call functions remotely. This step requires that the client also has RPYC installed and acts as the RPYC server. The smoke test unit connects to the RPYC server as a client, that is, connects to the client. When the connection is successful, the smoke test unit will execute the preset use case set according to different branches.

[0085] 8 test cases verify basic functions through RPYC driver client code and record execution logs.

[0086] The test cases in the smoke test unit are actually scripts that contain a set of driver client codes. The scripts will perform basic functions according to the preset driver client codes. While executing the functions, the test case script will record the execution log and save it in the log file, which contains the log of successful execution and the error message of failed execution.

[0087] 9The smoke test unit analyzes the execution log and obtains error information.

[0088] After the use case is executed, the smoke test unit analyzes the execution log of the use case and extracts the error information.

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

[0090] When there is an error message, the smoke test fails, and the smoke test unit returns the error message and execution failure as the result to the continuous integration unit; when there is no error message, the smoke test succeeds, and the smoke test unit returns the execution success and empty error message as the result to the continuous integration unit. At the same time, the smoke test unit closes the client process.

[0091] 11 The continuous integration unit notifies the submitter of the result.

[0092] 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 the success; if the test result is failed, the submitter is notified of the failure and the error message is sent to the submitter, who is responsible for fixing the problem.

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

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

[0095] In the example of the present invention, the submission information of the SVN warehouse is sensed and obtained through the SVN hooks plug-in, and the execution of the smoke test task is triggered through Jenkins. The smoke test unit executes the test cases preset in different branches through the submission information to meet the different basic functional requirements of different branches. At the same time, the smoke test unit drives the client to execute functions through RPYC, so as to perform basic functional tests more fully, comprehensively and stably. Through smoke testing, the continuous integration system quickly feeds back the verification of basic functions to the submitter, thereby effectively ensuring the reliability of the submitted version.

[0096] Figure 3 It is a functional module diagram of a continuous delivery device based on automated smoke testing provided by the present invention, and the device includes:

[0097] Continuous Integration Unit 201, mainly responsible for the following functions:

[0098] 1. Specify the commit monitoring of the branch repository and record the commit information;

[0099] 2. Start the smoke test unit;

[0100] 3. Based on the smoke test results, notify the submitter and execute or terminate the continuous integration step.

[0101] Smoke test unit 202 is mainly responsible for the following functions:

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

[0103] 2. Connect to the client and execute the specified test case;

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

[0105] Figure 4 It is a functional module diagram of the continuous integration unit 201, which includes:

[0106] 2011, SVN plug-in module: The main function of this module is to allow the continuous integration unit to sense the commits in the SVN branch repository, so as to perform necessary analysis and processing on the commits. The implementation of this module relies on the fact that SVN itself can configure hooks. Its core function is the callback before or after SVN commits. We can configure the hooks triggered after the commit to sense the commits in the branch repository.

[0107] 2012. Redis read-write module: The main function of this module is to store the submitted information, so that each module of the continuous integration unit can obtain the required data when it needs to use the submitted information data. As a widely used in-memory database, redis has a high read and write speed, which is conducive to the unit to quickly complete the overall test task.

[0108] 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. In the continuous integration unit, the smoke test task is the first stage of all continuous integration pipelines after the branch is submitted. When the smoke test task fails, we can use the characteristics of Jenkins to terminate the current task pipeline and not execute subsequent steps to improve the efficiency of continuous delivery.

[0109] 2014. Information notification module: The main function of this module is to collect the results of the smoke test and then notify the responsible person. This module has many options, such as notification and alarm through SMS, email, or IM software.

[0110] This method quickly senses the submission of the SVN repository through the SVN hooks plug-in and stores the submission information in redis to ensure the circulation of the submission 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 the smoke test.

[0111] Figure 5 2 is a functional module diagram of the smoke test unit 202, which includes:

[0112] 2021. Client process management module: The main function of this module is to manage the start and stop of the client process. When the smoke test unit is started, the module will start the corresponding branch client of the deployment device according to the incoming branch information; when the smoke test is over, the started client will also be closed.

[0113] 2022. Login module: The main function of this module is to automatically complete the login process after the game process is started. The game client needs to log in to experience the content provided by the game, and different branch environments need to log in to different supporting servers to experience the game content normally. Therefore, this module will log in to a pre-set test account, and log in to the specified server to test and verify the function according to the incoming branch information.

[0114] 2023. Use case management module: The main functions of this module are to establish RPYC communication connection with the client, manage test cases, and record the log of use case execution. Since different branches focus on different basic functions, there will be different test cases. This module will execute the preset corresponding use cases according to the incoming branch information. At the same time, this module will record the log of use case execution for subsequent analysis of smoke test results.

[0115] 2024. Log analysis module: The main function of this module is to analyze and collect error information in the log after the use case is executed, and return it to the continuous integration unit based on whether there is error information as the result of the smoke test.

[0116] This method meets the testing requirements of different branches for different basic functions by managing and assigning different branch test cases. At the same time, by driving the client code through RPYC, basic function testing is more comprehensive and fully covered, which is more suitable for functional verification of game software than traditional interface testing and UI testing.

[0117] Figure 6 This is a working principle diagram of the use case management module in the smoke test unit. Due to the verification of the basic functions of the game, only a small part of the functions can be tested through user input operations (such as movement, skill release, UI clicks, etc.), and many parts cannot be tested by simulated input (such as Buff effects, scene changes, unit creation and destruction, etc.). In order to meet the verification 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 method is as follows:

[0118] First, the client acts as the RPYC server in the test phase and listens to the specified port after the game is started. The use case management module in the smoke test unit acts as the RPYC client and connects to the game through the IP and port. Through the established communication, the smoke test unit can call all modules in the game and execute the corresponding code. However, calling the code module in the game alone cannot meet the requirements of functional testing. There are two main problems:

[0119] Question 1: How to know whether the effect of the numerical change after the in-game test is in line with expectations? For example, after obtaining a certain item, the character's numerical value changes. How can the test case determine whether this change is correct?

[0120] Question 2: Simply calling the in-game code module to create objects and execute code will not have any actual effect. The reason is that 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 in the existing memory objects.

[0121] In order to solve these two main problems, this method solves them by the following methods:

[0122] Regarding the above question 1: Since the values, scenes, props, etc. in the game are all controlled by tables. For example, there are many types of props in the game, with different names, effects, types, etc., but from the code point of view, props are actually a prop class, which has properties such as name, effect, type, etc., and the specific properties of a prop are controlled by the prop table. All the tables of the game will be converted from the original Excel file to a specified Python file, which contains compressed data table objects. These Python files containing data table objects are referenced in the game as code modules, so this smoke test unit also obtains complete numerical information by calling these data table objects. One advantage of obtaining data information in this way is that the numerical information is always up to date, which is more timely and accurate than the test form of hard-coding numerical values ​​in the use case code.

[0123] After obtaining the complete data table information, the use case code compares the numerical changes before and after the use case operation is implemented with the results calculated using the data table information. If they are consistent, the numerical changes are in line with expectations; otherwise, an error indicating inconsistent numerical values ​​is thrown.

[0124] Regarding the above question 2: Since we need to test the specified object in the memory, the primary goal is to locate the memory object. In the smoke test, the memory objects that need to be located most are the current user object and the current scene object. These two objects can already meet the testing requirements of basic functions. Here we use Python's memory management mechanism. Since in the Python interpreter, objects are managed through the memory pool, they will be destroyed when the memory object is no longer referenced. The user object is one of the most basic objects in the game and is referenced by all bound component objects. When the game process exists, this object will not be destroyed and will always exist in the memory pool. In this solution, the player class's memory object is located in the memory pool, and other related module objects are located through the reflection mechanism. Then, other objects are located through module object reflection, such as prop objects, Buff objects, etc.

[0125] After locating the specified test object, call the function bound to the object to drive the game to perform the specified function for testing and verification.

[0126] In the use case management module of the smoke test unit, based on RPYC communication, we first obtain the latest data information by reading and parsing the matching table. Then locate the object of the player class in the memory through the memory pool, and locate other related objects based on the tree relationship referenced by the object in the memory. After locating the memory object required for the test, call the function method of the object to test the game function. By comparing the tested value with the result calculated from the data read in the matching table, the correctness of the value can be found. This test method is more suitable for game test scenarios than tests that rely solely on user input.

[0127] Compared with other existing solutions, this method realizes the monitoring of multiple development branches and records the submission information of each monitored branch to locate the responsible person. When a submission occurs, the smoke test unit will execute the preset use case according to the branch. The use case communicates with the client through RPYC to drive the game to execute the functional code to cover the basic functions that cannot be covered by interface testing and UI testing, thereby realizing a smoke test that is more suitable for game software. When the smoke test fails, the person responsible for the submission will be directly located based on the submission information, thereby promoting the rapid repair of the problem branch version and ensuring the reliability of the version.

[0128] For the above method embodiments, see Figure 7 A smoke test device is shown, the device comprising:

[0129] The test branch determination module 702 is used to determine the test branch and the preset test case corresponding to the test branch in response to the smoke test triggering event; the preset test case corresponds to the function to be tested of the test branch;

[0130] The communication establishment module 704 is used to establish communication with the client deployed in the test branch; wherein the client saves multiple memory objects;

[0131] The client control module 706 is used to execute the preset test case to control the client to perform the following operations: based on the binding relationship between multiple memory objects, search for the target memory object related to the function to be tested of 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 of logging 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;

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

[0133] The above-mentioned smoke test device, in response to a smoke test triggering event, determines a test branch and a preset test case corresponding to the test branch; the preset test case corresponds to the function to be tested of the test branch; establishes communication with a client deployed with the test branch; wherein the client saves multiple memory objects; executes the preset test case to control the client to perform the following operations: based on the binding relationship between multiple memory objects, searches the client for a target memory object related to the function to be tested of the test branch, calls the function bound to the target memory object, and executes the function to be tested through the function; determines the test result based on the data generated by the function executing the function to be tested. In this method, the smoke test of the code is realized 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 the data generated during the execution process can be used to determine whether the function to be tested can be implemented normally.

[0134] The above-mentioned memory objects include a user object of a user account that logs into the client and multiple 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 multiple first memory objects are bound in the form of a tree structure; the user object is the root node of the tree structure; the client control module is also used to: search for the user object from the client; search for 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.

[0135] The above-mentioned client saves the table matching file; the table matching file includes table matching data of multiple memory objects; the above-mentioned device also includes: a table matching data parsing module, which is used to control the client to parse the table matching file to obtain the table matching data; the table matching data includes configuration parameters of the memory object; the configuration parameters are used to indicate at least one of the following: the identification, attributes and effects of the memory object.

[0136] The test result determination module is also used to: determine the expected result corresponding to the function to be tested based on the matching table data of the target memory object related to the function to be tested; determine the test result based on the data and expected result generated by the function execution of the function to be tested.

[0137] The above-mentioned device includes a test server; the communication establishment module is also used for: the test server to establish 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 service end.

[0138] The above-mentioned device includes a test server and a designated server; the test server is communicatively connected with the designated server; the designated server is used to: monitor the submission event of the code data of the test branch, and after the submission result of the submission event is successful, send a notification message to the test server; the above-mentioned device also includes: a smoke test determination module, which is used for the test server to determine the occurrence of a smoke test trigger event in response to receiving a notification message sent by the designated server; and a client update module, which is used for the test server to obtain the code data of the test branch and update the client deployed in the test branch based on the code data.

[0139] The above-mentioned test result determination module is also used to: obtain the data generated by executing the function to be tested based on the function in the process of the client executing the function to be tested, and generate a log file based on the obtained data; parse the log file and extract error information from the parsing result; determine the test result based on the error information.

[0140] This embodiment further provides 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-mentioned smoke test method, for example:

[0141] In response to a smoke test triggering event, a test branch and a preset test case corresponding to the test branch are determined; the preset test case corresponds to a function to be tested of the test branch; communication with a client deployed with the test branch is established; wherein the client saves a plurality of memory objects; the preset test case is executed to control the client to perform the following operations: based on a binding relationship between the plurality of memory objects, a target memory object related to the function to be tested of the test branch is searched from the client, a function bound to the target memory object is called, and the function to be tested is executed through the function; and a test result is determined based on data generated by the execution of the function to be tested.

[0142] In the above method, the function to be tested is executed by controlling the client to call the function bound to the memory object related to the function to be tested, and then the data generated during the execution process can be used to determine whether the function to be tested can be implemented normally, thereby realizing smoke testing of the code.

[0143] Optionally, the above-mentioned memory objects include a user object of a user account that logs into the client and multiple 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 multiple first memory objects are bound in the form of a tree structure; the user object is the root node of the tree structure; based on the binding relationship between the multiple memory objects, the step of searching for the target memory object related to the function to be tested of the test branch from the client includes: searching for the user object from the client; searching for 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.

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

[0145] Optionally, the above-mentioned step of determining the test result based on the data generated by the function executing the function to be tested includes: 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; determining the test result based on the data generated by the function executing the function to be tested and the expected result.

[0146] Optionally, the method includes a test server; the step of establishing communication with a client deployed in a test branch includes: 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.

[0147] Optionally, the above method includes a test server and a designated server; the test server is communicatively connected to the designated server; the designated server is used to: listen to the submission event of the code data of the test branch, and after the submission result of the submission event is successful, send a notification message to the test server; the method also includes: the test server determines that a smoke test trigger event occurs in response to receiving the notification message sent by the designated server; the test server obtains the code data of the test branch, and updates the client deployed on the test branch based on the code data.

[0148] Optionally, the above-mentioned step of determining the test result based on the data generated by the function executing the function to be tested includes: in the process of the client executing the function to be tested based on the function, obtaining the data generated by the execution of the function to be tested, and generating a log file based on the obtained data; parsing the log file, and extracting error information from the parsing result; and determining the test result based on the error information.

[0149] See also Figure 8 As shown, 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 above-mentioned smoke test method.

[0150] Further, Figure 8 The electronic device shown further includes a bus 102 and a communication interface 103 , and the processor 100 , the communication interface 103 and the memory 101 are connected via the bus 102 .

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

[0152] The processor 100 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit or software instructions in the processor 100. The above processor 100 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can 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 gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present disclosure can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in conjunction with the embodiments of the present disclosure can be directly embodied as a hardware decoding processor for execution, or a combination of hardware and software modules in the decoding processor for execution. The software module may be located in a storage medium mature in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 101, and the processor 100 reads the information in the memory 101 and completes the steps of the method of the above embodiment in combination with its hardware.

[0153] This embodiment further provides a machine-readable storage medium, which stores machine-executable instructions. When the machine-executable instructions are called and executed by a processor, the machine-executable instructions prompt the processor to implement the above-mentioned smoke test method.

[0154] A smoke test method, device and electronic device provided in the embodiments of the present disclosure include a computer-readable storage medium storing program code, and the program code includes instructions that can be used to execute the methods described in the previous method embodiments, for example:

[0155] In response to a smoke test triggering event, a test branch and a preset test case corresponding to the test branch are determined; the preset test case corresponds to a function to be tested of the test branch; communication with a client deployed with the test branch is established; wherein the client saves a plurality of memory objects; the preset test case is executed to control the client to perform the following operations: based on a binding relationship between the plurality of memory objects, a target memory object related to the function to be tested of the test branch is searched from the client, a function bound to the target memory object is called, and the function to be tested is executed through the function; and a test result is determined based on data generated by the execution of the function to be tested.

[0156] In the above method, the function to be tested is executed by controlling the client to call the function bound to the memory object related to the function to be tested, and then the data generated during the execution process can be used to determine whether the function to be tested can be implemented normally, thereby realizing smoke testing of the code.

[0157] Optionally, the above-mentioned memory objects include a user object of a user account that logs into the client and multiple 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 multiple first memory objects are bound in the form of a tree structure; the user object is the root node of the tree structure; based on the binding relationship between the multiple memory objects, the step of searching for the target memory object related to the function to be tested of the test branch from the client includes: searching for the user object from the client; searching for 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.

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

[0159] Optionally, the above-mentioned step of determining the test result based on the data generated by the function executing the function to be tested includes: 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; determining the test result based on the data generated by the function executing the function to be tested and the expected result.

[0160] Optionally, the method includes a test server; the step of establishing communication with a client deployed in a test branch includes: 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.

[0161] Optionally, the above method includes a test server and a designated server; the test server is communicatively connected to the designated server; the designated server is used to: listen to the submission event of the code data of the test branch, and after the submission result of the submission event is successful, send a notification message to the test server; the method also includes: the test server determines that a smoke test trigger event occurs in response to receiving the notification message sent by the designated server; the test server obtains the code data of the test branch, and updates the client deployed on the test branch based on the code data.

[0162] Optionally, the above-mentioned step of determining the test result based on the data generated by the function executing the function to be tested includes: in the process of the client executing the function to be tested based on the function, obtaining the data generated by the execution of the function to be tested, and generating a log file based on the obtained data; parsing the log file, and extracting error information from the parsing result; and determining the test result based on the error information.

[0163] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the system and device described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0164] In addition, in the description of the embodiments of the present disclosure, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two components. For those skilled in the art, the specific meanings of the above terms in the present disclosure can be understood according to specific circumstances.

[0165] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present disclosure, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present disclosure. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program code.

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

[0167] Finally, it should be noted that the above embodiments are only specific implementation methods of the present disclosure, which are used to illustrate the technical solutions of the present disclosure, rather than to limit them. The protection scope of the present disclosure is not limited thereto. Although the present disclosure is described in detail with reference to the above embodiments, those skilled in the art should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the above embodiments within the technical scope disclosed in the present disclosure, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present disclosure, and should be included in the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be based on the protection scope of the claims.

Claims

1. A smoke test method, characterized in that: The method comprises: In response to a smoke test triggering event, determine a test branch and a preset test case corresponding to the test branch; the preset test case corresponds to a function to be tested of the test branch; establish communication with a client deployed by the test branch; wherein the client stores a plurality of memory objects; 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 the client for a target memory object related to the function to be tested of the test branch, calling a function bound to the target memory object, and executing the function to be tested through the function; The memory object includes at least one of the following: a user account for logging 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 is determined based on data generated by executing the function to be tested.

2. The method according to claim 1, characterized in that The memory object includes a user object of a user account that logs 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 multiple memory objects, the step of searching, from the client, a target memory object related to the function to be tested of the test branch comprises: Searching for the user object from the client; The target memory object related to the to-be-tested function of the test branch is searched from the client based on the user object and the tree structure through a preset reflection mechanism.

3. The method according to claim 1, characterized in that The client saves a table configuration file; the table configuration file includes table configuration data of the multiple memory objects; The method further comprises: The client is controlled to parse the table configuration file to obtain table configuration data; the table configuration data includes configuration parameters of the memory object; the configuration parameters are used to indicate at least one of the following: the identification, attributes and effects of the memory object.

4. The method according to claim 3, characterized in that: The step of determining the test result based on the data generated by the function executing the function to be tested comprises: Determine the expected result corresponding to the function to be tested based on the allocation table data of the target memory object related to the function to be tested; A test result is determined based on the data generated by the function executing the function to be tested and the expected result.

5. The method according to claim 1, characterized in that The method includes testing a server; The step of establishing communication with the client deployed in 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 service end.

6. The method according to claim 1, characterized in that The method includes a test server and a designated server; the test server is connected to the designated server for communication; the designated server is used to: monitor the submission event of the code data of the test branch, and send a notification message to the test server after the submission result of the submission event is successful; The method further comprises: The test server determines, in response to receiving the notification message sent by the designated server, that a smoke test triggering event occurs; The test server obtains the code data of the test branch, and updates the client deployed by the test branch based on the code data.

7. The method according to claim 1, characterized in that The step of determining the test result based on the data generated by the function executing the function to be tested comprises: In the process of the client executing the function to be tested based on the function, acquiring data generated by executing the function to be tested, and generating a log file based on the acquired data; Parsing the log file and extracting error information from the parsing result; Based on the error information, a test result is determined.

8. A smoke test device, characterized in that: The device comprises: 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 function to be tested of the test branch; A communication establishment module, used to establish communication with a client deployed in the test branch; wherein the client stores a plurality of memory objects; The client control module is used 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 the target memory object related to the function to be tested of the test branch from the client, calling the 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 for logging 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; The test result determination module is used to determine the test result based on the data generated by the function executing the function to be tested.

9. An electronic device, characterized in that: The invention comprises 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 smoke test method according to any one of claims 1 to 7.

10. A machine-readable storage medium, characterized in that: The machine-readable storage medium stores machine-executable instructions. When the machine-executable instructions are called and executed by a processor, the machine-executable instructions prompt the processor to implement the smoke test method according to any one of claims 1 to 7.

Images