Method and system for realizing hosted API automatic test by API gateway

Abstract

The invention discloses a method and a system for realizing hosted API automatic testing by an API gateway, belongs to the technical field of computer software, and aims at solving the technical problems of how to realize non-intrusive and automatic API testing, ensuring that monitoring and verification can be directly carried out on an API flow level, improving the testing efficiency and the coverage rate and improving the testing efficiency. According to the technical scheme, the method comprises the steps of test case generation, wherein an interface structure is automatically analyzed based on an API document, and a basic test case set is generated; flow capturing: monitoring the actual calling condition of the API in real time, and recording the specific content of each request and the corresponding response data; carrying out flow playback: carrying out playback test based on the captured historical flow, and verifying the compatibility of the API; assertion verification: assertion judgment is performed on indexes of the return value and the response time through an assertion mechanism, and abnormity is found; and test report generation: aggregating test result data, generating a test report containing success rate, response time and error log detailed information, and supporting HTML / PDF / JSON export.

Description

Technical Field

[0001] The present invention relates to the field of computer software technology, and in particular to a method and system for implementing automated testing of a managed API via an API gateway. Background Art

[0002] With the prevalence of cloud computing and microservices architecture, APIs have become the core of communication between system components. However, frequent API updates, version iterations, and multi-service interactions lead to high testing costs, and traditional manual testing methods are no longer able to meet the needs of modern software development.

[0003] Most current API testing tools rely on external agents or independent testing frameworks, which have the following problems:

[0004] ① Strong environmental dependence: Testing tools usually require additional proxy server or client configuration.

[0005] ② Limited test coverage: Unable to fully capture all API call scenarios, especially exception flow processing.

[0006] ③High test maintenance costs: After each API update, test cases need to be manually maintained, which increases labor costs.

[0007] Therefore, how to implement non-invasive, automated API testing, ensure that monitoring and verification can be performed directly at the API traffic level, and improve testing efficiency and coverage is a technical problem that needs to be solved urgently. Summary of the Invention

[0008] The technical task of the present invention is to provide a method and system for implementing managed API automated testing through an API gateway to solve the problem of how to implement non-invasive and automatic API testing, ensure that monitoring and verification can be performed directly at the API traffic level, and improve test efficiency and coverage.

[0009] The technical task of the present invention is achieved in the following manner: a method for implementing automated testing of a managed API using an API gateway, the method being as follows:

[0010] Test case generation: Automatically parse the interface structure based on the API document and generate a basic test case set;

[0011] Traffic capture: monitors actual API calls in real time, recording the specific content of each request and its corresponding response data; in particular, the specific content of each request and its corresponding response data HTTP header information, request and response bodies, as well as timestamps and status code metadata;

[0012] Traffic replay: Perform replay tests based on captured historical traffic to verify API compatibility. Simulating real user behavior patterns to reproduce past API call sequences can be used to verify whether newly deployed functions adversely affect existing business logic.

[0013] Assertion verification: Assertion mechanisms are used to assess return values ​​and response time metrics and identify anomalies. The assertion mechanism defines correctness rules for API return values, ensuring output consistency and accuracy. It also verifies the API's basic functionality and detects anomalies and edge cases.

[0014] Test report generation: Aggregate test result data to generate a test report containing success rate, response time, and error log details, and support HTML / PDF / JSON export.

[0015] As a preference, test case generation is as follows:

[0016] Parsing API definition documents: Parsing OpenAPI documents or Swagger definitions to extract API endpoints, request parameters, and return values. Specifically, for OpenAPI specifications, use open source libraries such as swagger-parser to parse YAML or JSON format files to obtain all API paths and operations contained therein.

[0017] Automatically generate basic test cases: Combined with historical API call data, it automatically generates positive test, negative test and boundary test cases, and supports users to add custom rules and boundary conditions. Specifically: the operation type of each API endpoint determines the test logic corresponding to the API endpoint; among them, the operation types of API endpoints include GET and POST; for a GET request, the test case includes checking whether the status code is 200 and whether the response body conforms to the expected model; for a POST request, it is necessary to construct a valid request body and verify whether the returned data is correct.

[0018] As a preference, traffic capture is as follows:

[0019] Integration gateway plug-in: deploy non-intrusive listeners at the API gateway layer to collect API call data in real time;

[0020] Storing request and response data: Store the captured request and response data in a persistent database. Specifically, use log storage or message queues (such as Kafka) or a time series database (such as InfluxDB) to store API requests, responses, and related metadata.

[0021] Data encryption and privacy protection: Use symmetric encryption algorithms (such as AES) to encrypt sensitive fields before storing them in the database.

[0022] As a preference, traffic playback is as follows:

[0023] Replay historical traffic: Extract historical traffic data from the database and replay it in the original order using multi-threaded or asynchronous programming techniques to build replay test scenarios;

[0024] Result comparison and analysis: Use simulated request technology to send historical requests to the API and compare the returned results. Combined with transaction consistency testing, ensure that the playback test is consistent with the actual API behavior. Alternatively, predefine a set of expected response rules and then compare the actual responses one by one to see if they meet expectations.

[0025] As an option, the assertion verification is as follows:

[0026] Define assertion rules: predefine the format, status code, and response time constraints of the API return data through configuration files or coding interfaces.

[0027] Execute assertions: During the test process, the assertion conditions are dynamically adjusted through the rule engine, and the test framework automatically performs verification according to the defined assertion rules to improve test accuracy.

[0028] Preferably, the test report is generated as follows:

[0029] Collect test results: Collect all test result data, including the success or failure of each test case, response time, and error logs;

[0030] Generate report template: use template engine to generate test report;

[0031] Export reports: Use WeasyPrint or ReportLab third-party libraries to convert HTML reports to PDF format, or use the Pandas library to export data to CSV files.

[0032] A system for implementing automated testing of a managed API using an API gateway, the system comprising:

[0033] The test case generation module is used to automatically generate test cases based on API definitions, parse standard format documents, and support custom rules to improve coverage;

[0034] Traffic capture module, used to monitor the actual API calls in real time, recording the specific content of each request and its corresponding response data; in particular, the specific content of each request and its corresponding response data HTTP header information, request and response body, as well as timestamp and status code metadata;

[0035] The traffic replay module is used to perform replay tests based on captured historical traffic to verify API compatibility. It also simulates real user behavior patterns to reproduce past API call sequences to verify whether newly deployed functions have adverse effects on existing business logic.

[0036] The assertion module is used to assert return values ​​and response time metrics and detect anomalies through the assertion mechanism. The assertion mechanism is used to define the correctness rules of API return values ​​to ensure the consistency and accuracy of the output. The assertion mechanism is also used to verify the basic functionality of the API and detect anomalies and edge cases.

[0037] The test report generation module is used to generate test reports containing success rate, response time, and error log details, and supports HTML / PDF / JSON export.

[0038] Preferably, the test case generation module includes:

[0039] The API definition document parsing submodule is used to parse OpenAPI documents or Swagger definitions to extract API endpoints, request parameters, and return values. Specifically, for OpenAPI specifications, it uses open source libraries such as swagger-parser to parse YAML or JSON format files to obtain all API paths and operations contained therein.

[0040] The basic test case automatic generation sub-module is used to automatically generate positive test, negative test and boundary test cases based on historical API call data, and supports users to add custom rules and boundary conditions; specifically: the operation type of each API endpoint determines the test logic corresponding to the API endpoint; among them, the operation types of API endpoints include GET and POST; for a GET request, the test case includes checking whether the status code is 200 and whether the response body conforms to the expected model; for a POST request, it is necessary to construct a valid request body and verify whether the returned data is correct.

[0041] Preferably, the traffic capture module includes:

[0042] The gateway plug-in integration submodule is used to deploy non-intrusive listeners at the API gateway layer to collect API call data in real time;

