Application development test processing method, system, device and equipment and storage medium

By receiving development test requests during application development, determining the testing phase and methods, conducting comprehensive testing and information merging, the problems of missed testing and low development efficiency in the existing technology are solved, and an efficient development test closed loop is achieved.

CN119883873APending Publication Date: 2025-04-25TENCENT TECHNOLOGY (SHENZHEN) CO LTD
View PDF 0 Cites 1 Cited by

Patent Information

Application Number
CN202311354205.5
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2023-10-18
Publication Date
2025-04-25

AI Technical Summary

Technical Problem

During the development process of existing application programs, the development and testing process lacks a closed-loop mechanism, and QA tests are mostly black box tests, which often lead to missed testing, affecting application stability and development efficiency.

Method used

Provides an application development test processing method, which can obtain relevant development branches and server environments by receiving development test requests, determine the test stage and corresponding test types and methods, conduct comprehensive testing of code files, merge different versions of test information, and display the target code files and their test information.

Benefits of technology

It realizes the deployment of different test methods in different testing stages, reduces missed testing, improves development and testing efficiency, and ensures the comprehensive and accurate testing.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119883873A_ABST
    Figure CN119883873A_ABST
Patent Text Reader

Abstract

The invention relates to an application development test processing method, system, device and equipment. The method comprises the steps of obtaining development branches of an application program associated with an application development test request and server environments deployed by the development branches, and determining test stages of the application development test request, test types matched with the test stages and test methods matched with the test types, and respectively calling each test method matched with the corresponding test type in each test stage, and carrying out test processing on the code file of each development branch in each deployed server environment to obtain test information files of different development branches in each server environment. Extracting a first version identifier to which each test information file belongs, combining the test information files of different first version identifiers to obtain a branch test information file, and displaying a target code file corresponding to a second version identifier to which the branch test information file belongs and the corresponding branch test information file, by adopting the method, the test can be ensured to be comprehensive and accurate.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to an application development test processing method, system, device, computer equipment, storage medium and computer program product. Background Art

[0002] With the development of computer technology and the promotion and use of various applications, in order to meet different needs in actual use or maintain the normal use of applications, it is necessary to improve the functions of applications or fix problems. When adding new functions or fixing problems for applications, it is usually necessary to re-develop and test them to confirm whether the functional requirements are met or whether the problems are fixed.

[0003] In traditional technology, during the application development process, developers are usually required to write code according to actual needs, and testers are required to perform QA testing (i.e. Quality Assurance testing) on ​​the written code to determine whether the developed application meets the development requirements, such as whether the new functions meet the requirements, whether the application can run normally, and whether the problems existing during the operation are fixed.

[0004] However, in the current application development process, the development process and the testing process have not formed a closed-loop mechanism, and QA tests are mostly black-box tests. For example, multiple services and multiple interfaces are connected in series to complete the test of a certain scenario. It mainly simulates client calls (such as apps, or H5 pages, or web pages) to deploy end-to-end tests of real services, and the test cases and the objects under test are in different processes. Therefore, missed tests are prone to occur. In addition, since black-box testing cannot clearly know the specific test process, missed tests cannot be discovered in time when they occur, and there is a risk of application instability. The development and testing processing efficiency in the application development process still needs to be improved. Summary of the invention

[0005] Based on this, it is necessary to provide an application development and testing processing method, device, computer equipment, computer-readable storage medium and computer program product that can improve the development and testing processing efficiency in the application development process in response to the above technical problems.

[0006] In a first aspect, the present application provides an application development test processing method, comprising:

[0007] Receive an application development test request, and obtain a development branch of an application program associated with the application development test request, and each server environment where the development branch is deployed;

[0008] Acquire the test phase that triggers the application development test request, and determine the test type that matches each of the test phases, and the test method that matches the test type;

[0009] Invoke each test method matching the corresponding test type in each test phase, perform test processing on the code files of each development branch in each deployed server environment, and obtain test information files of different development branches of the application in each server environment;

[0010] Extracting the first version identifier of the code file to which each of the test information files belongs, and merging the test information files belonging to different first version identifiers to obtain a merged branch test information file;

[0011] A second version identifier corresponding to the branch test information file and a target code file corresponding to the second version identifier are obtained, and the target code file and its corresponding branch test information file are displayed.

[0012] In a second aspect, the present application also provides an application development test processing system, including a request client and a test server; wherein:

[0013] The request client is used to trigger an application development test request and send the application development test request to a test server;

[0014] The test server is used to: receive the application development test request, and obtain the development branch of the application program associated with the application development test request, and each server environment deployed by the development branch; obtain the test phase that triggers the application development test request, and determine the test type matching each test phase, and the test method matching the test type; call each test method matching the corresponding test type in each test phase, respectively, test and process the code file of each development branch in each deployed server environment, and obtain the test information file of different development branches of the application program in each server environment; extract the first version identifier of the code file to which each test information file belongs, and merge the test information files belonging to different first version identifiers to obtain the merged branch test information file; obtain the second version identifier corresponding to the branch test information file, and the target code file corresponding to the second version identifier, and display the target code file and its corresponding branch test information file.

[0015] In a third aspect, the present application also provides an application development test processing device, comprising:

[0016] An application development test request receiving module, used to receive an application development test request, and obtain a development branch of an application program associated with the application development test request, and each server environment where the development branch is deployed;

[0017] A test method determination module, used to obtain the test phase that triggers the application development test request, and determine the test type matching each of the test phases, and the test method matching the test type;

[0018] A test information file acquisition module, used to call each test method matching the corresponding test type in each test phase, perform test processing on the code file of each development branch in each deployed server environment, and obtain the test information file of different development branches of the application in each server environment;

[0019] A test information file merging module, used to extract the first version identifier of the code file to which each of the test information files belongs, and merge the test information files belonging to different first version identifiers to obtain a merged branch test information file;

[0020] The display module is used to obtain the second version identifier corresponding to the branch test information file and the target code file corresponding to the second version identifier, and display the target code file and its corresponding branch test information file.

[0021] In a fourth aspect, the present application provides a computer device, wherein the computer device comprises a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the steps of the above-mentioned application development test processing method are implemented.

[0022] In a fifth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of the above-mentioned application development test processing method are implemented.

[0023] In a sixth aspect, the present application provides a computer program product, wherein the computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the above-mentioned application development test processing method are implemented.

[0024] In the above-mentioned application development test processing method, system, device, computer equipment, storage medium and computer program product, by obtaining the development branch of the application associated with the received application development test request and the server environments deployed by the development branch, and obtaining the test phase that triggers the application development test request, the test type matching each test phase and the test method matching the test type are determined. Among them, by calling each test method matching the corresponding test type in the test phase, the code file of each development branch is tested in each deployed server environment, and the test information file of different development branches of the application in each server environment is obtained, so that different test methods can be deployed in different test phases, so as to achieve full and comprehensive testing of the code file, reduce missed tests, and avoid repeated tests due to missed tests, thereby improving the efficiency of application development testing. Furthermore, by extracting the first version identifier of the code file to which each test information file belongs, and merging each test information file belonging to different first version identifiers, the merged branch test information file is obtained, so that the test information files of code files of different versions can be concentrated, avoiding the omission of new code files in a certain version, so as to accurately count the test information of code files of different development branches. By obtaining the second version identifier corresponding to the branch test information file and the target code file corresponding to the second version identifier, the target code file and its corresponding branch test information file can be displayed, so as to accurately obtain the test information of each target code file under different branches, and timely confirm the test progress of different development branches, thereby ensuring the comprehensiveness and accuracy of the test, and further improving the development and test processing efficiency in the application development process. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments or the related technical descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0026] Figure 1 An application environment diagram of an application development test processing method in one embodiment;

[0027] Figure 2 A flowchart of an application development test processing method in one embodiment;

[0028] Figure 3 is a schematic diagram of test types and test methods corresponding to different test phases in one embodiment;

[0029] Figure 4A schematic diagram of test types and test methods corresponding to the development self-test stage in one embodiment;

[0030] Figure 5 A schematic diagram of coverage rates corresponding to different test methods in an embodiment;

[0031] Figure 6 A schematic diagram of a test information file of a development branch of an application program in one embodiment;

[0032] Figure 7 A schematic diagram of coverage of a development branch in one embodiment;

[0033] Figure 8 A schematic diagram of a target code file after chaos processing in one embodiment;

[0034] Fig. 9 A schematic diagram of a flow chart of obtaining test information files of different development branches of an application program in each server environment in one embodiment;

[0035] Fig.10 A schematic diagram of a process for obtaining a test information file in one embodiment;

[0036] Fig.11 A flowchart of a test processing method for application development in another embodiment;

[0037] Fig.12 A schematic diagram of synchronizing the merged test information file to the R&D environment in one embodiment;

[0038] Fig.13 A schematic diagram of a process of displaying a target code file and its corresponding branch test information file in one embodiment;

[0039] Fig.14 A schematic diagram of a flow chart of obtaining a second sub-test information file in each server environment for different development branches of an application program in one embodiment;

[0040] Fig.15 A schematic diagram of an entry interface of a game service webpage in one embodiment;

[0041] Fig.16 A schematic diagram of a test interface of a game service webpage in one embodiment;

[0042] Fig.17 A schematic diagram of a process of obtaining a second sub-test information file by calling a web page interactive game service test method in one embodiment;

[0043] Fig.18 A schematic diagram of a process for determining a target code file associated with a game service instruction in one embodiment;

[0044] Fig.19 A schematic diagram of an interface for querying game service instructions based on a game service instruction storage component in one embodiment;

[0045] Fig. 20 A schematic diagram of the format of a game service instruction in one embodiment;

[0046] Fig.21 A flowchart of an application development test processing method in another embodiment;

[0047] Fig. 22 A schematic diagram of an execution result corresponding to a request execution logic in one embodiment;

[0048] Fig.23 A flowchart of an application development test processing method in another embodiment is provided;

[0049] Fig.24 A schematic diagram of the architecture of an application development test processing system in one embodiment;

[0050] Fig.25 A structural block diagram of an application development test processing device in one embodiment;

[0051] Fig.26 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0052] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0053] The application development test processing method provided in the embodiment of the present application specifically relates to computer processing technology, which can be applied to various scenarios such as cloud technology, artificial intelligence, smart transportation, network media, and assisted driving, and can be specifically applied to Figure 1In the application environment shown. Among them, the request client 102 communicates with the test server 104 through the network. The data storage system can store the data that the test server 104 needs to process. The data storage system can be set separately, can be integrated on the test server 104, or can be placed on the cloud or other network broadcast control servers. Among them, the request client 102 can be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, Internet of Things devices, portable wearable devices, and aircraft, etc. The Internet of Things devices can be smart speakers, smart TVs, smart car-mounted devices, etc. Portable wearable devices can be smart watches, smart bracelets, head-mounted devices, etc. The test server 104 can be an independent physical broadcast control server, or a broadcast control server cluster composed of multiple physical broadcast control servers, or a cloud broadcast control server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms and other basic cloud computing services. The request client 102 and the test server 104 can be directly or indirectly connected by wired or wireless communication, which is not limited in the embodiments of the present application.

[0054] Among them, both the request client 102 and the test server 104 can be used separately to execute the application development test processing method provided in the embodiment of the present application, and the request client 102 and the test server 104 can also cooperate to execute the application development test processing method provided in the embodiment of the present application. For example, taking the request client 102 and the test server 104 to cooperate to execute the application development test processing method provided in the embodiment of the present application as an example, the request client 102 triggers the application development test request and sends the application development test request to the test server 104. The test server 104 is used to receive the application development test request and obtain the development branch of the application associated with the application development test request, and each server environment deployed by the development branch. Secondly, the test server 104 obtains the test phase that triggers the application development test request, and determines the test type that matches each test phase, and the test method that matches the test type, so as to call each test method that matches the corresponding test type in each test phase, respectively, and test the code files of each development branch in each deployed server environment to obtain the test information files of different development branches of the application in each server environment. Furthermore, the test server 104 extracts the first version identifier of the code file to which each test information file belongs, merges the test information files belonging to different first version identifiers, obtains the merged branch test information file, and obtains the second version identifier corresponding to the branch test information file, and the target code file corresponding to the second version identifier, so as to display the target code file and its corresponding branch test information file on the requesting client 102.

[0055] In an exemplary embodiment, Figure 2 As shown, a method for processing application development tests is provided, which is applied to Figure 1 Taking the test server 104 in the example as an example, the method includes the following steps S202 to S210. Among them:

[0056] Step S202: receiving an application development test request, and obtaining a development branch of an application program associated with the application development test request, and each server environment where the development branch is deployed.

[0057] Among them, during the development and testing process of applications (such as game applications, social applications, and multimedia applications, etc.), different development branches need to be set up according to different actual application requirements or different problems that need to be fixed. That is, different development branches correspond to different application versions, and different application versions correspond to different code files.

[0058] Different development branches of the application are deployed with different server environments. For example, the development branches include the development trunk, stable branches, and repair branches, which correspond to the code files of the development version, stable version, and repair version of the application. Among them, each development branch is deployed with a development self-test server environment, a quality test service environment, and a stable delivery service environment. The development self-test service environment can be used to implement the test processing in the development self-test phase, the quality test service environment can be used to implement the test processing in the quality test phase, and the stable delivery service environment is used to perform fault testing on the stable version of the code files to determine whether there are problems.

[0059] Specifically, the test server receives an application development test request triggered by a requesting client, and obtains the development branch of the application program associated with the application development test request, such as a development trunk, a stable branch, or a repair branch, and further determines the server environments deployed by the development branch, including a development self-test server environment, a quality testing service environment, and a stable delivery service environment.

[0060] Step S204, obtaining the test phase that triggers the application development test request, and determining the test type that matches each test phase and the test method that matches the test type.

[0061] Specifically, the test phase of the application development test request specifically includes the development self-test phase, and the test types include the same-process code test and the same-process module integration test corresponding to the development self-test phase, and the test methods include the unit test method corresponding to the same-process code test and the object simulation test method corresponding to the same-process module integration test. Similarly, the test phase of the application development test request also includes the quality test phase, and the test types include the single-service interface asynchronous test and the multi-service multi-interface asynchronous test corresponding to the quality test phase, and the test methods include the game service test method based on web page interaction corresponding to the single-service interface asynchronous test and the application program test method corresponding to the multi-service multi-interface asynchronous test.

[0062] Furthermore, the development self-test phase is located before the quality test phase, that is, it is necessary to fully conduct development self-test before switching to quality testing. Specifically, in the development self-test phase, by calling the unit test method corresponding to the same-process code test and the object simulation test method corresponding to the same-process module integration test, the code files of each development branch are tested in each deployed server environment.

[0063] Among them, the same-process code test means testing the methods and classes of the application's code files. It only depends on the code files being tested, and uses the method of testing the tested object and the test case in the same process to test the application's code files. Usually, the execution time of a single test case is set to within 1 second. The same-process module integration test means the integration verification between the modules within the service. In addition to relying on the code files being tested (including testing the methods and classes of the code files being tested), it further relies on local resources (including local databases, local file systems, and same-process simulation objects, etc.), and the test cases and the tested services (including code files and local resources) are also in the same process, that is, the test cases and the tested services are tested in the same process, and the execution time of a single test case is usually set to within 3 seconds.

[0064] Unit testing method (i.e. unit testing) refers to checking and verifying the smallest testable unit in an application. A "unit" can be a function, method, class, functional module or subsystem. The unit testing methods include: static checking (also known as code walking), which is used to check the code file to ensure the correctness of the code logic; dynamic execution, which is to check whether the actual running results are consistent with the expected results by running the code file of the application. The object simulation testing method (i.e. mock testing) means that during the testing process, for some objects that are not easy to construct or obtain, a mock object is created to simulate the behavior of the object. For example, if service B needs to be called, but service B has not been developed, the undeveloped part of service B can be mocked to simulate the call to the undeveloped part of service B to obtain the required return result and complete the test for calling service B.

[0065] Specifically, the unit testing method can be used to test the smallest testable unit (such as code lines, functions, methods, and classes, etc.) in the code files of each development branch, while the object simulation testing method can be used to simulate the different methods or classes in the code files that construct the application, so that the application's code files can be fully and comprehensively self-tested through object simulation testing even when the development is not completed.

[0066] For example, Figure 3 As shown, a schematic diagram of the test types and test methods corresponding to different test stages is provided. Figure 3 It can be seen that the testing stages of the application development test request specifically include the development self-test stage and the quality test stage. The test types include the same-process code test and the same-process module integration test corresponding to the development self-test stage, the single service interface asynchronous test and the multi-service multi-interface asynchronous test corresponding to the quality test stage. The testing methods include the unit testing method corresponding to the same-process code test, the object simulation testing method corresponding to the same-process module integration test, and the web page interaction-based game service testing method corresponding to the single service interface asynchronous test, and the application program testing method corresponding to the multi-service multi-interface asynchronous test.

[0067] Specifically, refer to Figure 3It can be seen that the quality test phase is located after the development self-test phase. After the development self-test phase performs the test processing, the test results of the development self-test phase are fed back to the quality test phase, and the test processing continues to be performed in the quality test phase. Among them, the same-process code test and the same-process module integration test corresponding to the development self-test phase are white-box tests, which focus on testing the logic, exceptions and boundaries of the application code files, while the single-service interface asynchronous test and multi-service multi-interface asynchronous test corresponding to the quality test phase are black-box tests, which focus on testing the functions and systems of the application.

[0068] Among them, refer to Figure 3 It can be seen that by feeding back the test results of the development self-test phase to the quality test phase, and vice versa, the test results of the quality test phase can be communicated between the two phases, and the test status of each other can be checked to ensure the comprehensiveness and accuracy of the test.

[0069] Step S206, calling each test method matching the corresponding test type in each test phase, testing the code files of each development branch in each deployed server environment, and obtaining the test information files of different development branches of the application in each server environment.

[0070] Specifically, by calling the unit test method corresponding to the same-process code test and the object simulation test method corresponding to the same-process module integration test in the development self-test stage, the code files of each development branch are tested in each deployed server environment, and the first sub-test information files of different development branches of the application program in each server environment are obtained. The first sub-test information files include the code location files and code coverage files of each development branch in each server environment in the development self-test stage.

[0071] Furthermore, by adopting the unit testing method, the smallest testable unit (such as code line, function, method, and class, etc.) in the code file of each development branch can be tested, that is, the unit testing method is called to test the code file of each development branch in each deployed server environment (including the development self-test server environment, the quality test service environment, and the stable delivery service environment, etc.). Similarly, by calling the object simulation testing method, when the development is not fully completed, the different methods or classes in the code file of the application are simulated to test the code files of each development branch constructed by simulation in each deployed server environment (including the development self-test server environment, the quality test service environment, and the stable delivery service environment, etc.).

[0072] Among them, by calling the unit test method corresponding to the same-process code test and the object simulation test method corresponding to the same-process module integration test, the first sub-test information files of different development branches of the application in each server environment are obtained, including the development trunk, or the stable branch, or the repair branch, and the first sub-test information files in each deployed server environment, including the development self-test server environment, the quality test service environment and the stable delivery service environment.

[0073] For example, Figure 4 As shown, a schematic diagram of the test types and test methods corresponding to the development self-test stage is provided. Figure 4 It can be seen that the test types in the development self-test phase include same-process code testing and same-process module integration testing, and the test methods include unit testing methods corresponding to same-process code testing and object simulation testing methods corresponding to same-process module integration testing. Among them, the unit test method is expressed as unit testing, and the object simulation test method is expressed as mock testing. By combining the unit test method and the object simulation test method, the member functions, ordinary functions, methods, and classes in the code file of the application are further simulated to solve the problems of poor independence of application modules and incomplete consideration of early testability in the asynchronous framework during the development process, improve the test processing efficiency, and obtain accurate and comprehensive test results.

[0074] In an exemplary embodiment, since the quality test stage is located after the development self-test stage, after the test processing is performed in the development self-test stage, each first sub-test information file corresponding to the development self-test stage is obtained, and it is determined whether each first sub-test information file meets the quality test requirements.

[0075] Specifically, if it is determined that each first sub-test information file meets the quality testing requirements, then in the quality testing stage, the web page interaction-based game service testing method corresponding to the single service interface asynchronous test and the application testing method corresponding to the multi-service multi-interface asynchronous test are called to test the code files of each development branch in each deployed server environment, and obtain the second sub-test information files of different development branches of the application in each server environment.

[0076] The quality test requirement is used to indicate whether the coverage rate in each first sub-test information file reaches a preset threshold. If it is determined that the coverage rate in each first sub-test information file reaches the preset threshold, it indicates that the test processing in the development self-test phase meets the quality test requirement. The preset threshold can be set according to the actual needs of the application development process and is not limited to one or some specific values.

[0077] Single service interface asynchronous testing means testing the service interface of the application program, using a method that fully relies on real links, and the test case and the object under test are in different processes, and the service needs to be deployed and started. The execution time of a single test case is usually set to be within 10 seconds. Multi-service multi-interface asynchronous testing means testing a certain scenario by connecting multiple services and multiple interfaces in series, mainly simulating client calls (such as apps, H5 pages, and web pages, etc.), deploying real services, and relying on full-link end-to-end testing of real downstream. The test case and the object under test are in different processes, and the execution time of a single test case is usually set to be within the range of 1 second to 600 seconds.

[0078] The webpage-based interactive game service testing method refers to the use of a webpage-based interactive game management system framework to implement the modification or execution management of game servers and game characters during the development phase, and provide functional testing, code debugging, and other functions during the development phase. The application testing method refers to the simulation of the application testing in different scenarios, including simulating the calls to multiple different service interfaces in each scenario, in order to obtain the response speed of each service interface and the service resource scheduling of the application in different scenarios.

[0079] Furthermore, by calling the game service testing method based on web page interaction, it is possible to test, for example, the game server, game character modification or execution management functions of the game application during the development process, and by calling the application testing method, it is possible to test, for example, the game application in different scenarios, including game character modification, game item purchase, and game scene switching.

[0080] In an exemplary embodiment, Figure 5 As shown, a coverage diagram of different test methods is provided. Figure 5 It can be seen that the testing methods include daily automatic testing, unit testing and comprehensive testing (comprehensive testing consisting of automatic testing and unit testing), such as Figure 5 The information shown in the figure is the coverage information of the unit test, including the coverage progress of each code file after calling the unit test method, coverage valid lines, code valid lines, and coverage level.

[0081] Step S208, extracting the first version identifier of the code file to which each test information file belongs, and merging the test information files belonging to different first version identifiers to obtain a merged branch test information file.

[0082] After obtaining the test information files of different development branches of the application in each server environment, the historical test information files and the latest test information files are further merged according to the generation time of the test information files to obtain the merged test information files. Furthermore, by synchronizing the merged test information files to each server environment deployed by different development branches, the historical test information files and the latest test information files are incrementally merged according to the synchronization time of each test information file within a preset update cycle to obtain the current test information file after the incremental merger.

[0083] Furthermore, by extracting the first version identifier of the code file to which the current test information file after each incremental merger belongs, and obtaining each test information file belonging to a different first version identifier, the test information files belonging to a different first version identifier are merged to obtain a merged branch test information file.

[0084] For example, Figure 6 As shown, a schematic diagram of the test information file of the development branch of an application is provided, referring to Figure 6 It can be seen that the development branch specifically includes the development trunk, stable branch, or repair branch, etc. For example, under the development trunk, you can specifically view the total coverage progress corresponding to the trunk development (including coverage effective lines and total effective lines of code). The trunk development includes multiple code file directories, and you can view the coverage effective lines, effective lines, and coverage level corresponding to each code file directory. Among them, each code file directory also includes multiple code files, and you can further view the coverage effective lines, effective lines, and coverage level of each code file in each code file directory.

[0085] Furthermore, if Figure 7 As shown, a coverage diagram of a development branch is provided. Figure 7 It can be seen that the development branch specifically includes the development trunk, or the stable branch, or the repair branch, etc. For example, under the development trunk, you can view the coverage information of the code files submitted by different developers. The coverage information specifically includes the coverage progress of the code file, the statistical start time, the statistical end time, the total code lines, the number of covered lines, the coverage percentage (specifically determined according to the ratio of the number of covered lines to the total code lines), the total number of new functions and the number of covered functions, etc.

[0086] Step S210, obtaining the second version identifier corresponding to the branch test information file and the target code file corresponding to the second version identifier, and displaying the target code file and the corresponding branch test information file.

[0087] Specifically, by obtaining the second version identifier corresponding to the branch test information file, extracting the target code file corresponding to the second version identifier, and performing chaotic processing based on the target code file, the target code file after chaotic processing is obtained, so as to display the target code file after chaotic processing and its corresponding branch test information file.

[0088] Among them, by performing chaos processing on the target code file, part of the source code file can be hidden, the leakage of the code file can be reduced, and the security of the code file can be guaranteed.

[0089] In an exemplary embodiment, Figure 8 As shown, a schematic diagram of the target code file after chaos processing is provided. Figure 8 It can be seen that by performing chaotic processing on certain code lines in the target code file, hiding some source code lines (using "X" and "..." to replace the code lines that need to be hidden), and displaying each code line in the target code file after chaotic processing, as well as the number of executions corresponding to each code line, that is, the coverage rate, it is possible to reduce code file leakage and ensure the security of code files while comprehensively and accurately displaying the coverage rate corresponding to each code line, thereby improving the development and testing processing efficiency in the application development process.

[0090] Among them, refer to Figure 8 It can be seen that when displaying each code line in the target code file after chaos processing and the number of executions corresponding to each code line, the development branch to which the current target code file belongs can also be displayed, such as the main branch, and the total coverage progress, coverage valid lines, and code valid lines corresponding to the development branch can be displayed at the same time.

