Smoke test method, device, electronic device and storage medium

Abstract

The present disclosure provides a smoking test method and device, electronic equipment and storage medium. 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 to-be-tested function of the test branch. Communication is established with a client deployed in the test branch. The preset test case is executed to control the client to perform the following operations: based on the binding relationship between a plurality of memory objects, a target memory object related to the to-be-tested function of the test branch is found from the client, a function bound to the target memory object is called, and the to-be-tested function is executed through the function; based on the data generated by executing the to-be-tested function, a test result is determined. In this way, by controlling the client to call the function bound to the memory object related to the to-be-tested function to execute the to-be-tested function, it can be determined whether the to-be-tested function can be normally implemented 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 technical field of testing, in particular to a smoke testing method and device, electronic equipment and storage medium. BACKGROUND

[0002] In the software development process, after the developer submits the code, the basic functions of the client through the code need to be verified, such as verifying whether the interface is basically correct, or verifying whether the basic functions are normal by clicking the graphical user interface. Such 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 relatively complex, and it is difficult to test them by using the above smoke testing method, so it is impossible to verify whether the code can normally implement the corresponding business functions. SUMMARY

[0003] Therefore, the purpose of the present disclosure is to provide a smoke testing method, device, electronic equipment and storage medium to realize smoke testing of the code.

[0004] In a first aspect, the embodiments of the present disclosure provide a smoke testing method, which comprises: 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 to-be-tested function 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, 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.

[0005] 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 in the test branch; wherein the client stores a plurality of memory objects; and a client control module configured to execute the preset test case to control the client to perform the following operations: based on 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 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; and determining a test result based on data generated by the function executing the function to be tested.

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

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

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

[0009] 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 in 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, 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 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 smoke testing of the code.

[0010] 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 description or can be learned by practice of the present disclosure. The purposes and other advantages of the present disclosure will be realized and attained by the structures particularly pointed out in the description, claims and drawings.

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

[0012] 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 for those skilled in the art, other drawings can also be obtained from these drawings without creative labor.

[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 test 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 by an embodiment of the present disclosure;

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

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

[0021] In order to make the purposes, technical solutions and advantages of the embodiments of the present disclosure clearer, the technical solutions of the present disclosure will be described clearly and completely below with reference to the drawings. Obviously, the described embodiments are some but not all of the embodiments of the present disclosure. Based on the embodiments in the present disclosure, all other embodiments obtained by those skilled in the art without creative work fall within the scope 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 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, it will inevitably affect the normal development, testing, acceptance and other links of other related technical personnel, and affect the overall efficiency of the team.

[0023] In the traditional software development process, a 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 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:

[0024] 1. The interface smoke and UI smoke of the 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;

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

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

[0027] Therefore, 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 requiring smoke testing.

[0028] In one possible implementation, the embodiments of the present disclosure provide a smoke testing method.

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

[0030] Step S102, in response to the 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.

[0031] The smoke test trigger event can be various. For example, a user can send a test request to the test server through a terminal device, thereby generating a smoke test trigger 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 smoke testing on the code data.

[0032] The smoke test trigger 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. After receiving the notification message sent by the specified server, the test server determines that the smoke test trigger event occurs. The user usually submits the code to the specified server, so the specified server can listen to 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 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 by smoke 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 tested by smoke from the data storage server, thereby updating the client.

[0034] 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 by smoke, the server needs to listen to the code data of the version.

[0035] For convenience, the version of the code data to be monitored is referred to as a test branch. The test branch to be monitored is usually set in a specified server. When the specified server detects a commit event of the code data of the test branch and the commit event is successful, a notification message is sent to the test server. If the specified server is a server storing the code data, the code data of the test branch can also be sent to a data storage server, so that the test server can 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] In step S104, communication with the client deployed with the test branch is established; and the client stores a plurality of memory objects.

