Production test platform system

Abstract

The invention discloses a production test platform system, and belongs to the field of production test. The production test platform system comprises a message processing general part and a plurality of function sub-modules, each function sub-module is used for providing a service function for a tested object to be subjected to production test, and the message processing general part comprises a communication strategy module. And the communication strategy module obtains service result information fed back by the function submodule based on the first interface communication specification, determines a first target communication mode corresponding to the service result information according to a preset configuration file, and feeds back the service result information to the tested object based on the first target communication mode. According to the invention, the technical problems of flexible deployment and flexible expansion design of the current production test platform can be solved.

Description

Technical Field

[0001] The present application relates to the field of production testing, and in particular to a production testing platform system. Background Art

[0002] Current testing software platforms are primarily based on testing systems within a specific field, focusing on research into testing methods for products or software within that field. Microservices, a hallmark of the networked era, are used in many internet products, but their application in testing systems is still relatively limited. As software scales, traditional standalone process software becomes complex, with high coupling and inter-reference relationships between functional submodules, making distributed deployment impossible. Furthermore, the iteration speed of new features is slower than that of microservices, which rely on underlying networks and servers for operation and maintenance, making it difficult to meet the requirements of low cost and high performance.

[0003] The test software platforms in related technologies are either built based on traditional methods or based on microservices. In the field of production testing, the basic hardware facilities for production testing vary, and the performance requirements of application scenarios for users are also different. If there is only one deployment method, it is difficult to cope with various scenarios, which makes the current production testing platform unable to be flexibly deployed and flexibly expanded. Summary of the Invention

[0004] The main purpose of this application is to provide a production test platform system, aiming to solve the technical problem that the current production test platform cannot be flexibly deployed and flexibly expanded.

[0005] To achieve the above objectives, the present application provides a production test platform system, comprising:

[0006] Multiple functional sub-modules, each of which is used to provide a service function for the object under test to be produced and tested;

[0007] A message processing universal component, wherein the message processing universal component includes a communication strategy module;

[0008] Among them, the communication strategy module obtains the service result information fed back by the functional sub-module based on the first interface communication specification, and determines the first target communication mode corresponding to the service result information according to a preset configuration file, so as to feed back the service result information to the object under test based on the first target communication mode.

[0009] In some embodiments, the first target communication mode is a cloud microservice call mode or a local microservice call mode.

[0010] In some embodiments, the message processing universal component further includes an internal interface and an external interface, wherein the internal interface, the communication strategy module, and the external interface are connected in sequence, and the internal interface is further connected to each of the functional sub-modules respectively;

[0011] Among them, the internal interface receives the service result information fed back by the functional sub-module through the first interface communication specification, and inputs the service result information into the communication strategy module so that the communication strategy module can obtain the service result information fed back by the functional sub-module, and the external interface feeds back the service result information to the object under test based on the first target communication mode.

[0012] In some embodiments, the external interface is configured to communicate with the measured object using a second interface communication specification;

[0013] The external interface feeds back the service result information to the measured object based on the first target communication mode and the second interface communication specification.

[0014] In some embodiments, the external interface is configured to receive service request information sent by the measured object through the second interface communication specification, and input the service request information into the communication strategy module;

[0015] The communication strategy module is configured to determine the second target communication mode corresponding to the service request information according to a preset configuration file and notify the internal interface;

[0016] The internal interface is configured to call the functional submodule corresponding to the service request information to perform functional testing on the object under test based on the second target communication mode and the first interface communication specification, and receive service result information fed back by the functional submodule through the first interface communication specification.

[0017] In some embodiments, the first interface communication specification includes information format and information content type indicating the service result information.

[0018] In some embodiments, the second interface communication specification includes a service name, a function name, and function parameters indicating the corresponding calling service of the object under test.

[0019] In some embodiments, the production test platform system includes a domain layer and an infrastructure layer, each of the functional sub-modules includes at least one first functional sub-module and at least one second functional sub-module, all of the first functional sub-modules are located in the domain layer, and the message processing universal component and all of the second functional sub-modules are located in the infrastructure layer;

[0020] Among them, one of the first functional sub-modules calls at least one of the second functional sub-modules through the message processing universal component.

[0021] In some embodiments, the external interface is configured to receive service call information sent by the first functional submodule through a third interface communication specification, and input the service call information into the communication strategy module;

[0022] The communication strategy module is configured to determine the third target communication mode corresponding to the service call information according to a preset configuration file and notify the internal interface;

[0023] The internal interface is configured to call the second functional submodule corresponding to the service call information for functional testing based on the third target communication mode and the third interface communication specification, and receive the service call result information fed back by the second functional submodule through the fourth interface communication specification.

[0024] In some embodiments, the internal interface is configured to input the service call result information into the communication strategy module after receiving the service call result information;

[0025] The communication strategy module is configured to determine, based on a preset configuration file, a fourth target communication mode corresponding to the service call result information and notify the external interface;

[0026] The external interface is configured to feed back the service call result information to the first functional sub-module based on the fourth target communication mode and the third interface communication specification.

[0027] In some embodiments, the third interface communication specification includes input parameters and return parameters, wherein the input parameters include a module name indicating the module corresponding to the call of the second functional sub-module, and the return parameters include an information format and information content type indicating the service call result information.

[0028] In some embodiments, the first functional sub-module includes an instrument management module, a version management module, an environment management module, and a device interaction management module.

[0029] In some embodiments, the second functional submodule includes upper and lower electrical equipment, a high-temperature cabinet, a test instrument, a cloudMDS database, and a test terminal monitoring tool.

[0030] The present application proposes a production test platform system. The production test platform system of an embodiment of the present application includes a general message processing component and multiple functional sub-modules. Each functional sub-module is used to provide service functions for the object to be tested in production. The general message processing component includes a communication strategy module, wherein the communication strategy module obtains service result information feedback from the functional sub-module based on the first interface communication specification, and determines the first target communication mode corresponding to the service result information according to a preset configuration file, so as to feed back the service result information to the object to be tested based on the first target communication mode.

[0031] The embodiment of the present application defines a set of interface communication specifications (i.e., the first interface communication specifications) to standardize the behavior of all functional sub-modules in providing services, thereby ensuring the independence and isolation of each functional sub-module, facilitating the flexible expansion of the production test platform system of the embodiment of the present application, and ensuring that the designed microservice modules (i.e., functional sub-modules) can be connected in accordance with this set of interface communication specifications, so that the production test platform system of the embodiment of the present application can be efficiently expanded and integrated, and developed in layers. For business-related developers, they can only care about the functions within their own related businesses. For example, when developing a test function A, function A, in addition to its own unique functions, also needs to call the existing module test function B (i.e., functional sub-module B) of the production test platform system. Then, the developer only needs to encapsulate the external function function A according to the first interface communication specification, and use it inside A to call the existing functional sub-module B of the production test platform system according to the interface communication specification, without having to worry about the specific implementation of how A and B communicate. In addition, the embodiment of the present application also uses a unified message processing universal component to enable the services provided by all functional sub-modules to interact through the unified message processing universal component, thereby providing a low-coupling SOA (Service-Oriented Architecture) architecture. The services are isolated and have no direct reference relationship, further ensuring that the production test platform system can be flexibly expanded and designed.

[0032] In addition, the embodiment of the present application designs a communication strategy module so that the communication strategies of all microservice modules (i.e., functional sub-modules) of the production test platform system of the embodiment of the present application can be configured through configuration files, thereby supporting communication in the form of microservices on the cloud and direct calling in a local manner, thereby enabling the production test platform of the embodiment of the present application to simultaneously support working in different manners in different application environments, for example, supporting working in the form of microservices on the cloud and supporting working in the form of processes under the cloud, that is, it can realize that some services (i.e., some functional sub-modules) run on the cloud and some services run under the cloud (i.e., locally), effectively realizing the function of flexible deployment through configuration, thereby enabling the embodiment of the present application to solve the technical problem that the current production test platform cannot be flexibly deployed and flexibly expanded. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0034] Figure 1 This is a schematic diagram of module connections of a production test platform system in an embodiment of the present application;

[0035] Figure 2 A schematic diagram of a scenario in which a production test platform system performs production testing in an embodiment of the present application;

[0036] Figure 3 Schematic diagram of the DDD layered architecture of the production test platform system in an embodiment of the present application;

[0037] Figure 4 A hierarchical call relationship diagram of the production test platform system in an embodiment of the present application;

[0038] Figure 5 This is a diagram of the SOA architecture of the production test platform system in the embodiment of this application;

[0039] Figure 6 This is a communication scheduling flow chart of the production test platform system in an embodiment of the present application;

[0040] Figure 7 This is a schematic diagram of a deployment scenario of a production test platform system in the first embodiment of the present application;

[0041] Figure 8 This is a schematic diagram of a deployment scenario of a production test platform system in the second embodiment of the present application;

[0042] Figure 9 This is a schematic diagram of a deployment scenario of a production test platform system in the third embodiment of the present application;

[0043] Figure 10 This is a schematic diagram of the structure of the general message processing component in the embodiment of the present application;

[0044] Figure 11 This is a structural diagram of the production test platform system in an embodiment of the present application.

[0045] Description of Figure Numbers:

[0046] Label name Label name 100 Production test platform system 22 Internal interface 1 Functional submodule 23 External interface 2 Message processing general components 11 The first functional submodule 21 Communication Strategy Module 12 Second functional submodule

[0047] The realization of the objectives, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0048] It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application.

[0049] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0050] It should be noted that all directional indications in the embodiments of the present application (such as up, down, left, right, front, back, etc.) are only used to explain the relative position relationship, movement status, etc. between the various components under a certain specific posture (as shown in the accompanying drawings). If the specific posture changes, the directional indication will also change accordingly.

[0051] In this application, unless otherwise specified or limited, the terms "connection" and "fixation" should be understood in a broad sense. For example, "fixation" can mean fixed connection, detachable connection, or integration; mechanical connection or electrical connection; direct connection or indirect connection through an intermediate medium; internal communication between two elements or interaction between two elements, unless otherwise specified. For those skilled in the art, the specific meanings of the above terms in this application can be understood according to specific circumstances.

[0052] In addition, the descriptions of "first", "second", etc. in this application are for descriptive purposes only and should not be understood as indicating or implying their relative importance or implicitly indicating the number of the technical features indicated. Therefore, the features defined as "first" or "second" may explicitly or implicitly include at least one of such features. In addition, the technical solutions between the various embodiments can be combined with each other, but this must be based on the fact that they can be implemented by ordinary technicians in this field. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such combination of technical solutions does not exist and is not within the scope of protection required by this application.

[0053] Current testing software platforms are primarily based on testing systems within a specific field, focusing on research into testing methods for products or software within that field. Microservices, a hallmark of the networked era, are used in many internet products, but their application in testing systems is still relatively limited. As software scales, traditional standalone process software becomes complex, with high coupling and inter-reference relationships between functional submodules, making distributed deployment impossible. Furthermore, the iteration speed of new features is slower than that of microservices, which rely on underlying networks and servers for operation and maintenance, making it difficult to meet the requirements of low cost and high performance.

