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

Smoking test method, device, electronic equipment and storage medium

[0001] Cross Reference to Related Applications

[0002] This application claims priority to Chinese Patent Application No. 202410977034.X, filed on July 19, 2024, entitled “Smoking test method, device, electronic equipment and storage medium”, the contents of which are incorporated herein in their entirety by reference. TECHNICAL FIELD

[0003] The present disclosure relates to the technical field of testing, in particular, to a smoking test method, device, electronic equipment and storage medium. BACKGROUND

[0004] In the software development link, after the developer code is submitted, it is necessary to verify whether the client can execute the basic functions through the code, for example, verifying whether the interface is basically correct, or verifying whether the basic functions are normal in the way of clicking the graphical user interface. Such verification is collectively referred to as smoking test. The core purpose of smoking test is to verify whether the basic functions of the software are normal. However, the code of some software corresponds to complex business functions, which is difficult to test by using the above-mentioned smoking test method, so as to verify whether the code can normally implement the corresponding business functions. SUMMARY

[0005] Therefore, the purpose of the present disclosure is to provide a smoking test method, device, electronic equipment and storage medium to realize the smoking test of the code.

[0006] In a first aspect, the embodiments of the present disclosure provide a smoking test method, which comprises: in response to a smoking test triggering event, determining a test branch and a preset test case corresponding to the test branch; the preset test case corresponds to a to-be-tested function of the test branch; establishing communication with a client deployed with the test branch; wherein the client saves 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, searching for a target memory object related to the to-be-tested function of the test branch from the client, calling a function bound to the target memory object, and executing the to-be-tested function through the function; wherein the memory object at least includes 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 the function executing the to-be-tested function.

[0007] In a second aspect, the embodiments of the present disclosure provide a smoke testing 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 testing trigger event; the preset test case corresponding to a function to be tested 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 a binding relationship between the plurality of 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 execute the function to be tested; wherein the memory object at least includes 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; and determining a test result based on data generated by the function executing the function to be tested.

[0008] In a third aspect, the embodiments of the present disclosure provide an electronic device, comprising a processor and a memory, the memory storing machine executable instructions capable of being executed by the processor, and the processor executes the machine executable instructions to implement the smoke testing method described above.

[0009] In a fourth aspect, the embodiments of the present disclosure provide a machine readable storage medium, the machine readable storage medium storing machine executable instructions, and when the machine executable instructions are invoked and executed by a processor, the machine executable instructions cause the processor to implement the smoke testing method described above.

[0010] The embodiments of the present disclosure have the following beneficial effects:

[0011] The smoke testing method, device, electronic device and storage medium described above, in response to a smoke testing trigger 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; communication is established with a client deployed by the test branch; wherein the client stores 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, 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 execute the function to be tested; and determining a test result based on data generated by the function executing the function to be tested. In this way, 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, it can be determined whether the function to be tested can be normally implemented through the data generated in the execution process, thereby realizing smoke testing of the code.

[0012] Other features and advantages of the present disclosure will be set forth in the descriptions that follow and in part will be apparent from the descriptions or can be learned by practice of the present disclosure. The objectives and other advantages of the present disclosure will be realized and attained by the structure particularly pointed out in the description.

[0013] In order to make the above objectives, features and advantages of the present disclosure more obvious and comprehensible, the following will specifically describe preferred embodiments in combination with the accompanying drawings, and the detailed description is as follows. BRIEF DESCRIPTION OF DRAWINGS

[0014] In order to more clearly illustrate the specific embodiments of the present disclosure or the technical solutions in the prior art, the following will briefly introduce the drawings needed to be used in the specific embodiments or prior art description. Obviously, the drawings in the following description are some embodiments of the present disclosure, and other drawings can be obtained by those skilled in the art without creative labor.

[0015] Fig. 1 is a flow chart of a smoke test method provided by one of the embodiments of the present disclosure;

[0016] Fig. 2 is a flow chart of another smoke test method provided by one of the embodiments of the present disclosure;

[0017] Fig. 3 is a flow chart of another smoke test method provided by one of the embodiments of the present disclosure;

[0018] Fig. 4 is a functional module diagram of a continuous delivery device based on automated smoke test provided by one of the embodiments of the present disclosure;

[0019] Fig. 5 is a functional module diagram of a continuous integration unit provided by one of the embodiments of the present disclosure;

