CN116467158A

CN116467158A - Code testing method, device, computer equipment and storage medium

Info

Publication number: CN116467158A
Application number: CN202210034736.5A
Authority: CN
Inventors: 周勇钧
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2022-01-12
Filing date: 2022-01-12
Publication date: 2023-07-21

Abstract

The utility model relates to a code test method, a device, a computer device, a storage medium and a computer program product, wherein a instrumentation pile is woven into a source code to be tested to construct instrumentation pile executable files, the instrumentation pile executable files are deployed in each container test environment, a plurality of abnormal injection test scenes corresponding to the source code to be tested are obtained at the same time, and then the abnormal injection test scenes are respectively injected into each container test environment, so that parallel test verification is carried out on the source code to be tested, and high-efficiency test can be effectively carried out on the reliability of the source code to be tested when the source code to be tested faces to abnormal conditions.

Description

Code testing method, device, computer equipment and storage medium

Technical Field

The present application relates to the field of computer technology, and in particular, to a code testing method, apparatus, computer device, storage medium, and computer program product.

Background

With the development of computer technology, various kinds of computer-based services are also developing at a high speed. To meet the requirements of high performance and availability of computer services, business programs introduce various concurrent processing, asynchronous processing or various caching mechanism modes to solve the problems. For example, in a blockchain service based on computer and network technology, in order to improve the validity check of a transaction set in a block, a multi-cooperative concurrency mode is introduced to improve the verification efficiency, and in order to improve the consensus efficiency and the storage performance of mass data in a cluster, an asynchronous communication and voting waiting mode is introduced.

However, with the continuous introduction of these high-performance services, the complexity of the architecture of the service program is also improved, the difficulty of testing and verifying the service program is improved, and the testing efficiency is lower.

Disclosure of Invention

In view of the foregoing, it is desirable to provide a code testing method, apparatus, computer device, storage medium, and computer program product that can effectively improve the efficiency of testing for business program high performance services.

In a first aspect, the present application provides a code testing method. The method comprises the following steps:

acquiring a source code to be tested, weaving in and inserting the source code to be tested, and acquiring an inserting executable file corresponding to the source code to be tested;

deploying the instrumentation executable file in each container testing environment in a preset multi-container testing environment;

acquiring random abnormal injection test scene data corresponding to the source code to be tested;

and respectively performing scene injection in the deployed multiple container test environments based on the random abnormal injection test scene data to obtain a test result corresponding to the source code to be tested.

In a second aspect, the present application further provides a code testing device. The device comprises:

The data acquisition module is used for acquiring a source code to be tested, weaving in the instrumentation processing for the source code to be tested, and acquiring an instrumentation executable file corresponding to the source code to be tested;

the file deployment module is used for deploying the instrumentation executable file in each container testing environment in a preset multi-container testing environment;

the scene acquisition module is used for acquiring random abnormal injection test scene data corresponding to the source code to be tested;

and the injection test module is used for respectively carrying out scene injection in the deployed multiple container test environments based on the random abnormal injection test scene data to obtain a test result corresponding to the source code to be tested.

In a third aspect, the present application also provides a computer device. The computer device comprises a memory storing a computer program and a processor which when executing the computer program performs the steps of:

In a fourth aspect, the present application also provides a computer-readable storage medium. The computer readable storage medium having stored thereon a computer program which when executed by a processor performs the steps of:

In a fifth aspect, the present application also provides a computer program product. The computer program product comprises a computer program which, when executed by a processor, implements the steps of:

The code testing method, the code testing device, the computer equipment, the storage medium and the computer program product are characterized in that the method comprises the steps of obtaining source codes to be tested, performing weaving-in instrumentation processing on the source codes to be tested, and obtaining instrumentation executable files corresponding to the source codes to be tested; deploying the instrumentation executable file in each container testing environment in a preset multi-container testing environment; acquiring random abnormal injection test scene data corresponding to a source code to be tested; and based on the random abnormal injection test scene data, respectively performing scene injection in a plurality of deployed container test environments to obtain a test result corresponding to the source code to be tested. In the method, the instrumentation pile is woven into the instrumentation pile to construct the instrumentation pile executable file, the instrumentation pile executable file is deployed in each container test environment, a plurality of abnormal injection test scenes corresponding to the source code to be tested are obtained at the same time, and then the abnormal injection test scenes are respectively injected into each container test environment, so that parallel test verification is carried out on the source code to be tested, and high-efficiency test can be effectively carried out on the reliability of the source code to be tested in the face of abnormal conditions.

