A context-aware based API intelligent testing method

Abstract

The application provides a context-aware-based API intelligent testing method, and relates to the technical field of software testing, which comprises the following steps: constructing a system context corpus by loading structured data such as API interface documents and parameter dependency tables, and unstructured data such as business rules and user manuals. According to the natural language test target input by the user, a test plan containing the calling sequence, parameter dependency and state change is generated in combination with the context, and a state-aware API calling sequence is further generated. The test load is formed by intelligently fuzzing the parameters. The load is executed and the response is captured, and the vulnerabilities or abnormalities are analyzed and identified. The test strategy is dynamically adjusted based on the results, a closed-loop feedback is formed, and the iteration is executed until the termination condition is met, and finally the test report is output.

Description

Technical Field

[0001] This application belongs to the field of software testing technology, specifically relating to a context-aware API intelligent testing method. Background Technology

[0002] With the widespread application of enterprise-level information systems (such as reporting platforms and cloud service platforms), their functions are becoming increasingly complex, the number of APIs is growing rapidly, and many involve cross-system integration and multi-user role interaction. Traditional software testing methods have shown significant shortcomings in addressing the security and stability verification of such systems.

[0003] In existing technologies, fuzzing, as a mainstream automated testing method, involves inputting large amounts of random or mutated data into a target system to trigger program crashes, memory leaks, or unexpected behavior, thereby discovering potential vulnerabilities. However, traditional fuzzing tools are mostly stateless, 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 typically includes: user login → creating a report draft → submitting for approval → approver viewing and approving. Traditional tools struggle to maintain session state, track resource IDs (such as reportId), and understand the semantic dependencies between "submit" and "approval."

[0004] Furthermore, while current advanced stateful fuzzing tools (such as RESTler) can infer parameter dependencies based on the OpenAPI specification and generate API call chains to a certain extent, they are still limited to syntactic analysis and lack semantic understanding of business rules. For example, they cannot determine logical vulnerabilities such as "whether ordinary users can bypass the approval process and directly archive reports." In addition, these tools heavily rely 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] Meanwhile, generative artificial intelligence, particularly large language models (LLMs), has demonstrated powerful capabilities in natural language understanding, logical reasoning, and code generation. However, a mature technical solution has yet to be developed for effectively integrating the capabilities of large language models into the field of API security testing, especially for achieving the leap from "syntax testing" to "semantic testing." Summary of the Invention

[0006] This application provides a context-aware API intelligent testing method to solve one of the aforementioned technical problems.

[0007] The technical solution adopted in this application is as follows:

[0008] This application provides a context-aware API intelligent testing method, including:

[0009] Load the 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. The unstructured data includes at least business rule documents and user manuals.

[0010] Based on the natural language testing objectives input by the user, a test plan is generated for the system under test. The test plan includes the logical order of API calls, parameter dependencies, and expected state changes.

[0011] Based on the test plan and the context data, an API call sequence with state awareness is generated. The state awareness is used to ensure that the API calls comply with the business rules of the system under test. The request parameters in the API call sequence are intelligently obfuscated to generate a test load containing abnormal data.

[0012] The API calls corresponding to the test payload are executed, the response data of the system under test is captured, the response data is analyzed, potential vulnerabilities or system anomalies are identified, and the subsequent test strategies are dynamically adjusted based on the analysis results to form a closed-loop feedback. The above steps are executed iteratively until the preset termination conditions are met, and a test result report is output.

[0013] According to one embodiment of this application, the step of loading context data includes:

[0014] The structured data parsing module extracts endpoint information, request methods, and parameter specifications from the API interface definition document.

[0015] The natural language processing module parses business rules in unstructured data to generate parameter dependency tables and state transition rules.

[0016] The parsed data is integrated into a contextual corpus and loaded into a large language model for subsequent use.

[0017] According to one embodiment of this application, the step of generating a test plan includes:

[0018] The natural language test objectives input by the user are broken down into multiple sub-objectives, each corresponding to a specific business scenario of the system under test;

[0019] Based on the aforementioned context corpus, determine the API call path and required parameters for each sub-target;

[0020] The feasibility of the API call path was verified by leveraging the semantic understanding capabilities of a large language model, and missing preconditions were supplemented.

[0021] According to one embodiment of this application, the step of generating the API call sequence includes:

[0022] Based on the logical order in the test plan, determine the timing relationship of API calls and mark the dependency status of each API call;

[0023] Dynamically populate API request details using a large language model, including request method, URL path, request headers, and request body;

[0024] Embed state-aware logic in the request body to ensure that subsequent API calls are executed only when the preceding state conditions are met.

[0025] According to one embodiment of this application, the steps of the intelligent fuzzification process include:

[0026] Based on the business rules of the system under test, generate the abnormal types of parameter values, including type anomalies, format malformations, logical conflicts, and classic attack payloads;

[0027] Inject the generated abnormal parameter values ​​into the API request, and retain placeholders for valid parameter values ​​to support subsequent calls;

[0028] By leveraging the contextual understanding capabilities of large language models, we can ensure that abnormal data matches the business scenario of the system under test.

[0029] According to one embodiment of this application, the step of analyzing the response data includes:

[0030] Parse the HTTP status codes, response headers, and response body in the response data to identify abnormal status codes or error messages;

[0031] The validity of the response data is verified based on business rules, such as whether the report ID comes from the response of the previous call;

[0032] By leveraging the semantic analysis capabilities of large language models, it can be determined whether there are unauthorized operations, state skipping, or logical vulnerabilities.

[0033] According to one embodiment of this application, the step of dynamically adjusting the testing strategy includes:

[0034] Based on the analysis results, a feedback signal is generated, which includes the vulnerability type, the reason for failure, and remediation suggestions.

[0035] Based on the feedback signal, adjust the calling order, parameter values, or state awareness logic of subsequent test plans;

[0036] During the iteration process, high-risk scenarios are prioritized for coverage, and the execution trajectory of all test steps is recorded.

[0037] According to one embodiment of this application, the termination condition includes at least one of the following:

[0038] Discover critical vulnerabilities and reach the preset vulnerability threshold;

[0039] Complete the verification of all predefined test objectives;

[0040] The maximum number of iterations or execution time has been exceeded.

[0041] A second aspect of this application provides a computer-readable storage medium having a program stored thereon that, when executed by a processor, implements the steps described in the method.

[0042] A third aspect of this application provides an electronic device including a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method as described.

[0043] Due to the adoption of the above technical solution, the beneficial effects achieved by this application are as follows:

[0044] This application loads contextual data, including API interface definition documents, parameter dependency tables, business rule documents, and user manuals, enabling the large language model to fully understand the structure and behavioral logic of the system under test. The resulting test plan not only includes the logical sequence of API calls but also clarifies parameter dependencies and expected state changes, ensuring that the generated API call sequence can simulate the complete operation path of a real user, significantly improving test coverage for multi-step business processes.

[0045] Based on user-input natural language testing objectives (such as "testing for permission bypass"), this application enables the system to generate "state-aware" API call sequences by combining contextual data. For example, it can attempt to perform an approval operation before a report is submitted, or use a low-privilege account to call a high-privilege interface. This capability allows the system to proactively detect business logic vulnerabilities that traditional tools cannot find, achieving a technological leap from "syntactic compliance testing" to "semantic rationality verification."

[0046] This application employs intelligent obfuscation of request parameters in API call sequences. The system can inject anomalous data, such as data with type errors, malformed formats, logical conflicts, or classic attack payloads, while maintaining basic syntactic correctness. Because the obfuscation process is based on an understanding of business rules, the generated test payloads are more targeted, significantly reducing invalid input and improving testing efficiency and vulnerability detection rate.

[0047] This application enables the system to identify potential vulnerabilities or system anomalies by executing test loads, capturing response data, and performing in-depth analysis. More importantly, it dynamically adjusts subsequent testing strategies based on the analysis results, forming a closed-loop feedback loop. For example, when the response returns "401 Unauthorized," the system can automatically complete the authentication information and retry; when successful authorization is detected, the testing scope can be expanded to verify other sensitive interfaces. This mechanism significantly enhances the robustness and intelligence of the testing process.

[0048] This application iterates through the testing process multiple times until preset termination conditions are met (such as discovering critical vulnerabilities or completing all testing objectives). The system can progressively explore the potential risks of the system under test. The final test result report not only includes vulnerability details but also a complete reproduction path and execution logs, ensuring the traceability of the testing process and the verifiability of the results. Attached Figure Description

[0049] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0050] Figure 1 A flowchart illustrating a context-aware API intelligent testing method provided in this application embodiment;

[0051] Figure 2 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application;

[0052] Figure 3 This is a system architecture diagram of a context-aware API intelligent testing method provided in an embodiment of this application.

[0053] Figure label:

[0054] 810, Processor; 820, Communication interface; 830, Memory; 840, Communication bus. Detailed Implementation

[0055] To more clearly illustrate the overall concept of this application, a detailed explanation is provided below with reference to the accompanying drawings.

[0056] Many specific details are set forth in the following description to provide a thorough understanding of this application. However, this application may also be implemented in other ways different from those described herein. Therefore, the scope of protection of this application is not limited to the specific embodiments disclosed below. It should be noted that, unless otherwise specified, the embodiments of this application and the features thereof can be combined with each other.

[0057] In this application, unless otherwise expressly specified and limited, the "above" or "below" of the second feature can mean that the first and second features are in direct contact, or that the first and second features are in indirect contact through an intermediate medium. In the description of this specification, references to terms such as "an embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples.

[0058] Example 1

[0059] like Figure 1 As shown, a context-aware API intelligent testing method includes:

[0060] Load the 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. The unstructured data includes at least business rule documents and user manuals.

[0061] As mentioned above, structured data refers to data sources with a clear format and field definitions, which can be directly parsed and have key information extracted by programs. For example, API interface definition documents (such as OpenAPI / Swagger files) contain metadata such as the request method, path, parameter types, and request body structure for each endpoint; parameter dependency tables explicitly describe the input-output relationships between different API calls, such as the resource ID returned by a creation operation needing to be used as an input parameter for subsequent query or update operations. This data constitutes the "skeleton" of system interaction.

[0062] Unstructured data refers to textual materials existing in natural language, such as business rule documents, user manuals, requirements specifications, and system design documents. While this type of data lacks a fixed format, it contains rich semantic information such as business intent, state transition logic, and access control strategies. For example, rules such as "reports cannot be edited after submission" and "approvers cannot approve reports they themselves have submitted" are usually not reflected in API documentation, but are crucial for testing logic. By introducing this type of data, the system can understand "what operations are legal under what conditions," thereby supporting proactive detection of business logic vulnerabilities.

[0063] By loading and integrating the two types of data into a contextual corpus, the large language model not only knows "how to call the API," but also understands "why it is called this way," providing a knowledge base for generating test plans that conform to business semantics and identifying abnormal behavior.

[0064] For example, let's take an enterprise-level report management system as an example to illustrate the specific implementation of this step:

[0065] Loading structured data:

[0066] The system imports the OpenAPI v3 specification file of the reporting platform and extracts all API endpoint information from it, such as POST / reports for creating reports, PUT / reports / {id} / submit for submitting reports, and GET / reports / {id} for viewing reports.

[0067] At the same time, the parameter dependencies were parsed out: the response body of POST / reports contains a reportId field, which must be used as the {id} parameter in the paths PUT / reports / {id} / submit and GET / reports / {id}.

[0068] This information is stored in a structured manner, forming an API call graph and parameter mapping table, which can be referenced when generating stateful call sequences later.

[0069] Loading unstructured data:

[0070] The system reads the "Report Approval Operation Manual" and "System Security Design Document" provided by the company, which state: "Reports must be approved by the department head to take effect after creation," "Ordinary employees have no right to view sensitive reports from other departments," and "Reports are prohibited from being modified after being archived."

[0071] Natural language processing technology is used to transform these rules into semantic expressions that machines can understand. For example, "submit" is a prerequisite for "approval", "archive" is a terminated state, and "cross-department access" is restricted by role permissions.

[0072] These semantic rules are incorporated into the contextual knowledge base to guide whether test sequences violate business logic (such as skipping submissions and directly approving them).

[0073] By coordinating the loading of the two types of data, the system constructs a complete context model that includes both interface syntax structure and business semantic rules, laying a solid foundation for subsequent intelligent test generation.

[0074] It should be noted that, in specific implementation scenarios, the above solution can be extended to other standardized interface description formats such as Postman collection files, HAR (HTTP Archive) files, and gRPC Protobuf definition files. It can also include call chain logs generated during system runtime (such as trace data based on OpenTelemetry), from which the API call order and parameter passing paths can be automatically inferred, compensating for missing or outdated documentation. Parameter dependency tables can also be automatically generated by the system through analysis of historical call data, rather than relying entirely on manual maintenance.

[0075] In specific implementation scenarios, the above solutions can be expanded to include comments in the source code (such as JavaDoc and Python Docstring), change notes in Git commit records, and requirement descriptions from project management tools like Jira. It supports parsing multilingual documents, making it suitable for testing scenarios in multinational corporations or multilingual systems. 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.

[0076] In specific implementation scenarios, the context data can support incremental loading and dynamic update mechanisms, building upon the above solutions. For example, when the system detects an API documentation version upgrade, a context refresh process is automatically triggered to ensure the test knowledge base is always synchronized with the latest system state. Context priority strategies can be set; for instance, when there is a conflict between the API documentation and the user manual, the business rules in the manual are prioritized, reflecting the testing principle of "business intent over interface implementation." The reliability of context data can be evaluated; for example, information from official documentation is given higher weight than internal notes, preventing noisy data from interfering with test decisions.

[0077] In specific implementation scenarios, based on the above solutions, a sensitive information identification and de-identification module can be integrated during the loading of context data to automatically filter confidential content such as keys and account passwords 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 locally deployed context processing mechanism can be adopted to avoid the risk of data leakage.

[0078] Based on the natural language testing objectives input by the user, a test plan is generated for the system under test. The test plan includes the logical order of API calls, parameter dependencies, and expected state changes.

[0079] As mentioned above, natural language testing objectives refer to testing intentions entered by testers in everyday language, such as "testing whether ordinary users can approve their own reports" or "verifying the existence of unauthorized data export vulnerabilities." These objectives do not involve specific technical details but focus on security risks at the business logic level.

[0080] The test plan generation process relies on the context data loaded in the preceding steps. The large language model, combining API interface definitions, parameter dependencies, and business rule documents, performs semantic understanding of the natural language target, breaking it down into a series of logically coherent subtasks. Each subtask corresponds to a specific API operation, clearly defining its position in the overall process, required preconditions, and expected state changes.

[0081] The logical order of API calls refers to the time and causal relationship between multiple API calls, such as having to log in before creating a report, or having to submit before approval.

[0082] The parameter dependency refers to the use of the output of one API call (such as resource ID, token) as the input of another API call to ensure the integrity of the call chain.

[0083] The expected state change refers to the business state that the system should enter after performing a certain operation, such as a report changing from "draft" to "submitted", or a user's permission being upgraded from "normal" to "administrator".

[0084] By generating a test plan that includes the above three elements, the system can not only simulate normal business processes, but also proactively construct abnormal paths (such as skipping necessary steps or reversing operations), thereby effectively detecting logical vulnerabilities.

[0085] For example, let's take an internal expense reimbursement system of a company as an example to illustrate the specific implementation of this step:

[0086] User input natural language testing objectives:

[0087] The tester entered: "Can employees file expense reports directly without submitting approval?"

[0088] Large language models are used for semantic parsing and task decomposition.

[0089] The model identifies keywords by combining contextual data: "employee" corresponds to a low-privilege role, "submit for approval" is an intermediate state, and "archive" is the final operation.

[0090] According to the business rules document, the normal process should be "Create → Submit → Approval → Archive", and "Archive" can only be executed by administrators.

[0091] The model determines that the test objective is to verify the existence of both "state skipping" and "privilege bypass" vulnerabilities.

[0092] Generate a structured test plan:

[0093] Logical order:

[0094] Log in using your employee account;

[0095] Create a new expense report;

[0096] Skip the "Submit for Approval" step;

[0097] Directly call the "Archived Expense Report" interface.

[0098] Parameter dependencies:

[0099] The session token in the login response is used for all subsequent requests;

[0100] The expenseId returned by the expense report creation is used as the path parameter of the archiving interface.

[0101] Expected state changes:

[0102] Under normal circumstances, calling the archive interface should return "403 Forbidden" (insufficient permissions) or "400 BadRequest" (illegal status).

[0103] If "200 OK" is returned, it indicates that there is a serious logical flaw.

[0104] The test plan clearly describes the attack path, providing guidance for the subsequent generation of specific API call sequences and obfuscated payloads.

[0105] It should be noted that, in specific implementation scenarios, in addition to the above solutions, natural language test targets can not only be manually input, but also originate from automated systems, such as risk items in security requirements management systems, checkpoints in compliance audit checklists, or typical attack patterns in historical vulnerability databases. The system supports batch importing of multiple test targets and can automatically generate corresponding test plan sets, suitable for large-scale regression testing or compliance verification scenarios.

[0106] In specific implementation scenarios, based on the above solutions, we can also provide macro-level (covering the entire business module, such as "testing all approval interfaces"), meso-level (targeting a specific functional process, such as "leave approval closed loop"), and micro-level (focusing on a single boundary condition, such as "negative amount reimbursement"). We support generating two types of test plans: positive test plans (verifying normal functionality) and negative test plans (detecting abnormal behavior), to meet different testing objectives.

[0107] In specific implementation scenarios, based on the above solutions, the test plan content can be dynamically adjusted in real time by referencing the current system status (such as existing resources and user role permissions) during the test plan generation process. For example, if a report is detected to have been archived, related editing tests can be automatically skipped. By combining historical test results, similar paths to previously discovered vulnerabilities can be prioritized for generation, improving testing efficiency.

[0108] In specific implementation scenarios, building upon the above approach, when multiple test objectives are input simultaneously, the system can identify their logical relationships (such as dependencies, parallelism, and conflicts) and generate a unified comprehensive test plan. For example, "testing unauthorized access" and "testing data leakage" can be merged into a single call chain containing unauthorized reading of sensitive fields. For contradictory objectives (such as "prohibiting the deletion of approved reports" and "allowing deletion after revocation of approval"), the system can flag potential rule conflicts to assist developers in refining the business logic.

[0109] In specific implementation scenarios, based on the above solutions, testers can interactively modify and confirm the generated test plans, forming a collaborative mechanism of "AI generation + manual verification," balancing automation efficiency with professional judgment. Visual representations of the test plans, such as flowcharts or state machine diagrams, can be provided for easier understanding and review.

[0110] In specific implementation scenarios, industry-specific knowledge bases (such as anti-fraud rules in the financial industry and privacy protection standards in the medical system) can be integrated on top of the above solutions to ensure that the generated test plans meet industry compliance requirements. For emerging vulnerability types (such as supply chain attacks and AI model poisoning), the knowledge base can be updated to support the parsing of new test targets and the generation of test plans.

[0111] Based on the test plan and the context data, an API call sequence with state awareness is generated. The state awareness is used to ensure that the API calls comply with the business rules of the system under test. The request parameters in the API call sequence are intelligently obfuscated to generate a test payload containing abnormal data.

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

[0113] This step utilizes the previously generated test plan (including logical order, parameter dependencies, and expected state changes) and loaded context data (such as API definitions and business rules) to dynamically construct a call path that conforms to business semantics using a large language model. This path not only includes basic structures such as request methods, URLs, and header information, 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 a "Submit Report" operation to meet the prerequisite state requirements, or intentionally skip this step to test the soundness of the state verification mechanism.

[0114] Based on the generated legitimate call sequence, the system injects targeted abnormal data into the request parameters. Unlike traditional random fuzzing, the "intelligent fuzzing" in this application has the following characteristics:

[0115] Type awareness: Select the appropriate exception type based on the parameter definition (such as integer, string, enumeration value) (e.g., replace number with string);

[0116] Format awareness: For structured data such as JSON and XML, construct payloads that are syntactically valid but semantically abnormal (such as missing required fields or adding illegal nesting).

[0117] Logic awareness: Construct logically conflicting inputs by combining business rules (such as using the creator's identity token in the "Approval" operation);

[0118] Security Awareness: Injects known attack patterns (such as SQL injection fragments and cross-site scripting code) to detect common security vulnerabilities.

[0119] The "abnormal data" is not completely invalid, but is designed to pass preliminary validation at the grammatical level, but violates semantic or permission levels, thus making it more likely to penetrate front-end validation and trigger deep logical defects.

[0120] Through the above two steps of collaboration, the final generated test payload has both the "legitimacy" of real user operation and the "abnormal kernel" of attack intent, which significantly improves the ability to discover hidden vulnerabilities.

[0121] For example, let's take an enterprise contract management system as an example to illustrate the specific implementation process of this step:

[0122] Test plan input:

[0123] The test plan generated in the preceding steps is: "Verify whether ordinary employees can directly perform the 'archive' operation when the contract is in the 'draft' state."

[0124] Generate a state-aware API call sequence:

[0125] Step 1: Call POST / login to log in using a regular employee account and obtain a session token.

[0126] Step 2: Call POST / contracts to create a new contract. The system returns contractId=123.

[0127] Step 3: Skip the PUT / contracts / 123 / submit operation;

[0128] Step 4: Directly call PUT / contracts / 123 / archive to attempt archiving.

[0129] During this process, the system clearly knows that the prerequisite state for the "archiving" operation should be "committed", but the test objective requires skipping this state. Therefore, the call sequence is constructed as a state violation path to detect whether the system has sufficient state verification capabilities.

[0130] Intelligent fuzzification processing:

[0131] In the request body of step four, the system processes the parameters as follows:

[0132] The operatorRole field should have been "administrator", but it was replaced with "employee" (logical conflict);

[0133] The timestamp field is set to a future time (the format is valid but the semantics are incorrect).

[0134] A valid authentication token is retained in the request header to ensure that the request can enter the business logic layer.

[0135] The final generated test payload appears legitimate, but in fact contains multiple anomalies, and can simultaneously detect security issues in multiple dimensions such as access control, status verification, and input filtering.

[0136] After the test load is executed, if the system returns "200 OK", it indicates a serious business logic vulnerability; if it returns an error but exposes stack trace information, it may pose a risk of information leakage. In either case, the system can accurately identify and record the vulnerability.

[0137] It should be noted that, in specific implementation scenarios, the above solution can be further enhanced to support multi-role collaborative state transitions. For example, it can simulate a cross-role process of "User A creates → User B approves → User C archives," and verify the correctness of role permissions during state changes. A "virtual state machine" model can be introduced, abstracting business states as nodes and API operations as edges. The system can automatically traverse all possible state transition paths, including unconventional jumps (such as going directly from "draft" to "void"), achieving more comprehensive path coverage. It also supports handling concurrent states, such as locking mechanisms and consistency checks when multiple users simultaneously attempt to approve the same report.

[0138] In specific implementation scenarios, based on the above solutions, various types of sequences can be generated, such as positive sequences (verifying normal processes), negative sequences (testing abnormal paths), and boundary sequences (testing critical values), to meet different needs such as functional testing, security testing, and stability testing. Conditional branching is supported; for example, the subsequent call path can be dynamically selected based on the response result of the previous API (e.g., archived if approved, re-edited if rejected). A historical vulnerability pattern library can be integrated, prioritizing the reproduction of high-risk operation combinations when generating sequences.

[0139] In specific implementation scenarios, based on the above solutions, if an interface frequently returns 400 errors, the system can reduce the obfuscation intensity, prioritizing ensuring syntax compliance; if the response is stable, the offensive payload can be gradually increased. Prioritization of obfuscation strategies is supported, for example, testing privilege circumvention vulnerabilities first, then testing injection vulnerabilities. A "progressive obfuscation" mechanism can be introduced, starting with minor anomalies and gradually increasing the degree of deviation, making it easier to pinpoint the precise boundaries of vulnerability triggering.

[0140] In specific implementation scenarios, based on the above solutions, the system can perform similarity analysis on the generated test loads to avoid repeatedly executing highly redundant request combinations and improve testing efficiency. It also supports load optimization based on response feedback: if a certain type of anomaly is consistently blocked, the system can automatically adjust the generation strategy and try more subtle variants.

[0141] In specific implementation scenarios, the generated test payloads, based on the above solutions, can be exported in standard formats (such as Postman collections or HAR files) for reuse by other testing tools. It can also be integrated with static code analysis tools to focus obfuscation on interfaces with high code complexity or numerous historical defects.

[0142] In specific implementation scenarios, based on the above solutions, a sensitive data identification mechanism can be integrated during the obfuscation process to prevent accidental disclosure of real user information or keys in requests. It also supports enabling "shadow mode" in the test environment, where all abnormal requests do not actually modify data but are only used to observe system behavior, preventing tests from causing real business interruptions.

[0143] The API calls corresponding to the test payload are executed, the response data of the system under test is captured, the response data is analyzed, potential vulnerabilities or system anomalies are identified, and the subsequent test strategies are dynamically adjusted based on the analysis results to form a closed-loop feedback. The above steps are executed iteratively until the preset termination conditions are met, and a test result report is output.

[0144] As described above, the test executor sends real HTTP requests to the system under test in the order of the generated test payloads. Each call carries a complete request header (such as authentication token, content type), request body, and path parameters. The system accurately records the complete response to each request, including:

[0145] HTTP status codes (such as 200, 403, 500);

[0146] Response header information (such as Set-Cookie, Content-Length, and custom security headers);

[0147] Response body content (such as business data in JSON format, error description, stack trace);

[0148] Request and response timestamps are used for performance and timeout analysis.

[0149] The captured response data is sent to the analysis module for semantic interpretation in conjunction with the context corpus. The analysis process includes:

[0150] Abnormal status identification: Detect unexpected successful responses (such as a low-privilege user performing a high-privilege operation and returning a 200 error), server errors (5xx), and security configuration defects (such as exposing internal IP or version information);

[0151] Business logic verification: Determine whether the operation result conforms to the business rules. For example, "a report in draft status was successfully archived" is a logic violation.

[0152] Sensitive information leakage detection: Identify whether the response contains data that should not be exposed, such as passwords, keys, and user privacy information;

[0153] Status consistency verification: Confirm whether the system status evolves as expected, for example, whether the status field of the report is updated to "submitted" after submission.

[0154] The analysis results are not only used to report vulnerabilities, but also serve as "learning signals" to drive subsequent testing. The system dynamically optimizes the test path based on feedback.

[0155] If a request fails due to "401 Unauthorized", the system infers that additional authentication information is required and automatically injects a valid token in subsequent calls;

[0156] If a "400 Bad Request" error message indicates a missing parameter, the system will look up the parameter definition in the context document and complete it.

[0157] If the system detects a successful privilege escalation, it will expand the testing scope and attempt to reproduce the behavior on other similar interfaces.

[0158] If a certain path is consistently blocked, the system reduces the fuzziness intensity or switches the attack vector to explore alternative paths.

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

[0160] Starting with the initial test objective, the system continuously generates new loads, executes, analyzes, and optimizes, entering multiple iterations. Each iteration adjusts the test focus based on the previous results, gradually delving into the deeper logic of the system. When a preset termination condition is met, the iteration stops, and the system enters the results output stage.

[0161] The final generated structured report includes:

[0162] List of discovered vulnerabilities and their risk levels (high / medium / low);

[0163] Reproduction steps for each vulnerability (complete API call sequence);

[0164] Response data screenshots or text snippets;

[0165] Vulnerability cause analysis and remediation recommendations;

[0166] Test coverage statistics and execution trajectory logs.

[0167] For example, let's take an e-commerce platform order management system as an example to illustrate the specific implementation process of this step:

[0168] Perform test load:

[0169] The system executes a test payload: using the identity of ordinary user A, skipping the "payment" status, directly calling the "confirm receipt" interface (POST / orders / 789 / confirm-receipt).

[0170] Capture response data:

[0171] The system received a response:

[0172] Status code: 200 OK;

[0173] Response body: {"orderId": "789", "status": "completed", "message": "Orderconfirmed successfully"};

[0174] Response header: No security warnings, returned complete user address information.

[0175] Analyze the response and identify vulnerabilities:

[0176] Status code 200 indicates that the operation was successful, but the business rules stipulate that "confirm receipt" must be executed in the "paid" state. The current order is still "pending payment", which constitutes a status verification loophole.

[0177] The response body exposed the recipient's name, phone number, and detailed address, which constitutes an excessive return of sensitive information;

[0178] The system determined that the request triggered two separate security issues: a logical vulnerability and information leakage.

[0179] Dynamically adjust testing strategies:

[0180] To address the status verification vulnerability, the system generates a new test objective: "Attempt to 'confirm receipt' on orders with a 'cancelled' status."

[0181] To address the information leakage issue, the system has modified the fuzzy strategy for all subsequent read interfaces and added scanning of privacy fields in the response body;

[0182] The system also attempted to execute a "refund request" operation on the same order to verify whether there was a chain reaction of permission defects.

[0183] Iterative execution and report output:

[0184] After multiple iterations, the system identified three state skipping vulnerabilities and two information leakage points. A final report was generated, detailing the request / response pairs, risk descriptions, and remediation suggestions for each vulnerability (such as adding pre-state validation and anonymizing response data), along with complete test execution logs.

[0185] It should be noted that, in specific implementation scenarios, multiple test loads can be executed concurrently based on the above solutions to simulate system stability and access control consistency under high load scenarios; traffic proxies or gateways can be integrated to inject test requests without modifying the system under test, which is suitable for production isolation environments; delayed execution and scheduled tasks are supported for testing time-sensitive logic (such as scheduled activation and automatic closure upon expiration).

[0186] In specific implementation scenarios, pattern recognition technology can be introduced on the basis of the above solutions to automatically cluster similar responses and identify potential batch vulnerabilities (such as multiple interfaces having unauthorized access); support the processing of encrypted response bodies: if the system provides a decryption key or interface, content analysis can be performed after decryption; potential denial-of-service (DoS) risk points can be identified by combining performance indicators (such as response time and resource consumption).

[0187] In specific implementation scenarios, based on the above solutions, a "vulnerability pattern memory" can be established to use historically successfully triggered test paths as templates for rapid detection of new systems; it supports reinforcement learning-based strategy optimization: the system automatically adjusts the fuzzing strength, call frequency, and state transition strategy according to the vulnerability discovery efficiency; a priority scheduling mechanism can be set to prioritize the in-depth exploration of high-risk modules or high-reward paths.

[0188] In specific implementation scenarios, the termination conditions can be dynamically configured based on the above solutions, such as "no new vulnerabilities found for N consecutive rounds", "critical path coverage reaches the threshold", and "preset time budget is reached". It supports phased iteration: the first phase explores all interfaces with breadth priority, and the second phase explores high-risk paths with depth priority. It can be integrated with CI / CD systems to achieve daily automatic iteration and continuous monitoring of system security changes.

[0189] In specific implementation scenarios, based on the above solutions, reports can be generated in multiple formats: PDF documents, HTML visualization pages, and JSON data interfaces, facilitating integration into security management platforms; high-risk vulnerabilities can be automatically pushed to work order systems (such as Jira), creating remediation tasks and tracking closure; and compliance comparison tables can be generated, such as mapping to standard clauses like OWASPAPI Security Top 10 and ISO 27001.

[0190] In specific implementation scenarios, in addition to the above solutions, a "security sandbox" mode can be enabled during execution to ensure that testing activities do not cause irreversible damage to real data; all execution operations are recorded in audit logs, including operation time, executor (system identifier), and request content, to meet compliance audit requirements; and key data states are automatically backed up before and after testing to facilitate problem reproduction and recovery.

[0191] According to one embodiment of this application, the step of loading context data includes:

[0192] The structured data parsing module extracts endpoint information, request methods, and parameter specifications from the API interface definition document.

[0193] The natural language processing module parses business rules in unstructured data to generate parameter dependency tables and state transition rules.

[0194] The parsed data is integrated into a contextual corpus and loaded into a large language model for subsequent use.

[0195] As mentioned above, firstly, the API interface definition document is parsed using a structured data parsing module. This document can be a standard format file such as OpenAPI, Swagger, Postman collections, or HAR files. The parsing module extracts endpoint information for each API, including the request path, supported request methods (such as GET, POST, PUT, DELETE, etc.), and the name, type, required status, data format, and example values ​​of each request parameter. Simultaneously, the response structure is also extracted, including the return status code and the data model of the response body. This information is used to clarify the basic API calling method and data structure, forming the foundational knowledge for system interaction.

[0196] Secondly, the unstructured data is processed through a natural language processing (NLP) module. Unstructured data includes textual documents written in natural language, such as business rule documents, user manuals, system design specifications, and requirement documents. The NLP module performs semantic analysis on these texts, identifying the described business processes, access control strategies, state transition logic, and operational constraints. For example, it identifies rules from documents such as "reports cannot be modified after submission," "approvers cannot approve reports submitted by themselves," and "users must log in before creating resources." Based on these rules, the system generates a parameter dependency table to record the input-output relationships between different API calls. For instance, the resource ID returned by a creation interface must be used as an input parameter for subsequent query or update interfaces. Simultaneously, it generates state transition rules, describing the state change paths of resources under different operations and their validity judgment conditions.

[0197] Finally, the information extracted from both structured and unstructured data is integrated and organized into a unified contextual corpus. This corpus contains the syntactic structure information of the API and business semantic rules, forming a comprehensive and consistent knowledge set. The corpus is organized in a format readable and understandable by the large language model and loaded into it, serving as the knowledge foundation for subsequent test plan generation, call sequence construction, and response result analysis. This ensures that the testing process conforms to both interface specifications and actual business logic.

[0198] According to one embodiment of this application, the step of generating a test plan includes:

[0199] The natural language test objectives input by the user are broken down into multiple sub-objectives, each corresponding to a specific business scenario of the system under test;

[0200] Based on the aforementioned context corpus, determine the API call path and required parameters for each sub-target;

[0201] The feasibility of the API call path was verified by leveraging the semantic understanding capabilities of a large language model, and missing preconditions were supplemented.

[0202] As mentioned above, the user-input natural language test objective is first broken down. This test objective is a high-level security or functional verification intent expressed in natural language, such as "testing whether a regular user can approve a report they submit" or "verifying the existence of unauthorized data export functionality." The system uses a large language model to perform semantic analysis on this objective, decomposing it into multiple logically independent and executable sub-objectives. Each sub-objective corresponds to a specific business scenario in the system under test, such as "login as a low-privilege user," "create a new report," or "attempt to call the approval interface to act on a report created by itself." This decomposition transforms the abstract test intent into a series of actionable technical actions.

[0203] Secondly, based on the context corpus built in the previous steps, the corresponding API call path and required parameters are determined for each sub-target. The context corpus contains information such as API interface definitions, parameter dependencies, and business rules. By querying this corpus, the system identifies the specific API endpoints, request methods, request headers, request body structures, and paths or query parameters required to implement each sub-target. Simultaneously, it determines the dependencies between calls, such as whether the resource identifier or authentication token returned by the previous operation is used as input for subsequent requests. This process ensures that each sub-target can be mapped to an actual combination of interfaces, forming an ordered call chain.

[0204] Finally, the semantic understanding capabilities of the large language model are used to verify the feasibility of the determined API call paths. 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 any missing preconditions. For example, in the sub-goal "Execute Approval," 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, thus determining that the path lacks necessary preconditions. The system automatically supplements the corresponding precondition calls, such as adding a call to the "Submit Report" interface, and ensures that its parameters are passed correctly. Through this verification and supplementation process, the generated test plan is not only logically complete but also conforms to the actual operational constraints of the system, laying the foundation for the subsequent generation of executable test sequences.

[0205] According to one embodiment of this application, the step of generating the API call sequence includes:

[0206] Based on the logical order in the test plan, determine the timing relationship of API calls and mark the dependency status of each API call;

[0207] Dynamically populate API request details using a large language model, including request method, URL path, request headers, and request body;

[0208] Embed state-aware logic in the request body to ensure that subsequent API calls are executed only when the preceding state conditions are met.

[0209] As mentioned above, firstly, based on the logical sequence defined in the test plan, the temporal relationship between each API call is clarified. The execution flow of the sub-targets is defined in the test plan, and the system arranges the order of API calls accordingly to ensure that the operations conform to the time sequence of the business process. Simultaneously, each API call is labeled with its dependent state conditions, such as "the report must be in the 'submitted' state before calling the approval interface" or "the user must have administrator privileges when performing a deletion operation." These state labels are used to guide the construction and execution control of subsequent requests, ensuring that the call sequence reflects the state transition requirements of the real system.

[0210] Secondly, a large language model is used to dynamically populate the specific request content for each API call. The model, combined with the interface definition information in the context corpus, determines the request method (e.g., GET, POST), the complete URL path (including the specific resource ID or parameter values), and necessary request headers (e.g., authentication token, content type). For the request body, the model generates JSON or form data that conforms to the format requirements based on the data structure defined in the interface, and fills in the corresponding field values. Dynamic parameters (such as the resource ID returned by previous calls and session tokens) are correctly referenced and inserted into their corresponding positions, ensuring the integrity and validity of the request.

[0211] Finally, state-aware logic is embedded during the request body construction process. This logic is not a simple static configuration, but rather reflects state judgment conditions in the request based on business rules. For example, when generating an "Approve Report" request, the system checks whether the preceding operation has updated the report status to "Submitted." If not, this state checkpoint is retained in the test sequence for subsequent verification of whether the system allows operations to be executed even when the state conditions are not met. This state-aware mechanism allows the generated call sequence to simulate both legitimate processes and construct state violation paths, thus supporting comprehensive testing of the state verification mechanism. The final API call sequence is an ordered, complete, and executable test script with state context information.

[0212] According to one embodiment of this application, the steps of the intelligent fuzzification process include:

[0213] Based on the business rules of the system under test, generate the abnormal types of parameter values, including type anomalies, format malformations, logical conflicts, and classic attack payloads;

[0214] Inject the generated abnormal parameter values ​​into the API request, and retain placeholders for valid parameter values ​​to support subsequent calls;

[0215] By leveraging the contextual understanding capabilities of large language models, we can ensure that abnormal data matches the business scenario of the system under test.

[0216] As mentioned above, firstly, based on the business rules and interface definitions of the system under test, abnormal data types applicable to each parameter are generated. The system combines parameter specifications extracted from the context corpus with business logic to generate four types of abnormal values ​​for different fields: type anomalies, such as entering a string in a field requiring integers; format malformations, such as providing text that does not conform to standard format in an email field, or constructing nested syntax errors in a JSON structure; logical conflicts, such as attempting to call an interface only allowed to "administrators" when the user role is "ordinary employee," or performing a "confirm receipt" operation when the order status is "pending payment"; and classic attack payloads, such as injecting SQL statement fragments, cross-site scripting code, or command execution strings, used to detect common security vulnerabilities. The selection of these anomaly types is based on the semantic roles of the parameters and potential weaknesses in the system.

[0217] Secondly, the generated abnormal parameter values ​​are injected into the corresponding locations in the API request, including path parameters, query parameters, request headers, and request body. During the injection process, the system retains other unobfuscated parameters as valid values ​​and maintains their original structure and format. Especially for parameters with dependencies, such as resource IDs and session tokens, valid values ​​obtained from preceding responses are still used as placeholders to ensure the overall request structure is valid, allowing it to pass basic validation and enter the business logic processing stage. This hybrid mode of partially abnormal and partially valid parameters increases the possibility of test loads penetrating the front-end validation mechanism, helping to uncover deep-seated logical defects.

[0218] Finally, leveraging the contextual understanding capabilities of the large language model, the generated abnormal data is filtered and adapted to ensure it matches the specific business scenario of the system under test. Based on the loaded contextual corpus, the model determines whether a particular anomaly reasonably exists in the current interface's usage environment. For example, in financial interfaces, anomalies involving negative or extremely large amounts are prioritized, while in user management interfaces, the focus is on test loads related to privilege escalation. Simultaneously, the model avoids generating obviously invalid or immediately blocked extreme inputs (such as completely garbled characters), instead selecting data that is syntactically close to legal but semantically violates rules, thereby improving the effectiveness and relevance of the tests. Through this process, intelligent and contextualized construction of abnormal data is achieved, enhancing the ability to detect vulnerabilities in business logic.

[0219] According to one embodiment of this application, the step of analyzing the response data includes:

[0220] Parse the HTTP status codes, response headers, and response body in the response data to identify abnormal status codes or error messages;

[0221] The validity of the response data is verified based on business rules, such as whether the report ID comes from the response of the previous call;

[0222] By leveraging the semantic analysis capabilities of large language models, it can be determined whether there are unauthorized operations, state skipping, or logical vulnerabilities.

[0223] As described above, the system first parses the response data captured after executing the test load. The system extracts the HTTP status code, response headers, and response body from the response. For the status code, it identifies any anomalies, such as server errors (5xx status codes) or client request errors (unexpected rejection scenarios in 4xx status codes, such as 403 Insufficient Privilege or 400 Incorrect Parameter). For the response header, it checks for anomalies in key fields, such as missing security policy headers, exposed internal service information, or incorrectly set session tokens. For the response body, it parses its data structure (e.g., JSON or XML format) to extract the returned business data, message descriptions, or error details, providing a basis for subsequent judgments.

[0224] Secondly, based on the business rules defined in the context corpus, the system verifies the legality of the response data. The system checks whether the key parameters returned in the response conform to business logic and process constraints. For example, whether the reportId returned after the "Create Report" operation is correctly referenced and processed in subsequent "Query" or "Submit" requests; in the approval process, whether the current operation occurs after the correct status, such as whether the "Approval" operation only returns success when the report status is "Submitted". Simultaneously, the system verifies whether the response data contains information that should not be present, such as returning data from other users during unauthorized access, or leaking sensitive content such as the system stack or database structure in failed responses.

[0225] Finally, the semantic analysis capabilities of the large language model are leveraged to perform in-depth analysis of the overall response behavior. The model combines the test objective, expected behavior, and actual response to identify potential security risks or logical flaws. For example, if a low-privilege user calls a high-privilege interface and receives a 200 success response, it is identified as an unauthorized operation vulnerability; if the "submit" status is skipped and the "archive" status is executed directly with a successful response, it is identified as a status skipping vulnerability; if the response result clearly contradicts business rules, such as the status remaining "approved" after approval is rejected, it is identified as a logical processing error. By understanding the semantic relationships between operational intent, contextual status, and system feedback, the large language model can uncover complex logical vulnerabilities that are difficult to capture with traditional rule matching, improving the accuracy and comprehensiveness of the analysis.

[0226] According to one embodiment of this application, the step of dynamically adjusting the testing strategy includes:

[0227] Based on the analysis results, a feedback signal is generated, which includes the vulnerability type, the reason for failure, and remediation suggestions.

[0228] Based on the feedback signal, adjust the calling order, parameter values, or state awareness logic of subsequent test plans;

[0229] During the iteration process, high-risk scenarios are prioritized for coverage, and the execution trajectory of all test steps is recorded.

[0230] As mentioned above, firstly, feedback signals are generated based on the analysis results of the response data. These feedback signals summarize and judge the current test execution status, containing three core elements: first, the identified vulnerability type, such as unauthorized access, state skipping, missing parameter validation, or sensitive information leakage; second, the specific reasons for test failure, such as requests being rejected due to missing authentication information, incorrect parameter formats, or violations of business state rules; and third, remediation suggestions generated based on a large language model understanding, such as supplementing permission validation logic, adding pre-state checks, and anonymizing response data. These feedback signals serve as the basis for subsequent test optimization, forming a closed loop from execution to understanding.

[0231] Secondly, the system adjusts subsequent test plans based on the generated feedback signals. It dynamically modifies the call order in the test paths according to the feedback content. For example, after discovering that an interface requires a prior login operation, the "login" call is inserted at the beginning of the subsequent test sequence. Parameter values ​​are adjusted, such as replacing previously invalid parameters with malicious outliers that meet the format requirements, or applying similar test loads to similar interfaces with discovered vulnerabilities in batches. State awareness logic is updated; for example, after confirming a validation vulnerability in a state transition, the test scope is expanded to attempt to reproduce similar behavior in other state paths. This adjustment makes the testing process adaptive, enabling continuous and in-depth exploration of the system's exposed weaknesses.

[0232] Finally, throughout the iterative testing process, the system prioritizes coverage of high-risk scenarios. High-risk scenarios include similar interfaces with known vulnerabilities, operations involving core business functions (such as payment, approval, and data export), and processes with frequent permission changes and status transitions. The system dynamically prioritizes test tasks based on vulnerability severity and business impact, ensuring critical issues are exposed as early as possible. Simultaneously, the execution trajectory of all test steps is fully recorded, including the test objectives for each round, the generated call sequence, the actual requests sent, the received responses, analysis conclusions, and strategy adjustment decisions. This execution trajectory is not only used to generate the final report but also supports the traceability of the testing process and the verifiability of the results.

[0233] According to one embodiment of this application, the termination condition includes at least one of the following:

[0234] Discover critical vulnerabilities and reach the preset vulnerability threshold;

[0235] Complete the verification of all predefined test objectives;

[0236] The maximum number of iterations or execution time has been exceeded.

[0237] As mentioned above, the first scenario involves discovering critical vulnerabilities and reaching a preset vulnerability threshold. During testing, the system continuously identifies and categorizes discovered vulnerabilities, assessing them based on their type, severity, and impact. When a critical vulnerability belonging to a high-risk category (such as unauthorized access, identity bypass, sensitive data leakage, or disruption of core business logic) is detected and its cumulative number reaches a preset threshold, the testing process automatically terminates. This threshold is configured by the user or system policy to ensure that testing ends promptly after discovering a sufficient number of significant issues, avoiding resource waste and quickly transitioning to the issue response phase.

[0238] The second scenario involves verifying all predefined test objectives. The set of test objectives set at the start of the test task includes a series of business scenarios, security checks, or functional 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 pass or fail) 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 test coverage and is suitable for goal-oriented test tasks.

[0239] The third scenario involves exceeding the preset maximum number of iterations or execution time. To prevent the testing process from looping infinitely or consuming excessive resources, the system has a maximum limit on the number of iterations and a maximum execution time. The maximum number of iterations refers to the upper limit on the number of rounds for adjusting and re-executing the test strategy; the maximum execution time refers to the total duration limit from test start to termination. When the actual number of iterations reaches the set limit, or the test has run to the predetermined deadline, the system stops further execution regardless of whether a vulnerability has been found or all objectives have been achieved. This condition ensures the controllability of the testing process and the rationality of resource usage, and is suitable for scenarios such as automated pipelines or scheduled inspections.

[0240] When any of the above conditions are met, the system determines that the test task has reached the termination state, stops generating new test loads, and enters the result summary and report output stage.

[0241] A second aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in any of the embodiments of the first aspect above.

[0242] Figure 2 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 2As shown, the electronic device may 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 communicate with each other via the communication bus 840. The processor 810 may call logical instructions in the memory 830 to execute the method in any of the embodiments of the first aspect described above, the method including:

[0243] Load the 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. The unstructured data includes at least business rule documents and user manuals.

[0244] Based on the natural language testing objectives input by the user, a test plan is generated for the system under test. The test plan includes the logical order of API calls, parameter dependencies, and expected state changes.

[0245] Based on the test plan and the context data, an API call sequence with state awareness is generated. The state awareness is used to ensure that the API calls comply with the business rules of the system under test. The request parameters in the API call sequence are intelligently obfuscated to generate a test load containing abnormal data.

[0246] The API calls corresponding to the test payload are executed, the response data of the system under test is captured, the response data is analyzed, potential vulnerabilities or system anomalies are identified, and the subsequent test strategies are dynamically adjusted based on the analysis results to form a closed-loop feedback. The above steps are executed iteratively until the preset termination conditions are met, and a test result report is output.

[0247] Furthermore, the logical instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0248] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer is able to perform the methods provided by the above-described methods, which include:

[0249] Load the 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. The unstructured data includes at least business rule documents and user manuals.

[0250] Based on the natural language testing objectives input by the user, a test plan is generated for the system under test. The test plan includes the logical order of API calls, parameter dependencies, and expected state changes.

[0251] Based on the test plan and the context data, an API call sequence with state awareness is generated. The state awareness is used to ensure that the API calls comply with the business rules of the system under test. The request parameters in the API call sequence are intelligently obfuscated to generate a test load containing abnormal data.

[0252] The API calls corresponding to the test payload are executed, the response data of the system under test is captured, the response data is analyzed, potential vulnerabilities or system anomalies are identified, and the subsequent test strategies are dynamically adjusted based on the analysis results to form a closed-loop feedback. The above steps are executed iteratively until the preset termination conditions are met, and a test result report is output.

[0253] In another aspect, this application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the cigarette box image recognition method provided by the methods described above, the method comprising:

[0254] Load the 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. The unstructured data includes at least business rule documents and user manuals.

[0255] Based on the natural language testing objectives input by the user, a test plan is generated for the system under test. The test plan includes the logical order of API calls, parameter dependencies, and expected state changes.

[0256] Based on the test plan and the context data, an API call sequence with state awareness is generated. The state awareness is used to ensure that the API calls comply with the business rules of the system under test. The request parameters in the API call sequence are intelligently obfuscated to generate a test load containing abnormal data.

[0257] The API calls corresponding to the test payload are executed, the response data of the system under test is captured, the response data is analyzed, potential vulnerabilities or system anomalies are identified, and the subsequent test strategies are dynamically adjusted based on the analysis results to form a closed-loop feedback. The above steps are executed iteratively until the preset termination conditions are met, and a test result report is output.

[0258] Example 2

[0259] like Figure 3 The diagram illustrates the overall architecture of the API fuzzing system proposed in this application. The system mainly consists of the following modules:

[0260] Target System: This is the application that needs to be security tested, such as the "Inspur Reporting Platform". This system provides services to the outside world through a set of APIs.

[0261] Context Ingestion Module: This module is responsible for collecting and preprocessing all background information related to the system under test, providing a basis for decision-making in the large language model. Its input sources include:

[0262] 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 structures.

[0263] Unstructured data: such as plain text user manuals, developer documents, business requirements documents, and even comments in the source code. These documents describe the business logic, use cases, and design intent of the API.

[0264] All of this data is integrated and processed to form a "Context Corpus," which serves as the core knowledge foundation of LLM.

[0265] The LLM Core: The brain of the system, typically a pre-trained large language model, such as a Transformer-based model (like the GPT-4 series). It receives corpora from the context ingestion module and high-level instructions from external sources, and is responsible for semantic understanding, logical reasoning, and content generation.

[0266] Test Sequence Generation Engine: This engine works closely with the LLM core. It receives a high-level test objective described in natural language (e.g., "a privilege circumvention vulnerability in a test report approval process") and generates a specific, ordered sequence of API requests by issuing a series of carefully crafted prompts to the LLM core. This process involves generating a complete HTTP request for each step in the sequence, including the request method, URL, headers, and intelligent request bodies (payloads).

[0267] Test Executor: This module receives the test sequence created by the generation engine and initiates real API calls to the target system under test in the specified order. It handles network communication and accurately captures the complete response of each call, including HTTP status codes, response headers, and response bodies.

[0268] Response Analysis & Feedback Module: This is a key innovative component that distinguishes this application from existing technologies. It feeds back the raw API responses obtained from the test executor to the LLM core for analysis. The LLM core leverages its powerful interpretation capabilities to analyze the responses to achieve the following objectives:

[0269] Fault Identification: Detects server crashes (5xx series errors), security misconfigurations (such as detailed error stacks that leak sensitive information), or unexpected successful operations (for example, receiving a "200 OK" in an unauthorized operation that was expected to return a "403 Forbidden").

[0270] State Update: Maintaining an understanding of the application's current state. For example, after successful login, the module records the session token and informs the LLM that this token will be needed in subsequent requests.

[0271] Strategy Refinement: Learning from failures. If a request fails due to a missing required parameter, the LLM can infer what that parameter might be and how to obtain it based on information from the context corpus, and generate a new request for retry. This process forms an adaptive, closed-loop testing flow.

[0272] Methods and Processes

[0273] The following illustrates the specific implementation steps of the method described in this application:

[0274] Step 1: Context Loading

[0275] The process begins with the context ingestion module loading a corpus of contextual information about the system under test into the LLM core. This step provides the LLM with in-depth knowledge of the expected functionality and business rules of the system under test.

[0276] Step 2: Goal Definition

[0277] Testers (or automated systems) provide a high-level test objective described in natural language. For example, "Test whether the user profile modification function has an unauthorized access vulnerability," or choose from a set of predefined general security test objectives (such as testing SQL injection, testing invalid access control, etc.).

[0278] Step 3: Test Plan Generation

[0279] The test sequence generation engine prompts the LLM core to break down high-level test objectives into a logically clear test plan. For the objective "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. Locate the endpoint and request format for approving the report from the API documentation; 4. Attempt to call the approval endpoint using user A's authentication token, applying it to the newly created report.

[0280] Step 4: Stateful Sequence Construction

[0281] The LLM core translates the aforementioned test plan into a concrete, executable sequence of API calls. It leverages its contextual knowledge to populate specific parameters in the request. For example, it knows from the documentation that the API for creating a report returns a `reportId`, and that subsequent approval operations require this `reportId` as a path parameter or part of the request body. This demonstrates its ability to perceive and handle state.

[0282] Step 5: Intelligent Payload Fuzzing

[0283] Based on the constructed API call sequence, LLM injects obfuscated data. This injection is not random, but intelligent and targeted:

[0284] Type awareness: Inserting a string into a field that is expected to contain integers.

[0285] Format awareness: Provides a poorly structured object in the body of a JSON request.

[0286] Security awareness: Injecting classic attack payloads that target specific vulnerability types, such as SQL injection's 'OR '1'='1'.

[0287] Logical awareness: This is what makes this application unique. For example, entering a negative number in a field representing a monetary amount; or deliberately attempting to approve a report in a "draft" state when the business logic dictates that the report status must be "submitted" for approval.

[0288] Step 6: Execution and Monitoring

[0289] The test executor sends the generated sequence of API requests containing obfuscated payloads to the target system under test one by one, and records the response to each request in its entirety.

[0290] Step 7: Response Analysis and Learning

[0291] The response analysis and feedback module passes the captured responses to the LLM core. The LLM interprets the results. If a vulnerability is discovered (e.g., a low-privilege user successfully approved a report), the vulnerability and its reproduction steps are logged in detail. If an obstacle is encountered (e.g., the server returns a "400 Bad Request" indicating a missing field), the LLM understands the error message.

[0292] Step 8: Iteration and Refinement

[0293] Based on the analysis results from step 7, LLM generates an optimized new test sequence, and the process returns to step 4 to continue execution. For example, if the previous step failed due to missing fields, the new sequence will attempt to include the required fields inferred by LLM. This iterative, self-correcting closed loop is key to achieving efficient intelligent testing in this application. This feedback loop is not a simple repetition, but an "AI-driven cognitive loop" that transforms the fuzzing tool from a "brute-force tool" that only executes preset instructions into an "intelligent agent" capable of autonomously learning and solving problems, thereby overcoming the fragility and low adaptability problems commonly found in existing technologies.

[0294] For any parts not mentioned in this application, existing technologies may be used or referenced.

[0295] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0296] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A context-aware API intelligent testing method, characterized in that, include: Load the 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. The unstructured data includes at least business rule documents and user manuals. Based on the natural language testing objectives input by the user, and combined with the loaded context data, the large language model performs semantic parsing and task decomposition to generate a test plan for the system under test. The test plan includes the logical order 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 through the large language model. The state awareness is used to ensure that the API calls comply with the business rules of the system under test. The request parameters in the API call sequence are intelligently obfuscated to generate a test load containing abnormal data. The API calls corresponding to the test payload are executed, the response data of the system under test is captured, the response data is analyzed, potential vulnerabilities or system anomalies are identified, and the subsequent test strategies are dynamically adjusted based on the analysis results to form a closed-loop feedback. The above steps are executed iteratively until the preset termination conditions are met, and a test result report is output.

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

3. The method according to claim 1, characterized in that, The generation of a test plan for the system under test includes: The natural language test objectives input by the user are broken down into multiple sub-objectives, each corresponding to a specific business scenario of the system under test; Based on the context corpus, determine the API call path and required parameters for each sub-target; The feasibility of the API call path was verified by leveraging the semantic understanding capabilities of a large language model, and missing preconditions were supplemented.

4. The method according to claim 1, characterized in that, The execution of the API call corresponding to the test payload includes: Based on the logical order in the test plan, determine the timing relationship of API calls and mark the dependency status of each API call; Dynamically populate API request details using a large language model, including request method, URL path, request headers, and request body; Embed state-aware logic in the request body to ensure that subsequent API calls are executed only when the preceding state conditions are met.

5. The method according to claim 4, characterized in that, The steps of the intelligent fuzzification process include: Based on the business rules of the system under test, generate the abnormal types of parameter values, including type anomalies, format malformations, logical conflicts, and classic attack payloads; Inject the generated abnormal parameter values ​​into the API request, and retain placeholders for valid parameter values ​​to support subsequent calls; By leveraging the contextual understanding capabilities of large language models, we can ensure that abnormal data matches the business scenario of the system under test.

6. The method according to claim 1, characterized in that, The analysis of the response data includes: Parse the HTTP status codes, response headers, and response body in the response data to identify abnormal status codes or error messages; Verify the legality of response data based on business rules; By leveraging the semantic analysis capabilities of large language models, it can be determined whether there are unauthorized operations, state skipping, or logical vulnerabilities.

7. The method according to claim 1, characterized in that, The dynamic adjustment of subsequent testing strategies based on analysis results includes: Based on the analysis results, a feedback signal is generated, which includes the vulnerability type, the reason for failure, and remediation suggestions. Based on the feedback signal, adjust the calling order, parameter values, or state awareness logic of subsequent test plans; During the iteration process, high-risk scenarios are prioritized for coverage, and the execution trajectory of all test steps is 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 the verification of all predefined test objectives; The maximum number of iterations or execution time has been exceeded.

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

10. An electronic device comprising a memory, a processor, and a program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method as described in any one of claims 1-8.

Images