Interface access path test method and device, computer equipment and computer readable storage medium
By generating and empowering interface access paths and iterative testing combined with test cases, the problem of low accuracy of traditional interface testing methods in complex business scenarios is solved, and more efficient interface testing and business importance assessment is achieved.
Patent Information
- Application Number
- CN202411717505.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-27
- Publication Date
- 2025-03-11
AI Technical Summary
When traditional interface testing methods test a single interface function, it is difficult to match business scenarios in complex terminal systems, resulting in a decrease in the accuracy of interface testing.
By determining the interface to be tested and generating multiple access paths between them, each path is given weights to indicate its business importance, interface testing is performed based on these weights and test cases, use case and path weights are updated, and the test is iterated until the termination condition is reached.
It improves the accuracy of interface testing, makes the test results more match complex business scenarios, and enhances the ability to evaluate the importance of interface access path business.
Smart Images
Figure CN119597666A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the technical field of software testing, and in particular to an interface access path testing method, apparatus, computer equipment, and computer-readable storage medium. Background Art
[0002] With the development of software testing technology, interface testing technology has emerged, which can be used to test interface functions.
[0003] In traditional technology, some test cases are usually input into a single interface, and the values of various fields of the results returned by the interface are used to check whether the interface functions as expected.
[0004] However, as the complexity of terminal systems continues to increase, the implementation of business functions is usually related to multiple interfaces, and the test method for testing a single interface function is usually poorly matched with the business scenario, which leads to lower accuracy of interface testing. Summary of the invention
[0005] Based on this, it is necessary to provide an interface access path testing method, apparatus, computer equipment, computer-readable storage medium and computer program product that can improve the accuracy of interface testing in order to address the above technical problems.
[0006] In a first aspect, the present application provides an interface access path testing method, comprising:
[0007] Determine each interface to be tested, and generate multiple interface access paths to be tested between each interface to be tested;
[0008] Generate a path weight corresponding to each of the access paths of the interface to be tested, wherein the path weight represents the business importance of the access path of the interface to be tested;
[0009] Interface testing step: obtaining the path weight corresponding to each of the interface access paths to be tested, and based on each of the path weights, performing interface testing using each test case and each of the interface access paths to be tested to obtain an interface testing result;
[0010] According to the interface test result, the use case weight of each of the test cases is updated, and according to the updated use case weight, the path weight is updated;
[0011] Return to execute the interface test step until the preset iterative test termination condition is reached, and use all updated path weights as interface access path test results.
[0012] In one embodiment, the interface test result includes the current use case usage frequency and test exception information; and updating the use case weight of each test case according to the interface test result includes:
[0013] For each of the test cases, according to the current test case usage frequency and the test exception information, update the test case weight of the test case in the current iterative test round;
[0014] Detecting at least one associated test case associated with the test case, and obtaining an updated case weight of the current iterative test round corresponding to each of the associated test cases;
[0015] Aggregate the updated case weights of the current iterative test round corresponding to each of the associated test cases to obtain the case weights of the test cases in the next iterative test round.
[0016] In one embodiment, updating the use case weight of the test case in the current iterative test round according to the use frequency of the current use case and the test exception information includes:
[0017] For each of the test cases, if the current test case usage frequency of the test case is greater than the previous test case usage frequency, then increasing the test case weight of the test case in the current iterative test round;
[0018] If the current test case usage frequency of the test case is less than the previous test case usage frequency, reducing the test case weight of the test case in the current iterative test round;
[0019] If the test exception information indicates that a test exception occurs in the test case, the test case weight of the test case in the current iterative test round is increased.
[0020] In one embodiment, updating each of the path weights according to the updated use case weights includes:
[0021] For each of the interface access paths to be tested, determining a plurality of target test interfaces corresponding to the interface access path to be tested;
[0022] Determine the target test case corresponding to each of the target test interfaces according to the corresponding relationship between the interfaces to be tested and the test cases to be tested;
[0023] Aggregating the case weights of each target test case in the next iterative test round to obtain an aggregated weight;
[0024] The aggregation weight is normalized to obtain an updated path weight.
[0025] In one embodiment, the performing of interface testing based on each of the path weights and using each of the test cases and each of the interface access paths to be tested includes:
[0026] Based on each of the path weights, generating a path test frequency of each of the interface access paths to be tested;
[0027] According to the test frequency of each path, each test case is called, and the interface test is performed according to each interface access path to be tested.
[0028] In one embodiment, the generating a plurality of interface access paths to be tested between the interfaces to be tested includes:
[0029] Enumerate the access paths between the interfaces to be tested to obtain a full set of interface access paths;
[0030] Performing feasibility verification on each interface access path in the full set of interface access paths to obtain a feasibility verification result;
[0031] According to the feasibility verification result, unexecutable interface access paths are eliminated from the full set of interface access paths to obtain multiple initial test interface access paths;
[0032] Repetitive paths and loop paths are eliminated from the multiple initial test interface access paths to obtain multiple interface access paths to be tested.
[0033] In one of the embodiments, after calling each of the test cases according to the path test frequency and performing interface testing according to each of the interface access paths to be tested, the method further includes:
[0034] If there is a failed test case that failed the test, import the failed test case into the retry test case set;
[0035] Retesting step: calling the failed test cases in the retry test case set according to the test frequency of each path, and performing interface testing according to each interface access path to be tested;
[0036] If the failed test case is successfully retested, removing the failed test case from the retry test case set;
[0037] If the failed test case fails in retesting, detecting the number of test failures of the failed test case in which the retesting fails;
[0038] If the number of test failures is greater than a preset number threshold, the failed test case is marked as a final failure case, and the final failure case is removed from the retry test case set;
[0039] Return to execute the retest step until the retry test case set is empty.
[0040] In a second aspect, the present application also provides an interface access path testing device, including:
[0041] A path generation module, used to determine each interface to be tested, and generate multiple interface access paths to be tested between each interface to be tested;
[0042] A weight generating module, used to generate a path weight corresponding to each of the access paths of the interface to be tested, wherein the path weight represents the business importance of the access path of the interface to be tested;
[0043] The interface test module is used for the interface test step: obtaining the case weight corresponding to each test case, and based on each path weight, performing interface test using each test case and each interface access path to be tested to obtain an interface test result;
[0044] A weight updating module, used to update the use case weight of each of the test cases according to the interface test result, and update the weight of each of the paths according to the updated use case weight;
[0045] The test result generating module is used to return to execute the interface test step until a preset iterative test termination condition is reached, and all updated path weights are used as interface access path test results.
[0046] In one embodiment, the interface test result includes the usage frequency of the current use case and test exception information; the weight updating module is further used to:
[0047] For each of the test cases, according to the current test case usage frequency and the test exception information, update the test case weight of the test case in the current iterative test round;
[0048] Detecting at least one associated test case associated with the test case, and obtaining an updated case weight of the current iterative test round corresponding to each of the associated test cases;
[0049] Aggregate the updated case weights of the current iterative test round corresponding to each of the associated test cases to obtain the case weights of the test cases in the next iterative test round.
[0050] In one embodiment, the weight updating module is further used for:
[0051] For each of the test cases, if the current test case usage frequency of the test case is greater than the previous test case usage frequency, then increasing the test case weight of the test case in the current iterative test round;
[0052] If the current test case usage frequency of the test case is less than the previous test case usage frequency, reducing the test case weight of the test case in the current iterative test round;
[0053] If the test exception information indicates that a test exception occurs in the test case, the test case weight of the test case in the current iterative test round is increased.
[0054] In one embodiment, the weight updating module is further used for:
[0055] For each of the interface access paths to be tested, determining a plurality of target test interfaces corresponding to the interface access path to be tested;
[0056] Determine the target test case corresponding to each of the target test interfaces according to the corresponding relationship between the interfaces to be tested and the test cases to be tested;
[0057] Aggregating the case weights of each target test case in the next iterative test round to obtain an aggregated weight;
[0058] The aggregation weight is normalized to obtain an updated path weight.
[0059] In one embodiment, the interface testing module is further used for:
[0060] Based on each of the path weights, generating a path test frequency of each of the interface access paths to be tested;
[0061] According to the test frequency of each path, each test case is called, and the interface test is performed according to each interface access path to be tested.
[0062] In one embodiment, the path generation module is further used to:
[0063] Enumerate the access paths between the interfaces to be tested to obtain a full set of interface access paths;
[0064] Performing feasibility verification on each interface access path in the full set of interface access paths to obtain a feasibility verification result;
[0065] According to the feasibility verification result, unexecutable interface access paths are eliminated from the full set of interface access paths to obtain multiple initial test interface access paths;
[0066] Repetitive paths and loop paths are eliminated from the multiple initial test interface access paths to obtain multiple interface access paths to be tested.
[0067] In one embodiment, the interface testing module is further used for:
[0068] If there is a failed test case that failed the test, import the failed test case into the retry test case set;
[0069] Retesting step: calling the failed test cases in the retry test case set according to the test frequency of each path, and performing interface testing according to each interface access path to be tested;
[0070] If the failed test case is successfully retested, removing the failed test case from the retry test case set;
[0071] If the failed test case fails in retesting, detecting the number of test failures of the failed test case in which the retesting fails;
[0072] If the number of test failures is greater than a preset number threshold, the failed test case is marked as a final failure case, and the final failure case is removed from the retry test case set;
[0073] Return to execute the retest step until the retry test case set is empty.
[0074] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:
[0075] Determine each interface to be tested, and generate multiple interface access paths to be tested between each interface to be tested; generate a path weight corresponding to each interface access path to be tested, wherein the path weight represents the business importance of the interface access path to be tested; interface testing step: obtain the path weight corresponding to each interface access path to be tested, and based on each path weight, perform interface testing using each test case and each interface access path to be tested to obtain an interface test result; according to the interface test result, update the use case weight of each test case, and update each path weight according to the updated use case weight; return to execute the interface testing step until the preset iterative test termination condition is reached, and use all updated path weights as the interface access path test result.
[0076] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the following steps are implemented:
[0077] Determine each interface to be tested, and generate multiple interface access paths to be tested between each interface to be tested; generate a path weight corresponding to each interface access path to be tested, wherein the path weight represents the business importance of the interface access path to be tested; interface testing step: obtain the path weight corresponding to each interface access path to be tested, and based on each path weight, perform interface testing using each test case and each interface access path to be tested to obtain an interface test result; according to the interface test result, update the use case weight of each test case, and update each path weight according to the updated use case weight; return to execute the interface testing step until the preset iterative test termination condition is reached, and use all updated path weights as the interface access path test result.
[0078] In a fifth aspect, the present application further provides a computer program product, including a computer program, which implements the following steps when executed by a processor:
[0079] Determine each interface to be tested, and generate multiple interface access paths to be tested between each interface to be tested; generate a path weight corresponding to each interface access path to be tested, wherein the path weight represents the business importance of the interface access path to be tested; interface testing step: obtain the path weight corresponding to each interface access path to be tested, and based on each path weight, perform interface testing using each test case and each interface access path to be tested to obtain an interface test result; according to the interface test result, update the use case weight of each test case, and update each path weight according to the updated use case weight; return to execute the interface testing step until the preset iterative test termination condition is reached, and use all updated path weights as the interface access path test result.
[0080] The above-mentioned interface access path testing method, device, computer equipment and computer-readable storage medium first determine each interface to be tested, and generate multiple interface access paths to be tested between each interface to be tested, and then generate a path weight corresponding to each interface access path to be tested, wherein the path weight represents the business importance of the interface access path to be tested, and execute the interface testing step: obtain the path weight corresponding to each interface access path to be tested, based on each of the path weights, use each test case and each interface access path to be tested to perform interface testing, and obtain the interface testing result, thereby achieving the purpose of performing interface testing based on the interface access path, and then perform the case weight of each test case according to the interface testing result. Update, and update each path weight according to the updated use case weight, and return to execute the interface test step until the preset iterative test termination condition is reached. In this way, the purpose of testing the path weight of each interface access path to be tested is achieved by continuously iterating the interface access path test, and then all updated path weights are used as the interface access path test results. Since the path weight represents the business importance of the interface access path to be tested, it is achieved to test the business importance of the interface access path in an iterative testing manner. The interface access path testing method in this application has a higher match between the implementation of business functions and business scenarios related to multiple interfaces, so the accuracy of the interface test can be improved. BRIEF DESCRIPTION OF THE DRAWINGS
[0081] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.
[0082] Figure 1 A flowchart of an interface access path testing method in one embodiment of the present application;
[0083] Figure 2 A schematic diagram of a flow chart for updating the test case weights of each test case in one embodiment of the present application;
[0084] Figure 3 This is a structural block diagram of an interface access path testing device in one embodiment of the present application;
[0085] Figure 4 This is a diagram of the internal structure of a computer device in one embodiment of the present application. DETAILED DESCRIPTION
[0086] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.
[0087] In an exemplary embodiment, Figure 1 As shown, a method for testing an interface access path is provided, including the following steps 202 to 210. Among them:
[0088] Step 202: determine each interface to be tested, and generate multiple interface access paths to be tested between each interface to be tested.
[0089] In this embodiment, the interface access path testing method is applied to a terminal system, which may be a computer system or a mobile terminal system, and is not limited here.
[0090] It should be noted that after receiving an access request, in order to respond to the access request, the terminal system usually needs to access multiple interfaces in sequence based on the access request, thereby generating a request response result corresponding to the access request, and these accessed interfaces are arranged in sequence according to the access order to form an interface access path.
[0091] As an example, step 202 includes: determining each interface to be tested, and performing exhaustive enumeration among each interface path to be received to obtain multiple interface access paths to be tested.
[0092] In one embodiment, generating multiple interface access paths to be tested between interfaces to be tested includes:
[0093] The access paths between the interfaces to be tested are exhaustively enumerated to obtain a full set of interface access paths; the feasibility of each interface access path in the full set of interface access paths is verified to obtain a feasibility verification result; based on the feasibility verification result, unexecutable interface access paths are eliminated from the full set of interface access paths to obtain multiple initial test interface access paths; duplicate paths and loop paths are eliminated from the multiple initial test interface access paths to obtain multiple interface access paths to be tested.
[0094] The loop path is an interface access path that forms a closed loop. At this time, the service request is continuously called between the interfaces of the loop path, forming a closed loop, and the request response result cannot be output.
[0095] Specifically, the access paths between the interfaces to be tested are exhaustively enumerated to obtain a full set of interface access paths; for each interface access path in the full set of interface access paths, a test case is called to test the interface access path to obtain a test result; according to the field value in the test result, whether the interface access path is executable is detected to obtain a feasibility verification result; according to the feasibility verification result, the non-executable interface access paths in the full set of interface access paths are eliminated, and the remaining multiple interface access paths in the full set of interface access paths are used as initial test interface access paths; duplicate paths and loop paths are eliminated from the multiple initial test interface access paths, and the remaining multiple initial test interface access paths are used as the interface access paths to be tested. In this embodiment, when generating multiple interface access paths to be tested, non-executable interface access paths, duplicate paths and loop paths are eliminated, which reduces the order of magnitude of the generated interface access paths to be tested, helps to improve the efficiency of the interface access path test, and reduces the adverse effects of non-executable interface access paths, duplicate paths and loop paths on the interface access path test, which helps to improve the accuracy of the interface access path test.
[0096] Step 204: Generate a path weight corresponding to each interface access path to be tested, wherein the path weight represents the service importance of the interface access path to be tested.
[0097] As an example, step 204 includes: in response to the weight assignment instruction, assigning initial weights to each interface access path to be tested, and obtaining path weights corresponding to each tested interface access path. The initial path weights can be marked by the tester according to experience.
[0098] As an example, step 204 also includes: for each interface access path to be tested, obtaining the number of key interfaces in the interface access path to be tested and the historical call frequency of each interface to be tested, and assigning a path weight to the interface access path to be tested according to the number of interfaces and the historical call frequency of each interface to be tested. The higher the number of key interfaces, the higher the path weight, and the higher the historical call frequency, the higher the path weight. The key interface can be an interface with a key label, and the key label indicates that the importance of the interface to be tested is high.
[0099] As an example, the path weight may be set between 0 and 1 to avoid a large difference between the path weights of different interface paths to be tested, thereby preventing an avalanche effect from occurring. This helps improve the accuracy of the interface access path test.
[0100] Step 206, interface testing step: obtaining the path weight corresponding to each interface access path to be tested, and based on each path weight, performing interface testing using each test case and each interface access path to be tested to obtain an interface testing result.
[0101] Among them, the path weight represents the business importance of the interface access path to be tested. The higher the path weight, the higher the business importance of the interface access path to be tested. At this time, more test resources should be invested in the interface access path to be tested; the lower the path weight, the lower the business importance of the interface access path to be tested. At this time, fewer test resources should be invested in the interface access path to be tested.
[0102] It should be noted that the way to invest more testing resources is to increase the calling frequency of the interface access path to be tested or increase the number of test cases invested in the interface access path to be tested during the interface access path testing process; the way to invest fewer testing resources is to reduce the calling frequency of the interface access path to be tested or reduce the number of test cases invested in the interface access path to be tested during the interface access path testing process.
[0103] As an example, in this embodiment, interface path testing can be performed based on the unittest framework of Python, and data-driven testing can be implemented based on Python DDT.
[0104] As an example, step 206 includes: obtaining the path weight corresponding to each interface access path to be tested, and calling each test case and each interface access path to be tested to perform interface testing according to the number of use cases invested and the path calling frequency corresponding to each path weight, to obtain the interface test results.
[0105] In one embodiment, based on each path weight, interface testing is performed using each test case and each interface access path to be tested, including:
[0106] Based on the weight of each path, a path test frequency of each interface access path to be tested is generated; according to each path test frequency, each test case is called, and interface testing is performed according to each interface access path to be tested.
[0107] Specifically, based on the weight of each path, a path test frequency of each interface access path to be tested is generated, wherein the higher the path weight, the higher the path test frequency; the number of path tests of each interface access path to be tested is determined according to the path test frequency, and according to the number of path tests, each test case is called, and interface testing is performed according to the interface call order corresponding to each interface access path to be tested.
[0108] Step 208: Update the use case weight of each test case according to the interface test result, and update each path weight according to the updated use case weight.
[0109] Among them, in this embodiment, a corresponding use case weight is set for each test case. The higher the use case frequency of the test case, the higher the use case weight of the test case can be set; the higher the number of test exceptions that occur in the test case, the higher the use case weight of the test case can be set.
[0110] As an example, step 208 includes: according to the interface test results, counting the use case frequency and test exception frequency of each test case; updating the use case weight of each test case according to the use case frequency and test exception frequency of each test case; for each interface access path to be tested, aggregating the updated use case weights corresponding to each interface to be tested in the interface access path to be tested to obtain an updated path weight.
[0111] In one embodiment, updating each path weight according to the updated use case weight includes:
[0112] For each access path of the interface to be tested, determine multiple target test interfaces corresponding to the access path of the interface to be tested; determine the target test case corresponding to each target test interface based on the correspondence between the interface to be tested and the test case; aggregate the case weights of each target test case in the next iterative test round to obtain the aggregate weight; normalize the aggregate weight to obtain the updated path weight.
[0113] Among them, the use case weight of the next iterative test round is the updated use case weight.
[0114] Specifically, for each access path of the interface to be tested, multiple target test interfaces corresponding to the access path of the interface to be tested are determined; according to the corresponding relationship between the interface to be tested and the test case to be tested, the target test case corresponding to each target test interface is determined; the case weights of all target test cases in the next iterative test round are superimposed, and the superposition result is the aggregate weight; the aggregate weight is normalized to a preset value interval to obtain an updated path weight, wherein the preset value interval can be 0 to 1. In this way, the present embodiment realizes the real-time update of the path weight according to the interface test results, so that the path weight can be continuously iterated and updated until it is optimal during the subsequent iterative test process, thereby ensuring the accuracy of the path weight, that is, ensuring the accuracy of the interface access path test, and each time the path weight is updated in the present embodiment, the path weight is normalized, which can avoid the gap between the path weights of different interface paths to be tested being too large, thereby avoiding the avalanche effect, thereby further improving the accuracy of the interface access path test.
[0115] Step 210, returning to the interface test step, until the preset iterative test termination condition is reached, and taking all updated path weights as the interface access path test results.
[0116] The preset iterative test termination condition may be that a maximum preset number of iterative tests is reached, or that the update change amplitude of all path weights during the iterative test process is less than a preset amplitude threshold.
[0117] It should be noted that after obtaining the path weight of each interface access path to be tested, the path weight can be used to indicate the alarm level setting or the monitoring level setting, etc. For example, for an interface access path with a high path weight, when an abnormality occurs, the abnormal alarm level can be set higher; for an interface access path with a low path weight, when an abnormality occurs, the abnormal alarm level can be set lower; for another example, for an interface access path with a high path weight, the monitoring level can be set higher; for an interface access path with a low path weight, the monitoring level can be set lower.
[0118] In this embodiment, each interface to be tested is first determined, and multiple interface access paths to be tested between each interface to be tested are generated, and then path weights corresponding to each interface access path to be tested are generated, wherein the path weight represents the business importance of the interface access path to be tested, and an interface test step is performed: the path weight corresponding to each interface access path to be tested is obtained, and based on each path weight, interface testing is performed using each test case and each interface access path to be tested to obtain an interface test result, thereby achieving the purpose of performing interface testing based on the interface access path, and then according to the interface test result, the use case weight of each test case is updated, and according to the updated use case weight, each path weight is updated, and the interface test step is returned to perform until the preset iterative test termination condition is reached, thereby achieving the purpose of testing the path weights of each interface access path to be tested by continuously iterating the interface access path test, and then all updated path weights are used as the interface access path test result. Since the path weight represents the business importance of the interface access path to be tested, the business importance of the interface access path is tested in an iterative test manner. In this embodiment, the interface access path test method has a higher matching degree with the implementation of business functions and business scenarios related to multiple interfaces, so the accuracy of the interface test can be improved.
[0119] In one embodiment, referring to Figure 2 The interface test results include the current use case usage frequency and test exception information; according to the interface test results, the use case weight of each test case is updated, including:
[0120] Step 302: for each test case, update the test case weight of the test case in the current iteration test round according to the current test case usage frequency and test exception information.
[0121] The test exception information may be the test exception frequency of the test case in the current iterative test round, that is, the number of test exceptions; the current test case usage frequency may be the test case usage frequency of the test case in the current iterative test round.
[0122] As an example, assuming that a test case includes a parent case and multiple child cases, the case weight of the test case is a weight vector composed of the case weight of the parent case and the case weights of multiple child cases. For example, the case weight of the test case can be set to ,in, is the use case weight of the parent use case, , ,..., The use case weights for multiple sub-use cases.
[0123] As an example, step 302 includes: for each test case, if the current use case usage frequency is greater than the first preset frequency threshold or the test exception frequency is greater than the second preset frequency threshold, then the use case weight of the test case in the current iterative test round is increased; if the current use case usage frequency is less than or equal to the first preset frequency threshold and the test exception frequency is less than or equal to the second preset frequency threshold, then the use case weight of the test case in the current iterative test round is reduced.
[0124] In one embodiment, based on the current use case usage frequency and test exception information, updating the use case weight of the test case in the current iteration test round includes:
[0125] For each test case, if the current use frequency of the test case is greater than the previous use frequency, the use case weight of the test case in the current iteration test round is increased; if the current use frequency of the test case is less than the previous use frequency, the use case weight of the test case in the current iteration test round is reduced; if the test exception information indicates that the test case has a test exception, the use case weight of the test case in the current iteration test round is increased. In this way, by detecting the use frequency and test exception information of the test case in each round of iterative testing, the use case weight of each test case is updated in real time, laying the foundation for updating the path weight of the access path to be tested.
[0126] The test exception information may also be information indicating whether a test exception occurs in the test case during the current iterative test process.
[0127] Step 304: Detect at least one associated test case associated with the test case, and obtain the updated case weight of the current iterative test round corresponding to each associated test case.
[0128] Step 306 , aggregate the updated case weights of the current iterative test round corresponding to each associated test case to obtain the case weights of the test case in the next iterative test round.
[0129] Among them, in the access path of the interface to be tested, the test cases corresponding to two adjacent interfaces to be tested are mutually related test cases.
[0130] As an example, steps 304 to 306 include: for each test case, detecting the adjacent test interface of the interface to be tested where the test case is located in at least one access path of the interface to be tested, taking the test case corresponding to the adjacent test interface as the associated test case of the test case, and obtaining the updated case weight of the current iterative test round corresponding to each associated test case; taking the weighted average of the updated case weights of the current iterative test round of the associated test cases corresponding to the test case, to obtain the case weight of the test case in the next iterative test round.
[0131] In the above embodiment, after updating the use case weight of each test case based on the interface test results, the updated use case weights of the current iteration test round of multiple associated test cases corresponding to each test case are aggregated into the use case weight of the test case in the next iteration test round. In this way, the use case weight of each test case is updated based on the interface test results, taking into account the association relationship between test cases. The update strategy of the use case weight is more reasonable and comprehensive, which can improve the update accuracy of the use case weight and lay a foundation for improving the accuracy of the interface access path test.
[0132] In one embodiment, after calling each test case according to the test frequency of each path and performing interface test according to each interface access path to be tested, the method further includes:
[0133] If there are failed test cases that have failed the test, the failed test cases will be imported into the retry test case set; retest step: according to the test frequency of each path, call the failed test cases in the retry test case set, and perform interface testing according to the access path of each interface to be tested; if the failed test case is successfully retested, remove the failed test case from the retry test case set; if the failed test case fails in retesting, detect the number of test failures of the failed test case in the retest; if the number of test failures is greater than the preset threshold, mark the failed test case as the final failed case, and remove the final failed case from the retry test case set; return to execute the retest step until the retry test case set is empty.
[0134] Specifically, if there are failed test cases that have failed the test, the failed test cases are imported into the retry test case set; retest step: according to the test frequency of each path, determine the test call times of the failed test cases in the retry test case set, wherein the higher the path test frequency, the higher the test call times; according to the number of test calls, call the failed test cases in the retry test case set, and perform interface tests in the interface call order of each interface access path to be tested; if the failed test case is successfully retested, remove the failed test case from the retry test case set; if the failed test case fails to be retested, detect the number of test failures of the failed test case in which the retest failed; if the number of test failures is greater than the preset number threshold, it means that the number of test failures itself is abnormal, so the failed test case is marked as the final failed case, and the final failed case is removed from the retry test case set; return to execute the retest step until the retry test case set is empty.
[0135] In the above embodiment, a retry test case set is set up. The retry test case set can be used to re-add failed test cases with fewer test failures to the interface access path test, thereby improving the utilization rate of test cases and saving test resources. In addition, failed test cases with more test failures are marked as final failure cases, so that test cases with abnormalities can be eliminated to prevent the test cases with abnormalities from continuously wasting test resources and affecting test efficiency.
[0136] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.
[0137] Based on the same inventive concept, the embodiment of the present application also provides an interface access path testing device for implementing the interface access path testing method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more interface access path testing device embodiments provided below can refer to the limitations on the interface access path testing method above, and will not be repeated here.
[0138] In an exemplary embodiment, Figure 3 As shown, an interface access path testing device is provided, including: a path generation module 402, a weight generation module 404, an interface testing module 406, a weight updating module 408 and a test result generation module 410, wherein:
[0139] The path generation module 402 is used to determine each interface to be tested and generate multiple interface access paths to be tested between the interfaces to be tested;
[0140] The weight generating module 404 is used to generate a path weight corresponding to each of the access paths of the interface to be tested, wherein the path weight represents the business importance of the access path of the interface to be tested;
[0141] The interface testing module 406 is used for the interface testing step: obtaining the case weight corresponding to each test case, and based on each path weight, performing interface testing using each test case and each interface access path to be tested to obtain an interface testing result;
[0142] The weight updating module 408 is used to update the use case weight of each of the test cases according to the interface test result, and update the weight of each of the paths according to the updated use case weight;
[0143] The test result generating module 410 is used to return to execute the interface test step until a preset iterative test termination condition is reached, and all updated path weights are used as interface access path test results.
[0144] In one embodiment, the interface test result includes the usage frequency of the current use case and test exception information; the weight updating module is further used to:
[0145] For each of the test cases, according to the current test case usage frequency and the test exception information, update the test case weight of the test case in the current iterative test round;
[0146] Detecting at least one associated test case associated with the test case, and obtaining an updated case weight of the current iterative test round corresponding to each of the associated test cases;
[0147] Aggregate the updated case weights of the current iterative test round corresponding to each of the associated test cases to obtain the case weights of the test cases in the next iterative test round.
[0148] In one embodiment, the weight updating module is further used for:
[0149] For each of the test cases, if the current test case usage frequency of the test case is greater than the previous test case usage frequency, then increasing the test case weight of the test case in the current iterative test round;
[0150] If the current test case usage frequency of the test case is less than the previous test case usage frequency, reducing the test case weight of the test case in the current iterative test round;
[0151] If the test exception information indicates that a test exception occurs in the test case, the test case weight of the test case in the current iterative test round is increased.
[0152] In one embodiment, the weight updating module is further used for:
[0153] For each of the interface access paths to be tested, determining a plurality of target test interfaces corresponding to the interface access path to be tested;
[0154] Determine the target test case corresponding to each of the target test interfaces according to the corresponding relationship between the interfaces to be tested and the test cases to be tested;
[0155] Aggregating the case weights of each target test case in the next iterative test round to obtain an aggregated weight;
[0156] The aggregation weight is normalized to obtain an updated path weight.
[0157] In one embodiment, the interface testing module is further used for:
[0158] Based on each of the path weights, generating a path test frequency of each of the interface access paths to be tested;
[0159] According to the test frequency of each path, each test case is called, and the interface test is performed according to each interface access path to be tested.
[0160] In one embodiment, the path generation module is further used to:
[0161] Enumerate the access paths between the interfaces to be tested to obtain a full set of interface access paths;
[0162] Performing feasibility verification on each interface access path in the full set of interface access paths to obtain a feasibility verification result;
[0163] According to the feasibility verification result, unexecutable interface access paths are eliminated from the full set of interface access paths to obtain multiple initial test interface access paths;
[0164] Repetitive paths and loop paths are eliminated from the multiple initial test interface access paths to obtain multiple interface access paths to be tested.
[0165] In one embodiment, the interface testing module is further used for:
[0166] If there is a failed test case that failed the test, import the failed test case into the retry test case set;
[0167] Retesting step: calling the failed test cases in the retry test case set according to the test frequency of each path, and performing interface testing according to each interface access path to be tested;
[0168] If the failed test case is successfully retested, removing the failed test case from the retry test case set;
[0169] If the failed test case fails in retesting, detecting the number of test failures of the failed test case in which the retesting fails;
[0170] If the number of test failures is greater than a preset number threshold, the failed test case is marked as a final failure case, and the final failure case is removed from the retry test case set;
[0171] Return to execute the retest step until the retry test case set is empty.
[0172] Each module in the above-mentioned interface access path testing device can be implemented in whole or in part by software, hardware and their combination. Each of the above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to each of the above modules.
[0173] In an exemplary embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as shown in FIG. Figure 4As shown. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit and an input device. The processor, the memory and the input / output interface are connected via a system bus, and the communication interface, the display unit and the input device are connected to the system bus via the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be implemented through WIFI, a mobile cellular network, near field communication (NFC) or other technologies. When the computer program is executed by the processor, it implements an interface access path testing method. Those skilled in the art can understand that Figure 4 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.
[0174] In one embodiment, a computer device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above method embodiments when executing the computer program.
[0175] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.
[0176] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.
[0177] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.
[0178] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.
[0179] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.
Claims
1. A method for testing an interface access path, characterized in that: The method comprises: Determine each interface to be tested, and generate multiple interface access paths to be tested between each interface to be tested; Generate a path weight corresponding to each of the access paths of the interface to be tested, wherein the path weight represents the business importance of the access path of the interface to be tested; Interface testing step: obtaining the path weight corresponding to each of the interface access paths to be tested, and based on each of the path weights, performing interface testing using each test case and each of the interface access paths to be tested to obtain an interface testing result; According to the interface test result, the use case weight of each of the test cases is updated, and according to the updated use case weight, the path weight is updated; Return to execute the interface test step until the preset iterative test termination condition is reached, and use all updated path weights as interface access path test results.
2. The interface access path testing method according to claim 1, characterized in that: The interface test result includes the current use case usage frequency and test exception information; and updating the use case weight of each test case according to the interface test result includes: For each of the test cases, according to the current test case usage frequency and the test exception information, update the test case weight of the test case in the current iterative test round; Detecting at least one associated test case associated with the test case, and obtaining an updated case weight of the current iterative test round corresponding to each of the associated test cases; Aggregate the updated case weights of the current iterative test round corresponding to each of the associated test cases to obtain the case weights of the test cases in the next iterative test round.
3. The interface access path testing method according to claim 2, characterized in that: The updating of the test case weight of the test case in the current iterative test round according to the current test case usage frequency and the test exception information includes: For each of the test cases, if the current test case usage frequency of the test case is greater than the previous test case usage frequency, then increasing the test case weight of the test case in the current iterative test round; If the current test case usage frequency of the test case is less than the previous test case usage frequency, reducing the test case weight of the test case in the current iterative test round; If the test exception information indicates that a test exception occurs in the test case, the test case weight of the test case in the current iterative test round is increased.
4. The interface access path testing method according to claim 2, characterized in that: The updating of each path weight according to the updated use case weight includes: For each of the interface access paths to be tested, determining a plurality of target test interfaces corresponding to the interface access path to be tested; Determine the target test case corresponding to each of the target test interfaces according to the corresponding relationship between the interfaces to be tested and the test cases to be tested; Aggregating the case weights of each target test case in the next iterative test round to obtain an aggregated weight; The aggregation weight is normalized to obtain an updated path weight.
5. The interface access path testing method according to claim 1, characterized in that: The performing of interface testing based on the path weights and using the test cases and the interface access paths to be tested includes: Based on each of the path weights, generating a path test frequency of each of the interface access paths to be tested; According to the test frequency of each path, each test case is called, and the interface test is performed according to each interface access path to be tested.
6. The interface access path testing method according to claim 1, characterized in that: The generating a plurality of interface access paths to be tested between the interfaces to be tested comprises: Enumerate the access paths between the interfaces to be tested to obtain a full set of interface access paths; Performing feasibility verification on each interface access path in the full set of interface access paths to obtain a feasibility verification result; According to the feasibility verification result, unexecutable interface access paths are eliminated from the full set of interface access paths to obtain multiple initial test interface access paths; Repetitive paths and loop paths are eliminated from the multiple initial test interface access paths to obtain multiple interface access paths to be tested.
7. The interface access path testing method according to claim 5, characterized in that: After calling each of the test cases according to the test frequency of each of the paths and performing interface testing according to each of the interface access paths to be tested, the method further includes: If there is a failed test case that failed the test, import the failed test case into the retry test case set; Retesting step: calling the failed test cases in the retry test case set according to the test frequency of each path, and performing interface testing according to each interface access path to be tested; If the failed test case is successfully retested, removing the failed test case from the retry test case set; If the failed test case fails in retesting, detecting the number of test failures of the failed test case in which the retesting fails; If the number of test failures is greater than a preset number threshold, the failed test case is marked as a final failure case, and the final failure case is removed from the retry test case set; Return to execute the retest step until the retry test case set is empty.
8. An interface access path testing device, characterized in that: The device comprises: A path generation module, used to determine each interface to be tested, and generate multiple interface access paths to be tested between each interface to be tested; A weight generating module, used to generate a path weight corresponding to each of the access paths of the interface to be tested, wherein the path weight represents the business importance of the access path of the interface to be tested; The interface test module is used for the interface test step: obtaining the case weight corresponding to each test case, and based on each path weight, performing interface test using each test case and each interface access path to be tested to obtain an interface test result; A weight updating module, used to update the use case weight of each of the test cases according to the interface test result, and update the weight of each of the paths according to the updated use case weight; The test result generating module is used to return to execute the interface test step until a preset iterative test termination condition is reached, and all updated path weights are used as interface access path test results.
9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.