CN116662210B - An interface regression testing method, device and application - Google Patents

Abstract

The application provides an interface regression testing method, device and application, which comprises the following steps: acquiring a tested interface and assigning a unique interface number, determining a test point, dividing a test scene and assigning a unique scene number; writing at least one test case, and naming each test case; and carrying out primary regression testing by using all the test cases, repairing failed test cases, and carrying out secondary regression testing by using the repaired failed test cases and the test cases associated with the failed test cases until all the tests are passed, wherein the associated test cases are obtained by naming each test case. According to the scheme, the test cases needing secondary regression are screened through the naming of each test case to carry out secondary test, so that basis is provided for interface regression, and screening time is shortened to save interface regression test time.

Description

An interface regression testing method, device and application

Technical field

This application relates to the field of interface testing, and in particular to an interface regression testing method, device and application.

Background technique

Interface test cases are test cases specifically used to test the interface functions of software systems. In software development, interfaces are the key points for data exchange and communication between different modules, components or systems. Interface test cases are designed to verify the interface. Correctness, reliability and stability to ensure that each component can correctly transmit and interact with data.

Interface regression testing is a software testing method used to verify whether the modified or updated software interface still works as expected and does not destroy existing functions. Performing interface regression testing can ensure the stability and compatibility of the software at the interface level. stability and reduce the risk of introducing new problems after modifying or updating the interface.

There are many subjective factors in existing interface regression testing, and there is a lack of unified methods, which can easily cause defects to escape. It is particularly important to use tested cases to achieve limits when defect regression is performed. Currently, most interface regression tests The method adopted is to re-execute the test cases when the defect was discovered, and then conduct artificial and subjective verification and screening to believe that there may be other problems caused by modifying the defective test cases. This method causes inconsistencies in regression. Certainty and great subjectivity, there are large differences in accuracy depending on the experience level of the tester.

Therefore, there is an urgent need for an interface regression testing method that can improve the accuracy of interface regression testing and consume less time.

Contents of the invention

The embodiments of this application provide an interface regression testing method, device and application. The test cases that require secondary regression are screened by naming each test case for secondary testing to provide a basis for interface regression, and discarded during the test process. Low priority test cases to save time in interface regression testing.

In a first aspect, embodiments of this application provide an interface regression testing method, which method includes:

Obtain at least one tested interface, set a different interface number for each tested interface, obtain test points of all tested interfaces, divide different test scenarios according to the test points, and set different scenarios for each test scenario Number, write at least one test case, and name each test case according to the interface number of the tested interface to which each test case belongs, the scene number of the scene to which it belongs, and its own category;

Obtain failed test cases during a regression test, select and change the reference test cases that will be affected by the failed test cases based on the interface number, scenario number and own category in the failed test case naming;

Use the repaired failed test cases and conduct secondary regression testing with the reference test cases until all test cases pass.

In the second aspect, embodiments of the present application provide an interface regression testing device, including:

Setting module: obtain at least one tested interface, and set different interface numbers for each tested interface, obtain test points of all tested interfaces, divide different test scenarios according to the test points, and set different test scenarios for each test scenario. Write at least one test case for different scenario numbers, and name each test case according to the interface number of the tested interface to which each test case belongs, the scenario number of the scenario to which it belongs, and its own category;

Acquisition module: Obtain failed test cases during a regression test, and select and change the reference test cases that will be affected by the failed test cases based on the interface number, scenario number and own category in the naming of the failed test cases;

Regression testing module: Use the repaired failed test cases and perform secondary regression testing with the reference test cases until all test cases pass.

In a third aspect, embodiments of the present application provide an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to run the computer program to perform an interface regression test. method.

In a fourth aspect, embodiments of the present application provide a readable storage medium. A computer program is stored in the readable storage medium. The computer program includes program code for controlling a process to execute the process. The process includes a An interface regression testing method.

The main contributions and innovations of the present invention are as follows:

The embodiment of this application names the test cases through the interface number and scene number, and during the secondary regression, the test cases that need to be subjected to the secondary regression are screened according to the naming of the test cases, which can provide a basis for the interface regression and ensure the accuracy of the regression test. Accuracy; this solution sets different priorities for each test case to further screen failed test cases and test cases associated with failed test cases to save time in interface testing; this solution is used for secondary testing During regression, not only the failed test cases are tested, but also other test cases related to the failed test cases are regressed twice, which improves the stability of the interface test.

The details of one or more embodiments of the present application are set forth in the following drawings and description to make other features, objects, and advantages of the present application more concise and understandable.

Description of the drawings

The drawings described here are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation of the present application. In the attached picture:

Figure 1 is a flow chart of an interface regression testing method according to an embodiment of the present application;

Figure 2 is a flow chart for generating test cases according to an embodiment of the present application;

Figure 3 is a schematic diagram of generating a path class test case according to an embodiment of the present application;

Figure 4 is a flow chart for interface regression testing according to an embodiment of the present application;

Figure 5 is a structural block diagram of an interface regression testing device according to an embodiment of the present application;

FIG. 6 is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present application.

Detailed ways

Exemplary embodiments will be described in detail herein, examples of which are illustrated in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings refer to the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatus and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, methods may include more or fewer steps than described in this specification. In addition, a single step described in this specification may be broken down into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step in other embodiments. describe.

Embodiment 1

The embodiment of the present application provides an interface regression testing method. Specifically, referring to Figure 1, the method includes:

Obtain at least one tested interface, set a different interface number for each tested interface, obtain test points of all tested interfaces, divide different test scenarios according to the test points, and set different scenarios for each test scenario Number, write at least one test case, and name each test case according to the interface number of the tested interface to which each test case belongs, the scene number of the scene to which it belongs, and its own category;

Obtain failed test cases during a regression test, select and change the reference test cases that will be affected by the failed test cases based on the interface number, scenario number and own category in the failed test case naming;

Use the repaired failed test cases and conduct secondary regression testing with the reference test cases until all test cases pass.

In some embodiments, in the step of "obtaining the test points of all tested interfaces and dividing different test scenarios according to the test points", each interface has multiple different test points, and each test point can be divided simultaneously into different test scenarios.

Specifically, list all test points of each interface under test. The test points refer to the specific functions, behaviors or conditions of the interface under test. They are the targets of testing and are used to check whether the interface works as expected.

For example, test points may include input data, boundary conditions, exceptions, interaction logic, etc.

In some embodiments, each test case is assigned a different priority from high to low according to the extent to which it affects the business functions of the core business. The priority is divided into high priority, medium priority and low priority. level, the high-priority test cases are test cases that affect core business, the medium-priority test cases are test cases that affect functional correctness, and the low-priority test cases are test cases that do not constitute a substantial contribution to business functions. Test cases that have a negative impact or have a slight impact but do not affect business operations.

Specifically, setting the priority for each test case can fix problems according to the priority in subsequent regression testing and reduce the time required for regression testing.

In some embodiments, the categories of the test cases are divided into logical categories, fault-tolerant categories, and path categories. Logical test cases refer to test cases for testing the logical functions of the software or system, and fault-tolerant test cases are used to test the logical functions of the software or system. Test cases are used to test the behavior and reaction of a system or software in the event of a fault or error. Path test cases are test cases designed based on different paths and execution logic of the software or system.

In this solution, the number a represents the logical test case, the number b represents the fault-tolerant test case, and the number c represents the path test case. Therefore, the naming format of each test case in this program is xx-scenario number-interface Number-a/b/c-xx, xx represents other coding elements. The flow chart of generating test cases is shown in Figure 2.

For example, the logical interface use case in this solution usually indicates that an interface can return the expected correct information after passing various legal parameters according to the established parameter transmission requirements.

The fault-tolerant interface use cases in this solution usually represent various possible situations when an interface passes parameters according to abnormal logic (null values, non-specified parameter types, etc.), and the interface is required to handle them correctly and give prompts without exceptions.

The interface use case of the path class in this solution usually means that after an interface passes parameters and gets the returned value, the value is used by the downstream interface when passing parameters, or the generated value is stored in the database and is processed and returned by the downstream interface. The downstream interface After using this parameter value, the service is correct. It is also possible that the parameter value of this interface also comes from the upstream interface. This situation belongs to the path class. For example, as shown in Figure 3, there are n segments of paths a and b connected to each other in the same scenario. , c, d, e, you can generate tests with different paths, such as start>a+b+c>end1, start>a+b+d>end2, start>a+e>end2, etc.

Specifically, each test case is named to provide a basis for subsequent interface regression testing.

In some embodiments, low-priority failed test cases are excluded from a regression test.

Specifically, during the regression testing process, fixing a problem is likely to lead to the emergence of another bigger problem. Since low-priority test cases do not have a substantial impact on business functions, during a regression test Save time in interface testing by excluding low-priority failing test cases.

In some embodiments, in the step of "using the repaired failed test cases and performing secondary regression testing with the reference test cases until all test cases pass", if the failed test cases are logical test cases, then based on the failure The test case naming extracts all path class test cases with the same scenario number as the failed test case and all logic class test cases with the same scenario number and the same interface number as reference test cases.

Specifically, since modifying logical test cases may affect the upstream and downstream access to the interface, it is necessary to conduct secondary regression testing on all path test cases in the same scenario to prevent more problems.

In some embodiments, in the step of "using the repaired failed test cases and performing a secondary regression test with the reference test cases until all test cases pass", if the failed test cases are fault-tolerant test cases, then based on the failure The test case naming extracts all path-type test cases with the same scenario number as the failed test case and all fault-tolerance type test cases with the same scenario number and the same interface number as reference test cases.

Specifically, since modifying the fault-tolerant test cases will affect the upstream and downstream access to the interface, it is necessary to conduct a second regression test on all path test cases in the same scenario to prevent more problems.

In some embodiments, in the step of "using the repaired failed test cases and performing secondary regression testing with the reference test cases until all test cases pass", if the failed test case is a path class test case, based on the failure The test case naming extracts all logical class test cases and all path class test cases under the same scenario number as the failed test case as reference test cases.

In some embodiments, test cases associated with failed test cases are only high-priority test cases.

Specifically, the flow chart of interface regression testing in this solution is shown in Figure 4. In order to improve the efficiency of secondary regression testing and provide regression basis for interface regression testing, the naming of test cases is used to find and There are associated test cases for failed test cases, and only high-priority test cases need to be executed.

For example, there is a defect in the import interface in a device import scenario. The interface number of the import interface is import. The defect of the import interface is roughly described as follows: This interface supports import of three device types, namely A, B, C, where an error occurred while importing type B equipment.

Obtain the test case that failed the test. The test case is roughly described as follows: when the device parameter passed is type B, fill in the other parameters and check whether the return interface is correct. It can be seen that the test case is a logical test case and belongs to the device import scenario. Then the test case name containing the interface number import, type a (logical class), and scenario number sbdr (device import scenario) is extracted and the following test case is obtained: sbxx3 -Import-a-sbdr-0014 This use case verifies the imported device type is A, sbxx-Import-a-sbdr-002 This use case verifies the imported device type is B, sbxx-Import-a-sbdr-003 This use case verifies the import The device type is C, etc. (the test cases extracted above are only examples and not exhaustive). At the same time, path class test cases must also be extracted, and the test case names include path classes and device import scenarios. For example: sbxx-null-c-sbdr- 155. This test case is used to verify that the data returned by the interface for querying the device list data on the page remains correct (this use case also belongs to the large scenario of device import sbdr. It can be understood from the page operation that after importing the device, check whether the list corresponds to the correct update display. , mainly used to verify the display of the data downstream interface after importing device type B, and can also be used to reconfirm device type A/C).

Embodiment 2

Based on the same concept, with reference to Figure 5, this application also proposes an interface regression testing device, including:

Setting module: obtain at least one tested interface, and set different interface numbers for each tested interface, obtain test points of all tested interfaces, divide different test scenarios according to the test points, and set different test scenarios for each test scenario. Write at least one test case for different scenario numbers, and name each test case according to the interface number of the tested interface to which each test case belongs, the scenario number of the scenario to which it belongs, and its own category;

Acquisition module: Obtain failed test cases during a regression test, and select and change the reference test cases that will be affected by the failed test cases based on the interface number, scenario number and own category in the naming of the failed test cases;

Regression testing module: Use the repaired failed test cases and perform secondary regression testing with the reference test cases until all test cases pass.

Embodiment 3

This embodiment also provides an electronic device. Referring to Figure 6, it includes a memory 404 and a processor 402. The memory 404 stores a computer program. The processor 402 is configured to run the computer program to perform any of the above methods. The steps in the example.

Specifically, the above-mentioned processor 402 may include a central processing unit (CPU), or an Application Specific Integrated Circuit (ASIC for short), or may be configured to implement one or more integrated circuits according to the embodiments of the present application.