Drawings

FIG. 1 is a schematic diagram of an application environment of a code testing method in one embodiment;

FIG. 2 is a flow chart of a code testing method in one embodiment;

FIG. 3 is a schematic diagram illustrating a process of performing a weave instrumentation process on source code to be tested in one embodiment;

FIG. 4 is a schematic diagram of a process of constructing a scenario data step of a random anomaly injection test scenario in one embodiment;

FIG. 5 is a flow diagram of the steps for determining a critical function call link in one embodiment;

FIG. 6 is a flow diagram of the identify key function call step in one embodiment;

FIG. 7 is a flowchart illustrating steps for obtaining test results corresponding to source code to be tested in one embodiment;

FIG. 8 is a flowchart illustrating a step of updating a predetermined anomaly injection model in one embodiment;

FIG. 9 is a flow chart of a code testing method according to another embodiment;

FIG. 10 is a block diagram of a code testing device in one embodiment;

FIG. 11 is an internal block diagram of a computer device in one embodiment.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be further described in detail with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the present application.

The code testing method provided by the embodiment of the application can be applied to an application environment shown in fig. 1. Wherein the terminal 102 communicates with the server 104 via a network. The data storage system may store data that the server 104 needs to process. The data storage system may be integrated on the server 104 or may be located on a cloud or other network server. When a worker on the terminal 102 side needs to test the performance of a business code in an abnormal environment, the code test can be performed by the server 104. The terminal 102 firstly sends a source code to be tested to the server 104, the server 104 acquires the source code to be tested, and the source code to be tested is woven into the instrumentation processing to acquire an instrumentation executable file corresponding to the source code to be tested; deploying the instrumentation executable file in each container testing environment in a preset multi-container testing environment; acquiring random abnormal injection test scene data corresponding to a source code to be tested; and based on the random abnormal injection test scene data, respectively performing scene injection in a plurality of deployed container test environments to obtain a test result corresponding to the source code to be tested. The terminal 102 may be, but not limited to, various personal computers, notebook computers, smart phones, tablet computers, internet of things devices, and portable wearable devices, where the internet of things devices may be smart speakers, smart televisions, smart air conditioners, smart vehicle devices, and the like. The portable wearable device may be a smart watch, smart bracelet, headset, or the like. The server 104 may be implemented as a stand-alone server or a cluster of servers, or may be a node on a blockchain.

In one embodiment, as shown in fig. 2, a code testing method is provided, and the method is applied to the server 104 in fig. 1 for illustration, and includes the following steps:

and step 201, obtaining a source code to be tested, weaving in the instrumentation processing of the source code to be tested, and obtaining an instrumentation executable file corresponding to the source code to be tested.

The source code to be tested is the target code tested in the code testing method, and the code testing method is used for carrying out random exception injection test on the source code to be tested. The exception test is a test type different from the function test and the performance test, and through the exception test, the performance bottleneck caused by system exception, dependence service exception, application self exception and other reasons can be found, so that the stability of the system is improved. The source code to be tested can be a code corresponding to a service application, in a specific embodiment, the source code to be tested can be a blockchain application program, in a blockchain service, in order to improve the validity check of a transaction set in a block, a multi-cooperative concurrency mode is introduced to improve the verification efficiency, and in order to improve the consensus efficiency in a cluster and the storage performance of mass data, an asynchronous communication and voting waiting mode is introduced. The high-performance architecture complexity is improved, and the difficulty of test verification is also improved, so that the block chain application program can be tested through the technical scheme. The instrumentation processing is program instrumentation, which is a method for inserting some probes (also called "probes", essentially, code segments for information acquisition, which can be assignment statements or function calls for acquisition of coverage information) into a program on the basis of ensuring the original logic integrity of the tested program, executing the probes and throwing out characteristic data of program operation, and analyzing the data to obtain control flow and data flow information of the program, further obtaining dynamic information such as logic coverage and the like, thereby realizing the test purpose. And the instrumentation is to dynamically insert instrumentation code under the base of the source code. In the scheme of the application, the executable file capable of injecting function level abnormality in real time is mainly generated through instrumentation, namely, the instrumentation executable file. After instrumentation, the original function call is inserted with function exception injection, which generally provides function level exception injection of delay, skip, repeat execution, throw error, etc.

Specifically, in the scheme of the application, the service source code is tested in a code instrumentation mode, so that after the source code to be tested is obtained, in order to realize the test processing of the source code to be tested, the source code to be tested needs to be woven in instrumentation processing first, function exception injection processing is inserted in original function call of the source code to be tested through instrumentation, instrumentation executable files corresponding to the source code to be tested are obtained, and the function exception injection processing provides function level exception injection such as delay, skip, repeated execution, polishing and the like. Thus, the random exception injection test for the source code to be tested can be realized.

In step 203, the instrumented executable file is deployed within each of the container test environments in the preset multi-container test environment.

The container effectively divides the resources of a single operating system into isolated groups so as to better balance conflicting resource use requirements among the isolated groups. The preset multi-container test environment specifically refers to an operation environment in which a plurality of containers are deployed in parallel, and each container specifically corresponds to a test file and is used for executing a test of abnormal injection.

Specifically, after the instrumented executable files are obtained, the files can be directly subjected to abnormal instrumentation to perform substitution testing. In order to test the code, a test environment needs to be deployed first, and the scheme of the application specifically establishes the test environment for the code test by presetting a multi-container test environment. Therefore, the obtained instrumentation executable files can be deployed in each container testing environment in a preset multi-container testing environment, the instrumentation executable files can be operated in the testing environment, and then the testing of the source code to be tested can be realized by monitoring the operation condition of the instrumentation executable files in the containers.

Step 205, acquiring random anomaly injection test scene data corresponding to the source code to be tested.

The random exception injection test scene is specifically used for providing exception injection of different function levels, including providing function level exception injection of delay, skip, repeat execution, throwing error and the like. The random anomaly injection test scene specifically needs to set data such as anomaly type, occurrence probability, anomaly parameters and the like, and when the setting is completed, scene data of the random anomaly injection test scene such as pre-execution delay, post-execution delay, pre-execution service anomaly exit, post-execution service anomaly exit or event timeout time tampering can be obtained.

Specifically, the scheme of the application is specifically used for carrying out random function exception injection test on the source code to be tested, so that during the test, scene data of an exception injection test scene is injected in the running process of the executable file corresponding to the source code to be tested, and the running effect verification of the executable file under the exception injection condition is realized. And obtaining corresponding test result data.

Step 207, performing scene injection in the deployed multiple container test environments based on the random abnormal injection test scene data, respectively, to obtain a test result corresponding to the source code to be tested.

Specifically, when obtaining the scene data of a plurality of random abnormal injection test scenes, the server 102 may inject the scene data into each container test environment in the preset multi-container test environment, where the instrumentation executable file is deployed, so that each scene data may be injected into each container test environment correspondingly, and each container test environment corresponds to the scene data of an abnormal injection test scene. And performing injection test under an abnormal injection test scene on the source code to be tested. And the parallel test of the source code to be tested can be realized by respectively injecting the scene data into each container test environment in the preset multi-container test environment. And obtaining test result data of the source code to be tested under each abnormal injection test scene. In one embodiment, the pressure test tool may be used to apply pressure to a preset multi-container test environment, so as to obtain a test result corresponding to the source code to be tested in the continuous pressure test process.

According to the code testing method, the source code to be tested is obtained, the instrumentation processing is carried out on the source code to be tested, and the instrumentation executable file corresponding to the source code to be tested is obtained; deploying the instrumentation executable file in each container testing environment in a preset multi-container testing environment; acquiring random abnormal injection test scene data corresponding to a source code to be tested; and based on the random abnormal injection test scene data, respectively performing scene injection in a plurality of deployed container test environments to obtain a test result corresponding to the source code to be tested. In the method, the instrumentation pile is woven into the instrumentation pile to construct the instrumentation pile executable file, the instrumentation pile executable file is deployed in each container test environment, a plurality of abnormal injection test scenes corresponding to the source code to be tested are obtained at the same time, and then the abnormal injection test scenes are respectively injected into each container test environment, so that parallel test verification is carried out on the source code to be tested, and high-efficiency test can be effectively carried out on the reliability of the source code to be tested in the face of abnormal conditions.

