Environment separation method based on Root Framework interface automation framework, medium and equipment

Abstract

The invention belongs to the technical field of software testing, and provides an environment separation method based on a Root Framework interface automation framework, a medium and equipment. The method comprises the following steps: S1, constructing a public module and a system hierarchical structure; s2, system update maintenance design: when the system is updated and maintained, only configuration data in a specific environment in a specific system needs to be changed; s3, designing flexibility and expandability; s4, test framework content filling and implementation; and S5, implementation and verification. According to the invention, the method has the advantages of high maintainability, easy expansion, high flexibility, simplified management and Root Framework, can improve the flexibility, maintainability and reusability of the test, and provides better support for the expansion and configuration management of the framework, thereby enabling the automatic test of the interface to be more efficient and reliable.

Description

Technical Field

[0001] This invention belongs to the field of software testing technology, specifically, it relates to an environment separation method, medium, and device based on the Robot Framework interface automation framework. Background Technology

[0002] Robot Framework is a general-purpose automated testing framework whose flexibility and scalability make it an ideal choice for automated interface testing.

[0003] In terms of environment: In actual software development, there are usually multiple different environments, such as development, testing, pre-release, and production environments. Automated interface testing for different environments is a very common requirement, therefore a flexible framework is needed to support the execution of test cases in different environments.

[0004] In terms of configuration management: API automated testing requires managing various configuration information, such as API addresses, authentication information, and database connections. This configuration information may differ in different environments, therefore a mechanism is needed to manage and switch these configurations.

[0005] Based on the above factors, when conducting automated interface testing, it is necessary to consider the management and switching of configurations such as interface addresses and authentication information under different environments, which necessitates environment separation. To meet the needs of practical automated interface testing, the Robot Framework provides rich functionality and flexible extensibility, making environment separation possible. By properly utilizing the features of the Robot Framework, the environment separation problem in automated interface testing can be effectively solved, thereby improving the flexibility and maintainability of the testing.

[0006] Currently, the known technology distinguishes system environments by reading YAML configuration files. However, this approach has certain limitations and cannot be reused for various projects. If a company contains multiple systems, storing the environment addresses and variable data of each system in the same configuration file will cause data redundancy and is not conducive to the daily maintenance of individual systems. Summary of the Invention

[0007] The purpose of this invention is to provide an environment separation method based on the Robot Framework interface automation framework, so as to solve the technical problems existing in the prior art.

[0008] To achieve the above objectives, the technical solution adopted by the present invention is as follows: An environment separation method based on the Robot Framework interface automation framework includes: Step S1: Construct common modules and system layering structure, as follows: Step S1.1: Determine the common modules and system layering principles, and encapsulate common operations into common keywords based on API functions; Step S1.2: Create a dataCollection layer to store system environment configuration information, and manage the configuration parameters of different environments through independent environment variable files; Step S1.3: Create a data layer to store the file resources required for test execution; Step S1.4: Create an interface layer to encapsulate and manage custom keywords; Step S1.5: Create a testcase layer to organize and store test cases; Step S2: Store each environment configuration independently in the dataCollection layer, and dynamically load the corresponding configuration based on the environment identifier; Step S3: Decouple the execution logic of the test suite from the environment-specific configuration file to achieve dynamic association and control between test execution and environment configuration; Step S4: Fill in the environment configuration data, test resources, encapsulation keywords and test cases in each layer to build a complete and executable test framework; Step S5: Deploy the system layered structure in an actual project, and execute test cases by switching environment identifiers to verify its portability in multiple environments.

[0009] Preferably, in step S1.2, the environment variable file is a Python file or a YAML file, and the configuration parameters include at least one of server address, database connection information, and API endpoint.

[0010] Preferably, in step S2, the specific method for dynamically loading the configuration is as follows: specify the environment tag through Robot Framework command line parameters or configuration file, and automatically load the variable file under the corresponding tag directory in the dataCollection layer when the test is executed.

[0011] Preferably, the specific method in step S3 is as follows: By setting the variable file path through the Robot Framework command-line options or in the test suite initialization file, the target environment configuration file loaded at runtime is specified, so that the test cases can dynamically obtain the parameters of the environment.

[0012] Preferably, step S3 further includes: creating test suite tags or metadata corresponding to different environments, executing them through Robot Framework's filtering, and automatically running the associated set of test cases according to the selected environment.

[0013] Preferably, in step S4, the keywords encapsulated in the interface layer include: API request construction, response data parsing, database operation, and result assertion.

[0014] Preferably, in step S4, the test cases written in the testcase layer complete the interface testing steps by calling keywords in the interface layer and combining test data files in the data layer.

[0015] To achieve the above objectives, the present invention also provides a computer-readable storage medium having a computer program stored thereon, characterized in that the computer program, when executed by a processor, implements the RobotFramework interface-based automated framework environment separation method as described above.

[0016] To achieve the above objectives, the present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor, when executing the computer program, implements the Robot Framework interface-based automation framework environment separation method as described above.

[0017] Compared with the prior art, the present invention has the following beneficial effects: (1) According to the present invention, the same data information is extracted into a common interface, and the modular design according to the system layer makes maintenance simpler and clearer. Each module has a clear responsibility and boundary, reducing coupling.

[0018] (2) According to the present invention, new functions can be easily added or existing functions can be modified through the hierarchical structure without large-scale code reconstruction.

[0019] (3) According to the present invention, by configuring specific data (dataCollection layer) for different environments, the corresponding configuration information can be loaded when the test suite is executed in different environments. This enables the system to flexibly adapt to different deployment environments.

[0020] (4) According to the present invention, only the configuration data in a specific environment of a specific system needs to be changed, which will not affect the availability of other project systems and reduces the risk introduced by environmental changes.

[0021] (5) According to the present invention, by utilizing the variable file and keyword parameterization function of Robot Framework, flexible control and reuse of test suites and configuration files can be achieved, thereby improving the readability and maintainability of test scripts.

[0022] (6) According to the present invention, Robot Framework can easily read and use environment variables, simplifying the process of executing test cases in different environments and improving the reliability of test cases.

[0023] (7) According to the present invention, when the system is updated and maintained, only the configuration data under a specific environment needs to be modified, without changing the overall data file, which reduces maintenance costs and workload.

[0024] (8) According to the present invention, the flexibility, maintainability and reusability of testing can be improved, and better support is provided for the expansion and configuration management of the framework, thereby making interface automation testing more efficient and reliable. Attached Figure Description

[0025] Figure 1 This is a flowchart of Embodiment 1 of the present invention.

[0026] Figure 2 This is a principle block diagram of Embodiment 3 of the present invention. Detailed Implementation

[0027] To enable those skilled in the art to have a clearer understanding of the present invention, the present invention will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described below are merely for illustrative purposes and to facilitate understanding. The technical solutions provided by the present invention are not limited to those provided in the following embodiments, nor should they limit the scope of protection of the present invention.

[0028] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the shape, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0029] Example 1 This embodiment provides an environment separation method based on the Robot Framework interface automation framework. This method considers the different environments existing in different systems and uses a common module + system layering principle to extract common data information into a common interface. Each project system includes a dataCollection layer to store the system's own environment configuration information, a data layer to store files needed to execute test cases, an interface layer to store custom keywords, and a testcase layer to store the executed test cases. The dataCollection layer stores specific data required for executing test cases in the form of environments. Subsequent system updates and maintenance only require changing the configuration data of the specific environment within the specific system, thus avoiding changes to a unified overall data file that could affect the usability of other project systems.

[0030] The specific technical solution of the environment separation method based on the Robot Framework interface automation framework provided in this embodiment is as follows: Step S1: Construct common modules and system layering structure.

[0031] First, establish a clear hierarchical directory structure in the RobotFramework project, as shown in the example below: `common / `: A resource file named `common_utils.robot` in the `common / ` directory encapsulates cross-system common keywords such as "generate random strings" and "calculate signatures." It is imported into the `systems / system_a / interface / ` resource file using the `Resource` keyword to store common resources across different business systems, such as highly reusable keyword libraries, common utility scripts, or global configuration templates. `systems / `: Used for organizing and isolating by business system. Under it, a dedicated subdirectory is created for each independent system under test (e.g., `system_a / `, `system_b / `). Each system subdirectory uses a unified hierarchical structure, containing the following four core layers: `dataCollection / `: Environment configuration layer. Used to store configuration parameters related to the deployment environment. Subdirectories are created under it according to environment (e.g., `dev / `, `test / `, `prod / `), and each environment directory stores the corresponding configuration file (e.g., `config.yaml` or `config.py`), achieving physical isolation of configurations. `data / `: Test data and file resource layer. This layer is used to store various input data files (such as Excel, CSV, JSON) required for test case execution, as well as sample files (such as images, document templates) related to file upload / download tests. `interface / `: Custom keywords and resource layer. Used to encapsulate and store RobotFramework resource files (.robot) or custom Python libraries that implement specific test logic. These files encapsulate reusable keywords such as HTTP requests, database operations, and result assertions. `testcases / `: Test case layer. Used to organize specific test suites and test case files (.robot). This layer should have a clear structure, mainly containing a high-level description of the test logic, and driving the test by calling keywords from the `interface / ` layer and referencing data from the `data / ` layer. `resources / `: Used to store project-level public resources, such as project-wide variable definitions and basic keywords shared by multiple systems, as a supplement or specification to the `common / ` directory.

[0032] The dataCollection layer is used to store configuration parameters bound to specific environments. It creates an independent subdirectory for each environment (such as dev, test, prod) and places configuration files (such as config.yaml) in it. The configuration file format supports variable file formats that Robot Framework can recognize, such as YAML or Python files. The data layer is used to store static or dynamic data files required for test execution, such as CSV, Excel, and JSON data files, as well as images and document samples used for file upload tests, thus separating test data from scripts. Interface layer: This layer encapsulates and organizes custom keywords by creating .robot resource files. These keywords are abstractions of test logic, such as HTTP request sending, response assertions, database queries, etc. Testcase layer: This layer stores the actual test case files. Test cases should be concise, primarily calling keywords encapsulated in the interface layer and referencing data files in the data layer; Step S2: System update and maintenance and dynamic configuration loading.

[0033] Each environment configuration is stored independently in the dataCollection layer, and the corresponding configuration is dynamically loaded according to the environment identifier. In this embodiment, the specific method for dynamically loading the configuration is as follows: The environment configuration file to be used for the current execution is specified by the Robot Framework command-line parameter -variablefile. Furthermore, to achieve more flexible environment binding, in addition to directly specifying the full path using --variablefile, the configuration can also be loaded by dynamically calculating the path during the test suite initialization phase. For example: Create a Python utility script (such as env_loader.py), which parses the environment identifier according to the input parameters and returns the corresponding configuration dictionary or configuration file path; In the Robot Framework resource file or settings, import the Python module through the Library and call its function to set global variables; Before the test suite starts, call the keyword Load Environment ConfigurationDynamically; When executing the test, specify the environment through the command line: robot --variable ENV:test systems / system_a / testcases / your_suite.robot.

[0034] Step S3: Implement dynamic correlation and control between test execution and environment configuration.

[0035] The specific method for this step is as follows: Specify the target environment configuration file to be loaded at runtime by setting the variable file path through the Robot Framework's variablefile command-line option or in the test suite initialization file, enabling test cases to dynamically obtain parameters for that environment. Specific tags can be added to test cases for different environments, such as env:dev and env:prod. Combined with the --include or --exclude command-line options, only a subset of tests designed for a specific environment can be run. Furthermore, metadata association is possible; keywords such as Set Suite Variable or Set Global Variable can be used in the test suite or resource files to dynamically set metadata that controls the test flow based on the loaded configuration.

[0036] Step S4: Build a complete and executable test framework.

[0037] Each layer is populated with environment configuration data, test resources, encapsulated keywords, and test cases to build a complete and executable test framework. Specifically: The configuration file under the dataCollection layer is improved for each target environment; sufficient test data and file samples are prepared in the data layer; business keywords are continuously encapsulated and optimized in the interface layer to form a stable and reliable keyword library, with keywords covering API requests, data validation, database cleanup, complex business flow combinations, etc.; in the testcase layer, test cases are written in a highly readable manner, prioritizing data-driven approaches to improve test case coverage and maintainability.

[0038] Step S5: Implementation and verification.

[0039] Implement the above design in a specific software project. Deploy the layered system structure in the actual project and verify its portability across multiple environments by switching environment identifiers to execute test cases. Example: Implementation: Initialize the project according to the directory structure in step S1; fill in the content described in step S4 according to the actual information of each environment; write or adjust the continuous integration (CI) script (such as Jenkinsfile), in which the test execution environment is controlled through command-line parameters. Verification: On the local machine or CI server, switch the environment configuration file pointed to by `--variablefile` by executing different commands, and observe whether the same set of test cases can run successfully in different environments (such as test environment, pre-release environment) and correctly access the API and database of the corresponding environment, thereby verifying the effectiveness of the environment separation mechanism.

[0040] Through the steps described above, this invention leverages the flexibility and scalability of Robot Framework, utilizing variable files and keyword parameterization, along with test suites and configuration files, to execute different test suites in different environments and load the corresponding configuration information. Robot Framework can easily read and use environment variables, making the execution of test cases in different environments simpler and more reliable.

[0041] Example 2 This embodiment provides a computer-readable storage medium on which a computer program is stored. The computer program is executed by a processor to implement the Robot Framework interface-based automation framework environment separation method provided in Embodiment 1. Those skilled in the art will understand that all or part of the steps of the method provided in Embodiment 1 can be implemented by hardware related to the computer program. The aforementioned computer program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the method provided in Embodiment 1. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0042] Example 3 like Figure 2 As shown, this embodiment provides an electronic device, including: a processor and a memory; the memory is used to store a computer program; the processor communicates with the memory to execute the computer program stored in the memory, so that the electronic device executes the Robot Framework interface-based automation framework environment separation method provided in Embodiment 1.

[0043] Specifically, memory includes various media that can store program code, such as ROM, RAM, magnetic disks, USB flash drives, memory cards, or optical discs.

[0044] Preferably, the processor can be a general-purpose processor, including a central processing unit, a network processor, etc.; it can also be a digital signal processor, an application-specific integrated circuit, a field-programmable gate array or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component.

[0045] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.

Claims

1. An environment separation method based on the Robot Framework interface automation framework, characterized in that, include: Step S1: Construct common modules and system layering structure, as follows: Step S1.1: Determine the common modules and system layering principles, and encapsulate common operations into common keywords based on API functions; Step S1.2: Create a dataCollection layer to store system environment configuration information, and manage the configuration parameters of different environments through independent environment variable files; Step S1.3: Create a data layer to store the file resources required for test execution; Step S1.4: Create an interface layer to encapsulate and manage custom keywords; Step S1.5: Create a testcase layer to organize and store test cases; Step S2: Store each environment configuration independently in the dataCollection layer, and dynamically load the corresponding configuration based on the environment identifier; Step S3: Decouple the execution logic of the test suite from the environment-specific configuration file to achieve dynamic association and control between test execution and environment configuration; Step S4: Fill in the environment configuration data, test resources, encapsulation keywords and test cases in each layer to build a complete and executable test framework; Step S5: Deploy the system layered structure in an actual project, and execute test cases by switching environment identifiers to verify its portability in multiple environments.

2. The method for separating the automation framework environment based on the Robot Framework interface according to claim 1, characterized in that, In step S1.2, the environment variable file is a Python file or a YAML file, and the configuration parameters include at least one of server address, database connection information, and API endpoint.

3. The method for separating the automation framework environment based on the Robot Framework interface according to claim 2, characterized in that, In step S2, the specific method for dynamically loading the configuration is as follows: specify the environment tag through Robot Framework command line parameters or configuration file, and automatically load the variable file under the corresponding tag directory in the dataCollection layer when the test is executed.

4. The method for separating the automation framework environment based on the Robot Framework interface according to claim 3, characterized in that, The specific method in step S3 is as follows: By setting the variable file path through the Robot Framework command-line options or in the test suite initialization file, the target environment configuration file loaded at runtime is specified, so that the test cases can dynamically obtain the parameters of the environment.

5. The method for separating the automation framework environment based on the Robot Framework interface according to claim 4, characterized in that, Step S3 further includes: creating test suite tags or metadata corresponding to different environments, executing them through RobotFramework's filtering, and automatically running the associated set of test cases according to the selected environment.

6. The method for separating the automation framework environment based on the Robot Framework interface according to claim 5, characterized in that, In step S4, the keywords encapsulated in the interface layer include: API request construction, response data parsing, database operation, and result assertion.

7. The method for separating the automation framework environment based on the Robot Framework interface according to claim 6, characterized in that, In step S4, the test cases written in the testcase layer complete the interface testing steps by calling keywords in the interface layer and combining test data files in the data layer.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the Robot Framework interface-based automation framework environment separation method as described in any one of claims 1 to 7.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the Robot Framework interface-based automation framework environment separation method as described in any one of claims 1 to 7.

Images