Abnormality testing method and device, electronic equipment and storage medium

Abstract

This application relates to software testing technology, applicable to the fintech field, and particularly to an anomaly testing method, apparatus, electronic device, and storage medium. The method involves: obtaining anomaly definition information from the interface documentation of the service to be tested; clustering error codes of downstream services within the anomaly definition information to obtain anomaly test information for the service to be tested; generating an anomaly test case set based on the anomaly test information and automated test cases; and performing anomaly testing based on the anomaly test case set to obtain the anomaly test results. This application improves the robustness of the upstream and downstream call chains of software.

Description

Technical Field

[0001] This application relates to software testing technology, and more particularly to an anomaly testing method, apparatus, electronic device, and storage medium. Background Technology

[0002] Testing is a crucial part of software development, used to verify whether the software meets the specified requirements and to clarify the difference between expected and actual results.

[0003] In existing technologies, as the technical architecture transforms to a distributed microservice architecture, exception handling and other aspects of program logic are externalized from within the system and product to services and even between systems, significantly increasing the complexity of program implementation.

[0004] However, existing technologies for anomaly testing can only focus on the service being tested itself and cannot guarantee the robustness of the entire chain. Summary of the Invention

[0005] This application provides an anomaly testing method, apparatus, electronic device, and storage medium to improve the robustness of upstream and downstream call chains of software.

[0006] In a first aspect, embodiments of this application provide an anomaly testing method, which includes:

[0007] Obtain the exception definition information defined in the API documentation of the service to be tested;

[0008] Cluster the error codes of downstream services in the exception definition information to obtain the exception test information of the service to be tested.

[0009] Generate an abnormal test case set based on abnormal test information and automated test cases;

[0010] Based on the set of abnormal test cases, perform abnormal tests and obtain the abnormal test results.

[0011] Secondly, embodiments of this application also provide an anomaly testing apparatus, which includes:

[0012] The exception definition information acquisition module is used to acquire exception definition information defined in the interface documentation of the service to be tested;

[0013] The abnormal test information determination module is used to cluster the error codes of downstream services in the abnormal definition information to obtain the abnormal test information of the service to be tested.

[0014] The exception test case generation module is used to generate a set of exception test cases based on exception test information and automated test cases;

[0015] The abnormal test result acquisition module is used to perform abnormal tests based on the abnormal test case set and obtain abnormal test results.

[0016] Thirdly, embodiments of this application also provide an electronic device, which includes:

[0017] One or more processors;

[0018] Storage device for storing one or more programs;

[0019] When one or more programs are executed by one or more processors, the one or more processors implement any of the exception testing methods provided in the embodiments of this application.

[0020] Fourthly, embodiments of this application also provide a storage medium including computer-executable instructions, which, when executed by a computer processor, are used to perform any of the exception testing methods provided in embodiments of this application.

[0021] This application obtains exception definition information from the interface documentation of the service under test, standardizes and normalizes exception definitions in the interface documentation, and improves the standardization of subsequent exception test cases. It clusters error codes of downstream services in the exception definition information to obtain exception test information for the service under test. By clustering error codes of downstream services, exceptions in downstream services can be distinguished, and exceptions in the call chain can be located. Based on the exception test information and automated test cases, an exception test case set is generated. The automated test cases enable rapid generation of the exception test case set and ensure comprehensive exception testing coverage. Exception testing is performed based on the exception test case set to obtain exception test results. By distinguishing exceptions in downstream services, exception testing of the downstream call chain can be achieved, improving the robustness of the software's upstream and downstream call chain. Therefore, the technical solution of this application solves the problem in existing technologies that exception testing can only focus on the service being tested and cannot guarantee the robustness of the entire chain, thus achieving the effect of improving the robustness of the software's upstream and downstream call chain. Attached Figure Description

[0022] Figure 1 This is a flowchart of an anomaly testing method according to Embodiment 1 of this application;

[0023] Figure 2 This is a flowchart of an anomaly testing method according to Embodiment 2 of this application;

[0024] Figure 3 This is a flowchart of an anomaly testing method according to Embodiment 3 of this application;

[0025] Figure 4 This is a schematic diagram of an anomaly testing device according to Embodiment 4 of this application;

[0026] Figure 5 This is a schematic diagram of the structure of an electronic device according to Embodiment 5 of this application. Detailed Implementation

[0027] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0028] It should be noted that the terms "first" and "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0029] Example 1

[0030] Figure 1 This is a flowchart of an anomaly testing method provided in Embodiment 1 of this application. This embodiment is applicable to the automatic testing of anomaly scenarios in software testing and can be applied to software testing in the financial technology field. The method can be executed by an anomaly testing device, which can be implemented in software and / or hardware and specifically configured in the testing platform.

[0031] See Figure 1 The anomaly testing method shown includes the following steps:

[0032] S110. Obtain the exception definition information defined in the interface documentation of the service to be tested.

[0033] The service to be tested can be a service within the software that needs to be tested. The interface documentation can be the documentation for the interfaces of the software to be tested; it is a technical document used in software development to describe the interaction rules between systems. Its core function is to standardize the communication methods between different modules, services, or applications, facilitating efficient collaboration during system development. In this application, exception definition information for testing is predefined in the interface documentation. Exception definition information can be related to the elements defining exception handling in the interface documentation, used to standardize the definition of exceptions in testing. For example, exception definition information may include error codes, error code dictionaries, and exception classes. In a dedicated section of the interface documentation, standardized and structured descriptions of the corresponding interface error codes, error code dictionaries, and exception types are presented.

[0034] If exception definition information is defined in the interface documentation during software development, the exception definition information can be directly read from the interface documentation during testing.

[0035] S120. Cluster the error codes of downstream services in the exception definition information to obtain the exception test information of the service to be tested.

[0036] Downstream services can be services called by the service under test, specifically services downstream of the service under test in the call chain. Error codes are unique codes used to identify the type of service error. Clustering is used to aggregate error codes from downstream exception information of the service under test into a single error code. Clustering allows for standardized management of error codes as a whole, distinguishing between application-specific exceptions and downstream call exceptions, facilitating the localization of exceptions in long call chains and the construction of standardized exception handling test scenarios. Exception test information can be related to various exceptions during testing, used to generate exception test cases. For example, the error codes of downstream services can be clustered into a single error code to obtain the exception test information of the service under test.

[0037] S130. Generate an exception test case set based on the exception test information and automated test cases.

[0038] Automated test cases are automatically generated test cases for transactions and interfaces. Converting the relevant information from exception test information into corresponding program code and adding it to the corresponding automated test cases results in an exception test case set. Exception test information includes various exception types; adding each type of exception information to the corresponding automated test cases yields multiple exception test cases, which together constitute an exception test case set.

[0039] S140. Based on the abnormal test case set, perform abnormal tests and obtain abnormal test results.

[0040] In the appropriate testing environment, run exception test cases to perform exception testing and obtain exception test results. For example, exception test results may include exception code and the service that encountered the exception.

[0041] It should be noted that all information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this disclosure are information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data comply with the relevant laws, regulations and standards of the relevant regions.

[0042] The technical solution of this embodiment obtains the exception definition information defined in the interface document of the service to be tested, and standardizes and normalizes the exception definitions in the interface document, thereby improving the standardization of subsequent exception test cases. It clusters the error codes of downstream services in the exception definition information to obtain the exception test information of the service to be tested. By clustering the error codes of downstream services, exceptions in downstream services can be distinguished, and exceptions in the call chain can be located. An exception test case set is generated based on the exception test information and automated test cases. The automated test cases enable the rapid generation of the exception test case set and ensure comprehensive coverage of exception testing. Exception testing is performed based on the exception test case set to obtain the exception test results. By distinguishing exceptions in downstream services, exception testing of the downstream call chain can be achieved, improving the robustness of the software's upstream and downstream call chain. Therefore, the technical solution of this application solves the problem in the prior art that exception testing can only focus on the service being tested itself and cannot guarantee the robustness of the entire chain, thus achieving the effect of improving the robustness of the software's upstream and downstream call chain.

[0043] Example 2

[0044] Figure 2 This is a flowchart of an anomaly testing method provided in Embodiment 2 of this application. The technical solution of this embodiment is further refined based on the above technical solution.

[0045] Furthermore, after performing abnormal tests based on abnormal test cases and obtaining abnormal test results, the following is added: "If the abnormal test result is a downstream error, then recursively follow the call chain according to the abnormal test information of the service under test until the test result is not a downstream error, and return all error codes in the recursive chain", so as to return all error codes in the recursive chain.

[0046] See Figure 2 An anomaly testing method is shown, comprising:

[0047] S210. Obtain the exception definition information defined in the interface documentation of the service to be tested.

[0048] S220. Cluster the error codes of downstream services in the exception definition information to obtain the exception test information of the service to be tested.

[0049] In one optional embodiment, the error codes of downstream services in the exception definition information are clustered to obtain the exception test information of the service to be tested, including: clustering all the error codes of exceptions caused by the exception of the downstream service being called in the exception definition information into downstream error codes that are different from other error codes, thereby obtaining the exception test information of the service to be tested.

[0050] Downstream error codes can be clustered into a single, identical code representing all error codes from downstream services invoked in the exception definition information. This cluster indicates that the corresponding exception was caused by a downstream service exception. To facilitate differentiation between exceptions in this service and those in downstream services, all error codes generated in the exception definition information due to exceptions in downstream services are clustered into downstream error codes. These downstream error codes are uniquely distinguishable from other error codes, allowing determination of whether the exception was caused by a downstream error in the call chain based on the returned error code.

[0051] Table 1 is an error code information table. In Table 1, service B is a downstream service of service A, and the error codes of service A caused by service B are clustered as 3001.

[0052] Table 1 Error Code Information Table

[0053]

[0054]

[0055] By clustering all error codes of exceptions caused by the failure of downstream services in the exception definition information into downstream error codes that are distinct from other error codes, the exception test information of the service to be tested can be obtained. Clustering all error codes of downstream services into downstream error codes that are distinct from other error codes makes it easier to distinguish between errors of this service and errors of downstream services, so as to quickly locate exceptions on the call chain.

[0056] S230. Generate an abnormal test case set based on the abnormal test information and automated test cases.

[0057] S240. Based on the abnormal test case set, perform abnormal tests and obtain abnormal test results.

[0058] S250. If the abnormal test result is a downstream error, then recursively follow the call chain according to the abnormal test information of the service under test until the test result is not a downstream error, and return all error codes in the recursive chain.

[0059] If the abnormal test result is a downstream error, it is necessary to locate the downstream location where the exception occurred. Therefore, based on the abnormal test information of the service under test, the call chain is recursively followed until the test result is no longer a downstream error. At this point, the cause of the downstream error is found, and all error codes in the recursive chain are returned. This can expose the downstream call chain and the cause of the exception to the developers, making it easier for them to make improvements and improve the robustness of the call chain.

[0060] For example, service A calls service B, and service B calls service C. When service C encounters a "format validation failed" error, both service B and service A will display the downstream error code. If the service to be tested is service A, the downstream error code is 3001, and the format validation failed code is 1000, then the returned error codes are: 3001 for service B and 1000 for service C.

[0061] The technical solution of this embodiment, if the abnormal test result is a downstream error, then recursively follows the call chain according to the abnormal test information of the service under test until the test result is not a downstream error, and returns all error codes in the recursive chain, thereby exposing all errors on the call chain and making it easier to locate the cause of errors in the downstream service.

[0062] Example 3

[0063] Figure 3 This is a flowchart of an anomaly testing method provided in Embodiment 3 of this application. The technical solution of this embodiment is further refined based on the above technical solution.

[0064] Furthermore, the phrase "generate an exception test case set based on exception test information and automated test cases" is further refined to: "add the exception information code constructed based on the exception test information to the corresponding automated test case code to generate an exception test case set" to obtain the exception test case set.

[0065] See Figure 3 An anomaly testing method is shown, comprising:

[0066] S310. Obtain the exception definition information defined in the interface document of the service to be tested.

[0067] S320. Cluster the error codes of downstream services in the exception definition information to obtain the exception test information of the service to be tested.

[0068] S330. Add the exception information code constructed based on the exception test information to the corresponding automated test case code to generate an exception test case set.

[0069] Exception information codes can be program code converted from exception test information. Based on the explicit exception objects and error codes in the exception test information, and according to the structured and standardized exception handling elements, exception information codes are constructed and injected into the corresponding code segments of the automated test cases to simulate exception scenarios and generate exception test cases. All exception test cases constitute an exception test case set.

[0070] For example, abnormal test information can be injected into automated test cases using methods such as chaos engineering and dynamic bytecode to generate abnormal test cases. Specifically, abnormal test cases can be combined with transaction automation test cases and interface automation test cases in the test, and the automated test cases can be expanded by permutation and combination to achieve comprehensive and effective coverage of the abnormal handling branch.

[0071] Taking Java applications as an example, the Java Agent mechanism injects specific exception testing information through dynamic bytecode technology, and standardizes and automates exception injection through a tool platform. Corresponding exception injection events are generated by defining the target method, exception type, and duration.

[0072] In an optional embodiment, exception information code constructed based on exception test information is added to the corresponding automated test case code to generate an exception test case set. This includes: for downstream exception definition information related to downstream services in the service exception test information, using the automated test cases corresponding to the downstream exception definition information in each downstream service as invocation test cases, and adding the downstream exception information code constructed based on the downstream exception definition information to the corresponding invocation test cases to generate downstream exception test cases; for service exception definition information related to the service under test in the service exception test information, using the automated test cases corresponding to the service exception definition information in the service under test as service test cases, and adding the service exception information code constructed based on the service exception definition information to the corresponding service test cases to generate service exception test cases; and using the set of exception test cases composed of downstream exception test cases and service exception test cases as the exception test case set.

[0073] Downstream exception definition information can be related exception definition information for service exceptions caused by downstream errors. For example, downstream exception definition information may include downstream service name, downstream service error type, downstream service error code, service error name, service error type, and service error code. For instance, based on the error code information table in Table 1 above, the downstream exception definition information for error code 1000 in service B could be: Service B: Error code 1000, error code dictionary format verification failed; Service A: Error code 3001, downstream error in error code dictionary.

[0074] Invocation test cases can be automated test cases related to downstream exception definition information in downstream services. For example, corresponding invocation test cases can be obtained based on downstream exception definition information. For instance, downstream exception definition information could be: Service B: Error code 1000, error code dictionary format validation failed; Service A: Error code 3001, error code dictionary error occurs downstream. In this case, the invocation test case could be an automated test case for format validation in Service B. The downstream exception definition information is then converted into corresponding program code and added to the corresponding invocation test case to obtain the downstream exception test case.

[0075] In one optional embodiment, downstream exception information code constructed based on downstream exception definition information is added to the corresponding call test case to generate a downstream exception test case, including: generating call exception code based on downstream exception definition information; adding the call exception code to the corresponding call automation test case to obtain a call exception test case.

[0076] Invocation exception code can be program code converted from downstream exception definition information. Adding this invocation exception code to the corresponding automated invocation test case yields an invocation exception test case. For example, invocation exception code can be generated based on downstream exception definition information using methods such as chaos engineering and dynamic bytecode, and then added to the corresponding automated invocation test case to obtain the invocation exception test case.

[0077] By generating call exception code based on downstream exception definition information, and adding the call exception code to the corresponding call automation test case, call exception test cases can be obtained. Call exception test cases can be obtained directly from call automation test cases. By reusing call automation test cases, the efficiency and accuracy of call exception test case generation can be improved.

[0078] The exception definition information for this service can be exception definition information related to the exception of the service under test itself. For example, the exception definition information for this service can include the error name of the service under test, the error type of the service under test, and the error code of the service under test. For example, based on the error code information table in Table 1 above, the exception definition information for error code 2001 of service A can be: Service A, error code 2001, error code dictionary: user password error.

[0079] This service test case can be an automated test case related to the service's exception definition information. For example, the corresponding service test case can be obtained based on the service's exception definition information. For instance, if the service's common definition information is: Service A, Error Code 2001, Error Code Dictionary: User Password Error, the test case can be an automated test case for user password verification in Service A. The service exception definition information is converted into corresponding program code and added to the corresponding service test case to obtain the service exception test case.