[0091] In the above-mentioned application development test processing method, by obtaining the development branch of the application associated with the received application development test request and the server environments deployed by the development branch, and obtaining the test phase that triggers the application development test request, the test type matching each test phase and the test method matching the test type are determined. Among them, by calling each test method matching the corresponding test type in the test phase, the code files of each development branch are tested in each deployed server environment, and the test information files of different development branches of the application in each server environment are obtained, so that different test methods can be deployed in different test phases, respectively, to achieve full and comprehensive testing of the code files, reduce missed tests, and avoid the need for repeated tests due to missed tests, thereby improving the efficiency of application development testing. Furthermore, by extracting the first version identifier of the code file to which each test information file belongs, and merging the test information files belonging to different first version identifiers, the merged branch test information file is obtained, so that the test information files of code files of different versions can be concentrated, avoiding the omission of new code files in a certain version, so as to accurately count the test information of code files of different development branches. By obtaining the second version identifier corresponding to the branch test information file and the target code file corresponding to the second version identifier, the target code file and its corresponding branch test information file can be displayed, so as to accurately obtain the test information of each target code file under different branches, and timely confirm the test progress of different development branches, thereby ensuring the comprehensiveness and accuracy of the test, and further improving the development and test processing efficiency in the application development process.

[0092] In an exemplary embodiment, Fig. 9 As shown, the step of obtaining the test information files of different development branches of the application in each server environment, that is, testing the code files of each development branch in each deployed server environment, and obtaining the test information files of different development branches of the application in each server environment, specifically includes steps S902 to S910. Among them:

[0093] Step S902 , respectively pull code files corresponding to different development branches, and add preset compilation parameters to the code files, the preset compilation parameters including a first compilation parameter corresponding to the code location file, and a second compilation parameter corresponding to the code coverage file.

[0094] Specifically, by pulling the code files corresponding to different development branches from the version management tool, the source files in the ".c format" are obtained, and when compiling the source files in the ".c format", preset compilation parameters are added to the source files in the ".c format", including a first compilation parameter corresponding to the code location file and a second compilation parameter corresponding to the code coverage file.

[0095] Exemplarily, the first compilation parameter is "-ftest-coverage", which is used to generate a code location file, namely a ".gcno file", during compilation, which contains the line numbers of the code in the source file. The second compilation parameter is "-fprofile-arcs", which is used to generate code coverage information during compilation, and obtain a code coverage file, namely a ".gcda file", which contains the execution times of each code line in each code file.

[0096] Step S904 , compile preprocessing the code file with the preset compile parameters added to obtain an assembly file, and perform stub processing on the assembly file according to the assembly statement for collecting program execution information.

[0097] Specifically, by compiling and preprocessing the code file with preset compilation parameters, an assembly file in ".s format" is obtained, and each stub in the assembly file is obtained, and assembly statements for collecting program execution information are inserted at each determined stub to complete the stub insertion processing of the assembly file. The number of inserted assembly statements can be set according to actual needs, such as inserting 3 to 4 assembly statements at each stub to collect program execution information of the application.

[0098] Step S906, performing assembly processing based on the assembly file to obtain an executable file and a code location file.

[0099] Specifically, assembly processing is performed based on the assembly file in the ".s format", that is, the ".s format" assembly file is assembled into a target file in the ".o format", and by running the target file in the ".o format", an executable file that can be run by the game server and a code location file for recording the line number of the code, namely the ".gcno file", are obtained.

[0100] Step S908, executing the executable files in the server environments deployed in the different development branches respectively, and collecting program execution information by running the assembly statements inserted in the assembly files to obtain code coverage information.

[0101] Specifically, by executing executable files separately in various server environments (such as development self-test server environment, quality testing service environment, and stable delivery service environment) deployed in different development branches (such as development trunk, stable branch, and repair branch, etc.), starting applications such as game application processes, and synchronously running assembly statements inserted in assembly files, the execution times of each code file in the executable file are collected to obtain program execution information.

[0102] Step S910, generating a code coverage file according to the code coverage information, and calling a test information file generation component to generate a test information file according to the code location file and the code coverage file.

[0103] Specifically, by calling a data output function (such as the _gcov_flush function, which is a function used to output code coverage information to a code coverage file), the code coverage information is counted and output to obtain a code coverage file, that is, a ".gcda file".

[0104] Further, the test information file generation component is called to merge the code location file and the code coverage file to obtain the test information file. Specifically, the lcov tool (i.e., the test information file generation component used to generate new test files) is called to merge the code location file, i.e., the ".gcno file", and the code coverage file, i.e., the ".gcda file", to obtain the test information file, i.e., the ".info file". In the test information file, i.e., the ".info file", the number of runs of each code line in each code file is counted to provide a more accurate and clear coverage of the code line, so as to timely confirm the coverage progress of the test and avoid the situation where the test ends early or some code lines in a code file are missed.

[0105] In an exemplary embodiment, Fig.10 As shown, a process for obtaining a test information file is provided, referring to Fig.10 It can be seen that, first, by pulling the code files corresponding to different development branches from the version management tool, the source files in ".c format" are obtained, and preset compilation parameters are added to the source files in ".c format", including the first compilation parameter "-ftest-coverage" and the second compilation parameter "-fprofile-arcs", to obtain the preprocessing file in ".i format" (that is, the code file with preset compilation parameters added).

[0106] Secondly, by compiling and preprocessing the preprocessing file in ".i format", an assembly file in ".s format" is obtained, and the assembly file in ".s format" is plugged in at the same time, that is, according to the assembly statement used to collect program execution information, the assembly file in ".s format" is plugged in.

[0107] Third, assembly processing is performed based on the assembly file in the ".s format", that is, the ".s format" assembly file is assembled into a target file in the ".o format", and by running the target file in the ".o format", an executable file that can be run by the game server and a code location file for recording the line number of the code, namely the ".gcno file", are obtained.

[0108] Fourth, by executing executable files separately in various server environments (such as development self-test server environment, quality testing service environment and stable delivery service environment) deployed in different development branches (such as development trunk, stable branch, and repair branch, etc.), applications such as game application processes are started.

[0109] The coverage client periodically sends an execution signal to the game server. After receiving the execution signal, the game server calls the signal processing function to synchronously run the assembly statement inserted in the assembly file and collect the execution times of each code file in the executable file. The purpose of the coverage client sending the execution signal is to land the execution times, so as to obtain the program execution information, and obtain the code coverage information of the code file based on the program execution information, that is, the execution times of each code line in the code file, and the total number of codes in the code file, and further generate the code coverage file based on the code coverage information, that is, the ".gcda file".

[0110] Fifth, by calling the test information file generation component, namely the lcov tool, the code location file, namely the ".gcno file", and the code coverage file, namely the ".gcda file", the test information file, namely the ".info file", is obtained.

[0111] Sixth, obtain the generation time of each test information file in real time, call the test information file generation component, namely the lcov tool, and merge the historical test information file, namely the ".info historical file" and the latest test information file ".info latest file" according to the generation time of the test information file to obtain the merged test information file "merged .info file".

[0112] In this embodiment, by pulling the code files corresponding to different development branches respectively, adding preset compilation parameters to the code files, and compiling and preprocessing the code files with the preset compilation parameters, an assembly file is obtained, and the assembly file is plugged according to the assembly statement used to collect program execution information. Further, assembly processing is performed based on the assembly file to obtain an executable file and a code location file, and the executable files are respectively executed in each server environment deployed by different development branches, and the program execution information is collected by running the assembly statement inserted in the assembly file to obtain code coverage information. Further, a code coverage file is generated according to the code coverage information, and a test information file generation component is called to generate a test information file based on the code location file and the code coverage file, so that when the executable files are respectively executed in each server environment deployed by different development branches, the program execution information of each executable file is counted, and then the code coverage information of the code files in each server environment deployed by different development branches is accurately obtained, and the coverage test efficiency of the code files of different branches in each server environment is improved.

[0113] In an exemplary embodiment, Fig.11 As shown, a method for processing application development tests is provided, which is applied to Figure 1 Taking the test server 104 in the example as an example, after generating the test information file, the following steps S1102 to S1112 are specifically included. Among them:

[0114] Step S1102, obtaining the generation time of each test information file in real time.

[0115] Specifically, since new code files are continuously added under different development branches during the application development and testing process, test information files corresponding to different versions of code files are generated. After the test information files are generated, the generation time of each test information file is obtained in real time so that the test information files can be merged based on the generation time.

[0116] Step S1104, calling the test information file generation component, merging the historical test information file and the latest test information file according to the generation time of the test information file to obtain a merged test information file.

[0117] Specifically, according to the generation time of the test information file, the historical test information file and the latest test information file can be determined, and then by calling the test information file generation component, the historical test information file and the latest test information file can be merged according to the generation time of the test information file, and then the historical test information file and the latest test information file can be merged to obtain the merged test information file.

[0118] Step S1106, calling the coverage client to determine the metadata information corresponding to the merged test information file, the metadata information includes the initial test information summary value of the test information file, the development branch to which the test information file belongs, the server environment to which the test information file belongs, and the version identifier of the code file to which the test information file belongs.

[0119] Specifically, by calling the coverage client, metadata calculation and processing are performed on the merged test information file to obtain metadata information corresponding to the merged test information file, including the initial test information summary value of the test information file, the development branch to which the test information file belongs, the server environment to which the test information file belongs, and the version identifier of the code file to which the test information file belongs.

[0120] Among them, the initial test information summary value of the test information file is used to compare with the current test information summary value of the merged test information file determined by the coverage server to determine whether there is a transmission error in the test information file, so as to ensure the correctness of the test information file. Among them, the development branch to which the test information file belongs indicates the development branch to which the test information file belongs, such as the development trunk, or the stable branch, or the repair branch. The server environment to which the test information file belongs indicates that the test file information is specifically obtained by testing in the development self-test server environment of the development branch, or the quality test service environment, or the stable delivery service environment. The version identifier of the code file to which the test information file belongs indicates the version of the code file to which the test file information belongs.

[0121] Step S1108, sending the metadata information and the merged test information file to the coverage server associated with the coverage client, and determining the current test information summary value of the merged test information file through the coverage server.

[0122] Specifically, the metadata information and the merged test information file are sent to the coverage server associated with the coverage client, and the coverage server calculates the test information summary value of the received merged test information file to obtain the current test information summary value of the merged test information file.

[0123] Step S1110, compare the current test information digest value with the received metadata information, if it is determined that the current test information digest value is consistent with the initial test information digest value in the metadata information, then determine the storage path of the merged test information file according to the metadata information.

[0124] Specifically, by comparing the current test information digest value with the initial test information digest value in the received metadata information, it is determined whether the current test information digest value is consistent with the initial test information digest value in the metadata information. If it is determined that the current test information digest value is consistent with the initial test information digest value in the metadata information, it indicates that the test information file is correctly transmitted, and further according to the metadata information, the storage path of the merged test information file is determined.

[0125] The storage path of the test information file is specifically composed of a fixed path prefix, a branch name, a version number, a server environment name, an IP address, and a timestamp.

[0126] For example, the storage path of a test information file is provided as follows:

[0127] / data / home / user00 / coverage_server / lcov_info / trunk_main / 235640 / trunk_main_test / XXX.XXX.XXX.XXX / 168XXXXXXX.

[0128] Among them, "data / home / user00 / coverage_server / lcov_info" is the fixed path prefix, "trunk_main" is the branch name, such as the development trunk, "235640" is understood as the version number, "trunk_main_test" is understood as the server environment name, specifically indicating the quality test service environment of the development trunk, and "XXX.XXX.XXX.XXX" is the IP address, and "168XXXXXXX" is represented by the timestamp.

[0129] Step S1112, obtaining the merged test information file from the storage path of the merged test information file, and synchronizing the merged test information file to the research and development environment.

[0130] Specifically, if it is determined that the test information file is correctly transmitted and the storage path of the merged test information file is determined according to the metadata information, the merged test information file is obtained from the storage path of the merged test information file.

[0131] Among them, since new code files will be continuously added under different development branches during the application development and testing process, test information files corresponding to different versions of code files will be generated, and then by storing the continuously updated test information files in the determined storage path, the current latest test information files can be obtained in real time based on the storage path, so that the current latest test information files can be synchronized to the R&D environment through data synchronization tools (such as rsync tools, which are tools used to achieve file synchronization and backup).

[0132] Specifically, since the server environment, coverage client and coverage server are all deployed in the IDC environment (i.e., a network-based centralized environment for collecting, storing, processing and sending data), the obtained test information files are also located in the IDC environment, and the code files need to be downloaded to the R&D environment for display. Therefore, the code files and test information files are located in different environments and cannot be displayed and compared at the same time. Therefore, it is necessary to use a data synchronization tool to synchronize the test information files to the R&D environment so that the test information files and code files can be displayed at the same time. The test information file contains the coverage of the code file, so that each line of code in the code file and its corresponding coverage can be viewed at the same time.

