Fault-tolerant capability determination method and device, storage medium and electronic device

Abstract

The invention discloses a fault-tolerant capability determination method and device, a storage medium and an electronic device, and relates to the technical field of smart home, the fault-tolerant capability determination method comprises the following steps: determining the type of a to-be-tested end, the type comprising one of the following: an interface of a front-end device and an interface of a rear-end device; under the condition that the type of the end to be tested is front-end equipment, normal response information of the rear-end equipment is adjusted to generate abnormal response information which does not meet a first preset standard, and the abnormal response information is sent to the front-end equipment to determine the fault-tolerant capability of the front-end equipment; and under the condition that the type of the to-be-tested end is the interface of the back-end equipment, adjusting normal request information of the front-end equipment to generate abnormal request information which does not conform to a second preset standard, and sending the abnormal request information to the interface of the back-end equipment to determine the fault-tolerant capability of the interface of the back-end equipment.

Description

Technical Field

[0001] The present application relates to the field of smart home technology, and more specifically, to a method and device for determining fault tolerance, a storage medium, and an electronic device. Background Art

[0002] In the process of modern software development and system integration, front-end device testing and interface testing are key steps to ensure software stability and user experience. During the test process, it is usually necessary to simulate various input parameters and output parameters to comprehensively evaluate the response and processing capabilities of the software. However, in the related art, when testing the front-end device and / or interface, it is necessary to manually combine different input parameters and output parameters, resulting in low coverage of the test parameters.

[0003] Regarding the related art, when testing front-end devices and / or interfaces, it is necessary to manually combine different input parameters and output parameters, resulting in low test parameter coverage, and no effective solution has been proposed yet. Summary of the invention

[0004] The embodiments of the present application provide a method and device for determining fault tolerance, a storage medium and an electronic device, so as to at least solve the problem in the related art that when testing the front-end device and / or interface, different input parameters and output parameters need to be manually combined, resulting in low test parameter coverage.

[0005] According to an embodiment of the embodiments of the present application, a method for determining fault tolerance is provided, comprising: determining the type of an end to be tested, wherein the type comprises one of the following: an interface of a front-end device or a back-end device; when the type of the end to be tested is a front-end device, adjusting normal response information of the back-end device to generate abnormal response information that does not conform to a first preset standard, and sending the abnormal response information to the front-end device to determine the fault tolerance of the front-end device, wherein the first preset standard is used to indicate the corresponding data type and data length of each field of the normal response information; when the type of the end to be tested is an interface of a back-end device, adjusting normal request information of the front-end device to generate abnormal request information that does not conform to a second preset standard, and sending the abnormal request information to the interface of the back-end device to determine the fault tolerance of the interface of the back-end device, wherein the second preset standard is used to indicate the corresponding data type and data length of each field of the normal request information.

[0006] In an exemplary embodiment, normal response information of the back-end device is adjusted to generate abnormal response information that does not meet the first preset standard, including: determining the first preset standard corresponding to the normal response information; adjusting the data in the field of the normal response information according to the first preset standard to generate the abnormal response information, wherein the data of at least one field in the abnormal response information does not meet the first preset standard.

[0007] In an exemplary embodiment, adjusting the data in the field of the normal response information according to the first preset standard includes at least one of the following: adjusting the data type of the data in the field of the normal response information so that the adjusted data type does not conform to the first preset standard; adjusting the data length in the field of the normal response information so that the adjusted data length does not conform to the first preset standard.

[0008] In an exemplary embodiment, normal request information of the front-end device is adjusted to generate abnormal request information that does not meet the second preset standard, including: determining the second preset standard corresponding to the normal request information; adjusting the data in the field of the normal request information according to the second preset standard to generate the abnormal request information, wherein the data of at least one field in the abnormal request information does not meet the second preset standard.

[0009] In an exemplary embodiment, the exception response information is sent to a front-end device to determine the fault tolerance capability of the front-end device, including: obtaining a display result of the front-end device, wherein the display result is a display result corresponding to the exception response information; determining the fault tolerance capability of the front-end device according to the display result; the exception request information is sent to an interface of a back-end device to determine the fault tolerance capability of the interface of the back-end device, including: obtaining response information of the interface of the back-end device; and determining the fault tolerance capability of the interface of the back-end device according to the response information.

[0010] In an exemplary embodiment, after sending the exception response information to the front-end device to determine the fault tolerance capability of the front-end device, the method further includes: when the fault tolerance capability of the front-end device does not meet the first preset fault tolerance capability, optimizing the display logic and exception handling mechanism of the front-end device; after sending the exception request information to the interface of the back-end device to determine the fault tolerance capability of the interface of the back-end device, the method further includes: when the fault tolerance capability of the front-end device does not meet the second preset fault tolerance capability, optimizing the verification logic of the front-end device, wherein the verification logic is used to verify the received request information.

[0011] In an exemplary embodiment, before determining the type of the end to be tested, the method further includes: obtaining request information sent by a front-end device, wherein, when the end to be tested is a front-end device, the normal response information is response information corresponding to the request information, and when the end to be tested is an interface of the back-end device, the request information is the normal request information; determining whether to allow determination of the fault tolerance capability of the end to be tested based on the request information according to a preset whitelist, wherein the preset whitelist includes at least one of the following: a user identification whitelist, a device identification whitelist, a version number whitelist, an Internet Protocol address whitelist, and an interface uniform resource locator whitelist.

[0012] According to another embodiment of the embodiment of the present application, a device for determining fault tolerance capability is also provided, including: a determination module, used to determine the type of an end to be tested, wherein the type includes one of the following: an interface of a front-end device or a back-end device; a first test module, used to, when the type of the end to be tested is a front-end device, adjust the normal response information of the back-end device to generate abnormal response information that does not meet the first preset standard, and send the abnormal response information to the front-end device to determine the fault tolerance capability of the front-end device; a second test module, used to, when the type of the end to be tested is the interface of the back-end device, adjust the normal request information of the front-end device to generate abnormal request information that does not meet the second preset standard, and send the abnormal request information to the interface of the back-end device to determine the fault tolerance capability of the interface of the back-end device.

[0013] According to another aspect of the embodiments of the present application, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the above-mentioned method for determining fault tolerance capability when running.

[0014] According to another aspect of an embodiment of the present application, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the method for determining fault tolerance capability through the computer program.

[0015] According to another aspect of the embodiments of the present application, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the method for determining the fault tolerance capability is implemented.

[0016] In an embodiment of the present application, the type of the end to be tested is determined, wherein the type includes one of the following: a front-end device, an interface of a back-end device; when the type of the end to be tested is a front-end device, the normal response information of the back-end device is adjusted to generate abnormal response information that does not meet the first preset standard, and the abnormal response information is sent to the front-end device to determine the fault tolerance capability of the front-end device; when the type of the end to be tested is an interface of a back-end device, the normal request information of the front-end device is adjusted to generate abnormal request information that does not meet the second preset standard, and the abnormal request information is sent to the interface of the back-end device to determine the fault tolerance capability of the interface of the back-end device; the present application can comprehensively test the fault tolerance of the interface and the front-end by automatically generating input parameters and output parameters that do not meet the preset standards, improve test coverage, avoid artificial omission of test scenarios, and improve user experience. Therefore, the above technical solution is adopted to solve the problem of low test parameter coverage caused by the need to manually combine different input parameters and output parameters when testing the front-end device and / or interface. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0018] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0019] Figure 1 It is a hardware environment diagram of a method for determining fault tolerance according to an embodiment of the present application;

[0020] Figure 2 is a flow chart of a method for determining fault tolerance according to an embodiment of the present application;

[0021] Figure 3 is a flow chart of storing data preset values ​​according to an embodiment of the present application;

[0022] Figure 4 is a timing diagram of a test front-end device according to an embodiment of the present application;

[0023] Figure 5 is a timing diagram of a test interface according to an embodiment of the present application;

[0024] Figure 6 It is a structural block diagram of a device for determining fault tolerance according to an embodiment of the present application. DETAILED DESCRIPTION

[0025] In order 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 in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this application.

[0026] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0027] According to one aspect of an embodiment of the present application, a method for determining fault tolerance is provided. The method for determining fault tolerance is widely used in smart home, smart home, smart home device ecology, smart house ecology and other whole-house intelligent digital control application scenarios. Optionally, in this embodiment, the above method for determining fault tolerance can be applied to Figure 1 In the hardware environment composed of the terminal device 102 and the server 104 shown in FIG. Figure 1 As shown, the server 104 is connected to the terminal device 102 via a network, and can be used to provide services (such as application services, etc.) for the terminal or a client installed on the terminal. A database can be set on the server or independently of the server to provide data storage services for the server 104. Cloud computing and / or edge computing services can be configured on the server or independently of the server to provide data computing services for the server 104.

[0028] The network may include but is not limited to at least one of the following: wired network, wireless network. The wired network may include but is not limited to at least one of the following: wide area network, metropolitan area network, local area network, and the wireless network may include but is not limited to at least one of the following: WIFI (Wireless Fidelity), Bluetooth. The terminal device 102 may be but is not limited to a PC, a mobile phone, a tablet computer, a smart air conditioner, a smart range hood, a smart refrigerator, a smart oven, a smart stove, a smart washing machine, a smart water heater, a smart washing device, a smart dishwasher, a smart projection device, a smart TV, a smart clothes drying rack, a smart curtain, a smart audio and video, a smart socket, a smart speaker, a smart fresh air device, a smart kitchen and bathroom device, a smart bathroom device, a smart sweeping robot, a smart window cleaning robot, a smart mopping robot, a smart air purification device, a smart steamer, a smart microwave oven, a smart kitchen treasure, a smart purifier, a smart water dispenser, a smart door lock, etc.

[0029] In this embodiment, a method for determining fault tolerance is provided, which is applied to the above-mentioned computer terminal. Figure 2 : is a flow chart of a method for determining fault tolerance capability according to an embodiment of the present application, the process comprising the following steps:

[0030] Step S202, determining the type of the end to be tested, wherein the type includes one of the following: an interface of a front-end device or a back-end device;

[0031] Step S204, when the type of the end to be tested is a front-end device, adjusting the normal response information of the back-end device to generate abnormal response information that does not meet the first preset standard, and sending the abnormal response information to the front-end device to determine the fault tolerance capability of the front-end device, wherein the first preset standard is used to indicate the corresponding data type and data length of each field of the normal response information;

[0032] Step S206, when the type of the end to be tested is the interface of a back-end device, adjust the normal request information of the front-end device to generate abnormal request information that does not meet the second preset standard, and send the abnormal request information to the interface of the back-end device to determine the fault tolerance capability of the interface of the back-end device, wherein the second preset standard is used to indicate the corresponding data type and data length of each field of the normal request information.

[0033] Through the above steps, in an embodiment of the present application, the type of the end to be tested is determined, wherein the type includes one of the following: a front-end device, an interface of a back-end device; when the type of the end to be tested is a front-end device, the normal response information of the back-end device is adjusted to generate abnormal response information that does not meet the first preset standard, and the abnormal response information is sent to the front-end device to determine the fault tolerance of the front-end device, wherein the first preset standard is used to indicate the corresponding data type and data length of each field of the normal response information; when the type of the end to be tested is an interface of a back-end device, the normal request information of the front-end device is adjusted to generate abnormal request information that does not meet the second preset standard, and the abnormal request information is sent to the interface of the back-end device to determine the fault tolerance of the interface of the back-end device, wherein the second preset standard is used to indicate the corresponding data type and data length of each field of the normal request information; the present application can comprehensively test the fault tolerance of the interface and the front-end by automatically generating input parameters and output parameters that do not meet the preset standards, improve the test coverage, avoid artificial omission of test scenarios, and improve the user experience. Therefore, the above technical solution is adopted to solve the problem that different input parameters and output parameters need to be manually combined when testing the front-end device and / or interface, resulting in low test parameter coverage.

[0034] Optionally, in order to better understand the above-mentioned step S204, the above-mentioned step S204 can be implemented in the following manner: determine the first preset standard corresponding to the normal response information; adjust the data in the field of the normal response information according to the first preset standard to generate the abnormal response information, wherein the data of at least one field in the abnormal response information does not meet the first preset standard.

[0035] In an embodiment of the present application, a method is provided for how a Mock service generates abnormal response information to test the fault tolerance of the front end. Specifically, when the Mock service obtains normal response information, it determines the data type and data length limit corresponding to the current normal response information in the database, that is, the first preset standard; for example, the data type of the field "success" is Boolean, and the data type of the field "message" is string. Based on the determined first preset standard, the Mock service will automatically modify the field data in the normal response information so that these data no longer meet the preset data type or length requirements. For example, a "success" field value that should be a Boolean type is modified to a non-Boolean value, such as an integer 1, or the length of a string field is modified to exceed its maximum allowed length. The generated abnormal response information will be sent to the front end to test the processing ability of the front end when receiving data that does not meet expectations. The front end should be able to handle these abnormal information correctly, for example, by displaying friendly error messages instead of crashing or displaying error pages.

[0036] It should be noted that the above-mentioned normal response information can be understood as the response information returned by the back-end interface to the front-end when it operates normally.

[0037] Through the embodiments of the present application, various possible error scenarios can be simulated, such as data type error, data length overflow, etc., so as to comprehensively evaluate the exception handling capability of the front-end device and ensure that the front-end device can handle various unexpected responses correctly to avoid crashes or display errors.

[0038] Optionally, adjusting the data in the field of the normal response information according to the first preset standard includes at least one of the following: adjusting the data type of the data in the field of the normal response information so that the adjusted data type does not conform to the first preset standard; adjusting the data length of the data in the field of the normal response information so that the adjusted data length does not conform to the first preset standard.

[0039] That is to say, when adjusting the data, it can be achieved in the following two ways, specifically:

[0040] 1) Data type adjustment: In normal interface response information, the data type of each field is clearly specified, for example, a field may be required to be a Boolean type (bool), and another field may be required to be a string type (string). The MOCK service can identify these preset data types and change the data types of these fields, such as setting a field that should be a bool type to a string type, or setting a field that should be a string type to an int type.

[0041] 2) Data length adjustment: In addition to data types, field data length (or size) is also a common restriction in interface definitions. For example, a field may be limited to contain a maximum of 50 characters. The MOCK service will generate data that exceeds the preset length based on these length restrictions, such as setting a field that should be 50 characters to 100 characters, in order to test the interface's ability to handle data that exceeds the length limit.

[0042] Through the above two methods, the MOCK service can systematically and automatically generate abnormal data that does not match the normal response information, thereby comprehensively testing the robustness of the interface and the fault tolerance of the front end. The embodiment of the present application improves the coverage and efficiency of the test, reduces human errors, and ensures the stability and security of the software when facing irregular data input.

[0043] Optionally, in order to better understand the above-mentioned step S206, the above-mentioned step S206 can be implemented in the following manner: determine the second preset standard corresponding to the normal request information; adjust the data in the field of the normal request information according to the second preset standard to generate the abnormal request information, wherein the data of at least one field in the abnormal request information does not meet the second preset standard.

[0044] In the embodiment of the present application, a method is provided for automatically generating abnormal request information in a Mock service to test the fault tolerance of an interface. Specifically:

[0045] When the mock service obtains normal request information, it determines the data type and data length limit corresponding to the current normal request information in the database. For example, if the data type of an API request field "age" is preset to an integer (int) and the data length is preset to not exceed 3 digits, then the input that meets the standard can be a number from 1 to 999. By changing the data type or length of the field in the normal response information so that it does not meet the original preset standard, it is converted into abnormal request information. For example, the normal response data of the field "age" is adjusted from an integer type to a string type, or its length is extended from the preset 3 digits to more than 4 digits, so that the generated data no longer meets the preset standard.

[0046] Through the above adjustment, the Mock service can generate a series of abnormal request information, which contains at least one field whose data does not meet the second preset standard. These abnormal request information can be various, such as setting the value of the "age" field to "100years", which not only changes the data type but also exceeds the data length limit, which is typical abnormal data.

[0047] Through the embodiments of the present application, the Mock service can comprehensively test the fault tolerance of the interface, ensuring that the interface can respond correctly in various abnormal situations instead of crashing or producing erroneous results, thereby improving the stability of the software and user experience. And the process of automatically generating abnormal request information can cover a wider range of abnormal scenarios, avoiding scenarios that may not be considered during manual testing due to negligence or experience limitations, thereby improving the integrity and efficiency of the test.

[0048] Optionally, the exception response information is sent to the front-end device to determine the fault tolerance capability of the front-end device, including: obtaining a display result of the front-end device, wherein the display result is a display result corresponding to the exception response information; determining the fault tolerance capability of the front-end device according to the display result; the exception request information is sent to the interface of the back-end device to determine the fault tolerance capability of the interface of the back-end device, including: obtaining response information of the interface of the back-end device; and determining the fault tolerance capability of the interface of the back-end device according to the response information.

[0049] That is to say, in the above embodiment, a method of how the MOCK service tests the fault tolerance of the front-end device and the back-end device interface is provided, which is specifically divided into two parts:

[0050] 1) Test the fault tolerance of front-end equipment:

[0051] First, the MOCK service generates a series of abnormal response information that is intentionally inconsistent with the expected format or content, such as type error, length limit exceeded, etc., in order to simulate possible errors in the backend. The MOCK service sends these abnormal response messages to the front-end device to test how the front-end device handles this information. After receiving the abnormal response information, the front-end device will try to parse and display it. The MOCK service will observe and record the display results of the front-end device to confirm whether there are error prompts, page crashes, or no response. Based on the display results, the MOCK service evaluates the fault tolerance of the front-end device, that is, whether the front-end device can correctly handle the abnormal response information when it receives it, avoid abnormalities in the user interface, and ensure user experience.

[0052] 2) Test the fault tolerance of the back-end device interface:

[0053] The MOCK service will automatically combine a series of abnormal request information that does not meet the requirements based on the input parameter format and length requirements of the interface, simulating the erroneous requests that may be sent by the front end. These abnormal request information are sent to the interface of the back-end device to simulate the actual request scenario and test how the back-end interface handles these abnormal requests. The MOCK service monitors the response of the back-end interface to check whether the error code and error information are returned, and whether the interface can be closed normally or provide some default response information instead of directly crashing or being unresponsive. Based on the response information of the back-end interface, the MOCK service evaluates the fault tolerance of the back-end interface, that is, whether the interface can give reasonable error feedback when receiving abnormal request information to avoid system-level failures.

[0054] That is, the MOCK service generates and sends exception information to test the system's fault tolerance from two perspectives: front-end display and back-end interface response. This ensures that when unexpected input occurs, the system can run stably without crashing or giving misleading information, which is crucial to improving the stability of the software system and user experience. This method can fully cover possible abnormal situations, reduce test blind spots, and improve test efficiency and effectiveness.

[0055] Optionally, after sending the exception response information to the front-end device to determine the fault tolerance capability of the front-end device, the method further includes: when the fault tolerance capability of the front-end device does not meet the first preset fault tolerance capability, optimizing the display logic and exception handling mechanism of the front-end device; after sending the exception request information to the interface of the back-end device to determine the fault tolerance capability of the interface of the back-end device, the method further includes: when the fault tolerance capability of the front-end device does not meet the second preset fault tolerance capability, optimizing the verification logic of the front-end device, wherein the verification logic is used to verify the received request information.