[0037] If a smoke test triggering event occurs, communication with the client deployed with the test branch is required. When there are a plurality of branches and a corresponding client is deployed for each branch, the client corresponding to the test branch is determined as a target client, and communication with the target client is established.

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

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

[0040] Step S106, 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 to-be-tested function of the test branch is found from the client, the 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, an executable behavior of the user account, a virtual resource related to the user account, and a virtual scene related to the user account.

[0041] The 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 a user object of an account logged into the client, or other various memory objects directly or indirectly bound to the user object as described above.

[0042] The memory objects can be bound in various forms, such as chain structure, tree structure, etc. The specific setting can be made according to the needs, which is not limited here. In the process of finding the target memory object related to the to-be-tested function of the test branch, the identifier of the target memory object can usually be obtained from the test case, and then the related data of the target memory object can be found from 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 to-be-tested function through the function.

[0043] Step S108, based on the data generated by the function executing the to-be-tested function, the test result is determined.

[0044] In the execution process of the to-be-tested function, a large amount of data is usually generated. These data can indicate whether an error is generated in the execution process of each function called, and whether the change of the related parameters of the user object after the function is executed is as expected.

[0045] If an error is generated in the execution process of the function, and the change of the related parameters of the user object is not as expected, it can be judged that the test result is failed. If the function is executed normally, and the change of the related parameters of the user object is as expected, it can be judged that the test result is successful.

[0046] In order to determine whether the change of the relevant parameters of the user object meets the expectation, the test case can give the expected result in advance, which is usually a 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 will usually be 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 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 above-mentioned user points of 50 are regarded as an expected result.

[0047] In some cases, the user points of each level are stored as business data in the client. 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. This way will not affect the accuracy of the test result when the business data obtained by the client and the tester may be inconsistent.

[0048] 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 in the execution process 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 failed.

[0049] The above-mentioned smoke test method determines 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; a communication between the test branch and the client deployed 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 controlling 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 test of the code.

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

[0051] The above method is usually applied to test a server. When a test of a function to be tested is needed, the test server needs to establish a remote procedure call with a client. In the 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 enables the client to call functions on a remote server as if they were local functions, without having to worry about the underlying network communication details. In the remote procedure call, the test server acts as a client, and the client acts as a server.

[0052] In some cases, the test server is also in communication connection with a specified server. The specified server is configured to listen to a submission event of the code data of the test branch, and send a notification message to the test server after a submission result of the submission event is a submission success. When the test server receives the notification message sent by the specified server, it is determined that a smoke test triggering event occurs; further, the test server needs to obtain the code data of the test branch, and update the client deployed by the test branch based on the code data, and further can test the function to be tested of the code through the updated client.

[0053] In a specific implementation, a continuous integration tool Jenkins can be used to listen to the code submission event. When a relevant person submits the latest code to the version library, the specified server deployed with Jenkins will automatically pull the latest package from Git (a kind of open source distributed version control system) / SVN (an abbreviation of subversion, which is an open source version control system), and then redeploy, so that the latest code can be used in the test process.

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

[0055] The memory object is usually a user object of a user account of a client and a plurality of other memory objects bound thereto. For the convenience of writing, the other memory objects are referred to as first memory objects. The first memory objects can be behavior objects, resource objects and scene objects. The user object and the plurality of first memory objects are bound in a tree structure, and the user object is the root node of the tree structure.

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