[0054] The test software platforms in related technologies are either built based on traditional methods or based on microservices. In the field of production testing, the basic hardware facilities for production testing vary, and the performance requirements of application scenarios for users are also different. If there is only one deployment method, it is difficult to cope with various scenarios, which makes the current production testing platform unable to be flexibly deployed and flexibly expanded.

[0055] Based on this, please refer to Figure 1 , an embodiment of the present application provides a production test platform system 100, comprising:

[0056] Multiple functional sub-modules 1, each functional sub-module 1 is used to provide a service function for a test object (not shown) to be produced and tested;

[0057] Message processing universal component 2, the message processing universal component 2 includes a communication strategy module 21;

[0058] Among them, the communication strategy module 21 obtains the service result information fed back by the functional sub-module 1 based on the first interface communication specification, and determines the first target communication mode corresponding to the service result information according to the preset configuration file, so as to feed back the service result information to the object under test based on the first target communication mode.

[0059] The production test platform system 100 in the embodiment of the present application is a production test platform system based on CloudPT. CloudPT is service-oriented in design as a whole and is a distributed flexible system when deployed. CloudPT has designed a communication rule between services and a set of service interface specifications. The service functions provided according to this set of interface specifications can be connected to the CloudPT system, and the final communication mode of the service (microservice or local service) is determined by means of configuration files, that is, the cloud microservice call mode or the local microservice call mode. All functional sub-modules 1 in CloudPT provide external functions in the form of services and communicate according to the rules of CloudPT. CloudPT has integrated existing module functions for production testing, including test instruments, version management, environment management, device communication, etc. Since CloudPT is a SOA (Service-Oriented Architecture) architecture, sub-services (i.e., functional sub-modules 1) can be expanded and integrated according to the specific application field requirements. It can be applied to distributed platform systems with flexible deployment requirements in any field.

[0060] It's worth noting that any CloudPT user can integrate their own business services into CloudPT to form a distributed platform system for their specific domain. CloudPT simply provides a service socket and scheduling configuration system. Users only need to focus on building the service functionality relevant to their business, without having to rebuild a new platform. CloudPT has significant market value in the distributed platform system field.

[0061] Exemplarily, the first target communication mode is a cloud microservice call mode or a local microservice call mode.

[0062] To facilitate understanding, the production test platform system 100 of the present application can deploy the CloudPT distributed system according to the following scenario:

[0063] Scenario 1: Server resources are sufficient, and the networking environment of all sub-services (also called microservices or functional sub-modules 1) has the conditions to run the service on the cloud. For example, in the figure below, the network between the CloudPT sending command service and the object under test must be connected. Figure 7 As shown, Figure 7 This is a schematic diagram of the deployment scenario of the production test platform system 100 in the first embodiment of the present application, that is, all microservices (or all functional sub-modules 1) adopt the cloud microservice call mode.

[0064] Scenario 2: Some services run on the cloud, and some services run off-cloud. For example, in the figure below, the object under test is isolated from the cloud server network in the test network segment. In this case, the CloudPT command service can only be deployed locally. Figure 8 As shown, Figure 8 This is a schematic diagram of the deployment scenario of the production test platform system 100 in the second embodiment of the present application, that is, some microservices (or some functional sub-modules 1) adopt the cloud microservice calling mode, and some microservices (or some functional sub-modules 1) adopt the local microservice calling mode.

[0065] Scenario 3: No server resources or network environment, all services run in the cloud. Figure 9 As shown, Figure 9 This is a schematic diagram of the deployment scenario of the production test platform system 100 in the third embodiment of the present application, that is, all microservices (or all functional sub-modules 1) adopt the local microservice call mode.

[0066] It is known to those skilled in the art that CloudPT is a secondary development intermediate framework platform developed based on the CloudMAT platform. CloudPT is located in the middle layer between CloudMAT and test items. The external systems involved in the interaction of the CloudPT platform include: CloudMAT platform, CloudMDS data platform, environmental tooling lower computer, test board lower computer, instrument software and test items. The test item is the caller of the function for CloudPT, and CloudPT interacts with other external systems through communication protocols. Figure 2 As shown, Figure 2 This is a schematic diagram of a scenario in which the production test platform system 100 performs production testing in an embodiment of the present application.

[0067] When CloudPT is used for CloudMAT testing, it must be connected to the test server. In non-CloudMAT testing scenarios, if CloudPT communicates as a microservice, it must be connected to the server where the microservice is deployed (i.e., the cloud microservice call model). If CloudPT communicates locally, it does not rely on any network environment and runs as a process on the local machine (i.e., the local microservice call model).

[0068] In this embodiment, one functional sub-module 1 corresponds to one service function. The functional sub-module 1 may include a rack management module, an instrument management module, a version management module, an environment management module and a device interaction management module. It will be understood by those skilled in the art that the rack management module is used to provide the service function of rack management for the object under test to be produced and tested. The instrument management module is used to provide the service function of instrument management for the object under test to be produced and tested. The version management module is used to provide the service function of version management for the object under test to be produced and tested. The environment management module is used to provide the service function of environment management for the object under test to be produced and tested. The device interaction management module is used to provide the service function of device interaction management for the object under test to be produced and tested. Specifically, the main functions of these functional sub-modules 1 are shown in the following table (1):

[0069]

[0070] (one)

[0072] The functional submodule 1 may also include upper and lower electrical equipment, a high-temperature cabinet, test instruments, a cloudMDS database, and a test terminal monitoring tool, which are not specifically limited in this embodiment.