[0020] Fig. 6 is a functional module diagram of a smoke test unit provided by one of the embodiments of the present disclosure;

[0021] Fig. 7 is a structural schematic diagram of a smoke test device provided by one of the embodiments of the present disclosure;

[0022] Fig. 8 is a structural schematic diagram of an electronic device provided by one of the embodiments of the present disclosure. DETAILED DESCRIPTION

[0023] In order to make the objectives, technical solutions and advantages of the embodiments of the present disclosure more clear, the technical solutions of the present disclosure will be described clearly and completely in combination with the drawings. Obviously, the described embodiments are some of the embodiments of the present disclosure, but not all the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by those skilled in the art without creative labor are within the protection scope of the present disclosure.

[0024] Continuous delivery is a software development practice in which software developers reduce development cycle and risk by frequently integrating code into a code repository. 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. As the software development team expands, once there is a problem with a code commit that affects the normal work of other functions of the software, it will inevitably affect the normal development, testing, acceptance, etc. of other related technical personnel, affecting the overall efficiency of the team.

[0025] In the traditional software development process, a common solution is to perform basic verification after the developer code is submitted, such as verifying the basic correctness of the interface or verifying whether the basic function is normal by clicking the UI. Such verification is collectively referred to as smoke testing. The core purpose of smoke testing is to verify whether the basic function of the software is normal, and it does not comprehensively and deeply test each function. Integrating smoke testing into continuous delivery is a common solution to ensure the correctness of the basic function of the software, but there are still some problems in its application in game projects:

[0026] 1. The interface smoke and UI smoke of traditional software cannot meet the testing of the basic functions of some software, and many basic functions cannot be verified by running through interface calling and UI clicking;

[0027] 2. The traditional smoke testing cannot effectively cover the testing needs of all branch versions in game projects;

[0028] 3. The smoke testing in the traditional continuous delivery only focuses on the correctness of the function, but when the function has a problem, it cannot quickly locate the responsible person causing the problem.

[0029] Based on this, the embodiments of the present disclosure provide a smoke testing method, device, electronic equipment and storage medium, which can be applied to a scene that needs to be tested.

[0030] In one possible implementation, the embodiments of the present disclosure provide a smoke testing method. As shown in FIG. 1, the method includes the following steps:

[0031] Step S102, in response to a smoke testing 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.

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

[0033] The smoke test triggering event can also be a submission event of the code data, which is generated after confirming the success of the submission. A module for listening to the code submission event can be pre-set in a specified server. After the specified server listens to the code submission event and the submission result of the submission event is successful, a notification message is sent to the test server. The test server determines that the smoke test triggering event occurs after receiving the notification message sent by the specified server. The user usually submits the code to the specified server, so the specified server can listen to the code submission event.

[0034] 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 saves different versions of code has a large amount of data and high confidentiality, it is difficult to open access rights to the test server, so the code that needs to be tested can be sent to a data storage server. The data storage server can be an open database. The test server obtains the code that needs to be tested from the data storage server, thereby updating the client.

[0035] In practical applications, a software project usually involves multiple branches, such as a development branch (also referred to as a “development version”), a test branch (also referred to as a “test version”), a release branch (also referred to as a “release version”), etc. Different versions have corresponding code. For different branches, a corresponding client is usually deployed. When the code data of a certain branch needs to be tested, the server needs to listen to the code data of the version.

[0036] For convenience, the version of the code data that needs to be listened to is referred to as a test branch. The test branch that needs to be listened to is usually set in the specified server. When the specified server listens to the submission event of the code data of the test branch and the result of the submission event is successful, a notification message is sent to the test server. If the specified server is a server that saves code data, the code data of the test branch can also be sent to a data storage server to facilitate the 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.

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

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

[0039] Remote procedure call can be established with the client in general. Remote procedure call (RPC) needs to be applied in the Python environment, and is supported by rpyc (Remote Python Call). In the remote procedure call, the test server acts as a client, and the client acts as a server.

[0040] Taking game software as an example, in the client, the related data of the game can be saved in the form of memory objects. Memory objects are usually used to indicate user accounts logged into the client, executable behaviors of user accounts, virtual resources related to user accounts, and virtual scenes related to user accounts, etc. Correspondingly, memory objects can be divided into user objects, behavior objects, resource objects, scene objects, etc. Memory objects usually have an association relationship. In general, the data related to the user account is bound to the user object corresponding to the user account in the form of the corresponding 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 from the binding relationship of the user object. The above data storage method is common in game clients, etc.