[0056] In other words, the exception response information generated by the MOCK service is to test the performance of the front-end device (such as H5, APP, applet, Web, etc.) when receiving unexpected data. By analyzing the front-end device's handling of the exception response, it can be determined whether its fault tolerance meets the first preset fault tolerance standard. If the front-end device fails to properly handle the exception response, resulting in display logic confusion or failure of the exception handling mechanism, it means that its fault tolerance is insufficient.

[0057] When it is found that the fault tolerance of the front-end device does not meet expectations, the target object (such as developers) needs to optimize the display logic and exception handling mechanism of the front-end device. For example: enhance data verification, improve error capture and processing flow, or adjust the dynamic response mechanism of UI elements to ensure that the front-end device can maintain stable operation when receiving any type of abnormal response, avoiding degradation of user experience or the emergence of security vulnerabilities.

[0058] And the abnormal request information generated by the MOCK service is used to test the fault tolerance of the backend device interface. To verify whether the backend interface can correctly handle unexpected request information without crashing or generating an error response. If the fault tolerance of the backend interface does not meet the standard, that is, it does not meet the second preset fault tolerance, then the verification logic of the request information needs to be optimized.

[0059] After evaluating the fault tolerance of the backend device interface, if it performs poorly, the target object (such as developers) needs to optimize the request information verification logic of the interface. This may include enhancing type checking, adding data length verification, or implementing stricter data format verification to ensure that the interface can handle various abnormal situations without causing service interruptions or data processing errors due to incorrect request information.

[0060] Through continuous testing and optimization, MOCK service can ensure that the software can run stably in various expected and unexpected situations, thereby improving the overall development quality and user experience.

[0061] Optionally, before the above-mentioned step S202, it also includes: obtaining request information sent by the front-end device, wherein, when the end to be tested is a front-end device, the normal response information is the response information corresponding to the request information, and when the end to be tested is the interface of the back-end device, the request information is the normal request information; determining whether to allow the fault tolerance capability of the end to be tested to be determined based on the request information according to a preset whitelist, wherein the preset whitelist includes at least one of the following: a user identification whitelist, a device identification whitelist, a version number whitelist, an Internet Protocol address whitelist, and an interface uniform resource locator whitelist.

[0062] The embodiment of the present application provides a method for determining whether to allow a request through a preset whitelist mechanism when processing request information, and further testing the fault tolerance capability of the tested end (which may be the front end or the back end) if allowed, specifically:

[0063] When the end to be tested is a front-end device, the normal response information refers to the correct response returned by the back-end device to the front-end after receiving the request. When the end to be tested is the interface of the back-end device, the fault tolerance of the back-end interface is tested by constructing abnormal request information.

[0064] The whitelist mechanism is an access control strategy that allows specific users, devices, versions, IP addresses or interface URLs to access the system, while other requests not in the whitelist will be rejected. This allows only specific test requests to pass during the test, while ensuring that the normal operation of the system is not affected by the test.

[0065] The preset whitelist includes at least five types: user ID, device ID, version number, IP address and interface URL. Therefore, the system can filter according to different dimensions of the request source, increasing the flexibility and security of the test environment.

[0066] In order to better understand the process of the above-mentioned method for determining fault tolerance capability, the implementation process of the above-mentioned method for determining fault tolerance capability is described below in combination with an optional embodiment, but it is not used to limit the technical solution of the embodiment of the present application.

[0067] In this embodiment, a method for determining fault tolerance is provided. Figure 3 is a flow chart of storing data preset values ​​according to an embodiment of the present application, such as Figure 3 As shown, the details are as follows:

[0068] Import the interface document (for example, a json format file) corresponding to the interface into the database corresponding to the Mock service in advance, indicate the type and length requirements of the request and response fields, and record the unexpected type and length of each field.

[0069] Optionally, in an embodiment of the present application, a method for testing a front-end device is also provided. Figure 4 is a timing diagram of a test front-end device according to an embodiment of the present application, such as Figure 4 As shown, specifically including:

[0070] Step S401: the front end (equivalent to the front end device in the above embodiment) requests MOCK service according to the white list;

[0071] It should be noted that only specified users or user groups are allowed to access the Mock service, and other users can access the system server normally. Therefore, a whitelist strategy is set, for example:

[0072] 1) User ID whitelist: Create a whitelist based on user ID to allow specific users to access the Mock service.

[0073] 2) Device ID whitelist: Allow specific device IDs to access the Mock service.

[0074] 3) Version number whitelist: Allow users running specific application versions to access the Mock service.

[0075] 4) IP whitelist: Allow specific IPs to access the Mock service.

[0076] 5) Interface URL whitelist: Allow specific interface URLs to access the Mock service.

[0077] Step S402: the Mock service web layer sends the interface request (equivalent to the request information in the above embodiment) to the system server;

[0078] Step S403: Send the response information of the system server (equivalent to the normal response information in the above embodiment) to the Mock service logic layer;

[0079] Step S404: The mock service logic layer will match the corresponding interface response information in the preset information according to the URL (URL+response information) in the received information, and generate and combine all response combinations that do not meet the expectations (equivalent to the abnormal response information in the above embodiment) according to the conditions in the preset information (equivalent to the first preset standard in the above embodiment).

[0080] For example:

[0081] Normal output parameters of the interface:

[0082] "success":true,

[0083] "message":null,

[0084] }.

[0085] success: bool type, must be true or false;

[0086] message: string type.

[0087] The abnormal data is:

[0088] success:1;

[0089] success:"abc";

[0090] success: null;

[0091] message: 1;

[0092] message: true;

[0093] Abnormal data combinations: There are 6 combinations of the above two data types.

[0094] example:{

[0095] "success":1,

[0096] "message":true,

[0097] }.

[0098] {

[0099] "success": null,

[0100] "message": 1,

[0101] }.

[0102] Step S405: Send the response combination that does not meet the expectation to the Mock service web layer;

[0103] Step S406: The Mock service web layer sends the response combination that does not meet the expectations to the front end;

[0104] Step S407: The front end (H5, app, mini program, web) will display the response information of the interface that does not meet expectations.

[0105] Optionally, in the embodiment of the present application, a method for testing the interface is also provided. Figure 5 is a timing diagram of a test interface according to an embodiment of the present application, such as Figure 5 As shown, specifically including:

[0106] Step S501: the front end (equivalent to the front end device in the above embodiment) requests MOCK service according to the white list;

[0107] Step S502: the Mock service web layer sends the interface request (equivalent to the request information in the above embodiment) to the Mock service logic layer;

[0108] Step S503: the logic layer matches the corresponding interface request information in the preset information according to the URL in the received request information (URL, request body), and generates and combines all request combinations that do not meet the expectations (equivalent to the abnormal request information in the above embodiment) according to the conditions in the preset information;

[0109] Specifically: 1) According to the input parameter type of the interface, match the non-conforming type (all data types have been set in advance in the mock service code);

[0110] 2) According to the length limit, match the length limit that does not meet the requirement;

[0111] According to the above two steps, the data value that does not meet the requirements for each input parameter is obtained, and then all the input parameter field combinations in the interface are obtained;

[0112] For example:

[0113] Normal interface input parameters: {

[0114] "flag":true,

[0115] "data":null,

[0116] }.

[0117] flag: bool type, must be true or false;

[0118] data: string type;

[0119] The abnormal data is:

[0120] flag:1;

[0121] flag:"abc";

[0122] flag: null;

[0123] data:1;

[0124] data: true;

[0125] Abnormal data combinations: There are 6 combinations of the above two data types.

[0126] Unusual data combinations, such as:

[0127] {

[0128] "flag":1,

[0129] "data":true,

[0130] }.

[0131] {

[0132] "flag": null,

[0133] "data": 1,

[0134] }.

[0135] Step S504: the logic layer sends the request combination that does not meet the expectation to the system server;

[0136] Step S505: Sending the response information of the system server to the interface tool;

[0137] Step S506: The test interface returns.

[0138] In an embodiment of the present application, according to the input parameter format and length of the interface, all data that do not meet the input parameter specifications are automatically combined to generate multiple groups of input parameters that do not meet the requirements, and these input parameters are used to request the interface; according to the output parameter setting of the interface, all output parameter data that do not meet the requirements are automatically combined to generate multiple groups of output parameters that do not meet the requirements, and the output parameters are returned to the front end; the interface information is imported in advance, the expected value of the interface field is obtained, and according to the expected type and length, the unexpected type and length are obtained and recorded.

[0139] Through the above embodiments, the MOCK service can simulate real service behaviors or specific service behaviors, improve test efficiency, and ensure test quality; test service stability and security in advance to avoid problems such as system crashes or data leaks caused by malicious attacks or misoperations.

[0140] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods of each embodiment of the present application.

[0141] Figure 6 is a structural block diagram of a device for determining fault tolerance according to an embodiment of the present application; Figure 6 As shown, including:

[0142] The determination module 62 is used to determine the type of the end to be tested, wherein the type includes one of the following: an interface of a front-end device or a back-end device;

[0143] A first test module 64 is used for adjusting the normal response information of the back-end device to generate abnormal response information that does not meet the first preset standard when the type of the end to be tested is a front-end device, and sending the abnormal response information to the front-end device to determine the fault tolerance capability of the front-end device, wherein the first preset standard is used to indicate the corresponding data type and data length of each field of the normal response information;

[0144] The second test module 66 is used to adjust the normal request information of the front-end device when the type of the tested end is the interface of the back-end device to generate abnormal request information that does not meet the second preset standard, and send the abnormal request information to the interface of the back-end device to determine the fault tolerance capability of the interface of the back-end device, wherein the second preset standard is used to indicate the corresponding data type and data length of each field of the normal request information.