In one embodiment, step 201 specifically includes: and weaving the source code to be tested into the instrumentation processing by a tangent plane programming mode or a hook mode to obtain an instrumentation executable file corresponding to the source code to be tested.

The tangent plane programming method is a AOP (Aspect Oriented Programming) technology, and can extract the tangent plane in the service processing process and dynamically cut codes into the designated method and position. The Hook, called Hook function, can capture the message before the system calls the function, and the Hook function gets control first, so that the Hook function can process (change) the execution behavior of the function and can force the end of the message transfer. The hook can capture calling information and process the calling information, and then the original operation is executed when the source function is called.

Specifically, the instrumentation processing of the source code to be tested can be realized in a tangent plane-oriented programming mode or a hook mode, so that an executable file capable of injecting function-level exceptions in real time is generated. The function call relationship before and after instrumentation may specifically refer to fig. 3, and after instrumentation processing is performed on source codes to be tested in a tangent plane-oriented programming manner or a hook manner, function exception injection processing is inserted into the original function call relationship, so that function level exception injection such as delay, skip, repeat execution, polishing and the like is provided. In this embodiment, instrumentation of the source code to be tested is implemented in a tangent plane programming mode or a hook mode, so that an instrumentation executable file for executing an abnormal injection test can be obtained more efficiently, and the function abnormal injection capability of the program is ensured.

In one embodiment, as shown in FIG. 4, step 205 includes:

step 401, acquiring a key function call link corresponding to a source code to be tested.

Step 403, generating a plurality of random abnormal injection test scene data based on the key function call link and the preset abnormal injection model.

The function call link is used for accommodating call relations among different functions in the source code to be tested. The key function call chain is used for forming a key function call, and in one embodiment, the key function may specifically include a function for implementing functions of reading and writing a cache, reading and writing a database, receiving and sending network information, processing event cycle messages, and a heartbeat monitoring mechanism in the source code to be tested. The preset abnormal injection model is used for recording function features corresponding to each key function, so that the construction of scene data is realized.

Specifically, the scheme of the present application may implement construction of a random exception injection test scenario by using a function random exception injection tool built in the server 102, first, a data flow model corresponding to a source code to be tested may be determined by analyzing the source code, and a key function call link may be analyzed. Based on the key function call, various parallel or logic parallel key functions are obtained. Then, the random function exception injection tool in the server 102 combines the function features of the preset exception injection model, and correlates the matched key functions to the required type of the injected exception, occurrence probability, exception parameters, etc., such as delay before execution, delay after execution, service exception exit before execution, service exception exit after execution, or event timeout time tampering, etc. Thereby constructing scene data of a plurality of random abnormal injection test scenes to realize the abnormal injection test of the source code to be tested. In this embodiment, the scene data of the random abnormal injection test scene is constructed by calling the link and the preset abnormal injection model by the key function, so that the scene data of a plurality of different random abnormal injection test scenes can be effectively constructed, smooth running of the code test process is ensured, and meanwhile, the effectiveness of the abnormal injection test is ensured.

In one embodiment, as shown in FIG. 5, step 401 includes:

step 502, running the source code to be tested, and acquiring a key function call relation in the source code to be tested by taking a coroutine, a thread or a process as a unit.

And step 504, acquiring a key function call link corresponding to the source code to be tested according to the key function call relation.

The process is a process of dynamically executing a program with a certain independent function on a data set, is an independent unit for the operating system to allocate and schedule resources, and is a carrier for the application program to run. A thread is a single sequential control flow in program execution, is the smallest unit of program execution flow, and is the basic unit of processor scheduling and dispatch. A process may have one or more threads, with each thread sharing a program's memory space (i.e., the memory space of the process in which it resides). A standard thread consists of a thread ID, a current instruction Pointer (PC), registers and a stack. And a process consists of memory space (code, data, process space, open files) and one or more threads. Coroutines are based on the existence of threads, but which are lighter than threads, and are managed by programmers writing programs themselves, called "user space threads", with the feature of being invisible to the kernel. Just as a process may own multiple threads, a thread may also own multiple threads.

