Interface automatic test method and system based on hot loading reflection and YAML driving

Abstract

The application provides a method and system for interface automatic testing based on hot loading reflection and YAML driving, and belongs to the technical field of software testing. The method comprises the following steps: parsing test case data in a structured data configuration file into a structured data object and serializing the structured data object into a string; identifying a method call placeholder in the string through regular matching, dynamically calling a corresponding preset logic function by using a reflection mechanism, and replacing the placeholder; constructing and sending an HTTP request based on the test case data after the replacement is completed to obtain an interface response; selecting a JSONPath or a regular expression to extract associated parameters according to a response data type, and storing the associated parameters in a session-level associated variable storage area for subsequent test case reading and injection. The application enables a structured data test case file to have programmable capability, realizes full-link automatic circulation and multi-dimensional composite assertion of interface associated variables, and significantly reduces the code writing amount and maintenance cost of interface automatic testing.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to an automated interface testing method and system based on hot-loading reflection and YAML-driven testing. Background Technology

[0002] Interface automation testing is a crucial means of software quality assurance. Currently, the industry commonly employs keyword-driven or data-driven models to build interface automation testing frameworks. Typical technical solutions include the interface automation testing method and system disclosed in patent CN111159049A filed by Bank of China Limited, and the automation testing method based on the pytest framework disclosed in patent CN115454811A filed by China Education Cloud Intelligence Digital Technology Group Co., Ltd. Both solutions use structured files such as YAML to define interface request parameters and expected results, which are then parsed by Python code to drive HTTP request execution, achieving partial separation of test data and test code. However, in these existing technologies, YAML only serves as a static data carrier and cannot call dynamic logic functions such as encryption signatures and timestamp generation in the test case definition. Complex authentication scenarios still require writing Python code, undermining the original design intention of separating data and code. Furthermore, the parameterization logic in existing technologies is separated from the test case definition. YAML cannot self-describe parameterization rules, requiring additional data source configuration in the Python code, resulting in low test case writing efficiency and high maintenance costs.

[0003] Regarding the passing of interface-related variables, patent CN122045053A discloses an automated testing method for web interfaces, which automatically generates interface test sequences through interface dependency modeling. However, this solution requires manual annotation of dependencies between interfaces beforehand and cannot achieve automatic extraction and injection of response variables. Another patent, CN202211613661.2, discloses an automated testing method for protocol interfaces, which uses hard-coding to handle interface-related variables, requiring manual maintenance of interface dependencies. In terms of assertion methods, patent CN202311482255, applied for by Tianjin Hualai Technology Co., Ltd., discloses an automated interface testing method based on pytest, which performs assertion verification on interface responses using JSONPath. However, assertion rules need to be defined in Python code, and the YAML layer cannot express multi-dimensional assertion logic such as positive, negative, and null values. Regarding result notification and environment adaptation, patent CN202010978541 discloses an automated testing system for Socket interfaces, but its test execution and result output are tightly coupled, lacking a multi-channel notification mechanism; patent CN202210403634.6 discloses an automated testing method for interfaces of multi-database systems, but environment switching requires manual adjustment, and notification push lacks a zero-intervention mechanism. In summary, existing automated interface testing frameworks have shortcomings in terms of test case programmability, automatic flow of associated variables, assertion capabilities, data-driven integration, and operational assurance. There is an urgent need for an interface testing solution that can achieve end-to-end automation without writing code. Summary of the Invention

[0004] To address the aforementioned technical problems in related technologies, this invention proposes an automated interface testing method and system based on hot-loading reflection and YAML driving, which can overcome the above-mentioned shortcomings of the prior art.

[0005] To achieve the above-mentioned technical objectives, the technical solution of the present invention is implemented as follows: An automated interface testing method based on hot-loading reflection and YAML-driven approach; This automated interface testing method and system based on hot-loading reflection and YAML-driven methods includes: Parse the test case data in the structured data configuration file into structured data objects; The structured data object is serialized to obtain test case data in string form; The method call placeholder in the string is identified by regular expression matching. The placeholder contains the name and parameters of the method to be called. The method dynamically invokes a preset logic function corresponding to the method name using reflection. The preset logic function includes functions for reading environment configuration, calculating cryptographic signatures, generating random numbers and timestamps, and the return value of the logic function replaces the placeholder. After replacing the placeholders in the request address, request header, request parameters, and request body in the test case data, construct and send an HTTP request to obtain the interface response; Select the corresponding parser to extract the associated parameters based on the data type of the interface response; The extracted associated parameters are stored in the session-level associated variable storage area, so that subsequent use cases can read and inject them through the placeholders called by the method.

[0006] Further, the step of selecting the corresponding parser to extract associated parameters based on the data type of the interface response includes: When the Content-Type of the interface response is in JSON format, the target field is extracted using the JSONPath expression; When the Content-Type of the interface response is HTML or TEXT format, regular expressions are used to extract the target fields.

[0007] Furthermore, it also includes: Assertion validation is performed on a specified field of the interface response. The assertion validation includes at least one of the following types to perform multi-dimensional validation on the same field: The equals assertion is used to perform exact value matching on the field. The contains assertion is used to verify whether the field contains a specified value. The not_contains assertion is used to check whether the field does not contain a specified value. The not_contains assertion distinguishes between cases where a field exists but has an empty value and cases where the field does not exist. It is considered a failure when the field exists and has a non-empty value, and a success when the field does not exist.

[0008] Furthermore, it also includes: Parse the parameterized definition block in the structured data configuration file, the parameterized definition block containing at least one column name defined in the first row and test data in subsequent rows; Identify column name reference placeholders in the use case template, wherein the format of the placeholder is “$ddt{column name}”; Replace the column name reference placeholders with the test data row by row to generate multiple independent parameterized test cases.

[0009] Furthermore, the step of dynamically invoking the preset logic function corresponding to the method name using reflection includes: The string is repeatedly matched against all method call placeholders until all placeholders are replaced. Restore the replaced string to its original data type.

[0010] Furthermore, the preset logic functions called in the method call placeholder include at least one of the following: a function to read the base URL from the environment configuration, a function to dynamically generate request headers, a function to read associated variables from the associated variable storage area, an encryption signature function, a random number generation function, and a timestamp generation function.

[0011] Furthermore, it also includes: Before each test class starts, clear the historical data in the associated variable storage area; After the test session ends, test result statistics are automatically collected through the hook functions of the test framework; The test result statistics will be pushed through at least one notification channel.

[0012] Furthermore, the automatic collection of test result statistics through the hook functions of the testing framework includes: Collect at least one of the following data using the terminal_summary hook in the pytest framework: total number of test cases, number of passed cases, number of failed cases, number of skipped cases, number of errors, execution time, and success rate. The notification channels include at least one of DingTalk robot, WeChat Work robot, and email.

[0013] Furthermore, it also includes: When starting the test, the corresponding report generation tool path is automatically selected based on the current operating system type; When executing multiple test cases concurrently, a file lock mechanism is used to protect the write operation of test results, preventing data corruption caused by simultaneous writes by multiple processes.

[0014] According to another aspect of the present invention, an automated interface testing system based on hot-loading reflection and YAML-driven methods is provided; This automated interface testing system, based on hot-loading reflection and YAML-driven architecture, includes... The parsing module is used to parse test case data in the structured data configuration file into structured data objects; The hot-loading reflection module is used to serialize the structured data object to obtain test case data in string form. It identifies method call placeholders in the string through regular expression matching, dynamically calls the preset logic function corresponding to the method name in the placeholder using the reflection mechanism, and replaces the placeholder with the return value of the logic function. The hot-loading reflection module performs loop matching and replacement on all placeholders in the request address, request header, request parameters, and request body of the test case data, and restores the replaced string to the original data type. The request sending module is used to construct and send HTTP requests based on the test case data after the replacement is completed, and to obtain the interface response; The associated variable extraction module is used to select the corresponding parser to extract associated parameters according to the data type of the interface response, and store the extracted associated parameters in the session-level associated variable storage area for subsequent use cases to read and inject through the method call placeholder.

[0015] The beneficial effects of this invention are as follows: By employing a hot-loading reflection mechanism, structured data test case files are enabled to dynamically call logical functions, allowing testers to complete all configurations for complex authentication scenarios such as encrypted signatures and timestamp generation within the test case definition without writing any code. The design of a dual-mode extraction system using JSONPath and regular expressions, along with a session-level associated variable storage area, enables a closed-loop flow of parameter dependencies between interfaces, from response extraction to automatic injection of subsequent test cases. The construction of a three-layer assertion system—forward matching, reverse exclusion, and precise null value judgment—significantly enhances the data integrity verification capability of interface responses. A lightweight data-driven engine deeply integrated with structured data formats allows parameterized test cases to be self-describing within the test case file, eliminating the need for external libraries. Multi-environment adaptive and zero-intervention notification mechanisms automate the entire process from execution to result push, thereby significantly reducing the amount of code and maintenance costs for automated interface testing and improving testing efficiency. Attached Figure Description

[0016] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating the overall test execution process of the interface automated testing method based on hot-loading reflection and YAML-driven architecture described in this invention. Figure 2 Flowchart for hot-loading reflection replacement; Figure 3 Flowchart for automatic flow of associated variables; Figure 4 This is a system architecture diagram of the interface automated testing system based on hot-loading reflection and YAML driving as described in this invention. Detailed Implementation

[0018] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," and "counterclockwise," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limiting this invention.

[0020] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified. Furthermore, the terms "installed," "connected," and "linked" should be interpreted broadly; for example, they may refer to a fixed connection, a detachable connection, or an integral connection; they may refer to a mechanical connection or an electrical connection; they may refer to a direct connection or an indirect connection through an intermediate medium; and they may refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0021] like Figures 1 to 3 As shown in the embodiment of the present invention, the interface automated testing method based on hot-loading reflection and YAML driving includes: Parse the test case data in the structured data configuration file into structured data objects; The structured data object is serialized to obtain test case data in string form; The method call placeholder in the string is identified by regular expression matching. The placeholder contains the name and parameters of the method to be called. The method dynamically invokes a preset logic function corresponding to the method name using reflection. The preset logic function includes functions for reading environment configuration, calculating cryptographic signatures, generating random numbers and timestamps, and the return value of the logic function replaces the placeholder. After replacing the placeholders in the request address, request header, request parameters, and request body in the test case data, construct and send an HTTP request to obtain the interface response; Select the corresponding parser to extract the associated parameters based on the data type of the interface response; The extracted associated parameters are stored in the session-level associated variable storage area, so that subsequent use cases can read and inject them through the placeholders called by the method.

[0022] According to an embodiment of the present invention, the interface automated testing method based on hot-loading reflection and YAML-driven interface, in a specific implementation, includes selecting the corresponding parser to extract associated parameters based on the data type of the interface response, which includes: When the Content-Type of the interface response is in JSON format, the target field is extracted using the JSONPath expression; When the Content-Type of the interface response is HTML or TEXT format, regular expressions are used to extract the target fields.

[0023] The interface automation testing method based on hot-loading reflection and YAML driving according to an embodiment of the present invention further includes, in a specific implementation: Assertion validation is performed on a specified field of the interface response. The assertion validation includes at least one of the following types to perform multi-dimensional validation on the same field: The equals assertion is used to perform exact value matching on the field. The contains assertion is used to verify whether the field contains a specified value. The not_contains assertion is used to check whether the field does not contain a specified value. The not_contains assertion distinguishes between cases where a field exists but has an empty value and cases where the field does not exist. It is considered a failure when the field exists and has a non-empty value, and a success when the field does not exist.

[0024] The interface automation testing method based on hot-loading reflection and YAML driving according to an embodiment of the present invention further includes, in a specific implementation: Parse the parameterized definition block in the structured data configuration file, the parameterized definition block containing at least one column name defined in the first row and test data in subsequent rows; Identify column name reference placeholders in the use case template, wherein the format of the placeholder is “$ddt{column name}”; Replace the column name reference placeholders with the test data row by row to generate multiple independent parameterized test cases.

[0025] According to an embodiment of the interface automation testing method based on hot-loading reflection and YAML-driven architecture described in this invention, in a specific implementation, the step of dynamically invoking a pre-defined logic function corresponding to the method name using reflection includes: The string is repeatedly matched against all method call placeholders until all placeholders are replaced. Restore the replaced string to its original data type.

[0026] According to an embodiment of the present invention, the interface automation testing method based on hot-loading reflection and YAML-driven interface, in a specific implementation, includes at least one of the following preset logic functions called in the method call placeholder: a function to read the base URL from the environment configuration, a function to dynamically generate request headers, a function to read associated variables from the associated variable storage area, an encryption signature function, a random number generation function, and a timestamp generation function.

[0027] The interface automation testing method based on hot-loading reflection and YAML driving according to an embodiment of the present invention further includes, in a specific implementation: Before each test class starts, clear the historical data in the associated variable storage area; After the test session ends, test result statistics are automatically collected through the hook functions of the test framework; The test result statistics will be pushed through at least one notification channel.

[0028] According to an embodiment of the present invention, the interface automation testing method based on hot-loading reflection and YAML-driven architecture, in a specific implementation, includes automatically collecting test result statistics through hook functions of the testing framework, comprising: Collect at least one of the following data using the terminal_summary hook in the pytest framework: total number of test cases, number of passed cases, number of failed cases, number of skipped cases, number of errors, execution time, and success rate. The notification channels include at least one of DingTalk robot, WeChat Work robot, and email.

[0029] The interface automation testing method based on hot-loading reflection and YAML driving according to an embodiment of the present invention further includes, in a specific implementation: When starting the test, the corresponding report generation tool path is automatically selected based on the current operating system type; When executing multiple test cases concurrently, a file lock mechanism is used to protect the write operation of test results, preventing data corruption caused by simultaneous writes by multiple processes.

[0030] Secondly, such as Figure 4As shown in the embodiment of the present invention, the interface automated testing system based on hot-loading reflection and YAML-driven interface includes: The parsing module is used to parse test case data in the structured data configuration file into structured data objects; The hot-loading reflection module is used to serialize the structured data object to obtain test case data in string form. It identifies method call placeholders in the string through regular expression matching, dynamically calls the preset logic function corresponding to the method name in the placeholder using the reflection mechanism, and replaces the placeholder with the return value of the logic function. The hot-loading reflection module performs loop matching and replacement on all placeholders in the request address, request header, request parameters, and request body of the test case data, and restores the replaced string to the original data type. The request sending module is used to construct and send HTTP requests based on the test case data after the replacement is completed, and to obtain the interface response; The associated variable extraction module is used to select the corresponding parser to extract associated parameters according to the data type of the interface response, and store the extracted associated parameters in the session-level associated variable storage area for subsequent use cases to read and inject through the method call placeholder.