Among others, memory 404 may include mass storage 404 for data or instructions. By way of example and not limitation, the memory 404 may include a hard disk drive (Hard Disk Drive, HDD for short), a floppy disk drive, a Solid State Drive (SSD for short), flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (Universal Serial Bus, Referred to as USB) drive or a combination of two or more of these. Memory 404 may include removable or non-removable (or fixed) media, where appropriate. Memory 404 may be internal or external to the data processing device, where appropriate. In certain embodiments, memory 404 is Non-Volatile memory. In a specific embodiment, the memory 404 includes read-only memory (Read-OnlyMemory, ROM for short) and random access memory (RandomAccessMemory, RAM for short). Under appropriate circumstances, the ROM can be a mask-programmed ROM, programmable ROM (ProgrammableRead-OnlyMemory, referred to as PROM), erasable PROM (ErasableProgrammableRead-OnlyMemory, referred to as EPROM), electrically erasable PROM (Electrically ErasableProgrammableRead) -OnlyMemory (EEPROM for short), Electrically Alterable Read-OnlyMemory (EAROM for short) or flash memory (FLASH) or a combination of two or more of these. Under appropriate circumstances, the RAM can be static random access memory (StaticRandom-AccessMemory, referred to as SRAM) or dynamic random access memory (DynamicRandomAccessMemory, referred to as DRAM), where DRAM can be fast page mode dynamic random access Memory 404 (FastPageModeDynamicRandomAccessMemory, referred to as FPMDRAM), extended data output dynamic random access memory (ExtendedDateOutDynamicRandomAccessMemory, referred to as EDODRAM), synchronous dynamic random access memory (SynchronousDynamicRandom-AccessMemory, referred to as SDRAM), etc.

Memory 404 may be used to store or cache various data files required for processing and/or communication, as well as possibly computer program instructions executed by processor 402.

The processor 402 reads and executes the computer program instructions stored in the memory 404 to implement any of the interface regression testing methods in the above embodiments.

Optionally, the above-mentioned electronic device may also include a transmission device 406 and an input-output device 408, wherein the transmission device 406 is connected to the above-mentioned processor 402, and the input-output device 408 is connected to the above-mentioned processor 402.

Transmission device 406 may be used to receive or send data over a network. Specific examples of the above-mentioned network may include a wired or wireless network provided by a communication provider of the electronic device. In one example, the transmission device includes a network adapter (Network Interface Controller, NIC for short), which can be connected to other network devices through a base station to communicate with the Internet. In one example, the transmission device 406 may be a radio frequency (Radio Frequency, RF for short) module, which is used to communicate with the Internet wirelessly.

Input and output devices 408 are used to input or output information. In this embodiment, the input information may be test cases, quadratic regression test cases, etc., and the output information may be test results, etc.

Optionally, in this embodiment, the above-mentioned processor 402 can be configured to perform the following steps through a computer program:

S101. Obtain at least one tested interface, set a different interface number for each tested interface, obtain test points of all tested interfaces, divide different test scenarios according to the test points, and set different test scenarios for each test scenario. Scenario number, write at least one test case, and name each test case according to the interface number of the tested interface to which each test case belongs, the scenario number of the scenario to which it belongs, and its own category;

S102. Obtain failed test cases during a regression test, and select and change the reference test cases that will be affected by the failed test cases according to the interface number, scenario number and own category in the naming of the failed test cases;

S103. Use the repaired failed test cases and conduct a second regression test with the reference test cases until all test cases pass.

It should be noted that for specific examples in this embodiment, reference may be made to the examples described in the above-mentioned embodiments and optional implementations, and the details of this embodiment will not be repeated here.

Generally, various embodiments may be implemented in hardware or special purpose circuitry, software, logic, or any combination thereof. Some aspects of the invention may be implemented in hardware, while other aspects may be implemented in firmware or software that may be executed by a controller, microprocessor or other computing device, although the invention is not limited thereto. Although various aspects of the invention may be shown and described as block diagrams, flow diagrams, or using some other graphical representation, it is to be understood that, by way of non-limiting example, the blocks, devices, systems, techniques, or methods described herein may be Hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controllers or other computing devices, or some combination thereof.

Embodiments of the invention may be implemented by computer software executable by a data processor of the mobile device, such as in a processor entity, or by hardware, or by a combination of software and hardware. Computer software or programs (also referred to as program products), including software routines, applets, and/or macros, may be stored on any device-readable data storage medium, and they include program instructions for performing specific tasks. A computer program product may include one or more computer-executable components that are configured to perform embodiments when the program is executed. One or more computer-executable components may be at least one software code or a portion thereof. Additionally, at this point, it should be noted that any block of the logic flow in Figure 6 may represent program steps, or interconnected logic circuits, blocks, and functions, or a combination of program steps and logic circuits, blocks, and functions. Software may be stored on physical media such as memory chips or memory blocks implemented within a processor, magnetic media such as hard or floppy disks, and optical media such as, for example, DVD and its data variants, CDs. Physical media are non-transient media.