[0145] Through the above-mentioned device, in an embodiment of the present application, the type of the end to be tested is determined, wherein the type includes one of the following: a front-end device, an interface of a back-end device; when the type of the end to be tested is a front-end device, the normal response information of the back-end device is adjusted to generate abnormal response information that does not meet the first preset standard, and the abnormal response information is sent to the front-end device to determine the fault tolerance capability of the front-end device; when the type of the end to be tested is an interface of a back-end device, the normal request information of the front-end device is adjusted to generate abnormal request information that does not meet the second preset standard, and the abnormal request information is sent to the interface of the back-end device to determine the fault tolerance capability of the interface of the back-end device; the present application can comprehensively test the fault tolerance of the interface and the front-end by automatically generating input parameters and output parameters that do not meet the preset standards, improve test coverage, avoid artificial omission of test scenarios, and improve user experience. Therefore, the above-mentioned technical solution is adopted to solve the problem of low test parameter coverage caused by the need to manually combine different input parameters and output parameters when testing the front-end device and / or interface.

[0146] In an exemplary embodiment, the first test module 64 is used to determine the first preset standard corresponding to the normal response information; adjust the data in the field of the normal response information according to the first preset standard to generate the abnormal response information, wherein the data in at least one field in the abnormal response information does not meet the first preset standard.

[0147] In an exemplary embodiment, the first test module 64 is used to perform at least one of the following: adjusting the data type of the data in the field of the normal response information so that the adjusted data type does not conform to the first preset standard; adjusting the data length of the data in the field of the normal response information so that the adjusted data length does not conform to the first preset standard.

[0148] In an exemplary embodiment, the second test module 66 is used to determine the second preset standard corresponding to the normal request information; adjust the data in the field of the normal request information according to the second preset standard to generate the abnormal request information, wherein the data of at least one field in the abnormal request information does not meet the second preset standard.

[0149] In an exemplary embodiment, the first test module 64 is used to obtain a display result of the front-end device, wherein the display result is a display result corresponding to the abnormal response information; and determine the fault tolerance capability of the front-end device according to the display result.

[0150] In an exemplary embodiment, the second test module 66 is used to obtain response information of the interface of the backend device; and determine the fault tolerance capability of the interface of the backend device according to the response information.

[0151] In an exemplary embodiment, the above-mentioned device also includes: an optimization module, which is used to optimize the display logic and exception handling mechanism of the front-end device when the fault tolerance capability of the front-end device does not meet the first preset fault tolerance capability; when the fault tolerance capability of the front-end device does not meet the second preset fault tolerance capability, optimize the verification logic of the front-end device, wherein the verification logic is used to verify the received request information.

[0152] In an exemplary embodiment, a determination module 62 is used to obtain request information sent by a front-end device, wherein, when the end to be tested is a front-end device, the normal response information is the response information corresponding to the request information, and when the end to be tested is an interface of the back-end device, the request information is the normal request information; and determine whether to allow the fault tolerance capability of the end to be tested to be determined based on the request information according to a preset whitelist, wherein the preset whitelist includes at least one of the following: a user identification whitelist, a device identification whitelist, a version number whitelist, an Internet Protocol address whitelist, and an interface uniform resource locator whitelist.

[0153] An embodiment of the present application further provides a storage medium, which includes a stored program, wherein the program executes any of the above methods when it is run.

[0154] Optionally, in this embodiment, the storage medium may be configured to store program codes for executing the following steps:

[0155] S1, determining the type of the end to be tested, wherein the type includes one of the following: an interface of a front-end device or a back-end device;

[0156] S2, when the type of the end to be tested is a front-end device, adjusting the normal response information of the back-end device to generate abnormal response information that does not meet a first preset standard, and sending the abnormal response information to the front-end device to determine the fault tolerance capability of the front-end device, wherein the first preset standard is used to indicate the corresponding data type and data length of each field of the normal response information;

[0157] S3. When the type of the end to be tested is the interface of a backend device, the normal request information of the frontend device is adjusted to generate abnormal request information that does not meet the second preset standard, and the abnormal request information is sent to the interface of the backend device to determine the fault tolerance capability of the interface of the backend device, wherein the second preset standard is used to indicate the corresponding data type and data length of each field of the normal request information.

[0158] An embodiment of the present application further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0159] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0160] Optionally, in this embodiment, the processor may be configured to perform the following steps through a computer program:

[0161] S1, determining the type of the end to be tested, wherein the type includes one of the following: an interface of a front-end device or a back-end device;

[0162] S2, when the type of the end to be tested is a front-end device, adjusting the normal response information of the back-end device to generate abnormal response information that does not meet a first preset standard, and sending the abnormal response information to the front-end device to determine the fault tolerance capability of the front-end device, wherein the first preset standard is used to indicate the corresponding data type and data length of each field of the normal response information;

[0163] S3. When the type of the end to be tested is the interface of a backend device, the normal request information of the frontend device is adjusted to generate abnormal request information that does not meet the second preset standard, and the abnormal request information is sent to the interface of the backend device to determine the fault tolerance capability of the interface of the backend device, wherein the second preset standard is used to indicate the corresponding data type and data length of each field of the normal request information.

[0164] Optionally, in this embodiment, the above-mentioned storage medium may include but is not limited to: a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and other media that can store program codes.

[0165] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any one of the above method embodiments are implemented.

[0166] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above method embodiments are implemented.