[0031] To facilitate understanding of the above technical solutions of the present invention, the following detailed explanation of the above technical solutions and principles is provided.

[0032] In automated API testing scenarios for microservice architectures, the system under test typically contains multiple business modules (such as retrieval module A, information module B, statistics module C, etc.), and authentication dependencies exist between the interfaces of each module (such as unified token authentication), with response formats potentially being JSON or HTML. The testing team needs to complete the entire process description from request definition, dynamic parameter generation, interface association to result assertions in the YAML test case file, avoiding the need to write Python test code for each interface.

[0033] This invention addresses the aforementioned scenarios by proposing an automated interface testing method and system based on hot-loading reflection and YAML-driven approaches. Its core innovation lies in a "five-in-one" combined design: a layered decoupled architecture + a hot-loading reflection programmable engine + dual-mode automatic flow of interface-related variables + a three-layer assertion system + multi-environment adaptive operation assurance, enabling automated interface testing to achieve zero-code intervention across the entire chain, from test case definition to result notification.

[0034] The interface automation testing method based on hot-loading reflection and YAML-driven architecture described in this invention specifically includes the following steps: 1. After the test starts, the report tool path is automatically selected based on the operating system type to ensure seamless switching between the Windows development environment and the Linux CI environment.

[0035] 2. After initializing the environment configuration, clear the context storage area of ​​the associated variables to avoid the influence of residual data from the previous test.

[0036] 3. After the pytest execution engine starts, it reads the YAML test case files one by one. If the file contains the parameterize keyword, it first performs data-driven parsing to generate multiple test cases; otherwise, it directly parses a single test case.

[0037] 4. Perform hot-reload reflection replacement on all "${function(args)}" placeholders in YAML, and fill the test case data with the results of dynamic logic function calls.

[0038] 5. After the replacement is complete, send an HTTP request. Based on the response Content-Type, use JSONPath or regular expressions to extract the associated variables and write them to the associated variable context storage area.

[0039] 6. Perform three-level assertion checks (equals / contains / not_contains) and record the results in Allure.

[0040] 7. After all test cases have been executed, collect and statistically analyze the results, generate a report, and push notifications via DingTalk, WeChat Work, and email.

[0041] The hot-loading reflection replacement process is as follows: 1. Serialize the dictionary / list data parsed from YAML into a string representation.

[0042] 2. Match placeholders in the format "${function_name(args)}" using regular expressions.

[0043] 3. After extracting the function name and parameters, use Python's "getattr(DebugTalk(), function_name)" reflection mechanism to dynamically call the corresponding method in the hot-loaded function set.

[0044] 4. Replace the placeholders in the string with the function's return value, and then continue the loop matching until all placeholders have been replaced.

[0045] 5. Finally, restore the string to its original data type (dictionary / list / string) and return the replaced data.

[0046] This mechanism enables YAML use cases to be "programmable": dynamic logic such as cryptographic signing, timestamp generation, configuration reading, and variable extraction can be called directly in YAML without writing any Python code.

[0047] The automatic transfer of related variables is detailed below: 1. After receiving a response from the API request, determine the response format based on the Content-Type.

[0048] 2. JSON responses are extracted using JSONPath (supports expressions such as "$.data.token", which retrieves the first element for a single value and returns the complete list for multiple values); HTML / TEXT responses are extracted using regular expressions (supports "'(.*?)'" capture groups).

[0049] 3. The extracted results are constructed into a key-value pair dictionary and appended to the context storage area of ​​the associated variables (such as the extract.yaml file).

[0050] 4. Subsequent YAML use cases are automatically injected in two ways: (a) “${get_extract_data(token)}” is directly referenced in the request parameters; (b) “${get_headers('Content-Type')}” automatically replaces the “${token}” placeholder in the Headers with the actual value in the context storage area of ​​the associated variable.

[0051] 5. The entire process, from extraction to injection, is fully automated, enabling automatic flow of interface-related variables across the entire chain.

[0052] The interface automated testing system based on hot-loading reflection and YAML-driven architecture described in this invention specifically includes the following modules; Operation control layer Test startup module: As the unified entry point of the framework, it automatically selects the report tool path based on the operating system type (using .bat for Windows and / bin for Linux), calls the pytest execution engine, and switches between Allure or HTML report generation mode according to the configuration.

[0053] Report generation module: After execution, it extracts detailed interface test data (interface name, request method, status, response time) from the Allure temporary JSON file and generates a concise HTML email report; it also customizes the Allure report title and category.

[0054] Notification push module: Supports parallel push from three sources: DingTalk robot (HMAC-SHA256 signature authentication), WeChat Work robot (Markdown format), and email (HTML body + attachment). It is automatically triggered by the pytest hook and does not require manual invocation.

[0055] Global Hook Layer Environment initialization module: Automatically disables HTTPS alarms and initializes the global variable dictionary when the test session starts.

[0056] Results collection module: Automatically collects total number of test cases, number of passed cases, number of failed cases, number of skipped cases, number of errors, execution time and success rate through the pytest_terminal_summary hook, and triggers notification push.

[0057] Related data cleanup module: Automatically clears the context storage area of ​​related variables before each test class starts, to prevent residual data from the previous test from affecting the current test.

[0058] Test case layer Test case execution engine: The test case data parsed from YAML is parameterized and passed to the test method through the pytest.mark.parametrize decorator, and the core parsing engine is called to execute the test cases.

[0059] Allure annotation module: Uses a three-level annotation system of @allure.epic / feature / story to classify test cases hierarchically, and dynamically sets the test case title through allure.dynamic.title.

[0060] Number generator: Adopting the Python generator (yield) pattern, it implements automatic incrementing and global uniqueness of three-level numbering: S (session level), M (module level), and C (use case level).

[0061] Core parsing engine layer YAML test case parsing module: Performs specification validation on YAML test cases (must contain four first-level keywords: name, base_url, request, and validate; request must contain two second-level keywords: method and url), and distributes them to subsequent modules such as hot reloading, request sending, and assertion validation.

[0062] The hot-loading reflection module (core innovation) serializes YAML data into a string, matches the placeholder "${function_name(args)}" using regular expressions, and dynamically calls the corresponding function in the hot-loading function layer using Python reflection's "getattr()" mechanism, thus achieving YAML programmability. It supports nested replacement (looping through all ${} placeholders) and automatically restores the data type (dict / list / str).

[0063] Request sending module: Implements automatic session-level cookie management based on requests.Session, performs hot reloading and replacement of base_url / url / headers / params / data / json before sending requests, and supports timeout configuration and SSL verification control.

[0064] The associated variable extraction module (core innovation) processes variables in two ways based on the response Content-Type: JSON responses are extracted using JSONPath (supporting single-value and multi-value extraction), while HTML / TEXT responses are extracted using regular expressions. The extracted results are appended to the associated variable context storage area (such as the extract.yaml file) for subsequent use cases to automatically read and inject via a hot-loading function.

[0065] The assertion validation module implements three assertion types: equals, contains, and not_contains. It supports JSONPath mode (a combination of field existence and value inclusion) and plain text mode. The not_contains module handles null value checks specially. This module supports multi-dimensional composite assertions on the same response field, including independent or combined checks on field existence, data type, exact value, inclusion relationship, and null value status. Particularly for reverse assertions, when the preset expected value is null, the judgment logic is "failure if the field exists and its value is not null," unlike the conventional "success if the field does not exist."

[0066] Data-driven parsing module: Parses the parameterize keyword in YAML. The first row is the column name, and the subsequent rows are the data. It generates multiple test cases by cyclically replacing the placeholder "$ddt{column_name}" and automatically removes quotes from int / float types.

[0067] Tool encapsulation layer HTTP request encapsulation: Unified encapsulation of the requests library, class-level Session reuse.

[0068] YAML read / write wrapper: Provides methods for reading second-level nodes of config.yaml, reading and writing context storage areas of associated variables (such as extract.yaml files), and clearing them.

[0069] Log encapsulation: dual-channel output including console colorlog and file log. Log levels are dynamically read from the configuration file, and error levels automatically throw assertion exceptions.

[0070] Database encapsulation: Supports both MySQL and Oracle drivers, provides single-row queries, multiple queries, and CRUD operations, and uses DictCursor to return dictionary-formatted results.

[0071] Allure report encapsulation: Supports modifying report titles, custom categories, and extracting API data from temporary JSON, implementing a 5-level strategy for request extraction.

[0072] Persistent encapsulation of results: FileLock is used to protect concurrent write safety and intelligently merge interface data with the same name.

[0073] Hot-load function layer Dynamic configuration function set: including get_base_url (reads the base URL from the environment configuration), get_headers (dynamically retrieves request headers and automatically replaces token placeholders), and get_extract_data (reads variable values ​​from the associated variable context store).

[0074] Encryption signature function set: including md5_encode, base64_encode / decode, sha1_encode, rsa_public_secret (RSA public key encryption), and signs (interface signature calculation, including dictionary ASCII sorting).

[0075] Variable extraction function set: including get_random_number (random integer generation) and timestamp (timestamp generation).

[0076] Configuration layer Environment configuration: Store URLs for multiple environments (internal network testing environment, production environment, and third-party environment), and dynamically select them through a hot-reload function.