[0133] In an exemplary embodiment, Fig.12 As shown in the figure, a schematic diagram of synchronizing the merged test information file to the R&D environment is provided. Fig.12 It can be seen that different development branches (such as development trunk and repair branch) are deployed with different server environments (including development self-test server environment, quality testing service environment and stable delivery service environment, etc.), and each server environment of each development branch is deployed with a corresponding coverage client, which is used to obtain the test information files corresponding to each server environment of each branch, that is, the test information files corresponding to the development self-test server environment deployed by the development trunk, the test information files corresponding to the quality testing service environment, and the test information files corresponding to the stable delivery service environment can be obtained, and the test information files corresponding to the development self-test server environment deployed by the repair branch, the test information files corresponding to the quality testing service environment, and the test information files corresponding to the stable delivery service environment can be obtained.

[0134] Specifically, each coverage client sends the test information file (i.e., .info file) obtained by each client to the coverage server. At the same time, the coverage client performs metadata calculation processing on the merged test information file to obtain metadata information corresponding to the merged test information file, including the initial test information summary value of the test information file, the development branch to which the test information file belongs, the server environment to which the test information file belongs, and the version identifier of the code file to which the test information file belongs.

[0135] Among them, the metadata information and the merged test information file are sent to the coverage server associated with the coverage client, and the coverage server calculates the test information summary value of the received merged test information file to obtain the current test information summary value of the merged test information file.

[0136] Further, by comparing the current test information digest value with the initial test information digest value in the received metadata information, it is determined whether the current test information digest value is consistent with the initial test information digest value in the metadata information. If it is determined that the current test information digest value is consistent with the initial test information digest value in the metadata information, it indicates that the test information file is correctly transmitted, and further according to the metadata information, the storage path of the merged test information file is determined.

[0137] Finally, the merged test information file is obtained from the storage path of the merged test information file, and the merged test information file is synchronized to the research and development environment.

[0138] In an exemplary embodiment, Fig.13 As shown, a process of displaying a target code file and its corresponding branch test information file is provided, referring to Fig.13 It can be seen that, first, by utilizing a data synchronization tool (such as the rsync tool, which is a tool for realizing file synchronization and backup), the merged test information file obtained from the storage path of the merged test information file is synchronized to the R&D environment. Since there are test information files with different version identifiers (such as V1, V2, V3 and other versions) for each development branch (such as trunk development and repair branch), a multi-threaded approach is adopted to merge the test information files with different version identifiers at the same time to improve the processing efficiency of the synchronization of the test information files.

[0139] Secondly, after synchronizing the merged test information file to the R&D environment, the historical test information file and the latest test information file are incrementally merged according to the synchronization time of each test information file within the preset update cycle to obtain the current test information file after incremental merging.

[0140] Specifically, refer to Fig.13It can be seen that, taking trunk development as an example, there are test information files of different versions (including V1, V2, V3, etc.), and by caching the test information files of different versions at the same time, historical test information files of different versions are obtained (including historical info1, historical info2, historical info3, etc.). However, since the application development and test processing process is dynamically executed, new test information files (such as new infoV1, new infoV2, new infoV3, etc.) will be continuously generated for different code files after addition, modification or deletion, as well as for code files in the running process, and multi-threading is needed to realize incremental merging, so as to incrementally merge the new test information files and historical test information files of each version.

[0141] For example, for example, the historical test information files obtained for the first time include historical info1, historical info2, historical info3, etc., and the new test information files obtained for the second time include new infoV1, new infoV2, new infoV3, etc. Specifically, the historical info1 is merged with the new infoV1, the historical info2 is merged with the new infoV2, and the historical info3 is merged with the new infoV3 to obtain merged info1+infoV1, info2+infoV2, and info3+infoV3, and the new test information files obtained for the third time include new infoV1, new infoV2, new infoV3, etc. nfoV12, new infoV22, new infoV32, etc., directly merge the merged "info1+infoV1" with the new infoV12, merge the merged "info2+infoV2" with the new infoV22, and merge "info3+infoV3" with the new infoV32, instead of merging the historical info1, new infoV1, and new infoV12. This can reduce repeated merging operations and directly merge the historically merged test information files and the latest test information files, thereby improving the merging efficiency of the test information files.

[0142] Similarly, refer to Fig.13It can be seen that, taking the repair branch as an example, it also has test information files of different versions (including V1', V2', V3', etc.). The test information files of different version identifiers are cached and processed simultaneously in a multi-threaded manner to obtain historical test information files of different version identifiers (including historical info1', historical info2', historical info3', etc.). However, since the application development and test processing process is dynamically executed, new test information files (such as new infoV1', new infoV2', new infoV3', etc.) will be continuously generated for different newly added, modified or deleted code files during the development and test processing, and it is necessary to use an incremental merge method to merge the new test information files and historical test information files of each version identifier.

[0143] Third, for the current test information file after the incremental merger, further extract the first version identifier of the code file to which each current test information file after the incremental merger belongs, and obtain each test information file belonging to a different first version identifier, and then merge each test information file belonging to a different first version identifier to obtain a merged branch test information file. Specifically, the "diff" method (i.e., comparing the similarities and differences of text files line by line) can be used to realize the merging process between each test information file belonging to a different first version identifier.

[0144] Among them, refer to Fig.13 It can be seen that the branch test information file corresponding to the trunk development obtained by merging is specifically the final info file, and the branch test information file corresponding to the repair branch obtained by merging is specifically the finalinfo' file.

[0145] Further, refer to Fig.13 It can be seen that by obtaining the second version identifier corresponding to the branch test information file, and extracting the target code file corresponding to the second version identifier, and then performing chaotic processing based on the target code file, the target code file after chaotic processing is obtained, so that the target code file after chaotic processing and its corresponding branch test information file can be displayed.

[0146] Among them, according to the second version identifier, the submission object of the target code file can be further traced back, so that the target code files submitted by different submission objects and their corresponding branch test information files can be displayed, that is, specifically, the target code files of different submission objects and the coverage of the target code files can be displayed.

[0147] The above-mentioned application development test processing method obtains the generation time of each test information file in real time, calls the test information file generation component, merges the historical test information file and the latest test information file according to the generation time of the test information file, and obtains the merged test information file. Further, by calling the coverage client, the metadata information corresponding to the merged test information file is determined, and the metadata information and the merged test information file are sent to the coverage server associated with the coverage client. Among them, the current test information summary value of the merged test information file can be determined through the coverage server. By comparing the current test information summary value with the received metadata information, when it is determined that the current test information summary value is consistent with the initial test information summary value in the metadata information, it can be confirmed that the test information file is correctly transmitted. Therefore, the storage path of the merged test information file can be determined according to the metadata information, and the merged test information file can be obtained from the storage path of the merged test information file, so as to synchronize the merged test information file to the R&D environment, so as to synchronously display the target code file and the corresponding test information file in the R&D environment, accurately and comprehensively know the coverage of different code lines in the target code file, timely confirm the coverage progress, avoid premature interruption or omission of the test, and further improve the efficiency of application development test processing.

[0148] In an exemplary embodiment, Fig.14 As shown, the step of obtaining the second sub-test information file of different development branches of the application in each server environment, that is, in the quality testing stage, calling the game service test method based on web page interaction corresponding to the single service interface asynchronous test, testing and processing the code files of each development branch in each deployed server environment, and obtaining the second sub-test information file of different development branches of the application in each server environment, specifically includes steps S1402 to S1408, wherein:

[0149] Step S1402, in the quality test phase, triggering an access request based on the game service webpage, accessing the game service webpage, and determining a server to be tested based on the game service webpage.

[0150] In the quality testing phase, a login request is triggered based on a smart terminal device or a simulated client test tool (such as a testclient tool, i.e., a test tool developed by a server simulating a client), and the test account input is detected based on the smart terminal device or the simulated client test tool, and the test account is used to log in to the game server to be tested. If it is determined that the test account successfully logs in to the game server to be tested, the test account is uploaded to the message forwarding service component (i.e., the player online login and message forwarding service component) through the game server to be tested, and the test account and the address of the game server to be tested corresponding to the test account are recorded through the message forwarding service component, so that the message forwarding service component can be used to forward the information related to the test account to the address of the game server to be tested.

[0151] Specifically, in the quality test phase, an access request based on the game service webpage is triggered, and the game service webpage is accessed. When accessing the game service webpage, the server to be tested and the object identifier of the game to be tested need to be further determined based on the game service webpage (i.e., the input test account is obtained and determined as the object identifier of the game to be tested).

[0152] Before triggering the access request based on the game service webpage, object authentication is required, which can be specifically performed based on an object authentication platform. If the authentication is passed, the access request based on the game service webpage is triggered.

[0153] In an exemplary embodiment, Fig.15 As shown, a schematic diagram of the entry interface of a game service webpage is provided, referring to Fig.15 It can be seen that when the access request of the game service webpage is triggered, the entry interface of the game service webpage is accessed, and the entry interface displays various servers to be tested for selection. Among them, since the code files of different development branches can be published to different server environments, the servers to be tested can include different server environments deployed by different development branches of the application, such as the development self-test server environment, quality test service environment and stable delivery service environment deployed by the development trunk, and the development self-test server environment, quality test service environment and stable delivery service environment deployed by the repair branch, that is, the server environments deployed by different development branches are displayed, and any of the server environments can be selected as the server to be tested.

[0154] Among them, refer to Fig.15It can be seen that the server to be tested currently determined based on the entry interface of the game service webpage is specifically the development self-test server environment deployed in the trunk branch, and the entry interface of the game service webpage can further determine the user ID of the game to be tested, that is, by obtaining the input test account, it is determined as the user ID of the game to be tested. Among them, the test account can be an open account associated with the user of the game to be tested, which is composed of numbers, letters and characters.

[0155] Further, refer to Fig.15 It can be seen that by binding the server to be tested (i.e. the server environment deployed by a development branch) and the object identifier of the game to be tested (i.e. the input test account), the test process is triggered and jumps to the test interface in the game service webpage.

[0156] Step S1404: Based on the game service webpage, determine the function to be tested corresponding to the server to be tested and the game service instruction parameters corresponding to the function to be tested.

[0157] Specifically, after the test process is triggered, the game service webpage is redirected to the test interface, and based on the test interface of the game service webpage, the input or selected function to be tested and the game service instruction parameters corresponding to the function to be tested are obtained.

[0158] For example, Fig.16 As shown, a test interface diagram of a game service web page is provided. Fig.16 It can be seen that in the test interface of the game service webpage, a single game service instruction or a combined game service instruction can be input. Among them, for the combined game service instruction, there are further functions of executing the instruction group, viewing the instruction group, modifying the instruction group, deleting the instruction group and adding the instruction group, that is, the subsequent operations such as viewing, modifying, deleting and adding the combined game service instruction can be performed for the combined game service instruction, and the operation of triggering the execution of the combined game service instruction can also be directly executed.

[0159] Furthermore, different functions to be tested correspond to a variety of different game service instruction parameters, and each game service instruction parameter corresponds to a game server instruction that needs to be executed, that is, by executing the game service instruction corresponding to the game service instruction parameter, the purpose of testing the function to be tested can be achieved.

[0160] Optionally, refer to Fig.16It can be seen that the game service instruction parameters corresponding to a certain function to be tested (such as the help function) may specifically include game character parameters, score parameters, level parameters, and game match parameters, and the game server instructions corresponding to each game service instruction parameter include game character modification instructions, score update instructions, level update instructions, and game history match update instructions. Among them, the game character modification instruction is used to modify and adjust the game character of the test account, such as selecting a new game character or adjusting the appearance of a historical game character. The score update instruction is used to update the points of the test account, including adding points, deducting points, etc. The level update instruction is used to update the game level of the test account. The game history match update instruction is used to detect the number of game matches of the test account in real time and update the number of historical matches in real time.

[0161] Step S1406, determining a matching game service instruction according to the game service instruction parameter, and determining a target code file associated with the game service instruction according to the code files of each development branch.

[0162] Specifically, the matching game service instructions are determined according to the game service instruction parameters, such as game character parameters, score parameters, level parameters, and game match parameters, and the corresponding game character modification instructions, score update instructions, level update instructions, and game history match update instructions are determined respectively.

[0163] Furthermore, based on the code files of each development branch, the target code files associated with each game service instruction are determined, such as game character modification instructions, score update instructions, level update instructions, and game history update instructions, and their respective associated target code files.

[0164] Among them, since corresponding code files need to be written in advance for different functions or different scenarios of game applications, when different game service instructions need to be executed to test certain functions or scenarios, for example, when the point update or level update function of the game application needs to be tested, it is necessary to call and execute the code files corresponding to the corresponding functions (including point update, level update, etc.), that is, specifically, determine the target code files associated with the game service instructions from the code files of each development branch to implement the testing of the corresponding functions.

[0165] Step S1408, calling the web page interaction-based game service test method corresponding to the single service interface asynchronous test, testing the target code file associated with the game service instruction in the server to be tested deployed in each development branch, and obtaining the second sub-test information file of different development branches of the application in each server environment.

[0166] Specifically, by calling the game service testing method based on web page interaction corresponding to the asynchronous test of the single service interface, that is, adopting the game management system framework based on web page interaction, the function of modifying or executing management of the game server and game character in the application development stage is realized, so as to achieve the functional testing and code debugging method in the application development stage, so as to test and process the target code files associated with the game service instructions in the server to be tested deployed in each development branch, that is, after determining the object identifier of the server to be tested and the game to be tested based on the game service web page, each game service instruction is called and executed based on the object identifier of the game to be tested, and the target code file associated with each game service instruction executed under the object identifier of the game to be tested is obtained, so as to test and process the target code file, and obtain the corresponding second sub-test information file, that is, obtain the coverage information of the target code file.

[0167] Furthermore, by testing the obtained target code file in the server to be tested deployed in each development branch, the second sub-test information file of the different development branches of the application in each server to be tested can be obtained. In particular, since it is necessary to implement a comprehensive test of the application, it is usually necessary to use the server environments of the different development branches of the application as the server to be tested in turn to obtain the second sub-test information file corresponding to each server environment deployed in each development branch of the application.

[0168] In an exemplary embodiment, Fig.17 As shown, a process of calling a web page interactive game service test method to obtain a second sub-test information file is provided. Taking the function to be tested in the test process as an example in which the function to be tested is located in the game lobby server, that is, taking the server to be tested as the game lobby server as an example, the description is made. Fig.17 It can be seen that the process of calling the web page interactive game service test method to obtain the second sub-test information file specifically includes:

[0169] 1) During the quality testing phase, a login request is triggered based on an intelligent terminal device or a simulated client testing tool.