[0043] The request and response data storage submodule is used to store the captured request and response data in a persistent database. Specifically, it uses log storage or message queues (such as Kafka) or time series databases (such as InfluxDB) to store API requests, responses, and related metadata.

[0044] The data encryption and privacy protection submodule is used to encrypt sensitive fields using a symmetric encryption algorithm (such as AES) and then store them in the database;

[0045] The traffic replay module includes:

[0046] The historical traffic playback submodule is used to extract historical traffic data from the database and play it back in the original order through multi-threading or asynchronous programming technology to build playback test scenarios;

[0047] The result comparison and analysis submodule uses simulated request technology to send historical requests to the API and compare the returned results. It also combines transaction consistency detection to ensure that the playback test is consistent with the actual API behavior, or predefines a set of expected response rules and then compares the actual responses one by one to see if they meet expectations.

[0048] Preferably, the assertion verification module includes:

[0049] The assertion rule definition submodule is used to predefine the format, status code, and response time constraints of the API return data through configuration files or encoding interfaces.

[0050] The assertion execution submodule is used to dynamically adjust assertion conditions through the rule engine during the test process. The test framework automatically performs verification according to the defined assertion rules to improve test accuracy.

[0051] The test report generation module includes:

[0052] The test result collection submodule is used to collect the result data of all tests, including the success or failure of each test case, response time and error log;

[0053] Report template generation submodule, used to generate test reports using the template engine;

[0054] The report export submodule is used to convert HTML reports to PDF format using the WeasyPrint or ReportLab third-party libraries, or to export data to CSV files using the Pandas library.

[0055] The method and system for implementing managed API automated testing via an API gateway of the present invention have the following advantages:

[0056] (1) The present invention integrates an automated testing module at the API gateway layer to achieve real-time monitoring of API calls, dynamic traffic analysis, and automated test execution, thereby significantly reducing manual testing workload, increasing test coverage, and improving the efficiency and quality of API testing.

[0057] (2) This invention ensures the stability and security of API functions through key technologies such as test case generation, data flow capture, traffic playback, and assertion mechanisms. It is suitable for API management in microservice architecture and cloud computing environments, and provides effective support for API full life cycle testing;

[0058] (3) The present invention integrates a testing module at the API gateway layer to achieve automated monitoring, testing, and analysis of API call behavior, thereby reducing the workload of manual testing and improving the reliability and security of the API;

[0059] (IV) The present invention achieves comprehensive quality assurance through core components, specifically: first, the test case generation module automatically generates test cases according to the API definition, parses standard format documents and supports custom rules to improve coverage; second, the traffic capture module records the request and response data of API calls in real time, providing real data support for subsequent tests; then, the traffic playback module uses historical traffic to perform compatibility testing, simulating user behavior to verify the impact of new functions on existing logic; in addition, the assertion mechanism defines the rules for the correctness of API return values ​​to ensure the consistency and accuracy of the output; finally, a test report containing detailed information, such as success rate, response time, error log, etc., is generated, and supports export to multiple formats. The present invention integrates the functions of each module to achieve full-process automated testing from test case generation to anomaly detection, significantly improving the quality and reliability of the API;

[0060] (5) The present invention has the advantage of non-invasive testing, that is, automated testing can be performed without modifying the API code;

[0061] (6) The present invention has efficient coverage: based on actual traffic analysis, it improves test coverage;

[0062] (7) The present invention can automatically maintain: automatically generate and update test cases, reducing manual maintenance costs;

[0063] (VIII) The traffic replay of the present invention replays the test request based on the captured historical traffic data, and the assertion mechanism verifies the correctness of the API response according to predefined rules. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] The present invention will be further described below with reference to the accompanying drawings.

[0065] Attachment Figure 1 A diagram of a system that implements managed API automation testing for an API gateway. DETAILED DESCRIPTION

[0066] The method and system for implementing automated testing of hosted APIs using an API gateway of the present invention are described in detail below with reference to the accompanying drawings and specific embodiments.

[0067] Example 1:

[0068] This embodiment provides a method for implementing automated testing of managed APIs through an API gateway. The method is as follows:

[0069] S1. Test case generation: Automatically parse the interface structure based on the API document and generate a basic test case set;

[0070] S2. Traffic Capture: Monitors actual API calls in real time, recording the specific content of each request and its corresponding response data. This includes HTTP header information, request and response bodies, as well as timestamps and status code metadata.

[0071] S3, Traffic Replay: Perform replay testing based on captured historical traffic to verify API compatibility. Simulating real user behavior patterns to reproduce past API call sequences is used to verify whether newly deployed functions adversely affect existing business logic.

[0072] S4. Assertion Verification: Assertion verification is performed on return values ​​and response time indicators through the assertion mechanism to detect anomalies. The assertion mechanism is used to define the correctness rules of API return values ​​to ensure the consistency and accuracy of the output. The assertion mechanism is also used to verify the basic functionality of the API and detect anomalies and edge cases.

[0073] S5. Test report generation: Aggregate test result data to generate a test report containing success rate, response time, and error log details, and support HTML / PDF / JSON export.

[0074] The test case generation in step S1 of this embodiment is specifically as follows:

[0075] S101. Parse API definition documents: Parse OpenAPI documents or Swagger definitions to extract API endpoints, request parameters, and return values. Specifically, for OpenAPI specifications, use open source libraries such as swagger-parser to parse YAML or JSON format files to obtain all API paths and operations contained therein.

[0076] S102. Automatically generate basic test cases: Combine historical API call data to automatically generate positive test, negative test, and boundary test cases. Specifically, the operation type of each API endpoint determines the corresponding test logic of the API endpoint. The operation types of API endpoints include GET and POST. For a GET request, the test case includes checking whether the status code is 200 and whether the response body conforms to the expected model. For a POST request, it is necessary to construct a valid request body and verify whether the returned data is correct.

[0077] In addition to generating basic test cases, the test case generation module should also support users adding custom rules and boundary conditions. For example, in some scenarios, developers may want to test specific error conditions or verify the performance of an API when processing large amounts of data. To this end, flexible configuration options can be provided when generating test cases, allowing users to specify additional test conditions.

[0078] For example, custom rules can be passed via command line arguments or a configuration file:

[0079] custom_rules:

[0080] -endpoint:" / api / v1 / users"

[0081] method:"POST"

[0082] payload:{"name":"John","age":100}

[0083] expected_status:400.

[0084] The traffic capture in step S2 of this embodiment is specifically as follows:

[0085] S201, Integration Gateway Plug-in: Deploy non-intrusive listeners at the API gateway layer to collect API call data in real time;

[0086] To achieve traffic capture, you can integrate a dedicated plug-in into the API gateway. Most modern API gateways (such as Kong and NGINX Plus) support extended functionality through plug-ins. Taking Kong as an example, you can write a custom plug-in to capture information related to API calls. The key code is as follows:

[0087] local plugin_name="traffic-capture"

[0088] local_M={

[0089] PRIORITY=1000,

[0090] VERSION="0.1",

[0091] }

[0092] function_M:access(config)

[0093] --Record request information during the access phase

[0094] end

[0095] function_M:header_filter(config)

[0096] --Record response information in the response header stage

[0097] end

[0098] return_M;

[0099] In the access function, you can record the request URI, HTTP method, request header, and request body; in the header_filter function, you can record the response status code, response header, and response body.

[0100] S202. Store request and response data: Store the captured request and response data in a persistent database. Specifically, use log storage or a message queue (such as Kafka) or a time series database (such as InfluxDB) to store API requests, responses, and related metadata.

[0101] S203. Data encryption and privacy protection: Considering that API calls may contain sensitive information (such as user credentials and personal data), the traffic capture module also needs to have data encryption and privacy protection capabilities. Sensitive fields can be encrypted using a symmetric encryption algorithm (such as AES) before being stored in the database.

[0102] The traffic playback in step S3 of this embodiment is specifically as follows:

[0103] S301. Replay historical traffic: Extract historical traffic data from the database and replay it in the original order using multi-threaded or asynchronous programming technology to build a replay test scenario;

[0104] S302. Result comparison and analysis: Use simulated request technology to send historical requests to the API and compare the returned results. Combined with transaction consistency testing, ensure that the playback test is consistent with the actual API behavior. Alternatively, define a set of expected response rules in advance and then compare the actual responses one by one to see if they meet expectations.

[0105] The assertion verification in step S4 of this embodiment is specifically as follows:

[0106] S401. Define assertion rules: predefine the format, status code, and response time constraints of the API return data through a configuration file or coding interface.

[0107] For example, you can use the YAML format to define the following assertion rules:

[0108] assertions:

[0109] -endpoint:" / api / v1 / users"

[0110] method:"GET"

[0111] status_code:200

[0112] body_contains:"John Doe";

[0113] In the above configuration, a GET request to the / api / v1 / users endpoint is specified, with the expected return status code of 200 and the string "John Doe" in the response body.

[0114] S402. Execute assertions: During the test process, assertion conditions are dynamically adjusted through the rule engine, and the test framework automatically performs verification according to the defined assertion rules to improve test accuracy.

[0115] Here is an example of assertion execution implemented in Python:

[0116] def execute_assertion(response,assertion):

[0117] if response.status_code! =assertion['status_code']:

[0118] raise AssertionError(f"Expected status code{assertion['status_code']},but got{response.status_code}")

[0119] if assertion['body_contains']not in response.text:

[0120] raise AssertionError(f"Expected response to contain'{assertion['body_contains']}',but it did not");

[0121] Through the above code, you can flexibly define and execute various assertion rules to ensure the correctness of the API.

[0122] The test report generation in step S5 of this embodiment is specifically as follows:

[0123] S501. Collect test results: Collect all test result data, including the success or failure of each test case, response time, and error log. A unified data structure can be used to store this information:

[0124] {

[0125] "test_case_id":"TC-001",

[0126] "endpoint":" / api / v1 / users",

[0127] "method":"GET",

[0128] "success":true,

[0129] "response_time_ms":120,

[0130] "error_log":""

[0131] }.

[0132] S502. Generate a report template: Generate a test report using a template engine. The following is an example of using the Jinja2 template engine to generate an HTML report:

[0133] from jinja2 import Environment,FileSystemLoader

[0134] env=Environment(loader=FileSystemLoader('.'))

[0135] template=env.get_template('report-template.html')

[0136] def generate_report(test_results):

[0137] report_content=template.render(test_results=test_results)

[0138] with open('test-report.html','w')as f:

[0139] f.write(report_content);

[0140] In the above code, report-template.html defines the layout and style of the report, and the generate_report function fills the template content according to the test results.

[0141] S503. Export report: Use WeasyPrint or ReportLab third-party libraries to convert HTML reports to PDF format, or use the Pandas library to export data to a CSV file. The following is an example of converting an HTML report to PDF:

[0142] from weasyprint import HTML

[0143] def export_to_pdf(html_file,pdf_file):

[0144] HTML(filename=html_file).write_pdf(pdf_file);

[0145] Through the above steps, a detailed and easy-to-understand test report can be generated, providing strong support for subsequent API optimization.

[0146] Example 2:

[0147] As attached Figure 1 As shown, this embodiment provides a system for implementing managed API automated testing via an API gateway, the system comprising:

[0148] The test case generation module is used to automatically generate test cases based on API definitions, parse standard format documents, and support custom rules to improve coverage;

[0149] Traffic capture module, used to monitor the actual API calls in real time, recording the specific content of each request and its corresponding response data; in particular, the specific content of each request and its corresponding response data HTTP header information, request and response body, as well as timestamp and status code metadata;

[0150] The traffic replay module is used to perform replay tests based on captured historical traffic to verify API compatibility. It also simulates real user behavior patterns to reproduce past API call sequences to verify whether newly deployed functions have adverse effects on existing business logic.

[0151] The assertion module is used to assert return values ​​and response time metrics and detect anomalies through the assertion mechanism. The assertion mechanism is used to define the correctness rules of API return values ​​to ensure the consistency and accuracy of the output. The assertion mechanism is also used to verify the basic functionality of the API and detect anomalies and edge cases.

[0152] The test report generation module is used to generate test reports containing success rate, response time, and error log details, and supports HTML / PDF / JSON export.

[0153] The test case generation module in this embodiment is the foundation of the entire automated testing framework. Its main function is to automatically generate test cases based on API definitions. In modern software development, APIs are typically described in standard formats such as OpenAPI (formerly Swagger), RAML, or API Blueprint. These specifications provide detailed interface information, such as endpoint paths, HTTP methods, request parameters, and response models, providing a rich data source for automated testing.

[0154] The test case generation module in this embodiment includes:

[0155] The API definition document parsing submodule is used to parse OpenAPI documents or Swagger definitions to extract API endpoints, request parameters, and return values. Specifically, for OpenAPI specifications, it uses open source libraries such as swagger-parser to parse YAML or JSON format files to obtain all API paths and operations contained therein.

[0156] The basic test case automatic generation sub-module is used to automatically generate positive test, negative test and boundary test cases based on historical API call data, and supports users to add custom rules and boundary conditions; specifically: the operation type of each API endpoint determines the test logic corresponding to the API endpoint; among them, the operation types of API endpoints include GET and POST; for a GET request, the test case includes checking whether the status code is 200 and whether the response body conforms to the expected model; for a POST request, it is necessary to construct a valid request body and verify whether the returned data is correct.

[0157] The traffic capture module in this embodiment monitors actual API calls in real time, recording the specific content of each request and its corresponding response data. This includes not only HTTP headers, request and response bodies, but also metadata such as timestamps and status codes. These detailed interaction records provide valuable data support for subsequent regression testing.

[0158] The traffic capture module in this embodiment includes:

[0159] The gateway plug-in integration submodule is used to deploy non-intrusive listeners at the API gateway layer to collect API call data in real time;

[0160] The request and response data storage submodule is used to store the captured request and response data in a persistent database. Specifically, it uses log storage or message queues (such as Kafka) or time series databases (such as InfluxDB) to store API requests, responses, and related metadata.

[0161] The data encryption and privacy protection submodule is used to encrypt sensitive fields using a symmetric encryption algorithm (such as AES) and then store them in the database.

[0162] The traffic replay module in this embodiment performs playback testing based on captured historical traffic to verify API compatibility. By simulating real user behavior patterns, this module can reproduce past API call sequences, helping to verify whether newly deployed functions have adversely affected existing business logic.

[0163] The traffic playback module in this embodiment includes:

[0164] The historical traffic playback submodule is used to extract historical traffic data from the database and play it back in the original order through multi-threading or asynchronous programming technology to build playback test scenarios;

[0165] The result comparison and analysis submodule uses simulated request technology to send historical requests to the API and compare the returned results. It also combines transaction consistency detection to ensure that the playback test is consistent with the actual API behavior, or predefines a set of expected response rules and then compares the actual responses one by one to see if they meet expectations.

[0166] The assertion verification module in this embodiment includes:

[0167] The assertion rule definition submodule is used to predefine the format, status code, and response time constraints of the API return data through configuration files or encoding interfaces.

[0168] The assertion execution submodule is used to dynamically adjust assertion conditions through the rule engine during the test process. The test framework automatically performs verification according to the defined assertion rules to improve test accuracy.

[0169] The test report generation module in this embodiment is responsible for generating test reports containing detailed information such as success rate, response time, error logs, etc., and supports exporting to multiple formats (such as HTML, PDF, CSV, etc.). Test reports are not only an important basis for evaluating test results, but also a key tool for improving API quality and performance.

[0170] The test report generation module in this embodiment includes:

[0171] The test result collection submodule is used to collect the result data of all tests, including the success or failure of each test case, response time and error log;

[0172] Report template generation submodule, used to generate test reports using the template engine;

[0173] The report export submodule is used to convert HTML reports to PDF format using the WeasyPrint or ReportLab third-party libraries, or to export data to CSV files using the Pandas library.

[0174] The working process of the system is as follows:

[0175] ① Test case generation: Automatically parse the interface structure based on API documents (such as OpenAPI) and generate a basic test case set;

[0176] ② Traffic capture: Real-time monitoring of actual API calls, recording the specific content of each request and its corresponding response data:

[0177] ③Automated test execution: Forward testing replays historical API calls to ensure the compatibility of different API versions; exception testing is used to perform boundary value verification;

[0178] ④ Assertion verification: Assert indicators such as return value and response time to detect anomalies;

[0179] ⑤Test report generation: Aggregate test result data to generate a test report containing detailed information such as success rate, response time, error log, etc., and support HTML / PDF / JSON export.

[0180] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for implementing automated testing of hosted APIs using an API gateway, characterized in that: The method is as follows: Test case generation: Automatically parse the interface structure based on the API document and generate a basic test case set; Traffic capture: monitors actual API calls in real time, recording the specific content of each request and its corresponding response data; in particular, the specific content of each request and its corresponding response data HTTP header information, request and response bodies, as well as timestamps and status code metadata; Traffic replay: Perform replay tests based on captured historical traffic to verify API compatibility. Simulating real user behavior patterns to reproduce past API call sequences can be used to verify whether newly deployed functions adversely affect existing business logic. Assertion verification: Assertion mechanisms are used to assess return values ​​and response time metrics and identify anomalies. The assertion mechanism defines correctness rules for API return values, ensuring output consistency and accuracy. It also verifies the API's basic functionality and detects anomalies and edge cases. Test report generation: Aggregate test result data to generate a test report containing success rate, response time, and error log details, and support HTML / PDF / JSON export.

2. The method for implementing automated testing of hosted APIs using an API gateway according to claim 1, wherein: The test case generation is as follows: Parsing API definition documents: Parsing OpenAPI documents or Swagger definitions to extract API endpoints, request parameters, and return values. Specifically, for OpenAPI specifications, use open source libraries to parse YAML or JSON format files to obtain all API paths and operations contained therein. Automatically generate basic test cases: Combined with historical API call data, it automatically generates positive test, negative test and boundary test cases, and supports users to add custom rules and boundary conditions. Specifically: the operation type of each API endpoint determines the test logic corresponding to the API endpoint; among them, the operation types of API endpoints include GET and POST; for a GET request, the test case includes checking whether the status code is 200 and whether the response body conforms to the expected model; for a POST request, it is necessary to construct a valid request body and verify whether the returned data is correct.

3. The method for implementing automated testing of hosted APIs using an API gateway according to claim 1, wherein: Traffic capture is as follows: Integration gateway plug-in: deploy non-intrusive listeners at the API gateway layer to collect API call data in real time; Storing request and response data: Storing captured request and response data in a persistent database. Specifically, use log storage, message queues, or a time series database to store API requests, responses, and related metadata. Data encryption and privacy protection: Use symmetric encryption algorithms to encrypt sensitive fields before storing them in the database.

4. The method for implementing automated testing of hosted APIs using an API gateway according to claim 1, wherein: Traffic playback is as follows: Replay historical traffic: Extract historical traffic data from the database and replay it in the original order using multi-threaded or asynchronous programming techniques to build replay test scenarios; Result comparison and analysis: Use simulated request technology to send historical requests to the API and compare the returned results. Combined with transaction consistency detection, ensure that the playback test is consistent with the actual API behavior. Alternatively, predefine a set of expected response rules and then compare the actual responses one by one to see if they meet expectations.

5. The method for implementing automated testing of hosted APIs using an API gateway according to claim 1, wherein: The assertion verification is as follows: Define assertion rules: predefine the format, status code, and response time constraints of the API return data through configuration files or coding interfaces. Execute assertions: During the test process, the assertion conditions are dynamically adjusted through the rule engine, and the test framework automatically performs verification according to the defined assertion rules to improve test accuracy.

6. The method for implementing automated testing of hosted APIs through an API gateway according to claims 1-5, characterized in that: The test report is generated as follows: Collect test results: Collect all test result data, including the success or failure of each test case, response time, and error logs; Generate report template: use template engine to generate test report; Export reports: Use WeasyPrint or ReportLab third-party libraries to convert HTML reports to PDF format, or use the Pandas library to export data to CSV files.

7. A system for implementing automated testing of hosted APIs using an API gateway, characterized in that: The system includes: The test case generation module is used to automatically generate test cases based on API definitions, parse standard format documents, and support custom rules to improve coverage; Traffic capture module, used to monitor the actual API calls in real time, recording the specific content of each request and its corresponding response data; in particular, the specific content of each request and its corresponding response data HTTP header information, request and response body, as well as timestamp and status code metadata; The traffic replay module is used to perform replay tests based on captured historical traffic to verify API compatibility. It also simulates real user behavior patterns to reproduce past API call sequences to verify whether newly deployed functions have adverse effects on existing business logic. The assertion module is used to assert return values ​​and response time metrics and detect anomalies through the assertion mechanism. The assertion mechanism is used to define the correctness rules of API return values ​​to ensure the consistency and accuracy of the output. The assertion mechanism is also used to verify the basic functionality of the API and detect anomalies and edge cases. The test report generation module is used to generate test reports containing success rate, response time, and error log details, and supports HTML / PDF / JSON export.

8. The system for implementing managed API automated testing using an API gateway according to claim 7, characterized in that: The test case generation module includes: The API definition document parsing submodule is used to parse OpenAPI documents or Swagger definitions to extract API endpoints, request parameters, and return values. Specifically, for OpenAPI specifications, it uses open source libraries to parse YAML or JSON format files to obtain all the API paths and operations contained therein. The basic test case automatic generation sub-module is used to automatically generate positive test, negative test and boundary test cases based on historical API call data, and supports users to add custom rules and boundary conditions; specifically: the operation type of each API endpoint determines the test logic corresponding to the API endpoint; among them, the operation types of API endpoints include GET and POST; for a GET request, the test case includes checking whether the status code is 200 and whether the response body conforms to the expected model; for a POST request, it is necessary to construct a valid request body and verify whether the returned data is correct.

9. The system for implementing managed API automated testing using an API gateway according to claim 7, characterized in that: The traffic capture module includes: The gateway plug-in integration submodule is used to deploy non-intrusive listeners at the API gateway layer to collect API call data in real time; The request and response data storage submodule is used to store the captured request and response data in a persistent database. Specifically, it uses log storage, message queues, or a time series database to store API requests, responses, and related metadata. The data encryption and privacy protection submodule is used to encrypt sensitive fields using a symmetric encryption algorithm and then store them in the database; The traffic replay module includes: The historical traffic playback submodule is used to extract historical traffic data from the database and play it back in the original order through multi-threading or asynchronous programming technology to build playback test scenarios; The result comparison and analysis submodule uses simulated request technology to send historical requests to the API and compare the returned results. It also combines transaction consistency detection to ensure that the playback test is consistent with the actual API behavior, or predefines a set of expected response rules and then compares the actual responses one by one to see if they meet expectations.

10. A system for implementing automated testing of hosted APIs through an API gateway according to any one of claims 7 to 9, characterized in that: The assertion verification module includes: The assertion rule definition submodule is used to predefine the format, status code, and response time constraints of the API return data through configuration files or encoding interfaces. The assertion execution submodule is used to dynamically adjust assertion conditions through the rule engine during the test process. The test framework automatically performs verification according to the defined assertion rules to improve test accuracy. The test report generation module includes: The test result collection submodule is used to collect the result data of all tests, including the success or failure of each test case, response time and error log; Report template generation submodule, used to generate test reports using the template engine; The report export submodule is used to convert HTML reports to PDF format using the WeasyPrint or ReportLab third-party libraries, or to export data to CSV files using the Pandas library.

Images