CN113535533B - Method, apparatus, device and storage medium for testing code - Google Patents
Method, apparatus, device and storage medium for testing code Download PDFInfo
- Publication number
- CN113535533B CN113535533B CN202010296161.5A CN202010296161A CN113535533B CN 113535533 B CN113535533 B CN 113535533B CN 202010296161 A CN202010296161 A CN 202010296161A CN 113535533 B CN113535533 B CN 113535533B
- Authority
- CN
- China
- Prior art keywords
- code
- test task
- historical
- task
- target
- 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.)
- Active
Links
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
-
- 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/362—Debugging of software
- G06F11/3628—Debugging of software of optimised code
-
- 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/3692—Test management for test results analysis
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
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 application discloses a method, a device, equipment and a storage medium for testing codes, and relates to the field of code testing. The specific implementation scheme is as follows: acquiring information of a target code test task; acquiring information of a historical code testing task; determining a redundancy test task from the target code test task and the history code test task according to the information of the target code test task and the information of the history code test task; and determining a test result of the target code test task based on the redundancy test task. The implementation mode realizes reasonable utilization of the test resources and shortens the test period.
Description
Technical Field
The present application relates to the field of computer technology, and in particular, to the field of code testing, and in particular, to a method, apparatus, device, and storage medium for testing codes.
Background
In the development process of the software project in the prior art, developers can perform internal testing on the software in the development project. For many software projects, especially those developed by large software teams, the prior art uses a software development model of a branch-and-merge backbone. This code development of the respective new function is completed on a plurality of branches, and then the new function completed on the branches is subjected to a branch test. After each branch functional test passes, the branch code is merged into the directory where the backbone code resides. Such a test model may be generally referred to as a hierarchical build.
In the conventional test mode, in order to ensure the test quality of software, a large and full test mode is operated in each hierarchical construction, namely, the test method and the test magnitude of each method are heavy, and some redundancy exists. Today, the above-described situation is not pursued by ideal test services in order to meet today's requirements for high-speed iteration of the internet industry while guaranteeing quality.
Disclosure of Invention
A method, apparatus, device, and storage medium for testing code are provided.
According to a first aspect, there is provided a method for testing code, comprising: acquiring information of a target code test task; acquiring information of a historical code testing task; determining a redundancy test task from the target code test task and the history code test task according to the information of the target code test task and the information of the history code test task; and determining a test result of the target code test task based on the redundancy test task.
According to a second aspect, there is provided an apparatus for testing code, comprising: a first acquisition unit configured to acquire information of an object code test task; a second acquisition unit configured to acquire information of a history code test task; the redundancy determining unit is configured to determine a redundancy test task from the target code test task and the history code test task according to the information of the target code test task and the information of the history code test task; and a result determination unit configured to determine a test result of the object code test task based on the redundancy test task.
According to a third aspect, there is provided an electronic device comprising: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method as described in the first aspect.
According to a fourth aspect, there is provided a non-transitory computer readable storage medium storing computer instructions for causing a computer to perform the method as described in the first aspect.
According to the technology, the technical problems of waste of test resources and prolonged test period caused by redundant tasks in the existing code test scheme are solved, reasonable utilization of the test resources is realized, and the test period is shortened.
It should be understood that the description in this section is not intended to identify key or critical features of the embodiments of the disclosure, nor is it intended to be used to limit the scope of the disclosure. Other features of the present disclosure will become apparent from the following specification.
Drawings
The drawings are for better understanding of the present solution and do not constitute a limitation of the present application. Wherein:
FIG. 1 is an exemplary system architecture diagram in which an embodiment of the present application may be applied;
FIG. 2 is a flow chart of one embodiment of a method for testing code according to the present application;
FIG. 3 is a flow chart of another embodiment of a method for testing code according to the present application;
FIG. 4 is a schematic view of an application scenario of the embodiment shown in FIG. 3;
FIG. 5 is a schematic structural view of one embodiment of an apparatus for testing code according to the present application;
fig. 6 is a block diagram of an electronic device for implementing a method for testing code of an embodiment of the present application.
Detailed Description
Exemplary embodiments of the present application are described below in conjunction with the accompanying drawings, which include various details of the embodiments of the present application to facilitate understanding, and should be considered as merely exemplary. Accordingly, one of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present application. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
It should be noted that, in the case of no conflict, the embodiments and features in the embodiments may be combined with each other. The present application will be described in detail below with reference to the accompanying drawings in conjunction with embodiments.
FIG. 1 illustrates an exemplary system architecture 100 to which embodiments of the methods for testing code or apparatus for testing code of the present application may be applied.
As shown in fig. 1, a system architecture 100 may include terminal devices 101, 102, 103, a network 104, and a server 105. The network 104 is used as a medium to provide communication links between the terminal devices 101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.
A developer can interact with the server 105 via the network 104 using the terminal devices 101, 102, 103 to receive or send messages or the like. Various communication client applications, such as a version control class application, a code development class application, and the like, may be installed on the terminal devices 101, 102, 103. The developer may send the developed code to the server 105 via the network 104.
The terminal devices 101, 102, 103 may be hardware or software. When the terminal devices 101, 102, 103 are hardware, they may be various electronic devices including, but not limited to, smartphones, tablets, laptop and desktop computers, and the like. When the terminal devices 101, 102, 103 are software, they can be installed in the above-listed electronic devices. Which may be implemented as multiple software or software modules (e.g., to provide distributed services), or as a single software or software module. The present invention is not particularly limited herein.
The server 105 may be a server providing various services, such as a background server testing codes submitted by the terminal devices 101, 102, 103. The background server can receive codes submitted by developers, test the codes and feed test results back to the terminal devices 101, 102 and 103.
The server 105 may be hardware or software. When the server 105 is hardware, it may be implemented as a distributed server cluster formed by a plurality of servers, or as a single server. When server 105 is software, it may be implemented as a plurality of software or software modules (e.g., to provide distributed services), or as a single software or software module. The present invention is not particularly limited herein.
It should be noted that the method for testing code provided in the embodiments of the present application is generally performed by the server 105. Accordingly, the means for testing the code is typically provided in the server 105.
It should be understood that the number of terminal devices, networks and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.
With continued reference to FIG. 2, a flow 200 of one embodiment of a method for testing code according to the present application is shown. The method for testing codes of the present embodiment includes the steps of:
Step 201, information of an object code test task is obtained.
In this embodiment, the execution body (e.g., the server 105 shown in fig. 1) of the method for testing a code may acquire information of a target code test task through a wired connection or a wireless connection. Here, the object code test task is a test task of a pointer to an object code, which may be code written by a developer through a software development class application for testing. After the developer submits the code object code, the execution body may generate an object code test task.
The information of the object code test task may include a task initiator identification of the object code test task, initiation time, object code, code status. The task initiator identifier refers to an identifier of a developer initiating the target code test task or an identifier of a developer submitting the target code. The initiation time may refer to the acquisition time of the target code test task, and may also refer to the time when the task initiator initiates the code test task. The target code is the code to be tested, which may include the target native code and the target backbone code. The code state is used to indicate whether the target native code is merged into the main stem code, and the code state may include both merged and uncombined.
The save path of the code is stabilized in the version control software (e.g., SVN, git, clearase, etc.), whereby the path compiles the release version of the software. Typically, only one backbone path exists for a software development project. What is kept under the directory of the backbone is the backbone code. In the version control software, a developer develops and tests new functions on branches by developing/debugging a code save path, and when the functions are verified to be correct, the local codes are combined into a backbone. Typically, a software development project may have multiple branches present. Kept under the directory of branches is the branch code.
In this embodiment, the target native code refers to a native code that is aimed at when a developer initiates a target code test task. The target trunk code refers to the trunk code aimed at when the developer initiates the target code test task. It will be appreciated that the target backbone code may or may not include code incorporated by other developers.
In this embodiment, the execution body may obtain the information of the target code test task after receiving the code test request. The code test request may be a code test request that the user sends to the execution question by clicking on some buttons in a code writing class application installed on the terminal device.
Step 202, obtaining information of a historical code testing task.
The execution body may also obtain information of the historical code test tasks. Here, the history code test task refers to a code test task acquired before the above-described target code test task is acquired. For example, at the current time of 3:15, the execution body receives the code test task a at 3:10 and the code test task B at 3:15. The code test task a becomes a history code test task and the code test task B becomes a target code test task.
In this embodiment, the information of the history code test task may include a task initiator identifier, an initiation time, a history code, a code state, and an operation state of the history code test task. The task initiator identification of the history code test task refers to the identification of the developer initiating the history code test task. The initiation time may refer to the acquisition time of the history code test task, and may also refer to the time when the history code test task is initiated by the history task initiator. The history codes are codes aimed by the history test tasks, and the history codes can also comprise history local codes and history trunk codes. It may be understood that the historical local code refers to the local code to which the historical code test task is initiated, and the historical backbone code refers to the backbone code to which the historical code test task is initiated. The code state is used to indicate whether the history native code is incorporated into the history backbone code at the initiation of the history code test task. The code state may include both engaged and disengaged. The running state is used for representing the completion state of the historical code testing task, and the running state can comprise: completed, in-test, not tested.
And 203, determining a redundancy test task from the target code test task and the history code test task according to the information of the target code test task and the information of the history code test task.
After obtaining the information of the target code test task and the information of the historical code test task, the execution body can determine the redundant test task from the target code test task and the historical code test task. Specifically, the execution body may identify at least one code test task initiated by the same task initiator within a preset period of time as a redundant test task. For example, the execution subject may take the previous code test task of the 2 code test tasks initiated by developer a within 1 minute as a redundant test task. It is understood that the redundancy test task may be an object code test task or a history code test task.
Step 204, determining a test result of the target code test task based on the redundancy test task.
After determining the redundancy test task, the execution body may determine a test result of the object code test task. Specifically, if the redundancy test task is an object code test task, the execution subject may not execute the object code test task and multiplex test results of the history code test task. That is, the test result of the history code test task is taken as the test result of the target code test task. If the redundant test task is a historical code test task, the target code test task can be continuously executed to obtain a test result of the target code test task.
With continued reference to fig. 3, a schematic diagram of one application scenario of a method for testing code according to the present application is shown. In the application scenario of fig. 3, a developer sends a code test request to a server 302 through a version control class application installed in a terminal 301. The server 302 may obtain the information of the target code test task and the information of the history code test task after receiving the code test request. The server 302, through analysis, determines that the object code test task is a redundant test task. Server 302 may multiplex the test results of the history code test tasks as the test results of the target code test tasks. The test results are then returned to the terminal 301. Therefore, the target code test task does not need to be executed, the test resources are saved, and the test period is shortened.
The method for testing the codes, which is provided by the embodiment of the application, can determine the redundant test tasks, so that the number of the test tasks is reduced, the accuracy of the test result is ensured, the test efficiency is improved, and the test period is shortened.
With continued reference to FIG. 4, a flow 400 of another embodiment of a method for testing code according to the present application is shown. As shown in fig. 4, the method for testing code of the present embodiment may include the steps of:
Step 401, obtaining information of an object code test task.
In this embodiment, the information of the target code test task may include a task initiator identifier, a code incorporation state, a target local code, and a target backbone code of the target code test task.
Step 402, information of a historical code testing task is obtained.
In this embodiment, the information of the historical code test task may include a task initiator identifier, an initiation time, a code merging state, a historical code, a code state, and an operation state of the historical code test task.
Step 403, determining whether the code in-process status of the object code test task and the history code test task is not in-process.
The execution subject can judge whether the target local code is not in the merging state according to the code in the target code test task information. Similarly, the execution subject may determine whether the history local code is not incorporated according to the code incorporation state in the history code test task information. If so, step 4041 is performed, indicating that the user is performing a native code test. If not, then steps 4042 and 4043 are performed.
Step 4041, determining whether the target task initiator identity is the same as the historical task initiator identity.
The execution body may further determine whether the target task initiator identifier in the target code test task information is the same as the historical task initiator identifier in the historical code test task information. It will be appreciated that the target native code in the object code test task is not entered, nor is the historical native code in the historical code test task compared here. If so, then the target code test task and the history code test task are initiated by the same user, and step 4051 is continued.
Step 4051, it is determined whether the target local code and the history local code are the same.
In practical application, when a developer initiates self-test, the developer may frequently modify codes and repeatedly initiate code test tasks. This scenario may be intended where a previously initiated code test task has not yet been performed to completion. Thus, the last initiated code test task cannot reuse the results of the previously initiated code test task. But the previously initiated code test task has been invalidated with respect to the last initiated code test task. Thus, the previously initiated code test task may be executed concurrently with the last initiated code test task. This can result in excessive use of test resources in a short period of time, resulting in the problem of a large number of code test tasks waiting for stacking, as other code test tasks need to be queued because the test resources are occupied.
In this embodiment, the execution subject may determine whether the target native code and the history native code are identical. Specifically, in practical applications, a developer may modify the code in the form of a patch (patch). That is, the developer would add a patch after the last code, indicating a modification to the code. The execution subject may determine whether the patch is added to the target native code by comparing the target native code to the history native code. If a patch is not added, indicating that the developer has not modified the history native code, then step 4061 is performed. If a patch is added, indicating that the developer modified the historical native code, step 4062 is performed.
Step 4061, determining the historical code test task as a redundant test task.
In this embodiment, if the developer modifies the historical native code, it is indicated that the historical code test task is not the same as the target code test task. And if the meaning of the test result of the historical code test task is not great, the historical code test task can be determined to be a redundant test task.
Step 4062, determining the target code test task as a redundant test task.
In this embodiment, if the developer does not modify the historical native code, it is stated that the historical code test task is the same as the target code test task. Since the historical code test tasks have been initiated, the execution subject may no longer execute the target code test tasks. Therefore, the object code test task is determined as a redundant test task.
Step 4042, a first difference between the target native code and the target stem code is determined.
In practical application, because the code is submitted and incorporated continuously due to frequent iteration of the service, the local code is often integrated with the incorporated code of other developers, and the code itself is often changed. While developers typically only focus on the running of their own code. Thus, the developer is more concerned about the differences in the native code and the backbone code.
In this embodiment, if the target native code has been merged into the target stem code, the execution subject may first determine a first difference between the target native code and the target stem code.
Step 4052, a second difference between the historical native code and the historical backbone code is determined.
In this embodiment, the execution subject may also determine a second difference between the history native code and the history backbone code. It will be appreciated that the historical native code herein has also incorporated the historical backbone code.
Step 4063, determining whether the first difference and the second difference are the same.
If the first difference and the second difference are the same, the object code test task is the same as the history code test task. Then the object code test task need not be executed, which is a redundant test task.
In step 4043, it is determined whether the target backbone code is the same as the history backbone code.
After the codes of the developers are integrated into the main code, each integrated code can be independently executed. However, after all the codes of the developers are mixed, the overall running condition cannot be judged, and at the moment, the codes of all the developers are required to be integrated for unified test. In this case, the execution subject may determine whether the target backbone code is identical to the history backbone code. If so, the target code test task is the same as the history code test task. Then the object code test task need not be executed, which is a redundant test task.
Step 407, cancelling execution of the historical code test task in response to determining that the historical code test task is a redundant task and that the running state of the historical code test task is under test or not under test; and executing the target code test task to obtain a test result of the target code test task.
If the execution subject determines that the historical code testing task is a redundant task and the running state of the historical code testing task is under test or not, namely the historical code testing task still occupies testing resources. The execution subject may cancel the execution of the history code test task and execute the object code test task to obtain a test result of the object code test task.
In step 408, in response to determining that the target code test task is a redundant test task, the test result of the historical code test task is taken as the test result of the target code test task.
In this embodiment, if the execution subject determines that the object code test task is a redundant test task, the execution subject may not execute the object code test task and multiplex the test results of the history code test task. That is, the test result of the history code test task is taken as the test result of the target code test task.
According to the method for testing codes provided by the embodiment of the application, redundant test tasks under two conditions before and after the codes are combined can be determined, and test results of historical code test tasks can be multiplexed or the historical code test tasks can be canceled for the redundant test tasks. Redundant tasks in the test tasks are simplified, and the test period is shortened.
In some optional implementations of the present embodiment, the method may further include the following steps not shown in fig. 4: receiving a data calling request, wherein the calling request comprises test task retrieval information; and outputting the information of the historical code test task corresponding to the test task retrieval information through a preset interface.
In this implementation, the execution body may be implemented as a task scheduling platform. The task scheduling platform can receive all code test tasks, and can collect data of each code test task before, during and after execution and store the data in the data center. Therefore, the system is convenient for unified maintenance, and the operation and maintenance cost of each code test task can be reduced. The task scheduling platform also provides an externally unified interface (API) for other electronic devices to call. That is, the task scheduling platform may receive a data call request, which may include test task retrieval information. The test task retrieval information may include task originator identification, time of initiation, and so forth. The execution subject can retrieve the information of the corresponding historical code test task according to the test task retrieval information. And outputting the retrieved information of the historical code testing task through the interface. Thus, the subsequent strategy analysis on the code test task is facilitated.
With further reference to fig. 5, as an implementation of the method shown in the above figures, the present application provides an embodiment of an apparatus for testing codes, which corresponds to the method embodiment shown in fig. 2, and which is particularly applicable to various electronic devices.
As shown in fig. 5, the apparatus 500 for testing code of the present embodiment includes: a first acquisition unit 501, a second acquisition unit 502, a redundancy determination unit 503, and a result determination unit 504.
The first obtaining unit 501 is configured to obtain information of an object code test task.
The second obtaining unit 502 is configured to obtain information of the history code test task.
The redundancy determination unit 503 is configured to determine a redundancy test task from the object code test task and the history code test task according to the information of the object code test task and the information of the history code test task.
The result determination unit 504 is configured to determine a test result of the object code test task based on the redundancy test task.
In some optional implementations of the present embodiment, the information of the target code test task includes a code in-state, a target task initiator identification, and a target native code, and the information of the history code test task includes a code in-state, a history task initiator identification, and a history native code. The redundancy determining unit 503 may be further configured to: in response to determining that the code in-process state of the target code test task and the historical code test task is not in-process, determining whether the target task initiator identifier is the same as the historical task initiator identifier; in response to determining that the target task initiator identity is the same as the historical task initiator identity, determining whether the target local code and the historical local code are the same; in response to determining that the target native code and the historical native code are the same, the target code test task is determined to be a redundant test task.
In some optional implementations of the present embodiment, the redundancy determining unit 503 may be further configured to: in response to determining that the target native code and the historical native code are not identical, the historical code test task is determined to be a redundant test task.
In some optional implementations of the present embodiment, the information of the object code test task includes a code in-state, an object native code, and an object backbone code, and the information of the history code test task includes a code in-state, a history native code, and a history backbone code. The redundancy determining unit 503 may be further configured to: in response to determining that the engaged state of the object code test task and the history code test task is engaged, determining a first difference between the object code and the object backbone code and a second difference between the history local code and the history backbone code; in response to determining that the first discrepancy is the same as the second discrepancy, the object code test task is determined to be a redundant test task.
In some optional implementations of the present embodiment, the information of the object code test task includes a code in-state and an object backbone code; the information of the historical code testing task comprises a code merging state and a historical trunk code. The redundancy determining unit 503 is further configured to: in response to determining that the code merging state of the target code testing task and the historical code testing task is merged, determining whether the target trunk code is the same as the historical trunk code; and in response to determining that the target backbone code is the same as the historical backbone code, determining that the target code test task is a redundancy test task.
In some optional implementations of the present embodiment, the result determination unit 504 is further configured to: and responding to the determination that the target code test task is a redundant test task, and taking the test result of the historical code test task as the test result of the target code test task.
In some alternative implementations of the present embodiment, the information of the historical code test task includes an operational state, the operational state including being tested, not being tested. The result determination unit is further configured to: and in response to determining that the historical code test task is a redundant test task and the running state of the historical code test task is in testing or not, canceling the execution of the historical code test task, and executing the target code test task to obtain a test result of the target code test task.
In some optional implementations of the present embodiment, the apparatus 500 may further include an information calling unit, not shown in fig. 5, configured to: receiving a data calling request, wherein the calling request comprises test task retrieval information; and outputting the information of the historical code test task corresponding to the test task retrieval information through a preset interface.
It should be understood that the units 501 to 504 described in the apparatus 500 for testing codes correspond to the respective steps in the method described with reference to fig. 2. Thus, the operations and features described above with respect to the method for testing code are equally applicable to the apparatus 500 and the units contained therein, and are not described in detail herein.
According to embodiments of the present application, an electronic device and a readable storage medium are also provided.
As shown in fig. 6, is a block diagram of an electronic device that performs a method for testing code according to an embodiment of the present application. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular telephones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the application described and/or claimed herein.
As shown in fig. 6, the electronic device includes: one or more processors 601, memory 602, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The various components are interconnected using different buses and may be mounted on a common motherboard or in other manners as desired. The processor may process instructions executing within the electronic device, including instructions stored in or on memory to display graphical information of the GUI on an external input/output device, such as a display device coupled to the interface. In other embodiments, multiple processors and/or multiple buses may be used, if desired, along with multiple memories and multiple memories. Also, multiple electronic devices may be connected, each providing a portion of the necessary operations (e.g., as a server array, a set of blade servers, or a multiprocessor system). One processor 601 is illustrated in fig. 6.
Memory 602 is a non-transitory computer-readable storage medium provided herein. Wherein the memory stores instructions executable by the at least one processor to cause the at least one processor to perform the methods provided herein for outputting information. The non-transitory computer readable storage medium of the present application stores computer instructions for causing a computer to perform the methods provided herein for outputting information.
The memory 602 is a non-transitory computer readable storage medium, and may be used to store a non-transitory software program, a non-transitory computer executable program, and modules, such as program instructions/modules (e.g., the first acquisition unit 501, the second acquisition unit 502, the redundancy determination unit 503, and the result determination unit 504 shown in fig. 5) corresponding to the method for outputting information in the embodiment of the present application. The processor 601 executes various functional applications of the server and data processing by running non-transitory software programs, instructions, and modules stored in the memory 602, i.e., implements the method for outputting information in the above-described method embodiments.
The memory 602 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, at least one application program required for a function; the storage data area may store data created according to the use of the electronic device performing the output of information, and the like. In addition, the memory 602 may include high-speed random access memory, and may also include non-transitory memory, such as at least one magnetic disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory 602 may optionally include memory provided remotely from processor 601, such remote memory being connectable through a network to the electronic device performing the functions for outputting information. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
The electronic device performing the method for outputting information may further include: an input device 603 and an output device 604. The processor 601, memory 602, input device 603 and output device 604 may be connected by a bus or otherwise, for example in fig. 6.
The input device 603 may receive input numeric or character information and generate key signal inputs related to performing user settings and function controls of the electronic device for outputting the information, such as a touch screen, a keypad, a mouse, a track pad, a touch pad, a pointer stick, one or more mouse buttons, a track ball, a joystick, etc. input devices. The output means 604 may include a display device, auxiliary lighting means (e.g., LEDs), tactile feedback means (e.g., vibration motors), and the like. The display device may include, but is not limited to, a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display, and a plasma display. In some implementations, the display device may be a touch screen.
Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, application specific ASIC (application specific integrated circuit), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs, the one or more computer programs may be executed and/or interpreted on a programmable system including at least one programmable processor, which may be a special purpose or general-purpose programmable processor, that may receive data and instructions from, and transmit data and instructions to, a storage system, at least one input device, and at least one output device.
These computing programs (also referred to as programs, software applications, or code) include machine instructions for a programmable processor, and may be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, and/or device (e.g., magnetic discs, optical disks, memory, programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor.
To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and pointing device (e.g., a mouse or trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic input, speech input, or tactile input.
The systems and techniques described here can be implemented in a computing system that includes a background component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such background, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), wide Area Networks (WANs), and the internet.
The computer system may include a client and a server. The client and server are typically remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
According to the technical scheme of the embodiment of the application, the learning ability of the language model to external knowledge can be improved and the accuracy of understanding the input text can be improved by introducing the reference text in the pre-training and fine-tuning processes; by marking the input text and the reference text, the introduction of noise or dilution of the input text is avoided.
It should be appreciated that various forms of the flows shown above may be used to reorder, add, or delete steps. For example, the steps described in the present application may be performed in parallel, sequentially, or in a different order, provided that the desired results of the technical solutions disclosed in the present application can be achieved, and are not limited herein.
The above embodiments do not limit the scope of the application. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives are possible, depending on design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present application are intended to be included within the scope of the present application.
Claims (16)
1. A method for testing code, comprising:
acquiring information of an object code test task, wherein the information of the object code test task comprises a code merging state, a target specimen code and a target trunk code;
acquiring information of a historical code test task, wherein the information of the historical code test task comprises a code merging state, a historical local code and a historical trunk code;
according to the information of the target code test task and the information of the historical code test task, determining a redundancy test task from the target code test task and the historical code test task comprises the following steps: in response to determining that the in-process status of the object code test task and the historical code test task is in-process, determining a first difference between the object native code and the object backbone code and a second difference between the historical native code and the historical backbone code; in response to determining that the first variance is the same as the second variance, determining that the target code test task is a redundant test task;
And determining a test result of the target code test task based on the redundancy test task.
2. The method of claim 1, wherein the information of the target code test task includes a code in-state, a target task initiator identification, and a target native code, and the information of the history code test task includes a code in-state, a history task initiator identification, and a history native code; and
and determining a redundancy test task from the target code test task and the history code test task according to the information of the target code test task and the information of the history code test task, including:
determining whether the target task initiator identifier is the same as the historical task initiator identifier in response to determining that the code in-process state of the target code test task and the historical code test task is not in-process;
responsive to determining that the target task initiator identity is the same as the historical task initiator identity, determining whether the target native code and the historical native code are the same;
in response to determining that the target native code and the historical native code are the same, the target code test task is determined to be a redundant test task.
3. The method of claim 2, wherein the determining a redundancy test task from the object code test task and the history code test task based on the information of the object code test task and the information of the history code test task comprises:
in response to determining that the target native code and the historical native code are not identical, the historical code test task is determined to be a redundant test task.
4. The method of claim 1, wherein the information of the object code test task includes a code in-state and an object backbone code; the information of the historical code testing task comprises a code merging state and a historical trunk code; and
and determining a redundancy test task from the target code test task and the history code test task according to the information of the target code test task and the information of the history code test task, including:
in response to determining that the code in-process state of the target code test task and the historical code test task is in-process, determining whether the target backbone code and the historical backbone code are the same;
In response to determining that the target backbone code is the same as the historical backbone code, determining that the target code test task is a redundancy test task.
5. The method of any of claims 1-4, wherein the determining a test result of the object code test task based on the redundancy test task comprises:
and responding to the determination that the target code test task is a redundant test task, and taking the test result of the historical code test task as the test result of the target code test task.
6. The method of claim 5, wherein the information of the historical code testing task includes an operational state, the operational state including being tested, not tested; and
the determining, based on the redundancy test task, a test result of the object code test task includes:
and in response to determining that the historical code test task is a redundant test task and the running state of the historical code test task is in testing or not, canceling to execute the historical code test task, and executing the target code test task to obtain a test result of the target code test task.
7. The method of claim 1, wherein the method further comprises:
receiving a data call request, wherein the call request comprises test task retrieval information;
and outputting the information of the historical code test task corresponding to the test task retrieval information through a preset interface.
8. An apparatus for testing code, comprising:
the first acquisition unit is configured to acquire information of an object code test task, wherein the information of the object code test task comprises a code merging state, a target local code and a target trunk code;
the second acquisition unit is configured to acquire information of a historical code testing task, wherein the information of the historical code testing task comprises a code merging state, a historical local code and a historical trunk code;
a redundancy determination unit configured to determine a redundancy test task from the object code test task and the history code test task according to the information of the object code test task and the information of the history code test task, including: in response to determining that the in-process status of the object code test task and the historical code test task is in-process, determining a first difference between the object native code and the object backbone code and a second difference between the historical native code and the historical backbone code; in response to determining that the first variance is the same as the second variance, determining that the target code test task is a redundant test task;
And a result determining unit configured to determine a test result of the object code test task based on the redundancy test task.
9. The apparatus of claim 8, wherein the information of the target code test task includes a code in-state, a target task initiator identification, and a target native code, and the information of the history code test task includes a code in-state, a history task initiator identification, and a history native code; and
the redundancy determination unit is further configured to:
determining whether the target task initiator identifier is the same as the historical task initiator identifier in response to determining that the code in-process state of the target code test task and the historical code test task is not in-process;
responsive to determining that the target task initiator identity is the same as the historical task initiator identity, determining whether the target native code and the historical native code are the same;
in response to determining that the target native code and the historical native code are the same, the target code test task is determined to be a redundant test task.
10. The apparatus of claim 9, wherein the redundancy determination unit is further configured to:
In response to determining that the target native code and the historical native code are not identical, the historical code test task is determined to be a redundant test task.
11. The apparatus of claim 8, wherein the information of the object code test task includes a code in-state and an object backbone code; the information of the historical code testing task comprises a code merging state and a historical trunk code; and
the redundancy determination unit is further configured to:
in response to determining that the code in-process state of the target code test task and the historical code test task is in-process, determining whether the target backbone code and the historical backbone code are the same;
in response to determining that the target backbone code is the same as the historical backbone code, determining that the target code test task is a redundancy test task.
12. The apparatus according to any of claims 8-11, wherein the result determination unit is further configured to:
and responding to the determination that the target code test task is a redundant test task, and taking the test result of the historical code test task as the test result of the target code test task.
13. The apparatus of claim 12, wherein the information of the historical code testing task includes an operational state, the operational state including being tested, not tested; and
the result determination unit is further configured to:
and in response to determining that the historical code test task is a redundant test task and the running state of the historical code test task is in testing or not, canceling to execute the historical code test task, and executing the target code test task to obtain a test result of the target code test task.
14. The apparatus of claim 8, wherein the apparatus further comprises an information invoking unit configured to:
receiving a data call request, wherein the call request comprises test task retrieval information;
and outputting the information of the historical code test task corresponding to the test task retrieval information through a preset interface.
15. An electronic device, comprising:
at least one processor; and
a memory communicatively coupled to the at least one processor; wherein,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.
16. A non-transitory computer readable storage medium storing computer instructions for causing the computer to perform the method of any one of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010296161.5A CN113535533B (en) | 2020-04-15 | 2020-04-15 | Method, apparatus, device and storage medium for testing code |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010296161.5A CN113535533B (en) | 2020-04-15 | 2020-04-15 | Method, apparatus, device and storage medium for testing code |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113535533A CN113535533A (en) | 2021-10-22 |
| CN113535533B true CN113535533B (en) | 2024-04-05 |
Family
ID=78120079
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010296161.5A Active CN113535533B (en) | 2020-04-15 | 2020-04-15 | Method, apparatus, device and storage medium for testing code |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113535533B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115061697A (en) * | 2022-06-30 | 2022-09-16 | 抖音视界(北京)有限公司 | A code deployment method, device, computer equipment and storage medium |
Citations (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105095059A (en) * | 2014-04-15 | 2015-11-25 | 阿里巴巴集团控股有限公司 | Method and device for automated testing |
| CN105302716A (en) * | 2014-07-30 | 2016-02-03 | 腾讯科技（深圳）有限公司 | Method and apparatus for test in joint development mode |
| CN105893259A (en) * | 2016-03-31 | 2016-08-24 | 广州华多网络科技有限公司 | Code detection system, method and device |
| CN106547683A (en) * | 2015-09-22 | 2017-03-29 | 阿里巴巴集团控股有限公司 | A kind of redundant code detection method and device |
| CN107145438A (en) * | 2016-03-01 | 2017-09-08 | 阿里巴巴集团控股有限公司 | Code test method, code tester device and code tester system |
| CN107273281A (en) * | 2016-04-06 | 2017-10-20 | 阿里巴巴集团控股有限公司 | Service interface test method, system based on code change |
| CN107678773A (en) * | 2017-09-28 | 2018-02-09 | 郑州云海信息技术有限公司 | A kind of code development based on git and testing process management method |
| CN108170610A (en) * | 2018-01-17 | 2018-06-15 | 北京网信云服信息科技有限公司 | The method and apparatus for determining test coverage |
| CN108491331A (en) * | 2018-04-13 | 2018-09-04 | 平安普惠企业管理有限公司 | Method for testing software, device, equipment and computer storage media |
| CN108829580A (en) * | 2018-05-07 | 2018-11-16 | 百度在线网络技术（北京）有限公司 | Multi version test data processing method, device, equipment and storage medium |
| CN109388568A (en) * | 2018-09-29 | 2019-02-26 | 百度在线网络技术（北京）有限公司 | Code test method and device |
| CN110515827A (en) * | 2019-07-05 | 2019-11-29 | 中国平安财产保险股份有限公司 | Automated testing method, device, computer equipment and storage medium |
| CN110633208A (en) * | 2019-08-22 | 2019-12-31 | 浙江大搜车软件技术有限公司 | Incremental code coverage rate testing method and system |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9619375B2 (en) * | 2014-05-23 | 2017-04-11 | Carnegie Mellon University | Methods and systems for automatically testing software |
| US10296446B2 (en) * | 2015-11-18 | 2019-05-21 | International Business Machines Corporation | Proactive and selective regression testing based on historic test results |
-
2020
- 2020-04-15 CN CN202010296161.5A patent/CN113535533B/en active Active
Patent Citations (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105095059A (en) * | 2014-04-15 | 2015-11-25 | 阿里巴巴集团控股有限公司 | Method and device for automated testing |
| CN105302716A (en) * | 2014-07-30 | 2016-02-03 | 腾讯科技（深圳）有限公司 | Method and apparatus for test in joint development mode |
| CN106547683A (en) * | 2015-09-22 | 2017-03-29 | 阿里巴巴集团控股有限公司 | A kind of redundant code detection method and device |
| CN107145438A (en) * | 2016-03-01 | 2017-09-08 | 阿里巴巴集团控股有限公司 | Code test method, code tester device and code tester system |
| CN105893259A (en) * | 2016-03-31 | 2016-08-24 | 广州华多网络科技有限公司 | Code detection system, method and device |
| CN107273281A (en) * | 2016-04-06 | 2017-10-20 | 阿里巴巴集团控股有限公司 | Service interface test method, system based on code change |
| CN107678773A (en) * | 2017-09-28 | 2018-02-09 | 郑州云海信息技术有限公司 | A kind of code development based on git and testing process management method |
| CN108170610A (en) * | 2018-01-17 | 2018-06-15 | 北京网信云服信息科技有限公司 | The method and apparatus for determining test coverage |
| CN108491331A (en) * | 2018-04-13 | 2018-09-04 | 平安普惠企业管理有限公司 | Method for testing software, device, equipment and computer storage media |
| CN108829580A (en) * | 2018-05-07 | 2018-11-16 | 百度在线网络技术（北京）有限公司 | Multi version test data processing method, device, equipment and storage medium |
| CN109388568A (en) * | 2018-09-29 | 2019-02-26 | 百度在线网络技术（北京）有限公司 | Code test method and device |
| CN110515827A (en) * | 2019-07-05 | 2019-11-29 | 中国平安财产保险股份有限公司 | Automated testing method, device, computer equipment and storage medium |
| CN110633208A (en) * | 2019-08-22 | 2019-12-31 | 浙江大搜车软件技术有限公司 | Incremental code coverage rate testing method and system |
Non-Patent Citations (2)
| Title |
|---|
| 代码覆盖率驱动的测试用例管理系统的设计与实现;褚悦;《中国优秀硕士学位论文全文数据库 信息科技辑》;20180415(第04期);I138-460 * |
| 白盒测试中源代码变更管理方法的研究与实现;柳永坡 等;《计算机工程与应用》;20090221;第45卷(第06期);85-88 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113535533A (en) | 2021-10-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP4006731B1 (en) | Method, apparatus, device, storage medium and computer program product for testing code | |
| KR102493449B1 (en) | Edge computing test methods, devices, electronic devices and computer-readable media | |
| CN110765024B (en) | Simulation test method, simulation test device, electronic equipment and computer readable storage medium | |
| EP3859533A2 (en) | Method and apparatus for testing map service, electronic device, storage medium and computer program product | |
| CN112306880A (en) | Test method, apparatus, electronic device, and computer-readable storage medium | |
| US8683449B2 (en) | Automated parallel software code impact analysis | |
| CN113778486B (en) | Method, device, medium and equipment for containerization processing of code pipeline | |
| US12174732B2 (en) | Regression testing on deployment pipelines | |
| EP4075283A1 (en) | Method and apparatus for continuous integration testing | |
| CN111752843A (en) | Method, device, electronic equipment and readable storage medium for determining influence surface | |
| CN111666217B (en) | Method and apparatus for testing code | |
| CN111309343A (en) | Development deployment method and device | |
| CN111913707A (en) | Running process multiplexing method and device | |
| CN111966361A (en) | Method, device and equipment for determining model to be deployed and storage medium thereof | |
| CN114721686A (en) | Configuration data updating method and device, electronic equipment and storage medium | |
| US20230153229A1 (en) | Method of testing performance, electronic device, and computer-readable medium | |
| CN117149406A (en) | Resource scheduling method, device, system, computer equipment and storage medium | |
| CN113535533B (en) | Method, apparatus, device and storage medium for testing code | |
| CN114416578A (en) | Test method and apparatus | |
| CN113220586A (en) | Automatic interface pressure test execution method, device and system | |
| CN111582476A (en) | Automatic quantitative strategy search method, device, device and storage medium | |
| CN113297088B (en) | Test methods, test devices, electronic equipment and storage media | |
| CN116248526A (en) | Method and device for deploying container platform and electronic equipment | |
| CN112099954A (en) | Method, device, equipment and storage medium for deploying and downloading resources | |
| US11163667B2 (en) | Method and apparatus for error ticket management |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |