Detailed Description
It should be noted that the method provided by the application can be applied to a terminal or a system, for example, the terminal can be a smart phone or a computer, a tablet computer, a smart television, a smart watch, a portable computer terminal or a fixed terminal such as a desktop computer. For convenience of explanation, the PC terminal is taken as an execution subject in the present application.
Referring to fig. 1, the present application first provides an embodiment of a method for testing a trigger path of a POS terminal, which includes:
s101, acquiring a test case of a POS terminal to be tested, wherein the test case records a specified trigger path;
before testing, the PC terminal can preset various testing scenes and the corresponding appointed trigger paths into a testing case table. The test case table may contain specific settings for trigger combinations, such as the number and status of trigger channels (paths).
The read specified trigger path may be represented in the form of a string or array, where each element corresponds to the switch state of a certain channel (e.g., 1 for closed, 0 for open). By reading this information from the table, the test scenario that is currently needed to be executed can be automatically determined.
S102, controlling the opening or closing of each trigger path between the relay and the POS terminal to be tested according to the appointed trigger path;
And the PC terminal controls the POS terminal to be tested by using the relay, and operates a trigger channel of the POS terminal to be tested according to the appointed trigger path read from the test case table.
Specifically, the relays can open or close the corresponding channels one by one according to the set trigger combination. For example, if the test case requires that channels 1 and 3 be closed, channels 2 and 4 be open, and the relay will perform these operations in sequence.
The control of the relay can be realized by sending instructions through a TCP/IP protocol, so that the state of each path accords with the expectations. After the PC terminal sends the send control command to the relay, a command may also be sent to confirm that the relay has completed execution.
In this step, a corresponding control command is generated according to the designated trigger path read from the test case. These instructions may be in a specific protocol command format for telling the relay the operation to perform. For example, the format of the control command may be SET RELAY CHANNEL ON (control channel 1 closed) or SET RELAY CHANNEL OFF (control channel 2 open). And the control instructions are sent one by one according to a preset trigger combination, so that the state of the relay meets the expected requirement.
S103, controlling the POS terminal to be tested to execute the test case;
The PC terminal can be connected with the POS terminal to be tested through a preset interface (such as a wireless link or a USB interface), and according to the test case, a test instruction is sent to start a relevant test program on the POS terminal. The test instructions may run test scripts through an automated test tool (e.g., a UI automation tool) that simulates user operational behavior. A unified protocol command (e.g., JSON or other communication protocol) may also be used to control POS terminals to perform specified operations to simulate user operation behavior specified in test cases. For example, pressing certain keys on the POS terminal, selecting particular options on the screen, executing a payment procedure, etc.
And simulating an actual operation scene according to the trigger path specified in the test case. This operation may be accomplished by combining the relay control module with the POS terminal internal logic.
The test system monitors the operation response of the POS terminal in real time through the interface, and records the UI interface change, the prompt information or the equipment behavior (if yes, the trigger occurs). The POS terminal records operation details through the internal log, and the test system can read log information from the POS terminal for analyzing the actual trigger path and behavior.
A specific implementation is provided below:
A wireless connection link between the PC terminal and the POS terminal to be tested is established through a wireless connection (e.g., wi-Fi), and an ADB (Android debug bridge) tool can be used for remote control.
And the PC terminal sends UI automation control instructions to the POS terminal to be tested through the wireless connection link so as to realize operations such as clicking, inputting, jumping and the like on the interface. These operations may include entering a menu page, performing a trigger state view operation, etc. The UI automation execution ensures the automation control of the test flow, manual intervention is not needed, and errors of manual operation are reduced.
When the trigger information of the POS terminal to be tested is obtained, the PC terminal needs to perform standardized data interaction with the POS terminal to be tested through a CDC (Communications DEVICE CLASS) protocol. CDC is a common communication protocol for transmitting data between a PC terminal and a POS terminal to be tested.
Due to the use of the CDC protocol, the serial port instruction cannot directly control the interface operation of the POS terminal to be tested. Therefore, UI automation operations cannot be realized through conventional serial communication.
In order to overcome the limitation of serial port instructions, the interface operation of the POS terminal to be tested is controlled by wireless connection and using an ADB tool to send instructions. The ADB can simulate clicking operation and interface jump of a user, and UI automatic test is realized.
The Wi-Fi ADB connection enables the PC terminal to perform automated operations on the interface of the POS terminal under test, such as clicking a button or navigating to a specific interface. This approach may simulate the user's operational behavior, thereby performing an automated test procedure.
S104, acquiring an actual trigger path fed back by the POS terminal to be tested after executing the test case;
And in the process of executing automatic operation by the POS terminal to be tested, the PC terminal acquires trigger state information reported by the POS terminal. The POS terminal to be tested reports the detected current actual trigger path to the PC terminal. The data may be transmitted in encrypted form, and then the PC terminal needs to decrypt or parse to obtain the actual designated trigger path of the plaintext.
In the process of executing automatic operation, the POS terminal to be tested detects the current actual trigger path and reports the trigger state information to the PC terminal. These data may be transmitted in JSON format, XML format, or custom protocol format.
For example, the trigger state information may be in JSON format as follows:
{
"triggerStatus":"encrypted_data_here",
"timestamp":"2024-10-15T12:34:56"
}
wherein the "triggerStatus" field contains the actual specified trigger path after encryption.
If the reported data may be transmitted in encrypted form, the PC terminal needs to decrypt the received data first. The specific implementation of decryption depends on the encryption algorithm and key management scheme employed.
S105, obtaining a test result according to the designated trigger path and the actual trigger path.
The PC terminal can verify whether the response of the POS terminal to be tested accords with the expectation by comparing the actual trigger path with the expected trigger path. If the actual trigger path is consistent with the expected trigger path, the test case passes, otherwise, the abnormality is recorded and the reason is further analyzed. After the test result is obtained, the PC terminal writes the test result into the test case table in real time to generate a test report. This ensures the integrity of the test data and provides reliable data support for subsequent analysis.
When the test case table is read, the PC terminal can use pandas libraries in the Python to read Excel files or CSV files, and load test case data into the program. And then acquiring the reported trigger state information from the POS terminal to be tested, and obtaining an actual trigger path through decryption and analysis. And comparing the actual value obtained by analysis with the expected value in the test case table.
If the actual value is the same as the expected value, the test result is recorded as "pass".
If not, recording the test result as failure and marking as abnormality.
And writing the comparison result (pass/fail) into the test case table in real time so as to track the test execution condition at any time.
The PC terminal may also update the test case table using the pandas library, writing the comparison result into a certain "test result" column in the table. Detailed test result information, including actual values of the test, expected values, comparison results, time stamps, etc., may be added to the test case table to provide a more detailed test report. And saving the test case table after the test result is written in real time in the file again. According to the embodiment, manual operation is reduced and testing efficiency is improved through automatic comparison and result recording.
In an alternative embodiment, the step S102 may be implemented in the following manner, where the implementation manner includes:
reading identification information representing an SD path from a specified trigger path, wherein characters or numbers in the identification information are used for representing a specific SD path;
And sequentially controlling the relays to sequentially disconnect the corresponding trigger paths according to the trigger sequence indicated by the identification information.
Step S102 of this alternative embodiment sequentially controls the relays by reading the designated trigger paths and in accordance with the trigger sequence indicated in the identification information. Firstly, a specified trigger path is read from a preset test case table, wherein the specified trigger path comprises an SD path state which needs to be operated.
The designated trigger path may be represented as an identification information, where each character or number is used to represent a particular SD way state, e.g., "1" for closed and "0" for open.
Each character or number in the identification information corresponds to the state of a certain SD way. For example, the string "1010" may represent the state of four SD ways, where:
The first character "1" indicates that path 1 needs to be closed;
the second character "0" indicates that way 2 needs to be disconnected;
the third character "1" indicates that path 3 needs to be closed;
The fourth character "0" indicates that the 4 th path needs to be disconnected.
And sequentially controlling the relays to execute corresponding operations one by one according to the analyzed SD channel state.
Specifically, each character of the identification information is traversed, and the following operations are performed on each character:
and judging the character value, and determining whether the current SD circuit needs to be closed or opened.
And sending corresponding control instructions to the relay, for example, sending instructions through TCP/IP, serial ports or other communication protocols, and controlling the relay to change the state of the relay.
And executing control operation on each SD path one by one according to the sequence corresponding to each character in the identification information. After each control operation, it is possible to confirm whether the state of the current relay coincides with the target state by sending a read instruction. If the confirmed result is consistent with the state indicated in the identification information, the operation is successful, otherwise, the abnormality is recorded or the control command is resent to correct.
In this implementation, if the last state of the current relay is the off state, the corresponding trigger path is maintained in the off state.
Specifically, before the trigger operation is performed, the last state of the current relay is first read, and it is determined whether each trigger path (SD path) is in the "closed" or "open" state.
For each character, it is determined whether an operation needs to be performed:
if the current character indicates "0" (off) and the last state of the relay is already "off", no operation is performed, and the current state is kept unchanged by direct skipping.
If the current character indicates a "0" (open), but the last state is "closed", then a command is sent to open the channel.
If the current character indicates a "1" (closed), an instruction is sent to close the channel, whether the last state was "closed" or "open".
In the implementation mode, if the last state of the current relay is a closed state, the method comprises the steps of judging whether the current trigger path is a target test trigger path or not, if so, controlling the relay to disconnect the trigger path, and recording the disconnection time point.
Specifically, first, the state information of the current relay is read, and it is determined whether the last state of the current relay is a closed state (i.e., the channel is in a conductive state). And comparing the trigger path of the current operation with the target test trigger path in the target test case.
If the current trigger path is the target test trigger path, continuing to execute the next step, and if not, skipping the operation of the current trigger path.
By sending a control command, an opening operation is performed to switch the relay from the closed state to the open state.
This may be accomplished by a TCP/IP protocol, serial communication, or other interface sending commands to the relay controller. For example, a command is sent to the relay to shut off the current, changing the state of the relay.
The point in time of the relay opening operation is recorded. This time may be marked with a system time, for example, call datetime module retrieves the current timestamp and records it.
The recorded data may include the trigger path number, the point in time of the disconnect operation, and possibly additional information (e.g., the current test number or identification of the test case).
The application also provides an alternative embodiment, which further improves the accuracy and reliability of the test by sending an instruction to the relay to confirm the state of the relay after the relay is controlled to disconnect the corresponding trigger path. This embodiment is described in detail below:
referring to fig. 2, an embodiment of a method for testing a trigger path of a POS terminal is provided in the present application, where the embodiment includes:
s201, acquiring a test case of a POS terminal to be tested, wherein the test case records a specified trigger path;
s202, determining other trigger paths except the designated trigger path from all trigger paths according to the identification information of the designated trigger path;
S203, controlling the relay to disconnect the rest trigger paths between the POS terminal to be tested and the control relay;
S204, sending trigger path state acquisition information to the relay;
s205, receiving state information of other trigger paths fed back by the relay to confirm whether the other trigger paths are disconnected;
After each control operation is performed, the PC terminal sends trigger path state acquisition information to the relay, for example, a read command may be sent to confirm whether the current relay state is consistent with the expected state. If the object is open and the current state is open, this indicates that the operation is expected, and if the object is closed and the current state is closed, this also indicates that the operation is expected. If a condition is detected that does not match the expected condition, an anomaly is recorded or corrective action is taken.
Specifically, a control command is sent to the relay immediately after the relay is controlled to operate (e.g., open or close a designated channel). The command is sent to the relay controller via a designated communication interface (e.g., TCP/IP, serial) to perform an open or close operation.
After the control operation is completed, a read command is sent to acquire the actual state of the current relay. The read command is used to query the current state (e.g., "closed" or "open") of each channel of the relay.
The controller of the relay returns state information of each channel, and the current state of each channel can be obtained by analyzing the returned data.
The returned actual state is compared with the expected state. If the target state is "open" and the read current state is also "open", this indicates that the operation is expected, and if the target state is "closed" and the read state is also "closed", this also indicates that it is expected.
If the actual state does not match the expected state, this may indicate that the operation may fail or that the relay does not respond properly to the control command.
If the detected state does not meet the expectations, the recording of exception information may be selected, including relay channel number, expected state, actual state, and time stamp of operation. This information can be used for subsequent analysis and troubleshooting.
At the same time corrective action may be taken, such as resending control commands attempting to perform the corresponding operation again, or triggering an alarm notification, in order to deal with the problem in time.
By verifying the execution result of each control operation, the problems can be found and corrected in time, and the accuracy of the test process is ensured.
S206, controlling the POS terminal to be tested to execute the test case;
s207, acquiring an actual trigger path fed back by the POS terminal to be tested after executing the test case;
s208, obtaining a test result according to the designated trigger path and the actual trigger path.
Steps not described in detail in this embodiment, and the specific implementation manner thereof is similar to the relevant steps in the foregoing embodiment, and will not be repeated here.
The application also provides an optional embodiment, which provides a specific implementation mode for controlling the POS terminal to be tested to execute the test case, and the UI automation operation is controlled to be executed by the POS terminal to be tested through wireless connection with the POS terminal to be tested. Referring to fig. 3, this embodiment includes:
s301, acquiring a test case of a POS terminal to be tested, wherein the test case records a specified trigger path;
s302, controlling the opening or closing of each trigger path between the relay and the POS terminal to be tested according to the appointed trigger path;
S303, reading an automatic test script aiming at a UI interface of the POS terminal to be tested;
Firstly, reading operation instructions and steps aiming at a UI interface of a POS terminal to be tested from an automatic test script file prepared in advance. These scripts contain a series of commands defining the UI operations that need to be performed, such as clicking buttons, entering text, selecting menus, etc. The test script may be a JSON, XML or other formatted file containing various UI operational instructions. At the time of reading, the file content may be processed using a suitable parser.
S304, starting an automatic test script, and sending a test instruction to the POS terminal to be tested through a wireless connection link;
after the test script is read, the script will be started. Such as parsing commands and parameters in the script for subsequent execution. A connection is established with the POS terminal under test via a wireless connection link (e.g., wi-Fi) so that an instruction can be sent to the target device.
S305, simulating user operation behaviors according to the test instruction, and controlling the POS terminal to be tested to execute corresponding UI automation operation;
and converting the instructions in the automatic test script into a format suitable for the POS terminal to be tested, and transmitting the instructions through a wireless connection link. The instructions may include a simulation of user behavior such as clicking on a UI element, entering text into an input box, sliding a screen, etc.
And according to the received test instruction, controlling the POS terminal to be tested to simulate the corresponding user operation behavior. This operation may be implemented by an ADB or the like tool for automated execution on the target device. At this stage, the UI of the POS terminal to be tested may be changed according to an instruction, for example, to navigate to a specific page or to perform a specific function.
S306, monitoring and recording UI interface changes of the POS terminal to be tested;
In the automatic operation process, the UI interface change of the POS terminal to be detected is continuously monitored. This may be accomplished by capturing a screenshot, reading the UI element state, obtaining the current properties of the UI control, and so forth. The result and status of the operation may be recorded by the ADB obtaining a screenshot or reading attributes of the UI element. The format of the record data may be selected from CSV, JSON, or database storage for subsequent analysis.
The changed data is recorded, and the changed data comprises information such as operation time, operation steps, UI states, response time and the like. These data can be used for subsequent test analysis and problem investigation.
S307, acquiring an actual trigger path fed back by the POS terminal to be tested after executing the test case, and S308, obtaining a test result according to the designated trigger path and the actual trigger path.
UI test is executed through an automatic script, manual operation is reduced, and test speed and efficiency are improved. The automatic test can ensure the consistency and repeatability of the test process and reduce the influence of human errors.
In this embodiment, steps not described in detail are similar to those related to the foregoing embodiment, and will not be described here again.
The application also provides an alternative embodiment, which provides a specific implementation way for establishing a wireless connection link with the POS terminal to be tested through the ADB tool and controlling the wireless connection link to execute UI automation operation. Referring to fig. 4, this embodiment is described in detail below, and includes:
s401, acquiring a test case of a POS terminal to be tested, wherein the test case records a specified trigger path;
S402, controlling opening and/or closing of each trigger path between the relay and the POS terminal to be tested according to the appointed trigger path;
S403, sending an ADB command to the POS terminal to be tested through an ADB tool, and acquiring the IP address of the POS terminal to be tested;
And acquiring the IP address of the POS terminal to be tested through an ADB (Android debug bridge) tool, so as to prepare for subsequent wireless connection.
First, the PC terminal is connected to the POS terminal through USB, and the ADB tool is already installed and configured. The command adb devices can be used to see if the connection is correct. If the serial number of the POS device is displayed, this indicates that the connection was successful.
The ADB command ADB shell ip route is used to run the command on the POS terminal under test. The return result of the command contains network routing information of the POS terminal to be tested. The IP address after "default via" is the current network address of the POS terminal.
And extracting IP address information in command output for use in subsequent steps. For example, if the output is default via 192.168.1.100dev wlan0, 192.168.1.100 is the IP address of the POS terminal.
S404, configuring ADB service on the POS terminal to be tested into a TCP/IP mode, and monitoring a designated port;
The ADB service is switched from USB mode to TCP/IP mode, allowing communication over Wi-Fi. The ADB service is first configured to TCP/IP mode by using the command ADB TCP < port >, where < port > is a specified port number, e.g., 5555, to set the ADB service to TCP/IP mode. This command initiates the TCP/IP mode of the ADB at the POS terminal and listens to the designated port.
When the command execution is successful, the ADB service will listen for connection requests from the PC on the designated port of the POS terminal. At this point, the POS terminal may already accept Wi-Fi mode ADB connectivity.
S405, establishing Wi-Fi connection with a POS terminal to be tested through an IP address, and carrying out communication based on a CDC protocol with the POS terminal to be tested through a designated port;
ADB connection between the PC terminal and the POS terminal to be tested is established through Wi-Fi, so that a channel is provided for subsequent communication based on CDC protocol.
First connect to the POS terminal under test through ADB, < port > can be connected to the POS terminal under test through Wi-Fi using the command ADB connect < ip_address >, where < ip_address > is the POS terminal IP address previously acquired and < port > is the designated listening port (e.g., 5555). For example, the command may be adb connect 192.168.1.100:5555.
After the ADB connection is established, communication with the POS terminal can be performed through a CDC protocol. CDC (Communication DEVICE CLASS) is a standard protocol for data transmission and device control. Various control commands and data transmission instructions can be sent through the ADB, so that remote control and operation of the POS terminal to be tested can be realized.
In the process, an automatic test instruction can be sent to control the UI of the POS terminal to be tested, clicking, inputting, jumping and other operations are executed, and user behaviors are simulated.
The Wi-Fi connection is communicated with the POS terminal to be tested, so that a user is allowed to operate without physically contacting the equipment, and flexibility of testing and maintenance is improved. Through ADB tool and TCP/IP mode, user can dispose POS terminal fast, avoid complicated connection step, make the preparation work of equipment more high-efficient. And the ADB is utilized to send commands and control UI automation operation, so that the requirement of manual intervention is reduced, the efficiency and consistency of the testing process are improved, and the risk of human errors is reduced.
S406, acquiring an actual trigger path fed back by the POS terminal to be tested after executing the test case;
s407, obtaining a test result according to the designated trigger path and the actual trigger path.
In this embodiment, steps not described in detail are similar to those related to the foregoing embodiment, and will not be described here again.
Referring to fig. 5, another embodiment of a method for testing a trigger path of a POS terminal is provided, which includes:
s501, acquiring a test case of a POS terminal to be tested, wherein the test case records a specified trigger path;
S502, controlling the opening or closing of each trigger path between the relay and the POS terminal to be tested according to the appointed trigger path;
s503, establishing Wi-Fi connection with a POS terminal to be tested;
the PC terminal can acquire a dynamic or static IP address of the PC terminal under the current Wi-Fi network through an ADB tool or a POS terminal management interface, so as to construct Wi-Fi connection.
S504, transmitting a unified communication protocol format to the POS terminal to be tested through Wi-Fi connection, and transmitting a remote control instruction to the POS terminal to be tested so as to execute UI automation operation of the test case;
The communication protocol format may be a standardized format such as JSON, XML, etc. The PC terminal may send a remote control command to the IP address and the designated port of the POS terminal using a network programming tool (e.g., socket programming or HTTP interface). After the POS terminal receives the instruction, the protocol content is analyzed, and corresponding UI operation, such as clicking a button, inputting a text or triggering sliding operation, is triggered according to the test case.
S505, acquiring an actual trigger path fed back by the POS terminal to be tested after executing the test case;
s506, obtaining a test result according to the designated trigger path and the actual trigger path.
In an alternative embodiment, if the actual trigger path is encrypted data, executing decryption operation to obtain a decrypted actual trigger path, and comparing the designated trigger path with the decrypted actual trigger path to obtain a test result of the test case.
In some cases, the trigger path returned by the POS terminal under test may be transmitted in encrypted form. This is due to security requirements (e.g., preventing data leakage) or communication mechanism requirements of the system. The encrypted actual trigger path can be compared with the designated trigger path after decryption, otherwise, whether the test case is successful or not cannot be correctly verified. The decryption operation ensures that the data on which the comparison is based is readable and accurate. The un-decrypted data may be completely mismatched with the designated trigger path due to the randomness of the encryption algorithm, thereby obtaining an erroneous test result. After decryption operation, the decrypted actual trigger path is obtained, and then compared with the designated trigger path, so that the result of the test case is obtained based on correct and real data.
Further, the test case may be a test case in a preset test case table, where the preset test case table is further used to record an actual trigger path and a test result after each test case is executed.
In this embodiment, remote operation is supported through Wi-Fi connection and standardized communication protocols, and is suitable for various test environments. The test instruction can be automatically sent, so that manual intervention is reduced, and the test efficiency is improved. The unified communication protocol is convenient for adding instruction types and functions, and meets the complex test requirements.
The foregoing embodiment describes in detail a method for testing a POS terminal trigger path provided in the present application, and describes an embodiment of a device for testing a POS terminal trigger path provided in the present application, with reference to fig. 6, where the embodiment includes:
The test case reading module 601 is configured to obtain a test case of a POS terminal to be tested, where the test case records a specified trigger path;
The relay control module 602 is configured to control opening or closing of each trigger path between the relay and the POS terminal to be tested according to the specified trigger path;
a POS terminal control module 603, configured to control the POS terminal to be tested to execute the test case
The actual trigger path obtaining module 604 is configured to obtain an actual trigger path fed back by the POS terminal to be tested after executing the test case;
the test module 605 is configured to obtain a test result according to the specified trigger path and the actual trigger path;
optionally, the relay control module 602 is specifically configured to:
determining the rest trigger paths except the appointed trigger path from the trigger paths according to the identification information of the appointed trigger path;
And controlling a relay to disconnect the rest trigger paths between the relay and the POS terminal to be tested.
Optionally, the relay control module 602 is further configured to:
Maintaining the disconnection state of the rest trigger paths.
Optionally, the relay control module 602 is further configured to:
sending trigger path state acquisition information to the relay;
and receiving state information of the rest trigger paths fed back by the relay so as to confirm whether the rest trigger paths are disconnected.
The POS terminal control module 603 specifically is configured to:
establishing Wi-Fi connection with the POS terminal to be tested;
And sending a unified communication protocol format to the POS terminal to be tested through the Wi-Fi connection, and sending a remote control instruction to the POS terminal to be tested so as to execute the UI automation operation of the test case.
The test module 605 is specifically configured to:
if the actual trigger path is encrypted data, executing decryption operation to obtain a decrypted actual trigger path;
and comparing the appointed trigger path with the decrypted actual trigger path to obtain a test result of the test case.
Optionally, the test case is a test case in a preset test case table, and the preset test case table is further used for recording an actual trigger path and a test result after each test case is executed
Referring to fig. 7, the present application further provides an embodiment of a testing apparatus for a trigger path of a POS terminal, including:
a processor 701, a memory 702, an input/output unit 703, and a bus 704;
The processor 701 is connected to the memory 702, the input-output unit 703, and the bus 704;
The memory 702 holds a program, and the processor 701 calls the program to execute any of the methods described above.
The application also relates to a computer readable storage medium having a program stored thereon, which when run on a computer causes the computer to perform any of the methods described above.
It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, which are not repeated herein.
In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.
The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in part or all of the technical solution or in part in the form of a software product stored in a storage medium, including instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present application. The storage medium includes a usb disk, a removable hard disk, a read-only memory (ROM), a random-access memory (RAM, random access memory), a magnetic disk, an optical disk, or other various media capable of storing program codes.