API intelligent test method based on context awareness

Abstract

The invention provides an API (Application Program Interface) intelligent testing method based on context awareness, which relates to the technical field of software testing and comprises the following steps of: constructing a system context corpus by loading structured data such as an API document and a parameter dependency table and unstructured data such as a business rule and a user manual; according to a natural language test target input by a user, a test plan including a calling sequence, parameter dependence and state change is generated in combination with a context, an API calling sequence of state perception is further generated, parameters are subjected to intelligent fuzzification processing, and a test load is formed. Executing the load, capturing response, analyzing and identifying vulnerabilities or abnormities, dynamically adjusting a test strategy based on a result, forming closed-loop feedback, iteratively executing until a termination condition is met, and finally outputting a test report.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of software testing, and particularly relates to an API intelligent testing method based on context awareness. BACKGROUND

[0002] With the wide application of enterprise-level information systems (such as report platforms, cloud service platforms, etc.), their functions are increasingly complex, the number of APIs is rapidly increasing, and they are often involved in cross-system integration and multi-user role interaction. Traditional software testing methods have obvious deficiencies in verifying the security and stability of such systems.

[0003] In the prior art, fuzzing, as a mainstream automated testing method, inputs a large amount of random or variant data into the target system in order to trigger program crashes, memory leaks or unexpected behaviors, thereby discovering potential vulnerabilities. However, traditional fuzzing tools are mostly designed in a "stateless" manner, focusing only on the input and output of a single API interface, and cannot simulate the multi-step, stateful operation sequences of real users in complex business processes. For example, in a report approval system, a complete business process usually includes: user login → creating a report draft → submitting for approval → approver viewing and approving. Traditional tools cannot maintain session states, track resource IDs (such as reportId), and cannot understand the semantic dependency relationship between "submit" and "approve".

[0004] Further, although the current advanced stateful fuzzing tools (such as RESTler) can infer parameter dependencies based on OpenAPI specifications and achieve a certain degree of API call link generation, they are still limited to syntax-level analysis and lack semantic understanding of business rules. For example, they cannot detect logical vulnerabilities such as whether a normal user can bypass the approval process to directly archive a report. In addition, these tools are highly dependent on the completeness and accuracy of API documentation, and have poor adaptability to undocumented behaviors or dynamically generated parameters (such as tokens and timestamps), resulting in low test coverage and high false positive rates.

[0005] At the same time, generative artificial intelligence, especially large language models (LLM), has shown strong capabilities in natural language understanding, logical reasoning and code generation. However, how to effectively introduce the capabilities of large language models into the field of API security testing, especially to achieve the transition from "syntax testing" to "semantic testing", has not yet formed a mature technical solution. SUMMARY

[0006] The application provides an API intelligent testing method based on context awareness to solve one of the above technical problems.

[0007] The technical solution adopted by the application is: The embodiment of the present application provides an API intelligent testing method based on context awareness, which comprises the following steps: loading context data of a system to be tested, wherein the context data comprises structured data and unstructured data, the structured data at least comprises API interface definition documents and parameter dependency tables, and the unstructured data at least comprises business rule documents and user manuals; generating a test plan for the system to be tested according to a natural language test target input by a user, wherein the test plan comprises a logical order of API calls, parameter dependency relationships and expected state changes; generating an API call sequence comprising state awareness based on the test plan and the context data, wherein the state awareness is used to ensure that the API calls conform to business rules of the system to be tested, and intelligent fuzzing processing is performed on request parameters in the API call sequence to generate a test load comprising abnormal data; performing API calls corresponding to the test load, capturing response data of the system to be tested, analyzing the response data, identifying potential vulnerabilities or system abnormalities, dynamically adjusting subsequent test strategies based on analysis results, forming a closed-loop feedback, iteratively performing the above steps until a preset termination condition is met, and outputting a test result report.

[0008] According to one embodiment of the present application, the step of loading context data comprises the following steps: extracting endpoint information, request methods and parameter specifications in the API interface definition documents through a structured data analysis module; analyzing business rules in the unstructured data through a natural language processing module to generate a parameter dependency table and state transition rules; integrating the parsed data into a context corpus and loading the context corpus into a large language model for subsequent calling. According to one embodiment of the present application, the step of generating a test plan comprises the following steps: decomposing a natural language test target input by a user into a plurality of sub-targets, each of which corresponds to a specific business scenario of the system to be tested; determining an API call path and required parameters corresponding to each sub-target based on the context corpus; verifying the feasibility of the API call path through semantic understanding capability of the large language model and supplementing missing preconditions.

[0009] According to one embodiment of the present application, the step of generating an API call sequence comprises the following steps: determining a timing relationship of API calls according to a logical order in the test plan, and marking dependency states of each API call; The details of the API request, including the request method, URL path, request header, and request body, are dynamically filled by a large language model. State-aware logic is embedded in the request body to ensure that subsequent API calls are only executed when the preconditions are met.

[0010] According to an embodiment of the present application, the intelligent fuzzing process includes: According to the business rules of the system under test, the abnormal types of parameter values are generated, including type abnormalities, format abnormalities, logical conflicts, and classic attack payloads. The generated abnormal parameter values are injected into the API request, and placeholders for legal parameter values are retained to support subsequent calls. Through the context understanding ability of the large language model, it is ensured that the abnormal data matches the business scenario of the system under test.

[0011] According to an embodiment of the present application, the step of analyzing the response data includes: Parse the HTTP status code, response header, and response body in the response data to identify abnormal status codes or error information. Verify the legality of the response data based on business rules, such as whether the report ID comes from the response of the previous call. Through the semantic analysis ability of the large language model, it is determined whether there are unauthorized operations, state skipping, or logical vulnerabilities.

[0012] According to an embodiment of the present application, the step of dynamically adjusting the test strategy includes: Generate a feedback signal based on the analysis results, which includes vulnerability types, failure causes, and repair suggestions. Based on the feedback signal, adjust the calling order, parameter values, or state-aware logic of the subsequent test plan; In the iteration process, high-risk scenarios are given priority, and the execution trajectory of all test steps is recorded.

[0013] According to an embodiment of the present application, the termination condition includes at least one of the following: Key vulnerabilities are found and a preset vulnerability threshold is reached; All predefined test objectives are verified; Exceed the maximum number of iterations or execution time set in advance.

[0014] The second aspect embodiment of the present application provides a computer readable storage medium having a program stored thereon, which is executed by a processor to implement the steps in the method as described.

[0015] The third aspect of the present application provides an electronic device, comprising a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor implements the steps in the method as described when executing the program.

[0016] As the above technical solutions are adopted, the present application has the following beneficial effects: The present application loads context data including API interface definition documents, parameter dependency tables, business rule documents, and user manuals, so that the large language model can comprehensively understand the structure and behavior logic of the system to be tested. The test plan generated on this basis not only contains the logical order of API calls, but also clearly defines the parameter dependency relationship and expected state changes, so as to ensure that the generated API call sequence can simulate the complete operation path of a real user, significantly improving the test coverage of multi-step business processes.

[0017] Based on the natural language test target input by the user (such as "test permission bypass"), the system can generate an API call sequence containing "state awareness" in combination with the context data. For example, attempting to perform an approval operation in the state of a report not being submitted, or calling a high-privilege interface using a low-privilege account. This capability enables the system to actively detect business logic vulnerabilities that traditional tools cannot find, achieving a technical leap from "syntax compliance testing" to "semantic reasonableness verification".

[0018] The present application intelligently fuzzes the request parameters in the API call sequence, so that the system can inject type abnormalities, format abnormalities, logic conflicts, or classic attack payloads under the premise of maintaining basic syntax correctness. Since the fuzzing process is based on the understanding of business rules, the generated test payloads are more targeted, significantly reducing invalid inputs and improving test efficiency and vulnerability detection rate.

[0019] The present application executes test payloads, captures response data, and performs in-depth analysis, so that the system can identify potential vulnerabilities or system abnormalities. More importantly, based on the analysis results, the system dynamically adjusts the subsequent test strategy, forming a closed-loop feedback. For example, when the response returns "401 Unauthorized", the system can automatically complete the authentication information and retry; when unauthorized success is found, the test range can be expanded to verify other sensitive interfaces. This mechanism significantly enhances the robustness and intelligence level of the test process.

[0020] The present application iteratively executes the test process until the preset termination condition (such as finding a critical vulnerability or completing all test objectives) is met, so that the system can gradually and deeply explore potential risk points in the system to be tested. The final output test result report not only contains vulnerability details, but also includes complete reproduction paths and execution logs, ensuring the traceability of the test process and the verifiability of the results. BRIEF DESCRIPTION OF DRAWINGS

[0021] The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the application. In the drawings: Figure 1 A flowchart of a context-aware API intelligent testing method provided by an embodiment of the application; Figure 2 A structural diagram of an electronic device provided by an embodiment of the application; Figure 3 A system architecture diagram of a context-aware API intelligent testing method provided by an embodiment of the application.

[0022] Reference signs: 810, processor; 820, communication interface; 830, memory; 840, communication bus. DETAILED DESCRIPTION

[0023] In order to more clearly illustrate the whole conception of the application, the following will be a detailed description in the manner of examples with reference to the accompanying drawings.

[0024] In the following description, numerous specific details are set forth in order to provide a thorough understanding of the application. However, it will be apparent to one skilled in the art that the application can be practiced without the specific details and other implementations can be employed. In other instances, well-known methods have not been described in detail in order to avoid obscuring the application. It will be appreciated that embodiments of the application can be used in combination with each other unless specifically stated otherwise, and that features described as part of one embodiment can also be implemented with other embodiments.

[0025] In the present application, unless specifically stated and limited otherwise, the first feature is "on" or "under" the second feature can be that the first and second features are in direct contact, or the first and second features are indirectly in contact through an intermediate medium. In the description of the specification, the description of the terms "one embodiment", "some embodiments", "an example", "a specific example", or "some examples" means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the application. In the present specification, the illustrative description of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any appropriate manner in any one or more embodiments or examples.

[0026] Embodiment 1 As shown in the figure, a context-aware API intelligent testing method includes: Figure 1 ​Load the context data of the system to be tested, which includes structured data and unstructured data, the structured data at least includes API interface definition documents, parameter dependency tables, and the unstructured data at least includes business rule documents and user manuals.

[0027] As described above, the structured data refers to a data source with explicit format and field definition, which can be directly parsed and key information extracted by a program. For example, the API interface definition document (such as OpenAPI / Swagger file) contains metadata such as request method, path, parameter type, request body structure, etc. of each endpoint; the parameter dependency table explicitly describes the input-output correlation between different API calls, such as the resource ID returned by a create operation needs to be used as an input parameter for subsequent query or update operation. These data constitute the "skeleton" of system interaction.

[0028] The unstructured data refers to text materials in natural language form, such as business rule documents, user operation manuals, requirement specifications, system design documents, etc. Although this kind of data does not have a fixed format, it contains rich business intent, state transition logic, permission control strategy and other deep semantic information. For example, the rules such as "report cannot be edited after submission" and "the approver cannot approve the report submitted by himself" are usually not reflected in the API document, but are crucial for testing logic. By introducing such data, the system can understand "what operation is legal under what condition", thereby supporting active detection of business logic vulnerabilities.

[0029] The above two types of data are loaded and integrated into a context corpus, so that the large language model not only knows "how to call API", but also understands "why to call like this", which provides a knowledge base for subsequent generation of test plans conforming to business semantics and identification of abnormal behaviors.

[0030] For example, taking an enterprise-level report management system as an example, the specific implementation of this step is described as follows: Loading of structured data: The system imports the OpenAPI v3 specification file of the report platform, and extracts all API endpoint information from it, such as POST / reports for creating a report, PUT / reports / {id} / submit for submitting a report, and GET / reports / {id} for viewing a report.

[0031] The parameter dependency is also parsed: the response body of POST / reports contains a reportId field, which must be used as the {id} parameter in the PUT / reports / {id} / submit and GET / reports / {id} paths.

[0032] These information are structured stored, forming API call graph and parameter mapping table, for subsequent generation of stateful call sequence reference.

[0033] Loading of unstructured data: The system reads the "Report Approval Operation Manual" and "System Security Design Document" provided by the enterprise, which states: "The report must be approved by the department manager before it can take effect" "Ordinary employees have no right to view sensitive reports of other departments" "The report is prohibited from any modification after archiving".

[0034] Through natural language processing technology, these rules are converted into machine-understandable semantic expressions, such as the "submit" label is the pre-state of "approval", "archive" is the termination state, and "cross-department access" is limited by role permissions.

[0035] These semantic rules are included in the context knowledge base to guide whether the test sequence violates business logic (such as skipping submission and directly approving).

[0036] Through the collaborative loading of the above two types of data, the system builds a complete context model that contains both interface syntax structure and business semantic rules, laying a solid foundation for subsequent intelligent test generation.

[0037] It should be noted that in specific implementation scenarios, the above-mentioned solutions can be extended to Postman collection files, HAR (HTTP Archive) files, gRPC Protobuf definition files, and other standardized interface description formats. It can also include system runtime generated call chain logs (such as OpenTelemetry-based trace data), automatically inferring API call order and parameter passing path, making up for the problem of missing or lagging documentation. The parameter dependency table can also be automatically generated by the system based on historical call data, rather than relying entirely on manual maintenance.

[0038] In specific implementation scenarios, the above-mentioned solutions can be extended to include annotation information in source code (such as JavaDoc, Python Docstring), change descriptions in Git commit records, and requirement description texts in Jira and other project management tools. Support for parsing multi-language documents is suitable for cross-border enterprises or multi-language system testing scenarios. Knowledge graph technology can be introduced to organize scattered unstructured rules into structured "business rule graphs", improving the understanding efficiency and reasoning accuracy of large language models.

[0039] In specific implementation scenarios, on the basis of the above scheme, the context data can support incremental loading and dynamic updating mechanism. For example, when the system detects that the API document version is upgraded, the context refresh process is automatically triggered to ensure that the test knowledge base is always synchronized with the latest system state. Context priority policies can be set, for example, when the API document and the user manual description conflict, the business rules in the manual are preferred, embodying the test principle of "business intention higher than interface implementation". The credibility of the context data is supported, for example, the information from the official document is higher than the internal notes, avoiding noise data interference with test decision.

[0040] In specific implementation scenarios, on the basis of the above scheme, in the process of loading context data, a sensitive information identification and desensitization module can be integrated to automatically filter confidential content such as keys, account passwords, etc. that may be contained in the document, ensuring the security of the test environment. For business rules involving privacy (such as financial and medical systems), a localized context processing mechanism can be used to avoid data leakage risks.

[0041] According to the natural language test target input by the user, a test plan for the to-be-tested system is generated, which includes the logical order of API calls, parameter dependency relationship and expected state change.

[0042] As mentioned above, the natural language test target refers to the test intention input by the tester in the form of daily language, such as "test whether a normal user can approve his own report" or "verify whether there is an unauthorized data export vulnerability". Such target does not involve specific technical details, but focuses on the security risks at the business logic level.

[0043] The generation process of the test plan depends on the context data loaded in the previous step. The large language model combines API interface definition, parameter dependency relationship and business rule document to understand the semantics of the natural language target, and decompose it into a series of logically coherent sub-tasks. Each sub-task corresponds to a specific API operation and clearly defines its position in the overall process, the required preconditions and the expected state change it will cause.

[0044] The logical order of API calls refers to the time and causal relationship between multiple API calls, for example, you must log in to create a report, and you must submit it to approve it.

[0045] The parameter dependency relationship refers to the output (such as resource ID, token) of one API call being used as the input of another API call, ensuring the integrity of the call chain.

[0046] The expected state change refers to the business state that the system should enter after performing a certain operation, for example, the report changes from "draft" to "submitted", and the user's permission is upgraded from "normal" to "administrator".

[0047] By generating a test plan containing the above three elements, the system can not only simulate normal business processes, but also actively construct abnormal paths (such as skipping necessary steps and reverse operations), thereby effectively detecting logical vulnerabilities.

[0048] For example, let's take an enterprise's internal expense reimbursement system as an example to illustrate the specific implementation of this step: User input natural language testing objectives: Tester input: "Test whether employees can directly file expense reports without submitting them for approval." Large language models perform semantic parsing and task decomposition: The model combines contextual data to identify keywords: "employee" corresponds to a low-privilege role, "submit for approval" is an intermediate state, and "archive" is the final operation.

[0049] According to the business rule document, the normal process should be "Create → Submit → Approve → Archive", and "Archive" is only allowed to be executed by administrators.

[0050] The model judges that the test goal is to verify whether there are dual vulnerabilities of "state skipping" and "permission bypassing".

[0051] Generate a structured test plan: Logical order: Log in using your employee account; Create a new expense report; Skip the "Submit for Approval" action; Directly call the "Archive Reimbursement Form" interface.

[0052] Parameter dependencies: The session token in the login response is used for all subsequent requests; The expenseId returned when creating the expense report is used as the path parameter of the archiving interface.

[0053] Expected status changes: Under normal circumstances, calling the archive interface should return "403 Forbidden" (insufficient permissions) or "400 BadRequest" (illegal status); If "200 OK" is returned, it indicates a serious logic vulnerability.

[0054] The test plan clearly describes the attack path and provides guidance for the subsequent generation of specific API call sequences and fuzzed payloads.

[0055] It should be noted that in a specific implementation scenario, on the basis of the above scheme, the natural language test target can not only be manually input, but also come from an automated system, such as a risk item in a security requirement management system, a check item in a compliance audit list, or a typical attack pattern in a historical vulnerability library. Support batch import of multiple test targets, and the system can automatically generate corresponding test plan sets, which are suitable for large-scale regression testing or compliance verification scenarios.

[0056] In a specific implementation scenario, on the basis of the above scheme, macro-level (covering the entire business module, such as "test all approval class interfaces"), meso-level (aiming at a certain function process, such as "leave application approval closed loop"), and micro-level (focusing on a single boundary condition, such as "negative amount reimbursement") can be used. Support to generate positive test plan (verify normal function) and negative test plan (detect abnormal behavior) two types, meet different test purposes.

[0057] In a specific implementation scenario, on the basis of the above scheme, during the generation of the test plan, the current state of the system (such as existing resources, user role permissions) can be referred to in real time, and the plan content can be dynamically adjusted. For example, if it is detected that a certain report has been archived, the editing test related to it is automatically skipped. Combined with historical test results, similar paths where vulnerabilities have been found are preferentially generated to improve test efficiency.

[0058] In a specific implementation scenario, on the basis of the above scheme, when multiple test targets are input at the same time, the system can identify their logical relationships (such as dependency, parallelism, conflict), and generate a unified comprehensive test plan. For example, "test unauthorized access" and "test data leakage" can be combined into a call chain containing illegal reading of sensitive fields. For mutually contradictory goals (such as "prohibit deleting approved reports" and "allow deleting after revoking approval"), the system can mark potential rule conflicts to assist developers in perfecting business logic.

[0059] In a specific implementation scenario, on the basis of the above scheme, support for test personnel to interactively modify and confirm the generated test plan can be provided, forming a "AI generation + manual verification" collaborative mechanism, taking into account automation efficiency and professional judgment. Visual display of the test plan, such as flowchart or state machine diagram, can be provided to facilitate understanding and review.

[0060] In a specific implementation scenario, on the basis of the above scheme, an industry-specific knowledge base (such as anti-fraud rules in the financial industry, privacy protection specifications in medical systems) can be integrated to make the generated test plan comply with industry compliance requirements. For emerging vulnerability types (such as supply chain attacks, AI model poisoning), the knowledge base can be updated to support the analysis and plan generation of new test targets.

[0061] Based on the test plan and the context data, an API call sequence containing state awareness is generated, the state awareness is used to ensure that the API call conforms to the business rules of the system to be tested, intelligent fuzzing is performed on the request parameters in the API call sequence, and a test load containing abnormal data is generated.

[0062] As described above, "state awareness" refers to the system's ability to understand and maintain the runtime state of the application under test when constructing the API call chain, including user identity, resource lifecycle, permission level, business process stage, etc. For example, a report may go through multiple states such as "draft → submit → approval in progress → archived" in the system, each state corresponding to different executable operations.

[0063] This step uses the test plan generated in the previous step (including logical order, parameter dependency, and expected state change) and the loaded context data (such as API definition and business rules) to dynamically build a call path that conforms to business semantics by a large language model. The path not only contains request methods, URLs, header information, and other basic structures, but also embeds state judgment logic to ensure that each call is executed in a reasonable context. For example, before calling the "approve report" interface, the system will automatically insert the "submit report" operation to meet the pre-state requirement, or intentionally skip this step to test whether the state verification mechanism is sound.