[0073] Among them, the communication strategy module 21 is used to provide a communication strategy for information transmission between the message processing universal component 2 and the functional sub-module 1, and to provide a communication strategy for information transmission between the message processing universal component 2 and the object under test. The communication strategy is the communication rule between services. The hardware embodiment of the communication strategy module 21 can be a chip or a microprocessor. It is worth mentioning that the communication strategy can be set according to the configuration file. User needs are often easy to change. With this communication strategy module 21, changes can be quickly adapted. The changes are isolated within this module and will not affect its upstream and downstream, and the entire system will be stable.

[0074] In this embodiment, the first interface communication specification is a service interface specification. Exemplarily, the first interface communication specification includes an information format and information content type indicating service result information. Specifically, the first interface communication specification may include an HTTP interface specification, an API interface, an RPC interface, an RMI interface, a Web service interface, and a RESTful interface, among others, which are not specifically limited in this embodiment.

[0075] In this embodiment, the communication strategy module 21 obtains the service result information fed back by the functional sub-module 1 based on the first interface communication specification, and determines the first target communication mode corresponding to the service result information according to the preset configuration file, so as to feed back the service result information to the object under test based on the first target communication mode, thereby realizing the service function of providing the object under test to be produced with performance indicators such as test product operation and aging.

[0076] The present application proposes a production test platform system 100. The production test platform system 100 of the embodiment of the present application includes a message processing general part 2 and multiple functional sub-modules 1. Each functional sub-module 1 is used to provide service functions for the object to be tested in production. The message processing general part 2 includes a communication strategy module 21, wherein the communication strategy module 21 obtains the service result information fed back by the functional sub-module 1 based on the first interface communication specification, and determines the first target communication mode corresponding to the service result information according to a preset configuration file, so as to feed back the service result information to the object to be tested based on the first target communication mode.

[0077] The embodiment of the present application defines a set of interface communication specifications (i.e., the first interface communication specifications) to standardize the behavior of all functional sub-modules 1 in providing services, ensure the independence and isolation of each functional sub-module 1, facilitate the flexible expansion of the production test platform system 100 of the embodiment of the present application, ensure that the designed microservice module (i.e., functional sub-module 1) can be connected in accordance with this set of interface communication specifications, and facilitate the efficient expansion and integration of the production test platform system 100 of the embodiment of the present application, and layered development. For business-related developers, they can only care about the functions within their own related businesses. For example, when developing a test function A, function A, in addition to its own unique functions, also needs to call the existing module test function B (i.e., functional sub-module 1B) of the production test platform system 100. Then, the developer only needs to encapsulate the external function function A according to the first interface communication specification, and use it inside A to call the existing functional sub-module 1B of the production test platform system 100 according to the interface communication specification, and no longer needs to worry about the specific implementation of how A and B communicate. In addition, the embodiment of the present application also uses a unified message processing universal component 2, so that the services provided by all functional sub-modules 1 can interact through the unified message processing universal component 2, thereby providing a low-coupling SOA (Service-Oriented Architecture) architecture, in which the services are isolated and have no direct reference relationship, further ensuring that the production test platform system 100 can be flexibly expanded and designed.

[0078] In addition, the embodiment of the present application designs a communication strategy module 21, so that the communication strategy of all microservice modules (i.e., functional sub-modules 1) of the production test platform system 100 of the embodiment of the present application can be configured through a configuration file, thereby supporting communication in the form of microservices on the cloud, as well as direct calling in a local manner, thereby enabling the production test platform of the embodiment of the present application to simultaneously support working in different manners in different application environments, for example, supporting working in the form of microservices on the cloud, and supporting working in the form of processes under the cloud, that is, it can realize that some services (i.e., some functional sub-modules 1) run on the cloud, and some services run under the cloud (i.e., locally), effectively realizing the function of flexible deployment through configuration, thereby enabling the embodiment of the present application to solve the technical problem that the current production test platform cannot be flexibly deployed and flexibly expanded.

[0079] In one practicable manner, please refer to Figure 1 and Figure 10 , the message processing universal component 2 further includes an internal interface 22 and an external interface 23, the internal interface 22, the communication strategy module 21 and the external interface 23 are connected in sequence, and the internal interface 22 is also connected to each functional sub-module 1 respectively;

[0080] Among them, the internal interface 22 receives the service result information fed back by the functional sub-module 1 through the first interface communication specification, and inputs the service result information into the communication strategy module 21 so that the communication strategy module 21 can obtain the service result information fed back by the functional sub-module 1. The external interface 23 feeds back the service result information to the object under test based on the first target communication mode.

[0081] Exemplarily, the first interface communication specification includes an information format and an information content type indicating the service result information.

[0082] In this embodiment, the internal interface 22 is an interface for information transmission between the functional submodule 1 and the communication strategy module 21. The external interface 23 is an interface for information transmission between the communication strategy module 21 and the object under test. Among them, the types of the internal interface 22 may include a serial port, a CAN (Controller Area Network) port, and an Ethernet port, etc. This embodiment does not make specific restrictions on this, and those skilled in the art can set it according to actual conditions. Similarly, the types of the external interface 23 may include a serial port, a CAN port, and an Ethernet port, etc. This embodiment does not make specific restrictions on this, and those skilled in the art can also set it according to actual conditions.

[0083] In this embodiment, the internal interface 22 includes hardware, firmware and / or software that enables communication with various functional submodules 1. In some embodiments, the internal interface 22 may also include a serial port, a parallel port, a general purpose input and output (GPIO) port, a universal serial bus (USB), a micro USB port, a high-definition multimedia (HDMI) port, a video port, an audio port, a Bluetooth TM port, NFC port, other similar communication interfaces, or any combination thereof.