[0170] 2) Based on the intelligent terminal device or the simulated client test tool, the test account input is detected and the test account is used to log in to the game lobby server.

[0171] 3) If it is determined that the test account has successfully logged into the game lobby server, the test account is uploaded to the message forwarding service component through the game lobby server.

[0172] 4) Perform object authentication based on the object authentication platform. If the authentication is successful, an access request based on the game service webpage is triggered, and the game service webpage is accessed.

[0173] 5) Access the entry interface of the game service webpage, determine the object identifiers of the server to be tested and the game to be tested based on the entry interface of the game service webpage, bind the server to be tested and the object identifiers of the game to be tested, and jump to the test interface in the game service webpage.

[0174] 6) Based on the test interface in the game service webpage, determine the function to be tested corresponding to the server to be tested and the game service instruction parameters corresponding to the function to be tested, and determine the matching game service instruction according to the game service instruction parameters.

[0175] 7) Sending the game service instruction to the game side server, the game side server converts the game service instruction into request data in a first preset format, and encapsulates the request data in the first preset format to obtain encapsulated service request data.

[0176] 8) The game side server sends the encapsulated service request data to the message forwarding service component.

[0177] 9) The message forwarding service component obtains the object status corresponding to the object identifier used by the game under test, and determines whether the object status is online.

[0178] 10) If it is determined that the object status is offline, a status message indicating that the game to be tested uses the object offline is returned to the game side server.

[0179] 11) If it is determined that the object state is online, the message forwarding service component forwards the encapsulated service request data to the game lobby server.

[0180] 12) The game hall server performs instruction query processing based on the game service instruction storage component. If it is determined that the game service instruction storage component does not exist, a message indicating that the game service instruction does not exist is returned to the game side server. The game service instruction storage component is understood as a structure array defined in the game hall server, and specifically, the game hall server performs instruction query processing based on the game service instruction storage component.

[0181] 13) If it is determined that the game service instruction storage component exists, based on the code files of each development branch corresponding to the game lobby server, determine the target code file associated with the service request data corresponding to the game service instruction.

[0182] 14) Call the web page interaction-based game service test method corresponding to the single service interface asynchronous test, test and process the target code file associated with the game service instruction in each server environment deployed by each development branch, and obtain the second sub-test information file of different development branches of the application in each server environment.

[0183] In one embodiment, the function to be tested during the test process may also be located in other servers, that is, other servers may be used as the server to be tested. In other words, if the function to be tested during the test process is located in other servers other than the game hall server, the game hall server further determines the server to be tested where the function to be tested is located, and forwards the encapsulated service request data to the server to be tested.

[0184] Among them, after the game lobby server forwards the encapsulated service request data to the server to be tested, the target code file associated with the service request data corresponding to the game service instruction is determined based on the code files of each development branch corresponding to the server to be tested, and the web page interaction-based game service test method corresponding to the single service interface asynchronous test is further called. In each server environment deployed by each development branch, the target code file associated with the game service instruction is tested and processed to obtain the second sub-test information file of different development branches of the application in each server environment.

[0185] In this embodiment, during the quality test phase, by accessing the game service webpage, the server to be tested, the function to be tested corresponding to the server to be tested, and the game service instruction parameters corresponding to the function to be tested are determined based on the game service webpage, and the matching game service instructions are determined according to the game service instruction parameters, so as to further determine the target code file associated with the game service instruction according to the code files of each development branch. Furthermore, by calling the game service test method based on webpage interaction corresponding to the asynchronous test of the single service interface, the target code file associated with the game service instruction is tested and processed in each server environment deployed by each development branch, and the second sub-test information file of the different development branches of the application in each server environment is obtained, so as to achieve the purpose of conducting a comprehensive test on the server to be tested deployed by each development branch according to the function to be tested and its corresponding game service instruction parameters, that is, by testing and processing the target code file associated with the game service instruction in the server to be tested, the comprehensive test situation of calling and executing different game service instructions in the server to be tested can be obtained, thereby improving the test processing efficiency in the application development and testing process.

[0186] In an exemplary embodiment, Fig.18 As shown, the step of determining the target code file associated with the game service instruction, that is, determining the matching game service instruction according to the game service instruction parameter, and determining the target code file associated with the game service instruction according to the code files of each development branch, specifically includes steps S1802 to S1810:

[0187] Step S1802, determining a matching game service instruction according to the game service instruction parameter, sending the game service instruction to the game side server, and instructing the game side server to convert the game service instruction into request data in a first preset format.

[0188] Specifically, a matching game service instruction is determined according to the game service instruction parameter, and an instruction query process is performed based on the game service instruction storage component to determine whether the game service instruction exists in the game service instruction storage component. If it is determined that the game service instruction exists in the game service instruction storage component, the game service instruction is sent to the game side server, a first preset format supported by the game side server is obtained, and the game side server is instructed to convert the game service instruction into request data in the first preset format.

[0189] Among them, a plurality of different game service instructions are pre-stored in the game service instruction storage component. After the game service instructions to be executed are determined according to the game service instruction parameters, instruction query processing is further performed based on the service instruction storage component to determine whether the game service instructions to be executed actually exist in the service instruction storage component.

[0190] For example, Fig.19 As shown, a schematic diagram of an interface for querying game service instructions based on a game service instruction storage component is provided, referring to Fig.19 It can be seen that based on the instruction query interface of the game service instruction storage component, the game service instructions determined according to the game service instruction parameters are queried, that is, it is determined whether the game service instructions determined according to the game service instruction parameters exist in the game service instruction storage component.

[0191] Further, refer to Fig.19 It can be seen that based on the instruction query interface of the game service instruction storage component, a single game service instruction or a combined game service instruction can be input and queried. If it is determined that the game service instruction storage component does not contain the game service instruction determined according to the game service instruction parameter, a prompt message that it cannot be executed is returned. On the contrary, if it is determined that the game service instruction storage component exists, the game service instruction is sent to the game side server.

[0192] Among them, in the instruction query interface, for the combined game service instructions, the functions of executing instruction groups, viewing instruction groups, modifying instruction groups, deleting instruction groups and adding instruction groups are further set, so that subsequent operations such as viewing, modifying, deleting, adding, etc. can be performed on the combined game service instructions, and operations to trigger the execution of the combined game service instructions can also be directly executed.

[0193] In an exemplary embodiment, the matching game service instructions are determined specifically based on game service instruction parameters, such as game character parameters, score parameters, level parameters, and game match parameters, etc., and the corresponding game character modification instructions, score update instructions, level update instructions, and game history match update instructions, etc. can be determined respectively.

[0194] Furthermore, the game service instruction is sent to the game side server, so that the game service instruction is converted into request data of a first preset format by the game side server. The request data of the first preset format is a preset format supported by the server to be tested, and specifically can be a memory structure format (a structure data format including information such as a structure name, a type name, and a member name). Since the currently determined game service instruction cannot be directly called or executed in the server to be tested, it is necessary to convert the game service instruction into request data of the first preset format supported by the server to be tested.

[0195] Among them, when accessing the game service webpage, it also includes determining the object identifier of the game to be tested based on the game service webpage, that is, determining the test account bound to the server to be tested, and then specifically obtaining the service execution information associated with the test account by executing the corresponding game service instructions under the test account, so as to perform further analysis based on the service execution information, obtain the service functions and service scenarios of the test account in the server to be tested, and judge whether the service functions and service scenarios meet the actual application requirements.

[0196] In an exemplary embodiment, Fig. 20 As shown, a game service instruction format is provided. Fig. 20 It can be known that the game service instruction determined according to the game service instruction parameters may be in XML format (ie, extensible markup language format).

[0197] Among them, since the currently determined game service instructions cannot be directly called or executed in the server to be tested, it is necessary to convert the game service instructions into request data in a first preset format supported by the server to be tested, that is, to convert the game service instructions in XML format into request data in a memory structure format.

[0198] Step S1804: encapsulate the request data in the first preset format to obtain encapsulated service request data.

[0199] Specifically, the request data in the first preset format is encapsulated to obtain encapsulated service request data, wherein the encapsulated service request data is used to be forwarded to the message forwarding service component, so as to forward the encapsulated service request data to the server under test through the message forwarding service component.

[0200] Step S1806, forwarding the packaged service request data to the message forwarding service component, obtaining the object status corresponding to the object identifier used by the game under test through the message forwarding service component, and if the object status is determined to be online, forwarding the packaged service request data to the server under test through the message forwarding service component.

[0201] Among them, after determining the object identifier of the game to be tested based on the game service web page, it is necessary to call and execute each game service instruction based on the object identifier of the game to be tested to obtain the corresponding test results and execution results of each game service instruction executed under the object identifier of the game to be tested. It is further necessary to determine that the object state of the object identifier of the game to be tested is an online state, that is, only when the object state is online can the test results and execution results when each game service instruction is executed by the object identifier of the game to be tested be further obtained.

[0202] Specifically, the encapsulated service request data is forwarded to the message forwarding service component, so as to obtain the object state corresponding to the object identifier used by the game to be tested through the message forwarding service component. The object state corresponding to the object identifier used by the game to be tested specifically includes an online state and an offline state. If the object state is determined to be an online state, the encapsulated service request data is forwarded to the server to be tested through the message forwarding service component.

[0203] Furthermore, if the object state is determined to be online through the message forwarding service component, the packaged service request data is forwarded to the server to be tested through the message forwarding service component. Among them, the server where the function to be tested is located during the test is the server to be tested. If the function to be tested is located on the game hall server, the server to be tested is specifically the game hall server. If the function to be tested is located on a server other than the game hall server, the other server is determined as the server to be tested. Specifically, the server to be tested where the function to be tested is located is further determined through the game hall server, and the packaged service request data is forwarded to the server to be tested (i.e., the other server).

[0204] Step S1808: If it is determined that the object state is offline, a state message indicating that the game to be tested uses the object offline is returned to the game side server.

[0205] Specifically, if the object status is determined to be offline through the message forwarding service component, it means that it is impossible to call and execute various game service instructions through the object identifier of the game to be tested, and the test processing cannot be completed. Specifically, the status message that the game to be tested object is offline is sent to the game side server.

[0206] Step S1810, based on the code files of each development branch corresponding to the server to be tested, determine the target code file associated with the service request data corresponding to the game service instruction.

[0207] Specifically, by obtaining the code files under the development branch corresponding to the server under test, such as obtaining the code files corresponding to the trunk development corresponding to the server under test, and then based on the code files corresponding to the trunk development, determine the code files involved in each game service instruction as the target code files associated with the game service instructions.

[0208] Similarly, the code file corresponding to the repair branch corresponding to the server to be tested may be obtained, and based on the code file corresponding to the repair branch, the code file related to each game service instruction may be determined as the target code file associated with the game service instruction.

[0209] Among them, since different development branches are deployed with different server environments, such as the development self-test server environment deployed by the trunk development, or the quality testing service environment, or the stable delivery service environment, etc., the target code files associated with the game service instructions can be tested and processed in each server environment deployed by different development branches, and the test information files of different development branches of the application in each server environment can be obtained.

[0210] In this embodiment, the matching game service instruction is determined according to the game service instruction parameter, the game service instruction is sent to the game side server, the game side server is instructed to convert the game service instruction into request data in a first preset format, and the request data in the first preset format is encapsulated to obtain the encapsulated service request data. Furthermore, the object state corresponding to the object identifier used by the game to be tested is obtained through the message forwarding service component. If the object state is determined to be an online state, the encapsulated service request data is forwarded to the server to be tested through the message forwarding service component. Finally, the target code file associated with the service request data corresponding to the game service instruction can be determined based on the code files of each development branch corresponding to the server to be tested. Based on the code files of each development branch corresponding to the server to be tested, the target code file associated with the game service instruction is accurately determined, so that targeted testing can be performed on the target code file in the future, accurate test results can be obtained, and the problem of repeated testing can be avoided, further improving the test processing efficiency in the application development and testing process.