[0080] The set of abnormal test cases is obtained by taking the union of the abnormal test cases in the downstream and the abnormal test cases in this service.

[0081] By analyzing downstream exception definitions related to downstream services within the service exception test information, automated test cases corresponding to these definitions in each downstream service are used as invocation test cases. The downstream exception information code, constructed based on the downstream exception definitions, is added to the corresponding invocation test cases to generate downstream exception test cases. Based on these downstream exception test cases and the automated test cases of downstream services, downstream exception test cases are quickly obtained, improving the generation efficiency of downstream exception test cases. Similarly, by analyzing service exception definitions related to the service under test within the service exception test information, automated test cases corresponding to these definitions in the service under test are used as test cases for this service. The exception information code, constructed based on these definitions, is added to the corresponding test cases for this service, generating service exception test cases. Based on these service exception test cases and the automated test cases of the service under test, service exception test cases are quickly obtained, improving the generation efficiency of this service exception test cases. The set of exception test cases, comprised of downstream exception test cases and service exception test cases, is considered an exception test case set, ensuring the comprehensiveness of the exception test cases in the set and guaranteeing full coverage of exception testing.

[0082] S340. Based on the abnormal test case set, perform abnormal tests and obtain the abnormal test results.

[0083] In an optional embodiment, abnormal testing is performed based on the abnormal test case set to obtain abnormal test results, including: abnormal test cases in the abnormal test case set are subjected to abnormal testing from bottom to top according to the call relationship of each service in the call chain of the service to be tested, and the abnormal test results of all upstream services are returned.

[0084] Exception testing is performed from bottom to top according to the call chain. That is, the called service is tested for exceptions first, and then exception testing is performed from bottom to top according to the call chain. When the downstream service is tested for exceptions, all its upper-layer services return the exception test results. This ensures that no test is missed in the upstream service and avoids repeated testing, thus improving testing efficiency.

[0085] By combining and scheduling automated test scenarios with test sets, automated exception handling test scenarios are generated at the transaction and interface dimensions. This enables automatic scheduling and assertion analysis of automated test scripts and exception injection events, thereby achieving exception testing and obtaining exception test results.

[0086] By using abnormal test cases from the abnormal test case set, abnormal tests are performed from bottom to top according to the call relationship of each service in the call chain of the service under test, and the abnormal test results of all upstream services are returned. This can ensure the comprehensiveness of the test and improve the test efficiency.

[0087] The technical solution of this embodiment generates an exception test case set by adding exception test information to the corresponding automated test case code. This allows for the rapid generation of exception test case sets based on existing automated test cases, thereby improving the efficiency of exception test case set generation.

[0088] Example 4

[0089] Figure 4 The diagram shown is a structural schematic of an anomaly testing device provided in Embodiment 4 of this application. This embodiment is applicable to the automatic testing of anomaly scenarios in software testing and is configured on a software testing platform. The specific structure of the anomaly testing device is as follows:

[0090] The exception definition information acquisition module 410 is used to acquire the exception definition information defined in the interface document of the service to be tested.

[0091] The abnormal test information determination module 420 is used to cluster the error codes of downstream services in the abnormal definition information to obtain the abnormal test information of the service to be tested.

[0092] The exception test case set generation module 430 is used to generate exception test case sets based on exception test information and automated test cases;

[0093] The abnormal test result acquisition module 440 is used to perform abnormal tests based on the abnormal test case set and obtain abnormal test results.

[0094] The technical solution of this embodiment obtains the exception definition information defined in the interface document of the service to be tested, and standardizes and normalizes the exception definitions in the interface document, thereby improving the standardization of subsequent exception test cases. It clusters the error codes of downstream services in the exception definition information to obtain the exception test information of the service to be tested. By clustering the error codes of downstream services, exceptions in downstream services can be distinguished, and exceptions in the call chain can be located. An exception test case set is generated based on the exception test information and automated test cases. The automated test cases enable the rapid generation of the exception test case set and ensure comprehensive coverage of exception testing. Exception testing is performed based on the exception test case set to obtain the exception test results. By distinguishing exceptions in downstream services, exception testing of the downstream call chain can be achieved, improving the robustness of the software's upstream and downstream call chain. Therefore, the technical solution of this application solves the problem in the prior art that exception testing can only focus on the service being tested itself and cannot guarantee the robustness of the entire chain, thus achieving the effect of improving the robustness of the software's upstream and downstream call chain.

[0095] Optional, the anomaly testing apparatus also includes:

[0096] The test result recursion module is used to recursively follow the call chain according to the abnormal test information of the service under test if the abnormal test result is a downstream error, until the test result is not a downstream error, and then returns all error codes in the recursive chain.

[0097] Optionally, the anomaly test information determination module 420 includes:

[0098] The error code clustering unit is used to cluster all error codes in the exception definition information that are caused by the exception of the downstream service being called into downstream error codes that are different from other error codes, so as to obtain the exception test information of the service to be tested.

[0099] Optional, the exception test case generation module 430 includes:

[0100] The exception code addition unit is used to add exception information code, which is constructed based on exception test information, to the corresponding automated test case code to generate exception test cases.

[0101] Optional exception code addition units include:

[0102] The downstream exception test case generation subunit is used to generate downstream exception test cases by taking the automated test cases corresponding to the downstream exception definition information in each downstream service as the call test cases, and adding the downstream exception information code constructed based on the downstream exception definition information to the corresponding call test cases.

[0103] This service exception test case generation subunit is used to generate this service exception test case by taking the automated test case corresponding to the service exception definition information in the service exception test information related to the service to be tested, using it as the service test case, and adding the service exception information code constructed based on the service exception definition information to the corresponding service test case.

[0104] The abnormal test case set determination sub-unit is used to form an abnormal test case set by combining the abnormal test cases from downstream and the abnormal test cases of this service.

[0105] Optionally, a downstream anomaly test case generation sub-unit is used specifically for:

[0106] Generate call exception code based on downstream exception definition information;

[0107] Add the exception code to the corresponding automated test case to obtain the exception test case.

[0108] Optionally, the anomaly test result acquisition module 440 includes:

[0109] The bottom-up testing unit is used for abnormal test cases in the abnormal test case set. It performs abnormal testing from bottom to top according to the call relationship of each service in the call chain of the service under test, and returns the abnormal test results of all upstream services.

[0110] The anomaly testing apparatus provided in this application embodiment can execute the anomaly testing method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects for executing the anomaly testing method.

[0111] According to embodiments of the present invention, the present invention also provides an electronic device, a readable storage medium, and a computer program product.

[0112] Example 5

[0113] Figure 5 This is a schematic diagram of the structure of an electronic device provided in Embodiment 5 of this application, as shown below. Figure 5As shown, the electronic device includes a processor 510, a memory 520, an input device 530, and an output device 540; the number of processors 510 in the electronic device can be one or more. Figure 5 Taking a processor 510 as an example; the processor 510, memory 520, input device 530, and output device 540 in the electronic device can be connected via a bus or other means. Figure 5 Taking the example of a connection between China and Israel via a bus.

[0114] The memory 520, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the anomaly testing method in this embodiment (e.g., the anomaly definition information acquisition module 410, the anomaly test information determination module 420, the anomaly test case set generation module 430, and the anomaly test result acquisition module 440). The processor 510 executes various functional applications and data processing of the electronic device by running the software programs, instructions, and modules stored in the memory 520, thereby implementing the aforementioned anomaly testing method.

[0115] The memory 520 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a given function; the data storage area may store data created based on terminal usage. Furthermore, the memory 520 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 520 may further include memory remotely located relative to the processor 510, which can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0116] Input device 530 can be used to receive input character information and generate key signal inputs related to user settings and function control of the electronic device. Output device 540 may include display devices such as a display screen.

[0117] Example 6

