CN113553250A - Code testing method and device - Google Patents
Code testing method and device Download PDFInfo
- Publication number
- CN113553250A CN113553250A CN202010328137.5A CN202010328137A CN113553250A CN 113553250 A CN113553250 A CN 113553250A CN 202010328137 A CN202010328137 A CN 202010328137A CN 113553250 A CN113553250 A CN 113553250A
- Authority
- CN
- China
- Prior art keywords
- code
- function
- execution result
- proxy
- proxy function
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Prevention of errors by analysis, debugging or testing of software
- G06F11/3668—Testing of software
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention provides a code testing method, a code testing device, electronic equipment and a computer readable storage medium; the method comprises the following steps: analyzing a code, and determining a node needing section configuration in a syntax tree of the code; generating a proxy function, wherein the proxy function comprises tangent plane configuration logic of the code; replacing the original function at the node needing section configuration with the proxy function; executing the tangent plane configuration logic included by the proxy function to simulate and run the code, and receiving a simulation execution result output by the proxy function; and matching the simulation execution result with an expected execution result to generate a test result of the code. By the invention, the code can be tested efficiently and accurately.
Description
Technical Field
The present invention relates to the field of computer software testing technologies, and in particular, to a code testing method and apparatus, an electronic device, and a computer-readable storage medium.
Background
With the rapid development of internet technology, various clients play a very important role in social production, and for such applications, a corresponding server and a code in a network are required to provide corresponding services, such as a database service or an email service. In order to ensure the normal operation of the client, the server generally provides services to the client according to codes stored in the server, and in order to ensure that the server can provide accurate services to the client, the codes in the server need to be tested to find and repair bugs in the codes.
Currently, the related art generally implements testing of code by generating a proxy function containing test logic before compiling the code and then manually replacing the original function call. However, the codes stored in the server need to be updated continuously along with the expansion of the service, a new code is obtained every time the code is updated, a manual intervention mode needs to be adopted again to test the code, and the cost of the test process is huge.
Disclosure of Invention
The embodiment of the invention provides a code testing method and device, electronic equipment and a computer readable storage medium, which can efficiently and accurately test codes.
The technical scheme of the embodiment of the invention is realized as follows:
the embodiment of the invention provides a code testing method, which comprises the following steps:
analyzing a code, and determining a node needing section configuration in a syntax tree of the code;
generating a proxy function, wherein the proxy function comprises tangent plane configuration logic of the code;
replacing the original function at the node needing section configuration with the proxy function;
executing the tangent plane configuration logic included by the proxy function to simulate and run the code, and receiving a simulation execution result output by the proxy function;
and matching the simulation execution result with an expected execution result to generate a test result of the code.
An embodiment of the present invention provides a device for testing a code, including:
the analysis module is used for analyzing the codes and determining nodes needing section configuration in a syntax tree of the codes;
a generating module, configured to generate a proxy function, where the proxy function includes a tangent plane configuration logic of the code;
a replacing module, configured to replace the primitive function located at the node where the section configuration needs to be performed with the proxy function;
the execution module is used for executing the section configuration logic included by the proxy function so as to simulate and run the code and receiving a simulation execution result output by the proxy function;
and the matching module is used for matching the simulation execution result with an expected execution result to generate a test result of the code.
In the above scheme, the parsing module is further configured to parse the tangent plane configuration in the code to determine an extension function in the code, and obtain a return value of the extension function; and traversing the syntax tree of the code according to the regular expression in the return value of the extension function so as to determine the nodes needing to be subjected to tangent plane configuration in the syntax tree of the code.
In the above scheme, the generating module is further configured to determine a name and a parameter of a primitive function located at the node where the section configuration needs to be performed; constructing a function body consistent with the name and the parameters of the primitive function; adding section configuration logic for simulating the running of the code in the function body to obtain the proxy function.
In the above scheme, the replacing module is further configured to determine a variable type of a primitive function located at the node where the section configuration needs to be performed; determining the storage address of the primitive function according to the variable type of the primitive function; determining the storage address of the proxy function by calling a proxy tool; and replacing the original function stored in the storage address of the original function with the proxy function stored in the storage address of the proxy function.
In the above solution, the execution module is further configured to create a main thread for executing the code, and create main context information corresponding to the main thread; creating a child thread for executing the section configuration logic included in the proxy function; determining subcontext information according to the main context information of the main thread, and binding the subcontext information with the subcontext; and obtaining a simulation execution result generated when the section configuration logic is executed according to the subcontext information bound by the subcontext.
In the above scheme, the execution module is further configured to extract a sequence number of the sub-thread from the sub-context information bound to the sub-thread; and calling a simulation execution result accessor to read a simulation execution result corresponding to the sequence number of the sub thread in the simulation execution result accessor.
In the above scheme, the matching module is further configured to match the simulation execution result with the expected execution result; when the simulation execution result is matched with the expected execution result, generating a test result representing that the code has no loophole; and when the simulation execution result is not matched with the expected execution result, generating a test result for representing that the code has a leak.
In the above solution, the apparatus for testing a code further includes: the injection module is used for injecting section configuration logic for simulating and running the code into the primitive function positioned at the node needing section configuration; executing the primitive function comprises tangent plane configuration logic to simulate running the code, and receiving a simulation execution result output by the primitive function when the tangent plane configuration logic is executed.
In the above solution, the apparatus for testing a code further includes: and the uplink module is used for storing the test result of the code into the blockchain network so that the blockchain network responds to the test data request aiming at the code according to the stored test result of the code.
An embodiment of the present invention provides an electronic device, including:
a memory for storing executable instructions;
and the processor is used for realizing the testing method of the codes provided by the embodiment of the invention when executing the executable instructions stored in the memory.
The embodiment of the invention provides a computer-readable storage medium, which stores executable instructions and is used for causing a processor to execute the executable instructions so as to realize the test method of the codes provided by the embodiment of the invention.
The embodiment of the invention has the following beneficial effects:
the method comprises the steps of determining a node needing section configuration in a syntax tree of the code by analyzing the code, and automatically replacing a primitive function located at the node with a proxy function comprising section configuration logic to simulate an operation code, so that the code is tested, manual intervention is not needed, bugs existing in the code are quickly and accurately detected, and the cost in the testing process is reduced, so that the testing efficiency is improved.
Drawings
FIG. 1 is a block diagram of a system 100 for testing code according to an embodiment of the present invention;
fig. 2 is a schematic structural diagram of an electronic device 500 according to an embodiment of the present invention;
FIG. 3A is a flowchart illustrating a method for testing code according to an embodiment of the present invention;
FIG. 3B is a diagram illustrating a slice configuration in a code provided by an embodiment of the invention;
FIG. 3C is a diagram of code and syntax trees for the code provided by an embodiment of the present invention;
FIG. 3D is a diagram illustrating invocation of a proxy function of an asynchronous thread statement in accordance with an embodiment of the present invention;
fig. 3E, fig. 3F, and fig. 3G are schematic diagrams illustrating an application of replacing a primitive function with a proxy function according to an embodiment of the present invention;
FIG. 4 is a flowchart illustrating a method for testing code according to an embodiment of the present invention;
FIG. 5 is a flowchart illustrating a method for testing code according to an embodiment of the present invention;
FIG. 6 is a schematic diagram of an application of a method for testing a code according to an embodiment of the present invention;
FIG. 7 is a flowchart illustrating a method for testing code according to an embodiment of the present invention;
fig. 8 is a flowchart illustrating a method for testing a code according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail with reference to the accompanying drawings, the described embodiments should not be construed as limiting the present invention, and all other embodiments obtained by a person of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.
In the following description, reference is made to "some embodiments" which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict.
Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The terminology used herein is for the purpose of describing embodiments of the invention only and is not intended to be limiting of the invention.
Before further detailed description of the embodiments of the present invention, terms and expressions mentioned in the embodiments of the present invention are explained, and the terms and expressions mentioned in the embodiments of the present invention are applied to the following explanations.
1) Code, or program, is a source file written in a language supported by a development tool, which is a set of well-defined rules that represent information in discrete form by characters, symbols, or signal symbols. The principles of code design include uniqueness, standardization and versatility, extensibility and stability, ease of recognition and memory, strive for shortness and format unification, and ease of modification. The source code corresponds to code, which in modern programming languages may be in the form of a book or tape, but the most common format is a text file, which is typically used for compiling a computer program. The ultimate purpose of computer source code is to translate human-readable text into computer-executable binary instructions called compilation, which is done by a compiler.
The codes include business codes and non-business codes. The code directly used for realizing the user requirement is a service code, for example, if the user needs to inquire certain data, the code directly inquires the database and returns a result is the service code. The non-service code refers to an auxiliary service code, which generally can be a code existing without a service, for example, a user inquires certain data, and receives a code input by the user, which may have a Chinese messy code.
2) In the static compiling type language, source codes are compiled into machine codes, linking is to connect the machine codes of all modules and a dependence library in series to generate an executable file, and semantic logic cannot be changed after compiling. The languages that are not variable in runtime structure are static languages, such as C language, C + + language, Go language, and the like.
3) Aspect Oriented Programming (AOP) is a technology for dynamically and uniformly adding functions to a program without modifying source code by means of a pre-compilation mode and a run-time dynamic proxy.
4) The proxy function is an indirect call function (i.e. proxy function) which is obtained by replacing the call of the original function (or called proxy function) after the AOP section, and can realize section configuration logic in the proxy function and call the original function at the same time.
5) Program instrumentation is to insert some probes (or detectors) into a code on the basis of ensuring the original logic integrity of the tested code, to obtain the control flow and data flow information of the code by executing the probes and throwing out the characteristic data of the code operation and analyzing the data, so as to obtain the dynamic information such as logic coverage and the like, thereby realizing the test purpose.
6) Simulation (Mock) testing is a testing method which is created by using a virtual object for some objects which are not easy to construct or obtain in the testing process. The virtual object is a Mock object, which is a substitute of a real object during debugging, and the Mock object can be used for simulating an interface.
7) The section configuration logic refers to logic (or code, function, method, program) for implementing Mock test.
8) Global variables, which are divided into local and global variables, may also be referred to as internal variables. Variables created by an object or a function are usually local variables, which can only be internally referenced, but cannot be referenced by other objects or functions. The global variable can be created by some object function or created anywhere in the program, and the global variable can be referred to by all objects or functions of the program.
9) Syntax trees (Syntax trees) are Tree-like representations of abstract Syntax structures of source code, here specifically the source code of a programming language. Each node on the tree represents a structure in the source code.
10) An application is a computer program that is a single executable file or a single program for performing one or more specific tasks. The application runs in user mode, can interact with the user, and has a visual user interface.
11) In response to the condition or state on which the performed operation depends, one or more of the performed operations may be in real-time or may have a set delay when the dependent condition or state is satisfied; there is no restriction on the order of execution of the operations performed unless otherwise specified.
12) Unit Testing (Unit Testing) refers to checking and verifying the smallest Unit of testability in code. The unit is the minimum tested function module specified by human. Unit testing is the lowest level of testing activity to be performed during software development, and individual units of software will be tested in isolation from other parts of the program.
13) Interface Testing (Interface Testing) is a test for Testing interfaces between components of a system, and is mainly used for Testing interfaces between the system and other external systems and interfaces between submodules in the system. The key points of the test are to check the correctness of the interface parameter transmission, the correctness of the interface function realization, the correctness of the output result, and the integrity and the rationality of the fault-tolerant processing of various abnormal conditions. The classification for software interfaces includes the following cases: calling between systems; for example, a software program is generally divided into a presentation layer, a service layer and a data layer, the presentation layer calls an interface of the service layer to complete own work, and the service layer calls an interface of the data layer to realize corresponding services.
14) Thread (Thread) is the smallest unit that the operating system can perform operation scheduling. It is included in the process and is the actual unit of operation in the process. A thread refers to a single sequential control flow in a process, multiple threads can be concurrently executed in a process, and each thread executes different tasks in parallel. Multiple threads in the same process will share all system resources in the process, e.g., virtual address space, file descriptors, signal processing, etc. But multiple threads in the same process all have respective Call stacks (Call Stack), respective Register contexts (Register Context), and respective Thread-Local stores (Thread-Local store).
15) A Process (Process) is a running activity of a program in a computer on a data set, is a basic unit of resource allocation and scheduling of a system, and is the basis of an operating system structure. A process is the basic entity of execution of a program and is also a container for threads.
16) The context, or called context information, has many external variables for each program, and if a program has external variables, the program is incomplete and cannot be run independently. In order to make the program with the external variables run, values are written into all the external variables of the program, and the set of the values is called context.
17) A Block chain (Blockchain) is a storage structure for encrypted, chained transactions formed from blocks (blocks).
18) A Blockchain Network (Blockchain Network) incorporates new blocks into a set of nodes of a Blockchain in a consensus manner.
19) Ledger (legger) is a general term for blockchains (also called Ledger data) and state databases synchronized with blockchains. Wherein, the blockchain records the transaction in the form of a file in a file system; the state database records the transaction in the blockchain in the form of different types of Key (Key) Value pairs, and is used for supporting quick query of transaction data in the blockchain.
20) Intelligent Contracts (Smart Contracts), also known as chain codes (chaincodes) or application codes, are programs deployed in nodes of a blockchain network, and the nodes execute the intelligent Contracts called in received transactions to perform operations of updating or querying key-value data of a state database.
21) Consensus (Consensus), a process in a blockchain network, is used to agree on a transaction in a block between the nodes involved, the agreed block to be appended to the end of the blockchain and used to update the state database.
The embodiment of the invention provides a code testing method and device, electronic equipment and a computer readable storage medium, which can efficiently and accurately detect vulnerabilities existing in network applications. An exemplary application of the code testing method provided by the embodiment of the present invention is described below, and the code testing method provided by the embodiment of the present invention may be implemented by a server, for example, may be implemented by one server alone, or may be implemented by cooperation of a plurality of servers (i.e., a server cluster).
In the following, the embodiment of the present invention is described by taking a server as an embodiment, and referring to fig. 1, fig. 1 is an architectural diagram of a test system 100 for code provided by the embodiment of the present invention. The test system 100 of the code includes: the server 200, the network 300, and the terminal 400 on which the client 410 operates will be described separately.
The server 200, which is a background server of the client 410, is configured to provide a corresponding service, such as a database service or an email service, to the client 410 by running code stored in the server. Before providing the corresponding service to the client 410, the server 200 needs to test the corresponding code stored therein (the testing process of the code will be described in detail below). When the code test passes (i.e., the code is not flawed), the server 200 provides the service corresponding to the code to the client 410; when the code test fails (i.e., the code has a bug), the server 200 sends the test result of the code to the tester to notify the tester to repair the bug of the code.
The network 300 is used as a medium for communication between the server 200 and the terminal 400, and may be a wide area network or a local area network, or a combination of both.
The terminal 400 is used for operating the client 410, and the client 410 is used for displaying a corresponding human-computer interaction interface to a user according to a corresponding service provided by the server 200.
The embodiment of the invention can be widely applied to the development stage of the codes, for example, before the codes are online (namely, the server 200 provides services for the client 410), whether the codes to be online have bugs is determined by testing the codes to be online, and the codes to be online are perfected according to the detected bugs so as to ensure the normal operation of the client, thereby providing accurate services for users and improving the use experience of the users.
Next, a structure of an electronic device for performing code testing according to an embodiment of the present invention is described, where the electronic device may be the server 200 shown in fig. 1, referring to fig. 2, fig. 2 is a schematic structural diagram of an electronic device 500 according to an embodiment of the present invention, and the electronic device 500 shown in fig. 2 includes: at least one processor 510, memory 530, and at least one network interface 520. The various components in the electronic device 500 are coupled together by a bus system 540. It is understood that the bus system 540 is used to enable communications among the components. The bus system 540 includes a power bus, a control bus, and a status signal bus in addition to a data bus. For clarity of illustration, however, the various buses are labeled as bus system 540 in fig. 2.
The Processor 510 may be an integrated circuit chip having Signal processing capabilities, such as a general purpose Processor, a Digital Signal Processor (DSP), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like, wherein the general purpose Processor may be a microprocessor or any conventional Processor, or the like.
Memory 530 includes volatile memory or nonvolatile memory, and can include both volatile and nonvolatile memory. The non-volatile Memory may be a Read Only Memory (ROM), and the volatile Memory may be a Random Access Memory (RAM). Memory 530 described with respect to embodiments of the present invention is intended to comprise any suitable type of memory. Memory 530 may optionally include one or more storage devices physically located remote from processor 510.
In some embodiments, memory 530 may be capable of storing data to support various operations, examples of which include programs, modules, and data structures, or subsets or supersets thereof, as exemplified below.
An operating system 531, including system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks;
a network communication module 532 for communicating to other computing devices via one or more (wired or wireless) network interfaces 520, exemplary network interfaces 520 including: bluetooth, wireless compatibility authentication (WiFi), and Universal Serial Bus (USB), etc.;
in some embodiments, the testing apparatus for code provided by the embodiments of the present invention may be implemented in software, and fig. 2 shows the testing apparatus 533 for code stored in the storage 530, which may be software in the form of programs and plug-ins, and includes the following software modules: parsing module 5331, generating module 5332, replacing module 5333, executing module 5334 and matching module 5335, which are logical and therefore can be arbitrarily combined or further split depending on the functionality implemented. The functions of the respective modules will be explained below.
In other embodiments, the testing apparatus for code provided by the embodiments of the present invention may be implemented in hardware, and for example, the testing apparatus for code provided by the embodiments of the present invention may be a processor in the form of a hardware decoding processor, which is programmed to execute the testing method for code provided by the embodiments of the present invention, for example, the processor in the form of the hardware decoding processor may be one or more Application Specific Integrated Circuits (ASICs), DSPs, Programmable Logic Devices (PLDs), Complex Programmable Logic Devices (CPLDs), Field Programmable Gate Arrays (FPGAs), or other electronic components.
Next, a detailed process of implementing the specific implementation of step 1 in fig. 1, that is, the server 200 implements the code testing method provided by the embodiment of the present invention to test the code so as to obtain the test result of the code, will be described in detail. Referring to fig. 3A, fig. 3A is a flowchart illustrating a method for testing a code according to an embodiment of the present invention, and will be described with reference to the steps shown in fig. 3A.
In step S101, the code is parsed, and the nodes requiring the tangent plane arrangement in the syntax tree of the code are determined.
Here, the code may be a service code or a non-service code. The service code is a code for realizing the user's requirement, for example, if the user needs to inquire certain data, the database is directly inquired, and the code for returning the result is the service code. When the code to be tested is a service code, whether the service code has a bug is tested, namely whether the service code can meet the requirements of a user is tested. Judging whether the service code can realize the user requirement or not is to judge whether the test result of the code is matched with the expected test result or not, and when the test result of the code is matched with the expected test result or not, representing that the service code can realize the user requirement; and when the test result of the code is not matched with the expected test result, the service code is characterized to have a bug, and the requirement of a user cannot be realized. The node needing section configuration is the node needing simulation (Mock) test in the code.
In some embodiments, the tangent plane configuration in the code is analyzed to determine the extension function in the code, and the return value of the extension function is obtained; and traversing the syntax tree of the code according to the regular expression in the return value of the extension function so as to determine (or match) nodes needing to be subjected to tangent plane configuration in the syntax tree of the code.
Here, before parsing the slice configuration in the code, the method may further include: parsing the syntax tree of the code and other source codes (or called source codes and codes) on which the syntax tree of the code depends; and carrying out recursive analysis on the syntax tree of the code and other source codes depended by the syntax tree of the code so as to improve the speed of determining nodes needing to be subjected to tangent plane configuration in the syntax tree of the code subsequently.
Taking a universal Mock implementation code of Http (i.e., an Http client carried by Go language) as an example, a section configuration in the code is described, referring to fig. 3B, where fig. 3B is a schematic diagram of the section configuration in the code provided by the embodiment of the present invention. In fig. 3B, a Mock function name (i.e., a proxied function name) is specified by writing a Pointcut () extension function 301, and a tangent plane configuration logic is implemented by extending an Advice function (i.e., a proxy function).
In the embodiment of the invention, the nodes needing section configuration can be obtained in the common function in a matching way; the node needing section configuration can be obtained in the asynchronous thread statement in a matching way; and matching and obtaining the nodes needing section configuration in the global variable.
As an example, by calling a function, a node to be subjected to tangent plane configuration is obtained by matching in a normal function.
As another example, a syntax tree of the schema traversal code of the syntax tree node is accessed by a syntax tree access tool (e.g., AstVisitor) to match in an asynchronous threading statement to obtain the node that needs to be subjected to the tangent plane configuration.
For example, the pseudo code for matching and obtaining the node to be configured in the asynchronous thread statement is as follows:
an if statement is a statement that contains an asynchronous keyword;
then, the sentence containing the asynchronous keyword is extracted.
As yet another example, referring to fig. 3C, fig. 3C is a schematic diagram of a code and a syntax tree of the code provided by an embodiment of the present invention. As shown in fig. 3C, the global variable 302 is usually in the cls directory of the root node of the syntax tree of the code, and therefore, the node that needs to be configured in the section can be directly obtained by matching in the cls directory of the root node of the syntax tree of the code.
The embodiment of the invention can not only match and obtain the nodes needing section configuration in the common function; the node needing section configuration can be obtained in the asynchronous thread statement in a matching way; the nodes needing section configuration can be obtained in the global variable in a matching mode, and therefore comprehensiveness and accuracy of code testing can be improved.
In step S102, a proxy function is generated.
Here, the proxy function includes a section configuration logic of the code, and the section configuration logic refers to a logic for implementing Mock test. Each part of the business logic (namely the codes) can be isolated by utilizing the section configuration logic, so that the coupling degree between each part of the business logic is reduced, the reusability of a program is improved, the development efficiency is improved, and the accuracy of code testing can be improved by realizing the Mock test through the section configuration logic.
In some embodiments, determining the name and parameters of the primitive function located at the node where the section configuration is required; constructing a function body consistent with the name and the parameters of the original function; adding section configuration logic for simulating the running code in the function body to obtain the proxy function.
Corresponding to the embodiment in step S101, step S102 may generate not only a proxy function corresponding to a normal function but also a global variable; proxy functions corresponding to asynchronous thread statements may also be generated.
As an example, the process of generating the proxy function corresponding to the normal function is specifically: determining the name and parameters of a common function at a node needing section configuration; constructing a function body consistent with the name and the parameters of the common function; adding section configuration logic for simulating the running code in the function body, and generating a proxy function corresponding to the common function.
As another example, the process of generating the proxy function corresponding to the global variable is specifically: determining the name and parameters of a global variable at a node needing section configuration; constructing a function body consistent with the name and the parameters of the global variable; adding section configuration logic for simulating running code in the function body, and generating a proxy function corresponding to the global variable.
As another example, taking the example that the code is written in Go language, the generation of the proxy function corresponding to the asynchronous thread statement is described, and the process is specifically as follows: by implementing the Context (Context) of the main thread (or parent thread) to be transferred to the child thread in the proxy function, the proxy function corresponding to the asynchronous thread statement is generated, for example, the call of the asynchronous thread statement (i.e. the primitive function) in the code is:
go func(){
access2DB();
}
referring to fig. 3D, fig. 3D is a schematic diagram of a call of a proxy function of an asynchronous thread statement according to an embodiment of the present invention, and in fig. 3D, pseudo code corresponding to the call of the proxy function of the asynchronous thread statement is:
in the process, before the execution of the child thread function, the father context is taken out, when the child thread function is executed, the father context is associated to generate the child context, and the child context is bound with the current child thread. And according to the thread Identification (ID), acquiring a corresponding context in a globally maintained thread context storage Map (Map) 303.
The embodiment of the invention can generate the proxy function corresponding to the common function and the global variable; proxy functions corresponding to asynchronous thread statements can be generated, so that the proxy functions can be replaced by the proxy functions flexibly in the following process no matter what types of functions the primitive functions located at the nodes needing to be subjected to tangent plane configuration are.
In step S103, the primitive function located at the node where the section configuration is required is replaced with a proxy function.
In some embodiments, determining a variable type of a primitive function located at a node where a tangent plane configuration is required; determining a storage address of the original function according to the variable type of the original function; determining a storage address of an agent function by calling an agent tool; and replacing the original function stored in the storage address of the original function with the proxy function stored in the storage address of the proxy function.
Corresponding to the embodiments in step S101 and step S102, step S103 may replace not only the normal function with the corresponding proxy function; global variables can also be replaced by corresponding proxy functions; the asynchronous thread statements may also be replaced with corresponding proxy functions.
As an example, replacing a normal function with a corresponding proxy function process is: and acquiring the call parameters of the common function by calling the proxy tool, and calling the corresponding proxy function according to the call parameters of the common function.
As another example, the process of replacing an asynchronous thread statement with a corresponding proxy function is: and acquiring the calling parameters of the asynchronous thread statements by calling the proxy tool, and calling corresponding proxy functions according to the calling parameters of the asynchronous thread statements.
As another example, taking the example that the code is written in Go language, the explanation is to replace the global variable call with a corresponding proxy function, and the pseudo code before replacement is:
var someVar anyType; global variable of any type
func main(){
dosemeting (somevar); the value of someVar may be changed
doSomething(someVar)
}
The pseudo code after replacement is:
var someVar anyType; global variable of any type
func main () {; first obtaining the address of global variable someVar, then calling Proxy (Proxy) to obtain new address of Proxy function, then using symbol (for example) to address to obtain Proxy function
doSomething (& someVar)); the value of someVar may be changed
dosemeting (proxy (somevar)); implementing substitution
}
For example, referring to fig. 3E, fig. 3F, and fig. 3G, fig. 3E, fig. 3F, and fig. 3G are schematic diagrams of applications in which primitive functions are replaced by proxy functions according to an embodiment of the present invention. In fig. 3E, a node 304 at "http. client" is the above-mentioned node that needs to be subjected to the tangent plane configuration, that is, a node that needs to be subjected to a simulation (Mock) test in the code, and a function in the node 304 is a primitive function, that is, a proxied function.
Fig. 3F is a schematic diagram of the primitive function before the replacement of the node 304, and fig. 3G is a schematic diagram after the primitive function at the node 304 is replaced with the proxy function.
As can be seen from fig. 3F and 3G, the return code 305 "client.do (req)" of the primitive function in fig. 3F has been replaced with the return code 306 "(_ aspect _ proxy _0_ Do _ of (client)) (req)" in fig. 3G, so that the return value "func (_ http.request)" of the function "_ aspect _0_ Do _ of" is the proxy function 307, and the internal call of the proxy function 307 is "_ proxy _0_ Do _ of", "proxy _0_ Do _ of" calls the internal call of the slice configuration logic 308 "(" & ttpclientdocact _ as {). advance "", "_ proxy _0_ Do _ of" ") and" call the internal call of the primitive function (call 35g _ origin) (i.e. 35g.) (call). Therefore, the calling of the original function http, client and Do in the code is replaced by the calling of the proxy function, and the return of the simulation execution result (or referred to as Mock data) is realized in the proxy function, so that the simulation (Mock) of the original function http, client and Do is realized, and the test of the code can be completed according to the returned Mock data subsequently.
The embodiment of the invention can isolate each part of the service logic (namely the code) by using the section configuration logic by replacing the primitive function at the node needing section configuration with the proxy function comprising the section configuration logic, thereby reducing the coupling degree between each part of the service logic, improving the reusability of the program, simultaneously improving the development efficiency, and improving the accuracy of the code test by realizing the Mock test through the section configuration logic.
In step S104, executing the profile configuration logic included in the proxy function to simulate the run code, and receiving the simulated execution result (or Mock data) output by the proxy function.
In some embodiments, a calling parameter of the primitive function is obtained, and the proxy function is called according to the calling parameter of the primitive function; executing a simulation object set in the section configuration logic included in the proxy function to simulate an operation code, and receiving a simulation execution result output by the proxy function; the simulation object is used for simulating a node which needs to be subjected to tangent plane configuration or simulating a dependent function (or called environment) of the node which needs to be subjected to tangent plane configuration.
In some embodiments, referring to fig. 4, fig. 4 is a flowchart illustrating a method for testing a code according to an embodiment of the present invention, and based on fig. 3A, step S104 may include steps S1041 to S1044.
In step S1041, a main thread for executing code is created, and main Context information (Context) corresponding to the main thread is created.
In some embodiments, each thread creates or binds a Context before executing, the Context contains the sequence number S of the current thread, and the sequence number S of the thread before acquiring the Mock data is incremented by 1 each time. The sequence number S of the outermost thread (i.e., the main thread) is an initial value of 0. Where Context and the thread itself are bound.
In step S1042, a child thread for executing the section configuration logic included in the proxy function is created.
In some embodiments, the running process in the child thread for executing the section configuration logic included in the proxy function is specifically: acquiring a calling parameter of an original function, and calling a proxy function according to the calling parameter of the original function; and executing the simulation object arranged in the section configuration logic included in the proxy function to simulate the running code.
As an example, each child thread creates or binds a piece of Sub-Context information (Sub-Context) for it, and the initial value of the sequence number S of the child thread is multiplied by 10000 from the current sequence number of the Context of the main thread as the initial value.
In step S1043, the child Context information is determined according to the main Context information (or called main Context, parent Context) of the main thread, and the child Context information is bound to the child thread.
In some embodiments, the additional attribute information of the Sub-Context of the child thread is copied from the Context of the main thread, so that cross-thread Context transfer can be realized. Similarly, the thread number S is incremented by 1 each time a child thread acquires Mock data.
In step S1044, a simulation execution result generated when the section configuration logic is executed is obtained according to the subcontext information bound to the child thread.
In some embodiments, the process of obtaining the simulation execution result generated when the section configuration logic is executed according to the subcontext information bound by the child thread is specifically: extracting the serial number of the sub thread from the sub context information bound by the sub thread; and calling a simulation execution result accessor (or Mock data accessor) to read a simulation execution result corresponding to the sequence number of the sub-thread in the simulation execution result accessor.
For example, each thread or sub-thread has a number segment that does not conflict with each other, and the number segment is incremented. And acquiring the Mock data from the Mock data accessor by taking the sequence number S as a parameter.
Here, although the created child threads are not executed in the order, since the sequence number segments are already assigned in the order of creation when the child threads are created, that is, before the child threads start execution, the sequence number segments of the child threads are arranged in the order of creation of the child threads strictly. And the sequence created by the sub-threads is fixed in the main thread semantically, so that the accuracy of the obtained simulation execution result is ensured.
In the embodiment of the invention, whether the code uses asynchronous multithreading or not, an accurate simulation execution result can be obtained according to the serial number of the thread. The method not only can solve the problem of the timing sequence of the Mock data acquisition of the multithreading asynchronous logic in the related technology, but also can ensure the accuracy of the timing sequence of the thread without modifying the code by a mode of acquiring the simulation execution result through the serial number of the thread.
In step S105, the simulation execution result is matched with the expected execution result, and a test result of the code is generated.
In some embodiments, the simulated execution results are matched to expected execution results; when the simulation execution result is matched with the expected execution result, generating a test result which represents that the code passes the test (namely the code has no loophole); when the simulation execution result is not matched with the expected execution result, a test result which represents that the code test fails (namely the code has a bug) is generated.
The embodiment of the invention realizes the test of the code by matching the simulation execution result with the expected execution result, and can realize the technical effect of quickly and accurately detecting the bugs in the code without manual intervention.
Referring to fig. 5, fig. 5 is a flowchart illustrating a method for testing a code according to an embodiment of the present invention, and based on fig. 3A, after step S101 and before step S105, steps S106 to S107 may be included, where steps S106 to S107 may replace steps S102 to S104, and steps S106 to S107 may also be executed in parallel with steps S102 to S104. Next, the explanation will be made by replacing step S102 to step S104 with step S106 to step S107.
In step S106, a section configuration logic for simulating the run code is injected into the primitive function located at the node where the section configuration is required.
In some embodiments, determining a variable type of a primitive function located at a node where a tangent plane configuration is required; and injecting section configuration logic for simulating the running code into the function body of the primitive function according to the variable type of the primitive function.
In the embodiment of the invention, no matter the primitive function at the node needing to be subjected to the tangent plane configuration is a common function, or a global variable and an asynchronous thread statement, the tangent plane configuration logic for simulating the running code can be injected into the primitive function. Here, when the code uses multithreading, the cross-plane configuration logic and the logic to pass context for simulating the running code may be injected in the underlying thread library.
In step S107, the tangent plane configuration logic included in the primitive function is executed to simulate the run code, and the simulated execution result output by the primitive function is received.
In some embodiments, a calling parameter of the primitive function is obtained, and the primitive function is called according to the calling parameter of the primitive function; executing a simulation object arranged in the section configuration logic included in the primitive function to simulate an operation code, and receiving a simulation execution result output by the primitive function when the section configuration logic is executed; the simulation object is used for simulating a node which needs to be subjected to tangent plane configuration or simulating a dependent function (or called environment) of the node which needs to be subjected to tangent plane configuration.
As an example, a main thread for executing code is created, and main context information corresponding to the main thread is created; creating a child thread for executing the section configuration logic included in the primitive function; determining subcontext information according to the main context information of the main thread, and binding the subcontext information with the subcontext; and obtaining a simulation execution result generated when the section configuration logic is executed according to the subcontext information bound by the subcontext. In this example, the simulation execution result is also obtained through the serial number of the thread, and the specific implementation process of this example is similar to steps S1041 to S1044, which will not be described herein again.
According to the embodiment of the invention, the section configuration logic for simulating the running code is injected into the code on the basis of ensuring the original logic integrity of the tested code, so that the manual intervention is not needed, the loopholes in the code can be quickly and accurately detected, and the testing efficiency is improved.
In some embodiments, after step S105, the method may further include: the test results of the code are stored in the blockchain network so that the blockchain network responds to the test data request for the code according to the stored test results of the code.
Next, an exemplary application of the code testing method provided by the embodiment of the present invention is described by taking an example that the server 200 in fig. 1 uploads the test result to the blockchain network for storage. Referring to fig. 6, fig. 6 is an application schematic diagram of a code testing method provided in an embodiment of the present invention, and includes a block chain network 600 (exemplarily illustrating a consensus node 610-1 to a consensus node 610-3), an authentication center 700, and a service principal 800/900, which are described below separately.
The type of blockchain network 600 is flexible and may be, for example, any of a public chain, a private chain, or a federation chain. Taking the public chain as an example, any electronic device (e.g., server 200) of a business entity can access the blockchain network 600 as a client node without authorization; taking a federation chain as an example, after being authorized, a business entity can access the electronic device under its jurisdiction to the blockchain network 600 to become a client node.
As an example, when the blockchain network 600 is a federation chain, the service entity 800/900 registers with the certificate authority 700 to obtain a digital certificate of each service entity, where the digital certificate includes the public key of the service entity and a digital signature signed by the certificate authority 700 on the public key of the service entity 800/900 and identity information, is used to be appended to a transaction (e.g., for uplink storage of test results or query of test results) together with the digital signature of the service entity for the transaction, and is sent to the blockchain network 600, so that the blockchain network 600 can take the digital certificate and the digital signature from the transaction, verify the authenticity of the transaction (i.e., whether it has not been tampered with) and the identity information of the service entity sending the message, and the blockchain network 600 can verify according to the identity, for example, whether it has the right to initiate the transaction.
In some embodiments, the client node may act as a mere watcher of the blockchain network 600, i.e., provide support for the business entity to initiate transaction functions, and may be implemented by default or selectively (e.g., depending on the specific business requirements of the business entity) for the functions of the consensus node 610 of the blockchain network 600, such as a ranking function, a consensus service, and an ledger function, etc. Therefore, the data and the service processing logic of the service subject can be migrated to the blockchain network 600 to the maximum extent, and the credibility and traceability of the data and service processing process are realized through the blockchain network 600.
Consensus nodes in blockchain network 600 receive transactions submitted by client nodes from different business entities (e.g., business entity 800/900 shown in fig. 6), perform transactions to update the ledger or query the ledger, and various intermediate or final results of performing transactions may be returned for display in the business entity's client nodes.
An exemplary application of the blockchain network is described below, taking as an example that the server 200 uploads the test results to the blockchain network for storage, and referring to fig. 6, the client node 810 may be the server 200.
First, the logic for chaining test results is set at the client node 810, e.g., when the test results are obtained, the client node 810 sends the test results to the blockchain network 600, and generates a corresponding transaction, which includes: the intelligent contract which needs to be called for the uplink test result and the parameters transferred to the intelligent contract; the transaction also includes the client node's 810 digital certificate, signed digital signature, and broadcasts the transaction to the consensus node 610 in the blockchain network 600.
Here, client node 810 may send test results to blockchain network 600 periodically or in real-time. For example, it may be sent to the blockchain network 600 whenever a test result is obtained; or, every certain time period (for example, 2 hours or 3 days), all the test results obtained in the time period are sent to the blockchain network 600, so as to ensure the reliability of obtaining the test results by the blockchain network 600.
Then, when the transaction is received in the consensus node 610 in the blockchain network 600, the digital certificate and the digital signature carried in the transaction are verified, and after the verification is successful, whether the service entity 800 has the transaction right is determined according to the identity of the service entity 800 carried in the transaction, and any verification judgment of the digital signature and the right verification will result in a transaction failure. After verification is successful, the consensus node 610 signs its own digital signature (e.g., by encrypting the digest of the transaction using the private key of node 610-1) and continues to broadcast in the blockchain network 600.
Finally, after the consensus node 610 in the blockchain network 600 receives the transaction that is successfully verified, the transaction is filled into a new block and broadcast. When a new block is broadcasted by the consensus node 610 in the block chain network 600, the new block is verified, for example, whether the digital signature of the transaction in the new block is valid is verified, if the verification is successful, the new block is appended to the tail of the block chain stored in the new block, and the state database is updated according to the transaction result to execute the transaction in the new block: for committed transactions that store test results, key-value pairs that include test results are added to the state database.
An exemplary application of the blockchain network is illustrated by taking the server 210 as an example to query the test result in the blockchain network 600. Referring to fig. 6, a client node 910 may be a server 210.
Here, the server 210 is a server that needs to be code tested, and the codes to be detected that the server 200 and the server 210 need to be code tested are the same. In this way, the test results required by the server 200 and the server 210 are the same, and therefore, the server 210 can directly obtain the test results through the block chain network 600, so that the server 210 can be prevented from testing the codes to be detected again to obtain the test results, and further, the resource consumption of the server is saved.
In some embodiments, the type of data that the client node 910 can query in the blockchain network 600 may be implemented by the consensus node 610 by restricting the authority of transactions that the client phase of the business entity can initiate, when the client node 910 has the authority to initiate a query test result, a transaction for querying the test result may be generated by the client node 910 and submitted into the blockchain network 600, the transaction is performed from the consensus node 610 to query the corresponding test result from the state database, and returned to the client node 910.
Continuing with fig. 2, an exemplary structure of the testing apparatus 533 for code provided by the embodiment of the present invention implemented as a software module is described below, and in some embodiments, as shown in fig. 2, the software module stored in the testing apparatus 533 for code in the memory 530 may include: parsing module 5331, generating module 5332, replacing module 5333, executing module 5334, and matching module 5335.
The parsing module 5331 is configured to parse a code and determine a node that needs to be configured by a tangent plane in a syntax tree of the code; a generating module 5332, configured to generate a proxy function, where the proxy function includes a tangent plane configuration logic of the code; a replacing module 5333, configured to replace the primitive function located at the node where the section configuration needs to be performed with the proxy function; an execution module 5334, configured to execute a section configuration logic included in the proxy function to simulate running the code, and receive a simulated execution result output by the proxy function; a matching module 5335, configured to match the simulation execution result with an expected execution result, and generate a test result of the code.
In some embodiments, the parsing module 5331 is further configured to parse the tangent plane configuration in the code to determine an extension function in the code, and obtain a return value of the extension function; and traversing the syntax tree of the code according to the regular expression in the return value of the extension function so as to determine the nodes needing to be subjected to tangent plane configuration in the syntax tree of the code.
In some embodiments, the generating module 5332 is further configured to determine names and parameters of primitive functions located at the node where the tangent plane configuration needs to be performed; constructing a function body consistent with the name and the parameters of the primitive function; adding section configuration logic for simulating the running of the code in the function body to obtain the proxy function.
In some embodiments, the replacing module 5333 is further configured to determine a variable type of the primitive function located at the node where the tangent plane configuration needs to be performed; determining the storage address of the primitive function according to the variable type of the primitive function; determining the storage address of the proxy function by calling a proxy tool; and replacing the original function stored in the storage address of the original function with the proxy function stored in the storage address of the proxy function.
In some embodiments, the execution module 5334 is further configured to create a main thread for executing the code and to create main context information corresponding to the main thread; creating a child thread for executing the section configuration logic included in the proxy function; determining subcontext information according to the main context information of the main thread, and binding the subcontext information with the subcontext; and obtaining a simulation execution result generated when the section configuration logic is executed according to the subcontext information bound by the subcontext.
In some embodiments, the execution module 5334 is further configured to extract a sequence number of the child thread from the child context information bound by the child thread; and calling a simulation execution result accessor to read a simulation execution result corresponding to the sequence number of the sub thread in the simulation execution result accessor.
In some embodiments, the matching module 5335 is further configured to match the simulated execution result with the expected execution result; when the simulation execution result is matched with the expected execution result, generating a test result representing that the code has no loophole; and when the simulation execution result is not matched with the expected execution result, generating a test result for representing that the code has a leak.
In some embodiments, the code testing apparatus 533 further includes: the injection module is used for injecting section configuration logic for simulating and running the code into the primitive function positioned at the node needing section configuration; executing the section configuration logic included in the primitive function to simulate and run the code, and receiving a simulation execution result output by the primitive function.
In some embodiments, the code testing apparatus 533 further includes: and the uplink module is used for storing the test result of the code into the blockchain network so that the blockchain network responds to the test data request aiming at the code according to the stored test result of the code.
Embodiments of the present invention provide a computer-readable storage medium storing executable instructions, which when executed by a processor, cause the processor to perform a method for testing code provided by embodiments of the present invention, for example, a method for testing code as shown in fig. 3A, fig. 4 or fig. 5, and various computing devices including an intelligent terminal and a server.
In some embodiments, the computer-readable storage medium may be memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash, magnetic surface memory, optical disk, or CD-ROM; or may be various devices including one or any combination of the above memories.
In some embodiments, executable instructions may be written in any form of programming language (including compiled or interpreted languages), in the form of programs, software modules, scripts or code, and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
By way of example, executable instructions can correspond, but do not necessarily correspond, to files in a file system, and can be stored in a portion of a file that holds other programs or data, e.g., in one or more scripts stored in a hypertext markup language document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code).
By way of example, executable instructions may be deployed to be executed on one computing device or on multiple computing devices at one site or distributed across multiple sites and interconnected by a communication network.
In the following, an exemplary application of the code testing method provided by the embodiment of the present invention to test a service code will be explained.
The automatic test of the service code of the server (i.e. the server) has two test methods, one is to realize the test by the simulation and reproduction of the state, and the other is the Mock test. For the service code, if repeatable, unit test, or interface test and other automated tests are required, and manual modification and intervention of the service logic code (i.e., the service code) are not required, a method capable of simulating (Mock) a Remote Procedure Call (RPC) interface, a network Call, or a third-party component is required to implement the test.
In view of the above technical problems, embodiments of the present invention provide a code testing method, which not only can automatically implant preset logic (i.e., the above-mentioned tangent plane configuration logic) into the code before and after function call to implement Mock testing, but also can solve the timing problem of Mock data acquisition of global variable (Mock) and multithreading asynchronous logic. The code testing method provided by the embodiment of the invention is suitable for functions and components of automatic interface testing, Mock called by a network and the like.
The specific implementation scheme of the embodiment of the invention is as follows:
first, a Mock function name (i.e., a proxied function name) is specified by writing a Pointcut () extension function, and a pre-set Mock logic (i.e., the above-mentioned tangent plane configuration logic) is implemented by extending an Advice function (i.e., the above-mentioned proxy function).
Then, executing AOP code replacement tool to replace the source code under the service code path, namely replacing the original function in the source code with the proxy function.
Through the steps, the call of the proxied function existing in the logic of the service code is replaced by the call of the proxy function, and the return of the Mock data in the proxy function is realized, so that the test of the service code can be completed according to the returned Mock data.
Referring to fig. 7, fig. 7 is a flowchart illustrating a method for testing a code according to an embodiment of the present invention, and a specific implementation manner of replacing a source code in a service code path is described in detail below with reference to fig. 7.
In step S701, the service code is parsed.
In some embodiments, a syntax tree of the business code is parsed, including other source codes on which the source file depends, and so on.
In step S702, the slice configuration is analyzed, and the return value of the extension function (e.g., PointCut () function) is acquired.
In step S703, a target syntax tree calling node (i.e., the node requiring the tangent plane configuration) is matched in the syntax tree of the service code according to the regular expression in the return value of the extension function.
In step S704, a proxy function is generated.
Here, the proxy function includes pre-set Mock logic.
In some embodiments, the name and parameters of the primitive function located at the calling node of the matching target syntax tree are determined; constructing a function body consistent with the name and the parameters of the original function; and adding pre-preset Mock logic in the function body to generate the proxy function.
In step S705, the primitive function in the target syntax tree calling node is replaced with a proxy function.
In some embodiments, the specific processes of step S704 and step S705 are: and analyzing the parameter signature of the primitive function, generating a proxy function with the same parameter signature according to the parameter signature of the primitive function, and adding the proxy function to the tail of the syntax tree.
In step S706, the source code file is rewritten and the rewritten source code file is overwritten on the original source code file.
In the testing process of the code, a calling process which is consistent in the testing environment and on line is needed, and external dependence and internal states are simulated generally. In the Mock testing process, points needing Mock in the service code can be divided into two types, which are respectively:
the first type is to obtain values through function calls, for example, obtaining remote RPC function interface values, obtaining network connection data through network functions, and obtaining component data through Software Development Kit (SDK) internal functions provided by third-party components.
The second type is a state variable of a local global, for example, a business customized global variable, a local cache frame and the like. The common characteristic of this category is that global variables are used, so if the reference of the global variables can be intercepted and the variable value of Mock is returned, the service with state can be restored in the field.
The embodiment of the invention can not only perform Mock on the common function, but also perform Mock on the global variable.
For the service code using the asynchronous thread, the time sequence problem of acquiring Mock data in the process of interface automation test and unit test is solved by generating the code transferred by the context and managing the context. Referring to fig. 8, fig. 8 is a schematic flowchart of a method for testing a code according to an embodiment of the present invention, and a specific implementation manner of acquiring Mock data (i.e., the above simulation execution result) is described in detail below with reference to fig. 8.
In step S801, the user request process is submitted to the main thread, and the Context manager is called to generate a parent Context (Context).
In some embodiments, each thread creates or binds a Context before executing, the Context contains the sequence number S of the current thread, and the sequence number S of the thread before acquiring the Mock data is incremented by 1 each time. The sequence number S of the outermost thread (i.e., the main thread) is an initial value of 0. Where Context and the thread itself are bound.
In step S802, the parent thread generates a sequence number for the component call, and updates the current sequence number S +1 by the sequence number generator.
In some embodiments, each thread or sub-thread has a respective non-conflicting sequence number segment, and the current sequence number S ═ S +1 is incremented within the sequence number segment. And the serial number S is used as a parameter, and the Mock data can be successfully acquired from the Mock data accessor.
In step S803, the parent thread calls a third-party component to obtain the current serial number S, and obtains Mock data according to the component name and the current serial number S as a data request result.
In step S804, the parent thread acquires a child thread context through the context manager.
In some embodiments, each child thread creates or binds a piece of Sub-Context information (Sub-Context) for it, and the initial value of the sequence number S of the child thread is multiplied by 10000 from the current sequence number of the Context of the main thread as the initial value. The Context manager obtains the initial sequence number S1 of the child Context (Sub Context) as 10000 × S +0 through the sequence number generator, and returns the child Context to the parent thread.
In step S805, the parent thread creates a child thread and passes the child context to the child thread.
In some embodiments, the additional attribute information of the Sub-Context of the child thread is copied from the Context of the main thread, so that cross-thread Context transfer can be realized. Similarly, the thread number S is incremented by 1 each time a child thread acquires Mock data.
In step S806, the child thread calls a third party component to obtain the current sequence number of the child context through the context manager S1 and Mock data from the component name and the current sequence number S1.
In some embodiments, the created child threads are not executed in order, but because the sequence number segments are assigned in the order of creation when the child threads are created, i.e., before the child threads initiate execution, the sequence number segments of the child threads are arranged in the exact order in which the child threads were created. And the order of child thread creation is also semantically fixed in the main thread, e.g., in the for loop statement, for i ═ 0to n { go func () { fmt.print (i); and the order of creating sub-threads (go func () statements) is also bound with i, so that the accuracy of the acquired Mock data can be ensured.
In summary, the embodiments of the present invention have the following beneficial effects:
(1) the method is suitable for automatic testing of codes of the server side of the static compiling type language. Through the implementation of Mock on the common components in the industry, the method can be suitable for various different business services.
(2) The code can be tested non-invasively for Mock: the service code does not need to be modified, and a tester does not need to write a test case.
(3) The code can be tested in all directions, namely a Mock test of a service with a state (namely a global variable) is supported; the Mock test of the service codes using asynchronous multithreading is supported, and the Mock timing problem in the automatic test process is solved.
(4) The nodes needing section configuration can be obtained in the common function in a matching way; the node needing section configuration can be obtained in the asynchronous thread statement in a matching way; the nodes needing section configuration can be obtained in the global variable in a matching mode, and therefore comprehensiveness and accuracy of code testing can be improved.
(5) Not only proxy functions corresponding to normal functions and to global variables can be generated; proxy functions corresponding to asynchronous thread statements can be generated, so that the proxy functions can be replaced by the proxy functions flexibly in the following process no matter what types of functions the primitive functions located at the nodes needing to be subjected to tangent plane configuration are.
(6) The simulation execution result is matched with the expected execution result to test the code, so that the technical effect of quickly and accurately detecting the bugs existing in the code without manual intervention can be realized.
(7) The section configuration logic for simulating the running code is injected into the code on the basis of ensuring the original logic integrity of the tested code, so that the bugs existing in the code can be quickly and accurately detected without manual intervention, and the testing efficiency is improved.
The above description is only an example of the present invention, and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, and improvement made within the spirit and scope of the present invention are included in the protection scope of the present invention.
Claims (10)
1. A method for testing code, the method comprising:
analyzing a code, and determining a node needing section configuration in a syntax tree of the code;
generating a proxy function, wherein the proxy function comprises tangent plane configuration logic of the code;
replacing the original function at the node needing section configuration with the proxy function;
executing the tangent plane configuration logic included by the proxy function to simulate the running of the code, and receiving a simulated execution result output by the proxy function;
and matching the simulation execution result with an expected execution result to generate a test result of the code.
2. The method of claim 1, wherein the parsing the code to determine the nodes in the syntax tree of the code that need to be configured as the tangent plane comprises:
analyzing the section configuration in the code to determine an extension function in the code and obtain a return value of the extension function;
and traversing the syntax tree of the code according to the regular expression in the return value of the extension function so as to determine the nodes needing to be subjected to tangent plane configuration in the syntax tree of the code.
3. The method of claim 1, wherein generating the proxy function comprises:
determining the name and parameters of the primitive function at the node needing section configuration;
constructing a function body consistent with the name and the parameters of the primitive function;
adding section configuration logic for simulating the running of the code in the function body to obtain the proxy function.
4. The method of claim 1, wherein replacing the primitive function at the node requiring the facet configuration with the proxy function comprises:
determining the variable type of the primitive function at the node needing section configuration;
determining the storage address of the primitive function according to the variable type of the primitive function;
determining the storage address of the proxy function by calling a proxy tool;
and replacing the original function stored in the storage address of the original function with the proxy function stored in the storage address of the proxy function.
5. The method of claim 1, wherein executing the proxy function comprises configuring logic in the tangent plane to simulate running the code, receiving simulated execution results output by the proxy function, and wherein the simulating comprises:
creating a main thread for executing the code and creating main context information corresponding to the main thread;
creating a child thread for executing the tangent plane configuration logic included by the proxy function;
determining subcontext information according to the main context information of the main thread, and binding the subcontext information with the subcontext;
and obtaining a simulation execution result generated when the section configuration logic is executed according to the subcontext information bound by the subcontext.
6. The method as claimed in claim 5, wherein the obtaining the simulation execution result generated when the section configuration logic is executed according to the subcontext information bound by the child thread comprises:
extracting the serial number of the sub thread from the sub context information bound by the sub thread;
and calling a simulation execution result accessor to read a simulation execution result corresponding to the sequence number of the sub thread in the simulation execution result accessor.
7. The method of claim 1, wherein matching the simulated execution result with an expected execution result to generate a test result of the code comprises:
matching the simulated execution result with the expected execution result;
when the simulation execution result is matched with the expected execution result, generating a test result representing that the code has no loophole;
and when the simulation execution result is not matched with the expected execution result, generating a test result for representing that the code has a leak.
8. The method of claim 1, wherein after parsing the code and determining the nodes in the syntax tree of the code that require the tangent plane configuration, the method further comprises:
injecting section configuration logic for simulating and running the code into the primitive function at the node needing section configuration;
executing the primitive function comprises tangent plane configuration logic to simulate running the code, and receiving a simulation execution result output by the primitive function when the tangent plane configuration logic is executed.
9. The method of claim 1, wherein after the generating the test result for the code, the method further comprises:
storing test results of the code into a blockchain network such that
And the block chain network responds to a test data request aiming at the code according to the stored test result of the code.
10. An apparatus for testing a code, the apparatus comprising:
the analysis module is used for analyzing the codes and determining nodes needing section configuration in a syntax tree of the codes;
a generating module, configured to generate a proxy function, where the proxy function includes a tangent plane configuration logic of the code;
a replacing module, configured to replace the primitive function located at the node where the section configuration needs to be performed with the proxy function;
the execution module is used for executing the tangent plane configuration logic included by the proxy function so as to simulate and run the code, and receiving a simulation execution result output by the proxy function;
and the matching module is used for matching the simulation execution result with an expected execution result to generate a test result of the code.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010328137.5A CN113553250A (en) | 2020-04-23 | 2020-04-23 | Code testing method and device |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010328137.5A CN113553250A (en) | 2020-04-23 | 2020-04-23 | Code testing method and device |
Publications (1)
Publication Number | Publication Date |
---|---|
CN113553250A true CN113553250A (en) | 2021-10-26 |
Family
ID=78129438
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010328137.5A Pending CN113553250A (en) | 2020-04-23 | 2020-04-23 | Code testing method and device |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113553250A (en) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114185520A (en) * | 2021-12-16 | 2022-03-15 | 上海众源网络有限公司 | Object copying method, device, electronic device and storage medium |
CN114723397A (en) * | 2022-03-28 | 2022-07-08 | 阿里云计算有限公司 | Flow execution method and device |
CN115344502A (en) * | 2022-10-18 | 2022-11-15 | 中建电子商务有限责任公司 | Method for automatically generating mock data and automatically loading mock data based on real data |
CN115795479A (en) * | 2022-11-24 | 2023-03-14 | 远光软件股份有限公司 | Vulnerability detection method of intelligent contract, electronic equipment and storage medium |
CN116137601A (en) * | 2021-11-17 | 2023-05-19 | 腾讯科技(深圳)有限公司 | A test method, related device and equipment for target test pile service |
CN118194293A (en) * | 2024-03-15 | 2024-06-14 | 北京奇虎科技有限公司 | Fuzz testing methods and related equipment for machine learning frameworks |
CN119046177A (en) * | 2024-11-04 | 2024-11-29 | 杭州新中大科技股份有限公司 | Processing method, device, equipment, medium and product for unit test |
-
2020
- 2020-04-23 CN CN202010328137.5A patent/CN113553250A/en active Pending
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116137601A (en) * | 2021-11-17 | 2023-05-19 | 腾讯科技(深圳)有限公司 | A test method, related device and equipment for target test pile service |
CN116137601B (en) * | 2021-11-17 | 2025-07-25 | 腾讯科技(深圳)有限公司 | Test method, related device and equipment for target test pile service |
CN114185520A (en) * | 2021-12-16 | 2022-03-15 | 上海众源网络有限公司 | Object copying method, device, electronic device and storage medium |
CN114723397A (en) * | 2022-03-28 | 2022-07-08 | 阿里云计算有限公司 | Flow execution method and device |
CN115344502A (en) * | 2022-10-18 | 2022-11-15 | 中建电子商务有限责任公司 | Method for automatically generating mock data and automatically loading mock data based on real data |
CN115344502B (en) * | 2022-10-18 | 2023-03-10 | 中建电子商务有限责任公司 | Method for automatically generating mock data and automatically loading mock data based on real data |
CN115795479A (en) * | 2022-11-24 | 2023-03-14 | 远光软件股份有限公司 | Vulnerability detection method of intelligent contract, electronic equipment and storage medium |
CN118194293A (en) * | 2024-03-15 | 2024-06-14 | 北京奇虎科技有限公司 | Fuzz testing methods and related equipment for machine learning frameworks |
CN119046177A (en) * | 2024-11-04 | 2024-11-29 | 杭州新中大科技股份有限公司 | Processing method, device, equipment, medium and product for unit test |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN113553250A (en) | Code testing method and device | |
US10846083B2 (en) | Semantic-aware and self-corrective re-architecting system | |
Huang et al. | Confvalley: A systematic configuration validation framework for cloud services | |
WO2019029160A1 (en) | Application construction method and system, computer device, and storage medium | |
CN109032825B (en) | Fault injection method, device and equipment | |
US20210191845A1 (en) | Unit testing of components of dataflow graphs | |
CN112104709A (en) | Intelligent contract processing method, device, medium and electronic equipment | |
Felício et al. | Rapitest: Continuous black-box testing of restful web apis | |
US8607203B1 (en) | Test automation framework using dependency injection | |
CN107391528B (en) | Front-end component dependent information searching method and equipment | |
CN110019116B (en) | Data tracing method, device, data processing equipment and computer storage medium | |
US20200110695A1 (en) | Dynamic integration of command line utilities | |
CN104679500B (en) | Method and device for realizing automatic generation of entity class | |
CN111625472B (en) | A unit testing method and device | |
CN105512044A (en) | Method and system for updating object base used for keyword drive test | |
Hughes | How to Specify It! A Guide to Writing Properties of Pure Functions | |
US20240160559A1 (en) | Automated decoupling of unit tests | |
US20200097260A1 (en) | Software application developer tools platform | |
CN111580409B (en) | Fault simulation test method for real-time embedded system | |
Marra | A live debugging approach for big data processing applications | |
CN113031964B (en) | Big data application management method, device, equipment and storage medium | |
CN116467188A (en) | Universal local reproduction system and method under multi-environment scene | |
Markusfeld | Automating build, deployment, and monitoring of model-based digital twins | |
Święcicki et al. | How is server software configured? examining the structure of configuration files | |
de Boer et al. | Run-time verification of coboxes |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |