A Katalon-based API automated testing method and system

Abstract

This invention discloses an API automated testing method and system based on Katalon, belonging to the field of API automated testing technology. It includes configuring multi-environment global variables for the Katalon test project; generating basic test case data based on API interface documentation, historical test databases, business logic, and dependencies; and then arranging the test case data and its various parameters, including interfaces, request parameters, expected results, and priorities, to ensure they conform to business logic and interface calls and verification. For high-complexity parameters, boundary value and abnormal format test data are generated; for low-complexity parameters, regular test data is generated. Simple response data and expected results are directly compared; complex response results and expectations are recursively compared using regular expressions; and even more complex response data can be validated using JSON Schema. If a mismatch is found, the location is recorded and the specific difference is output. The judgment rules are adjusted as needed based on the analysis and verification of the test report.

Description

Technical Field

[0001] This invention relates to the field of API automated testing technology, and in particular to an API automated testing method and system based on Katalon. Background Technology

[0002] API automated testing refers to the process of automatically verifying the functionality, performance, and security of an API using tools or scripts. Its main purpose is to ensure that the API functions as expected, correctly processing requests and returning accurate responses under various conditions. Therefore, how to leverage advanced technologies to improve the intelligence, uniformity, flexibility, and stability of API automated testing has become one of the most pressing issues to be addressed.

[0003] In the field of API automation testing, traditional API test cases often need to be written manually, which is time-consuming and prone to missing critical paths. The lack of automatic test case generation capabilities leads to insufficient test coverage and difficulty in fully detecting potential problems. Furthermore, for complex API parameters, simple regular test data may not be sufficient to reveal all potential problems. Boundary values, abnormal formats, and other special cases are often ignored, reducing the effectiveness and coverage of the tests.

[0004] Traditional API test cases require the use of scripts or specialized programming languages ​​to implement / maintain test cases in a targeted manner. Manual writing is tedious and prone to errors, which reduces timeliness, prolongs the software iteration cycle, and is not conducive to the unified management of the test process.

[0005] Traditional API testing also cannot easily support the sharing of test data between different stages or execution modes within the testing process, thus failing to support more complex functional testing, and the data between test cases is isolated and inflexible.

[0006] Mainstream API testing tools include Postman, primarily used for API debugging and basic testing. However, this tool has weak automation capabilities, limited assertion functionality, requires manual writing of JS scripts for complex validations, and has low efficiency in batch testing and debugging. Its integration support is poor, making it unsuitable for full-process automation; it's only suitable for quick debugging, simple API verification, and manual testing in small projects. Another popular performance testing tool is JMeter, which offers powerful overall functionality for API verification. However, it has several shortcomings, including complex script maintenance, the need to save test cases in separate files, difficulty in debugging multiple related APIs, low efficiency in error localization, unfriendly reporting, weak environment management, and difficulty in dynamically initializing or cleaning up, affecting the reliability of automation. Furthermore, these tools suffer from inadequate test data management, making assertion rules highly susceptible to data changes, weak support for encrypted APIs, and poor handling of security mechanisms such as signature authentication and dynamic tokens, requiring manual writing of preprocessing scripts.

[0007] Because these tools focus more on testing and verifying individual APIs, they fail to abstract a common execution flow in the overall design of batch tasks, and they also fail to perfectly decouple the process framework tools from the test case data. This results in test cases and their execution implementations being chaotic and difficult to manage in a unified manner, which is not conducive to timely verification / reproduction of problems in regression testing. Summary of the Invention

[0008] In view of the aforementioned existing problems, this invention is proposed.

[0009] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0010] In a first aspect, the present invention provides an API automated testing method based on Katalon, comprising:

[0011] Configure multi-environment global variables for the Katalon test project, generate basic test case data based on API interface documentation, historical test database, business logic and dependencies, and then arrange the test case data and its various parameters, including interface, request parameters, expected results and priorities, to make them conform to business logic and interface calls and verification.

[0012] Generate boundary value and abnormal format test data for high-complexity parameters, and generate regular test data for low-complexity parameters;

[0013] Simple response data is directly compared with the expected result. Complex response results are recursively compared with the expected result using regular expressions. More complex response data can be validated using JSON Schema. If a mismatch is found, the location is recorded and the specific difference is output. The judgment rules are adjusted as needed based on the analysis and verification of the test report.

[0014] The test cases are sorted according to their priority scores to generate a test queue. The specific steps are as follows:

[0015] All test cases are sorted in descending order according to their priority scores. During the sorting process, test cases with the same priority score are further sorted according to their most recent execution timestamp. The secondary sorting adopts an ascending order so that test cases that have not been executed for a long time can obtain higher execution priority.

[0016] The test case list is adjusted based on the current resource status. The adjustment process is implemented by dynamically assigning weights to each test case, as shown in the expression:

[0017] ;

[0018] in, and These are the priority score P and the importance coefficient of resource consumption, respectively. For projected resource consumption;

[0019] Convert the adjusted test case list into a test queue. The test queue is scored according to the overall priority of each test case. Sort from highest to lowest;

[0020] Use the scheduler to start from the test queue Test cases are retrieved and executed sequentially. When the scheduler detects that the resources are close to full load, it automatically pauses the start of new test cases until the resources are restored to a safe level.

[0021] As a preferred embodiment of the Katalon-based API automated testing method described in this invention, the specific steps for generating basic test case data include:

[0022] The set of environment parameters extracted from the user configuration file is classified to obtain multiple environment configuration groups. The set of environment parameters includes the target URL, authentication information, database connection string and timeout threshold under different deployment environments.

[0023] The parsing engine is used to perform syntax analysis on the received OpenAPI or Swagger format API interface documents, and extract the interface path, request method, request header, request body structure, response example and field description information.

[0024] The process of generating basic test case data and then executing these test case data includes initializing the configuration, obtaining test case data, assembling request parameters, sending requests and obtaining responses, asserting responses and expected results, recording issues and generating test reports.

[0025] The test case data obtained from the historical test database includes the number, description, request parameters, expected results, and given priority. This data is used by the test framework to call requests and verify responses. The execution priority is determined by combining the test case code ID, the given priority, and the logical dependencies between test cases.

[0026] As a preferred embodiment of the Katalon-based API automated testing method described in this invention, the basic data types are categorized as follows: high-complexity parameters refer to JSON object structures, arrays, and nested structures of the two; low-complexity parameters refer to integer, boolean, character, and string types. Boundary value and abnormal format test data are generated for high-complexity parameters; regular test data is generated for low-complexity parameters, and further boundary value and abnormal format test data are generated, specifically as follows:

[0027] For numerical parameters that are low-complexity parameters Determine its minimum value and maximum value and generate including Boundary value test data, including;

[0028] For string parameters, based on their length limits and character set definitions, generate test data in an abnormal format that includes minimum length, maximum length, length exceeding limits, and illegal characters;

[0029] Regular test data is generated for each parameter based on typical value ranges. The regular test data is used to verify whether the behavior under normal input conditions meets expectations. Boundary value and abnormal format test data of other low-complexity and high-complexity parameters are combined with the regular test data to form a comprehensive test case set.

[0030] As a preferred embodiment of the Katalon-based API automated testing method described in this invention, the specific steps for setting matching rules for key fields and verification rules for non-key fields in the response data are as follows:

[0031] Set matching rules for key fields in each API response data to be verified. The matching rules include numerical exact matching, string regular expression matching, or structure path matching, and can be pre-configured by the user into the test rule database.

[0032] During test execution, assertions are performed on key fields in the current response data, and the actual values ​​are compared with the expected results. If the actual values ​​do not meet the matching rules, the assertion of that key field is marked as failed.

[0033] As a preferred embodiment of the Katalon-based API automated testing method of the present invention, the following steps are taken: Validation rules are applied to the actual values ​​of non-critical fields to determine whether they conform to a preset set of format difference patterns, which includes case insensitivity, whitespace adjustment, date format conversion, or numerical precision fluctuation.

[0034] As a preferred embodiment of the Katalon-based API automated testing method described in this invention, the following features are provided: JSON Schema can be used to validate response data for more complex responses; the matching rules are not modified during the testing process; regular expressions can be used to cover situations where rule corrections need to be triggered; and adjustments can be made as needed after analyzing and verifying whether the issue is with the matching rules based on the test reports.

[0035] Secondly, this invention provides an API automated testing system based on Katalon, comprising:

[0036] The module includes a data configuration management module, a test case data orchestration module, a parameter integration and processing module, a process data sharing module, a rule parsing and judgment module, and a test report generation module.

[0037] The data configuration management module is used to uniformly manage the addition, deletion, query and modification of historical test case data and to classify the set of environment parameters extracted from the user configuration file to obtain multiple environment configuration groups.

[0038] The test case data orchestration module is used to perform syntax analysis on the received OpenAPI or Swagger format API interface documents using a parsing engine, extract interface paths, request methods, request headers, request body structures, response examples, and field description information, and generate corresponding test case data for each interface path and request method combination based on the extracted interface structure information, and supplement or correct the automatically generated test cases according to the business coverage requirements input by the testers.

[0039] The parameter integration and processing module is used to unify the parameter acquisition abstraction layer, preprocess and assemble parameters, calculate and generate signatures or authentication tokens for specific parameters or request bodies according to interface protocols or custom signature algorithms, and automatically add system-level public parameters and unified interface request sending and response acquisition.

[0040] The process data sharing module is used to dynamically cache and share the request parameters and response results of test cases during the execution of API test cases;

[0041] The rule parsing and judgment module is used to parse and judge whether the API test response conforms to the preset verification rules. The core includes two verification mechanisms: general data type matching, which directly matches the basic data types in the response; and complex data structure verification, which performs structured verification on the JSON objects nested in the response data to ensure that they conform to the expected format and constraints, so that they can pass the verification by parsing regular expressions or user-defined JSON Schema.

[0042] The test report generation module generates reports that can be analyzed and verified based on the output log statistics of the execution process of one, one, or a group of test cases, providing key information such as test pass rate and reasons for failure.

[0043] The beneficial effects of this invention are as follows: Through innovative integration of various functional modules, it solves the problems of low test case maintenance, invocation, and reuse rates caused by scattered and inconsistent test case management, making it difficult to achieve linkage between multiple test cases; the scattered logic of parameter acquisition, assembly, signing, and authentication, lacking a unified abstraction layer, leading to complex parameter processing, high repetition rate, and high interface call failure rate, affecting test stability; the response verification logic relying entirely on manual writing by testers, with inconsistent verification rules and inflexible adaptation to different scenarios, resulting in high misjudgment rate and test results that fail to accurately reflect interface functional issues; the lack of data sharing mechanisms and reuse difficulties in processing test data independently for each test case, leading to low test efficiency and difficulty in supporting multi-stage, multi-test case collaborative testing; and the lack of structure and traceability in test reports, making it difficult to support effective test analysis and problem localization. After effectively organizing the various modules, the system achieves intelligent generation of test cases and efficient data orchestration, unified parameter processing and flexible matching and verification of responses. Data reuse and dynamic sharing among multiple test cases improve testing efficiency and scalability. Through the generation of test reports, it provides comprehensive support for test analysis, ensuring the stability and traceability of tests. Especially in the process of software iteration, it significantly reduces the complexity and time cost of regression testing, and improves the efficiency, maintainability and adaptability of API testing to complex scenarios. Attached Figure Description

[0044] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1 This is a flowchart of the Katalon-based API automated testing method in Example 1.

[0046] Figure 2 This is a schematic diagram of the Katalon-based API automated testing system in Example 1.

[0047] Figure 3 This is a flowchart of the multi-environment configuration and test data acquisition process in Example 1.

[0048] Figure 4 This is a flowchart of the process for determining the sorting execution queue in Example 1. Detailed Implementation

[0049] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0050] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0051] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0052] Example 1, referring to Figures 1-4 This is the first embodiment of the present invention, which provides an API automated testing method based on Katalon, including the following steps:

[0053] S1. Configure the multi-environment global variables of the Katalon test project, generate basic test case data based on API interface documents, historical test database, business logic and dependencies, and then arrange the test case data and its various parameters, including interface, request parameters, expected results and priorities, to make them conform to business logic and interface calls and verification.

[0054] Furthermore, the test case database is initialized, multi-environment global variables of the Katalon test project are configured, existing historical test data is collected, and API interface documentation is imported to generate basic test cases. The specific steps are as follows:

[0055] The set of environment parameters extracted from the user configuration file is classified and processed to obtain multiple environment configuration groups. The set of environment parameters includes the target URL, authentication information, database connection string and timeout threshold under different deployment environments.

[0056] The parsing engine is used to perform syntax analysis on the received OpenAPI or Swagger format API interface documents, and extract the interface path, request method, request header, request body structure, response example and field description information.

[0057] The process of generating basic test case data and then executing these test case data includes initializing the configuration, obtaining test case data, assembling request parameters, sending requests and obtaining responses, asserting responses and expected results, recording issues and generating test reports.

[0058] The test case data obtained from the historical test database includes the number, description, request parameters, expected results, and given priority. This data is used by the test framework to call requests and verify responses. The execution priority is determined by combining the test case code ID, the given priority, and the logical dependencies between test cases.

[0059] It should be noted that this test case generation and management mechanism not only supports automated test case construction based on interface documents, but also continuously optimizes the test coverage and depth through historical data feedback, thereby improving test efficiency. In addition, the classification and processing mechanism of the environment configuration group ensures that the same set of test scripts can be flexibly switched in different deployment environments without having to repeatedly write or modify code, thereby enhancing the portability and adaptability of the test framework.

[0060] S2. Generate boundary value and abnormal format test data for high-complexity parameters, and generate regular test data for low-complexity parameters;

[0061] Furthermore, the execution order of test cases is sorted based on priority scores to generate a test queue. The specific steps are as follows:

[0062] All test cases are sorted in descending order based on their priority scores. During the sorting process, test cases with the same priority score are further sorted based on their most recent execution timestamp. The secondary sorting is in ascending order so that test cases that have not been executed for a long time can obtain higher execution priority.

[0063] The test case list is adjusted based on the current resource status. The adjustment process is implemented by dynamically assigning weights to each test case, as shown in the expression:

[0064] ;

[0065] in, and These are the priority score P and the importance coefficient of resource consumption, respectively. For projected resource consumption;

[0066] Convert the adjusted test case list into a test queue. The test queue is scored based on the overall priority of each test case. Sort from highest to lowest;

[0067] Use the scheduler to start from the test queue Test cases are retrieved sequentially and executed. When the scheduler detects that the resources are close to full load, it automatically pauses the start of new test cases until the resources are restored to a safe level.

[0068] It should be noted that the dynamic adjustment mechanism of the test queue takes into account the balance between resource consumption and priority, so that high-value test cases can still be executed first when resources are limited, ensuring the verification quality of key functions. At the same time, the scheduler's real-time monitoring of resource status and adaptive pause mechanism effectively prevent system overload and improve the stability and reliability of the overall test process, which is especially suitable for automated testing scenarios in continuous integration / continuous delivery (CI / CD) pipelines.

[0069] S3: Simple response data and expected results are directly compared; complex response results and expectations are recursively compared using regular expressions; even more complex response data can be validated using JSON Schema. If a mismatch is found, the location of the record is recorded and the specific difference is output. The judgment rules are adjusted as needed based on the analysis and verification of the test report.

[0070] Furthermore, the basic data types are categorized as follows: integers, booleans, characters, and strings are considered simple complexity parameters, while JSON object structures, arrays, and nested structures of the two are considered high complexity parameters. Complex parameters are generated based on the structure described in the interface documentation, initial test data is generated, and then the data is arranged, adjusted, and optimized.

[0071] For generating boundary value and anomalous format test data for high-complexity parameters, and for generating regular test data for low-complexity parameters, the specific steps are as follows:

[0072] For numerical parameters Determine its minimum value and maximum value and generate including Boundary value test data, including;

[0073] For string parameters, based on their length limits and character set definitions, generate test data in an abnormal format that includes minimum length, maximum length, length exceeding limits, and illegal characters;

[0074] Based on the typical value range, regular test data is generated for each parameter. The regular test data is used to verify whether the behavior under normal input conditions meets the expectations. Boundary value and abnormal format test data of other low-complexity and high-complexity parameters are combined with the regular test data to form a comprehensive test case set.

[0075] The specific steps for setting matching rules for key fields and validation rules for non-key fields in the response data are as follows:

[0076] Set matching rules for key fields in each API response data to be verified. The matching rules include exact numerical matching, regular string matching, or structural path matching, and can be pre-configured by the user in the test rule database.

[0077] During test execution, assertions are performed on key fields in the current response data, and the actual values ​​are compared with the expected results. If the actual values ​​do not meet the matching rules, the assertion of the key field is marked as failed.

[0078] Validation rules are applied to the actual values ​​of non-critical fields to determine whether they conform to a preset set of format difference patterns. The set of format difference patterns includes case insensitivity, whitespace adjustment, date format conversion, or numerical precision fluctuation.

[0079] For more complex response data, JSON Schema can be used to validate the response data. The matching rules are not modified during the test. If it is necessary to trigger the correction of the rules, regular expressions can be used to cover it. Afterwards, the rules can be adjusted as needed after analyzing and verifying whether the problem is with the matching rules based on the test report.

[0080] It should be noted that the response data verification mechanism adopts a layered strategy based on data complexity, which can efficiently verify simple fields and accurately identify format deviations in complex structures, avoiding false positives and missed detections. In addition, the combined use of regular expressions and JSON Schema provides a balance between flexibility and accuracy, supporting verification needs in various business scenarios. The rule correction mechanism achieves closed-loop optimization through test report-driven methods, which helps to continuously improve the accuracy and applicability of test assertions and enhance the intelligence level of automated testing.

[0081] This embodiment also provides an API automated testing system based on Katalon, including:

[0082] The module includes a data configuration management module, a test case data orchestration module, a parameter integration and processing module, a process data sharing module, a rule parsing and judgment module, and a test report generation module.

[0083] The data configuration management module is used to uniformly manage the addition, deletion, query and modification of historical test case data and classify the set of environment parameters extracted from the user configuration file to obtain multiple environment configuration groups. This ensures the independence of test data, isolates the environment using configuration variables, maximizes the reuse of existing frameworks and runtime resources, greatly reduces redundancy and effectively improves resource utilization.

[0084] The test case data orchestration module uses a parsing engine to perform syntax analysis on the received OpenAPI or Swagger format API interface documents, extracting interface paths, request methods, request headers, request body structure, response examples, and field descriptions. Based on the extracted interface structure information, it generates corresponding test case data and methods for each interface path and request method combination. It also incorporates test cases generated by testers based on their understanding of the business logic, including data on insufficient or defective test case coverage, such as evaluating the functional modules associated with each test case to obtain corresponding business priority weights.

[0085] The parameter integration and processing module is used to unify the parameter acquisition abstraction layer, preprocess and assemble parameters, calculate and generate signatures or authentication tokens for specific parameters or request bodies according to interface protocols or custom signature algorithms, automatically add system-level public parameters and unify the request sending and response acquisition of interfaces, etc. It extracts these scattered logical processing into public ones to reduce code redundancy, maintenance difficulties and interface call failures, which are inherent problems of traditional testing methods.

[0086] The process data sharing module is used to dynamically cache and share the request parameters and response results of test cases during the execution of API test cases, realize data reuse across test cases, improve test efficiency, scalability and adaptability to complex scenarios, thereby supporting data linkage between multiple test cases and meeting complex requirements such as multi-stage testing. This module solves the problems of low data duplication rate and poor complexity adaptability in traditional API testing through data caching and dynamic sharing strategies.

[0087] The rule parsing and judgment module is used to parse and judge whether the API test response conforms to the preset verification rules. It includes two core verification mechanisms: general data type matching, which directly matches basic data types in the response, efficiently handling simple data structures, avoiding complex verification logic, and suitable for general data format scenarios; and complex data structure verification, which performs structured verification on nested JSON objects in the response data to ensure they conform to the expected format and constraints. This is achieved by parsing regular expressions or user-defined JSON Schema to improve the accuracy of complex data verification, avoid test failures due to format errors, and support flexible verification strategies to adapt to unit tests or integration tests. It also uniformly records fields and error messages of failed verifications for easy test report generation, providing common response verification capabilities for API testing and suitable for highly complex testing scenarios.

[0088] The test report generation module generates reports based on the output log statistics of one, one, or a group of test cases, which can be used for test analysis and verification. It provides key information such as test pass rate and failure reasons in an effective and intuitive way on the interface, better supports test analysis and verification, and improves the transparency and traceability of the test process.

[0089] This embodiment also provides a computer device applicable to the Katalon-based API automated testing method, comprising: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the Katalon-based API automated testing method proposed in the above embodiment.

[0090] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0091] This embodiment also provides a storage medium storing a computer program that, when executed by a processor, implements the Katalon-based API automated testing method as proposed in the above embodiments. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0092] In summary, this invention, through innovative integration of various functional modules, addresses the following issues: fragmented and inconsistent test case management leads to low test case maintenance, invocation, and reuse rates, hindering multi-test case collaboration; fragmented parameter acquisition, assembly, signing, and authentication logic, lacking a unified abstraction layer, results in complex parameter processing, high repetition rates, and high interface call failure rates, impacting test stability; response verification logic relies entirely on manual coding by testers, with inconsistent verification rules and inflexible adaptation to different scenarios, leading to high misjudgment rates and inaccurate test results reflecting interface functionalities; test data can only be processed independently by individual test cases, lacking data sharing mechanisms and reusability, resulting in low test efficiency and difficulty in supporting multi-stage, multi-test case collaborative testing; and test reports lack structure, traceability, and support for effective test analysis and problem localization. After effectively organizing the various modules, the system achieves intelligent generation of test cases and efficient data orchestration, unified parameter processing and flexible matching and verification of responses. Data reuse and dynamic sharing among multiple test cases improve testing efficiency and scalability. Through the generation of test reports, it provides comprehensive support for test analysis, ensuring the stability and traceability of tests. Especially in the process of software iteration, it significantly reduces the complexity and time cost of regression testing, and improves the efficiency, maintainability and adaptability of API testing to complex scenarios.

[0093] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A Katalon-based API automated testing method, characterized in that: include: The set of environment parameters extracted from the user configuration file is classified and processed to obtain multiple environment configuration groups. The set of environment parameters includes the target URL, authentication information, database connection string and timeout threshold under different deployment environments. The parsing engine is used to perform syntax analysis on the received OpenAPI or Swagger format API interface document to extract the interface path, request method, request header, request body structure, response example and field description information. The process of generating basic test case data and then executing these test case data includes initializing the configuration, obtaining test case data, assembling request parameters, sending requests and obtaining responses, asserting responses and expected results, recording issues and generating test reports. The basic test case data also includes test case data from the historical test database, including test case number, description, request parameters, expected results and priority. The test execution order is determined based on the test case number, priority and logical dependencies between test cases. The basic data types are categorized as follows: high-complexity parameters refer to JSON object structures, arrays, and nested structures of the two; low-complexity parameters refer to integer, boolean, character, and string types; boundary value and abnormal format test data are generated for high-complexity parameters, and regular test data is generated for low-complexity parameters. For response data with low-complexity parameters, the actual value is directly compared with the expected result. For response data with high-complexity parameters, regular expressions are used for recursive comparison or JSON Schema is used for validation. If a mismatch is found, the location of the record is recorded and the specific difference is output. The judgment rules are adjusted based on the analysis and verification of the test report. The process of sorting test cases by priority to generate a test queue involves the following steps: All test cases are sorted in descending order according to their priority scores. During the sorting process, test cases with the same priority score are further sorted according to their most recent execution timestamp. The secondary sorting adopts an ascending order so that test cases that have not been executed for a long time can obtain higher execution priority. The test case list is adjusted based on the current resource status. The adjustment process is implemented by dynamically assigning weights to each test case, as shown in the expression: ; in, and These are priority scores. And the importance coefficient of resource consumption, For projected resource consumption; Convert the adjusted test case list into a test queue. The test queue is scored according to the overall priority of each test case. Sort from highest to lowest; Use the scheduler to start from the test queue Test cases are retrieved and executed sequentially. When the scheduler detects that the resources are close to full load, it automatically pauses the start of new test cases until the resources are restored to a safe level.

2. The API automated testing method based on Katalon as described in claim 1, characterized in that: For high-complexity parameters, generate boundary value and anomalous format test data; for low-complexity parameters, generate regular test data, and further generate boundary value and anomalous format test data, specifically: For numerical parameters that are low-complexity parameters Determine its minimum value and maximum value and generate including Boundary value test data, including; For string parameters, based on their length limits and character set definitions, generate test data in an abnormal format that includes minimum length, maximum length, length exceeding limits, and illegal characters; Regular test data is generated for each parameter based on typical value ranges. The regular test data is used to verify whether the behavior under normal input conditions meets expectations. Boundary value and abnormal format test data of other low-complexity and high-complexity parameters are combined with the regular test data to form a comprehensive test case set.

3. The API automated testing method based on Katalon as described in claim 2, characterized in that: The specific steps for setting matching rules for key fields and validation rules for non-key fields in the response data are as follows: Set matching rules for key fields in each API response data to be verified. The matching rules include numerical exact matching, string regular expression matching, or structure path matching, and are pre-configured by the user into the test rule database. During test execution, assertions are performed on key fields in the current response data. The actual values ​​are compared with the expected results. If the actual values ​​do not meet the matching rules, the assertion of that key field is marked as failed.

4. The API automated testing method based on Katalon as described in claim 3, characterized in that: Validation rules are applied to the actual values ​​of non-critical fields to determine whether they conform to a preset set of format difference patterns, which includes case insensitivity, whitespace adjustment, date format conversion, or numerical precision fluctuation.

5. A Katalon-based API automated testing system, based on the Katalon-based API automated testing method according to any one of claims 1 to 4, characterized in that: include: The module includes a data configuration management module, a test case data orchestration module, a parameter integration and processing module, a process data sharing module, a rule parsing and judgment module, and a test report generation module. The data configuration management module is used to uniformly manage the addition, deletion, query and modification of historical test case data and to classify the set of environment parameters extracted from the user configuration file to obtain multiple environment configuration groups. The test case data orchestration module is used to perform syntax analysis on the received OpenAPI or Swagger format API interface documents using a parsing engine, extract interface paths, request methods, request headers, request body structures, response examples, and field description information, and generate corresponding test case data for each interface path and request method combination based on the extracted interface structure information, and supplement or correct the automatically generated test cases according to the business coverage requirements input by the testers. The parameter integration and processing module is used to unify the parameter acquisition abstraction layer, preprocess and assemble parameters, calculate and generate signatures or authentication tokens for parameters or request bodies according to interface protocols or custom signature algorithms, and automatically add system-level public parameters and unified interface request sending and response acquisition. The process data sharing module is used to dynamically cache and share the request parameters and response results of test cases during the execution of API test cases; The rule parsing and judgment module is used to parse and judge whether the API test response conforms to the preset verification rules, and to perform special assertion verification according to the preset rules for the key fields marked by the user. The test report generation module generates reports that can be analyzed and verified based on the output log statistics of the execution process of one, one, or a group of test cases, providing key information such as test pass rate and reasons for failure.

Images