[0118] Embodiment Six of this application also provides a storage medium containing computer-executable instructions. When executed by a computer processor, the computer-executable instructions are used to execute an exception testing method. The method includes: obtaining exception definition information defined in the interface document of the service to be tested; clustering the error codes of downstream services in the exception definition information to obtain exception test information of the service to be tested; generating an exception test case set based on the exception test information and automated test cases; and performing exception testing based on the exception test case set to obtain exception test results.

[0119] Of course, the computer-executable instructions provided in the embodiments of this application are not limited to the method operations described above, but can also perform related operations in the anomaly testing method provided in any embodiment of this application.

[0120] Based on the above description of the implementation methods, those skilled in the art can clearly understand that this application can be implemented using software and necessary general-purpose hardware, and of course, it can also be implemented using hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as a computer floppy disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk, or optical disk, etc., including several instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0121] It is worth noting that in the embodiments of the above-mentioned abnormal testing device, the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the scope of protection of this application.

[0122] Note that the above are merely preferred embodiments and the technical principles employed in this application. Those skilled in the art will understand that this application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the appended claims.

Claims

1. An abnormality testing method characterized by comprising: include: Obtain the exception definition information defined in the API documentation of the service to be tested; Cluster the error codes of downstream services in the anomaly definition information to obtain the anomaly test information of the service to be tested. Based on the abnormal test information and automated test cases, an abnormal test case set is generated; Based on the aforementioned set of abnormal test cases, perform abnormal tests and obtain the abnormal test results.

2. The method of claim 1, wherein, After performing anomaly testing based on the anomaly test case set and obtaining the anomaly test results, the process further includes: If the abnormal test result is a downstream error, then the call chain is recursively processed according to the abnormal test information of the service under test until the test result is not a downstream error, and all error codes in the recursive chain are returned.

3. The method of claim 2, wherein, The clustering of error codes from downstream services in the anomaly definition information to obtain anomaly test information for the service to be tested includes: The error codes of the exceptions caused by the failure of the downstream service being called in the exception definition information are all clustered into downstream error codes that are different from other error codes, thus obtaining the exception test information of the service to be tested.

4. The method of claim 1, wherein, The step of generating an abnormal test case set based on the abnormal test information and automated test cases includes: The exception information code, constructed based on the exception test information, is added to the corresponding automated test case code to generate an exception test case set.

5. The method according to claim 4, characterized in that, The step of adding the exception information code constructed based on the exception test information to the corresponding automated test case code to generate an exception test case set includes: For the downstream exception definition information related to downstream services in the service exception test information, the automated test cases corresponding to the downstream exception definition information in each downstream service are used as call test cases, and the downstream exception information code constructed according to the downstream exception definition information is added to the corresponding call test cases to generate downstream exception test cases. For the service exception definition information related to the service under test in the service exception test information, the automated test case in the service under test that corresponds to the service exception definition information is used as the service test case, and the service exception information code constructed according to the service exception definition information is added to the corresponding service test case to generate the service exception test case; The set of abnormal test cases, consisting of the downstream abnormal test cases and the abnormal test cases of this service, is called the abnormal test case set.

6. The method according to claim 5, characterized in that, The step of adding the downstream exception information code constructed based on the downstream exception definition information to the corresponding call test case to generate a downstream exception test case includes: Based on the downstream exception definition information, generate the call exception code; Add the call exception code to the corresponding call automation test case to obtain the call exception test case.

7. The method according to claim 5, characterized in that, The step of performing anomaly testing based on the anomaly test case set and obtaining anomaly test results includes: The abnormal test cases in the abnormal test case set are tested from bottom to top according to the call relationship of each service in the call chain of the service to be tested, and the abnormal test results of all upstream services are returned.

8. An anomaly testing device, characterized in that, include: The exception definition information acquisition module is used to acquire exception definition information defined in the interface documentation of the service to be tested; An abnormal test information determination module is used to cluster the error codes of downstream services in the abnormal definition information to obtain the abnormal test information of the service to be tested. An exception test case set generation module is used to generate an exception test case set based on the exception test information and automated test cases; The abnormal test result acquisition module is used to perform abnormal tests based on the abnormal test case set and obtain abnormal test results.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the exception testing method as described in any one of claims 1-7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the anomaly testing method according to any one of claims 1-7.

Images