[0167] The embodiments of the present application also provide a computer program, which includes computer instructions, which are stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the steps in any one of the above method embodiments.

[0168] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be described in detail here.

[0169] Obviously, those skilled in the art should understand that the above modules or steps of the present application can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, and optionally, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order from that herein, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present application is not limited to any specific combination of hardware and software.

[0170] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for determining fault tolerance, characterized in that: include: Determine the type of the end to be tested, wherein the type includes one of the following: an interface of a front-end device or a back-end device; In the case where the type of the end to be tested is a front-end device, the normal response information of the back-end device is adjusted to generate abnormal response information that does not meet the first preset standard, and the abnormal response information is sent to the front-end device to determine the fault tolerance capability of the front-end device, wherein the first preset standard is used to indicate the corresponding data type and data length of each field of the normal response information; in the case where the type of the end to be tested is an interface of a back-end device, the normal request information of the front-end device is adjusted to generate abnormal request information that does not meet the second preset standard, and the abnormal request information is sent to the interface of the back-end device to determine the fault tolerance capability of the interface of the back-end device, wherein the second preset standard is used to indicate the corresponding data type and data length of each field of the normal request information.

2. The method for determining fault tolerance according to claim 1, characterized in that: The normal response information of the backend device is adjusted to generate abnormal response information that does not meet the first preset standard, including: Determining the first preset standard corresponding to the normal response information; The data in the fields of the normal response information are adjusted according to the first preset standard to generate the abnormal response information, wherein the data in at least one field of the abnormal response information does not meet the first preset standard.

3. The method for determining fault tolerance according to claim 2, characterized in that: Adjusting the data in the field of the normal response information according to the first preset standard includes at least one of the following: Adjusting the data type of the data in the field of the normal response information so that the adjusted data type does not meet the first preset standard; The data length in the field of the normal response information is adjusted so that the adjusted data length does not meet the first preset standard.

4. The method for determining fault tolerance according to claim 1, characterized in that: Adjusting the normal request information of the front-end device to generate abnormal request information that does not meet the second preset standard includes: Determining the second preset standard corresponding to the normal request information; The data in the fields of the normal request information are adjusted according to the second preset standard to generate the abnormal request information, wherein the data in at least one field of the abnormal request information does not meet the second preset standard.

5. The method for determining fault tolerance according to claim 1, characterized in that: Sending the abnormal response information to the front-end device to determine the fault tolerance capability of the front-end device includes: Acquire a display result of the front-end device, wherein the display result is a display result corresponding to the abnormal response information; determine the fault tolerance capability of the front-end device according to the display result; The abnormal request information is sent to the interface of the backend device to determine the fault tolerance capability of the interface of the backend device, including: obtaining response information of the interface of the backend device; and determining the fault tolerance capability of the interface of the backend device according to the response information.

6. The method for determining fault tolerance according to claim 1, characterized in that: After sending the exception response information to the front-end device to determine the fault tolerance capability of the front-end device, the method further includes: optimizing the display logic and exception handling mechanism of the front-end device when the fault tolerance capability of the front-end device does not meet the first preset fault tolerance capability; After sending the abnormal request information to the interface of the back-end device to determine the fault tolerance capability of the interface of the back-end device, the method further includes: when the fault tolerance capability of the front-end device does not meet the second preset fault tolerance capability, optimizing the verification logic of the front-end device, wherein the verification logic is used to verify the received request information.

7. The method for determining fault tolerance according to claim 1, characterized in that: Before determining the type of the terminal to be tested, the method further includes: Obtaining request information sent by the front-end device, wherein, when the end to be tested is a front-end device, the normal response information is the response information corresponding to the request information, and when the end to be tested is an interface of the back-end device, the request information is the normal request information; Determine whether to allow the fault tolerance capability of the tested end to be determined based on the request information according to a preset whitelist, wherein the preset whitelist includes at least one of the following: a user identification whitelist, a device identification whitelist, a version number whitelist, an Internet Protocol address whitelist, and an interface uniform resource locator whitelist.

8. A device for determining fault tolerance, characterized in that: include: A determination module, used to determine the type of the end to be tested, wherein the type includes one of the following: an interface of a front-end device or a back-end device; A first test module, configured to adjust the normal response information of the back-end device to generate abnormal response information that does not meet a first preset standard, and send the abnormal response information to the front-end device to determine the fault tolerance capability of the front-end device, when the type of the end to be tested is a front-end device, wherein the first preset standard is used to indicate the corresponding data type and data length of each field of the normal response information; The second test module is used to adjust the normal request information of the front-end device when the type of the tested end is the interface of the back-end device to generate abnormal request information that does not meet the second preset standard, and send the abnormal request information to the interface of the back-end device to determine the fault tolerance capability of the interface of the back-end device, wherein the second preset standard is used to indicate the corresponding data type and data length of each field of the normal request information.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein the program executes the method described in any one of claims 1 to 7 when executed.

10. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to execute the method according to any one of claims 1 to 7 through the computer program.

Images