[0064] On the basis of the generated legal call sequence, the system performs targeted abnormal data injection on the request parameters. Unlike traditional random fuzzing, the "intelligent fuzzing" of the present application has the following characteristics: Type awareness: select appropriate abnormal types (such as replacing numbers with strings) according to parameter definitions (such as integer, string, and enumeration value); Format awareness: for structured data such as JSON and XML, construct payloads that are syntactically legal but semantically abnormal (such as missing required fields or adding illegal nesting); Logic awareness: construct logically conflicting inputs in combination with business rules (such as using the creator's identity token in the "approval" operation); Security awareness: inject known attack patterns (such as SQL injection fragments and cross-site scripting code) to detect common security vulnerabilities.

[0065] The "abnormal data" is not completely invalid, but is designed to pass the initial validation at the syntax level, but violates the rules at the semantic or permission level, making it more likely to penetrate the front-end validation and trigger deep logic defects.

[0066] Through the above two-step cooperation, the final test load not only has the "legality of the cover" of real user operations, but also contains the "abnormal kernel" of attack intent, significantly improving the ability to discover hidden vulnerabilities.

[0067] For example, take a corporate contract management system as an example to illustrate the specific implementation process of this step: Test plan input: The test plan generated by the previous step is: "Verify whether an ordinary employee can directly perform the 'archive' operation when the contract is in the 'draft' state."

[0068] Generate state-aware API call sequence: Step 1: Call POST / login using an ordinary employee account to log in and obtain a session token (token); Step 2: Call POST / contracts to create a new contract, and the system returns contractId=123; Step 3: Skip the PUT / contracts / 123 / submit (submit) operation; Step 4: Directly call PUT / contracts / 123 / archive to attempt archiving.

[0069] During this process, the system explicitly knows that the pre-state of the "archive" operation should be "submitted", but the test goal requires skipping this state, so the call sequence is constructed as a state violation path to detect whether the system has sufficient state checking capabilities.

[0070] Intelligent fuzzing processing: In the request body of the fourth step, the system processes the parameters as follows: The operatorRole field should be "administrator", but it is replaced with "employee" (logical conflict); The timestamp field is set to a future time (format is legal but semantics is abnormal); The request header retains a valid authentication token to ensure that the request can enter the business logic layer.

[0071] The final test payload appears to be legal, but in fact contains multiple abnormalities, which can detect security issues in multiple dimensions such as permission control, state verification, and input filtering.

[0072] After the test payload is executed, if the system returns "200 OK", it indicates that there is a serious business logic vulnerability; if it returns an error but exposes stack information, it may cause information disclosure risks. In either case, it can be accurately identified and recorded by the system.

[0073] It should be noted that in a specific implementation scenario, on the basis of the above scheme, multi-role collaborative state flow can be supported, for example, a cross-role process of "user A creates → user B approves → user C archives" is simulated, and the correctness of the role permission in the state change is verified. A "virtual state machine" model can be introduced, abstracting the business state as a node and the API operation as an edge. The system can automatically traverse all possible state transition paths, including irregular jumps (such as from "draft" to "invalid" directly), to achieve more comprehensive path coverage. Concurrent state processing is supported, such as lock mechanism and consistency check when multiple users simultaneously attempt to approve the same report.

[0074] In a specific implementation scenario, on the basis of the above scheme, various types such as positive sequence (verify normal process), negative sequence (test abnormal path), and boundary sequence (test critical value) can be generated to meet different needs of function testing, security testing, and stability testing. Conditional branching judgment is supported, such as dynamically selecting the subsequent call path according to the response result of the previous API (such as archiving if the approval is passed, or re-editing if the approval is rejected). A historical vulnerability pattern library can be integrated to prioritize the reproduction of high-risk operation combinations when generating sequences.

[0075] In a specific implementation scenario, on the basis of the above scheme, if a certain interface frequently returns a 400 error, the system can reduce the fuzzing intensity and prioritize ensuring syntax compliance; if the response is stable, the attack payload can be gradually increased. Prioritization of fuzzing strategies is supported, such as testing permission bypass vulnerabilities first and then testing injection vulnerabilities. A "progressive fuzzing" mechanism can be introduced, starting with minor abnormalities and gradually increasing the deviation, to facilitate the positioning of the precise boundaries of vulnerability triggers.

[0076] In a specific implementation scenario, on the basis of the above scheme, the system can perform similarity analysis on the generated test payloads to avoid repeated execution of highly redundant request combinations and improve testing efficiency. Support for response feedback-based payload optimization: if a certain type of exception is always intercepted, the system can automatically adjust the generation strategy to try more subtle variants.

[0077] In a specific implementation scenario, on the basis of the above scheme, the generated test payloads can be exported in a standard format (such as Postman collection, HAR file) for reuse by other testing tools. It can be integrated with static code analysis tools to focus fuzzing on interfaces with high code complexity or a high number of historical defects.

[0078] In specific implementation scenarios, a sensitive data identification mechanism can be integrated in the fuzzing process to avoid accidental disclosure of real user information or keys in the request. A "shadow mode" can be enabled in the test environment, where all abnormal requests do not actually modify the data, and are only used to observe system behavior, preventing test-induced real business interruptions.

[0079] The API call corresponding to the test load is executed, the response data of the system under test is captured, potential vulnerabilities or system abnormalities are identified based on the analysis of the response data, and the subsequent test strategy is dynamically adjusted based on the analysis results, forming a closed-loop feedback, and the above steps are iteratively executed until the preset termination condition is met, and a test result report is output.

[0080] As mentioned above, the test executor initiates real HTTP requests to the system under test in the order of the generated test load. Each step of the call carries complete request headers (such as authentication tokens, content types), request bodies, and path parameters. The system accurately records the complete response of each request, including: HTTP status code (such as 200, 403, 500); Response header information (such as Set-Cookie, Content-Length, custom security headers); Response body content (such as JSON format business data, error description, stack information); Timestamps of requests and responses for performance and timeout analysis.

[0081] The captured response data is sent to the analysis module for semantic interpretation in combination with the context corpus. The analysis process includes: Abnormal state identification: Detect unexpected successful responses (such as low-privilege users performing high-privilege operations returning 200), server errors (5xx), and security configuration defects (such as exposing internal IP or version information); Business logic verification: Determine whether the operation result conforms to the business rules, for example, "a report in draft state is successfully archived" is a logic violation; Sensitive information leakage detection: Identify whether the response contains passwords, keys, user privacy, and other data that should not be exposed; State consistency check: Confirm whether the system state evolves as expected, for example, whether the report state field is updated to "submitted" after submission.

[0082] The analysis results are not only used to report vulnerabilities, but also serve as "learning signals" to drive subsequent testing: If a request fails due to "401 Unauthorized", the system infers that authentication information needs to be supplemented, and automatically injects a valid token in subsequent calls; If "400 Bad Request" prompts missing parameters, the system finds the parameter definition from the context document and completes it; If unauthorized success is found, the system will expand the test range and try to reproduce the behavior on other similar interfaces; If a path is always intercepted, the system reduces the fuzzing intensity or switches attack vectors to explore alternative paths.

[0083] This process forms an AI-driven cognitive cycle, enabling the testing system to learn autonomously and evolve strategies.

[0084] The system starts with the initial test target, continuously generates new payloads, executes, analyzes, and optimizes, entering multiple rounds of iteration. Each round of iteration adjusts the test focus based on the previous results, gradually delving into the deep logic of the system. When the preset termination conditions are met, iteration stops and enters the result output stage.

[0085] Finally, a structured report is generated, including: List of discovered vulnerabilities and their risk levels (high / medium / low); Reproduction steps for each vulnerability (complete API call sequence); Response data screenshots or text snippets; Vulnerability cause analysis and repair suggestions; Test coverage statistics and execution trajectory logs.

[0086] For example, take an e-commerce platform order management system as an example to illustrate the specific implementation process of this step: Execute test payload: The system executes a test payload: using the identity of normal user A, skipping the "payment" state, and directly calling the "confirm receipt" interface (POST / orders / 789 / confirm-receipt).

[0087] Capture response data: The system receives the response: Status code: 200 OK; Response body: {"orderId": "789", "status": "completed", "message": "Order confirmed successfully"}; Response header: No security warnings, complete user address information is returned.

[0088] Analyze the response and identify vulnerabilities: Status code 200 indicates that the operation is successful, but the business rules stipulate that "confirm receipt" must be executed in the "paid" state, and the current order is still "to be paid", constituting a state verification missing vulnerability; The receiver's name, phone number, and detailed address are exposed in the response body, which is sensitive information and is returned excessively. The system determines that this request triggers two independent security issues: a logic vulnerability and information leakage.

[0089] Dynamic adjustment of test strategy: For the state verification vulnerability, the system generates a new test target: "Try 'confirm receipt' on an order in the 'cancel' state"; For the information leakage issue, the system modifies the fuzzing strategy for all subsequent read interfaces, adding a scan for private fields in the response body. The system also attempts to perform a "refund request" operation on the same order to verify whether there are any chained permission defects.

[0090] Iterative execution and report output: After multiple iterations, the system discovers 3 state skipping vulnerabilities and 2 information leakage points. The final report lists each vulnerability's request / response pair, risk description, and repair suggestions (such as adding state pre-check, desensitizing response data), and includes the complete test execution log.

[0091] It should be noted that in specific implementation scenarios, the above scheme can be further supported to execute multiple test payloads concurrently, simulating system stability and permission control consistency under high load scenarios; integrate traffic proxies or gateways to inject test requests without modifying the system under test, suitable for production isolation environments; support delayed execution and scheduled tasks for testing time-sensitive logic (such as appointment effectiveness, automatic expiration).

[0092] In specific implementation scenarios, the above scheme can be further supported to introduce pattern recognition techniques to automatically cluster similar responses and identify potential batch vulnerabilities (such as multiple interfaces with unauthorized access); support processing of encrypted responses: if the system provides decryption keys or interfaces, the content can be decrypted and analyzed; combine performance indicators (such as response time, resource consumption) to identify potential denial-of-service (DoS) risk points.

[0093] In specific implementation scenarios, the above scheme can be further supported to establish a "vulnerability pattern memory bank" to use historical successful test paths as templates for rapid detection of new systems; support strategy optimization based on reinforcement learning: the system automatically adjusts fuzzing intensity, call frequency, and state jump strategy based on vulnerability discovery efficiency; set up a priority scheduling mechanism to preferentially explore high-risk modules or high-return paths.

[0094] In specific implementation scenarios, the termination condition can be dynamically configured based on the above scheme, such as "no new vulnerabilities found for N consecutive rounds", "key path coverage rate reaches threshold", "reaches preset time budget"; supports phased iteration: first phase explores all interfaces breadth-first, second phase digs high-risk paths depth-first; can be integrated with CI / CD system to realize daily automatic iteration and continuous monitoring of system security changes.

[0095] In specific implementation scenarios, the report can be generated in multiple formats based on the above scheme: PDF document, HTML visualization page, JSON data interface, to facilitate integration into a security management platform; high-risk vulnerabilities can be automatically pushed to a ticket system (such as Jira) to create repair tasks and track the closed loop; support for generating compliance comparison tables, such as mapping to OWASP API Security Top 10, ISO 27001, etc. standard clauses.

[0096] In specific implementation scenarios, the "security sandbox" mode can be enabled during execution to ensure that test behavior does not cause irreversible impact on real data; all execution operations are recorded in audit logs, including operation time, executor (system identifier), request content, to meet compliance audit requirements; supports automatic backup of key data state before and after testing to facilitate problem reproduction and recovery.

[0097] According to an embodiment of the present application, the step of loading context data comprises: extracting endpoint information, request methods and parameter specifications in the API interface definition document through the structured data parsing module; parsing business rules in unstructured data through the natural language processing module to generate parameter dependency relationship table and state transition rules; integrate the parsed data into a context corpus and load it into a large language model for subsequent calling. As described above, first, the API interface definition document is parsed by the structured data parsing module. The document can be an OpenAPI, Swagger, Postman collection or HAR file, etc. with a standard format. The parsing module extracts the endpoint information of each API, including the request path, supported request methods (such as GET, POST, PUT, DELETE, etc.), and the name, type, whether required, data format and example value of each request parameter. At the same time, the response structure is extracted, including the return status code and the data model of the response body. These information are used to clearly define the basic calling method and data structure of API, which constitutes the basic knowledge of system interaction.

[0098] Secondly, the unstructured data is processed by a natural language processing module. The unstructured data includes business rule documents, user operation manuals, system design specifications, requirement documents and the like text materials written in natural language. The natural language processing module performs semantic analysis on these texts, and identifies the business processes, permission control strategies, state transition logic and operation constraint conditions described therein. For example, the rules such as "the report cannot be modified after submission", "the approver cannot approve the report submitted by himself", "the user must log in before creating a resource" and the like are identified from the documents. Based on these rules, the system generates a parameter dependency table for recording the input-output association between different API calls, such as the resource ID returned by a creation interface needs to be used as an input parameter of a subsequent query or update interface; and generates state transition rules to describe the state change path of the resource under different operations and the legality judgment conditions thereof.

[0099] Finally, the information extracted from the structured data and the unstructured data is integrated and organized into a context corpus. The corpus contains the syntax structure information and the business semantic rules of the API, forming a comprehensive and consistent knowledge set. The corpus is organized in a format readable and understandable by the large language model, and is loaded into the large language model as the knowledge base for subsequent generation of test plans, construction of calling sequences and analysis of response results, ensuring that the test process conforms to the interface specification and is consistent with the actual business logic.

[0100] According to an embodiment of the present application, the step of generating a test plan comprises: decomposing the natural language test target input by the user into a plurality of sub-targets, each corresponding to a specific business scenario of the system under test; determining the API calling path and required parameters corresponding to each sub-target based on the context corpus; verifying the feasibility of the API calling path and supplementing the missing preconditions through the semantic understanding capability of the large language model.

[0101] As described above, first, the natural language test target input by the user is decomposed. The test target is a high-level security or function verification intention expressed in natural language form, such as "test whether a normal user can approve the report submitted by himself" or "verify whether there is an unauthorized data export function". The system performs semantic analysis on this target through the large language model, and decomposes it into a plurality of logically independent and executable sub-targets. Each sub-target corresponds to a specific business scenario in the system under test, such as "log in as a low-privilege user", "create a new report", "try to call the approval interface to act on the report created by himself" and the like. This decomposition converts the abstract test intention into a series of operable technical actions.

[0102] Secondly, based on the context corpus constructed in the previous step, the corresponding API call path and required parameters are determined for each sub-goal. The context corpus contains information such as API interface definitions, parameter dependencies, and business rules. The system queries this corpus to identify the specific API endpoints, request methods, request headers, request body structures, and path or query parameters required to implement each sub-goal. At the same time, the dependencies between calls are determined, such as whether the resource identifier or authentication token returned by the previous operation is used as input for the subsequent request. This process ensures that each sub-goal can be mapped to an actual existing interface combination and form an ordered call chain.

[0103] Finally, the semantic understanding capabilities of large language models are used to verify the feasibility of the determined API call path. The model combines business rules and state transition logic from the context corpus to determine whether the path is reasonable under the current system design and whether there are missing preconditions. For example, in the "execute approval" sub-goal, the model identifies that the normal process requires the report to be in the "submitted" state, but the current path does not include the "submit report" operation, so it determines that the path is missing the necessary pre-step. The system automatically supplements the corresponding pre-call, such as adding a call to the "submit report" interface, and ensures that its parameters are correctly passed. Through this verification and supplementation process, the generated test plan not only has complete logic but also conforms to the actual operating constraints of the system, laying the foundation for generating executable test sequences in the future.

[0104] According to an embodiment of the present application, the step of generating an API call sequence comprises: According to the logical order in the test plan, determine the timing relationship of API calls and mark the dependent state of each API call; Fill in the details of the API request dynamically through a large language model, including the request method, URL path, request header, and request body; Embed state-aware logic in the request body to ensure that subsequent API calls are only executed when the pre-state conditions are met.

[0105] As mentioned above, first, according to the logical order determined in the test plan, the timing relationship between each API call is clarified. The test plan has defined the execution flow of sub-goals, and the system arranges the order of API calls accordingly to ensure that the operations conform to the time sequence of the business process. At the same time, mark the state conditions that each API call depends on, such as "before calling the approval interface, the report must be in the'submitted' state" or "when executing the delete operation, the user must have administrator privileges." These state markers are used to guide the construction and execution control of subsequent requests, ensuring that the call sequence can reflect the state transition requirements of the real system.

[0106] Second, the specific request content of each API call is dynamically filled by a large language model. The model combines interface definition information in the context corpus to determine the request method (such as GET, POST, etc.), complete URL path (including specific resource ID or parameter value), and necessary request headers (such as authentication token, content type, etc.) for each call. For the request body part, the model generates JSON or form data that meets the format requirements according to the data structure defined by the interface and fills in the corresponding field values. Dynamic parameters such as resource IDs returned by previous calls and session tokens are correctly referenced and inserted into the corresponding positions to ensure the completeness and validity of the request.

[0107] Finally, state-aware logic is embedded in the process of constructing the request body. This logic is not simply statically configured, but rather reflects state judgment conditions in the request based on business rules. For example, when generating a "report approval" request, the system checks whether the report state has been updated to "submitted" by the previous operation. If not, a state check point is reserved in the test sequence for subsequent verification of whether the system allows the operation to be performed without meeting the state condition. This state-aware mechanism enables the generated call sequence to simulate both legal processes and state violation paths, thereby supporting comprehensive testing of state verification mechanisms. The final API call sequence is an executable test script that is ordered, complete, and has state context information.

[0108] According to an embodiment of the present application, the steps of intelligent fuzzing processing include: According to the business rules of the system under test, generate abnormal types of parameter values, including type abnormalities, format abnormalities, logical conflicts, and classic attack payloads; Inject the generated abnormal parameter values into the API request and reserve placeholders for legal parameter values to support subsequent calls; Ensure that the abnormal data matches the business scenario of the system under test through the context understanding ability of the large language model.

[0109] As mentioned above, first, according to the business rules and interface definitions of the system to be tested, the abnormal data types suitable for each parameter are generated. The system combines the parameter specifications extracted from the context corpus and the business logic to generate four types of abnormal values for different fields: type abnormalities, such as filling in strings in fields that require integers; format abnormalities, such as providing text that does not conform to the standard format in the mailbox field, or constructing syntax errors in the nested JSON structure; logic conflicts, such as attempting to call interfaces only allowed for "administrators" when the user role is "ordinary employee", or performing "confirm receipt" operations when the order status is "to be paid"; and classic attack payloads, such as injecting SQL statement fragments, cross-site scripting code, or command execution strings, for detecting common security vulnerabilities. The selection of these abnormal types is based on the semantic roles of the parameters and the possible weaknesses of the system.

[0110] Second, the generated abnormal parameter values are injected into the corresponding positions of the API request, including path parameters, query parameters, request headers, and request bodies. During the injection process, the system keeps other parameters that are not fuzzed as legal values and maintains their original structure and format. In particular, for parameters with dependency relationships, such as resource IDs, session tokens, etc., the system still uses valid values obtained from the previous response as placeholders, ensuring that the overall structure of the request is legal and can pass the basic verification and enter the business logic processing stage. This mixed mode of partial abnormality and partial legality improves the possibility of test payloads penetrating the front-end verification mechanism and helps to discover deep logic defects.

[0111] Finally, through the context understanding ability of the large language model, the generated abnormal data is filtered and adapted to ensure that it matches the specific business scenarios of the system to be tested. The model, based on the loaded context corpus, determines whether a certain abnormality is reasonable in the current interface usage environment. For example, in financial interfaces, negative or excessively large values are preferred, and in user management interfaces, permission promotion tests are emphasized. At the same time, the model avoids generating extreme inputs that are obviously invalid or will be immediately intercepted (such as complete gibberish), and instead selects data that is close to legal in syntax but violates rules in semantics, thereby improving the effectiveness and relevance of the test. Through this process, intelligent and scenario-based construction of abnormal data is achieved, enhancing the ability to detect business logic vulnerabilities.

[0112] According to an embodiment of the present application, the step of analyzing the response data comprises: parsing the HTTP status code, response header, and response body in the response data to identify abnormal status codes or error information; verifying the legality of the response data based on business rules, such as whether the report ID comes from the response of the previous call; By the semantic analysis capability of the large language model, it is determined whether there is an unauthorized operation, state skipping or logic loophole.

[0113] As described above, first, the response data captured after executing the test load is parsed. The system extracts the HTTP status code, response header and response body content in the response respectively. For the status code, it is identified whether there is an abnormal situation, such as server error (5xx status code), client request error (non-expected rejection situation in 4xx status code, such as 403 insufficient permission or 400 parameter error) and the like. For the response header, it is checked whether the key field is abnormal, such as lack of security policy header, exposure of internal service information or incorrect setting of session token. For the response body, the data structure (such as JSON or XML format) is parsed, the returned business data, message description or error details are extracted, and the basis for subsequent judgment is provided.

[0114] Secondly, based on the business rules defined in the context corpus, the legality of the response data is verified. The system checks whether the key parameters returned in the response conform to the business logic and process constraints. For example, whether the reportId returned after the "create report" operation is correctly referenced and processed in the subsequent "query" or "submit" request; in the approval process, whether the current operation occurs after the correct state, such as whether the "approval" operation returns success only when the report state is "submitted". At the same time, it is verified whether the response data contains information that should not appear, such as returning data of other users when unauthorized access, or leaking system stack, database structure and other sensitive content in failure response.

[0115] Finally, the semantic analysis capability of the large language model is used to make a deep judgment on the overall response behavior. The model combines the test target, expected behavior and actual response to identify whether there is a security risk or logic defect. For example, when a low-privilege user calls a high-privilege interface and returns 200 success, it is judged as an unauthorized operation loophole; when the "archive" is directly executed by skipping the "submit" state and a successful response is obtained, it is determined as a state skipping loophole; when the response result is obviously inconsistent with the business rules, such as the state is still "pass" after the rejection of the approval, it is identified as a logic processing error. The large language model can discover complex logic loopholes that traditional rule matching cannot capture by understanding the semantic relationship between operation intent, context state and system feedback, thereby improving the accuracy and comprehensiveness of analysis.

[0116] According to one embodiment of the present application, the step of dynamically adjusting the test strategy comprises: According to the analysis result, a feedback signal is generated, which contains the vulnerability type, failure cause and repair suggestion; Based on the feedback signal, the calling order, parameter value or state-aware logic of the subsequent test plan are adjusted; High-risk scenarios are prioritized for coverage during the iteration process, and the execution trajectory of all test steps is recorded.

[0117] As mentioned above, first, a feedback signal is generated according to the analysis result of the response data. This feedback signal is a summary and judgment of the current test execution situation, containing three core contents: first, the identified vulnerability types, such as unauthorized access, state skipping, missing parameter verification, or sensitive information leakage; second, the specific reasons for test failure, such as request denied due to missing authentication information, parameter format not meeting requirements, operation violating business state rules, etc.; third, repair suggestions generated based on large language model understanding, such as supplementing permission verification logic, adding state pre-judgment, desensitizing response data, etc. These feedback signals serve as the basis for subsequent test optimization, forming a closed loop from execution to cognition.

[0118] Second, based on the generated feedback signal, the subsequent test plan is adjusted. The system dynamically modifies the calling order in the test path according to the feedback content, such as inserting the "login" call at the beginning of the subsequent test sequence after discovering that a certain interface requires a pre-login operation; adjusting parameter values, such as replacing previously invalid parameters with abnormal values that meet the format requirements but are attack-oriented, or applying similar test payloads to similar interfaces that have discovered vulnerabilities; updating state awareness logic, such as expanding the test range after confirming that a state transition has a verification vulnerability, and attempting to reproduce similar behavior in other state paths. This adjustment enables the test process to have adaptive ability, allowing it to continuously deepen the detection of system weaknesses.

[0119] Finally, during the entire iterative test process, the system prioritizes the coverage of high-risk scenarios. High-risk scenarios include similar interfaces with discovered vulnerabilities, operations involving core business functions (such as payment, approval, data export), and frequent changes in permissions and state transitions. The system dynamically sorts test tasks according to the severity of vulnerabilities and the impact of business, ensuring that critical issues are exposed as soon as possible. At the same time, the execution trajectory of all test steps is recorded, including the test goal of each round, the generated calling sequence, the actual sent request, the received response, the analysis conclusion, and the strategy adjustment decision. This execution trajectory not only serves to generate the final report, but also provides support for the traceability and verifiability of the test process and results.

[0120] According to an embodiment of the present application, the termination condition comprises at least one of the following: Key vulnerabilities are discovered and a preset vulnerability threshold is reached; Verification of all predefined test objectives is completed; The maximum number of iterations or execution time exceeds the preset maximum number of iterations or execution time.

[0121] As mentioned above, the first case is that critical vulnerabilities are discovered and the preset vulnerability threshold is reached. The system continuously identifies and classifies the discovered vulnerabilities during the execution of the test process, and evaluates them according to their types, severity and impact range. When critical vulnerabilities (such as unauthorized access, identity bypass, sensitive data leakage or core business logic destruction) belonging to the high-risk category are detected and the cumulative number reaches the preset threshold, the test process is automatically terminated. This threshold is configured by the user or system policy, which controls the test to end in time after enough important issues are found, avoiding resource waste and quickly entering the problem response stage.

[0122] The second case is to complete the verification of all predefined test objectives. The test task is started with a set of test objectives, including a series of business scenarios, security checks or function paths that need to be covered. The system executes and verifies these objectives one by one during the iteration process. When all test objectives have been successfully executed and the corresponding test results (whether passed or failed) have been recorded and analyzed, the system determines that the test task is complete and triggers the termination process. This condition ensures the completeness of the test coverage and is suitable for test tasks guided by objective achievement.

[0123] The third case is to exceed the preset maximum number of iterations or execution time. To prevent the test process from running indefinitely or consuming too many resources, the system sets a maximum number of iterations and a maximum execution time limit. The maximum number of iterations refers to the upper limit of the number of rounds of test strategy adjustment and re-execution; the maximum execution time refers to the total time limit from the start to the termination of the test. When the actual number of iterations reaches the set upper limit, or the test has run to the predetermined time cutoff point, regardless of whether vulnerabilities are found or all objectives are completed, the system stops subsequent execution. This condition ensures the controllability of the test process and the rationality of resource usage, and is suitable for automated pipelines or timed inspections.

[0124] When any of the above conditions is met, the system determines that the test task has reached the termination state, stops generating new test payloads, and enters the result aggregation and report output phase.

[0125] The second aspect embodiment of the present application provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, the method in any of the embodiments of the first aspect is implemented.

[0126] Figure 2 An example of the physical structure of an electronic device is shown in the figure below. Figure 2As shown, the electronic device can include a processor 810, a communication interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 can communicate with each other through the communication bus 840. The processor 810 can invoke the logical instructions in the memory 830 to execute the method in any of the embodiments of the first aspect, which includes: loading context data of the system under test, the context data including structured data and unstructured data, the structured data including at least an API interface definition document and a parameter dependency table, and the unstructured data including at least a business rule document and a user manual; generating a test plan for the system under test according to a natural language test target input by a user, the test plan including a logical sequence of API calls, parameter dependencies, and expected state changes; generating an API call sequence including state awareness based on the test plan and the context data, the state awareness being used to ensure that the API calls conform to the business rules of the system under test, and intelligently fuzzing request parameters in the API call sequence to generate a test payload including abnormal data; executing the API calls corresponding to the test payload, capturing response data of the system under test, analyzing the response data to identify potential vulnerabilities or system abnormalities, and dynamically adjusting subsequent test strategies based on the analysis results to form a closed-loop feedback, iteratively executing the above steps until a preset termination condition is met, and outputting a test result report.

[0127] In addition, the logical instructions in the memory 830 described above can be implemented in the form of a software function unit and sold or used as an independent product, which can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application essentially or the parts that contribute to the prior art or parts of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, including a plurality of instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the methods described in the embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory, a random access memory, a magnetic disk or an optical disk, and various media that can store program codes.

[0128] On the other hand, the present application also provides a computer program product, which includes a computer program, the computer program can be stored on a non-transitory computer readable storage medium, and the computer program is executed by a processor, so that the computer can execute the method provided by the above-mentioned methods, which includes: loading context data of the system under test, the context data including structured data and unstructured data, the structured data including at least an API interface definition document and a parameter dependency table, and the unstructured data including at least a business rule document and a user manual; generating a test plan for the system under test according to a natural language test target input by a user, the test plan including a logical order of API calls, parameter dependencies, and expected state changes; generating an API call sequence including state awareness based on the test plan and the context data, the state awareness being used to ensure that the API calls conform to business rules of the system under test, and intelligently fuzzing request parameters in the API call sequence to generate a test payload including abnormal data; executing API calls corresponding to the test payload, capturing response data of the system under test, analyzing the response data, identifying potential vulnerabilities or system abnormalities, and dynamically adjusting a subsequent test strategy based on an analysis result, forming a closed-loop feedback, iteratively executing the above steps until a preset termination condition is met, and outputting a test result report.

[0129] In another aspect, the application also provides a non-transitory computer readable storage medium having a computer program stored thereon, the computer program being executed by a processor to implement a cigarette case image recognition method provided by each of the above methods, the method including: loading context data of the system under test, the context data including structured data and unstructured data, the structured data including at least an API interface definition document and a parameter dependency table, and the unstructured data including at least a business rule document and a user manual; generating a test plan for the system under test according to a natural language test target input by a user, the test plan including a logical order of API calls, parameter dependencies, and expected state changes; generating an API call sequence including state awareness based on the test plan and the context data, the state awareness being used to ensure that the API calls conform to business rules of the system under test, and intelligently fuzzing request parameters in the API call sequence to generate a test payload including abnormal data; executing API calls corresponding to the test payload, capturing response data of the system under test, analyzing the response data, identifying potential vulnerabilities or system abnormalities, and dynamically adjusting a subsequent test strategy based on an analysis result, forming a closed-loop feedback, iteratively executing the above steps until a preset termination condition is met, and outputting a test result report.

[0130] Embodiment 2 As Figure 3As shown, the overall architecture of the API fuzzing system proposed in this application is demonstrated. The system mainly consists of the following modules: Target System: This is the application that needs to be tested for security, such as "Wave Report Platform". The system provides services to the outside through a set of APIs.

[0131] Context Ingestion Module: This module is responsible for collecting and preprocessing all background information related to the target system, providing decision-making basis for large language models. Its input sources include: Structured data: such as OpenAPI / Swagger v2 / v3 specification files, Postman Collection v2.0 / 2.1, HTTP Archive (HAR) files, etc. These files define the API endpoints, parameters, data formats and basic request structure.

[0132] Unstructured data: such as user manuals, developer documents, business requirement documents, and even source code comments in plain text format. These documents describe the business logic, usage scenarios and design intent of the API.

[0133] After all these data are integrated and processed, a "context corpus" is formed, which serves as the knowledge base for the LLM core.

[0134] LLM Core: The brain of the system, usually a pre-trained large language model, such as a model based on the Transformer architecture (such as the GPT-4 series). It receives the corpus from the context ingestion module and high-level instructions from the outside, and is responsible for semantic understanding, logical reasoning and content generation.

[0135] Test Sequence Generation Engine: This engine works closely with the LLM core. It receives a high-level, natural language description of the test goal (for example: "test the permission bypass vulnerability in the report approval process"), and generates a specific, ordered API request sequence by issuing a series of carefully designed prompts to the LLM core. This process includes generating complete HTTP requests for each step in the sequence, including request methods, URLs, headers and intelligent payloads.

[0136] Test Executor: This module's function is to receive the test sequences created by the generation engine and initiate real API calls to the target system in the specified order. It is responsible for handling network communication and accurately capturing the complete response of each call, including HTTP status code, response headers, and response body.

[0137] Response Analysis & Feedback Module: This is the key innovative component that distinguishes the present application from the prior art. It feeds the raw API responses obtained from the test executor to the LLM core for analysis. The LLM core uses its powerful understanding capabilities to interpret the responses to achieve the following purposes: Fault Identification: Detect server crashes (5xx series errors), security configuration errors (such as detailed error stacks that leak sensitive information), or unexpected successful operations (e.g., in an unauthorized operation that is expected to return "403 Forbidden", but "200 OK" is received).

[0138] State Update: Maintain an understanding of the current state of the application. For example, after a successful login, the module will record the session token and inform the LLM that this token needs to be used in subsequent requests.

[0139] Strategy Refinement: Learn from failures. If a request fails because of the lack of a required parameter, the LLM can infer what this parameter might be and how to obtain it based on the information in the context corpus, and generate a new request for retry. This process forms a self-adaptive, closed-loop testing process.

[0140] Methods and Processes The following shows the specific execution steps of the method of the present application: Step 1: Context Loading The process begins with the context ingestion module loading the context corpus about the system under test into the LLM core. This step provides the LLM with deep knowledge about the expected functions and business rules of the system under test.

[0141] Step 2: Goal Definition The tester (or automated system) provides a high-level, natural language description of the test goal. For example, "Test if there is a privilege escalation vulnerability in the user profile modification function", or select from a predefined set of generic security test goals (e.g. test for SQL injection, test for broken access control, etc.).

[0142] Step 3: Test Plan Generation The test sequence generation engine prompts the LLM core to decompose the high-level test goal into a logically coherent test plan. For the goal "bypass approval", the LLM-generated plan might be: 1. Authenticate using the credentials of low-privilege user A; 2. Create a new report using user A's identity; 3. Find the endpoint and request format for approving reports from the API documentation; 4. Attempt to call the approval endpoint using user A's authentication token, targeting the just-created report.

[0143] Step 4: Stateful Sequence Construction The LLM core translates the above test plan into a concrete, executable sequence of API calls. It utilizes its contextual knowledge to populate specific parameters in the requests. For example, it knows from the documentation that the API to create a report returns a reportId, and that the subsequent approval operation needs to use this reportId as a path parameter or part of the request body. This embodies its ability to perceive and handle state.

[0144] Step 5: Intelligent Payload Fuzzing Based on the constructed API call sequence, the LLM injects fuzzed data. This injection is not random, but intelligent and targeted: Type-aware: Insert a string in a field expected to be an integer.

[0145] Format-aware: Provide a malformed object in a JSON request body.

[0146] Security-aware: Inject classic attack payloads targeting specific vulnerability types, such as'OR '1'='1 for SQL injection.

[0147] Logic-aware: This is the unique aspect of the present application. For example, enter a negative number in a field representing an amount; or in a scenario where business logic dictates that a report must be in the "submitted" state to be approved, deliberately attempt the approval operation on a report in the "draft" state.

[0148] Step 6: Execution and Monitoring The test executor sends the generated API request sequence containing fuzzed payloads to the target system one by one, and records the response of each request in detail.

[0149] Step 7: Response Analysis and Learning The response analysis and feedback module passes the captured response to the LLM core. The LLM interprets the results. If a vulnerability is found (for example, a low-privilege user successfully approves a report), the vulnerability and its reproduction steps will be recorded in detail. If an obstacle is encountered (for example, the server returns a "400 Bad Request" and prompts for a missing field), the LLM will understand this error information.

[0150] Step 8: Iteration and Refinement Based on the analysis results of step 7, the LLM generates an optimized new test sequence, and the process returns to step 4 for continuous execution. For example, if the previous step failed due to a missing field, the new sequence will attempt to include the required field inferred by the LLM. This iterative, self-correcting closed loop is the key to efficient intelligent testing in this application. This feedback loop is not simply a repetition, but an "AI-driven cognitive loop" that transforms the fuzzing tool from a "brute force tool" that only executes pre-set instructions into an "intelligent agent" that can learn and solve problems independently, thereby overcoming the widespread vulnerability and low adaptability problems in the prior art.

[0151] The places not mentioned in this application can be implemented or borrowed from the existing technology.

[0152] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between each embodiment can be referred to each other. Each embodiment focuses on the differences from other embodiments.

[0153] The above only describes the embodiments of the present application and is not intended to limit the present application. Those skilled in the art can make various modifications and changes to the present application. Any modification, equivalent replacement, improvement, etc. within the spirit and principles of the present application shall be included in the scope of the claims of the present application.

Claims

1. A context-aware API intelligent testing method, characterized in that: include: Loading context data of the system under test, the context data includes structured data and unstructured data, the structured data includes at least API interface definition documents and parameter dependency tables, and the unstructured data includes at least business rule documents and user manuals; Generate a test plan for the system under test based on the natural language test objectives entered by the user. The test plan includes the logical sequence of API calls, parameter dependencies, and expected state changes. Based on the test plan and the context data, a state-aware API call sequence is generated, wherein the state-aware API call is used to ensure that the API call complies with the business rules of the system under test, and request parameters in the API call sequence are intelligently fuzzified to generate a test payload containing abnormal data; Execute the API call corresponding to the test load, capture the response data of the system under test, analyze the response data, identify potential vulnerabilities or system anomalies, and dynamically adjust subsequent test strategies based on the analysis results to form a closed-loop feedback loop. Iterate the above steps until the preset termination conditions are met and output the test result report.

2. The method according to claim 1, characterized in that The step of loading context data includes: Extract endpoint information, request methods, and parameter specifications from the API interface definition document through the structured data parsing module; The natural language processing module parses the business rules in unstructured data to generate parameter dependency tables and state transition rules; The parsed data is integrated into a context corpus and loaded into the large language model for subsequent calls.

3. The method according to claim 1, characterized in that Generating a test plan for the system to be tested includes: Decompose the natural language test goal of user input into multiple sub-goals, each of which corresponds to a specific business scenario of the system under test; Based on the context corpus, determine the API call path and required parameters corresponding to each sub-goal; Through the semantic understanding ability of the large language model, the feasibility of the API call path is verified and the missing preconditions are supplemented.

4. The method according to claim 1, wherein The executing of the API call corresponding to the test load includes: Determine the timing relationship of API calls according to the logical sequence in the test plan and mark the dependency status of each API call; Dynamically fill in API request details, including request method, URL path, request header, and request body, through a large language model; Embed state-aware logic in the request body to ensure that subsequent API calls are executed only when the pre-conditions are met.

5. The method according to claim 4, characterized in that The steps of the intelligent fuzzy processing include: Generate parameter value exception types based on the business rules of the system under test, including type exceptions, format abnormalities, logical conflicts, and classic attack payloads; Inject the generated abnormal parameter values ​​into the API request and retain placeholders for legal parameter values ​​to support subsequent calls; Through the contextual understanding capabilities of large language models, we ensure that abnormal data matches the business scenarios of the system under test.

6. The method according to claim 1, characterized in that The analyzing the response data includes: Parse the HTTP status code, response header, and response body in the response data to identify abnormal status codes or error messages; Verify the legitimacy of response data based on business rules; Through the semantic analysis capabilities of the large language model, it is possible to determine whether there are unauthorized operations, state skipping or logical loopholes.

7. The method according to claim 1, characterized in that The dynamic adjustment of subsequent test strategies based on the analysis results includes: Generate a feedback signal based on the analysis results, including vulnerability type, failure cause, and repair suggestions; Based on the feedback signal, adjusting the calling sequence, parameter values ​​or state perception logic of subsequent test plans; During the iteration process, high-risk scenarios are covered first and the execution traces of all test steps are recorded.

8. The method according to claim 1, characterized in that The termination condition includes at least one of the following: Discover critical vulnerabilities and reach the preset vulnerability threshold; Complete verification of all predefined test objectives; The preset maximum number of iterations or execution time was exceeded.

9. A computer-readable storage medium having a program stored thereon, characterized in that: When the program is executed by a processor, the steps in the method according to any one of claims 1 to 8 are implemented.

10. An electronic device comprising a memory, a processor, and a program stored in the memory and executable on the processor, wherein: When the processor executes the program, the steps in the method according to any one of claims 1 to 8 are implemented.

Images