[0077] Headers configuration: Defines the default request header template, including a token placeholder, which is automatically replaced with the actual value by the get_headers function.

[0078] The context storage area for associated variables (such as the extract.yaml file) stores interface associated variables (such as token, session_id, etc.), which are appended by the extraction module, read and injected by the hot-loading function, and cleared by the cleanup module at the start of the session.

[0079] The key technical parameters involved in this invention are shown in the table below (Table 1):

[0080] Table 1: Key Technical Parameters Furthermore, although the specific embodiments of this invention are based on the Python + YAML technology stack, the core mechanism is also applicable to other technology stacks, as shown in the following variations: Programming language variants Although the implementation is based on Python, the core mechanism is also applicable to the following languages: Java variant: Combines SnakeYAML to parse YAML, uses Java reflection mechanism "Method.invoke()" to call dynamic methods, and hot-loaded function sets can be defined as a Java class, and reflection calls are implemented through "Class.forName()" and "getDeclaredMethod()".

[0081] Go variant: Combined with "gopkg.in / yaml.v3", it uses Go's "reflect" package to implement dynamic method calls, and hot-loaded function sets can be registered as a function map (map[string]func).

[0082] Other languages ​​that support metaprogramming and reflection, such as C# (using System.Reflection), Ruby (using the send method), and PHP (using call_user_func), can all implement the core mechanism of this invention.

[0083] Data format variants The core concept is not limited to YAML, but can also be extended to: JSON format: Use JSON Schema to define the test case structure, modify the placeholder format to a way that is suitable for JSON syntax (such as "${{func()}}"), and adjust the other serialization, matching and replacement logic accordingly.

[0084] XML format: Use XML tags to define the use case structure. Placeholders can be embedded through XML attributes or CDATA sections. The parsing engine is adapted to XML DOM operations.

[0085] For other structured data formats such as TOML / INI, only the serialization, placeholder regular expression matching, and data type restoration logic need to be modified accordingly.

[0086] Storage media variants Intermediate storage for correlated variables is not limited to the extract.yaml file; it can also be: Memory caching: such as Python's dict, Java's ConcurrentHashMap, Go's sync.Map, etc., are suitable for single-process high-concurrency scenarios and offer faster read and write speeds.

[0087] Databases: Key-value storage systems such as SQLite, MySQL, and Redis are suitable for distributed testing scenarios where multiple machines share related variables.

[0088] Distributed caching: such as Redis and Memcached, supports sharing of related variables across processes and machines.

[0089] Its core lies in the automatic flow logic of "extraction-storage-injection", and the choice of storage medium does not affect the implementation of this core mechanism.

[0090] Placeholder syntax variants The placeholder format is not limited to "${function_name(args)}", it can also be designed as: "{{func()}}": Double curly braces syntax, commonly found in template engines.

[0091] "#func()": The hash symbol prefix syntax is concise and intuitive.

[0092] "<%func()%>": Angle bracket percent sign syntax, similar to JSP / ERB templates.

[0093] Other custom syntax: As long as the parsing engine can recognize and process it, the placeholder format itself does not constitute a limitation on the scope of protection.

[0094] Assertion type extended variant The three-layer assertion system can be expanded to more dimensions: Add data type assertions (such as validating whether a field value is int / str / list / dict).

[0095] Add regular expression matching assertions (such as validating whether field values ​​match regular expression patterns like phone number or email address).

[0096] Add range assertions (such as validating whether a field value is within a specified range).

[0097] Add JSON Schema assertions (such as verifying whether the overall response structure conforms to a predefined schema).

[0098] These extensions are all extensions of the three-layer assertion system and do not depart from the scope of protection of this invention.

[0099] Example 1: Automated testing of an information retrieval platform interface Application Scenario: An information retrieval platform includes multiple business modules such as retrieval module A, information module B, and statistics module C. All interfaces use unified token authentication, with some interfaces responding in JSON format and others in HTML format. The testing team needs to define the entire process from obtaining the token upon login to testing the interfaces of multiple modules in the YAML test case file.

[0100] Given conditions: The platform comprises 6 business modules and a total of over 200 interfaces. Mixed API response formats (JSON + HTML) The authentication method is Bearer Token. Some interfaces require MD5 signatures and RSA encryption. System Flow Summary: 1. Test starts, automatically selects the Linux path (CI environment), and clears the context storage area of ​​associated variables.

[0101] 2. Execute the login interface YAML test case: "${get_base_url(base_api_pro_url)}" dynamically selects the production environment URL, and "${get_headers('Content-Type')}" automatically retrieves the request headers.

[0102] 3. The login response is in JSON format. The token is automatically extracted via JSONPath “$.data.token” and written to the context storage area of ​​the associated variable (such as the extract.yaml file).