[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 prop 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 find the target memory object from the client based on the user object and the tree structure through the preset reflection mechanism. The target memory object related to the function to be tested can be multiple or one, which is not limited here. Among them, the Java reflection mechanism is to call any method and attribute of any object in the running state; 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 way of processing response data through 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 values, scenes, and props in the game are controlled through a configuration table. All configuration tables of the game are converted from an 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 saved in the file is called 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 category of the memory object; the effects are usually used to represent what impact the memory object will have on the user object if it is applied to the user object. In some cases, the attributes also include the effects.

[0061] 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, so it is usually necessary to control the client to parse the configuration table file to obtain the configuration table data, and then obtain the configuration parameters of the memory object from the configuration table data.

[0062] The expected result corresponding to the function to be tested can be determined based on the matching 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 matching 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 a failure. 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 errors occur in the execution results of the function to be tested, errors such as interruption or freezing during the execution of the function to be tested may also occur. 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 results, and then determine the test results 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 This method provides a testing method that can ensure the reliability of game software versions during the continuous integration development process.

[0065] This method uses a continuous integration unit to mark the development branch repository that needs to be monitored, obtains each commit information through the SVN Hook, and stores it in Redis. The SVN hook refers to a script or program that is automatically called after an SVN operation (such as commit, update, merge, etc.) is completed. The continuous integration unit monitors the results of each commit. If the commit 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, after the update is complete, starts the smoke test unit (usually set in the aforementioned "test server"). The smoke test unit automatically starts the client for that branch and completes the login process; the smoke test unit connects to the client via RPYC and executes pre-set test cases; the test cases communicate via RPYC, drive the client code to perform basic functions, and record the execution log; after execution, the smoke test unit analyzes the execution log to obtain error information. If there is an error, the test result is a failure, otherwise it is a success; the smoke test unit obtains the commit information from the commit 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 pre-set 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] Because large projects often have different development branches, such as development, testing, and release branches, it's necessary to pre-mark branches for version reliability monitoring. Branch monitoring is implemented using the SVN hooks plug-in. When a branch is successfully committed, the plug-in's configuration uses the commit information as data and sends a request to the continuous integration unit, which then controls 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 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.

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

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

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

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

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

[0077] Pass the commit information as an execution parameter to start the smoke test unit;

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

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

[0080] As described in step 4 above, it is an execution step for the smoke test task. This step passes the commit information as an execution parameter to the smoke test unit to start the smoke test unit. The commit information must contain the branch of the commit, and the smoke test unit determines and executes the test case according to the branch.

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

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

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

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

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

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

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

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

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

[0090] When there is error information, the smoke test fails, and the smoke test unit returns the error information and execution failure as the result to the continuous integration unit. When there is no error information, the smoke test succeeds, and the smoke test unit returns the execution success and empty error information as the result to the continuous integration unit. Meanwhile, 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 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 sent the error information thereof, which is responsible for repairing.

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

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

[0095] 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 to more fully, comprehensively and stably perform the basic function test. The continuous integration system feeds back the verification of the basic functions to the submitter through the smoke test, thereby effectively guaranteeing the reliability of the submitted version.

[0096] Figure 3 A functional module diagram of a continuous delivery device based on automatic smoke test provided by the present application, the device comprising:

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

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

[0099] 2. Starting the smoke test unit;

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

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

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

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

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

[0105] Figure 4 A functional module diagram of the continuous integration unit 201, the unit comprising:

[0106] 2011. The SVN plug-in module: the main function of the 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 the module depends on the hooks of the SVN itself, and the 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.

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

[0108] 2013, Jenkins module: the main function of this module is to arrange the continuous integration task pipeline, so that the entire continuous integration link is 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 submission. When the smoke test task fails, we can use the features of Jenkins to terminate the current task pipeline and not execute the 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 optional solutions, such as sending notifications and alarms through SMS, email, or IM software.

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

[0111] Figure 5 The function module diagram of the smoke test unit 202 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, this module will start the corresponding branch client on the local deployment device according to the incoming branch information; when the smoke test is completed, the started client will also be closed.

[0113] 2022, login module: the main function of this module is to automatically complete the login link 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.

[0114] 2023, use case management module: the main function of this module is to establish RPYC communication connection with the client, manage test cases, and record the log of case execution. Because different branches pay attention to different basic functions, there will be different test cases, and this module will execute the preset test cases according to the incoming branch information. At the same time, this module will record the log of case execution, which will be used for subsequent analysis of smoke test results.

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