[0211] In an exemplary embodiment, Fig.21 As shown, a method for processing application development tests is provided, which is applied to Figure 1 Taking the test server 104 in the example as an example, after forwarding the encapsulated service request data to the server to be tested through the message forwarding service component, the following steps S2102 to S2106 are also included. Among them:

[0212] Step S2102: parse the encapsulated service request data and obtain the request execution logic corresponding to the encapsulated service request data.

[0213] Specifically, after the encapsulated service request data is forwarded to the server to be tested through the message forwarding service component, the encapsulated service request data is further parsed, and the request execution logic corresponding to the encapsulated service request data is obtained.

[0214] The request execution logic specifically includes attribute information adding request execution logic, attribute information modifying request execution logic, and attribute information deleting request execution logic. The attribute information adding request execution logic corresponds to the service request for adding attribute information, that is, it is used to add object attribute information of the object identifier used by the game under test, while the attribute information modifying request execution logic corresponds to the service request for modifying attribute information, that is, it is used to modify object attribute information of the object identifier used by the game under test, and the attribute information deleting request execution logic corresponds to the service request for deleting attribute information, that is, it is used to delete object attribute information of the object identifier used by the game under test.

[0215] Step S2104, instructing the server to be tested to execute the request execution logic, and performing information synchronization processing on the object attribute information of the object identifier used by the game to be tested, the information synchronization processing including adding attribute information, modifying attribute information, and deleting at least one of attribute information.

[0216] Specifically, by instructing the server under test to execute request execution logic, including executing attribute information addition request execution logic, attribute information modification request execution logic, and attribute information deletion request execution logic, etc., information synchronization processing is performed on the object attribute information of the object identifier used by the game under test, including adding processing, modifying processing, and deleting processing, etc. of the object attribute information of the object identifier used by the game under test.

[0217] Step S2106, the execution result of the execution request execution logic of the server under test is fed back to the game side server, and the second preset format supported by the game service webpage is obtained. After the game side server encapsulates the execution result into execution data in the second preset format, it is fed back to the game service webpage for display.

[0218] Specifically, the execution result of the execution logic of the request executed by the server under test is fed back to the game side server, and since the game service webpage cannot directly display the corresponding execution result, the data format supported is the second preset format, and then the execution result is packaged into the execution data of the second preset format by the game side server, and then fed back to the game service webpage for display. Among them, the second preset format can be XML format (i.e., extensible markup language format).

[0219] In an exemplary embodiment, Fig. 22 As shown, a schematic diagram of the execution result corresponding to the request execution logic is provided, referring to Fig. 22 It can be seen that after the object attribute information of the object identifier used by the game to be tested is synchronized, the corresponding execution result is obtained. For example, when the object attribute information of the object identifier used by the game to be tested needs to be modified, the level parameters of the object identifier used by the game to be tested can be modified (such as upgrading to level XX), and the point parameters of the object identifier used by the game to be tested can be modified (such as increasing XX points) at the same time, and the modification results are further fed back to the requesting client for display.

[0220] In the above-mentioned application development test processing method, by parsing the encapsulated service request data, the request execution logic corresponding to the encapsulated service request data is obtained, and the server under test is instructed to execute the request execution logic, and information synchronization processing is performed on the object attribute information of the object identifier used by the game under test. Furthermore, by feeding back the execution result of the request execution logic executed by the server under test to the game side server, a second preset format supported by the game service webpage is obtained, and the execution result is encapsulated into execution data of the second preset format by the game side server, and then fed back to the game service webpage for display, it is realized that according to the request execution logic of the encapsulated service request data, dynamic information synchronization processing is performed on the object attribute information of the object identifier used by the game under test, avoiding the problem of the execution of the game service instruction and the object attribute information of the object identifier used by the game under test being out of sync, which leads to test failures, so as to further improve the speed measurement processing efficiency in the application development test processing process.

[0221] In an exemplary embodiment, Fig.23 As shown, a method for processing application development tests is provided, which specifically includes the following steps:

[0222] Step S2301: receiving an application development test request, and obtaining a development branch of an application program associated with the application development test request, and each server environment deployed by the development branch.

[0223] Step S2302, obtaining the test phase that triggers the application development test request, and determining the test type that matches each test phase and the test method that matches the test type.

[0224] Step S2303, calling each test method matching the corresponding test type in each test phase, testing the code files of each development branch in each deployed server environment, and obtaining the test information files of different development branches of the application in each server environment.

[0225] Wherein, step S2303 specifically includes:

[0226] S1. In the development self-test phase, the unit test method corresponding to the same-process code test and the object simulation test method corresponding to the same-process module integration test are called to test the code files of each development branch in each deployed server environment, and obtain the first sub-test information files of different development branches of the application in each server environment.

[0227] S2. Obtain each first sub-test information file corresponding to the development self-test phase, and when it is determined that each first sub-test information file meets the quality test requirements, in the quality test phase, call the web page interaction-based game service test method corresponding to the single service interface asynchronous test, and the application program test method corresponding to the multi-service multi-interface asynchronous test, and perform test processing on the code files of each development branch in each deployed server environment to obtain the second sub-test information files of different development branches of the application in each server environment.

[0228] Furthermore, in step S2, the step of "in the quality testing phase, calling the game service test method based on web page interaction corresponding to the single service interface asynchronous test, and the application test method corresponding to the multi-service multi-interface asynchronous test, testing and processing the code files of each development branch in each deployed server environment, and obtaining the second sub-test information files of different development branches of the application in each server environment" specifically includes the following steps A1 to A6:

[0229] A1. In the quality testing phase, an access request based on a game service webpage is triggered to access the game service webpage, and the server to be tested and the object identifier of the game to be tested are determined based on the game service webpage.

[0230] A2. Based on the game service webpage, determine the function to be tested corresponding to the server to be tested and the game service instruction parameters corresponding to the function to be tested.

[0231] A3. Determine a matching game service instruction according to the game service instruction parameters, send the game service instruction to the game side server, instruct the game side server to convert the game service instruction into request data in a first preset format, and encapsulate the request data in the first preset format to obtain encapsulated service request data.

[0232] A4. Forward the encapsulated service request data to the message forwarding service component, and obtain the object status corresponding to the object identifier of the game under test through the message forwarding service component. If the object status is determined to be offline, return the status message of the game under test object being offline to the game side server. If the object status is determined to be online, forward the encapsulated service request data to the server under test through the message forwarding service component.

[0233] A5. Based on the code files of each development branch corresponding to the server to be tested, determine the target code file associated with the service request data corresponding to the game service instruction.

[0234] A6. Call the web page interaction-based game service test method corresponding to the single service interface asynchronous test, test the target code file associated with the game service instruction in the server to be tested deployed in each development branch, and obtain the second sub-test information file of different development branches of the application in each server environment.

[0235] The step of "testing the code files of each development branch in each deployed server environment to obtain the test information files of different development branches of the application in each server environment" in step S2303 specifically includes the following steps B1 to B3:

[0236] B1. Pull the code files corresponding to different development branches respectively, add preset compilation parameters to the code files, perform compilation preprocessing on the code files with the preset compilation parameters added, obtain assembly files, and perform stub processing on the assembly files according to the assembly statements used to collect program execution information.

[0237] B2. Perform assembly processing based on the assembly file to obtain an executable file and a code location file, and execute the executable file in each server environment deployed by different development branches respectively. At the same time, collect program execution information by running the assembly statements inserted in the assembly file to obtain code coverage information.

[0238] B3. Generate a code coverage file according to the code coverage information, and call a test information file generation component to generate a test information file according to the code location file and the code coverage file.

[0239] After executing step B3, the following steps B4 to B9 are further executed:

[0240] B4. Obtain the generation time of each test information file in real time, and call the test information file generation component to merge the historical test information file and the latest test information file according to the generation time of the test information file to obtain a merged test information file.

[0241] B5. Call the coverage client to determine the metadata information corresponding to the merged test information file, the metadata information includes the initial test information summary value of the test information file, the development branch to which the test information file belongs, the server environment to which the test information file belongs, and the version identifier of the code file to which the test information file belongs.

[0242] B6. Send the metadata information and the merged test information file to the coverage server associated with the coverage client, and determine the current test information summary value of the merged test information file through the coverage server.

[0243] B7. Compare the current test information summary value with the received metadata information. If it is determined that the current test information summary value is consistent with the initial test information summary value in the metadata information, determine the storage path of the merged test information file according to the metadata information.

[0244] B8. Obtain the merged test information file from the storage path of the merged test information file, and synchronize the merged test information file to the R&D environment.

[0245] B9. In a preset update cycle, the historical test information files and the latest test information files are incrementally merged according to the synchronization time of each test information file to obtain a current test information file after the incremental merger.

[0246] After executing step B9, execute step S2304, extract the first version identifier of the code file to which the current test information file after each incremental merger belongs, obtain each test information file belonging to a different first version identifier, and merge each test information file belonging to a different first version identifier to obtain a merged branch test information file.

[0247] Step S2305, obtaining the second version identifier corresponding to the branch test information file, and extracting the target code file corresponding to the second version identifier.

[0248] Step S2306, performing chaos processing based on the target code file to obtain the target code file after the chaos processing, and displaying the target code file after the chaos processing and its corresponding branch test information file.

[0249] In the above-mentioned application development test processing method, it is possible to achieve full and comprehensive testing of code files, reduce missed tests, and avoid the need for repeated testing due to missed tests, thereby improving the efficiency of application development testing. Furthermore, by merging the test information files belonging to different first version identifiers, a merged branch test information file is obtained, so that the test information files of code files of different versions can be concentrated to avoid missing new code files in a certain version, so as to accurately count the test information of code files of different development branches. By obtaining the second version identifier corresponding to the branch test information file and the target code file corresponding to the second version identifier, the target code file and its corresponding branch test information file can be displayed, so that the test information of each target code file under different branches can be accurately obtained, so as to timely confirm the test progress of different development branches, ensure the comprehensiveness and accuracy of the test, and further improve the development test processing efficiency in the application development process.

[0250] It should be understood that, although the steps in the flowcharts involved in the above embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0251] In an exemplary embodiment, an application development test processing system is provided, comprising a request client and a test server; wherein:

[0252] The request client is used to trigger the application development test request and send the application development test request to the test server;

[0253] A test server is used to: receive an application development test request, and obtain the development branch of the application program associated with the application development test request, and each server environment where the development branch is deployed; obtain the test phase that triggers the application development test request, and determine the test type that matches each test phase, and the test method that matches the test type; call each test method that matches the corresponding test type in each test phase, test the code file of each development branch in each deployed server environment, and obtain the test information file of different development branches of the application program in each server environment; extract the first version identifier of the code file to which each test information file belongs, and merge each test information file belonging to different first version identifiers to obtain a merged branch test information file; obtain the second version identifier corresponding to the branch test information file, and the target code file corresponding to the second version identifier, and display the target code file and its corresponding branch test information file.

[0254] In an exemplary embodiment, Fig.24 As shown, a schematic diagram of the architecture of an application development test processing system is provided. Fig.24 It can be seen that the application development test processing system includes a request client 2402, a test server 2404, a test component 2406, and a coverage platform 2408, wherein the test component 2406 includes a unit test component 24062, an object simulation test component 24064, a game service test component based on web page interaction 24066, and an application test component 24068, and the coverage platform 2408 includes a coverage client 24082 and a coverage server 24084. Among them:

[0255] The request client 2402 is used to trigger an application development test request and send the application development test request to the test server 2406 .

[0256] Test server 2404 is used to: receive an application development test request, and obtain the development branch of the application associated with the application development test request, and the server environments deployed by the development branch; obtain the test phase that triggers the application development test request, and determine the test type that matches each test phase, and the test method that matches the test type.

[0257] Among them, the test phase includes the development self-test phase, and the test types include the same-process code test and the same-process module integration test corresponding to the development self-test phase. The test methods include the unit test method corresponding to the same-process code test and the object simulation test method corresponding to the same-process module integration test. Similarly, the test phase also includes the quality test phase, and the test types include the single service interface asynchronous test and the multi-service multi-interface asynchronous test corresponding to the quality test phase. The test methods include the game service test method based on web page interaction corresponding to the single service interface asynchronous test and the application program test method corresponding to the multi-service multi-interface asynchronous test. Among them, the unit test method and the object simulation test method can be deployed on the request client and can be directly called when the application development test request is triggered, while the game service test method and the application program test method based on web page interaction need to be further deployed in a network connection manner to call the game service test method and the application program test method based on web page interaction through a network connection.