[0041] Step S106, executing a preset test case to control the client to perform the following operations: based on the binding relationship between a plurality of memory objects, finding a target memory object related to the to-be-tested function of the test branch from the client, calling a function bound to the target memory object, and executing the to-be-tested function through the function; wherein the memory object at least includes 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.

[0042] A preset test case can be executed, and the client can be controlled to execute the to-be-tested function through the communication mode of remote procedure call. The to-be-tested function usually involves a plurality of memory objects. The memory objects involved can be user objects of accounts logged into the client, or other various memory objects directly or indirectly bound to the user objects as described above.

[0043] The memory objects can be bound in various forms, such as a chain structure, a tree structure, and the like. The binding form can be set according to requirements, and is not limited herein. 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 be obtained from the test case, and the related data of the target memory object can be found according to the identifier and the binding relationship of the memory objects in the client. After the memory object is found, the function bound to the target memory object needs to be called to execute the function to be tested.

[0044] In step S108, the test result is determined based on the data generated by the function executing the function to be tested.

[0045] In the process of executing the function to be tested, a large amount of data is usually generated. The data can indicate whether an error is generated in the execution process of each function, and whether the related parameters of the user object change after the function is executed.

[0046] If an error is generated in the execution process of the function, and the change of the related parameters of the user object does not meet the expectation, it can be determined that the test result is failed. If the function is executed normally, and the change of the related parameters of the user object meets the expectation, it can be determined that the test result is successful.

[0047] In order to determine whether the change of the related parameters of the user object meets the expectation, the test case can give the expected result in advance. The expected result is usually a value determined by the test personnel who writes the test case when assuming that the function to be tested is implemented normally. In the process of calculating the expected result, some business data is usually used. For example, the function to be tested is to upgrade the user, and it is assumed that the user level has a corresponding relationship with the user points. The specific function to be 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 final user points become 50, the test is successful. The user points of 50 is regarded as an expected result.

[0048] In some cases, the user points of each level are stored in the client as business data. The client uses the stored business data to determine the user points after upgrading in the process of upgrading the user. The test case can calculate the expected result in advance, and read the user points corresponding to the user level implemented by the function to be tested from the client as the expected result. When the business data obtained by the client and the test personnel is inconsistent, this method will not affect the accuracy of the test result.

[0049] The data generated in the execution process of the function to be tested can be saved and a log file can be generated by saving and generating a log file in the execution process of the function to be tested. After the execution of the function to be tested, 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 failed.

[0050] The above-mentioned smoke testing method, in response to a smoke testing trigger 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; a communication between the 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 the binding relationship between the plurality of memory objects, the target memory object related to the function to be tested of the test branch is searched from the client, the function bound to the target memory object is called, and the function is executed to execute the function to be tested; based on the data generated by executing the function to be tested, the test result is determined. In this way, the function bound to the memory object related to the function to be tested is called by the client to execute the function to be tested, and then the data generated in the execution process can be used to determine whether the function to be tested can be normally implemented, thereby realizing the smoke testing of the code.

[0051] The following embodiments provide a specific way of establishing communication between the client deployed with the test branch.

[0052] The above-mentioned method is generally 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 a request to the server. The server executes the request and returns the result to the client. This mechanism allows the client to call functions on a remote server as if they were local functions, without worrying about the underlying network communication details. In remote procedure calls, the test server acts as a client, and the client acts as a server.

[0053] In some cases, the test server is also in communication connection with a specified server. The specified server is used to listen to 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 submission success. When the test server receives the notification message sent by the specified server, it is determined that a smoke testing trigger event occurs; further, the test server needs to obtain the code data of the test branch, and update the client deployed with the test branch based on the code data, and further test the function to be tested of the code through the updated client.

