Exploratory test method and system for travel SAAS (Software as Service)

Abstract

The invention discloses an exploratory test method and system for travel SAAS (Software as a Service). The invention relates to the technical field of SAAS platforms. And loading a prefabricated fuzzy test template rule base, and preparing a rule template for subsequent selection. And configuring a target service and a service interface, wherein the service interface comprises a machine IP of the tested service and a Swagger interface address. And selecting a part of rules from the rule base as a rule template of the test. Selecting a proper rule combination to cover the abnormal input scene according to the characteristics of the test target and the service interface; and traversing the selected interfaces, and initiating a fuzzy test request for each interface. In the request process, the enumeration value or the default value of the target field is replaced; by introducing the fuzzy test template rule base and automatically generating abnormal input data of various types, lengths and the like, the test range can be remarkably expanded, more boundary conditions and abnormal scenes which are difficult to touch by a traditional test method can be covered, and thus the overall test coverage rate is increased.

Description

Technical Field

[0001] The present invention relates to the technical field of SAAS platform, and in particular to business logic testing, and in particular to an exploratory testing method and system for travel SAAS. Background Art

[0002] SaaS (Software as a Service) is a model that provides software services to different companies through the Internet. Its core lies in providing an efficient and stable service system. Due to the extensiveness and immediacy of SaaS services, system stability has become one of the key indicators for measuring its service quality. Ensuring the stability of the SaaS system is not only related to user experience, but also directly affects the reputation and market competitiveness of the service provider.

[0003] In the testing practice of SaaS systems, the testing coverage of the business logic layer is relatively sufficient. This type of testing mainly focuses on the correctness of system functions, the integrity of business processes, and the convenience of user operations, and verifies the performance of the system by simulating actual business scenarios. However, with the increase in system complexity and the frequent interface interactions, it is difficult to fully guarantee the stability of the system by relying solely on business logic testing.

[0004] In particular, in the interface protocol dimension, the system faces more complex challenges. The interface protocol defines the specifications and conventions for interactions between systems, including data types, lengths, formats, and other aspects. When the parameters received by the interface do not meet these specifications, such as data type mismatch, length exceeding the limit, etc., it may cause system abnormalities or crashes, thereby reducing the stability of the business system. Such problems are often difficult to fully cover in daily business logic testing because they are more related to system boundary conditions and exception handling mechanisms.

[0005] Currently, most test coverage methods for service interface protocols are manual testing. Although manual testing can flexibly cope with various test scenarios, it is unable to cope with a large number of abnormal parameters. On the one hand, manual testing is difficult to exhaust all possible abnormal parameter combinations, resulting in loopholes in test coverage; on the other hand, manual testing is inefficient and cannot quickly respond to test requirements brought about by system changes and upgrades.

[0006] Therefore, in order to effectively solve the problem of reduced system stability caused by abnormal parameters such as input parameter data type and length in the interface protocol dimension, it is necessary to explore more efficient and comprehensive testing methods. Specifically, it should be used as a supplement to the missing items in the manual test scenario of business logic, and comprehensive coverage of interface protocol exceptions can be achieved through automated testing technology, abnormal parameter generation algorithms and other means. This will not only improve testing efficiency, but also ensure that the system can maintain stable and reliable performance in the face of various abnormal parameters, thereby further improving the overall quality of SaaS services and user satisfaction.

[0007] To this end, the present invention proposes an exploratory testing method and system for travel SAAS. Summary of the invention

[0008] In view of this, the present invention hopes to provide an exploratory testing method and system for travel SAAS to solve or alleviate the technical problems existing in the prior art, that is, to provide a fast verification method for abnormal data input such as parameter type and length in the service interface protocol dimension, mainly to solve the problem of test coverage omissions caused by inconsistent interface protocols with the design, and to provide at least a beneficial option for this; the technical solution of the present invention is implemented as follows:

[0009] First, exploratory testing methods for travel SAAS:

[0010] 1. Overview:

[0011] The present invention provides a systematic abnormal input testing method for the target service by constructing a fuzzy test template rule library. It uses the Swagger interface address to obtain the definition and information of the service interface, and then selects a suitable rule template as the basis for this test. Through these rule templates, the scheme can generate diversified test data, simulate various abnormal input scenarios, and conduct a comprehensive test on the target service. During the test process, the scheme records the parameters and results of each request, and pays special attention to the content in the response code, response message or response body to determine whether the service handles the abnormal input properly. Once an abnormality is found, the scheme records the abnormal details in detail to provide strong support for subsequent analysis and repair. In this way, the scheme aims to improve the robustness and reliability of the target service and ensure that it can run stably in the face of various abnormal inputs.

[0012] (II) Technical solution:

[0013] In order to achieve the above technical objectives, the present invention selects to execute the following operation steps.

[0014] 2.1 Step S1, initialization configuration:

[0015] Load the pre-made fuzz test template rule library and prepare the rule template for subsequent selection. Configure the target service and service interface, including the machine IP and Swagger interface address of the tested service. Select a part of the rules from the rule library as the rule template for this test. According to the characteristics of the test target and service interface, select the appropriate rule combination to cover the abnormal input scenario.

[0016] 2.1.1 Step S100, load the pre-made fuzz test template rule library:

[0017] Load the pre-built fuzz test template rule base file from the storage system; load the completed rule base for selection and use in subsequent steps.

[0018] 2.1.2 Step S101, configure the target service and service interface:

[0019] Enter the machine IP address of the service under test to ensure that the test system can access the target service.

[0020] Enter or obtain the Swagger interface address of the target service to obtain the definition, request method, and parameter list information of the service interface.

[0021] Output: Configured target service and service interface information.

[0022] 2.1.3 Step S102, select a part of rules from the rule library as the rule template for this test:

[0023] Browse the loaded rule library, filter and combine rules according to the characteristics of the parameter type and length limit of the service interface and the test target of the specific type of exception handling problem; make the final rule combination fully cover the abnormal input scenario, and improve the coverage and effectiveness of the test.

[0024] 2.2 Step S2, simulate interface call preparation:

[0025] Parse the Swagger interface document to obtain the interface location, request method, and parameter column information; activate the test data generation algorithm to generate real data that complies with the rules according to the rule template settings.

[0026] Traverse the selected interfaces and initiate fuzz test requests for each interface. During the request process, replace the enumeration value or default value of the target field and use the generated real data as the test value. Record detailed information of each request, including request time, request parameters, and request results.

[0027] 2.2.1 Step S200, parse the Swagger interface document:

[0028] Use the Swagger parsing tool or library to read and parse the Swagger interface document of the target service. Obtain the URL path, GET or POST request method, and parameter list information (including parameter name, type, and whether it is required) of the interface.

[0029] 2.2.2 Step S201, activating the test data generation algorithm:

[0030] According to the rule template selected in step S1, the corresponding test data generation algorithm is activated to generate a real data set including test data of various types, lengths and formats.

[0031] 2.2.3 Step S202, traverse the selected interface:

[0032] Traverse the interfaces selected in step S1 and prepare to initiate fuzz test requests one by one; for each interface, construct a test request based on the parsed interface information and the generated real data; during the request process, replace the enumeration value or default value of the target field and use the generated real data as the test value. For example, for a parameter that requires a user ID, it can be replaced with the generated real user ID for testing.

[0033] 2.2.4 Step S203, record detailed information of each request:

[0034] When initiating each request, the request time, request parameters (such as URL, request header, request body, etc.) and request results (such as response code, response message, response body, etc.) are recorded. This provides detailed data support for subsequent result analysis and exception records, making it easier to track and locate problems. The output is included as part of the request log or test report, including detailed information about each request.

[0035] 2.3 Step S3, processing the test response:

[0036] Receive and process the response data returned by the interface. Determine whether the response is abnormal based on the response code, response message, or the content in the response body. Mark the abnormal response and record the abnormal details.

[0037] 2.3.1 Step S300, receiving response data:

[0038] After initiating a fuzz test request, receive the response data returned by the target service interface; obtain the processing result of the interface for the test request; output the received response data, including the response code, response message and response body.

[0039] 2.3.2 Step S301, analyzing response data:

[0040] Perform detailed analysis of the received response data, including checking the response code, response message, and the content in the response body:

[0041] Response code: Determine whether the response code indicates success (such as HTTP 200) or an error (such as HTTP 4xx or 5xx);

[0042] Response message: Analyze whether the response message contains error prompts or warning information;

[0043] Response body: Check whether the content in the response body meets expectations, such as data format, field value, etc.;

[0044] 2.3.3 Step S302, determine whether the response is abnormal:

[0045] If the response code indicates an error, or the response message contains an error prompt, or the content in the response body does not meet expectations, the response is considered abnormal.

[0046] 2.3.4 Step S303, marking the abnormal response:

[0047] Mark the abnormal response as abnormal; for each abnormal response, record its abnormal details in detail, including the abnormal type, abnormal description, occurrence time, related request parameters and response data; output the abnormal detail record, which can be used as part of the test report or stored separately for subsequent analysis.

[0048] Provide detailed data support for subsequent exception handling and problem tracking, so that developers can quickly locate and fix problems.

[0049] 2.4 Step S4, output fuzz test request result:

[0050] Output the results of each test request to a specified log file or database. The results include detailed information about successful requests and failed requests (i.e., abnormal requests).

[0051] Filter the results of abnormal requests and export abnormal data; analyze the abnormal results and generate a test report, including statistical abnormal types and analysis of abnormal causes.

[0052] 2.4.1 Step S400, output the test request result to a log file or database:

[0053] The result of each test request, whether successful or failed (i.e., abnormal), is recorded in the specified log file or database; including the request time, request parameters, response code, response message, response body, and any related exception information.

[0054] 2.4.2 Step S401, filter the results of abnormal requests:

[0055] From the recorded test request results, filter out all requests marked as abnormal (i.e., failed) and export them to a separate file or data table. The exported data includes request parameters, response data, exception type, and exception description.

[0056] 2.4.3 Step S402, analysis operation:

[0057] Classify exceptions, including input validation errors, internal server errors, and timeout errors, and count the number of each type of exceptions; generate a test report based on the results of exception analysis.

[0058] (III) Mechanism for solving technical problems:

[0059] Build a fuzz test template rule library, which contains various parameter type, length, format and other verification rules. According to the definition of the target service interface protocol, select the appropriate rule template from the rule library as the test basis. Use the selected rule template to automatically generate test data that meets the protocol requirements and abnormal data that does not meet the protocol requirements. Automatically initiate requests for these test data to simulate actual user or system operations.

[0060] Monitor the target service's response to the test request, and record the response code, response message, and response body content. Analyze the response data to determine whether the service interface correctly handles normal and abnormal input data. If it is found that the service interface does not handle abnormal input as expected, record the abnormal details in detail. Generate a test report, summarize the test results, and point out potential interface protocol inconsistencies.

[0061] Second, the exploratory testing system for travel SAAS:

[0062] like Figure 4 As shown, the system is used to implement the exploratory testing method for travel SAAS described above, which includes:

[0063] (1) Configuration management layer: including the configuration management module and the rule base loading module; responsible for loading the fuzz test template rule base, configuring the relevant information of the target service and interface, and selecting the appropriate rule template from the rule base as the benchmark for this test.

[0064] (2) Test generation layer: includes a data generation module and an abnormal data construction module; based on the rule templates provided by the configuration management layer, it automatically generates test data that meets the protocol requirements and abnormal data that does not meet the protocol requirements.

[0065] (3) Test execution layer: including request sending module, response receiving module and logging module. It is responsible for initiating test requests to the target service interface, simulating the operation of actual users or systems, and recording detailed information of each request.

[0066] (4) Result analysis layer: includes response analysis module, exception recording module and report generation module; analyzes the response data returned by the test execution layer, determines whether the service interface correctly handles normal and abnormal input data, and records the exception details.

[0067] Compared with the prior art, the present invention has the following beneficial effects:

[0068] 1. Improve test coverage: By introducing a fuzzy test template rule library and automatically generating abnormal input data of various types and lengths, the present invention can significantly expand the test scope and cover more boundary conditions and abnormal scenarios that are difficult to reach with traditional testing methods, thereby improving the overall test coverage.

[0069] 2. Rapid discovery of potential problems: Through automated test generation and response monitoring, the present invention can quickly and efficiently discover possible problems that may exist in the service interface when processing abnormal input, such as parameter type mismatch, length excess, etc., providing strong support for timely repair and improvement.

[0070] 3. Improve interface stability: By continuously testing the service interface for abnormal input and promptly repairing any problems found, the present invention helps to improve the stability and reliability of the interface, ensuring that it can operate normally in the face of various complex and changing input data.

[0071] 4. Reduce manual testing costs: Automated test generation and analysis processes greatly reduce the workload of manual testing, reduce testing costs, while improving testing efficiency and accuracy, allowing testers to focus more on other higher-level testing tasks.

[0072] 5. Enhanced interface protocol consistency: By comparing the definition of the service interface protocol and the actual response results, the present invention helps to ensure the consistency of the interface implementation with the protocol design, reduce test coverage omissions and potential problems caused by protocol inconsistencies, and improve the overall quality and availability of the interface. BRIEF DESCRIPTION OF THE DRAWINGS

[0073] 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 technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0074] Figure 1 It is a schematic diagram of the method flow of the present invention;

[0075] Figure 2 A schematic diagram of the prefabricated template rule of the present invention;

[0076] Figure 3 This is a schematic diagram of the process of Embodiment 2 of the present invention;

[0077] Figure 4 It is a schematic diagram of the system composition of the present invention. DETAILED DESCRIPTION

[0078] In order to make the above-mentioned purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are described in detail below in conjunction with the accompanying drawings. In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways different from those described herein, and those skilled in the art can make similar improvements without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below;

[0079] It should be noted that the various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts between the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.

[0080] Explanation of relevant terms:

[0081] (1) Fuzz testing template rule library: This is a pre-made rule set that contains a variety of rule templates for fuzz testing. These rule templates define how to generate test data and how to perform abnormal input testing on the target service.

[0082] (2) Target service: refers to the service or system that needs to be fuzz tested. It is the object of the test. The purpose of fuzz testing is to discover possible problems that the service may have when processing abnormal input.

[0083] (3) Service interface: The interface provided by the target service for external interaction. Through these interfaces, external systems or users can communicate with the target service. Fuzz testing usually targets these interfaces.

[0084] (4) Swagger interface address: Swagger is a tool for describing and documenting RESTful APIs. The Swagger interface address refers to the URL where the Swagger document of the target service is located. By accessing this address, you can obtain information such as the interface definition, request method, and parameter list of the target service.

[0085] (5) As the rule template for this test: a set of rules selected from the fuzzy test template rule library for this test. These rules define the test data generation method and test strategy.

[0086] (6) Covering abnormal input scenarios: This means covering as many abnormal input scenarios as possible that the target service may encounter through fuzz testing. These scenarios include invalid input, boundary values, special characters, etc., to discover possible problems that the target service may have when processing these inputs.

[0087] (7) Request method: refers to the HTTP request method used when communicating with the target service interface, such as GET, POST, PUT, DELETE, etc. Different request methods correspond to different operations or resource access methods.

[0088] (8) Parameter column information: refers to the parameter list and related information required by the service interface, including parameter name, type, whether it is required, default value, etc. This information is used to generate test data and construct test requests.

[0089] (9) Request parameters: data sent along with the request when initiating a request to the target service. These data are generated according to the interface definition and test rules and are used to simulate the input of actual users or systems.

[0090] (10) Request result: refers to the processing result of the target service on the test request, including the success or failure status, returned data or message, etc. The request result is an important basis for judging whether the test passes.

[0091] (11) Response code, response message or content in the response body: These are the components of the target service's response to the request. The response code indicates the processing status of the request (such as 200 for success, 404 for not found, etc.); the response message is a brief description of the response code; and the response body contains the specific data or information returned.

[0092] (12) Exception details: When the target service processes the test request abnormally, detailed information about the exception is recorded. This includes the type of exception, cause, impact range, etc., which is used for subsequent analysis and repair work.

[0093] Embodiment 1: Figures 1-2 As shown, this embodiment discloses an exploratory testing method for travel SAAS. This embodiment conducts anti-fluctuation data testing on a SAAS online car-hailing platform, with the goal of verifying the stability and robustness of the platform when processing various abnormal data inputs. Through the fuzzy testing method, we will inject a large amount of abnormal data into the platform's interface, observe and record its response.

[0094] In this embodiment, regarding the initialization configuration (step S1):

[0095] Step S100: Loading a pre-built fuzzy test template rule library: Loading a pre-built fuzzy test template rule library file from the server's storage system, which contains the generation rules, length restrictions, format requirements, etc. of various data types. It provides a rich rule template for subsequent tests, facilitating the rapid construction of test data.

[0096] Step S101: Configure the target service and service interface: Enter the server IP address of the online car-hailing platform to ensure that the test system can access it. At the same time, enter or obtain the Swagger interface address of the platform to parse the interface definition.

[0097] Output: The configured target service information, including IP address, Swagger interface address, etc. The test target and interface are clarified, providing a basis for subsequent test requests.

[0098] Step S102: Select rules from the rule base: According to the interface parameter type and length limit of the online car-hailing platform, filter and combine rules from the rule base to ensure that the test data can fully cover abnormal input scenarios. This improves the coverage and effectiveness of the test, especially for the rapid verification of abnormal data input such as parameter type and length in the interface protocol dimension.

[0099] Through predefined rule templates, data that meets or exceeds the interface protocol can be quickly generated to verify the performance of the interface when processing these abnormal data. This helps to find test coverage omissions caused by inconsistent interface protocols and improve the robustness of the system.

[0100] In this embodiment, regarding the simulation interface call preparation (step S2):

[0101] Step S200: Parse the Swagger interface document: Use the Swagger parsing tool to read and parse the Swagger interface document of the online car-hailing platform to obtain the URL path, request method and parameter list information of the interface. Detailed interface information is provided for constructing a test request.

[0102] Step S201: Activate the test data generation algorithm: According to the selected rule template, activate the test data generation algorithm to generate test data of various types, lengths and formats, providing rich test data for fuzz testing.

[0103] Step S202: Traverse the selected interface: traverse the selected interface and construct test requests one by one. During the request process, replace the enumeration value or default value of the target field and use the generated real data as the test value.

[0104] For example, for a parameter that requires a user ID, replace it with a generated real (but possibly abnormal) user ID for testing. This ensures that each interface can be fully tested, improving the comprehensiveness of the test.

[0105] Step S203: Record request details: When initiating each request, record the request time, request parameters and request results, providing detailed data support for subsequent result analysis and exception recording.

[0106] In this embodiment, regarding processing the test response (step S3):

[0107] Step S300: receiving response data: receiving the response data returned by the online car-hailing platform interface, and obtaining the processing result of the interface for the test request.

[0108] Step S301: Analyze response data: Analyze the response code, response message and content in the response body in detail. Through comprehensive analysis, determine whether the interface processes the test request normally.

[0109] Step S302: Determine whether the response is abnormal: Determine whether the response is abnormal based on the analysis result, and accurately identify the abnormal processing of the interface.

[0110] Step S303: Mark the abnormal response and record the details: Mark the abnormal response as abnormal and record the abnormal details in detail, which provides detailed data support for subsequent abnormal processing and problem tracking.

[0111] In this embodiment, regarding outputting the fuzzy test request result (step S4):

[0112] Step S400: Output the test request results to a log file or database: Record the results of each test request to a specified log file or database, ensuring that the results of all test requests are fully saved.

[0113] Step S401: Filtering the results of abnormal requests: Filtering all abnormal requests from the recorded test request results and exporting them to a separate file or data table, providing a centralized data source for abnormal analysis.

[0114] Step S402: Analyze abnormal results and generate test reports: Classify and count the exported abnormal data, analyze the abnormal causes, and generate test reports. Through the test report, developers can quickly understand the abnormal situation and provide a basis for repair and improvement.

[0115] Embodiment 2: Figure 3 As shown, this embodiment will further disclose the strategy execution actions of each stage based on the first embodiment as follows:

[0116] (1) Test configuration: Obtain the application name and machine IP required to perform fuzz testing to configure the task of executing the test; perform screening and marking based on the target interface for performing fuzz testing;

[0117] (2) Confirmation of exception type coverage template: Filter the exception rules for executing fuzzy testing to form a test template that needs to execute the exception rules this time.

[0118] (3) Parameter assembly: Initiate a call request in the interface dimension to replace the body parameters of the API request, randomly generate enumeration values ​​of the target field, form a body parameter group of a complete request, and initiate an interface call request

[0119] (4) Result output: Output fuzz test result set, result set anomaly analysis & problem follow-up

[0120] (5) System processing: pre-test configuration, pre-screening and configuration of target test applications, interfaces, and fuzz test rules; parameter assembly of the execution process, initiation of a single parameter group request call; post-fuzz test result output, analysis and problem follow-up;

[0121] Embodiment 3: Based on Embodiment 1, this embodiment further provides a specific Python execution program as follows:

[0122] import json

[0123] import random

[0124] import string

[0125] import requests

[0126] import logging

[0127] # Initialize configuration

[0128] def load_rule_library():

[0129] # Load the rule library

[0130] return {

[0131] "string":{"min_length":1,"max_length":256,"charset":string.ascii_letters+string.digits},

[0132]

[0133]

[0134]

[0135]

[0136] In the above program:

[0137] load_rule_library(): Loads a rule library containing data generation rules.

[0138] configure_target_service(): Configure the IP address and Swagger interface address of the target service.

[0139] select_rules(): Select rules based on interface parameter type and length restrictions.

[0140] Interface call preparation:

[0141] parse_swagger_doc(): parses the Swagger interface document and returns a list of interface information.

[0142] generate_test_data():Generate test data according to the rules.

[0143] prepare_and_send_requests(): traverses the interface, constructs and sends test requests, and records request and response information.

[0144] Processing test responses:

[0145] process_responses(): Analyze the response data and determine whether the response is abnormal (in this simplified version, status code >= 400 is considered abnormal).

[0146] Output fuzz test request results:

[0147] output_results(): Log test results and exceptions to a log file.

[0148] All the above embodiments only express the implementation methods of the relevant practical applications of the present invention, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, which all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be based on the attached claims.

[0149] For those skilled in the art, it can be further appreciated that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0150] At the same time, those skilled in the art can understand that all or part of the processes in all the above-mentioned embodiments can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media provided in this application and used in the embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double-speed data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

Claims

1. An exploratory testing method for travel SAAS, characterized by: include: S1, load the pre-made fuzz test template rule library, prepare the rule template for subsequent selection; configure the target service and service interface; S2, obtain the location, request method and parameter column information of the interface; generate real data that conforms to the rules according to the rule template settings; Traverse the selected interfaces and initiate fuzz testing requests for each interface; S3, receives and processes the response data returned by the interface; Determine whether the response is abnormal based on the response code, response message, or content in the response body; mark abnormal responses and record abnormal details; S4, output the result of each test request to a specified log file or database; filter the results of abnormal requests and export abnormal data; Analyze abnormal results and generate test reports.

2. The exploratory testing method according to claim 1, characterized in that: In S1, a part of rules is selected from the rule library as the rule template for this test; according to the test objectives and the characteristics of the service interface, a suitable rule combination is selected to cover abnormal input scenarios.