Specifically, through analysis, it can be determined that key function calls forming a data flow model can appear in two dimensions, one is parallel processing dimension, and parallel injection verification is performed by taking a coroutine, a thread or a process as dimensions respectively; and the other is an event-loop message handling mechanism, a single co-program, thread or process to accept messages, possibly in a synchronous or concurrent manner to handle messages or events. Therefore, in the scheme of the application, the function call can be counted and analyzed by taking the coroutine, the thread or the process as a unit, so that the function call relation is automatically extracted, and the key function call link corresponding to the source code to be tested can be further obtained based on the function call relation. According to the scheme, the function call is counted and analyzed by taking the coroutine, the thread or the process as a unit, and the key function call link in the source code to be tested can be extracted efficiently and accurately, so that the smooth progress of the code testing process is ensured.

In one embodiment, as shown in FIG. 6, step 502 includes:

in step 601, the source code to be tested is run.

Step 603, before each function call is executed, a parallel identifier corresponding to the function call is obtained, where the parallel identifier includes a coroutine identifier, a thread identifier or a process identifier.

Step 605, it is determined whether a function call has been recorded.

In step 607, when no function call is recorded, recording the number of times of call corresponding to the function call as an initial value, and marking the function call as a pending key function call.

In step 609, when the function call is recorded and the function call is a sub-function of the associated function call, the number of calls corresponding to the function call is adjusted, and when the number of calls is greater than a preset threshold, the function call is marked as a pending key function call.

In step 611, when the function call is executed, the function call marked as the pending key function call is determined as the key function call.

The parallel identifier comprises a coroutine identifier, a thread identifier or a process identifier, is specifically used for setting an association relationship, and can be specifically a serial number mark.

Specifically, the technical scheme of the application determines the key function call relation by analyzing the source code to be tested, firstly, before each function call is executed in the running process of the source code to be tested, the current parallel identifier (cooperative identifier, thread identifier or process identifier) needs to be acquired, and then whether the function call is recorded or not is judged in the counted cache. If the current function call is not recorded, the parallel identification and the call times of the function call are recorded, the parallel identification and the call times are set to initial values, for example, 1, and then the function is marked to be executed as the pending key function call. If the current function call is recorded, judging whether the current function call is a sub-function of the associated function call, and if the current function call is not the sub-function of the associated function call, skipping and not processing. If the current function call is a sub-function of the associated function call, judging whether the accumulated number of times of the function call exceeds an upper limit, if the accumulated number of times of the function call does not exceed the upper limit, adjusting the accumulated number of times of the parallel identification corresponding to the function call, adding 1 to the accumulated number of times of the parallel identification corresponding to the current function call and the function call, and when the accumulated number of times of the function call is greater than a preset upper limit threshold, marking the current function call as a pending key function call. After the function call is executed, the function call marked as the pending key function call can be determined as the key function call. The process of the current function call being not a subfunction of the associated function call specifically comprises: judging whether the calling party of the current function call is the called party of the associated function call, and if the calling party of the current function call is the called party of the associated function call, determining the calling party as the sub-call. Examples: if the recorded associated function call is A to B, if the current function call is B to C, the function call is a subfunction, and if the current function call is D to E, the function call is not a subfunction. The preset upper threshold is set by the user according to the actual needs. For the event loop message processing mechanism, a loop processing function is firstly associated through parallel identification, and the function can exit the function call until a service exit party, therefore, an accumulation mechanism of sub-function calls needs to be introduced to judge whether the function of the loop processing message is processed or not, so that the loop processing function can be skipped, and the wanted message processing function call can be collected. Judging the call as a key function according to the call times, for example, the event processing dead loop function is not required to be called as the key function, and the message processing function (namely, the sub-function) under the event processing dead loop function can be called as the key function. Therefore, which function calls are key function calls can be effectively identified in the source code to be tested. In one embodiment, the server 102 further continuously includes an exception injection range for the key function call acquired in real time, so that the exception injection coverage range is further enlarged.

In one embodiment, as shown in fig. 7, the test results include a service log and a function call log, and step 207 includes:

step 702, in the running process of the instrumented executable file, performing scene injection in a plurality of deployed container test environments respectively.

Step 704, obtaining a service log and a function call log corresponding to the instrumented executable file.

And step 706, obtaining the availability of the business service corresponding to the instrumentation executable file according to the service log and the function call log.

Step 708, obtaining a test result corresponding to the source code to be tested according to the availability of the business service.

