Test method and device for port-out client, electronic equipment and storage medium
By receiving and converting the control command data from the departure client into standard command data, the problem of low testing efficiency caused by different departure equipment platforms is solved, and efficient testing of multi-platform clients is achieved.
Patent Information
- Application Number
- CN202411863466.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-17
- Publication Date
- 2025-10-24
- Estimated Expiration
- 2044-12-17
AI Technical Summary
Different departure clients use different departure equipment platforms, resulting in low efficiency during departure client testing and making it impossible to test departure clients using different departure equipment platforms simultaneously.
By receiving control command data from multiple departing clients, the data is converted into standard command data using the equipment data model, and then processed by standard departing equipment to determine the test results.
This technology enables simultaneous testing of multiple departure clients using different departure equipment platforms, thus improving testing efficiency.
Smart Images

Figure CN119676137B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the field of aviation information technology, in particular to a test method and device for a departure client, an electronic device and a storage medium. BACKGROUND
[0002] In an airport local area network, there are many external devices, such as boarding pass printers, baggage tag printers, manifest printers, boarding gate scanners, passport scanners, etc. Due to the differences in the types of these external devices, it is inconvenient for airlines to use them. In order to shield such differences and facilitate the calling of external devices by a departure client, many manufacturers have developed various departure device platforms. The departure client can call the control interface of the external device through the departure device platform to meet the needs of using the external device.
[0003] Different departure clients use different departure device platforms. When the version of the departure client is upgraded, time-consuming and laborious testing and authentication are required on the corresponding departure device platform. Different departure clients using different departure device platforms cannot be tested at the same time, resulting in low testing efficiency of the departure client.
[0004] At present, there is no effective solution to the above problems. SUMMARY
[0005] The embodiments of the present application provide a test method and device for a departure client, an electronic device and a storage medium, to at least solve the technical problem of low testing efficiency of the departure client.
[0006] According to an aspect of an embodiment of the present application, a test method for a departure client is provided, comprising: receiving control instruction data sent by a target departure client in a plurality of departure clients, wherein different departure clients use different data protocols when sending control instruction data; converting the control instruction data into standard instruction data using a device data model; processing the standard instruction data through a standard departure device to obtain a processing result; and determining a test result of the target departure client according to the processing result.
[0007] Further, receiving control instruction data sent by a target departure client in a plurality of departure clients comprises: in response to receiving a connection request sent by the target departure client, establishing a target protocol thread matched with the target departure client based on the connection request, wherein the target protocol thread is used to represent a thread corresponding to the data protocol used by the target departure client; and obtaining the control instruction data through the target protocol thread.
[0008] Further, the target protocol thread matched with the target off-port client is determined based on the connection request, including: analyzing the connection request sent by the target off-port client to obtain request information, wherein the request information at least includes one of the following: platform type, device type, Internet Protocol Address (IP for short) and port; and the target protocol thread matched with the target off-port client is determined based on the request information.
[0009] Further, the control instruction data is obtained through the target protocol thread, including: connecting the target off-port client through the target protocol thread to monitor the data sending situation of the target off-port client; and reading the control instruction data through the target protocol thread when the control instruction data sent by the target off-port client is monitored.
[0010] Further, the control instruction data is converted into standard instruction data by using the device data model, including: determining the target data protocol corresponding to the control instruction data based on the target protocol thread reading the control instruction data; analyzing the control instruction data based on the target data protocol by using the device data model to extract the device semantic field; and generating the standard instruction data based on the extracted device semantic field by using the device data model.
[0011] Further, the control instruction data is analyzed based on the target data protocol by using the device data model to extract the device semantic field, including: identifying the device-independent field in the control instruction data according to the target data protocol by using the device data model, wherein the device-independent field is used to represent the field that is different in the instruction data corresponding to different data protocols; and deleting the device-independent field in the control instruction data to obtain the device semantic field.
[0012] Further, the method further includes: in the case that the original device identifiers of the plurality of off-port clients are different, unifying the original device identifiers of the plurality of off-port clients to obtain target device identifiers of the plurality of off-port clients; and storing the target device identifiers of the plurality of off-port clients in the unified device cache.
[0013] According to another aspect of the embodiment of the application, a test device of an off-port system is also provided, including: a receiving module configured to receive control instruction data sent by a target off-port client in a plurality of off-port clients, wherein the instruction data sent by different off-port clients adopts different data protocols; a conversion module configured to convert the control instruction data into standard instruction data by using a device data model; a processing module configured to process the standard instruction data by using a standard off-port device to obtain a processing result; and a determination module configured to determine a test result of the target off-port client according to the processing result.
[0014] According to another aspect of the embodiments of the present application, an electronic device is provided, comprising a memory storing an executable program; and a processor configured to execute the program, wherein the program is configured to execute the test method of the departure client when executed.
[0015] According to another aspect of the embodiments of the present application, a computer readable storage medium is provided, comprising a stored executable program, wherein the program is configured to control a device on which the storage medium is located to execute the test method of the departure client when executed.
[0016] In the embodiments of the present application, control instruction data sent by a target departure client in a plurality of departure clients is received, wherein different data protocols are used by different departure clients to send the control instruction data; the control instruction data is converted into standard instruction data using a device data model; the standard instruction data is processed by a standard departure device to obtain a processing result; and the test result of the departure client is determined according to the processing result. It is easy to note that the control instruction data sent by the target departure client in the plurality of departure clients is converted, and the control instruction data is converted into standard instruction data that can be processed by the standard departure device. The control instruction data of the plurality of departure clients using different departure device platforms can be converted into standard instruction data at the same time, and the standard instruction data is processed by the standard departure device to obtain the test result. Therefore, the purpose of testing the plurality of departure clients using different departure device platforms at the same time can be achieved, and the technical effect of improving the test efficiency of the departure client is achieved, and the technical problem of low test efficiency of the departure client is solved. BRIEF DESCRIPTION OF DRAWINGS
[0017] The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the application. In the drawings:
[0018] Figure 1 FIG. 1 is a flowchart of a test method of a departure client according to an embodiment of the present application;
[0019] Figure 2 FIG. 2 is a schematic diagram of an optional multi-platform test system according to an embodiment of the present application;
[0020] Figure 3 FIG. 3 is a flowchart of an optional test method of a departure client according to an embodiment of the present application;
[0021] Figure 4 FIG. 4 is a schematic diagram of a test device of a departure client according to an embodiment of the present application. DETAILED DESCRIPTION
[0022] In the following, the technical solutions in the embodiments of the present application will be described clearly and completely with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all the other embodiments obtained by a person of ordinary skill in the art without creative effort should belong to the protection scope of the present application.
[0023] It should be noted that the terms "first", "second", and the like in the description and claims of the present application and the above-described drawings are used to distinguish similar objects, and do not necessarily indicate a specific order or a chronological sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product, or device that includes a series of steps or units does not necessarily have to include only those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to the process, method, product, or device.
[0024] Embodiment 1
[0025] According to an embodiment of the present application, an embodiment of a test method of a departure client is provided. It should be noted that the steps shown in the flowchart of the drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described herein can be executed in an order different from that shown herein.
[0026] Figure 1 is a flowchart of a test method of a departure client according to an embodiment of the present application, as shown in Figure 1 the method comprises the following steps:
[0027] Step S102, receiving control instruction data sent by a target departure client in a plurality of departure clients, wherein different departure clients adopt different data protocols when sending control instruction data.
[0028] The departure client in the above steps is a client used by airline or airport staff to handle passenger check-in, baggage check-in, boarding pass printing, and other departure services, also known as a pre-departure front-end system. The departure client needs to be connected to a departure device platform to determine the control interface of the departure device, and to call the departure device. Different departure clients can be connected to different departure device platforms.
[0029] The target departure client in the above step is the departure client that sends the test requirement to the test system and establishes a connection with the test system.
[0030] The control instruction data in the above step includes control commands and parameters for the departure device, and communication control information, data packet formatting information, error check information, and other data irrelevant to the control of the departure device.
[0031] The data protocol in the above step is used to represent the data format and transmission rules in the data communication process.
[0032] In an optional embodiment, the test system for implementing the test method includes a plurality of departure device platforms conforming to the CUTE (Common-Use Terminal Equipment) standard, such as the SITA platform (a departure device platform based on the CUTE standard proposed by the International Air Transport Association), the ARINC (Aviation Radio Communication Company) platform based on the CUTE, and the like. The client in the plurality of departure clients that sends the control instruction data to the departure device platform in the test system is determined as the target client, and the Socket connection thread is used to receive the control instruction data sent by the target departure client.
[0033] It should be noted that different target departure clients use different departure device platforms, and since the data protocols used by the departure device platforms are different, the data protocols used are different when different target departure clients send control instruction data to different departure device platforms in the test system, and the type of data protocol used needs to be determined according to the departure device platform used by the target departure client.
[0034] In step S104, the control instruction data is converted into standard instruction data using the device data model.
[0035] The device data model in the above step is used to analyze the control instruction data and convert the control instruction data into standard instruction data in a unified format for analysis and execution by the standard departure device.
[0036] The standard instruction data in the above step has a data format that conforms to a general standard and can be directly executed by the standard departure device. For example, the standard instruction data can be data conforming to the AEA (Association of European Airlines) standard, but is not limited thereto.
[0037] In an optional embodiment, because different departure clients use different data protocols when sending control instruction data, the header field of the control data instruction often has differences in format due to different data protocols. In order to facilitate the processing of the standard departure device, the control instruction data is input into the device data model, the control instruction data is converted into standard instruction data, the differences in format due to different data protocols are shielded, and only the data related to device control in the control instruction data is retained.
[0038] In step S106, the standard instruction data is processed by the standard departure device to obtain a processing result.
[0039] The standard departure device in the above steps is a departure device that complies with a general standard, which can be a departure device that complies with the AEA standard, but is not limited thereto. The departure device can include, but is not limited to, a boarding pass printer, a baggage tag printer, etc.
[0040] The processing result in the above steps is the result of the standard departure device executing the instruction operation after receiving the standard instruction data, which can include, but is not limited to, execution success, print output, scanning success, or information error, etc.
[0041] In an optional embodiment, the standard departure device is an AEA device, and the standard instruction data is AEA instruction set data. After receiving the standard instruction data, the standard departure device will analyze the standard instruction data to determine the device operation contained in the standard instruction data, such as printing a boarding pass, reading a barcode, verifying a certificate, etc. After the analysis of the standard instruction data is completed, the standard departure device will execute the corresponding operation according to the parsed instruction. For example, if the device operation contained in the standard instruction data is to print a boarding pass, the printer will start printing to generate the boarding pass. After the device operation contained in the standard instruction data is completed, the standard departure device can generate a processing result, which contains information such as whether the operation is successful, the device state, and whether there is an error, etc.
[0042] In step S108, the test result of the target departure client is determined according to the processing result.
[0043] The test result in the above steps is used to represent whether the function of the departure client calling the standard departure device is normal, which can be obtained by comparing the processing result with the predicted result.
[0044] In an alternative embodiment, the operation result is checked according to the processing result to see if it is expected, if the device state is normal, and if there is error information, i.e. the condition for passing the test is set as the operation result being expected, the device state being normal, and no error information. The test result is determined as passing the test in the case where the operation result is expected, the device state is normal, and there is no error information. For the rule of failing the test, it can be flexibly set according to the actual application, and the test can be determined as failing the test in the case where any one of the operation result being unexpected, the device state being abnormal, and there being error information exists; the test can be determined as failing the test in the case where any two of the operation result being unexpected, the device state being abnormal, and there being error information exists; and the test can be determined as failing the test in the case where all of the operation result being unexpected, the device state being abnormal, and there being error information exist. In the case of failing the test, an error code and an error description can be provided to locate the problem existing in the departure client.
[0045] The following will be described taking a preferred embodiment as an example, Figure 2 is a schematic diagram of an alternative multi-platform test system according to an embodiment of the present application, as Figure 2 shown, the target departure client sends a test request to the multi-platform test system and interacts with the platform control unit in the multi-platform test system. The two departure device platforms contained in the target departure client are the SITA platform and the ARINC platform, and the standard departure devices managed by the SITA platform and the ARINC platform are all air line ticket boarding printers (ATB) and baggage tag printers (BTP). The platform control unit establishes a socket connection thread according to the departure device platform type, the standard departure device type, the Internet protocol address and the port requested by the target departure client, and the following will be described taking three cases as examples.
[0046] The first case is that the target departure client needs to be connected to the SITA platform, a socket connection thread for the SITA platform is established, and the control instruction data sent by the target departure client is obtained through the socket connection thread for the SITA platform. Since the target departure client does not specify which standard departure device in the SITA platform to control, the general air line ticket boarding printer data model and the general baggage tag printer data model are used to convert the control instruction data into standard air line ticket boarding printer data and standard baggage tag printer data, so that the air line ticket boarding printer can process the standard air line ticket boarding printer data, and the baggage tag printer can process the standard baggage tag printer data to obtain a processing result.
[0047] The second case: in the case that the target departure client needs to be connected to the ARINC platform to control the departure boarding pass printer, a socket connection thread for the ARINC platform and the departure boarding pass printer is established; the control instruction data sent by the target departure client is acquired through the socket connection thread for the ARINC platform and the departure boarding pass printer; the control instruction data is converted into standard departure boarding pass printer data by using the general departure boarding pass printer data model, so that the departure boarding pass printer can process the standard departure boarding pass printer data to obtain a processing result.
[0048] The third case: in the case that the target departure client needs to be connected to the ARINC platform to control the departure baggage tag printer, a socket connection thread for the ARINC platform and the departure baggage tag printer is established; the control instruction data sent by the target departure client is acquired through the socket connection thread for the ARINC platform and the departure baggage tag printer; the control instruction data is converted into standard departure baggage tag printer data by using the general departure baggage tag printer data model, so that the departure baggage tag printer can process the standard departure baggage tag printer data to obtain a processing result.
[0049] Then, the test result of the departure client is determined according to the processing result by the multi-platform test system. It should be noted that the general departure boarding pass printer data model and the general departure baggage tag printer data model are the device data model in the above, the departure boarding pass printer and the departure baggage tag printer are the standard departure device in the above, and the standard departure boarding pass printer data and the standard departure baggage tag printer data are the standard instruction data in the above.
[0050] In the embodiment of the application, the control instruction data sent by a target departure client in a plurality of departure clients is received, wherein the instruction data sent by different departure clients adopts different data protocols; the control instruction data is converted into standard instruction data by using a device data model; the standard instruction data is processed by a standard departure device to obtain a processing result; and the test result of the target departure client is determined according to the processing result. It is easy to note that the control instruction data sent by the target departure client in the plurality of departure clients is converted into the standard instruction data that can be processed by the standard departure device by using the device data model, the control instruction data of the plurality of departure clients using different departure device platforms can be converted into the standard instruction data at the same time, the standard instruction data is processed by using the standard departure device, so that the test result is obtained, the purpose of testing the plurality of departure clients using different departure device platforms at the same time can be achieved, and the technical effect of improving the test efficiency of the departure client is achieved, and the technical problem of low test efficiency of the departure client is solved.
[0051] In an embodiment of the application, the control instruction data sent by the target departure client in the plurality of departure clients is received, including: in response to receiving the connection request sent by the target departure client, determining a target protocol thread matched with the target departure client based on the connection request establishment, wherein the target protocol thread is used to represent a thread corresponding to a data protocol adopted by the target departure client; and obtaining the control instruction data through the target protocol thread.
[0052] The connection request in the above step is a request sent by the target departure client to a departure device platform in the test system, and the purpose of sending the connection request is to establish a connection with the departure device platform so as to control the standard departure device through a device control interface provided by the departure device platform.
[0053] The target protocol thread in the above step is a communication thread customized for a data protocol adopted by the target departure client, and is used to listen to and receive the control instruction data sent by the target departure client. The target protocol thread can be a Socket connection thread, but is not limited thereto.
[0054] In an optional embodiment, when the target departure client sends a connection request to the test system, a network listening module of the test system receives the connection request. The test system parses the received connection request, extracts the request information therein, determines the departure device platform to be used by the target departure client and the standard departure device to be controlled by the target departure client, establishes a target protocol thread capable of listening to the target departure client according to the departure device platform to be used by the target departure client and the standard departure device to be controlled by the target departure client, and receives and obtains the control instruction data sent by the target departure client using the target protocol thread.
[0055] In an embodiment of the application, the target protocol thread matched with the target departure client is determined based on the connection request establishment, including: parsing the connection request sent by the target departure client to obtain request information, wherein the request information at least includes one of the following: platform type, device type, Internet protocol address, and port; and determining the target protocol thread matched with the target departure client based on the request information.
[0056] The request information in the above step is specific information contained in the connection request sent by the target departure client.
[0057] The platform type in the above step is the type of the departure device platform connected by the target departure client, which can be a SITA platform or an ARINC platform, but is not limited thereto.
[0058] The device type in the above step is the type of the standard departure device to be controlled by the target departure client through the departure device platform.
[0059] The Internet protocol address in the above step is used to identify the location of the target departure client in the network, so that the test system can determine the address that needs to be responded.
[0060] The port in the above step is used to identify different services or applications running on the same device, and the target departure client provides the port in the connection request, according to which the test system establishes the correct network connection.
[0061] In an optional embodiment, a service object is established for the port of different departure device platforms. For example, a first ServerSocket service object can be established for the port of the SITA platform, a second ServerSocket service object can be established for the ATB port of ARINC, and a third ServerSocket service object can be established for the BTP port of ARINC. The above ServerSocket service objects are used to listen to the IP address and port number corresponding to the service object to receive the connection request sent by the target departure client.
[0062] When the connection request sent by the target departure client is received, the connection request is parsed to obtain the request information. When the port in the request information is the port of the SITA platform, it is determined that the target protocol thread is the SITA_Socket thread, the SITA_Socket thread is created, and the thread is stored in the HashMap cache for unified management. When the port in the request information is the ATB port of ARINC, it is determined that the target protocol thread is the ARINC_ATB_Socket thread, the ARINC_ATB_Socket thread is created, and the thread is stored in the HashMap cache for unified management. When the port in the request information is the BTP port of ARINC, it is determined that the target protocol thread is the ARINC_BTP_Socket thread, the ARINC_BTP_Socket thread is created, and the thread is stored in the HashMap cache for unified management.
[0063] Through the above process, the automatic adaptation of the target departure client and the departure device platform is completed, the target protocol thread matched with the target departure client is established, and the unified management and concurrent control of each target protocol thread are completed.
[0064] In an embodiment of the present application, the control instruction data is obtained by the target protocol thread, including: connecting to the target departure client by the target protocol thread to monitor the data sending situation of the target departure client; and reading the control instruction data by the target protocol thread when the control instruction data sent by the target departure client is monitored.
[0065] In an alternative embodiment, the client socket of the target departure client is monitored by the target protocol thread, and the target protocol thread waits for the target departure client to send control instruction data. When the target protocol thread monitors that the target departure client sends control instruction data, the target protocol thread reads the control instruction data and stores the control instruction data in the memory.
[0066] In an embodiment of the present application, the control instruction data is converted into standard instruction data using a device data model, including: determining the target data protocol corresponding to the control instruction data based on the target protocol thread reading the control instruction data; parsing the control instruction data based on the target data protocol using the device data model to extract device semantic fields; and generating standard instruction data based on the extracted device semantic fields using the device data model.
[0067] The target data protocol in the above step is a data communication protocol used by the target departure client when interacting with the test system. Different departure device platforms (such as SITA, ARINC, etc.) have their own data protocols, which define the format of data, command structure, field meaning, etc. Since the target departure client needs to connect to different departure device platforms when interacting with the test system, the target protocol thread used by the target departure client when sending control instruction data is also different.
[0068] The device semantic field in the above step is a field in the control instruction data that is directly related to the function and operation of the device. The device semantic field carries actual instruction information sent by the target departure client to the standard departure device, such as printing specific content to a boarding pass or reading passenger information, etc.
[0069] In an alternative embodiment, different departure device platforms have their own data protocols. The target protocol thread corresponding to the departure device platform can be determined according to the target protocol thread, the data protocol used by the departure device platform is searched, and the data protocol is determined as the target data protocol. The device data model is used to determine which fields in the control instruction data are header fields unrelated to device operation and which fields are related to device operation according to the target data protocol, and only the fields related to device operation are reserved as device semantic fields.
[0070] Then the device data model is used to further adapt the device instructions, device status, error codes, etc. of the departure device platform to be uniform, and to convert the device semantic field into standard instruction data. For example, when the target data protocol is the data protocol of the SITA platform, the instruction for operating the device is "AD; CB", and when the target data protocol is the data protocol of the ARINC platform, the instruction for operating the device is "CB", and the standard AEA instruction corresponding to "AD; CB" and "CB" is "CB". Therefore, the device semantic field "AD; CB" is converted into the standard instruction data "CB".
[0071] In an embodiment of the present application, the device data model is used to parse the device control instruction data based on the target data protocol, and to extract the device semantic field, including: using the device data model to identify the device-independent field in the control instruction data according to the target data protocol, wherein the device-independent field is used to represent the field that is different in the instruction data corresponding to different data protocols; and deleting the device-independent field in the control instruction data to obtain the device semantic field.
[0072] The device-independent field in the above step is a field in the control instruction data that is not directly related to the device function or operation. The device-independent field can include a header and tail identifier, a length field, a check code, a sequence number, a padding field, etc. In the case of different target data protocols, the device-independent field in the control instruction data for the same standard departure device is different.
[0073] In an optional embodiment, the device data model is used to decouple the header field, i.e. the device-independent field, in the control instruction data according to the target data protocol, and to retain the device semantic field. For example, taking the SITA_Socket thread as an example, when the SITA_Socket thread reads a data stream, i.e. control instruction data, the target data protocol is the data protocol of the SITA platform. The header field of the target data protocol is identified based on the data protocol of the SITA platform, and the header field contains information such as data stream length Len, cyclic redundancy check code Crc, data stream incremental code Seq, and padding data filler. These device-independent fields are deleted, and the remaining fields are the device semantic field.
[0074] In an embodiment of the present application, the method further includes: in the case that the original device identifiers of the plurality of departure clients are different, unifying the original device identifiers of the plurality of departure clients to obtain target device identifiers of the plurality of departure clients; and storing the target device identifiers of the plurality of departure clients in the unified device cache.
[0075] The original equipment identification in the above step is an identifier used for uniquely identifying a standard departure equipment on different departure equipment platforms. The original equipment identification of the same standard departure equipment can be different on different departure equipment platforms.
[0076] The target equipment identification in the above step is a standard equipment identification uniformly used in the test system, which is used to replace the original equipment identification.
[0077] In an optional embodiment, the original equipment identification of the same standard departure equipment can be different on different departure equipment platforms, so that the original equipment identification of the standard departure equipment corresponding to multiple departure clients can be different when the different departure equipment platforms in the test system are connected by the different departure clients. In this case, the original equipment identification corresponding to the same standard departure equipment is replaced by a uniform identification, i.e., the target equipment identification, and the target equipment identification is stored in the uniform equipment cache. Exemplarily, when the target protocol thread established is an ARINC_ATB_Socket thread and an ARINC_BTP_Socket thread, the original equipment identification of ATB and BTP in the ARINC platform is converted into the target equipment identification corresponding to ATB and the target equipment identification corresponding to BTP, respectively, and the target equipment identification corresponding to ATB and the target equipment identification corresponding to BTP are both stored in the List cache, so as to complete the decoupling of the equipment identification of the departure equipment platform, thereby realizing the uniform equipment cache management.
[0078] The following describes a preferred embodiment, Figure 3 is a flowchart of an optional test method of a departure client according to an embodiment of the present application, as shown in Figure 3 The test method of the optional departure client has the following flow:
[0079] In step S302, the departure client accesses the multi-platform test system.
[0080] The departure client accesses the multi-platform test system containing multiple departure equipment platforms by sending a connection request, and sends control instruction data to the multi-platform test system after successful access.
[0081] In step S304, the platform equipment identification is decoupled.
[0082] In the case that the same departure equipment has different equipment identifications in multiple departure equipment platforms, the multi-platform test system unifies the equipment identification of the same departure equipment in multiple departure equipment platforms, thereby completing the decoupling of the platform equipment identification.
[0083] In step S306, the platform protocol field header is decoupled.
[0084] The multi-platform test system deletes a field header related to a data protocol in control instruction data, and only keeps a device semantic field related to device control, to realize decoupling of a platform protocol field header.
[0085] In step S308, the device data model is imported.
[0086] In step S310, device instructions of different platforms, general device states, and platform error codes are adapted.
[0087] The device instructions of different platforms, the general device states, and the platform error codes are unified through the device data model.
[0088] In step S312, the standard departure device is interacted with.
[0089] The device semantic field is converted into standard instruction data that can be processed by the standard departure device, and the standard instruction data is used to interact with the standard departure device. The standard departure device can be a standard AEA device, and the standard instruction data can be AEA instruction set data, but is not limited thereto.
[0090] Embodiment 2
[0091] According to the embodiment of the present application, an embodiment of a test device of a departure client is provided, which can execute the test method of the departure client provided in the above-mentioned embodiment 1, and the specific implementation manner and preferred application scenario are the same as those of the above-mentioned embodiment 1, which will not be repeated here.
[0092] Figure 4 is a schematic diagram of a test device of a departure client according to an embodiment of the present application, as shown in Figure 4 The test device of the departure client comprises:
[0093] The receiving module 40 is configured to receive control instruction data sent by a target departure client in a plurality of departure clients, wherein the instruction data sent by different departure clients adopts different data protocols;
[0094] The conversion module 42 is configured to convert the control instruction data into standard instruction data by using a device data model;
[0095] The processing module 44 is configured to process the standard instruction data by a standard departure device to obtain a processing result;
[0096] The determination module 46 is configured to determine a test result of the target departure client according to the processing result.
[0097] The receiving module comprises: a first determining unit, configured to, in response to receiving a connection request sent by a target off-port client, determine a target protocol thread matched with the target off-port client based on the connection request, wherein the target protocol thread is used to represent a thread corresponding to a data protocol adopted by the target off-port client; and an obtaining unit, configured to obtain control instruction data through the target protocol thread.
[0098] The first determining unit is further configured to parse the connection request sent by the target off-port client to obtain request information, wherein the request information at least comprises one of the following: platform type, device type, Internet protocol address, and port; and determine the target protocol thread matched with the target off-port client based on the request information.
[0099] The obtaining unit is further configured to connect to the target off-port client to monitor data sending of the target off-port client through the target protocol thread; and read the control instruction data through the target protocol thread in a case where the control instruction data sent by the target off-port client is monitored.
[0100] The conversion module comprises: a second determining unit, configured to determine a target data protocol corresponding to the control instruction data based on the target protocol thread used to read the control instruction data; an analyzing unit, configured to analyze the control instruction data based on the target data protocol using a device data model to extract a device semantic field; and a generating unit, configured to generate standard instruction data based on the extracted device semantic field using the device data model.
[0101] The analyzing unit is further configured to identify a device-independent field in the control instruction data according to the target data protocol using the device data model, wherein the device-independent field is used to represent a field that is different in instruction data corresponding to different data protocols; and delete the device-independent field in the control instruction data to obtain the device semantic field.
[0102] The receiving module further comprises: a unifying unit, configured to unify original device identifiers of a plurality of off-port clients to obtain target device identifiers of the plurality of off-port clients in a case where the original device identifiers of the plurality of off-port clients are different; and a storing unit, configured to store the target device identifiers of the plurality of off-port clients in a unified device cache.
[0103] Embodiment 3
[0104] According to the embodiments of the present application, an electronic device is further provided, comprising: a memory storing an executable program; and a processor configured to run the program, wherein the program is executed to perform the test method of the off-port client in the embodiment 1 when the program is run.
[0105] Embodiment 4
[0106] The embodiment of the present application further provides a computer readable storage medium, which comprises a stored executable program, wherein the executable program controls a device where the computer readable storage medium is located to perform the test method of the departure client in each embodiment of the present application when the executable program is executed.
[0107] The above-mentioned serial numbers of the embodiments of the present application are only for description, and do not represent the advantages and disadvantages of the embodiments.
[0108] In the above-mentioned embodiments of the present application, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the relevant description of other embodiments.
[0109] In several embodiments provided in the present application, it should be understood that the disclosed technical contents can be implemented by other manners. Among them, the above-mentioned device embodiments are only schematic, for example, the division of the units can be a logical function division, and in actual implementation, there can be another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units or modules shown or discussed can be indirect coupling or communication connection through some interfaces, units or modules, which can be electrical or other forms.
[0110] The units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, that is, they can be located in one place, or can be distributed to a plurality of units. According to actual needs, part or all of the units can be selected to achieve the purpose of the embodiment scheme.
[0111] In addition, each functional unit in each embodiment of the present application can be integrated in a processing unit, or each unit can exist physically independently, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be realized in the form of hardware or in the form of software functional unit.
[0112] The integrated unit, if implemented in the form of a software function unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application, essentially or in other words, the part that contributes to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, including a number of instructions to make a computer device (which can be a personal computer, a server or a network device, etc.) execute all or part of the steps of the methods described in various embodiments of the present application. The aforementioned storage medium includes: a U disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store program codes.
[0113] The above description is only the preferred embodiment of the present application, and it should be pointed out that for those skilled in the art, without departing from the principles of the present application, a number of improvements and refinements can be made, and these improvements and refinements should be considered as the protection scope of the present application.
Claims
1. A method of testing a departure client, characterized by, The method comprises: receiving control instruction data sent by a target off-port client in a plurality of off-port clients, wherein different off-port clients adopt different data protocols when sending the control instruction data; converting the control instruction data into standard instruction data using a device data model; processing the standard instruction data through a standard off-port device to obtain a processing result; determining a test result of the target off-port client according to the processing result; wherein the conversion of the control instruction data into the standard instruction data using the device data model comprises: determining a target data protocol corresponding to the control instruction data based on a target protocol thread reading the control instruction data; identifying a device-independent field in the control instruction data according to the target data protocol using the device data model, wherein the device-independent field is used to represent a field that is different in instruction data corresponding to different data protocols; deleting the device-independent field in the control instruction data to obtain a device semantic field; generating the standard instruction data based on the device semantic field using the device data model.
2. The method of testing a departure client of claim 1, wherein, Receiving control instruction data sent by a target off-port client in a plurality of off-port clients comprises: In response to receiving a connection request sent by the target off-port client, determining a target protocol thread matched with the target off-port client based on the connection request, wherein the target protocol thread is used to represent a thread corresponding to a data protocol adopted by the target off-port client; obtaining the control instruction data through the target protocol thread.
3. The method of testing a departure client of claim 2, wherein, Determining a target protocol thread matched with the target off-port client based on the connection request comprises: analyzing the connection request sent by the target off-port client to obtain request information, wherein the request information at least includes one of the following: platform type, device type, Internet protocol address, and port; determining a target protocol thread matched with the target off-port client based on the request information.
4. The method of testing a departure client of claim 2, wherein, Obtaining the control instruction data through the target protocol thread comprises: connecting to monitor data sending of the target off-port client through the target protocol thread; in the case of monitoring the control instruction data sent by the target off-port client, reading the control instruction data through the target protocol thread.
5. The method of testing a departure client according to any one of claims 1 to 4, wherein, The method further comprises: in the case that original device identifiers of the plurality of off-port clients are different, unifying the original device identifiers of the plurality of off-port clients to obtain target device identifiers of the plurality of off-port clients; storing the target device identifiers of the plurality of off-port clients in a unified device cache.
6. A test apparatus for a departure client, characterized by, The method comprises: a receiving module configured to receive control instruction data sent by a target off-port client in a plurality of off-port clients, wherein different off-port clients adopt different data protocols when sending the control instruction data; a conversion module configured to convert the control instruction data into standard instruction data using a device data model; a processing module configured to process the standard instruction data through a standard off-port device to obtain a processing result; A determining module is configured to determine a test result of the departure client according to the processing result. The conversion module comprises: A second determining unit is configured to determine a target data protocol corresponding to the control instruction data based on a target protocol thread reading the control instruction data; An analyzing unit is configured to identify device-independent fields in the control instruction data according to the target data protocol using the device data model, wherein the device-independent fields are used to represent fields that are different in instruction data corresponding to different data protocols; and delete the device-independent fields in the control instruction data to obtain device semantic fields; A generating unit is configured to generate the standard instruction data based on the device semantic fields using the device data model.
7. An electronic device, comprising: The program comprises: A memory storing an executable program; A processor configured to run the program, wherein the program is configured to perform the test method of the departure client according to any one of claims 1 to 5 when running.
8. A computer-readable storage medium, characterized in that, The computer-readable storage medium comprises a stored executable program, wherein the executable program is configured to control a device where the storage medium is located to perform the test method of the departure client according to any one of claims 1 to 5 when running.
Citation Information
Patent Citations
Flight display information display method and device, electronic equipment and storage medium
CN113420074A
VDES transceiver test system architecture
CN117615352A