Those skilled in the art should understand that the technical features of the above embodiments can be combined in any way. To simplify the description, not all possible combinations of the technical features in the above embodiments are described. However, as long as these technical features There is no contradiction in the combinations, and they should be considered to be within the scope of this manual.

The above embodiments only express several implementation modes of the present application, and their descriptions are relatively specific and detailed, but should not be construed as limiting the scope of the present application. It should be noted that, for those of ordinary skill in the art, several modifications and improvements can be made without departing from the concept of the present application, and these all fall within the protection scope of the present application. Therefore, the scope of protection of this application should be determined by the appended claims.

Claims (8)

1. An interface regression testing method, characterized by including the following steps: Obtain at least one tested interface, set a different interface number for each tested interface, obtain test points of all tested interfaces, divide different test scenarios according to the test points, and set different scenarios for each test scenario Number, write at least one test case, and name each test case according to the interface number of the tested interface to which each test case belongs, the scene number of the scene to which it belongs, and its own category; Obtain failed test cases during a regression test, select and change the reference test cases that will be affected by the failed test cases according to the interface number, scenario number and own category in the failed test case naming, and select and change the reference test cases that will be affected according to the test case itself. Categories divide test cases into logical test cases, fault-tolerant test cases and path test cases. If the failed test case is a logical test case, all test cases with the same scenario number as the failed test case will be extracted based on the failed test case name. Path class test cases and all logic class test cases with the same scene number and the same interface number are used as reference test cases; if the failed test case is a fault-tolerant test case, the test case with the same scene number as the failed test case will be extracted based on the name of the failed test case. All path test cases and all fault-tolerance test cases with the same scenario number and the same interface number are used as reference test cases; if the failed test case is a path class test case, the same scenario number as the failed test case will be extracted based on the failed test case naming All logical test cases and all path test cases under are used as reference test cases. Each test case is assigned a different priority from high to low according to the degree of impact on the business functions of the core business. The priority is Divided into high priority, medium priority and low priority; Use the repaired failed test cases and conduct secondary regression testing with the reference test cases until all test cases pass. 2. An interface regression testing method according to claim 1, characterized in that the high-priority test cases are test cases that affect core business, and the medium-priority test cases are those that affect functional correctness. Test cases, the low-priority test cases are test cases that do not have a substantial impact on business functions or have a slight impact but do not affect business development. 3. An interface regression testing method according to claim 1, characterized in that high-priority test cases are screened during secondary regression, and the test cases at this time include repaired failed test cases and selected reference tests. Example. 4. The interface regression testing method according to claim 1, characterized in that, during a regression test, low-priority failed test cases are excluded. 5. The interface regression testing method according to claim 1, characterized in that, a defective tested interface is obtained, and corresponding failed test cases are obtained according to the defects of the tested interface. 6. An interface regression testing device, characterized by including: Setting module: obtain at least one tested interface, and set different interface numbers for each tested interface, obtain test points of all tested interfaces, divide different test scenarios according to the test points, and set different test scenarios for each test scenario. Write at least one test case for different scenario numbers, and name each test case according to the interface number of the tested interface to which each test case belongs, the scenario number of the scenario to which it belongs, and its own category; Acquisition module: Obtain failed test cases during a regression test. Select and change the reference test cases that will be affected by the failed test cases according to the interface number, scenario number and own category in the failed test case naming. According to the test The test case's own category divides the test cases into logical test cases, fault-tolerant test cases and path test cases. If the failed test case is a logical test case, the same scenario as the failed test case will be extracted based on the failed test case name. All path test cases with the same number and all logical test cases with the same scene number and the same interface number are used as reference test cases; if the failed test case is a fault-tolerant test case, it will be extracted based on the failed test case naming and is the same as the failed test case. All path test cases with scenario numbers and all fault-tolerance test cases with the same scene number and interface number are used as reference test cases; if the failed test case is a path class test case, the failed test cases will be extracted based on the failed test case naming. All logical test cases and all path test cases under the same scenario number are used as reference test cases. Each test case is assigned a different priority from high to low according to the degree of impact on the business functions of the core business. Therefore, The above priorities are divided into high priority, medium priority and low priority; Regression testing module: Use the repaired failed test cases and perform secondary regression testing with the reference test cases until all test cases pass. 7. An electronic device, comprising a memory and a processor, characterized in that a computer program is stored in the memory, and the processor is configured to run the computer program to execute any one of claims 1-5. An interface regression testing method. 8. A readable storage medium, characterized in that a computer program is stored in the readable storage medium, and the computer program includes program code for controlling a process to execute a process, the process including claims 1-5 Any one of the interface regression testing methods described above.