3. The exploratory testing method according to claim 2, characterized in that: The execution method of S1 includes: S100 loads a pre-built fuzz test template rule base file from the storage system; the loaded rule base is provided for selection and use in subsequent steps; S101, input the machine IP address of the service under test to ensure that the test system can access the target service; input or obtain the Swagger interface address of the target service to obtain the definition, request method and parameter list information of the service interface; output the configured target service and service interface information; S102, browsing the loaded rule library, screening and combining rules according to the characteristics of the parameter type and length limit of the service interface and the test target of the specific type of exception handling problem, so that the final rule combination can fully cover the abnormal input scenario.

4. The exploratory testing method according to claim 2, characterized in that: In S2, during the request process, the enumeration value or default value of the target field is replaced, and the generated real data is used as the test value; the request time, request parameters and request result of each request are recorded.

5. The exploratory testing method according to claim 4, characterized in that: The execution method of S2 includes: S200, using the Swagger parsing tool or library, reads and parses the Swagger interface document of the target service; obtains the URL path, GET or POST request method, and parameter list information of the interface; S201, according to the rule template selected in step S1, activate the corresponding test data generation algorithm to generate a real data set, including test data of various types, lengths and formats; S202, traverse the interfaces selected in step S1, and prepare to initiate fuzzy test requests one by one; for each interface, construct a test request according to the parsed interface information and the generated real data; replace the enumeration value or default value of the target field, and use the generated real data as the test value; S203, when each request is initiated, the request time, request parameters and request result of the request are recorded.

6. The exploratory testing method according to claim 4, characterized in that: In S3, whether the response is abnormal is determined based on the response code, the response message or the content in the response body; the abnormal response is marked and the abnormal details are recorded.

7. The exploratory testing method according to claim 6, characterized in that: The execution method of S3 includes: S300, after initiating a fuzz test request, receiving response data returned by the target service interface; obtaining the processing result of the interface on the test request; outputting the received response data, including a response code, a response message and a response body; S301, perform detailed analysis on the received response data, including checking the response code, response message and the content in the response body: Response code: Determine whether the response code indicates success or error; Response message: Analyze whether the response message contains error prompts or warning information; Response body: Check whether the content in the response body meets expectations; S302: If the response code indicates an error, or the response message contains an error prompt, or the content in the response body does not meet expectations, the response is considered abnormal. S303, marking the abnormal response as abnormal; for each abnormal response, recording the abnormal details in detail, including the abnormal type, abnormal description, occurrence time, related request parameters and response data.

8. The exploratory testing method according to claim 1, 2, 4 or 6, characterized in that: The execution method of S4 includes: S400, recording the result of each test request into a designated log file or database; including request time, request parameters, response code, response message and response body; S401, filter out all requests marked as abnormal from the recorded test request results, and export them to a separate file or data table, where the exported data includes request parameters, response data, abnormal type, and abnormal description; S402, classify the exceptions, including input validation errors, internal server errors and timeout errors, and count the number of each type of exceptions; generate a test report based on the results of the exception analysis.

9. A system for implementing the exploratory testing method according to any one of claims 1 to 8, characterized in that: The system comprises: Configuration management layer: including configuration management module and rule base loading module; Test generation layer: including data generation module and abnormal data construction module; Test execution layer: including request sending module, response receiving module and logging module; Result analysis layer: includes response analysis module, exception recording module and report generation module.

10. The system according to claim 9, characterized in that: The configuration management layer is responsible for loading the fuzz test template rule base, configuring the relevant information of the target service and interface, and selecting a suitable rule template from the rule base as the benchmark for this test; The test generation layer automatically generates test data that meets the protocol requirements and abnormal data that does not meet the protocol requirements according to the rule template provided by the configuration management layer; The test execution layer is responsible for initiating test requests to the target service interface, simulating actual user or system operations, and recording detailed information for each request; The result analysis layer analyzes the response data returned by the test execution layer, determines whether the service interface correctly handles normal and abnormal input data, and records abnormal details.

Images