[0258] Furthermore, the test server 2404 is also used to: call each test method matching the corresponding test type in each test phase, perform test processing on the code files of each development branch in each deployed server environment, and obtain the test information files of different development branches of the application in each server environment.

[0259] Among them, the unit test component 24062 corresponds to the same-process code test in the development self-test stage, that is, by calling the unit test component 24062, the purpose of calling the unit test method corresponding to the same-process code test can be achieved. The object simulation test component 24064 corresponds to the same-process module integration test in the development self-test stage, that is, by calling the object simulation test component 24064, the purpose of calling the object simulation test method corresponding to the same-process module integration test can be achieved. The game service test component 24066 based on web page interaction corresponds to the single service interface asynchronous test in the quality test stage, that is, by calling the game service test component 24066 based on web page interaction, the purpose of calling the game service test method based on web page interaction corresponding to the single service interface asynchronous test can be achieved. The application test component 24068 corresponds to the multi-service multi-interface asynchronous test in the quality test stage, that is, by calling the application test component 24068, the purpose of calling the application test method corresponding to the multi-service multi-interface asynchronous test can be achieved.

[0260] Specifically, the test server 2404 is used to call the unit test method corresponding to the same-process code test and the object simulation test method corresponding to the same-process module integration test during the development self-test phase, test the code files of each development branch in each deployed server environment, obtain the first sub-test information files of different development branches of the application in each server environment, and obtain the first sub-test information files corresponding to the development self-test phase, and when it is determined that each first sub-test information file meets the quality testing requirements, in the quality testing phase, call the web page interaction-based game service test method corresponding to the single service interface asynchronous test and the application test method corresponding to the multi-service multi-interface asynchronous test, test the code files of each development branch in each deployed server environment, and obtain the second sub-test information files of different development branches of the application in each server environment.

[0261] In an exemplary embodiment, the test server 2404 is also used to: pull the code files corresponding to different development branches respectively, and add preset compilation parameters to the code files; the preset compilation parameters include a first compilation parameter corresponding to the code location file, and a second compilation parameter corresponding to the code coverage file; compile preprocessing the code files with the preset compilation parameters added to obtain an assembly file, and perform stub processing on the assembly file according to the assembly statement used to collect program execution information; perform assembly processing based on the assembly file to obtain an executable file and a code location file; execute the executable files in each server environment deployed by different development branches respectively, and collect program execution information by running the assembly statements inserted in the assembly file to obtain code coverage information; generate a code coverage file according to the code coverage information, and call the test information file generation component to generate a test information file according to the code location file and the code coverage file.

[0262] The test server 2404 is also used to: call the coverage client 24082 to determine the metadata information corresponding to the merged test information file; the metadata information includes the initial test information summary value of the test information file, the development branch to which the test information file belongs, the server environment to which the test information file belongs, and the version identifier of the code file to which the test information file belongs; send the metadata information and the merged test information file to the coverage server 24084 associated with the coverage client 24082, and determine the current test information summary value of the merged test information file through the coverage server 24084; compare the current test information summary value with the received metadata information, if it is determined that the current test information summary value is consistent with the initial test information summary value in the metadata information, determine the storage path of the merged test information file according to the metadata information; obtain the merged test information file from the storage path of the merged test information file, and synchronize the merged test information file to the R&D environment.

[0263] Among them, the test server 2404 can also obtain the generation time of each test information file in real time through the coverage client 24082, call the test information file generation component, merge the historical test information file and the latest test information file according to the generation time of the test information file, and obtain the merged test information file.

[0264] In an exemplary embodiment, an application development test processing system is provided, which also includes a server to be tested, a game side server associated with a game service test component 24066 based on web page interaction, a message forwarding service component, and a game service instruction storage component, wherein:

[0265] The test server 2406 is also used to: trigger an access request based on the game service webpage during the quality testing phase, access the game service webpage, and determine the server to be tested based on the game service webpage; determine the function to be tested corresponding to the server to be tested and the game service instruction parameters corresponding to the function to be tested based on the game service webpage; determine the matching game service instruction according to the game service instruction parameters, and determine the target code file associated with the game service instruction according to the code files of each development branch; call the game service test method based on webpage interaction corresponding to the single service interface asynchronous test, test the target code file associated with the game service instruction in the server to be tested deployed in each development branch, and obtain the second sub-test information file of different development branches of the application in each server environment.

[0266] Furthermore, the test server 2406 is also used to: determine the object identifier of the game to be tested based on the game service web page; determine the matching game service instruction according to the game service instruction parameters, send the game service instruction to the game side server, and instruct the game side server to convert the game service instruction into request data in a first preset format; encapsulate the request data in the first preset format to obtain encapsulated service request data; forward the encapsulated service request data to the message forwarding service component, obtain the object status corresponding to the object identifier of the game to be tested through the message forwarding service component, and if the object status is determined to be online, forward the encapsulated service request data to the server to be tested through the message forwarding service component; if the object status is determined to be offline, return a status message indicating that the game to be tested is offline to the game side server; based on the code files of each development branch corresponding to the server to be tested, determine the target code file associated with the service request data corresponding to the game service instruction.

[0267] In the above-mentioned application development test processing system, by obtaining the development branch of the application associated with the received application development test request and the server environments deployed by the development branch, and obtaining the test phase that triggers the application development test request, the test type matching each test phase and the test method matching the test type are determined. Among them, by calling each test method matching the corresponding test type in the test phase, the code files of each development branch are tested in each deployed server environment, and the test information files of different development branches of the application in each server environment are obtained, so that different test methods can be deployed in different test phases, so as to achieve full and comprehensive testing of the code files, reduce missed tests, and avoid the situation where repeated tests are required due to missed tests, thereby improving the efficiency of application development testing. Furthermore, by extracting the first version identifier of the code file to which each test information file belongs, and merging the test information files belonging to different first version identifiers, the merged branch test information file is obtained, so that the test information files of code files of different versions can be concentrated, avoiding the omission of new code files in a certain version, so as to accurately count the test information of code files of different development branches. By obtaining the second version identifier corresponding to the branch test information file and the target code file corresponding to the second version identifier, the target code file and its corresponding branch test information file can be displayed, so as to accurately obtain the test information of each target code file under different branches, and timely confirm the test progress of different development branches, thereby ensuring the comprehensiveness and accuracy of the test, and further improving the development and test processing efficiency in the application development process.

[0268] Based on the same inventive concept, the embodiment of the present application also provides an application development test processing device for implementing the application development test processing method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more application development test processing device embodiments provided below can refer to the limitations on the application development test processing method above, and will not be repeated here.

[0269] In an exemplary embodiment, Fig.25 As shown, an application development test processing device is provided, including: an application development test request receiving module 2502, a test method determining module 2504, a test information file obtaining module 2506, a test information file merging module 2508 and a display module 2510, wherein:

[0270] The application development test request receiving module 2502 is used to receive the application development test request and obtain the development branch of the application program associated with the application development test request and each server environment deployed by the development branch;

[0271] The test method determination module 2504 is used to obtain the test phase that triggers the application development test request, and determine the test type that matches each test phase, and the test method that matches the test type;

[0272] The test information file acquisition module 2506 is used to call each test method matching the corresponding test type in each test phase, perform test processing on the code files of each development branch in each deployed server environment, and obtain the test information files of different development branches of the application in each server environment;

[0273] The test information file merging module 2508 is used to extract the first version identifier of the code file to which each test information file belongs, and merge the test information files belonging to different first version identifiers to obtain a merged branch test information file;

[0274] The display module 2510 is used to obtain the second version identifier corresponding to the branch test information file and the target code file corresponding to the second version identifier, and display the target code file and its corresponding branch test information file.

[0275] In the above-mentioned application development test processing device, by obtaining the development branch of the application associated with the received application development test request and the server environments deployed by the development branch, and obtaining the test phase that triggers the application development test request, the test type matching each test phase and the test method matching the test type are determined. Among them, by calling each test method matching the corresponding test type in the test phase, the code files of each development branch are tested in each deployed server environment, and the test information files of different development branches of the application in each server environment are obtained, so that different test methods can be deployed in different test phases, respectively, to achieve full and comprehensive testing of the code files, reduce missed tests, and avoid the situation where repeated tests are required due to missed tests, thereby improving the efficiency of application development testing. Furthermore, by extracting the first version identifier of the code file to which each test information file belongs, and merging the test information files belonging to different first version identifiers, the merged branch test information file is obtained, so that the test information files of code files of different versions can be concentrated, avoiding the omission of new code files in a certain version, so as to accurately count the test information of code files of different development branches. By obtaining the second version identifier corresponding to the branch test information file and the target code file corresponding to the second version identifier, the target code file and its corresponding branch test information file can be displayed, so as to accurately obtain the test information of each target code file under different branches, and timely confirm the test progress of different development branches, thereby ensuring the comprehensiveness and accuracy of the test, and further improving the development and test processing efficiency in the application development process.

[0276] In an exemplary embodiment, the test information file acquisition module is also used to: in the development self-test stage, call the unit test method corresponding to the same-process code test and the object simulation test method corresponding to the same-process module integration test, test the code files of each development branch in each deployed server environment, and obtain the first sub-test information files of different development branches of the application in each server environment; wherein the first sub-test information file includes the code location file and code coverage file of each development branch in each server environment in the development self-test stage.

[0277] In an exemplary embodiment, the test information file acquisition module is also used to: obtain each first sub-test information file corresponding to the development self-test stage, and when it is determined that each first sub-test information file meets the quality test requirements, in the quality test stage, call the web page interaction-based game service test method corresponding to the single service interface asynchronous test, and the application test method corresponding to the multi-service multi-interface asynchronous test, test the code files of each development branch in each deployed server environment, and obtain the second sub-test information files of different development branches of the application in each server environment; wherein the second sub-test information file includes the code location file and code coverage file of each development branch in each server environment under the quality test stage.

[0278] In an exemplary embodiment, the test information file acquisition module is also used to: pull the code files corresponding to different development branches respectively, and add preset compilation parameters to the code files; the preset compilation parameters include a first compilation parameter corresponding to the code location file, and a second compilation parameter corresponding to the code coverage file; compile preprocessing the code file with the preset compilation parameters to obtain an assembly file, and perform stub processing on the assembly file according to the assembly statement used to collect program execution information; perform assembly processing based on the assembly file to obtain an executable file and a code location file; execute the executable files in each server environment deployed by different development branches respectively, and collect program execution information by running the assembly statements inserted in the assembly file to obtain code coverage information; generate a code coverage file according to the code coverage information, and call the test information file generation component to generate a test information file according to the code location file and the code coverage file.

[0279] In an exemplary embodiment, an application development test processing device is provided, further comprising:

[0280] A generation time acquisition module is used to obtain the generation time of each test information file in real time;

[0281] A merging module is used to call the test information file generation component, merge the historical test information file and the latest test information file according to the generation time of the test information file, and obtain the merged test information file;

[0282] A metadata information determination module is used to call the coverage client to determine the metadata information corresponding to the merged test information file; the metadata information includes an initial test information summary value of the test information file, a development branch to which the test information file belongs, a server environment to which the test information file belongs, and a version identifier of the code file to which the test information file belongs;

[0283] A current test information summary value determination module is used to send metadata information and the merged test information file to a coverage server associated with a coverage client, and determine the current test information summary value of the merged test information file through the coverage server;

[0284] The comparison module is further used to compare the current test information summary value with the received metadata information, and if it is determined that the current test information summary value is consistent with the initial test information summary value in the metadata information, the storage path of the merged test information file is determined according to the metadata information;

[0285] The test information file synchronization module is used to obtain the merged test information file from the storage path of the merged test information file and synchronize the merged test information file to the research and development environment.

[0286] In an exemplary embodiment, an application development test processing device is provided, further comprising an incremental merging processing module, for performing incremental merging processing on historical test information files and latest test information files according to the synchronization time of each test information file within a preset update cycle, to obtain a current test information file after incremental merging;

[0287] The test information file merging module is also used to: extract the first version identifier of the code file to which the current test information file after each incremental merger belongs, and obtain each test information file belonging to a different first version identifier; merge each test information file belonging to a different first version identifier to obtain a merged branch test information file.

[0288] In an exemplary embodiment, the display module is also used to: obtain a second version identifier corresponding to a branch test information file, and extract a target code file corresponding to the second version identifier; perform chaotic processing based on the target code file to obtain a target code file after chaotic processing; and display the target code file after chaotic processing and its corresponding branch test information file.

[0289] In an exemplary embodiment, the test information file acquisition module is also used to: in the quality testing stage, trigger an access request based on a game service web page, access the game service web page, and determine the server to be tested based on the game service web page; determine the function to be tested corresponding to the server to be tested, and the game service instruction parameters corresponding to the function to be tested based on the game service web page; determine the matching game service instruction according to the game service instruction parameters, and determine the target code file associated with the game service instruction according to the code files of each development branch; call the game service test method based on web page interaction corresponding to the single service interface asynchronous test, test the target code file associated with the game service instruction in the server to be tested deployed in each development branch, and obtain the second sub-test information file of different development branches of the application in each server environment.