[0116] In this method, by managing and distributing the execution of different branch test cases, the testing needs of different branches for different basic functions are met. At the same time, by driving the client code through RPYC, the basic function test is more comprehensive and sufficient, which is more suitable for function verification of game software compared with traditional interface test and UI test.

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

[0118] 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 the 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:

[0119] Problem 1: how to know whether the numerical value change effect after testing in the game meets 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;

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

[0121] To solve these two main problems, the method is solved by the following method:

[0122] 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 properties such as name, effect, type, etc. The specific properties of a certain prop are controlled by the prop table. All the configuration tables of the game are 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.

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

[0124] 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 a 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 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.

[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 the RPYC communication, we first obtain the current latest data information by reading and analyzing the configuration table. Then, we locate the player class object in the memory through the memory pool, and 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.

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

[0128] For the above method embodiment, refer to Figure 7 The device includes:

[0129] The test branch determination module 702 is configured to determine a test branch and a preset test case corresponding to the test branch in response to a smoke test trigger event; and the preset test case corresponds to a to-be-tested function of the test branch.

[0130] The communication establishment module 704 is configured to establish communication with a client deployed in the test branch; and the client stores a plurality of memory objects.

[0131] The client control module 706 is 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, the client finds a target memory object related to the to-be-tested function of the test branch from the client, calls a function bound to the target memory object, and executes the to-be-tested function through the function; and 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.

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

[0133] 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 corresponds to a function to be tested of the test branch; communication between the client deployed in 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 test the function; and a test result is determined based on data generated by executing the function to test the function. In this way, the function bound to the memory object related to the function to be tested is called 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 smoke testing of the code.

[0134] The memory object includes a user object of a user account logged in the client and a plurality of first memory objects; the first memory object is 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 client control module is further configured to search 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.

[0135] The client stores a configuration table file; the configuration table file includes configuration table data of the plurality of memory objects; 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 includes configuration parameters of the memory object; and the configuration parameters are used to indicate at least one of an identifier, an attribute and an effect of the memory object.

[0136] The test result determination module is further configured to determine 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 determine the test result based on the data generated by executing the function to test the function and the expected result.

[0137] 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 acts as the client, and the client acts as a server.

[0138] The device 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 a test branch, and send a notification message to the test server after a submission result of the submission event is submission success; the device further comprises a smoke test determination module configured to determine that a smoke test triggering 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 acquire code data of the test branch and update a client deployed by the test branch based on the code data.

[0139] The test result determination module is further configured to acquire 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 acquired data, parse the log file, extract error information from the parsed result, and determine the test result based on the error information.

[0140] The embodiment also provides an electronic device comprising a processor and a memory, wherein the memory stores 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:

[0141] In response to the 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 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.

[0142] 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 achieving smoke test of the code.

[0143] Optionally, the memory object comprises a user object of a user account of the client and a plurality of first memory objects; the first memory object is 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; 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, comprising: the user object is searched from the client; and based on the user object and the tree structure, the target memory object related to the function to be tested of the test branch is searched from the client through a preset reflection mechanism.

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

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

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

[0147] 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 the code data of the test branch, and send a notification message to the test server after a submission result of the submission event is a submission success; the method further includes: 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 the code data of the test branch, and updates the client deployed in the test branch based on the code data.

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

[0149] Referring to Figure 8 The electronic device shown in the figure includes a processor 100 and a memory 101, the memory 101 storing machine executable instructions capable of being executed by the processor 100, and the processor 100 executes the machine executable instructions to implement the above-mentioned smoke test method.

[0150] Further, Figure 8 The electronic device shown in the figure 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.

[0151] The memory 101 can include a random access memory (RAM) and can also 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 realized 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, an EISA bus, etc. The bus can 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 to represent the bus in the figure, but it does not mean that there is only one bus or only one type of bus.

[0152] The processor 100 can be an integrated circuit chip with signal processing capability. In the implementation process, each step of the above method can be completed by the integrated logic circuit of hardware in the processor 100 or the instruction in the form of software. The processor 100 described above 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. Each method, step and logic block 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 coding processor for execution, or a combination of hardware and software modules in the coding 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, an electrically erasable programmable memory, a register, or other mature storage media in the art. 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.

[0153] 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 smoking test method.

[0154] The method, device and electronic equipment provided by the embodiments of the present disclosure include a computer readable storage medium storing program codes, and the program codes include instructions for executing the method described in the foregoing method embodiments, for example:

[0155] In response to a 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 client deployed in 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; and based on data generated by executing the function to test the function, a test result is determined.

[0156] 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 smoke test of the code.

[0157] Optionally, the memory object includes a user object of a user account logged in the client and a plurality of first memory objects; the first memory object is 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 searching 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 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; the configuration table data includes configuration parameters of the memory object; the configuration parameters are used to indicate at least one of the following: an identifier, an attribute and an effect of the memory object.

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

[0160] Optionally, the method comprises a test server; and a 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 the client and the client acts as the server.

[0161] Optionally, the method comprises a test server and a designated server; the test server is communicatively connected with the designated server; the designated 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 a 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 designated server; the test server acquires the code data of the test branch, and updates the client deployed in the test branch based on the code data.

[0162] Optionally, the step of determining the test result based on the data generated by the function executing the to-be-tested function comprises: acquiring the data generated by the function executing the to-be-tested function in the process of the client executing the to-be-tested function, and generating a log file based on the acquired data; parsing the log file, and extracting error information from a 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 foregoing method embodiments, which will not be described here.

[0164] In addition, in the description of the embodiments of the present disclosure, unless otherwise explicitly specified and limited, the terms "mounting", "connecting", "connecting" should be understood in a broad sense, for example, it can be fixedly connected, or it can be detachably connected, or integrally connected; it can be mechanically connected, or it can be electrically connected; it can be directly connected, or it can be indirectly connected through an intermediate medium; it can be the communication inside 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.

[0165] If the functions are implemented in the form of software function units and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present disclosure can be embodied in the form of a software product, which is stored in a storage medium and includes a number 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 methods described in various embodiments of the present disclosure. The aforementioned 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 program code storage media.

[0166] In the description of the present disclosure, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer" and the like indicate the orientation or positional relationship shown in the drawings, and are only for the purpose of facilitating the description of the present disclosure and simplifying the description, and do not indicate or imply that the device or element 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.

[0167] 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 not to limit them, 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: any person skilled in the art within the technical range disclosed by the present disclosure, they can still modify or easily think of changes to the technical solutions recorded in the foregoing embodiments, or make equivalent replacement to part of the technical features; and these modifications, changes or replacements do not make the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present disclosure, and all 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 characterized by, The method comprises: In response to a smoking 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 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 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; Based on the data generated by executing the function to perform the function to be tested, determine the test result.

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, comprises: Finding the user object from the client; Based on the user object and the tree structure through a preset reflection mechanism, finding a target memory object related to the function to be tested of the test branch from the client.

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: identification, attributes, and effects 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, determine the test result, comprising: Based on the configuration data of the target memory object related to the function to be tested, determine the expected result corresponding to the function to be tested; Based on the data generated by executing the function to perform the function to be tested and the expected result, determine the test 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 used to listen to a submission event of code data of a test branch, and after the submission result of the submission event is 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 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 parsing result; The test result is determined based on the error information.

8. A smoking test device characterized by, The apparatus comprises: A test branch determination module is 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 is configured to establish communication with a client deployed by the test branch; the client stores a plurality of memory objects; A client control module is 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, 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; 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; A test result determination module is 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: The apparatus comprises a processor and a memory, the memory stores 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, characterized in that, The machine readable storage medium stores machine executable instructions, and when the machine executable instructions are called and executed by the processor, the machine executable instructions cause the processor to implement the smoke test method of any one of claims 1-7.

Images