[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, for game software, the configuration parameters of values, scenes, and props in the game are controlled by the configuration table. All configuration tables of the game are converted from the original Excel file into a specified Python file, also known as a configuration table file. The configuration table file is usually pre-stored in the client. The data stored in the file is referred to as configuration 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, a name, an icon reference information, etc. The attributes are usually used to represent the type of the memory object. The effects are usually used to represent the impact on the user object if the memory object is applied to the user object. In some cases, the attributes also include the effects.

[0062] Since the configuration table data is the data actually applied to the client, compared with querying the configuration parameters and writing test cases, directly obtaining the configuration table data is more authentic and reliable. Therefore, the client usually needs to be controlled 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 corresponding to the to-be-tested function can be determined based on the configuration table data of the target memory object related to the to-be-tested function. For example, the life value of the user object is 100, and a virtual prop is added to the user object by executing the to-be-tested function. When the function is 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 configuration table data, the life value that can be added by the virtual prop is 50, and 100+50=150 is calculated. Therefore, 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, it is determined that the test result is successful. If the life value of the user object is other values, it is determined that the test result is failed. That is, the test result can be determined based on the data generated by the function executing the to-be-tested function and the expected result.

[0064] In order to analyze the data later, the test server obtains the data generated by executing the to-be-tested function based on the function in the client, and generates a log file based on the obtained data. The log file is used to save the data generated by the function executing the to-be-tested function. In addition to the case where the execution result of the to-be-tested function is wrong, the to-be-tested function may also be interrupted or deadlocked during execution. When the above-mentioned situations occur, error information is usually generated. The test server can parse the log file to extract 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-mentioned test error does not occur.

[0065] The embodiment of the present disclosure further provides another smoke test method. The method is implemented on the basis of the method shown in FIG. 1. The method provides a test mode capable of guaranteeing the reliability of a game software version in a development link of continuous integration.

[0066] The method marks the development branch repository to be monitored by the continuous integration unit, acquires the submission information each time by the SVN Hook, and stores the information in redis. The SVN hook refers to a script or program automatically called after the completion of an SVN operation (such as submission, update, merge, etc.). The continuous integration unit listens to the result of each submission. If the submission is successful, the smoke test task deployed on the continuous integration tool Jenkins is triggered. The smoke test task automatically updates the project repository on the deployment device, and starts the smoke test unit (usually set in the above-mentioned "test server") after the update is completed. 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 case. The test case drives the client code to execute the basic function through RPYC communication and records the execution log. After the execution is completed, the smoke test unit analyzes the execution log and obtains the error information. If there is error information, the test result is failure, otherwise, the test result 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 is successful, the continuous integration tool Jenkins executes the subsequent task. When the smoke test fails, the continuous integration unit notifies the submitter of the error information and terminates the Jenkins task.

[0067] The role of the continuous integration unit in the above-mentioned method is to mark the branch repository to be monitored, acquire the submission information, trigger the smoke test task, and perform the subsequent steps according to the smoke test result. The role of the smoke test unit is to execute the pre-set test case set according to different branch repositories, collect the execution log information, and return the test result.

[0068] As shown in FIG. 2, the continuous delivery process based on the automated smoke test mainly includes the following steps:

[0069] 1. The continuous integration unit marks the branch repository to be monitored.

[0070] Since a large project has different development branches, such as development branch, test branch, release branch, etc., the branch to be monitored for version reliability needs to be marked in advance. The monitoring of the branch is realized by the SVN hooks plug-in. When the branch is successfully submitted, the plug-in is configured to send a request to the continuous integration unit with the submission information as data, so that the continuous integration unit controls the monitoring.

[0071] 2. The continuous integration unit monitors the commit and stores the commit information in redis.

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

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

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

[0075] 4. The smoke test task executes the updated commit branch repository.

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

[0077] According to the incoming commit information, update the repository of the branch on the local deployment device of the task;

[0078] Start the smoke test unit with the commit information as the execution parameter;

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

[0080] 5. The smoke test task passes the commit information as an execution parameter to start the smoke test unit.

[0081] As described in step 4 above, this is an execution step for the smoke test task. This step will pass the commit information as an execution parameter to the smoke test unit to start the smoke test unit. The commit information must contain the committed branch, and the smoke test unit will determine and execute the test cases according to the branch.

[0082] 6. The smoke test unit executes the client of the branch and performs login.

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

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

[0085] After the login is completed, the smoke test unit connects to the client through the RPYC. RPYC is a Python remote call library that allows different Python processes to communicate and remotely call functions. This step requires the client to also install RPYC and serve as an RPYC server. The smoke test unit connects to the RPYC server, i.e., the client, as a client. After a successful connection, the smoke test unit executes the preset use case set according to different branches.

[0086] 8. The test case verifies the basic functions through the RPYC-driven client code and records the execution log.

[0087] The test case in the smoke test unit is actually a script containing a set of driven client code. The script executes the basic functions according to the preset driven client code. While executing the functions, the use case script records the execution log, which includes the execution success log and error information of execution failure, into a log file.

[0088] 9. The smoke test unit analyzes the execution log to obtain error information.

[0089] After the use case is executed, the smoke test unit analyzes the execution log of the use case to extract error information.

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

[0091] When there is error information, the smoke test fails, and the smoke test unit returns the error information and execution failure to the continuous integration unit as the result. When there is no error information, the smoke test succeeds, and the smoke test unit returns the execution success and empty error information to the continuous integration unit as the result. Meanwhile, the smoke test unit closes the client process.

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

[0093] After receiving the smoke test result, the continuous integration unit notifies the submitter who triggered this task. If the test result is successful, the submitter is notified of the success of the submission. If the test result is failed, the submitter is notified of the failure of the submission, and the error information is sent to him for repair.

[0094] 12. The continuous integration unit executes subsequent steps according to the smoke test result.

[0095] When the smoke test fails, the continuous integration unit terminates the Jenkins task and does not execute the subsequent continuous integration task. When the smoke test succeeds, the subsequent continuous integration task is executed.

[0096] In the examples of the present application, the commit information of the SVN repository is perceived and acquired through the SVN hooks plug-in, and the execution of the smoke test task is triggered through Jenkins. The smoke test unit executes the preset test cases of different branches through the commit information to meet the different basic functional requirements concerned by different branches. Meanwhile, the smoke test unit performs functions through the RPYC driven client, so that the basic functional test is more sufficient, comprehensive and stable. The continuous integration system quickly feeds back the verification of the basic functions to the submitter through the smoke test, thereby effectively ensuring the reliability of the submitted version.

[0097] Fig. 3 is a functional module diagram of the continuous delivery device based on the automated smoke test provided by the present application, which comprises:

[0098] The continuous integration unit 201 is mainly responsible for the following functions:

[0099] 1. Monitoring the commit of the specified branch repository and recording the commit information;

[0100] 2. Starting the smoke test unit;

[0101] 3. According to the smoke test result, notifying the submitter to execute or terminate the continuous integration step.

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

[0103] 1. Starting and logging in the local client of the specified branch;

[0104] 2. Connecting the client and executing the specified test cases;

[0105] 3. Collecting the test case execution log and returning the test result to the continuous integration unit.

[0106] Fig. 4 is a functional module diagram of the continuous integration unit 201, which comprises:

[0107] 2011. SVN plug-in module: The main function of this module is to enable the continuous integration unit to perceive the commit of the SVN branch repository, so as to analyze and process the current commit as necessary. The implementation of this module depends on the hooks of SVN itself, and its core function is the callback before or after the SVN commit. We can perceive the commit of the branch repository by configuring the hooks triggered after the commit.

[0108] 2012. Redis read-write module: The main function of this module is to store the commit information, so that each module of the continuous integration unit can obtain the required data when needed. As a widely used in-memory database, the read and write speed of Redis is very high, which is beneficial to the rapid completion of the overall test task by the unit.

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

[0110] 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 optional solutions, such as notification and alarm through SMS, email, or IM software.

[0111] This method quickly perceives the submission of the SVN repository through the SVN hooks plug-in and stores the submission information in redis, ensuring the circulation of 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.

[0112] Figure 5 is a functional module 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 the client process. When the smoke test unit is started, this module will start the corresponding branch client on the deployment device according to the incoming branch information; when the smoke test is completed, the started client will also be closed.

[0114] 2022, login module: The main function of this module is to automate the login process after the game process is started. The client of the game 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 normally experience the game content. Therefore, this module will log in a pre-set test account and log in to the specified server according to the incoming branch information to test and verify the function.

[0115] 2023, use case management module: The main function of this module is to establish an RPYC communication connection with the client, manage test cases, and record the logs of the use case execution. Since different branches focus on different basic functions, there will be different test cases, and this module will execute the pre-set test cases according to the incoming branch information. At the same time, this module will record the logs of the use case execution for subsequent analysis of the results of the smoke test.

[0116] 2024, log analysis module: the main function of this module is to analyze the error information in the collected log after the use case is executed, and return the result to the continuous integration unit according to whether there is error information as the smoke test.

[0117] In this method, the management and allocation of different branch test cases are executed to meet the testing needs of different branches for different basic functions. At the same time, by driving the client code through RPYC, the basic function test is more comprehensive and sufficient, and compared with traditional interface test and UI test, it is more suitable for function verification of game software.

[0118] Fig. 6 is a working principle diagram of the use case management module in the smoke test unit. Since the basic function of the game is verified, only a small part of the function can be tested by user input operation (such as movement, skill release, UI click, etc.), and many parts cannot be tested by simulating input (for example, the effect of Buff, the change of scene, the creation and destruction of unit, etc.). In order to meet the verification of these functions, the scheme proposes to establish a test case module driven by client code based on the characteristics of RPYC cross-process communication. The specific implementation is as follows:

[0119] Firstly, the client acts as the server of RPYC in the test link and listens to the specified port after the game starts. The use case management module of the smoke test unit acts as the RPYC client and connects to the game through 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 only the code modules in the game cannot meet the needs of function test, and there are two main problems:

[0120] Problem 1: how to know whether the numerical value change effect after testing in the game is consistent with the expectation, for example, after obtaining a certain prop, the character's numerical value changes, how does the test case judge that this change is correct;

[0121] Problem 2: only by calling the code modules in the game to create objects and execute code, there will be no actual effect, because the functions in the game are bound to the created memory objects in the form of components, and even if we create new objects, they will not produce effects in the existing memory objects.

[0122] In order to solve these two main problems, the following methods are used in this method:

[0123] For the above problem 1: Because the values, scenes, props, etc. in the game are controlled by the configuration table. For example, there are many types of props in the game, each with different names, effects, types, etc. But from the code point of view, the prop is actually a prop class, which has attributes such as name, effect, type, etc. The specific attributes of a certain prop are controlled by the prop table. All the configuration tables of the game will be converted from the original Excel file to the specified Python file, which is a compressed data table object. 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 writing numerical values in the test code.

[0124] After obtaining the complete data table information, the use case code compares the numerical changes before and after the use case operation with the results calculated by the data table information. If they are consistent, the numerical changes are as expected; otherwise, an error of inconsistent numerical values is thrown.

[0125] For the above problem 2: Since we need to test the specified object in memory, the primary goal is to locate the memory object, and in the smoke test, the most important memory object to locate is the current user object and the current scene object, which can meet the basic functional testing requirements. Here we use the memory management mechanism of Python. In the Python interpreter, objects are managed by the memory pool, and when the memory object is no longer referenced, it will be destroyed. The user object is one of the most basic objects in the game, and it 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 scheme, the memory object of the player class is located in the memory pool, and other associated module objects are located through the reflection mechanism, and then other objects such as prop objects and buff objects are located through the module object reflection.

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

[0127] In the use case management module of the smoke test unit, based on the RPYC communication, we first obtain the current latest data information by reading and parsing the configuration table. Then, by locating the player class in the memory pool, we locate other associated objects according to the tree-like relationship of the object in the memory. After locating the memory object required for testing, the function method of the object is called to test the game function. By comparing the test value with the result calculated from the data read in the configuration table, the correctness of the value can be found. Compared with the test based on user input, this test method is more suitable for the test scene of the game.

[0128] Compared with other existing solutions, the method realizes the monitoring of multiple development branches and records the submission information of each monitoring 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 execution function code, so as to cover the basic functions that cannot be covered by interface testing and UI testing, thereby realizing the smoke test more suitable for the game software. When the smoke test fails, the responsible person can be directly located according to the submission information, so as to promote the rapid repair of the problem branch version and ensure the reliability of the version.

[0129] For the above method embodiment, refer to a smoke test device shown in FIG. 7, which includes:

[0130] The test branch determination module 702 is configured 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 to-be-tested function of the test branch;

[0131] The communication establishment module 704 is configured to establish communication with the client deployed in the test branch; wherein the client saves a plurality of memory objects;

[0132] The client control module 706 is 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, find the target memory object related to the to-be-tested function of the test branch from the client, call the function bound to the target memory object, and execute the to-be-tested function through the function; wherein the memory object at least includes 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;

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

[0134] The smoke test device determines 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 corresponding to a function to be tested of the test branch, establishes communication with a client deployed in the test branch, the client storing a plurality of memory objects, executes the preset test case to control the client to perform the following operations: based on a binding relationship between the plurality of memory objects, the client finds a target memory object related to the function to be tested of the test branch, calls a function bound to the target memory object, and executes the function to execute the function to be tested; and based on data generated by the function executing the function to be tested, determines a test result. In this way, the function bound to the memory object related to the function to be tested is called by the client to execute the function to be tested, and then the data generated in the execution process can be used to determine whether the function to be tested can be normally implemented, thereby achieving smoke testing of the code.

[0135] The memory objects include a user object of a user account logged in the client and a plurality of first memory objects, the first memory objects being at least one of a behavior object, a resource object, and a scenario object, the user object and the plurality of first memory objects being bound in a tree structure, the user object being a root node of the tree structure, and the client control module being further configured to find the user object from the client and find, based on the user object and the tree structure by a preset reflection mechanism, a target memory object related to the function to be tested of the test branch from the client.

[0136] The client stores a configuration table file, the configuration table file including configuration table data of the plurality of memory objects, and the device further includes a configuration table data analysis module configured to control the client to analyze the configuration table file to obtain the configuration table data, the configuration table data including configuration parameters of the memory objects, and the configuration parameters being used to indicate at least one of an identifier, an attribute, and an effect of the memory object.

[0137] The test result determination module is further configured to determine an expected result corresponding to the function to be tested based on configuration table data of the target memory object related to the function to be tested, and determine the test result based on the data generated by the function executing the function to be tested and the expected result.

[0138] The device includes a test server, and 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 serving as the client and the client serving as a server.

[0139] The device includes a test server and a designated server; the test server is in communication connection with the designated server; the designated server is configured to: listen to a submission event of code data of a test branch, and after a submission result of the submission event is submission success, send a notification message to the test server; the device further includes a smoke test determination module configured to determine that a smoke test trigger event occurs in response to the test server receiving the notification message sent by the designated server; and a client updating module configured to cause the test server to obtain code data of the test branch and update a client deployed by the test branch based on the code data.

[0140] The test result determination module is further configured to: obtain data generated by executing the function to be tested during execution of the function to be tested by the client, generate a log file based on the obtained data; analyze the log file, and extract error information from the analysis result; and determine the test result based on the error information.

[0141] The embodiment also provides an electronic device including a processor and a memory, the memory storing machine executable instructions capable of being executed by the processor, and the processor executes the machine executable instructions to implement the smoke test method described above, for example:

[0142] In response to the smoke test trigger 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 between the test server and a client deployed by the test branch is established; the client stores 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 is executed to perform the function to be tested; and based on data generated by executing the function to perform the function to be tested, a test result is determined.

[0143] In the above manner, the function bound to the memory object related to the function to be tested is called to perform the function to be tested by controlling the client, and then it can be determined whether the function to be tested can be normally implemented based on the data generated during the execution, thereby achieving the smoke test of the code.

[0144] Optionally, the memory objects include a user object of a user account of the login client and a plurality of first memory objects; the first memory objects are at least one of the following: a behavior object, a resource object, and a scenario object; the user object and the plurality of first memory objects are bound in a tree structure; the user object is a root node of the tree structure; the step of finding, from the client, a target memory object related to the to-be-tested function of the test branch based on the binding relationship between the plurality of memory objects includes: finding, from the client, the user object; and finding, from the client, the target memory object related to the to-be-tested function of the test branch based on the user object and the tree structure through a preset reflection mechanism.

[0145] Optionally, the client stores a configuration table file; the configuration table file includes configuration table data of the plurality of memory objects; the method further includes: controlling the client to parse the configuration table file to obtain the configuration table data; and the configuration table data includes configuration parameters of the memory objects; the configuration parameters are used to indicate at least one of the following: an identifier, an attribute, and an effect of the memory object.

[0146] Optionally, the step of determining the test result based on the data generated by the function executing the to-be-tested function includes: determining an expected result corresponding to the to-be-tested function based on the configuration table data of the target memory object related to the to-be-tested function; and determining the test result based on the data generated by the function executing the to-be-tested function and the expected result.

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

[0148] Optionally, the method includes a test server and a specified server; the test server is in communication connection with the specified server; the specified server is configured to: listen to a submission event of code data of the 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 includes: determining, by the test server, that a smoke test triggering event occurs in response to receiving the notification message sent by the specified server; obtaining, by the test server, the code data of the test branch, and updating the client deployed in the test branch based on the code data.

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

[0150] Referring to FIG. 8, the electronic device includes a processor 100 and a memory 101 storing machine executable instructions executable by the processor 100 to implement the above-described smoking test method.

[0151] Further, the electronic device shown in FIG. 8 further includes a bus 102 and a communication interface 103, and the processor 100, the communication interface 103, and the memory 101 are connected through the bus 102.

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

[0153] The processor 100 can be an integrated circuit chip with signal processing capability. In implementation, each step of the above method can be completed by integrated logic circuits or instructions in the form of software in the processor 100. The processor 100 described above can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component. Each method, step and logic block diagram 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. The steps of the method disclosed in combination with the embodiments of the present disclosure can be directly embodied as a hardware code processor for execution, or a combination of hardware and software modules in the code processor for execution. The software module can be located in 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 in the art is mature. The storage medium is located in the memory 101, and the processor 100 reads the information in the memory 101, and combines the hardware to complete the steps of the method of the above embodiments.

[0154] The embodiment also 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 cause the processor to implement the above smoke test method.

[0155] The smoke test method, device and electronic equipment provided by the embodiments of the present disclosure include a computer readable storage medium storing program codes, and the instructions included in the program codes can be used to execute the method described in the foregoing method embodiments, for example:

[0156] In response to a smoking test trigger 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 between the client deployed with the test branch and the client is established; the client stores 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 is executed to test the function to be tested; and based on data generated by executing the function to test the function to be tested, a test result is determined.

[0157] In the above manner, the function bound to the memory object related to the function to be tested is called by the client to execute the function to be tested, and then it can be determined whether the function to be tested can be normally implemented based on the data generated in the execution process, thereby realizing the smoking test of the code.

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

[0159] Optionally, the client stores a configuration table file; the configuration table file includes configuration table data of the plurality of memory objects; and the method further includes: controlling the client to parse the configuration table file to obtain the configuration table data; the configuration table data includes configuration parameters of the memory objects; and the configuration parameters are used to indicate at least one of an identifier, an attribute, and an effect of the memory object.

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

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

[0162] Optionally, the method comprises a test server and a designated server; the test server is in communication connection with the designated server; the designated server is configured to: listen to a submission event of code data of the test branch, and after a submission result of the submission event is a submission success, send a notification message to the test server; 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 designated server; the test server acquires the code data of the test branch, and updates the client deployed by the test branch based on the code data.

[0163] Optionally, the step of determining the test result based on the data generated by executing the to-be-tested function comprises: acquiring the data generated by executing the to-be-tested function in the process of executing the to-be-tested function on the client, and generating a log file based on the acquired data; parsing the log file, and extracting error information from the parsing result; and determining the test result based on the error information.

[0164] 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 foregoing method embodiments, which will not be described here.

[0165] In addition, in the description of the embodiments of the present disclosure, unless otherwise explicitly specified and limited, the terms "mounting", "connection", "connecting" should be understood in a broad sense, for example, can be fixed connection, can also be detachable connection, or integral connection; can be mechanical connection, can also be electrical connection; can be direct connection, can also be indirect connection through an intermediate medium, can be internal communication of two elements. For those skilled in the art, the specific meaning of the above terms in the present disclosure can be understood according to the specific circumstances.

[0166] The function, if realized in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present disclosure essentially or say the part that contributes to the prior art or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in various embodiments of the present disclosure. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0167] In the description of the present disclosure, it should be explained that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer" and the like indicate the orientation or positional relationship 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, and do not indicate or imply that the devices or elements referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as a limitation on the present disclosure. In addition, the terms "first", "second", "third" are only for the purpose of description, and cannot be understood as indicating or implying relative importance.

[0168] Finally, it should be noted that the above embodiments are only specific embodiments of the present disclosure, used to illustrate the technical solutions of the present disclosure, and are not limiting, and the protection scope of the present disclosure is not limited thereto. Although the present 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 make modifications or easily think of changes to the technical solutions recorded in the foregoing embodiments within the technical range disclosed by the present disclosure, or make equivalent replacements to some of the technical features; and these modifications, changes or replacements do not cause the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present disclosure, and should be covered within the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be subject to 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