Specifically, when the abnormal injection test is performed, the random abnormal injection test scenes can be respectively injected in each container test environment in the running process of the pile inserting executable file in the container, each container corresponds to one abnormal injection test scene, and after the injection is completed, the abnormal injection test of the pile inserting executable file can be realized. And then, obtaining a service log and a function call log corresponding to the instrumentation executable file to obtain a test result corresponding to the abnormal injection test, wherein the service log is used for recording the working condition of the business service corresponding to the instrumentation executable file. And the function call log is used for recording the call process of the instrumentation executable file in the running process. The service log and the function call log can be used for acquiring the availability of the business service corresponding to the instrumentation executable file, so that the test result of whether the service in the container can guarantee the service availability under the condition of abnormal injection is checked. In this embodiment, the service log and the function call log are used to obtain the test result corresponding to the source code to be tested, so that the validity of the test result can be effectively ensured.

In one embodiment, the test results include a service log and a function call log, as shown in fig. 8, and after step 207, further includes:

step 801, according to the service log and the function call log, obtaining an abnormal injection scene corresponding to the source code to be tested.

Step 803, updating the preset abnormal injection model according to the abnormal injection scene.

Specifically, after the random abnormal injection test process, the scheme of the application can further expand more abnormal injection test scenes. Therefore, after the test result corresponding to the source code to be tested is obtained, log information such as a service log and a function call log can be obtained, and then an abnormal injection test scene is better constructed based on the log information so as to be convenient for finding new abnormal problems, and after the abnormal problems are obtained, a preset abnormal injection model can be updated, so that the abnormal injection test scene corresponding to the abnormal problems can be constructed in the subsequent process. In this embodiment, the preset abnormal injection model is updated through the service log and the function call log, so that a richer abnormal injection test scene can be effectively constructed, and the effectiveness of the abnormal injection test is ensured.

The application scenario also provides an application scenario, and the application scenario applies the code testing method. Specifically, the code testing method is applied to the application scene as follows:

when a user needs to perform an abnormal injection test on a high-performance blockchain service application, the abnormal injection test can be performed on the codes of the blockchain service application through the code test method, so that the reliability of the blockchain service application under various random abnormal conditions is determined, and meanwhile, the test efficiency of the code test is ensured. Specifically, the complete flow of code testing may be illustrated with reference to fig. 9, where the server 102 needs to obtain the source code of the blockchain service application, then weave the source code into the instrumentation by way of AOP (tangent plane oriented programming) or HOOK (HOOK) to obtain the corresponding instrumentation executable file, and then deploy the instrumentation executable file into each container testing environment within the multi-container testing environment, and simultaneously run the instrumentation executable files within the container testing environments. Meanwhile, the source code can be analyzed to obtain a corresponding key function call link, and then a random function exception injection tool in the server 102 can construct a plurality of different exception injection test scenes based on the key function call link and a preset exception injection model, and scene data corresponding to the exception injection test scenes can be respectively injected into each container test environment configured with the instrumentation executable file to perform exception injection test. The test can be carried out by continuously applying pressure through a pressure test tool, and service logs and function call logs in the running process of the pile-inserting executable file in each container test environment can be obtained in the pressure test. The log information can be analyzed and detected, and whether the service in the container can guarantee the service availability under the condition of abnormal injection is checked. Meanwhile, the log information can be fed back to a function random anomaly injection tool, so that a random anomaly injection scene can be constructed better, and anomaly problems can be found.

It should be understood that, although the steps in the flowcharts related to the above embodiments are sequentially shown as indicated by arrows, these steps are not necessarily sequentially performed in the order indicated by the arrows. The steps are not strictly limited to the order of execution unless explicitly recited herein, and the steps may be executed in other orders. Moreover, at least some of the steps in the flowcharts described in the above embodiments may include a plurality of steps or a plurality of stages, which are not necessarily performed at the same time, but may be performed at different times, and the order of the steps or stages is not necessarily performed sequentially, but may be performed alternately or alternately with at least some of the other steps or stages.

Based on the same inventive concept, the embodiment of the application also provides a code testing device for realizing the code testing method. The implementation of the solution provided by the device is similar to the implementation described in the above method, so the specific limitation in one or more code testing device embodiments provided below may refer to the limitation of the code testing method hereinabove, and will not be repeated here.

In one embodiment, as shown in fig. 10, there is provided a code testing apparatus comprising:

the data acquisition module 1001 is configured to acquire a source code to be tested, perform instrumentation processing on the source code to be tested, and acquire an instrumentation executable file corresponding to the source code to be tested.

The file deployment module 1003 is configured to deploy the instrumented executable file in each container test environment in the preset multi-container test environment.

The scene acquisition module 1005 is configured to acquire random anomaly injection test scene data corresponding to the source code to be tested.

The injection test module 1007 is configured to perform scenario injection in a plurality of deployed container test environments based on random abnormal injection test scenario data, to obtain a test result corresponding to a source code to be tested.

According to the code testing device, the source code to be tested is obtained, the instrumentation processing is carried out on the source code to be tested, and the instrumentation executable file corresponding to the source code to be tested is obtained; deploying the instrumentation executable file in each container testing environment in a preset multi-container testing environment; acquiring random abnormal injection test scene data corresponding to a source code to be tested; and based on the random abnormal injection test scene data, respectively performing scene injection in a plurality of deployed container test environments to obtain a test result corresponding to the source code to be tested. In the method, the instrumentation pile is woven into the instrumentation pile to construct the instrumentation pile executable file, the instrumentation pile executable file is deployed in each container test environment, a plurality of abnormal injection test scenes corresponding to the source code to be tested are obtained at the same time, and then the abnormal injection test scenes are respectively injected into each container test environment, so that parallel test verification is carried out on the source code to be tested, and high-efficiency test can be effectively carried out on the reliability of the source code to be tested in the face of abnormal conditions.

In one embodiment, the data acquisition module 1001 is specifically configured to: and weaving the source code to be tested into the instrumentation processing by a tangent plane programming mode or a hook mode to obtain an instrumentation executable file corresponding to the source code to be tested.

In one embodiment, the scene acquisition module 1005 is specifically configured to: acquiring a key function call link corresponding to a source code to be tested; based on the key function call link and a preset abnormal injection model, generating scene data of a plurality of random abnormal injection test scenes.

In one embodiment, the scene acquisition module 1005 is further configured to: operating the source code to be tested, and acquiring a key function call relation in the source code to be tested by taking a coroutine, a thread or a process as a unit; and acquiring a key function call link corresponding to the source code to be tested according to the key function call relation.

In one embodiment, the scene acquisition module 1005 is further configured to: running a source code to be tested; before each function call is executed, a parallel identifier corresponding to the function call is obtained, wherein the parallel identifier comprises a coroutine identifier, a thread identifier or a process identifier; judging whether a function call is recorded or not; when the function call is not recorded, recording the call times corresponding to the function call as an initial value, and marking the function call as a pending key function call; when the function call is recorded and the function call is a sub-function of the related function call, adjusting the call times corresponding to the parallel identification and the function call, and when the call times are greater than a preset threshold value, marking the function call as a pending key function call; when the function call is executed, the function call marked as the undetermined key function call is determined as the key function call.

In one embodiment, the test result includes a service log and a function call log, and the apparatus further includes a model update module configured to: acquiring an abnormal injection scene corresponding to the source code to be tested according to the service log and the function call log; and updating the preset abnormal injection model according to the abnormal injection scene corresponding to the source code to be tested.

The code testing device and each module in the code testing device may be implemented in whole or in part by software, hardware, and combinations thereof. The above modules may be embedded in hardware or may be independent of a processor in the computer device, or may be stored in software in a memory in the computer device, so that the processor may call and execute operations corresponding to the above modules.

In one embodiment, a computer device is provided, which may be a server, and the internal structure of which may be as shown in fig. 11. The computer device includes a processor, a memory, and a network interface connected by a system bus. Wherein the processor of the computer device is configured 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, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database of the computer device is for storing the trajectory image data. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program, when executed by a processor, implements a code test method or a code test verification method.

It will be appreciated by those skilled in the art that the structure shown in fig. 11 is merely a block diagram of a portion of the structure associated with the present application and is not limiting of the computer device to which the present application applies, and that a particular computer device may include more or fewer components than shown, or may combine some of the components, or have a different arrangement of components.

In an embodiment, there is also provided a computer device comprising a memory and a processor, the memory having stored therein a computer program, the processor implementing the steps of the method embodiments described above when the computer program is executed.

In one embodiment, a computer-readable storage medium is provided, storing a computer program which, when executed by a processor, implements the steps of the method embodiments described above.

