Cross-system full-process automatic test method, equipment, medium and product

Abstract

The invention discloses a cross-system full-process automatic test method and device, a medium and a product, and relates to the technical field of computer software, and the method comprises the steps: obtaining a business full-process model, packaging a function interface according to function test points corresponding to a plurality of subsystems in the business full-process model, the function test points are bound with the corresponding function interfaces, and the business full-process model relates to a plurality of subsystems; configuring a data source for each function interface in the business full-process model; and configuring at least one test component in the shared market in each function test point according to a function in each function test point in the business full-process model with the configured data source, and performing a full-process test according to the business full-process model with the configured test component. According to the method and the device, comprehensive integration of cross-system automatic assets is realized, the continuity and the accuracy of the test process are improved, omission in the test process is effectively avoided, and the comprehensiveness of full-process automatic inspection is ensured.

Description

Technical Field

[0001] The present application relates to the field of computer software technology, and in particular to cross-system full-process automated testing methods, equipment, media and products. Background Art

[0002] With the continuous advancement of cloud computing and Internet technologies, the trend of application service is becoming more and more obvious. Large applications are being split into smaller and more modular microservice architectures. This architectural model promotes the normalization of cross-system development and testing. However, in the field of cross-system automated testing, the current application of similar technologies is mainly focused on the automated testing solutions of a single system, and when faced with complex cross-system testing involving multiple subsystems, some significant defects and limitations are exposed. There is currently no visual full-process automation construction method based on the user journey business perspective. This means that in the process of automated testing, there is a lack of a comprehensive, user-centric perspective to review and build the automated testing process. Summary of the invention

[0003] The main purpose of this application is to provide a cross-system full-process automated testing method, equipment, medium and product, aiming to solve the technical problem of insufficient comprehensiveness in full-process automatic testing.

[0004] To achieve the above objectives, the present application proposes a cross-system full-process automated testing method, which includes:

[0005] Obtain a business full process model, encapsulate functional interfaces according to functional test points corresponding to multiple subsystems in the business full process model, and bind the functional test points to the corresponding functional interfaces, wherein the functional interface is an interface used to transfer data between different functional test points and trigger the execution of the functional test points;

[0006] For each functional interface in the business full process model, a data source matching the functional interface is selected from a preset public data pool, and the selected data source is configured for the functional interface, wherein the public data pool includes data sources of multiple subsystems, and the data source of each subsystem is different;

[0007] According to the functions in each functional test point in the business full-process model with the data source configured, at least one test component in the shared market is configured in each functional test point, and the full-process test is performed according to the business full-process model with the configured test components, wherein the shared market is a component library containing multiple test components.

[0008] In one embodiment, before the step of selecting a data source matching the functional interface in a preset public data pool, the following steps are included:

[0009] Collect the test data needed by all subsystems in the full business process model during the testing process;

[0010] The test data is stored in a common data pool, wherein the test data of each subsystem in the common data pool is stored in its corresponding data source, and the data source of each subsystem contains at least one piece of test data.

[0011] In one embodiment, before the step of selecting a data source matching the functional interface in a preset public data pool, the following steps are included:

[0012] Determine whether the logged-in user account has the authority to access the data source in the public data pool;

[0013] If the logged-in user account has the authority to access the data source in the public data pool, the following steps are performed: Select a data source that matches the functional interface in the preset public data pool;

[0014] If the logged-in user account does not have permission to access the data source in the public data pool, the execution step is rejected: select a data source that matches the functional interface in the preset public data pool.

[0015] In one embodiment, the step of configuring at least one test component in a shared market in each functional test point includes:

[0016] For each functional test point in the business full process model, encapsulate the test logic of the functional test point into at least one test component;

[0017] Store test components in a shared marketplace.

[0018] In one embodiment, the step of performing a full-process test according to the business full-process model with configured test components includes:

[0019] When multiple test components in a shared market are configured in a functional test point, determine the arrangement order of the multiple test components;

[0020] The test components are connected in the arrangement order through the preset serial interface, and the functional interface corresponding to the functional test point is connected to the test component arranged first in the arrangement order.

[0021] In one embodiment, the steps of performing a full-process test according to the business full-process model with configured test components include:

[0022] For any functional test point in the business full-process model with configured test components, obtain the first test data required by the to-be-tested functional test point in the public data pool, send the first test data to the first test component group connected to the first functional interface through the functional interface bound to the functional test point, test the test data according to the first test component group, and obtain the test result, wherein the first test component group is a group of test components connected in a first arrangement order;

[0023] The test results corresponding to all functional test points are taken as the test results of the full process test.

[0024] In one embodiment, before the step of obtaining the business full process model, the following steps are included:

[0025] Displays the visualization page for drawing process models;

[0026] Obtain the visualization function test points and connection logic drawn on the visualization page, and generate a full business process model based on the visualization function test points and connection logic.

[0027] In addition, to achieve the above-mentioned objectives, the present application also proposes a cross-system full-process automated testing device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the cross-system full-process automated testing method as described above.

[0028] In addition, to achieve the above-mentioned purpose, the present application also proposes a medium, which is a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the cross-system full-process automated testing method as described above are implemented.

[0029] In addition, to achieve the above-mentioned purpose, the present application also provides a product, which is a computer program product. The computer program product includes a computer program, and when the computer program is executed by a processor, it implements the steps of the cross-system full-process automated testing method as described above.

[0030] One or more technical solutions proposed in this application have at least the following technical effects:

[0031] This application obtains a full-process business model, which not only includes a single functional point of the business process, but also covers all functions of multiple subsystems under the full business process, ensuring the comprehensiveness and accuracy of the full-process test. The functional interface is encapsulated according to the functional test points of multiple subsystems in the full-process business model. The functional interface is an interface used to transfer data between different functional test points and trigger the execution of functional test points. The functional test points are bound to the corresponding functional interfaces. In this way, each part of the model can correspond to the corresponding functional interface, which provides a basis for subsequent automated testing. A data source is configured for each functional interface in the full-process business model, wherein the data source includes the data sources of multiple subsystems in the common data pool. The common data pool breaks through the data asset barriers between subsystems across the system, promotes the circulation and sharing of data, and increases the flexibility of the system. Furthermore, the present application introduces the concept of a shared market, which is a component library containing multiple test components, breaking through the barriers of automation component assets of various subsystems across the system. In each functional test point of the business full-process model, according to the functions in each functional test point, at least one test component in the shared market is configured therein, and the full-process test is performed according to the business full-process model with the configured test components. This mechanism not only greatly improves the coverage of the test, but also ensures that each subsystem can easily access and use the necessary test components, thereby accelerating the test process, and fundamentally improving the efficiency and quality of the test, and realizing efficient execution and precise control of cross-system full-process automated testing. In summary, the present application realizes the comprehensive integration of cross-system automation assets, improves the consistency and accuracy of the test process, effectively avoids omissions in the test process, and ensures the comprehensiveness of full-process automated inspection. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0033] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0034] Figure 1 This is a flowchart of the first embodiment of the cross-system full-process automated testing method of the present application;

[0035] Figure 2 This is a schematic diagram of a scenario of the first embodiment of the cross-system full-process automated testing method of the present application;

[0036] Figure 3This is a full-process model diagram of the cross-system fund purchase business for this application of the cross-system full-process automated testing method;

[0037] Figure 4 This is a public data pool scenario diagram for the cross-system full-process automated testing method for this application;

[0038] Figure 5 A shared market scenario diagram for this application's cross-system, full-process automated testing method;

[0039] Figure 6 This is a schematic diagram of a scenario of Embodiment 2 of the cross-system full-process automated testing method of this application;

[0040] Figure 7 This is a schematic diagram of a scenario of Embodiment 3 of the cross-system full-process automated testing method of this application;

[0041] Figure 8 This is a schematic diagram of the module structure of a cross-system full-process automated testing device according to an embodiment of the present application;

[0042] Fig. 9 This is a schematic diagram of the device structure of the hardware operating environment involved in the cross-system full-process automated testing method in the embodiment of the present application.

[0043] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0044] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0045] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0046] Since existing technologies in the field of cross-system automated testing mainly focus on a single system, they have significant limitations when faced with a complex multi-subsystem environment. Each subsystem manages test data independently, which makes data sharing and reuse difficult, inefficient, wastes resources, and impairs the consistency of the test process. At the same time, existing solutions ignore cross-system full-process testing and only focus on single-system checkpoints, which results in insufficient coverage, easy omissions, and difficulty in ensuring the quality of the overall business process. In addition, the lack of a visual automation construction method based on the user journey perspective makes the test process lack comprehensiveness and user-centricity. In summary, existing technologies have obvious deficiencies in data management, test coverage, and user perspective in cross-system automated testing.

[0047] To solve the above problems, this embodiment provides a cross-system full-process automated testing solution. First, the existing automated testing platform and method are mainly aimed at a single software system, and the coding automated testing is realized by modularizing the test items. However, this embodiment, in particular, proposes a more efficient and comprehensive automated testing solution for multi-subsystem scenarios. This embodiment realizes data sharing and reuse among subsystems through public data management based on database tables. This method breaks the limitations of traditional single system data management and improves the efficiency of multi-system data preparation. At the same time, this embodiment also uses FastAPI (a framework for building modern applications) and other methods to encapsulate the test component interface, ensuring that the automated assets between the subsystems can be effectively connected, and improving the coverage of automated testing. In addition, the core of this embodiment is to implement modeling testing in the form of a flowchart, connect the entire process in series, and realize the comprehensive integration of the automated assets of each system. This method not only improves the consistency and accuracy of the test process, but also effectively avoids omissions in the test process and ensures the comprehensiveness of the full-process automated inspection.

[0048] This embodiment breaks through the data asset barriers between various subsystems across the system by establishing a shared data pool. This innovative data management architecture optimizes the automated data management process, realizes the unified storage, management and access of data resources, thereby improving data utilization efficiency and reducing data redundancy and duplication of work. Further, this embodiment proposes to build a component sharing market to break through the barriers of automated component assets of various subsystems across the system. By providing a rich test component and connecting it in series in the shared market, the present invention can efficiently improve the test coverage rate and ensure that each subsystem can access the required components, thereby accelerating the test process and improving the test quality. More importantly, this embodiment uses model-based modeling technology to carry out automated testing. By visually utilizing shared data and shared components, this embodiment connects the entire business process in series to achieve efficient and high-quality construction of cross-system full-process automation. This method not only improves the automation level of the test, but also ensures the consistency and accuracy of the test process, thereby improving the overall test efficiency and quality. In summary, compared with similar technologies, this embodiment has a wider range of applicable scenarios, more efficient data preparation and automated testing efficiency, and more comprehensive process modeling and automated asset integration capabilities. These features give this embodiment a significant competitive advantage and broad application prospects in the field of multi-subsystem automated testing.

[0049] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, a terminal system, etc. The following takes the system as an example to illustrate this embodiment and the following embodiments.

[0050] Based on this, this embodiment provides a cross-system full-process automated testing method, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the cross-system full-process automated testing method of the present application.

[0051] In this embodiment, the cross-system full-process automated testing method includes steps S10 to S30:

[0052] Step S10, obtaining a business full process model, encapsulating functional interfaces according to functional test points corresponding to multiple subsystems in the business full process model, and binding the functional test points to the corresponding functional interfaces, wherein the functional interface is an interface for transferring data between different functional test points and triggering the execution of the functional test points;

[0053] It should be noted that the business full process model is a comprehensive, cross-system model that covers all functional test points of all subsystems in the business full process. The model provides a comprehensive framework for automated testing from the perspective of the user journey. Functional test points refer to specific functions or conditions that need to be verified or tested in the business full process. They are used to ensure that each step of the business process is executed as expected and meets specific business rules or requirements. The functional interface is an interface used to pass data between different functional test points and trigger the execution of test components. It acts as a bridge for communication between components and ensures the smooth progress of the automated testing process.

[0054] First, it is necessary to receive a comprehensive business process model built by the user based on visual business modeling technology from the perspective of the user journey business. The model needs to cover all functional test points of all subsystems and clarify the various functional test points and their relationships. Then, according to the functional test points in the business process model, the functional interface is encapsulated according to the functions of each functional test point. This involves defining the name, parameters, return value, and error handling mechanism of the functional interface. The specific implementation method of functional interface encapsulation may vary depending on the technology stack, but the key is to ensure the ease of use, reliability, and scalability of the functional interface. During the encapsulation process, it is necessary to strictly follow the unified interface specification, which helps to ensure the compatibility and interoperability between different systems and reduce the difficulty of integration and testing. Then, the encapsulated functional interface is bound to the corresponding functional test point in the business process model. The purpose of this step is to establish a mapping relationship between the functional interface and the functional test point to ensure that the corresponding functional interface can be automatically called when the test process is executed to a certain test point. There is no restriction on the specific method of binding, including directly clicking on the functional test point, filling in the parameters of the corresponding functional interface in the interface list of the functional test point, or referencing the interface address in the test script, passing the necessary parameters and processing the results returned by the interface, and then configuring the test script in the functional test point. Through the binding operation, the test process can automatically traverse each functional test point in the business full process model and trigger the corresponding test logic.

[0055] Step S20: for each functional interface in the business full process model, a data source matching the functional interface is selected from a preset public data pool, and the selected data source is configured for the functional interface, wherein the public data pool includes data sources of multiple subsystems, and the data source of each subsystem is different;

[0056] It should be noted that the data source is the source of data provided to the test component for verification. The public data pool is a database or data storage system that centrally stores and manages the public business data of multiple subsystems. It is used to solve the problem of data sharing and reuse during cross-system testing and improve the consistency and accessibility of test data.

[0057] Users need to select the required data source in the public data pool according to the requirements of the functional interface. The public data pool usually contains common business data shared across systems, such as product data, organizational data, etc., which may be reused in multiple test scenarios. Then configure the selected data source in the functional interface, including the index of the data source, access path, etc., to facilitate the functional interface to establish a connection with the data source. Then in the functional interface, write or select the corresponding data access logic to implement operations such as reading, writing, and updating data in the data source. These logics will be customized based on the requirements of the interface and the characteristics of the data source to ensure that the required data can be accurately obtained or modified.

[0058] Furthermore, the system can also configure preset custom data sources. Preset custom data sources are data sources that users customize according to test requirements in addition to the public data pool. These data sources may contain test data in specific scenarios to meet specific test requirements. Custom data sources are more flexible and can be customized according to the special needs of specific test components, such as user accounts and passwords for testing, business data in specific scenarios, etc. For data sources that need to be obtained from external systems or databases, the corresponding data source connection information can be configured in the functional interface, including database address, port, user name, password, etc. This information will be used to establish a connection with the data source so that the required data can be accessed and obtained in real time during the test process.

[0059] Step S30, according to the functions in each functional test point in the business full-process model of the configured data source, configure at least one test component in the shared market in each functional test point, and perform full-process testing according to the business full-process model with the configured test components, wherein the shared market is a component library containing multiple test components.

[0060] It should be noted that the shared market is a component library that contains multiple test components. In this market, each subsystem can encapsulate its own test components and upload them so that other systems can reuse them, thereby improving development efficiency and test coverage. Test components are software modules used to verify the correctness of functional test points. They encapsulate specific test logic and verification rules. A functional test point can be configured with multiple test components according to the test logic to be implemented. During the automated testing process, the test components will check whether the output of a specific functional point meets expectations to ensure the correctness and stability of the business process.

[0061] First, browse and select test components that are suitable for the current functional test point requirements from the shared market. These components include data verification, business rule verification, performance monitoring and other test logics. Next, configure the selected test components in the functional test point in sequence, and configure the parameters of the test components to match the specific requirements of the functional test point, including the format of input data, expected output results, verification rules, etc. Finally, based on the configuration information of the configured business full process model, generate executable test cases (for example, generate test scripts from the business full process model) for automated testing.

[0062] For example, refer to Figure 2 , Figure 2 This is a scenario diagram of the first embodiment of the cross-system full-process automated testing method of the present application. First, we need to prepare the data and collect the public business data into the public data pool. The subsequent automated tests will take the test data from the public data pool. Then, based on the visual business modeling technology, a comprehensive business full-process model is constructed from the perspective of the entire business process. In this embodiment, taking user process X as an example, the participation of system A, system B and system C is required, and the function test point A (hereinafter referred to as function A), function test point B (hereinafter referred to as function B), and function test point C (hereinafter referred to as function C) need to be tested in turn. According to the above-mentioned function test points, the function A interface, function B interface, and function C interface are encapsulated, and the above-mentioned function test points are sealed and bound to the above-mentioned function interfaces. Assume that system A, system B and system C encapsulate the functions of the test process into test components 1 to 9 and put them into the shared market. Function A needs to test test components 1, 2 and 3 in sequence, function B needs to test test components 4, 5 and 6 in sequence, and function C needs to test test components 7, 8 and 9 in sequence. We select the above test components from the shared market and connect them. After the connection is completed, the full process automation of a single function is initiated through the functional interface to ensure that each function can be automatically executed before conducting the full process test.

[0063] This embodiment obtains a full-process business model, which not only includes a single functional point of the business process, but also covers all functions under the user journey, ensuring the comprehensiveness and accuracy of the full-process test. The functional interface is encapsulated according to the functional test points of multiple subsystems in the full-process business model. The functional interface is an interface used to transfer data between different functional test points and trigger the execution of functional test points. The functional test points are bound to the corresponding functional interfaces. In this way, each part of the model can correspond to the corresponding functional interface, providing a basis for subsequent automated testing. A data source is configured for each functional interface in the full-process business model, wherein the data source includes the data sources of multiple subsystems in the common data pool. The common data pool breaks through the data asset barriers between subsystems across the system, promotes the circulation and sharing of data, and increases the flexibility of the system. Furthermore, this embodiment introduces the concept of a shared market, which is a component library containing multiple test components, breaking through the barriers of automation component assets of various subsystems across the system. In each functional test point of the business full-process model, according to the function in each functional test point, at least one test component in the shared market is configured therein, and the full-process test is performed according to the business full-process model with the configured test components. This mechanism not only greatly improves the coverage of the test, but also ensures that each subsystem can easily access and use the necessary test components, thereby accelerating the test process, and fundamentally improving the efficiency and quality of the test, and realizing efficient execution and precise control of cross-system full-process automated testing. In summary, this embodiment realizes the comprehensive integration of cross-system automated assets, improves the consistency and accuracy of the test process, effectively avoids omissions in the test process, and ensures the comprehensiveness of the full-process automated inspection.

[0064] In a feasible implementation manner, the step of obtaining the full business process model in step S10 may include steps T10 to T20:

[0065] Step T10, displaying a visualization page for drawing a process model;

[0066] It should be noted that the visualization page for drawing the process model is a user interface that provides a variety of graphic elements (such as rectangles for steps, diamonds for decision points, arrows for process directions, etc.) and tools (such as dragging, scaling, rotating, etc.). Users can build and display business process models through the visualization interface (such as dragging, connecting, etc.). It provides an intuitive way to define the various steps in the business process, functional test points, and the logical relationships between them.

[0067] On the visual process drawing page, users will add functional test points at the corresponding step positions according to business needs. These checkpoints can be specific validation rules (such as input data validity verification), system calls (such as calling an API interface) or business logic (such as judging user permissions). At the same time, users also need to define the connection logic between these checkpoints, that is, the execution order and dependencies between them. This is usually achieved by drawing arrows or connecting lines. The direction of the arrow indicates the direction of the process, and the type of connecting line (such as solid line, dotted line) can represent different logical relationships (such as sequential execution, conditional branching, etc.).

[0068] Step T20, obtaining the visualization function test points and connection logic drawn on the page, and generating a full business process model based on the visualization function test points and connection logic.

[0069] It should be noted that the visual function test points are the function test points drawn by the user in the visual interface according to the whole business process. The connection logic defines the order and relationship between the visual function test points in the business process. It determines the flow of the business process, that is, which steps are executed sequentially, which steps are executed in parallel, and the dependencies between them. The business full process model is a complete business process model built on the visual process drawing page, which includes the function test points and connection logic of the whole business process. It is used to guide the execution of automated testing to ensure that every part of the business process is fully verified.

[0070] When the user completes the layout and editing of the visual process drawing page, the system will automatically generate a business process model based on the functional test points and connection logic defined on the page. This model is a structured representation that includes all the steps in the business process, functional test points, and the logical relationships between them.

[0071] Furthermore, in the process of generating the business full process model, the system will also perform a series of verification and optimization work. For example, it will check whether there are logical errors (such as circular dependencies, dead loops, etc.), and try to optimize the execution efficiency of the model (such as merging repeated steps, adjusting the execution order, etc.). Ultimately, the system will generate a complete, accurate and efficient business full process model to guide subsequent automated testing work.

[0072] For example, refer to Figure 3 , Figure 3 This is a cross-system fund purchase business full process model diagram of the cross-system full process automated testing method of this application. The figure shows the full process of the fund purchase business in the automated testing phase.

[0073] The purchase process involves the following systems: WEB channels, product middle platform, order middle platform, payment middle platform, transaction middle platform, and notification middle platform. After the purchase process is officially launched, users will perform specific purchase operations in the purchase system. This step may include users selecting fund products, entering purchase amounts, and confirming purchase information. In the purchase process, different "scenarios" are involved, which represent different purchase scenarios or business logics. At the same time, "purchase handling" refers to the process of processing purchase requests. The system will determine the "account type" used for payment based on the user's login account. If the "account type" is "quick account", then the personnel or systems of "payment handling" and "payment approval" are required to process the payment request. If the "account type" is not "quick account", then the system will determine "whether it is seamless". If the conditions are met, that is, the data exchange and verification process between the payment system and the purchase system can be carried out seamlessly, then "payment approval" will also be carried out seamlessly without manual intervention. If the result of the judgment of "whether it is seamless" is no, that is, there is no seamless requirement, then you can proceed directly to the next step. If the result of the judgment of "whether it is seamless" is yes, then the "re-send" step is required. The above are the operations of the purchase system and payment system. There are too many steps in the remaining systems, so only other systems are outlined. After the other systems are tested and passed, the entire purchase process will be completed.

[0074] First, it is necessary to collect the public data of the above systems, such as member data, institutional data, product data, net worth data, etc. Establish a public data pool, fill the public data into the public data pool, establish a public data mapping table, and refer to Figure 4 , Figure 4 It is a public data pool scenario diagram. The black box 01 on the left is a tree expansion of the public data pool, including a product data table set and an institution data table set. The product data table set includes product A, and the institution data table set includes institution B. The black box 02 on the right is a list of data about product A that is expanded after product A is selected, including product type (type C and type D) and whether it is seamless. Next, each system will sort out the checkpoints of the system for the fund purchase business, encapsulate the test components of the system, and upload them to the shared market for storage. After the above preparations are completed, according to the user journey of the purchase business, establish Figure 3 Then, according to the functional test points in the model, each functional test point is encapsulated with an interface, and then the encapsulated functional interface is bound to the functional test point in the corresponding business full process model. Then, the test components encapsulated by each system are selected from the shared market, and the test components are referred to. Figure 5 , Figure 5It is a sharing market scenario diagram. In the sharing market, the required test components can be searched according to the query box 11. After the search, the retrieved test components are displayed below. The displayed test component information includes the test component name, sharing time, and update time. After the test components are configured, the entire process of the user journey of purchase is automated.

[0075] This embodiment displays a visualization page for drawing process models, so that users can intuitively and conveniently build business process models, and use rich graphic elements and tools to define each step, functional test point and its logical relationship. This not only lowers the modeling threshold, but also improves the accuracy and efficiency of model building. Subsequently, the system intelligently captures these visual functional test points and connection logic, and automatically generates a full business process model. This process not only ensures a high degree of consistency between the model and business requirements, but also eliminates potential logical errors and improves model execution efficiency through built-in verification and optimization mechanisms. Ultimately, this process greatly promotes the accuracy and efficiency of automated testing, and provides strong support for cross-system, full-process business verification.

[0076] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the first embodiment can be referred to the above introduction, and will not be described in detail later. Steps A10 to A20 are also included before step S20:

[0077] Step A10, collecting test data required for use in the testing process of all subsystems in the business full process model, wherein the data source includes at least one piece of test data;

[0078] It should be noted that in the process of software testing or system testing, test data refers to data that must exist or be prepared in advance before executing a specific test case or test scenario. This data is the basis for the smooth progress of the test and is used to simulate various states or conditions that the system may encounter in the actual operating environment. Test data may include user information, configuration parameters, business data, etc. Multiple test data constitute a data source, which can be configured in the functional interface.

[0079] Clarify the specific functions and test objectives of the test subsystem, and based on this, identify which data is necessary in the testing process. This includes data that is directly involved in the test logic (such as user input, business parameters) and environmental data that indirectly affects the test results (such as system configuration, time settings). Classify the identified test data by type, purpose or source for subsequent management and use. For example, the data can be divided into user data, business data, configuration data, etc. Prepare or generate corresponding test data according to test requirements. This involves importing real data from the production environment (after desensitization), using test tools to generate simulated data, or manually creating data for specific scenarios. Before using the test data for testing, perform necessary verification to ensure the accuracy, completeness and consistency of the data. This helps avoid test failures or misleading results due to data problems.

[0080] Step A20, storing the test data in a common data pool, wherein the test data of each subsystem in the common data pool is stored in its corresponding data source, and the data source of each subsystem contains at least one piece of test data.

[0081] Each subsystem groups the prepared test data into different data sources according to different types and uploads them to the public data pool for easy configuration in the functional interface. This involves operations such as data format conversion, encryption (if necessary), and uploading to a specified location. In the public data pool, these data are organized according to certain rules or structures to facilitate subsequent retrieval and use. For example, data sources can be divided according to data types, test cases, or test scenarios. Appropriate access rights are set for different testers or test subsystems to ensure data security and controllability. Only authorized users or systems can access and modify data in the public data pool.

[0082] Furthermore, a version control mechanism can be implemented for the data stored in the public data pool, which helps to track the change history of the data, ensure that it can be rolled back to the previous version when necessary, and maintain data consistency between different test environments.

[0083] For example, refer to Figure 6 , Figure 6 This is a scenario diagram of Example 2 of the cross-system full-process automated testing method of the present application. Assuming that the following subsystems exist in the overall system: system A, system B and system C, it is necessary to collect the test data needed by the above subsystems during the testing process: business data A, business data B and business data C, and upload all of these test data to the public data pool for use during the full-process automated testing.

[0084] In this embodiment, the authenticity and comprehensiveness of the test environment are ensured by comprehensively collecting the test data required by each subsystem in the business full process model. These test data not only cover direct test elements such as user information and business parameters, but also cover indirect influencing factors such as system configuration and environmental status, laying a solid foundation for the accuracy and effectiveness of the test. Subsequently, the collected test data are stored in a public data pool to achieve unified management and efficient use of data. This measure not only simplifies the data access process, but also ensures the security and traceability of data through permission settings and version control mechanisms. In cross-system full-process automated testing, the public data pool has become a hub for data circulation and sharing, greatly improving test efficiency and quality, and ensuring the accuracy and reliability of test results.

[0085] In a feasible implementation, step S20 may include steps B10 to B30:

[0086] Step B10, determining whether the logged-in user account has the authority to access the data source in the public data pool;

[0087] It should be noted that authorization means that the system confirms through some mechanism that the user has the authority to perform specific operations (such as configuration, query, and modification) on specific resources (such as data sources in a public data pool). Authorization is an important part of access control, which ensures the security of resources and the legitimacy of user operations.

[0088] When a user tries to configure a data source in a public data pool, the system first needs to verify whether the logged-in user's account has the permission to perform this operation. This step involves the following key operations: First, the system needs to confirm the identity of the logged-in user. This is usually achieved through a username and password, a token (such as JWT), or a biometric-based authentication method. Once the user's identity is verified, the system will query the user permission database or permission management system to obtain whether the user has the permission to configure the data source in the public data pool. Permission information is usually associated with user roles, and different roles have different permission sets. The system compares the operation actually requested by the user (in this case, configuring the data source) with the permissions the user has. If this operation is included in the permission set, the user is deemed to be authorized; otherwise, the user is deemed to be unauthorized.

[0089] Step B20, if the logged-in user account has the authority to access the data source in the public data pool, then execute the steps: select a data source matching the functional interface in the preset public data pool;

[0090] If the logged-in user account has been granted permission to configure the data source, the user's configuration request is allowed and a success message can be displayed to the user.

[0091] Step B30: If the logged-in user account does not have permission to access the data source in the public data pool, the execution step is rejected: a data source matching the functional interface is selected in the preset public data pool.

[0092] If it is found during the test that the logged-in user account is not granted permission to configure the data source, the system will do the following: The system will directly reject the user's configuration request and can display an error message to the user stating that the user does not have sufficient permissions. To prevent the potential risk of unauthorized access, the system should record the unauthorized access event of this attempt to configure the data source. This will help with subsequent audits and security analysis. To improve the user experience, the system can provide users with some guidance information, such as how to obtain the required permissions and who to contact for help.

[0093] In this embodiment, through strict permission control, we ensure the security and compliance of the data source in the public data pool. When the user tries to configure the data source, the system first verifies its permissions, effectively preventing unauthorized access and maintaining the integrity and confidentiality of data resources. For unauthorized users, the system immediately rejects the configuration request and feedbacks the error message, which not only avoids potential security risks, but also enhances traceability through logging. This mechanism not only ensures the security of the test process, but also improves the compliance and user experience of the test through permission management and user guidance, and builds a solid security line for cross-system full-process automated testing.

[0094] Based on the first or second embodiment of the present application, in the third embodiment of the present application, the same or similar contents as those in the first or second embodiment can be referred to the above description, and will not be described in detail later. Steps C10 to C20 are also included before step S30:

[0095] Step C10, for each functional test point in the business full process model, encapsulate the test logic of the functional test point into at least one test component;

[0096] It should be noted that in a system, a subsystem is a part of the entire system that is responsible for performing a specific function or set of tasks. It usually has relatively independent logic, data, and interfaces, and can interact with other parts of the system. A test component is a software module used to perform data validation or functional checks. It usually contains a series of rules or logic to check the validity of input data, compare expected output with actual output, or confirm whether the system state meets specific conditions.

[0097] First, we need to deeply understand the role of the subsystem in the entire business process and the specific functions it should implement. Based on this understanding, identify key functional test points, which will be used to evaluate whether the subsystem performs as expected. Design corresponding test components for the test logic in each functional test point, and encapsulate at least one test component according to the complexity of the test logic of a functional test point. These components should contain the necessary logic and rules to accurately determine whether the performance of the subsystem at the corresponding checkpoint meets expectations. The comprehensiveness, accuracy and efficiency of the test should be considered during design. Encapsulate the designed test components into independent software units (such as classes, functions or modules), ensure that their internal implementation details are hidden, and only provide necessary interfaces for external calls. Encapsulation improves the reusability, maintainability and security of test components.

[0098] Step C20: storing the test component in the shared market.

[0099] Upload test components to the platform through the upload interface or interface provided by the shared market. In the shared market, users can easily view and access business components shared by other systems. These components provide reusable business logic and functions for each system. Through the shared market, each system can make full use of components provided by other systems to improve development efficiency, reduce duplication of work, and accelerate innovation.

[0100] For example, refer to Figure 7 , Figure 7 This is a scenario diagram of Example 3 of the cross-system full-process automated testing method of the present application. For a specific function A process, system A, system B and system C are required to function in sequence until the full process of function A is completed. In this scenario, each system can encapsulate the corresponding test components according to the needs and functions of each system. The encapsulation of these test components needs to be designed and implemented for the important checkpoints in function A to ensure that effective verification and inspection can be performed at all stages of the business process. Specifically, test component A is encapsulated according to the needs and functions of system A, test component B is encapsulated according to the needs and functions of system B, and test component C is encapsulated according to the needs and functions of system C. After encapsulation is completed, each system stores these test components in a shared market. In this way, other systems can easily find and obtain these test components when needed, so as to reuse and integrate them in their own systems.

[0101] This embodiment encapsulates the functional test point logic of each subsystem in the business full-process model into independent test components, and stores them centrally in the shared market. This measure greatly promotes the reuse and sharing of test resources, reduces development costs, and accelerates the test process. The encapsulation of test components not only ensures the accuracy and comprehensiveness of the test logic, but also improves the maintainability and scalability of the components. At the same time, the establishment of a shared market breaks down the barriers between systems, allowing test components to circulate and integrate across systems, providing strong support for cross-system full-process automated testing. This not only improves test efficiency, but also ensures the consistency of test quality, providing a strong guarantee for the stable operation of the system.

[0102] In a feasible implementation manner, before the step of performing the full process test according to the business full process model with configured test components in step S30, steps D10 to D20 may also be included:

[0103] Step D10, when multiple test components in a shared market are configured in the functional test point, determining the arrangement order of the multiple test components;

[0104] It should be noted that the arrangement order refers to the order in which multiple test components are arranged according to certain logic or rules when executing test tasks. This order determines the order in which the test components are called.

[0105] When performing functional testing, if a functional test point needs to configure multiple test components from different shared markets, you first need to determine the order in which these test components should be arranged. This order is usually based on the test strategy, dependencies, or logical requirements of the test process to ensure that the test process can proceed smoothly and the results are accurate and reliable.

[0106] Step D20, connecting the test components in the arrangement order through the preset serial interface, and connecting the functional interface corresponding to the functional test point to the test component arranged first in the arrangement order.

[0107] It should be noted that the preset serial interface is an interface used to connect test components, which is responsible for transmitting data among different test components to ensure that the test components can be executed in a predetermined order and logic.

[0108] Before connecting the test components, it is necessary to define clear preset serial interface specifications, including interface name, parameter list, return value type, etc. Then, according to the requirements of the test process, configure the serial logic between the test components, which includes determining the execution order of the test components, setting the trigger conditions for data transfer, etc. Next, use the defined preset serial interfaces to connect these test components in the determined order of arrangement. These interfaces are responsible for handling interactive tasks such as data transfer and control signal synchronization between components to ensure that the test process can be executed as expected. At the same time, connect the functional interface corresponding to the functional test point to the test component ranked first in the arrangement order. This step is to ensure that the test process can start from the starting point, that is, first execute the test component ranked first, and gradually move backward until the test tasks of all components are completed.

[0109] For example, suppose a functional test point needs to verify the shopping cart function test point of an e-commerce website, which may involve multiple test components such as user login, product addition, quantity modification, price calculation, etc. First, the tester will determine the order of these components according to the test strategy, such as logging in first and then adding products. Then, these components are connected in sequence through the preset series interface, and the functional interface of the shopping cart function is connected to the login component. When the test is executed, the test system will first execute the login component, verify that the user has successfully logged in, and then execute the subsequent components such as adding products and modifying quantities in sequence, and finally complete the test of the entire shopping cart function.

[0110] Through this embodiment, testers can build a complete test process, integrating multiple independent test components to form a collaborative test system. This can not only improve test efficiency, but also enhance the comprehensiveness and accuracy of the test, ensuring that software functions can operate normally in complex scenarios.

[0111] In a feasible implementation manner, the functional interface includes a first functional interface and a second functional interface, the functional test point includes a first functional test point and a second functional test point, the test component includes a first test component and a second test component, the arrangement sequence includes a first arrangement sequence and a second arrangement sequence, and steps E10 to E20 may be further included before step S30:

[0112] Step E10, for any functional test point in the business full process model with configured test components, obtain the first test data required by the to-be-tested functional test point in the public data pool, send the first test data to the first test component group connected to the first functional interface through the functional interface bound to the functional test point, test the test data according to the first test component group, and obtain the test result, wherein the first test component group is a group of test components connected in a first arrangement order;

[0113] Select a functional test point from the business full process model as the current test target. According to the requirements of the selected functional test point, retrieve and obtain the required first test data from the public data pool. These data are specially designed for this test point to trigger and verify specific functional behaviors. Use the functional interface bound to the functional test point to send the first test data to the first test component group connected to the functional interface. The first test component group processes and analyzes the received test data in turn according to the preset first arrangement order. Each test component may perform different test tasks, such as data verification, logical judgment, performance measurement, etc., to comprehensively evaluate the performance of the functional test point. After the test component group completes the test, it will generate corresponding test results. These results include the sign of test success, the reason for failure, performance data, etc., which are used to evaluate whether the functional test point meets the expected requirements. In the full process test, you can start the test directly from the first functional interface, and test the remaining functional interfaces at a time according to the logic of the business full process model.

[0114] Step E20, taking the test results corresponding to all functional test points as the test results of the full process test.

[0115] Check the test result of the current functional test point. If it fails, stop the test and send a reminder of the test failure to the user. If it succeeds, continue the same test process for the next functional test point. Of course, you can also determine the test result and the test logic of the next functional test point based on the custom logic of the functional interface. Finally, summarize the test results of all functional test points to form the test results of the whole process test.

[0116] This embodiment conducts a full-process business model test, which significantly improves the efficiency and accuracy of the test. By sequentially triggering the test components through the functional interface, the consistency and automation of the test process are ensured, reducing manual intervention and potential errors. Each functional test point is carried out in sequence, which not only verifies the correctness of each interface, but also ensures the stability and reliability of the overall business process. Finally, when all test points are verified, the full-process test is successfully completed, providing a strong guarantee for the quality and stability of the product.

[0117] It should be noted that, under the condition that the technology is feasible and the logic is clear, the above embodiments can be combined in pairs or in multiple combinations.

[0118] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the cross-system full-process automated testing method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0119] This application also provides a cross-system full-process automated testing device, please refer to Figure 8, the cross-system full-process automated testing device includes:

[0120] Model module 10, obtains the business full process model, encapsulates the functional interface according to the functional test points corresponding to the multiple subsystems in the business full process model, and binds the functional test points to the corresponding functional interfaces, wherein the functional interface is an interface for transferring data between different functional test points and triggering the execution of the functional test points;

[0121] The data source module 20 selects a data source matching the functional interface from a preset public data pool for each functional interface in the business full process model, and configures the selected data source for the functional interface, wherein the public data pool includes data sources of multiple subsystems, and the data source of each subsystem is different;

[0122] The component module 30 configures at least one test component in the shared market in each functional test point according to the functions in each functional test point in the business full-process model of the configured data source, and performs full-process testing according to the business full-process model with the configured test components, wherein the shared market is a component library containing multiple test components.

[0123] The cross-system full-process automated testing device provided by the present application adopts the cross-system full-process automated testing method in the above-mentioned embodiment, which can solve the technical problem of insufficient comprehensiveness during full-process automated testing. Compared with the prior art, the beneficial effects of the cross-system full-process automated testing device provided by the present application are the same as the beneficial effects of the cross-system full-process automated testing method provided by the above-mentioned embodiment, and other technical features in the cross-system full-process automated testing device are the same as the features disclosed in the above-mentioned embodiment method, which will not be repeated here.

[0124] The present application provides a cross-system full-process automated testing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the cross-system full-process automated testing method in the above-mentioned embodiment one.

[0125] Reference below Fig. 9, which shows a schematic diagram of the structure of a cross-system full-process automated test device suitable for implementing the embodiment of the present application. The cross-system full-process automated test device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Fig. 9 The cross-system full-process automated testing equipment shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0126] like Fig. 9 As shown, the cross-system full-process automated test equipment may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the cross-system full-process automated test equipment are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 1003 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 1009. The communication device 1009 can allow the cross-system full-process automated test equipment to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a cross-system full-process automated test equipment with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems may be implemented or have alternatively.

[0127] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0128] The cross-system full-process automated testing equipment provided by the present application adopts the cross-system full-process automated testing method in the above-mentioned embodiment, which can solve the technical problem of insufficient comprehensiveness during full-process automated testing. Compared with the prior art, the beneficial effects of the cross-system full-process automated testing equipment provided by the present application are the same as the beneficial effects of the cross-system full-process automated testing method provided by the above-mentioned embodiment, and the other technical features in the cross-system full-process automated testing equipment are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0129] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0130] The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0131] The present application provides a medium, which is a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, and the computer-readable program instructions are used to execute the cross-system full-process automated testing method in the above-mentioned embodiment.

[0132] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM: Random Access Memory), a read-only memory (ROM: Read Only Memory), an erasable programmable read-only memory (EPROM: Erasable Programmable Read Only Memory or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM: CD-Read Only Memory), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency: Radio Frequency), etc., or any suitable combination of the above.

[0133] The above-mentioned computer-readable storage medium may be included in the cross-system full-process automated testing device; or it may exist independently without being assembled into the cross-system full-process automated testing device.

[0134] The computer-readable storage medium carries one or more programs. When the one or more programs are executed by the cross-system full-process automated testing device, the cross-system full-process automated testing device:

[0135] Obtain a business full process model, encapsulate functional interfaces according to functional test points corresponding to multiple subsystems in the business full process model, and bind the functional test points to the corresponding functional interfaces, wherein the functional interface is an interface used to transfer data between different functional test points and trigger the execution of the functional test points;

[0136] For each functional interface in the business full process model, a data source matching the functional interface is selected from a preset public data pool, and the selected data source is configured for the functional interface, wherein the public data pool includes data sources of multiple subsystems, and the data source of each subsystem is different;

[0137] According to the functions in each functional test point in the business full-process model with the data source configured, at least one test component in the shared market is configured in each functional test point, and the full-process test is performed according to the business full-process model with the configured test components, wherein the shared market is a component library containing multiple test components.

[0138] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0139] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0140] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0141] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned cross-system full-process automated testing method, and can solve the technical problem of insufficient comprehensiveness during full-process automated testing. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the cross-system full-process automated testing method provided by the above-mentioned embodiment, and will not be elaborated here.

[0142] The present application also provides a product, which is a computer program product, including a computer program, which implements the steps of the above-mentioned cross-system full-process automated testing method when executed by a processor.

[0143] The computer program product provided by this application can solve the technical problem of insufficient comprehensiveness during full-process automatic testing. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as the beneficial effects of the cross-system full-process automatic testing method provided by the above embodiment, and will not be repeated here.

[0144] The above are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A cross-system full-process automated testing method, characterized in that: The cross-system full-process automated testing method includes: Acquire a business full process model, encapsulate functional interfaces according to functional test points corresponding to multiple subsystems in the business full process model, and bind the functional test points to the corresponding functional interfaces, wherein the functional interfaces are interfaces for transferring data between different functional test points and triggering the execution of the functional test points; For each of the functional interfaces in the business full process model, a data source matching the functional interface is selected from a preset public data pool, and the selected data source is configured for the functional interface, wherein the public data pool includes data sources of multiple subsystems, and the data source of each subsystem is different; According to the functions in each of the functional test points in the business full-process model with the data source configured, at least one test component in the shared market is configured in each of the functional test points, and the full-process test is performed according to the business full-process model with the configured test components, wherein the shared market is a component library containing multiple test components.

2. The cross-system full-process automated testing method according to claim 1, characterized in that: The step of selecting a data source matching the functional interface in a preset public data pool includes: Collecting the test data required for use during the testing process of all the subsystems in the business full process model; The test data is stored in the public data pool, wherein the test data of each subsystem in the public data pool is stored in its corresponding data source, and the data source of each subsystem contains at least one test data.

3. The cross-system full-process automated testing method according to claim 1, characterized in that: The step of selecting a data source matching the functional interface in a preset public data pool includes: Determine whether the logged-in user account has the authority to access the data source in the public data pool; If the logged-in user account has the authority to access the data source in the public data pool, the steps are performed: selecting a data source matching the functional interface in the preset public data pool; If the logged-in user account does not have permission to access the data source in the public data pool, the execution step is rejected: a data source matching the functional interface is selected in the preset public data pool.

4. The cross-system full-process automated testing method according to claim 1, characterized in that: The step of configuring at least one test component in a shared market in each of the functional test points includes: For each of the functional test points in the business full process model, encapsulate the test logic of the functional test point into at least one test component; The test components are stored in the shared marketplace.

5. The cross-system full-process automated testing method according to claim 1, characterized in that: The step of performing a full-process test according to the business full-process model with configured test components includes: When multiple test components in a shared market are configured in the functional test point, determining an arrangement order of the multiple test components; The test components are connected in the arrangement order through a preset serial interface, and the functional interface corresponding to the functional test point is connected to the test component arranged first in the arrangement order.

6. The cross-system full-process automated testing method according to claim 5, characterized in that: The step of performing a full-process test according to the business full-process model with configured test components includes: For any functional test point in the business full-process model with configured test components, obtain the first test data required by the functional test point to be tested in the public data pool, send the first test data to a first test component group connected to the first functional interface through a functional interface bound to the functional test point, test the test data according to the first test component group, and obtain a test result, wherein the first test component group is a group of test components connected in a first arrangement order; The test results corresponding to all the functional test points are used as the test results of the full process test.

7. The cross-system full-process automated testing method according to claim 1, characterized in that: Before the step of obtaining the business full process model, it includes: Displays the visualization page for drawing process models; The visualization function test points and connection logic drawn on the visualization page are obtained, and the business full process model is generated based on the visualization function test points and the connection logic.

8. A cross-system full-process automated testing device, characterized in that: The cross-system full-process automated testing device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the cross-system full-process automated testing method as described in any one of claims 1 to 7.

9. A medium, characterized in that The medium is a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the cross-system full-process automated testing method as described in any one of claims 1 to 7 are implemented.

10. A product, characterized in that The product is a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of the cross-system full-process automated testing method as described in any one of claims 1 to 7 are implemented.

Images