[0084] In addition, the external interface 23 includes hardware, firmware, and / or software that enables communication with various peripheral devices, such as a media drive (e.g., a disk, solid-state drive, or optical drive), other processing devices, or any other input source used in conjunction with the present technology. In some embodiments, the external interface 23 may also include a serial port, a parallel port, a general-purpose input and output (GPIO) port, a universal serial bus (USB), a micro-USB port, a high-definition multimedia (HDMI) port, a video port, an audio port, a Bluetooth TM port, NFC port, other similar communication interfaces, or any combination thereof.

[0085] This embodiment further sets the message processing universal part 2 to include an internal interface 22 and an external interface 23. The internal interface 22, the communication strategy module 21 and the external interface 23 are connected in sequence. The internal interface 22 is also connected to each functional sub-module 1 respectively, wherein the internal interface 22 receives the service result information fed back by the functional sub-module 1 through the first interface communication specification, and inputs the service result information into the communication strategy module 21 so that the communication strategy module 21 can obtain the service result information fed back by the functional sub-module 1. The external interface 23 feeds back the service result information to the object under test based on the first target communication mode, thereby designing a set of interface specifications and communication rules. All microservice modules connected to CloudPT need to follow this set of rules. Specifically, this embodiment defines a set of specifications, including interface rules, input and return parameter rules and communication strategy rules, which standardize the behavior of all services and ensure the independence and isolation of services. Through the unified message processing universal part 2, the services provided by all functional sub-modules 1 can interact with each other through the unified message processing universal part 2, thereby providing a low-coupling SOA (Service-Oriented Architecture, service-oriented) architecture, effectively ensuring that the production test platform system 100 can be flexibly expanded.

[0086] In a possible implementation, the external interface 23 is configured to communicate with the object under test using a second interface communication specification;

[0087] The external interface 23 feeds back the service result information to the object under test based on the first target communication mode and the second interface communication specification.

[0088] Exemplarily, the second interface communication specification includes a service name, a function name, and function parameters indicating a corresponding calling service of the object under test.

[0089] In this embodiment, the internal interface 22 is connected to each functional sub-module 1 using a first interface communication specification, and the external interface 23 is connected to the object under test using a second interface communication specification.

[0090] The embodiment of the present application sets the external interface 23 to communicate with the object under test using the second interface communication specification, wherein the external interface 23 feeds back the service result information to the object under test based on the first target communication mode and the second interface communication specification, so that this embodiment defines a set of specifications, including interface rules, input and return parameter rules and communication strategy rules, which standardize the behavior of all services and ensure the independence and isolation of services. Through the unified message processing universal component 2, the services provided by all functional sub-modules 1 can interact with each other through the unified message processing universal component 2, thereby providing a low-coupling SOA (Service-Oriented Architecture) architecture. On the basis of being able to implement a set of microservice functions for testing such as instrument management, version management, environment management, and device interaction management, it effectively ensures that the production test platform system 100 can be flexibly expanded and designed, thereby improving software reusability.

[0091] In a feasible embodiment, the external interface 23 is configured to receive service request information sent by the measured object through the second interface communication specification, and input the service request information into the communication strategy module 21;

[0092] The communication strategy module 21 is configured to determine the second target communication mode corresponding to the service request information according to a preset configuration file and notify the internal interface 22;

[0093] The internal interface 22 is configured to call the functional submodule 1 corresponding to the service request information to perform functional testing on the object under test based on the second target communication mode and the first interface communication specification, and receive the service result information fed back by the functional submodule 1 through the first interface communication specification.

[0094] The second target communication mode may be the same as or different from the first target communication mode. The second target communication mode is a cloud microservice call mode or a local microservice call mode.

[0095] The embodiment of the present application sets the external interface 23 to receive the service request information sent by the object under test through the second interface communication specification, and inputs the service request information into the communication strategy module 21. Then, the communication strategy module 21 is set to determine the second target communication mode corresponding to the service request information according to the preset configuration file and notify the internal interface 22. Then, the internal interface 22 is set to call the functional sub-module 1 corresponding to the service request information based on the second target communication mode and the first interface communication specification to perform functional testing on the object under test, and receive the service result information feedback by the functional sub-module 1 through the first interface communication specification. Thus, this embodiment defines a set of specifications, including interface rules, input and return parameter rules and communication strategy rules, which standardize the behavior of all services and ensure the independence and isolation of services. Through the unified message processing universal component 2, the services provided by all functional sub-modules 1 can interact through the unified message processing universal component 2, thereby providing a low-coupling SOA (Service-Oriented Architecture) architecture, effectively ensuring that the production test platform system 100 can be flexibly expanded.

[0096] In addition, the embodiment of the present application designs a communication strategy module 21, so that the communication strategy of all microservice modules (i.e., functional sub-modules 1) of the production test platform system 100 of the embodiment of the present application can be configured through a configuration file, thereby supporting communication in the form of microservices on the cloud, as well as direct calling in a local manner, thereby enabling the production test platform of the embodiment of the present application to simultaneously support working in different manners in different application environments, for example, supporting working in the form of microservices on the cloud, and supporting working in the form of processes under the cloud, that is, it can realize that some services (i.e., some functional sub-modules 1) run on the cloud, and some services run under the cloud (i.e., locally), effectively realizing the function of flexible deployment through configuration, thereby enabling the embodiment of the present application to solve the technical problem that the current production test platform cannot be flexibly deployed and flexibly expanded.

[0097] In one possible implementation, please refer to Figure 1 、 Figure 10 and Figure 11 The production test platform system 100 includes a domain layer and an infrastructure layer. Each functional sub-module 1 includes at least one first functional sub-module 11 and at least one second functional sub-module 12. All first functional sub-modules 11 are located in the domain layer, and the message processing universal component 2 and all second functional sub-modules 12 are located in the infrastructure layer.

[0098] A first functional submodule 11 correspondingly calls at least one second functional submodule 12 through the message processing universal component 2 .

[0099] As an example, the first functional submodule 11 includes an instrument management module, a version management module, an environment management module and a device interaction management module.

[0100] Exemplarily, the second functional submodule 12 includes upper and lower electrical equipment, a high-temperature cabinet, test instruments, a cloudMDS database, and a test terminal monitoring tool.

[0101] Furthermore, each second functional submodule 12 communicates with each other through the message processing universal component 2 .

[0102] In order to help understand the technical principle or technical concept of this embodiment, a specific embodiment is listed, please refer to Figures 3 to 5 ,in, Figure 3 Schematic diagram of the DDD (Domain Driven Design) layered architecture of the production test platform system 100 in an embodiment of the present application, Figure 4 This is the hierarchical calling relationship of the production test platform system 100 in the embodiment of the present application. Figure 5 The SOA architecture diagram of the production test platform system 100 in the embodiment of the present application specifically includes:

[0103] exist Figure 3 The domain layer and infrastructure layer also exist as services in the entire system, and the calling relationship follows the top-down calling principle. The service of the upper layer (i.e., the first functional sub-module 11) can call the service of the lower layer (i.e., the second functional sub-module 12), and the lower layer service cannot call the higher layer service in reverse. Figure 3 The common components in the framework are the basis of all upper-layer services. They not only encapsulate a unified communication interface, but also standardize the behavior of each service and unify the common operations in the services.

[0104] The SOA architecture enables CloudPT to achieve high scalability and architectural stability, while also being compatible with both on-premises and cloud-based models (i.e., both cloud-based and on-premises microservice invocation models). Because CloudPT completely encapsulates this functionality within a unified message processing component, this change is invisible to individual services, leaving the functionality of the services intact.

[0105] Figure 4 This diagram illustrates the current top-down call structure of CloudPT. The top layer (the Python test item) represents CloudPT's external systems, which dispatch CloudPT service functions through CloudPT's communication interfaces. External systems typically access corresponding functions through CloudPT's management module interfaces, but can also directly call the underlying infrastructure (i.e., calling the second functional submodule 12).

[0106] In this embodiment, one functional sub-module 1 corresponds to one service function (i.e., one functional sub-module 1 corresponds to one sub-service). The functional sub-module 1 may include a rack management module, an instrument management module, a version management module, an environment management module, and a device interaction management module. It will be understood by those skilled in the art that the rack management module is used to provide the service function of rack management for the object under test to be produced and tested. The instrument management module is used to provide the service function of instrument management for the object under test to be produced and tested. The version management module is used to provide the service function of version management for the object under test to be produced and tested. The environment management module is used to provide the service function of environment management for the object under test to be produced and tested. The device interaction management module is used to provide the service function of device interaction management for the object under test to be produced and tested. Specifically, the main functions of these functional sub-modules 1 are shown in Table (1) above.

[0107] from Figure 5 It can be seen that the CloudPT architecture is a low-coupling SOA architecture. Services are isolated and have no direct reference relationship. Services interact through a unified message processing component 2.

[0108] The technical effects that can be achieved by the CloudPT-based production test platform system 100 in the embodiments of the present application are as follows:

[0109] 1. SOA architecture makes the system easy to expand and integrate.

[0110] 2. Defines a set of specifications including interface rules, input and return parameter rules, and communication strategy rules, which standardize the behavior of all services and ensure the independence and isolation of services.

[0111] 3. Designed a communication strategy module to isolate changes and implement flexible deployment through configuration.

[0112] 4. The existing main testing methods are encapsulated to improve software reusability.

[0113] It should be noted that the above-mentioned specific embodiment 1 is only used to help understand the technical concept of the embodiment of the present application, and does not constitute a limitation of the present application. More simple transformations based on the technical concept should all be within the scope of protection of the present application.

[0114] Further, in one embodiment, the external interface 23 is configured to receive the service call information sent by the first functional submodule 11 through the third interface communication specification, and input the service call information into the communication strategy module;

[0115] The communication strategy module 21 is configured to determine the third target communication mode corresponding to the service call information according to a preset configuration file and notify the internal interface 22;

[0116] The internal interface 22 is configured to call the second functional submodule 12 corresponding to the service call information to perform a functional test based on the third target communication mode and the third interface communication specification, and receive the service call result information fed back by the second functional submodule 12 through the fourth interface communication specification.

[0117] The third target communication mode may be the same as or different from the first target communication mode. The third target communication mode is a cloud microservice call mode or a local microservice call mode.

[0118] In this embodiment, it should be noted that the second interface communication specification may be the same as or different from the third interface communication specification, and this embodiment does not impose any specific limitation.

[0119] Similarly, the fourth interface communication specification may be the same as or different from the third interface communication specification, and this embodiment does not impose any specific limitations thereon. The types of the third interface communication specification include, but are not limited to, HTTP interface specifications, API interfaces, RPC interfaces, RMI interfaces, Web service interfaces, and RESTful interfaces. Similarly, the types of the fourth interface communication specification include, but are not limited to, HTTP interface specifications, API interfaces, RPC interfaces, RMI interfaces, Web service interfaces, and RESTful interfaces.