[0103] 4. In subsequent YAML test cases, “${get_headers('Content-Type')}” will automatically replace “${token}” in the Headers with the actual token value in the context storage area of ​​the associated variable.

[0104] 5. Some interfaces use "${md5_encode(args)}" and "${rsa_public_secret(args)}" to directly call the encryption signature function in YAML.

[0105] 6. Assertions cover positive (equals to check status_code, contains to check message) and negative (not_contains to check if a field is not null).

[0106] 7. After all test cases have been executed, the pytest hook automatically collects the results and pushes a DingTalk notification, including a link to the Allure report.

[0107] Technical effects (quantitative data): Development efficiency: For a typical project with more than 200 interfaces, after using this invention, the test case writing time is reduced from the traditional average of 8 person-days (requiring Python code writing) to 2 person-days (only YAML file writing), improving efficiency by about 75%.

[0108] Code volume: The test case code volume (non-YAML data) has been reduced from approximately 5,000 lines of Python code to almost zero, and the core framework code has been reused.

[0109] Maintenance cost: Because the interface-related variables are automatically transferred, when the interface changes, the number of test case lines that need to be maintained is reduced from an average of 10 lines of code per interface to 2 lines of YAML configuration, reducing the maintenance workload by about 80%.

[0110] Execution efficiency: The average time for hot-load reflection replacement is less than 5ms per test case, and its impact on the total execution time of the entire test suite (200 test cases) is negligible (<1 second).

[0111] Notification timeliness: The delay from the completion of the test to the push of the notification is less than 3 seconds, achieving near real-time notification.

[0112] Example of parameter settings (not intended to limit the scope of the claims): API_TIMEOUT: 30 seconds (to prevent the API from freezing and causing the test to stop). REPORT_TYPE: allure FileLock timeout: 10 seconds (to ensure concurrency safety) Number generator range: S01-S999, M01-M999, C01-C999 Example 2: Parallel Testing in Multiple Environments Application scenario: The same set of YAML test cases needs to be validated in three environments: development environment (internal IP), testing environment (internal IP), and production environment (public domain name).

[0113] System Flow Summary: 1. Configure the base_url for the three environments in config.yaml.

[0114] 2. In YAML use cases, use hot-reload calls such as "${get_base_url(base_api_api_url)}" and "${get_base_url(base_api_pro_url)}" to dynamically select the environment URL.

[0115] 3. Different interface modules can mix and call URLs from different environments within the same test suite, adapting to microservice architectures.

[0116] 4. In the Windows development environment, Allure is started using the .bat path, and in the Linux CI environment, it is started using the / bin path. No code modification is required.

[0117] Technical effects: The same YAML test case can be adapted to three environments, with environment adaptation costs approaching zero simply by switching function parameters through hot reloading. Cross-environment hybrid calls support microservice architecture testing, with a single test case covering verification across multiple environments. Operating system adaptive, zero-configuration switching between development and CI environments, improving environment switching efficiency by over 90%. Example 3: Data-Driven Batch Testing Application scenario: An interface needs to use a large amount of test data for boundary value and equivalence class testing. Traditionally, this requires writing multiple sets of Python code or external data files.

[0118] System Flow Summary: 1. Use the parameterize keyword in YAML use cases to define a two-dimensional data table.

[0119] 2. Use the "$ddt{column_name}" placeholder to reference column names in the test case template, and the parsing engine will generate multiple independent test cases by iterating through and replacing them.

[0120] 3. Automatically remove quotes from int / float types to ensure data type consistency with interface expectations.

[0121] 4. Each generated test case is executed, asserted, and its results are recorded independently.

[0122] Technical effects: Parameterized use cases are self-describing in YAML, requiring no external data files or Python code, and improving parameterization efficiency by more than 5 times. Automatic conversion between int and float types avoids assertion failures due to data type mismatch, reducing type-related false positives by 95%.

[0123] In summary, by utilizing the technical solutions described above, the structured data test case files are enabled to dynamically call logical functions through a hot-loading reflection mechanism. This allows testers to complete all configurations for complex authentication scenarios such as encrypted signatures and timestamp generation within the test case definition without writing any code. The design of a dual-mode extraction system using JSONPath and regular expressions, along with a session-level associated variable storage area, enables a closed-loop flow of parameter dependencies between interfaces, from response extraction to automatic injection of subsequent test cases. The construction of a three-layer assertion system—forward matching, reverse exclusion, and precise null value judgment—significantly enhances the data integrity verification capability of interface responses. A lightweight data-driven engine deeply integrated with structured data formats allows parameterized test cases to be self-describing within the test case file, eliminating the need for external libraries. Furthermore, a multi-environment adaptive and zero-intervention notification mechanism automates the entire testing framework process from execution to result push, thereby significantly reducing the amount of code and maintenance costs for automated interface testing and improving testing efficiency.

[0124] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions 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. An automated interface testing method based on hot-loading reflection and YAML-driven methods, characterized in that, include: Parse the test case data in the structured data configuration file into structured data objects; The structured data object is serialized to obtain test case data in string form; The method call placeholder in the string is identified by regular expression matching. The placeholder contains the name and parameters of the method to be called. The method dynamically invokes a preset logic function corresponding to the method name using reflection. The preset logic function includes functions for reading environment configuration, calculating cryptographic signatures, generating random numbers and timestamps, and the return value of the logic function replaces the placeholder. After replacing the placeholders in the request address, request header, request parameters, and request body in the test case data, construct and send an HTTP request to obtain the interface response; Select the corresponding parser to extract the associated parameters based on the data type of the interface response; The extracted associated parameters are stored in the session-level associated variable storage area, so that subsequent use cases can read and inject them through the placeholders called by the method.

2. The automated interface testing method based on hot-loading reflection and YAML-driven interface as described in claim 1, characterized in that, The step of selecting the corresponding parser to extract associated parameters based on the data type of the interface response includes: When the Content-Type of the interface response is in JSON format, the target field is extracted using the JSONPath expression; When the Content-Type of the interface response is HTML or TEXT format, regular expressions are used to extract the target fields.

3. The automated interface testing method based on hot-loading reflection and YAML-driven approach according to claim 1, characterized in that, Also includes: Assertion validation is performed on specified fields of the interface response, and the assertion validation includes at least one of the following types to perform multi-dimensional validation on the same field: The equals assertion is used to perform exact value matching on the field. The contains assertion is used to verify whether the field contains a specified value. The not_contains assertion is used to check whether the field does not contain a specified value. The not_contains assertion distinguishes between cases where a field exists but has an empty value and cases where the field does not exist. It is considered a failure when the field exists and has a non-empty value, and a success when the field does not exist.

4. The automated interface testing method based on hot-loading reflection and YAML-driven interface as described in claim 1, characterized in that, Also includes: Parse the parameterized definition block in the structured data configuration file, the parameterized definition block containing at least one column name defined in the first row and test data in subsequent rows; Identify column name reference placeholders in the test case template, wherein the placeholders are in the format "$ddt{column name}"; Replace the column name reference placeholders with the test data row by row to generate multiple independent parameterized test cases.

5. The automated interface testing method based on hot-loading reflection and YAML-driven interface as described in claim 1, characterized in that, The method of dynamically invoking a preset logic function corresponding to the method name using reflection includes: The string is matched in a loop for all method call placeholders until all placeholders are replaced. Restore the replaced string to its original data type.

6. The automated interface testing method based on hot-loading reflection and YAML-driven interface as described in claim 1, characterized in that, The preset logic functions called in the method call placeholder include at least one of the following: a function to read the base URL from the environment configuration, a function to dynamically generate request headers, a function to read associated variables from the associated variable storage area, an encryption signature function, a random number generation function, and a timestamp generation function.

7. The automated interface testing method based on hot-loading reflection and YAML-driven interface as described in claim 1, characterized in that, Also includes: Before each test class starts, clear the historical data in the associated variable storage area; After the test session ends, test result statistics are automatically collected through the hook functions of the test framework; The test result statistics will be pushed through at least one notification channel.

8. The automated interface testing method based on hot-loading reflection and YAML-driven interface as described in claim 7, characterized in that, The automatic collection of test result statistics through the hook functions of the testing framework includes: Collect at least one of the following data using the terminal_summary hook in the pytest framework: total number of test cases, number of passed cases, number of failed cases, number of skipped cases, number of errors, execution time, and success rate. The notification channels include at least one of DingTalk robot, WeChat Work robot, and email.

9. The automated interface testing method based on hot-loading reflection and YAML-driven interface as described in claim 1, characterized in that, Also includes: When starting the test, the corresponding report generation tool path is automatically selected based on the current operating system type; When executing multiple test cases concurrently, a file lock mechanism is used to protect the write operation of test results, preventing data corruption caused by simultaneous writes by multiple processes.

10. An automated interface testing system based on hot-loading reflection and YAML-driven architecture, characterized in that, include: The parsing module is used to parse test case data in the structured data configuration file into structured data objects; The hot-loading reflection module is used to serialize the structured data object to obtain test case data in string form. It identifies method call placeholders in the string through regular expression matching, dynamically calls the preset logic function corresponding to the method name in the placeholder using the reflection mechanism, and replaces the placeholder with the return value of the logic function. The hot-loading reflection module performs loop matching and replacement on all placeholders in the request address, request header, request parameters, and request body of the test case data, and restores the replaced string to the original data type. The request sending module is used to construct and send HTTP requests based on the test case data after the replacement is completed, and to obtain the interface response; The associated variable extraction module is used to select the corresponding parser to extract associated parameters according to the data type of the interface response, and store the extracted associated parameters in the session-level associated variable storage area for subsequent use cases to read and inject through the method call placeholder.

Images