Automatic test environment dynamic management system for cross-border e-commerce multiple deployment scenes

Abstract

The invention provides a cross-border e-commerce multi-deployment scene-oriented automatic test environment dynamic management system, which comprises a configuration layer, a core service layer, an execution layer, a basic dependency layer, and a Token acquisition module and an interface request module coupled with the core service layer, all the modules and hierarchies cooperate to achieve full-process interface automatic testing of multi-environment adaptation, and the technical problems that in a multi-cloud, multi-region and multi-environment complex deployment scene, automatic testing environment configuration codes are high in invasiveness, attribution verification needs hard coding, multi-environment parallel testing interferes with one another, and environment identification naming rules are not unified are solved. The dynamic configuration of a zero-code-intrusion environment is realized, and the compliance verification of the data attribution is automatically completed.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to an automated testing environment dynamic management system for multi-deployment scenarios in cross-border e-commerce. Background Technology

[0002] With the globalization of cross-border e-commerce, SaaS service providers need to deploy service nodes in multiple geographical regions (such as Beijing, Ningxia, and Shanghai) across multiple cloud service providers (such as Alibaba Cloud and AWS) to meet requirements such as data compliance and access latency. Simultaneously, each geographical region requires the deployment of multiple environments (production environment, pre-production environment, and multiple test environments) for development and testing. This three-dimensional matrix deployment architecture of "multi-cloud × multi-region × multi-environment type" presents a significant challenge to automated testing. Therefore, existing automated testing frameworks have the following problems when dealing with the above scenarios: 1. The environment configuration code is highly invasive: In traditional solutions, each new deployment area requires modification of 5-10 code files, such as the assertion module, report generation module, and message push module, with a total modification volume of 50-100 lines of code. There is a risk of omissions, and it requires the intervention of developers. 2. Lack of automatic data attribution verification capability: Cross-border e-commerce systems have strict compliance requirements for the attribution of user data, and API responses must include attribution identifiers. Existing testing frameworks lack the ability to link attribution verification with environment configuration, requiring hard-coding verification logic in each test case. 3. Interference between parallel testing in multiple environments: Traditional solutions use a single token file and a single report file, which cannot support the simultaneous execution of automated tests in multiple environments, creating a bottleneck in the CI / CD pipeline. 4. Inconsistent environment identification naming rules: Environments created by different teams at different times use different naming rules (such as numerical codes, letter prefixes, etc.), lacking a unified resolution and compatibility mechanism. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide an automated testing environment dynamic management system for multiple deployment scenarios in cross-border e-commerce. It solves the technical problems of high code intrusion in automated testing environment configuration, hard coding required for location verification, mutual interference between parallel testing in multiple environments, and inconsistent environment identifier naming rules in complex deployment scenarios with multiple clouds, multiple regions, and multiple environments. It achieves dynamic environment configuration with zero code intrusion and automatically completes data location compliance verification. This invention provides a dynamic management system for automated testing environments in cross-border e-commerce with multiple deployment scenarios. It includes a configuration layer, a core service layer, an execution layer, a basic dependency layer, and a token acquisition module and an interface request module coupled to the core service layer. These modules and layers work together to achieve fully automated interface testing across multiple environments. Specifically: The configuration layer is used to centrally store and manage the configuration data required for multi-environment testing and provide data to the core service layer. It includes environment configuration files, user data configuration files and token storage directory. The environment configuration files record the names of different regional environments, location mapping rules and environment type mapping relationships. The user data configuration files store the test accounts, keys and version information corresponding to each environment. The token storage directory is used to store interface authentication tokens according to environment identifiers. The core service layer encapsulates core business logic based on configuration data provided by the configuration layer, and provides function calls to the execution layer. It includes an environment manager, user data manager, assertion module, and message push module, specifically: The environment manager is used to load the environment configuration file in the configuration layer, receive and parse the environment identifier and region identifier passed in from the execution layer, and output the corresponding environment name, environment type and location mapping configuration, supporting automatic mapping of digital environment identifiers to test environments; The user data manager is used to parse the command-line parameters passed from the execution layer, load the user configuration data corresponding to the environment in the configuration layer, generate and set the environment identifier and the exclusive token file path, realize the dynamic matching and isolation of environment configuration, and provide user configuration information and token storage path for the token acquisition module; the command-line parameters include environment parameters and region parameters; The assertion module is used to receive the test case execution results scheduled by the execution layer, and to implement status code verification and location verification of the interface response based on the location mapping configuration provided by the environment manager. It supports configuring a list of interfaces and environment types that do not require location verification, and can determine and skip location verification in specified scenarios. The message push module is used to obtain the current test environment information parsed by the environment manager and the test status fed back by the execution layer, construct test result messages and push them to the specified message receiving terminal; The execution layer, serving as the entry point and scheduler for the testing process, implements full-process testing scheduling based on the core service layer and basic dependency layer. It includes an environment identifier resolution and report management unit and a test execution entry point unit, specifically: The environment identifier parsing and report management unit is used to parse command line parameters and generate standard environment identifiers, providing environment identifiers for the test execution entry unit; at the same time, it creates directories by date to automatically archive test reports and generate report names containing environment identifiers and timestamps; The test execution entry unit is used to parse command line parameters to initialize the environment and test case paths, call the Token acquisition module associated with the core service layer to obtain the interface authentication token, schedule the execution of test cases in the specified directory and pass the results to the assertion module, generate an HTML test report based on the report generation library of the basic dependency layer, and trigger the message push module to push the test results. The basic dependency layer provides third-party libraries for the configuration layer, core service layer, and execution layer, including a configuration parsing library, a test framework library, a report generation library, and a network request library. Among them, the network request library provides basic request capabilities for the interface request module, the test framework library provides test case scheduling capabilities for the test execution entry unit, and the report generation library provides report generation capabilities for the test execution entry unit. One or more technical solutions provided by this invention have at least the following technical effects or advantages: 1. The core service layer of this invention encapsulates core logic such as environment parsing and configuration loading into independent modules, decoupling them from the execution layer: the execution layer does not need to concern itself with details such as "how to parse the environment" and "how to verify the location", but only needs to call the standardized interface of the core service layer. This avoids rewriting code and allows each module to be maintained and reused independently (for example, the environment parsing logic can support multiple scenarios such as test execution, report generation, and message push at the same time). 2. The environment parsing and configuration loading functions of this invention are concentrated in the core service layer. When adding / modifying an environment (such as adding an Alibaba Cloud Shanghai environment), only the configuration layer file needs to be adjusted. The parsing logic of the core service layer does not need to be changed, and the execution layer does not need to be adapted. This greatly reduces the development cost of multi-environment expansion and conforms to the best practice of "configuration-driven". 3. The assertion verification function of this invention is uniformly implemented in the core service layer, ensuring that the status codes and location verification rules of all test cases are consistent, avoiding missed detections / false judgments caused by inconsistent verification logic in different test cases; at the same time, it supports the flexible configuration of "skipping specified interface / environment verification", taking into account both standardization and scenario adaptability. 4. The message push function of this invention is based on the unified environment information parsed by the core service layer to construct messages, ensuring that the pushed environment description and abnormal information are accurate and in a unified format. Testers can obtain standardized test results in real time without having to manually organize environment information, thus improving testing efficiency. 5. This invention reuses mature third-party libraries (such as HTMLTestRunnerCN, requests, and pyyaml) to implement basic capabilities such as report generation, network requests, and configuration parsing, without the need to develop underlying logic from scratch. This shortens the framework development cycle and reduces the risk of underlying bugs by leveraging the maturity of open-source libraries. 6. The basic dependency layer of this invention focuses only on "capability support" and does not intervene in business logic, allowing the core service layer and execution layer to focus on testing business scenarios; at the same time, version updates and bug fixes of third-party libraries can be carried out independently without affecting the core business logic, reducing the overall maintenance cost of the framework. 7. The third-party libraries in the basic dependency layer of this invention can be extended as needed (e.g., to add GET request capability, only the GET method of the requests library needs to be reused; to add Excel report, only the report generation library needs to be extended), without refactoring the core architecture, allowing the framework to quickly adapt to changes in testing requirements. The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description The present invention will be further described below with reference to the accompanying drawings and embodiments. Figure 1 This is a test flowchart from Embodiment 1 of the present invention. Detailed Implementation This application provides an automated testing environment dynamic management system for cross-border e-commerce deployment scenarios, which solves the problem of how to achieve zero-code intrusion dynamic environment configuration and automatically complete data ownership compliance verification in complex deployment scenarios with multiple clouds, multiple regions and multiple environments. The overall concept of the technical solution in this application is as follows: The present invention provides an automated test environment dynamic management method for multi-cloud, multi-region deployment scenarios in cross-border e-commerce, comprising the following steps: Constructing a 3D environment configuration model: Establishing a 3D hierarchical configuration structure of "cloud service provider - geographical region - environment type", where: The first dimension is the geographical region identifier (such as ali-Alibaba Cloud Beijing, bj-AWS Beijing, nx-Ningxia, sh-Shanghai). The second dimension is the geographic location mapping relationship (including region identifier and expected_region expected value). The third dimension is the environment type mapping (p-formal, r-pre-prepared, test-test, 1~13-numbered test environments). Intelligent resolution of environment identifiers: Receives environment identifiers input from the command line and uses the "prefix_region" format resolution algorithm to separate the environment prefix and region identifier; the numeric prefix (1-13) is automatically mapped to the test type, while also supporting backward compatibility with old naming rules (such as the pure numeric format "9"). Environment Manager Singleton Initialization: Creates a globally unique environment manager instance, loads the configuration file once, and provides a unified environment information query interface to various functional modules. Automatic injection of location verification rules: When the assertion module is initialized, it automatically obtains the expected location value of the current environment from the environment manager and automatically compares it with the region field in the response header during API response verification. Test resource environment isolation: Generate independent token storage paths and report file names based on environment identifiers to achieve resource isolation for parallel testing in multiple environments. (II) System Architecture The present invention also provides an automated test environment dynamic management system for implementing the above method, comprising: Configuration file module: contains environment_config.yaml environment configuration file and user_data.yaml user data configuration file. environment_config.yaml is used to store all configuration nodes of the 3D environment configuration model, and user_data.yaml is used to store user credential information for different environments. The Environment Manager module (EnvironmentManager.py) implements functions such as loading configuration files, querying environment information, obtaining location mapping configurations, and parsing environment types, and provides a globally unique interface for querying environment information. The user data management module (UserData.py) parses command-line arguments to obtain the environment identifier, dynamically loads the user configuration for the corresponding environment, and generates an environment-isolated token file storage path. The assertion module (Assert.py) automatically retrieves the expected location value from the environment manager, performs status code verification and location compliance verification during API response validation, and supports skipping the location check of specified interfaces. The entry module (run2.py) parses command-line arguments, triggers test case execution, generates an environment-isolated test report, and completes pre-processing for pushing test results. Environment identifier parsing module (RunENV.py): Parses the environment identifiers input from the command line, completes the mapping from numeric prefixes to the test type, and implements date-based categorized storage of test reports. The message push module (DingDingTalk.py) retrieves environment information from the environment manager, constructs a push message containing the environment identifier, and pushes the test results. The core code is as follows: 1. Environment configuration file (environment_config.yaml) ```yaml #Environment Configuration File - Simply configure new environments here. environments: #Alibaba Cloud Beijing Environment ali: name: "Alibaba Cloud Beijing" region_mapping: region: "ali" expected_region: "abj" regions: p: "Pro Production Environment" r: "sim pre-installation environment" k8r: "k8s pre-deployment environment" k8p: "Kubernetes production environment" test: "test test environment" "1": "test-01 environment" "2": "test-02 environment" "3": "test-03 environment" "4": "test-04 environment" "5": "test-05 environment" "6": "test-06 environment" "7": "test-07 environment" "8": "test-08 environment" "9": "test-09 environment" "10": "test-10 environment" "11": "test-11 environment" "12": "test-12 environment" "13": "test-13 environment" # AWS Beijing Environment bj: name: "AWS Beijing" region_mapping: region: "bj" expected_region: "bj" regions: p: "Pro Production Environment" r: "sim pre-installation environment" test: "test test environment" "1": "test-01 environment" "2": "test-02 environment" ``` 2. Environment Manager (EnvironmentManager.py) Python # -*- coding: utf-8 -*- import yaml import os import sys class EnvironmentManager: def __init__(self): self.config_file = os.path.join(os.path.dirname(__file__),'..', 'Params', 'Data', 'environment_config.yaml') self.config = self._load_config() def _load_config(self): Load environment configuration files try: with open(self.config_file, 'r', encoding='utf-8') as f: return yaml.safe_load(f) except Exception as e: print(f"Failed to load environment configuration file: {e}") return {"environments": {}} def get_environment_info(self, env_key, region_key): """ Obtain environmental information Args: env_key: Environment identifier, such as 'p_ali', '9_bj', 'r_nx' region_key: Region identifier, such as 'ali', 'bj', 'nx' Returns: tuple: (environment name, environment type) """ if not self.config or "environments" not in self.config: return "Unknown Environment", "Unknown Environment" # Analyze environment identifiers if '_' in str(env_key): env_prefix = str(env_key).split('_')[0] else: env_prefix = str(env_key) # Get region information if region_key in self.config["environments"]: region_info = self.config["environments"][region_key] region_name = region_info.get("name", "Unknown region") # Get Environment Type if env_prefix in region_info["regions"]: env_type = region_info["regions"][env_prefix] else: env_type = "Unknown environment" return region_name, env_type else: return "unknown region", "unknown environment" def get_full_environment_name(self, env_key, region_key): """Retrieve the complete environment name for the report title""" region_name, env_type = self.get_environment_info(env_key,region_key) return f"{region_name}Purple Bird{env_type}" def get_environment_type(self, env_key): """Retrieves environment type description for DingTalk push notifications"" if '_' in str(env_key): env_prefix = str(env_key).split('_')[0] else: env_prefix = str(env_key) default_types = { 'p': 'Pro production environment' 'r': 'sim pre-installation environment', 'test': 'test test environment', 'k8r': 'k8s pre-installation environment' 'k8p': 'k8s production environment' } if env_prefix.isdigit(): return f'test-{env_prefix}environment' return default_types.get(env_prefix, 'Unknown environment') def get_region_mapping(self, region_key): """Get the region's geolocation mapping configuration""" if not self.config or "environments" not in self.config: return {"region": "unknown", "expected_region": "unknown"} if region_key in self.config["environments"]: region_info = self.config["environments"][region_key] if "region_mapping" in region_info: return region_info["region_mapping"] return {"region": region_key, "expected_region": region_key} # Global instance env_manager = EnvironmentManager() ``` 3. User Data Management (UserData.py) ```python # -*- coding: utf-8 -*- import yaml, os, json, sys class UserData: def __init__(self, env_key=None): if env_key is not None: self.env = env_key else: if len(sys.argv) > 1: self.env = str(sys.argv[1]) else: self.env = '9' if self.env in ['1','2','3','4','5','6','7','8','9','10','11','12','13']: self.env = 'test' if len(sys.argv) > 5: self.config_name = str(sys.argv[5]) else: self.config_name = 'ali' yaml_path = os.path.abspath(os.path.dirname(os.path.dirname(__file__)))+"\\Params\\Data\\user_data.yaml" f = open(yaml_path, encoding="utf-8") self.data = yaml.load(stream=f, Loader=yaml.FullLoader) f.close() self.config = self._get_config() if not self.config: print(f"Warning: Environment {self.env} configuration does not exist, using the default environment p") self.config = self.data.get('p', {}) def _get_env_key(self): """Get current environment identifier""" env = self.env if str(env) in ['1','2','3','4','5','6','7','8','9','10','11','12','13']: env = 'test' region = self.config_name if '_' in str(env): return str(env) else: return f"{env}_{region}" def _get_token_file_path(self): """Retrieve the token file path based on the environment identifier""" filePath = str(os.path.abspath(os.path.dirname(os.path.dirname(__file__)))) env_key = self._get_env_key() tokens_dir = os.path.join(filePath, "Params", "Data", "tokens") if not os.path.exists(tokens_dir): os.makedirs(tokens_dir, exist_ok=True) token_file = os.path.join(tokens_dir, f"token_{env_key}.json") return token_file def _get_config(self): Dynamically retrieves configurations and supports multiple naming conventions. # 1. Directly match environment name if self.env is in self.data: return self.data[self.env] # 2. Try combining environment name + configuration type config_key = f"{self.env}_{self.config_name}" if config_key in self.data: return self.data[config_key] # 3. Processing Numbers - Environment Type Format if '_' in str(self.env): parts = str(self.env).split('_') if len(parts) == 2 and parts[0].isdigit() and parts[1] in['ali', 'bj', 'nx']: if parts[1] == 'ali': return self.data.get('test_ali', {}) elif parts[1] == 'bj': return self.data.get('test_bj', {}) elif parts[1] == 'nx': return self.data.get('test_nx', {}) return self.data.get(self.env, {}) def get_token(self, key): """Get the token from the environment-specific token file""" env_key = self._get_env_key() token_file_path = self._get_token_file_path() try: with open(token_file_path, 'r', encoding='utf-8') as token_path: json_data = json.load(token_path) return json_data.get(key, "") except Exception as e: return "" ``` 4. Assertion Module (Assert.py) - Location Verification Part ```python # -*- coding: utf-8 -*- import json import sys from Common.EnvironmentManager import env_manager class Assert: def __init__(self, user_data=None): self.user_data = user_data if len(sys.argv) > 1: self.current_env = str(sys.argv[1]) else: self.current_env = getattr(user_data, 'env', 'unknown') if user_data else 'unknown' if len(sys.argv) > 5: self.current_config_name = str(sys.argv[5]) else: self.current_config_name = getattr(user_data, 'config_name', 'unknown') if user_data else 'unknown' self._setup_environment_config() self.skip_region_check_urls = " / isv / preset_scripts", " / heartbeat_new", " / user / app / list", def _setup_environment_config(self): """Use the environment manager to set up the environment configuration""" try: region_name, env_type = env_manager.get_environment_info(self.current_env, self.current_config_name) region_mapping = env_manager.get_region_mapping(self.current_config_name) self.region = region_mapping['region'] self.expected_region = region_mapping['expected_region'] self.region_description = region_name ​except Exception as e: print(f"Environment configuration settings failed: {e}") self.region = "unknown" self.expected_region = "unknown" self.region_description = "Unknown" def _should_skip_region_check(self, url): "Determine whether the geolocation check should be skipped." if self.current_env.split("_")[0] == 'k8r' or self.current_env.split("_")[0] == 'k8p': return True return any(skip_url in url for skip_url in self.skip_region_check_urls) def _assert_single_code_with_region(self, response_data,expected_code, key_type): """Assert the status code and location of a single response""" if isinstance(response_data, list) and len(response_data) >=1: actual_code = response_data[0] url = response_data[2] if len(response_data) > 2 else "" result = response_data[1] if len(response_data) > 1 else"" time = response_data[3] if len(response_data) > 3 else "" if key_type not in ("Exception: token authentication", "Exception: unencrypted authentication"): if actual_code != expected_code: error_message = f"{key_type} response error, interface status code: {actual_code}\nAssertion expected status code: {expected_code}" raise AssertionError(error_message) # Location verification if not self._should_skip_region_check(url): header = response_data[5] if len(response_data) >5 else {} if isinstance(header, dict) and "region" inheader: actual_region = header["region"] if actual_region != self.expected_region: err = f"{key_type} location error, expected({self.expected_region}), actual{actual_region}" raise AssertionError(err) else: raise AssertionError(f"{key_type} geolocation exception, no geolocation returned") return True ``` 5. Entry point (run2.py) Python # -*- coding: utf-8 -*- import sys, unittest import HTMLTestRunnerCN, DingDingTalk import datetime import os from RunENV import * from Common.Token import * from Common.EnvironmentManager import env_manager curPath = os.path.abspath(os.path.dirname(__file__)) if len(sys.argv) >= 3: case_param = str(sys.argv[2]) else: case_param = '0' if len(sys.argv) >= 5: priority_param = str(sys.argv[4]) else: priority_param = '0' case = RunENV().case_path(case_param) case_path = os.path.join(os.getcwd(), "Case\\" + case) report_path = os.path.join(os.getcwd(), "Report") runENV = str(sys.argv[1]) def all_case(): case_path = os.path.join(os.getcwd(), "Case") discover = unittest.defaultTestLoader.discover(case_path, pattern="test_*.py", top_level_dir=None) return discover if __name__ == "__main__": script_start_time = datetime.datetime.now() run_env_instance = RunENV() env_key = run_env_instance._get_env_key_from_argv() token_error = Token().set_token() desc_env = str(get_env()) if token_error: print("Token acquisition failed, skipping test case execution") if env_key: filename = f'.\\Report\\result_{env_key}.html' else: filename = '.\\Report\\result.html' fp = open(filename, 'wb') fp.close() run_env_instance.copyreport(env_key) DingDingTalk.report_info(token_error, priority_param) else: if env_key: filename = f'.\\Report\\result_{env_key}.html' else: filename = '.\\Report\\result.html' fp = open(filename, 'wb') HTMLTestRunnerCN.HTMLTestReportCN( stream=fp, title=u'Interface Regression', description=u'Purple Bird' + desc_env + str(case) + 'Interface Test Report:', tester=u"QA", start_time=script_start_time, priority=priority_param ).run(all_case()) fp.close() run_env_instance.copyreport(env_key) DingDingTalk.report_info(token_error, priority_param) ``` 6. Environmental Identifier Resolution (RunENV.py) Python # -*- coding: utf-8 -*- import shutil, os, datetime import sys class RunENV(): def _get_env_key_from_argv(self): """Resolving environment identifiers from command-line arguments""" env_key = "" try: if len(sys.argv) > 1: env_param = sys.argv[1] region_param = "" if len(sys.argv) > 5: region_param = sys.argv[5] # Numbers 1-13 mapped to test if env_param.isdigit() and 1 <= int(env_param) <= 13: env_prefix = "test" else: env_prefix = env_param if region_param: env_key = f"{env_prefix}_{region_param}" else: env_key = env_prefix except Exception as e: print(f"Failed to parse environment identifier: {e}") env_key = "" return env_key def case_path(self, path): if str(path) == "1": return str("SEMS") elif str(path) == "2": return str("SSOS") elif str(path) == "3": return str("Sip") elif str(path) == "0": return str("") else: return str("") def copyreport(self, env_key=None): """Copy the report to the date directory""" filePath = os.path.dirname(__file__) path = os.path.join(filePath, "Report\\") if env_key is None: env_key = self._get_env_key_from_argv() todaypath = path + str(datetime.datetime.now().strftime('%Y-%m-%d')) if env_key: reportname = str(path + env_key + "_" + str(datetime.datetime.now().strftime('%Y-%m-%d %H.%M.%S.%f')[:-3]) + "_report.html") source_file = path + f"result_{env_key}.html" else: reportname = str(path + "Release_" + str(datetime.datetime.now().strftime('%Y-%m-%d %H.%M.%S.%f')[:-3]) + "_report.html") source_file = path + "result.html" if not os.path.exists(todaypath): os.makedirs(todaypath) shutil.copy(source_file, reportname) shutil.move(reportname, todaypath) ``` 7. Message Push (DingDingTalk.py) - Environment Information Acquisition Section Python # -*- coding: utf-8 -*- from Common.EnvironmentManager import env_manager from Common.Request import * from RunENV import * import sys def get_env(): "Use the Environment Manager to obtain environment information" env = API().runENV return env_manager.get_environment_type(env) def report_info(additional_error_content=None, priority='0'): # Get environmental information if len(sys.argv) > 5: env_key = str(sys.argv[1]) if len(sys.argv) > 1 else '' region_key = str(sys.argv[5]) region_name, env_type = env_manager.get_environment_info(env_key, region_key) text = region_name else: try: env = API().runENV if '_' in env: env_prefix = env.split('_')[0] region_key = env.split('_')[1] region_name, env_type = env_manager.get_environment_info(env_prefix, region_key) text = f"{region_name}{env_type}" else: env_type = env_manager.get_environment_type(env) text = f"{env_type}environment" except Exception as e: text = 'Unknown Environment' # Build a message... msg = f"{text}Purple Bird Browser {get_env()} API Automated Regression Completed" # ... Message sending logic ``` 8. User data configuration example (user_data.yaml) ```yaml # Alibaba Cloud Environment p_ali: companyname: Alibaba Cloud production environment username: ali_boss psd: 123456Qq key: your_key_here machine_string: ali_prod_machine_001 version: 5.285.0.30 r_ali: companyname: Alibaba Cloud pre-deployment environment username: ali_boss_pre psd: 123456Qq key: your_key_here machine_string: ali_pre_machine_001 version: 5.285.0.30 test_ali: companyname: Alibaba Cloud Test Environment username: ali_test_user psd: 123456Qq key: your_key_here machine_string: ali_test_machine_001 version: 5.285.0.30 # AWS Beijing Environment p_bj: Company Name: AWS Beijing Production Environment username: bj_boss psd: 123456Qq key: your_key_here machine_string: bj_prod_machine_001 version: 5.285.0.30 # Ningxia Environment p_nx: Company Name: Ningxia Zhengshi Environment username: nx_boss psd: 123456Qq key: your_key_here machine_string: nx_prod_machine_001 version: 5.285.0.30 ``` 9. Usage Examples bash # Alibaba Cloud Production Environment python run2.py p_ali 0 0 0 ali # AWS Beijing Pre-deployment Environment python run2.py r_bj 0 0 0 bj # Ningxia Testing Environment python run2.py test_nx 0 0 0 nx # Digital environment (automatically mapped to test) python run2.py 9_ali 0 0 0 ali ``` Its advantages are: 1. Reduced configuration costs: Adding a new deployment area only requires modifying the configuration file, without changing the code, improving configuration efficiency by more than 80% and eliminating the risk of omissions caused by code modifications. 2. Ensure data compliance: Origin verification is completed automatically without hard coding, ensuring 100% coverage of cross-border e-commerce data origin compliance requirements and reducing compliance risks. 3. Improve testing efficiency: Resource isolation for parallel testing in multiple environments, improved CI / CD pipeline efficiency, and shortened testing cycle. 4. Compatible with legacy systems: The intelligent resolution algorithm for environment identifiers is compatible with the old naming rules, eliminating the need to modify existing CI / CD pipelines and enabling smooth upgrades. 5. Unified Environment Management: The 3D configuration model and global environment manager enable unified management of multiple environment information, reducing maintenance costs and improving system scalability. Example 1 This embodiment provides a dynamic management system for automated testing environments in cross-border e-commerce with multiple deployment scenarios. It includes a configuration layer, a core service layer, an execution layer, a basic dependency layer, and a token acquisition module and an interface request module coupled with the core service layer. These modules and layers work together to achieve full-process automated interface testing adaptable to multiple environments. Specifically: The configuration layer is used to centrally store and manage the configuration data required for multi-environment testing and provide data to the core service layer. It includes environment configuration files, user data configuration files and token storage directory. The environment configuration files record the names of different regional environments, location mapping rules and environment type mapping relationships. The user data configuration files store the test accounts, keys and version information corresponding to each environment. The token storage directory is used to store interface authentication tokens according to environment identifiers. The core service layer encapsulates core business logic based on configuration data provided by the configuration layer, and provides function calls to the execution layer. It includes an environment manager, user data manager, assertion module, and message push module, specifically: The environment manager is used to load the environment configuration file in the configuration layer, receive and parse the environment identifier and region identifier passed in from the execution layer, and output the corresponding environment name, environment type and location mapping configuration, supporting automatic mapping of digital environment identifiers to test environments; The user data manager is used to parse the command-line parameters passed from the execution layer, load the user configuration data corresponding to the environment in the configuration layer, generate and set the environment identifier and the exclusive token file path, realize the dynamic matching and isolation of environment configuration, and provide user configuration information and token storage path for the token acquisition module; the command-line parameters include environment parameters and region parameters; The assertion module is used to receive the test case execution results scheduled by the execution layer, and to implement status code verification and location verification of the interface response based on the location mapping configuration provided by the environment manager. It supports configuring a list of interfaces and environment types that do not require location verification, and can determine and skip location verification in specified scenarios. The message push module is used to obtain the current test environment information parsed by the environment manager and the test status fed back by the execution layer, construct test result messages and push them to the specified message receiving terminal; The execution layer, serving as the entry point and scheduler for the testing process, implements full-process testing scheduling based on the core service layer and basic dependency layer. It includes an environment identifier resolution and report management unit and a test execution entry point unit, specifically: The environment identifier parsing and report management unit is used to parse command line parameters and generate standard environment identifiers, providing environment identifiers for the test execution entry unit; at the same time, it creates directories by date to automatically archive test reports and generate report names containing environment identifiers and timestamps; The test execution entry unit is used to parse command line parameters to initialize the environment and test case paths, call the Token acquisition module associated with the core service layer to obtain the interface authentication token, schedule the execution of test cases in the specified directory and pass the results to the assertion module, generate an HTML test report based on the report generation library of the basic dependency layer, and trigger the message push module to push the test results. The basic dependency layer provides third-party libraries for the configuration layer, core service layer, and execution layer, including a configuration parsing library, a test framework library, a report generation library, and a network request library. Among them, the network request library provides basic request capabilities for the interface request module, the test framework library provides test case scheduling capabilities for the test execution entry unit, and the report generation library provides report generation capabilities for the test execution entry unit. In this embodiment, preferably, the step of receiving and parsing the environment identifier and region identifier passed from the execution layer, and outputting the corresponding environment name, environment type, and location mapping configuration specifically involves: receiving the environment identifier and region identifier parameters passed from the execution layer; if the environment identifier contains a separator, extracting the prefix part; matching the environment configuration information corresponding to the region identifier in the configuration layer based on the prefix part to obtain the environment name; matching the corresponding environment type according to the environment identifier prefix; if the environment identifier is a number, automatically mapping it to the corresponding numbered test environment type and outputting it. In this embodiment, preferably, it further includes: the user data manager prioritizes matching user configurations that are completely consistent with the environment identifier passed in from the execution layer; if the matching fails, the environment identifier prefix is ​​concatenated with the region identifier to form a combination, and the user data configuration in the configuration layer is matched again; if the environment identifier is a combination of numbers and region, it is mapped to the test environment configuration of the corresponding region for matching; if all the above matching fails, the default production environment configuration is used. In this embodiment, preferably, it further includes: the assertion module extracts the expected location of the current environment from the location mapping configuration output by the environment manager; obtains the actual location in the interface response header; determines whether the interface URL belongs to the preset list of environments that do not require verification, or whether the current environment is a set type environment. If so, the location verification is skipped; otherwise, the actual location is compared with the expected location. If they are inconsistent, an assertion exception is thrown and fed back to the execution layer. In this embodiment, preferably, it further includes: the message push module determines whether the command line parameters passed by the execution layer contain complete environment identifier and region identifier. If so, it directly calls the environment manager to parse and obtain the environment name and type, and concatenates them into an environment description. If the environment identifier is in a combined format, it separates the prefix and the region part, calls the environment manager to match the environment information respectively, and concatenates the environment description. If the parsing fails, it is marked as "unknown environment". If the execution layer reports abnormal information, it appends the abnormal information to the message content to form a complete test result message. In this embodiment, preferably, as follows: Figure 1 As shown, the specific implementation of the entire test process scheduling based on the core service layer and the basic dependency layer is as follows: Step 1: Parse the command line parameters, including environment identifier, test case directory parameters, priority parameters, and region identifier. Pass the environment identifier and region identifier to the environment manager and user data manager of the core service layer. Step 2: Determine the directory path of the test cases to be executed based on the test case directory parameters, and call the environment identifier resolution and report management unit to initialize the report storage directory; Step 3: Invoke the Token acquisition module coupled with the core service layer to obtain the interface authentication token for the current environment based on the user configuration information provided by the user data manager. If the token acquisition fails, an empty test report is generated, the environment identifier resolution and report management unit is invoked to archive the report, and the message push module is triggered to push a message containing exception information. If the token acquisition is successful, the HTML test report generator is initialized based on the report generation library of the basic dependency layer, the test cases named "test_*.py" in the specified directory are found and executed, and the interface response results are passed to the assertion module of the core service layer for verification. The HTML test report generator is an instance used to generate HTML format test reports. This instance can receive the test case execution results and finally generate an HTML test report. Step 4: After the test is completed, the environment identifier resolution and report management unit is called to archive the test report to the corresponding date directory, triggering the message push module to push the test completion message. In this embodiment, preferably, it also includes: the configuration layer supports extended configuration for new environments, and the extension process does not require modification of the core service layer and execution layer code; the specific extension method is: add the environment name, location mapping and environment type configuration of the new region to the environment configuration file of the configuration layer, add the user information configuration of the corresponding environment to the user data configuration file of the configuration layer, and the core service layer can directly load the new configuration. In this embodiment, preferably, the Token acquisition module is used to receive the current environment user configuration information and the path of the exclusive Token file provided by the user data manager, call the interface request module to send an authentication request to obtain the interface authentication Token, and store the Token in the exclusive Token file. In this embodiment, preferably, the interface request module is used to encapsulate HTTPPOST request logic based on the network request library of the basic dependency layer, set the request timeout, capture and throw HTTP request exceptions, and at the same time feed back the exception information to the Token acquisition module and the execution layer. In this embodiment, preferably, the test cases are stored in a set directory according to a preset specification, and the set directory supports the division of subdirectories according to business modules; the test execution entry unit of the execution layer selects to execute all test cases in the set directory or test cases in the subdirectory of a specified business module according to the parsed test case directory parameters, so as to realize the on-demand scheduling of test cases. While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the present invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A dynamic management system for automated testing environments in multi-deployment scenarios of cross-border e-commerce, characterized in that, It includes a configuration layer, a core service layer, an execution layer, a basic dependency layer, and a token acquisition module and an interface request module coupled with the core service layer. These modules and layers work together to achieve fully automated interface testing across multiple environments. Specifically: The configuration layer is used to centrally store and manage the configuration data required for multi-environment testing and provide data to the core service layer. It includes environment configuration files, user data configuration files and token storage directory. The environment configuration files record the names of different regional environments, location mapping rules and environment type mapping relationships. The user data configuration files store the test accounts, keys and version information corresponding to each environment. The token storage directory is used to store interface authentication tokens according to environment identifiers. The core service layer encapsulates core business logic based on configuration data provided by the configuration layer, and provides function calls to the execution layer. It includes an environment manager, user data manager, assertion module, and message push module, specifically: The environment manager is used to load the environment configuration file in the configuration layer, receive and parse the environment identifier and region identifier passed in from the execution layer, and output the corresponding environment name, environment type and location mapping configuration, supporting automatic mapping of digital environment identifiers to test environments; The user data manager is used to parse the command-line parameters passed from the execution layer, load the user configuration data corresponding to the environment in the configuration layer, generate and set the environment identifier and the exclusive token file path, realize the dynamic matching and isolation of environment configuration, and provide user configuration information and token storage path for the token acquisition module; the command-line parameters include environment parameters and region parameters; The assertion module is used to receive the test case execution results scheduled by the execution layer, and to implement status code verification and location verification of the interface response based on the location mapping configuration provided by the environment manager. It supports configuring a list of interfaces and environment types that do not require location verification, and can determine and skip location verification in specified scenarios. The message push module is used to obtain the current test environment information parsed by the environment manager and the test status fed back by the execution layer, construct test result messages and push them to the specified message receiving terminal; The execution layer, serving as the entry point and scheduler for the testing process, implements full-process testing scheduling based on the core service layer and basic dependency layer. It includes an environment identifier resolution and report management unit and a test execution entry point unit, specifically: The environment identifier parsing and report management unit is used to parse command line parameters and generate standard environment identifiers, providing environment identifiers for the test execution entry unit; at the same time, it creates directories by date to automatically archive test reports and generate report names containing environment identifiers and timestamps; The test execution entry unit is used to parse command line parameters to initialize the environment and test case paths, call the Token acquisition module associated with the core service layer to obtain the interface authentication token, schedule the execution of test cases in the specified directory and pass the results to the assertion module, generate an HTML test report based on the report generation library of the basic dependency layer, and trigger the message push module to push the test results. The basic dependency layer provides third-party libraries for the configuration layer, core service layer, and execution layer, including a configuration parsing library, a test framework library, a report generation library, and a network request library. Among them, the network request library provides basic request capabilities for the interface request module, the test framework library provides test case scheduling capabilities for the test execution entry unit, and the report generation library provides report generation capabilities for the test execution entry unit.

2. The automated testing environment dynamic management system for multiple deployment scenarios in cross-border e-commerce as described in claim 1, characterized in that, The specific steps for receiving and parsing the environment identifier and region identifier passed from the execution layer, and outputting the corresponding environment name, environment type, and location mapping configuration are as follows: receiving environment identifier and region identifier parameters passed from the execution layer; if the environment identifier contains a separator, extracting the prefix part; matching the environment configuration information corresponding to the region identifier in the configuration layer based on the prefix part to obtain the environment name; matching the corresponding environment type according to the environment identifier prefix; if the environment identifier is a number, automatically mapping it to the corresponding numbered test environment type and outputting it.

3. The automated testing environment dynamic management system for multiple deployment scenarios in cross-border e-commerce as described in claim 1, characterized in that, Also includes: The user data manager prioritizes matching user configurations that are completely consistent with the environment identifier passed in from the execution layer; If the match fails, the environment identifier prefix is ​​combined with the region identifier to form a combination, and the user data configuration in the configuration layer is matched again; if the environment identifier is a combination of numbers and region, it is mapped to the test environment configuration of the corresponding region for matching; if all the above matches fail, the default production environment configuration is used.

4. The automated testing environment dynamic management system for multi-deployment scenarios in cross-border e-commerce as described in claim 1, characterized in that, Also includes: The assertion module extracts the desired location of the current environment from the location mapping configuration output by the environment manager; Retrieve the actual location from the API response header; Determine whether the interface URL belongs to the preset list of URLs that do not require validation, or whether the current environment is a set type environment. If so, skip the location validation; otherwise, compare the actual location with the expected location. If they do not match, throw an assertion exception and report it to the execution layer.

5. The automated testing environment dynamic management system for multi-deployment scenarios in cross-border e-commerce as described in claim 1, characterized in that, Also includes: The message push module determines whether the command-line parameters passed from the execution layer contain complete environment and region identifiers. If so, it directly calls the environment manager to parse and obtain the environment name and type, and concatenates them into an environment description. If the environment identifier is in a combined format, it separates the prefix and region part, calls the environment manager to match the environment information respectively, and concatenates the environment description. If the parsing fails, it is marked as "unknown environment". If the execution layer reports an exception, the exception information is appended to the message content to form a complete test result message.

6. The automated testing environment dynamic management system for multi-deployment scenarios in cross-border e-commerce as described in claim 1, characterized in that, The specific implementation of the entire test process scheduling based on the core service layer and the basic dependency layer is as follows: Step 1: Parse the command line parameters, including environment identifier, test case directory parameters, priority parameters, and region identifier. Pass the environment identifier and region identifier to the environment manager and user data manager of the core service layer. Step 2: Determine the directory path of the test cases to be executed based on the test case directory parameters, and call the environment identifier resolution and report management unit to initialize the report storage directory; Step 3: Invoke the Token acquisition module coupled with the core service layer to obtain the interface authentication token for the current environment based on the user configuration information provided by the user data manager. If the token acquisition fails, generate an empty test report, call the environment identifier resolution and report management unit to archive the report, and trigger the message push module to push a message containing exception information. If the token acquisition is successful, initialize the HTML test report generator based on the report generation library of the basic dependency layer, find and execute test cases named "test_*.py" in the specified directory, and pass the interface response results to the assertion module of the core service layer for verification. The HTML test report generator is an instance used to generate HTML format test reports. This instance can receive the test case execution results and finally generate an HTML test report. Step 4: After the test is completed, the environment identifier resolution and report management unit is called to archive the test report to the corresponding date directory, triggering the message push module to push the test completion message.

7. The automated testing environment dynamic management system for multi-deployment scenarios in cross-border e-commerce as described in claim 1, characterized in that, Also includes: The configuration layer supports extended configurations for new environments, and the extension process does not require modification of the core service layer and execution layer code; The specific extension method is as follows: add the environment name, location mapping and environment type configuration of the new region to the environment configuration file of the configuration layer, add the user information configuration of the corresponding environment to the user data configuration file of the configuration layer, and the core service layer can directly load the new configuration.

8. The automated testing environment dynamic management system for multi-deployment scenarios in cross-border e-commerce as described in claim 1, characterized in that, The Token acquisition module is used to receive the current environment user configuration information and the path of the exclusive Token file provided by the user data manager, call the interface request module to send an authentication request to obtain the interface authentication Token, and store the Token in the exclusive Token file.

9. The automated testing environment dynamic management system for multi-deployment scenarios in cross-border e-commerce as described in claim 1, characterized in that, The interface request module is used to encapsulate HTTP POST request logic based on the network request library of the basic dependency layer, set the request timeout, capture and throw HTTP request exceptions, and feed back the exception information to the Token acquisition module and the execution layer.

10. The automated testing environment dynamic management system for multi-deployment scenarios in cross-border e-commerce as described in claim 1, characterized in that, The test cases are stored in a designated directory according to preset specifications, and the designated directory supports subdirectories based on business modules. The test execution entry unit of the execution layer selects to execute all test cases under the set directory or test cases under the specified business module subdirectory based on the parsed test case directory parameters, thereby realizing on-demand scheduling of test cases.

Images