[0120] Exemplarily, the third interface communication specification includes input parameters and return parameters, wherein the input parameters include the module name corresponding to the second functional sub-module 12 indicated for calling, and the return parameters include the information format and information content type indicating the service call result information.

[0121] The embodiment of the present application sets the external interface 23 to receive the service call information sent by the first functional sub-module 11 through the third interface communication specification, and inputs the service call information into the communication strategy module 21. Then, the communication strategy module 21 determines the third target communication mode corresponding to the service call information according to the preset configuration file and notifies the internal interface 22. The internal interface 22 is set to call the second functional sub-module 12 corresponding to the service call information for functional testing based on the third target communication mode and the third interface communication specification, and receives the service call result information feedback from the second functional sub-module 12 through the fourth interface communication specification, thereby further enabling this embodiment to standardize the behavior of all services through a set of unified communication specifications, including interface rules, input and return parameter rules and communication strategy rules, to ensure the independence and isolation of services. Through the unified message processing universal component 2, the services provided by all functional sub-modules 1 can interact through the unified message processing universal component 2, thereby providing a low-coupling SOA (Service-Oriented Architecture) architecture, effectively ensuring that the production test platform system 100 can be flexibly expanded.

[0122] As an implementable manner, the internal interface 22 is configured to input the service call result information into the communication strategy module 21 after receiving the service call result information;

[0123] The communication strategy module 21 is configured to determine the fourth target communication mode corresponding to the service call result information according to a preset configuration file and notify the external interface 23;

[0124] The external interface 23 is configured to feed back the service call result information to the first functional submodule 11 based on the fourth target communication mode and the third interface communication specification.

[0125] The fourth target communication mode may be the same as or different from the first target communication mode. The fourth target communication mode is a cloud microservice call mode or a local microservice call mode.

[0126] As an implementable method, the third interface communication specification includes input parameters and return parameters, wherein the input parameters include the module name corresponding to the second functional sub-module 12 indicated for calling, and the return parameters include the information format and information content type indicating the service call result information.

[0127] The embodiment of the present application is based on the internal interface 22 being set to receive the service call result information, and then inputting the service call result information into the communication strategy module 21, and then setting the communication strategy module 21 to determine the fourth target communication mode corresponding to the service call result information according to the preset configuration file and notify the external interface 23, and then setting the external interface 23 to be based on the fourth target communication mode and the third interface communication specification, and feeding back the service call result information to the first functional sub-module 11, so that the embodiment of the present application defines a unified external interface 23 rule for all services (services can only access each other through these external interfaces 23), and specifically defines the input and return parameters of all service external function functions. This design enables the calling method between all services to be unified, laying the foundation for the subsequent design of the communication strategy module 21. The input parameters may include the called service name, function name, function parameters (stored in JSON format) and reserved fields. The return parameters may include the result of calling the service (success or failure), error information, returned data (stored in Json format), and exception information, ensuring the independence and isolation of the service. This embodiment uses a unified message processing universal component 2 to enable the services provided by all functional sub-modules 1 to interact through the unified message processing universal component 2, thereby providing a low-coupling SOA (Service-Oriented Architecture) architecture. Any changes in the calling strategy are only within this communication strategy module 21. This design isolates the changes. Even if user requirements change, the individual services themselves are completely unaffected, and only the reference version of the strategy module needs to be upgraded.

[0128] In order to further help understand the technical concept of this embodiment, the specific embodiment 2 is listed, please refer to Figure 6 , Figure 6 1 is a flow chart of communication scheduling of the production test platform system 100 in an embodiment of the present application, wherein:

[0129] (1) CloudPT defines unified external interface 23 rules for all services (services can only access each other through these external interfaces 23):

[0130] CloudPT defines the input and return parameters for all external service functions. This design unifies the calling method across all services and lays the foundation for the subsequent design of communication strategy modules. The input parameters define the service name, function name, function parameters (stored in JSON format), and reserved fields. The return parameters define the result of the service call (success or failure), error information, returned data (stored in JSON format), and exception information.

[0131] (2) CloudPT encapsulates a unified communication policy module. All inter-service calls must pass through this policy module. The service caller passes the service name and parameters to the policy module. The policy module finds the target service based on the user configuration, makes the call, and returns the result to the caller. Any changes to the call policy are confined to the communication policy module. This design isolates changes. Even if user requirements change, the individual services themselves remain completely unaffected; only the referenced version of the policy module needs to be upgraded.

[0132] In addition, to help understand Figure 6 The communication scheduling flow chart of the production test platform system 100 is shown in FIG. 1 , wherein the communication scheduling module process design can be as follows:

[0133] The relevant configurations involved in the process are in the application.properties (process startup configuration) file in the config folder of the executable program directory of the running environment. The configuration content is as follows:

[0134] Current process running mode configuration: servicecall.selfiscloud = false.

[0135] Current process communication mode configuration: servicecall.isusecloud=true0.

[0136] Target service list configuration on the cloud:

[0137] servicecall.microservicelist=microserviceclouddata,ServiceMachine.

[0138] Configuration of target service list running in this process:

[0139] servicecall.localexeservicename=serviceCloudData,servicecloudptdata.

[0140] 3. Encapsulate the external interfaces of the sub-services of each business function according to the CloudPT interface rules and integrate them into CloudPT.

[0141] 4. Plan each functional submodule 1 according to the DDD design method, and finally form the following Figure 3 The design layering shown implements the business functions in each functional sub-module 1.

[0142] 5. The CloudPT distributed system can be deployed according to the following scenarios:

[0143] Scenario 1: The server resources are sufficient and the networking environment of all sub-services has the conditions to run the service on the cloud. For example, in the figure below, the network between the CloudPT sending command service and the tested object must be connected. Figure 7 As shown, Figure 7 This is a schematic diagram of the deployment scenario of the production test platform system 100 in the first embodiment of the present application, that is, all microservices (or all functional sub-modules 1) adopt the cloud microservice call mode.

[0144] Scenario 2: Some services run on the cloud, and some services run off-cloud. For example, in the figure below, the object under test is isolated from the cloud server network in the test network segment. In this case, the CloudPT command service can only be deployed locally. Figure 8 As shown, Figure 8 This is a schematic diagram of the deployment scenario of the production test platform system 100 in the second embodiment of the present application, that is, some microservices (or some functional sub-modules 1) adopt the cloud microservice calling mode, and some microservices (or some functional sub-modules 1) adopt the local microservice calling mode.

[0145] Scenario 3: No server resources or network environment, all services run in the cloud. Figure 9 As shown, Figure 9 This is a schematic diagram of the deployment scenario of the production test platform system 100 in the third embodiment of the present application, that is, all microservices (or all functional sub-modules 1) adopt the local microservice call mode.

[0146] It should be noted that the above-mentioned specific embodiment 2 is only used to help understand the technical concept of the embodiment of the present application, and does not constitute a limitation of the present application. More simple transformations based on the technical concept should all be within the scope of protection of the present application.

[0147] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or system comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or system. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or system comprising the element.

[0148] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0149] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as above, and includes a number of instructions for enabling an electronic device (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of each embodiment of the present application.

[0150] The above are only preferred embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the description and drawings of this application, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A production test platform system, comprising: Multiple functional sub-modules, each of which is used to provide a service function for the object under test to be produced and tested; A message processing universal component, wherein the message processing universal component includes a communication strategy module; Among them, the communication strategy module obtains the service result information fed back by the functional sub-module based on the first interface communication specification, and determines the first target communication mode corresponding to the service result information according to a preset configuration file, so as to feed back the service result information to the object under test based on the first target communication mode.

2. The production test platform system according to claim 1, wherein: The first target communication mode is a cloud microservice call mode or a local microservice call mode.

3. The production test platform system according to claim 1, wherein: The message processing universal component further includes an internal interface and an external interface, wherein the internal interface, the communication strategy module and the external interface are connected in sequence, and the internal interface is also connected to each of the functional submodules respectively; Among them, the internal interface receives the service result information fed back by the functional sub-module through the first interface communication specification, and inputs the service result information into the communication strategy module so that the communication strategy module can obtain the service result information fed back by the functional sub-module, and the external interface feeds back the service result information to the object under test based on the first target communication mode.

4. The production test platform system according to claim 3, wherein: The external interface is configured to communicate with the measured object using a second interface communication specification; The external interface feeds back the service result information to the measured object based on the first target communication mode and the second interface communication specification.

5. The production test platform system according to claim 4, characterized in that: The external interface is configured to receive service request information sent by the measured object through the second interface communication specification, and input the service request information into the communication strategy module; The communication strategy module is configured to determine the second target communication mode corresponding to the service request information according to a preset configuration file and notify the internal interface; The internal interface is configured to call the functional submodule corresponding to the service request information to perform functional testing on the object under test based on the second target communication mode and the first interface communication specification, and receive service result information fed back by the functional submodule through the first interface communication specification.

6. The production test platform system according to claim 5, characterized in that: The first interface communication specification includes an information format and an information content type indicating the service result information.

7. The production test platform system according to claim 5, characterized in that: The second interface communication specification includes a service name, a function name, and function parameters indicating a corresponding calling service of the object under test.

8. The production test platform system according to claim 3, wherein: The production test platform system includes a domain layer and an infrastructure layer, each of the functional submodules includes at least one first functional submodule and at least one second functional submodule, all of the first functional submodules are located in the domain layer, and the message processing universal component and all of the second functional submodules are located in the infrastructure layer; Among them, one of the first functional sub-modules calls at least one of the second functional sub-modules through the message processing universal component.

9. The production test platform system according to claim 8, wherein: The external interface is configured to receive service call information sent by the first functional submodule through a third interface communication specification, and input the service call information into the communication strategy module; The communication strategy module is configured to determine the third target communication mode corresponding to the service call information according to a preset configuration file and notify the internal interface; The internal interface is configured to call the second functional submodule corresponding to the service call information for functional testing based on the third target communication mode and the third interface communication specification, and receive the service call result information fed back by the second functional submodule through the fourth interface communication specification.

10. The production test platform system according to claim 9, wherein: The internal interface is configured to input the service call result information into the communication strategy module after receiving the service call result information; The communication strategy module is configured to determine, based on a preset configuration file, a fourth target communication mode corresponding to the service call result information and notify the external interface; The external interface is configured to feed back the service call result information to the first functional sub-module based on the fourth target communication mode and the third interface communication specification.

11. The production test platform system according to claim 9, wherein: The third interface communication specification includes input parameters and return parameters, wherein the input parameters include a module name indicating the module corresponding to the second functional sub-module being called, and the return parameters include an information format and information content type indicating the service call result information.

12. The production test platform system according to any one of claims 8 to 11, characterized in that: The first functional sub-module includes an instrument management module, a version management module, an environment management module and a device interaction management module.

13. The production test platform system according to any one of claims 8 to 11, characterized in that: The second functional submodule includes upper and lower electrical equipment, high-temperature cabinets, test instruments, cloudMDS database and test terminal monitoring tools.

Images