[0290] In an exemplary embodiment, the test information file acquisition module is also used to: determine the object identifier of the game to be tested based on the game service web page; determine the matching game service instruction according to the game service instruction parameter, send the game service instruction to the game side server, and instruct the game side server to convert the game service instruction into request data in a first preset format; encapsulate the request data in the first preset format to obtain encapsulated service request data; forward the encapsulated service request data to the message forwarding service component, obtain the object status corresponding to the object identifier of the game to be tested through the message forwarding service component, if the object status is determined to be online, forward the encapsulated service request data to the server to be tested through the message forwarding service component; if the object status is determined to be offline, return a status message indicating that the game to be tested is offline to the game side server; based on the code files of each development branch corresponding to the server to be tested, determine the target code file associated with the service request data corresponding to the game service instruction.

[0291] In an exemplary embodiment, the test information file acquisition module is also used to: determine the matching game service instructions based on the game service instruction parameters, and perform instruction query processing based on the game service instruction storage component to determine whether the game service instruction exists in the game service instruction storage component; if it is determined that the game service instruction exists in the game service instruction storage component, send the game service instruction to the game side server, obtain the first preset format supported by the game side server, and instruct the game side server to convert the game service instruction into request data in the first preset format.

[0292] In an exemplary embodiment, an application development test processing device is provided, which also includes an execution result display module, which is used to: parse the encapsulated service request data and obtain the request execution logic corresponding to the encapsulated service request data; instruct the server to be tested to execute the request execution logic and perform information synchronization processing on the object attribute information of the object identifier used by the game to be tested; the information synchronization processing includes adding attribute information, modifying attribute information, and deleting at least one of the attribute information; feeding back the execution result of the execution of the request execution logic by the server to be tested to the game side server, and obtaining the second preset format supported by the game service webpage, and after the execution result is encapsulated into the execution data of the second preset format by the game side server, it is fed back to the game service webpage for display.

[0293] Each module in the above-mentioned application development test processing device can be implemented in whole or in part by software, hardware and their combination. Each of the above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to each of the above modules.

[0294] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Fig.26 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store the development branches of the application program associated with the application development test request, the server environments deployed by each development branch, the test phase of the application development test request, the test type matching each test phase, the test method matching the test type, the test information file of different development branches of the application program in each server environment, the first version identifier of the code file to which each test information file belongs, the merged branch test information file, the second version identifier corresponding to the branch test information file, and the target code file corresponding to the second version identifier. The input / output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by a processor, an application development test processing method is implemented.

[0295] Those skilled in the art will understand that Fig.26 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0296] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above-mentioned application development test processing method when executing the computer program.

[0297] In an exemplary embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned application development test processing method are implemented.

[0298] In an exemplary embodiment, a computer program product is provided, including a computer program, which implements the steps in the above-mentioned application development test processing method when executed by a processor.

[0299] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0300] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0301] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0302] The above embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. An application development test processing method, characterized in that: The method comprises: Receive an application development test request, and obtain a development branch of an application program associated with the application development test request, and each server environment where the development branch is deployed; Acquire the test phase that triggers the application development test request, and determine the test type that matches each of the test phases, and the test method that matches the test type; Invoke each test method matching the corresponding test type in each test phase, perform test processing on the code files of each development branch in each deployed server environment, and obtain test information files of different development branches of the application in each server environment; Extracting the first version identifier of the code file to which each of the test information files belongs, and merging the test information files belonging to different first version identifiers to obtain a merged branch test information file; A second version identifier corresponding to the branch test information file and a target code file corresponding to the second version identifier are obtained, and the target code file and its corresponding branch test information file are displayed.

2. The method according to claim 1, characterized in that The testing phase includes a development self-test phase, the test types include same-process code testing and same-process module integration testing corresponding to the development self-test phase, and the testing methods include unit testing methods corresponding to the same-process code testing and object simulation testing methods corresponding to the same-process module integration testing; In the test phase, each test method matching the corresponding test type is called, and the code files of each development branch are tested in each deployed server environment to obtain the test information files of different development branches of the application in each server environment, including: In the development self-test phase, the unit test method corresponding to the same-process code test and the object simulation test method corresponding to the same-process module integration test are called to test the code files of each development branch in each deployed server environment, and obtain the first sub-test information files of different development branches of the application in each server environment; The first sub-test information file includes a code location file and a code coverage file of each development branch in each server environment during the development self-test phase.

3. The method according to claim 2, characterized in that The test phase also includes a quality test phase, the test types include a single service interface asynchronous test and a multi-service multi-interface asynchronous test corresponding to the quality test phase, and the test methods include a game service test method based on web page interaction corresponding to the single service interface asynchronous test and an application test method corresponding to the multi-service multi-interface asynchronous test; In the test phase, each test method matching the corresponding test type is called, and the code files of each development branch are tested in each deployed server environment to obtain the test information files of different development branches of the application in each server environment, including: Obtain each first sub-test information file corresponding to the development self-test phase, and when it is determined that each first sub-test information file meets the quality test requirements, in the quality test phase, call the game service test method based on web page interaction corresponding to the single service interface asynchronous test, and the application test method corresponding to the multi-service multi-interface asynchronous test, perform test processing on the code file of each development branch in each deployed server environment, and obtain the second sub-test information file of different development branches of the application in each of the server environments; The second sub-test information file includes a code location file and a code coverage file of each development branch in each server environment during the quality test phase.

4. The method according to claim 2 or 3, characterized in that: The code files of each development branch are tested in each deployed server environment to obtain test information files of different development branches of the application in each server environment, including: Pulling code files corresponding to different development branches respectively, and adding preset compilation parameters for the code files; the preset compilation parameters include a first compilation parameter corresponding to the code location file, and a second compilation parameter corresponding to the code coverage file; Performing compilation preprocessing on the code file to which the preset compilation parameters are added to obtain an assembly file, and performing stub processing on the assembly file according to the assembly statement for collecting program execution information; Performing assembly processing based on the assembly file to obtain an executable file and a code location file; In each server environment deployed by different development branches, the executable files are respectively executed, and program execution information is collected by running the assembly statements inserted in the assembly files to obtain code coverage information; A code coverage file is generated according to the code coverage information, and a test information file generation component is called to generate the test information file according to the code location file and the code coverage file.

5. The method according to claim 4, characterized in that After generating the test information file, it also includes: Obtaining the generation time of each of the test information files in real time; Calling the test information file generation component, merging the historical test information file and the latest test information file according to the generation time of the test information file, and obtaining a merged test information file; Calling the coverage client to determine metadata information corresponding to the merged test information file; the metadata information includes an initial test information summary value of the test information file, a development branch to which the test information file belongs, a server environment to which the test information file belongs, and a version identifier of a code file to which the test information file belongs; Sending the metadata information and the merged test information file to a coverage server associated with the coverage client, and determining a current test information summary value of the merged test information file through the coverage server; Comparing the current test information digest value with the received metadata information, if it is determined that the current test information digest value is consistent with the initial test information digest value in the metadata information, determining the storage path of the merged test information file according to the metadata information; The merged test information file is obtained from the storage path of the merged test information file, and the merged test information file is synchronized to the research and development environment.

6. The method according to claim 5, characterized in that After synchronizing the merged test information file to each server environment deployed in different development branches, it also includes: In a preset update cycle, the historical test information file and the latest test information file are incrementally merged according to the synchronization time of each test information file to obtain a current test information file after the incremental merger; The extracting the first version identifier of the code file to which each of the test information files belongs, and merging the test information files belonging to different first version identifiers to obtain a merged branch test information file includes: Extracting the first version identifier of the code file to which the current test information file after each incremental merger belongs, and obtaining each of the test information files belonging to a different first version identifier; The test information files belonging to different first version identifiers are merged to obtain a merged branch test information file.

7. The method according to claim 6, characterized in that The obtaining the second version identifier corresponding to the branch test information file and the target code file corresponding to the second version identifier, and displaying the target code file and its corresponding branch test information file, includes: Obtaining a second version identifier corresponding to the branch test information file, and extracting a target code file corresponding to the second version identifier; Performing chaos processing based on the target code file to obtain the target code file after chaos processing; The target code file after the chaos processing and its corresponding branch test information file are displayed.

8. The method according to claim 3, characterized in that In the quality test phase, the game service test method based on web page interaction corresponding to the single service interface asynchronous test is called, the code files of each development branch are tested in each deployed server environment, and the second sub-test information files of different development branches of the application in each server environment are obtained, including: In the quality test phase, triggering an access request based on a game service webpage, accessing the game service webpage, and determining a server to be tested based on the game service webpage; Based on the game service webpage, determining a function to be tested corresponding to the server to be tested and a game service instruction parameter corresponding to the function to be tested; Determining a matching game service instruction according to the game service instruction parameter, and determining a target code file associated with the game service instruction according to the code files of each development branch; The game service test method based on web page interaction corresponding to the single service interface asynchronous test is called, and the target code file associated with the game service instruction is tested in the server to be tested deployed in each development branch to obtain the second sub-test information file of the different development branches of the application in each server environment.

9. The method according to claim 8, characterized in that When accessing the game service webpage, the method further includes: determining a user identifier of the game to be tested based on the game service webpage; The step of determining a matching game service instruction according to the game service instruction parameter, and determining a target code file associated with the game service instruction according to the code files of each development branch, comprises: Determining a matching game service instruction according to the game service instruction parameter, sending the game service instruction to the game side server, and instructing the game side server to convert the game service instruction into request data in a first preset format; Encapsulating the request data in the first preset format to obtain encapsulated service request data; Forwarding the packaged service request data to a message forwarding service component, obtaining the object status corresponding to the object identifier of the game to be tested through the message forwarding service component, and if it is determined that the object status is an online state, forwarding the packaged service request data to the server to be tested through the message forwarding service component; If it is determined that the object state is offline, returning a state message indicating that the game usage object to be tested is offline to the game side server; Based on the code files of each development branch corresponding to the server to be tested, a target code file associated with the service request data corresponding to the game service instruction is determined.

10. The method according to claim 9, characterized in that The determining a matching game service instruction according to the game service instruction parameter, sending the game service instruction to a game side server, and instructing the game side server to convert the game service instruction into request data in a first preset format includes: Determine a matching game service instruction according to the game service instruction parameter, and perform instruction query processing based on the game service instruction storage component to determine whether the game service instruction exists in the game service instruction storage component; If it is determined that the game service instruction exists in the game service instruction storage component, the game service instruction is sent to the game side server, a first preset format supported by the game side server is obtained, and the game side server is instructed to convert the game service instruction into request data in the first preset format.

11. The method according to claim 9 or 10, characterized in that: After forwarding the encapsulated service request data to the server to be tested through the message forwarding service component, the method further includes: Parsing the encapsulated service request data to obtain the request execution logic corresponding to the encapsulated service request data; Instructing the server to be tested to execute the request execution logic to perform information synchronization processing on the object attribute information of the object identifier used by the game to be tested; the information synchronization processing includes at least one of adding attribute information, modifying attribute information, and deleting attribute information; The execution result of the request execution logic executed by the server under test is fed back to the game side server, and a second preset format supported by the game service webpage is obtained. After the game side server encapsulates the execution result into execution data in the second preset format, it is fed back to the game service webpage for display.

12. An application development test processing system, characterized in that: The system comprises a request client and a test server; wherein: The request client is used to trigger an application development test request and send the application development test request to a test server; The test server is used to: receive the application development test request, and obtain the development branch of the application program associated with the application development test request, and each server environment deployed by the development branch; obtain the test phase that triggers the application development test request, and determine the test type matching each test phase, and the test method matching the test type; call each test method matching the corresponding test type in each test phase, respectively, test and process the code file of each development branch in each deployed server environment, and obtain the test information file of different development branches of the application program in each server environment; extract the first version identifier of the code file to which each test information file belongs, and merge the test information files belonging to different first version identifiers to obtain the merged branch test information file; obtain the second version identifier corresponding to the branch test information file, and the target code file corresponding to the second version identifier, and display the target code file and its corresponding branch test information file.

13. An application development test processing device, characterized in that: The device comprises: An application development test request receiving module, used to receive an application development test request, and obtain a development branch of an application program associated with the application development test request, and each server environment where the development branch is deployed; A test method determination module, used to obtain the test phase that triggers the application development test request, and determine the test type matching each of the test phases, and the test method matching the test type; A test information file acquisition module, used to call each test method matching the corresponding test type in each test phase, perform test processing on the code file of each development branch in each deployed server environment, and obtain the test information file of different development branches of the application in each server environment; A test information file merging module, used to extract the first version identifier of the code file to which each of the test information files belongs, and merge the test information files belonging to different first version identifiers to obtain a merged branch test information file; The display module is used to obtain the second version identifier corresponding to the branch test information file and the target code file corresponding to the second version identifier, and display the target code file and its corresponding branch test information file.

14. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 11 are implemented.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 11 are implemented.

Citation Information

Cited By

  • Server test system and method, electronic equipment and storage medium

    CN120315956A