In one embodiment, a computer program product or computer program is provided that includes computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the steps in the above-described method embodiments.

It should be noted that, user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, presented data, etc.) referred to in the present application are information and data authorized by the user or sufficiently authorized by each party.

Those skilled in the art will appreciate that implementing all or part of the above-described methods in accordance with the embodiments may be accomplished by way of a computer program stored on a non-transitory computer readable storage medium, which when executed may comprise the steps of the embodiments of the methods described above. Any reference to memory, database, or other medium used in the various embodiments provided herein may include at least one of non-volatile and volatile memory. The nonvolatile Memory may include Read-Only Memory (ROM), magnetic tape, floppy disk, flash Memory, optical Memory, high density embedded nonvolatile Memory, resistive random access Memory (ReRAM), magnetic random access Memory (Magnetoresistive Random Access Memory, MRAM), ferroelectric Memory (Ferroelectric Random Access Memory, FRAM), phase change Memory (Phase Change Memory, PCM), graphene Memory, and the like. Volatile memory can include random access memory (Random Access Memory, RAM) or external cache memory, and the like. By way of illustration, and not limitation, RAM can be in the form of a variety of forms, such as static random access memory (Static Random Access Memory, SRAM) or dynamic random access memory (Dynamic Random Access Memory, DRAM), and the like. The databases referred to in the various embodiments provided herein may include at least one of relational databases and non-relational databases. The non-relational database may include, but is not limited to, a blockchain-based distributed database, and the like. The processors referred to in the embodiments provided herein may be general purpose processors, central processing units, graphics processors, digital signal processors, programmable logic units, quantum computing-based data processing logic units, etc., without being limited thereto.

The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.

The foregoing examples represent only a few embodiments of the present application, which are described in more detail and are not thereby to be construed as limiting the scope of the present application. It should be noted that it would be apparent to those skilled in the art that various modifications and improvements could be made without departing from the spirit of the present application, which would be within the scope of the present application. Accordingly, the scope of protection of the present application shall be subject to the appended claims.

Claims

1. A method of code testing, the method comprising:

2. The method of claim 1, wherein the performing instrumentation processing on the source code to be tested to obtain an instrumented executable file corresponding to the source code to be tested includes:

and weaving the source code to be tested into the instrumentation processing by a tangent plane programming mode or a hook mode, and obtaining the instrumentation executable file corresponding to the source code to be tested.

3. The method of claim 1, wherein the obtaining random anomaly injection test scenario data corresponding to the source code to be tested comprises:

acquiring a key function call link corresponding to the source code to be tested;

and generating a plurality of random abnormal injection test scene data based on the key function call link and a preset abnormal injection model.

4. The method of claim 3, wherein the obtaining the key function call link corresponding to the source code to be tested comprises:

operating the source code to be tested, and acquiring a key function call relation in the source code to be tested by taking a coroutine, a thread or a process as a unit;

And acquiring a key function call link corresponding to the source code to be tested according to the key function call relation.

5. The method of claim 4, wherein the running the source code to be tested, and the obtaining the key function call relationship in the source code to be tested in a coroutine, thread or process unit comprises:

running the source code to be tested;

before each function call is executed, a parallel identifier corresponding to the function call is obtained, wherein the parallel identifier comprises a cooperative identifier, a thread identifier or a process identifier;

when the function call is not recorded, recording the call times corresponding to the function call as an initial value, and marking the function call as a pending key function call;

when the function call is recorded and is a sub-function of the related function call, adjusting the call times corresponding to the function call by the parallel identification, and when the call times are larger than a preset threshold value, marking the function call as a pending key function call;

when the function call is executed, the function call marked as the undetermined key function call is determined as the key function call.

6. The method according to claim 3, wherein the performing scene injection in the deployed multiple container test environments based on the random anomaly injection test scene data, after obtaining the test results corresponding to the source code to be tested, further includes:

Acquiring the abnormal injection scene according to the service log and the function call log;

and updating the preset abnormal injection model according to the abnormal injection scene.

7. A code testing apparatus, the apparatus comprising:

8. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor implements the steps of the method of any of claims 1 to 6 when the computer program is executed.

9. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the steps of the method of any of claims 1 to 6.

10. A computer program product comprising a computer program, characterized in that the computer program, when being executed by a processor, implements the steps of the method of any of claims 1 to 6.