WO2023230798A1 - Cross-system key testing method and apparatus - Google Patents

Abstract

Embodiments of the present disclosure disclose a cross-system key testing method and apparatus. The method comprises: transmitting, by means of a remote process calling (RPC) module, a key instruction to a system to be tested, wherein the key instruction comprises an identifier of a target key and a target control mode; receiving, by means of the RPC module, state information returned by the system to be tested; and determining a test result corresponding to the identifier of the target key according to the state information and the identifier of the target key. Hence, a testing system can transmit, by means of the RPC module, the key instruction to the system to be tested, receive the state information returned by the system to be tested, and then can determine the corresponding test result according to the state information and the identifier of the target key, so that it is avoided that the test result of the target key is determined by means of querying multiple times, a key testing process is simplified, the time is saved, and the key testing efficiency is improved.

Description

A cross-system key testing method and device Technical field

The present disclosure relates to the field of computer technology, and in particular, to a cross-system key testing method, device, electronic equipment and storage medium.

Background technique

With the development of computer technology, various applications or systems are iteratively updated faster and faster. It is usually necessary to test the corresponding keys to determine whether the functions of the keys are normal and whether the keys can be used normally.

In related technologies, when testing buttons in the system to be tested, a button command is usually issued first. Since the execution status of the command is not known, it is impossible to know whether the execution is completed. Active query is usually required to determine the expected button. Whether the execution is completed or not, the process is more cumbersome and may be less efficient. Therefore, how to improve the efficiency of key testing is crucial.

Contents of the invention

Embodiments of the present disclosure provide a cross-system key testing method and device.

In the first aspect, embodiments of the present disclosure provide a cross-system key testing method, which is executed by the testing system, including:

Send key press instructions to the system under test through remote procedure call RPC module, where the key press instructions include the identification of the target key and the target control mode;

Receive status information returned by the system under test through the RPC module;

According to the status information and the identification of the target key, the test result corresponding to the identification of the target key is determined.

Optionally, after receiving the status information returned by the system to be tested through the RPC module, it also includes:

In response to the status information indicating that the application switch is successful, determine the type of the first application switched to the background of the system to be tested;

Adjust the connection state between the first application and the test system according to the type of the first application.

Optionally, adjusting the connection status between the first application and the test system according to the type of the first application includes:

When the first application is a resident application, maintain the connection with the first application;

When the first application is a non-resident application, disconnect the connection with the first application and release the status information corresponding to the first application.

Optionally, after receiving the status information returned by the system to be tested through the RPC module, it also includes:

In response to the status information indicating a focus change or a page change in the second application, the stored status information corresponding to the second application is updated.

Optionally, before sending key instructions to the system under test through the remote procedure call RPC module, it also includes:

The obtained test cases are parsed to determine the identification of the target button and the target control mode.

Optionally, determining the test result corresponding to the target key identification based on the status information and the identification of the target key includes:

In response to the identification of the target button as the return button, determine the test result corresponding to the return button based on the currently displayed application, page and/or focus location information in the system to be tested in the status information; or,

In response to the identification of the target button as a volume button, determine the test result corresponding to the volume button according to the current volume of the system to be tested in the status information; or,

In response to the identification of the target button as a startup button associated with any application, determine the test result corresponding to the startup button associated with any application according to the application currently displayed in the system to be tested in the status information; or ,

In response to the identification of the target button as a main interface button, the test result corresponding to the main interface button is determined according to the interface currently displayed in the system to be tested in the status information.

In the second aspect, embodiments of the present disclosure provide a cross-system key testing method, which is executed by the system to be tested, including:

Receive the key instructions sent by the test system through the remote procedure call RPC module, where the key instructions include the identification of the target key and the target control mode;

Start the listening process;

Based on the target control mode, control the target button corresponding to the identification of the target button;

Through the RPC module, the status information obtained by the listening process is sent to the test system.

Optionally, before sending the status information obtained by the listening process to the test system, the method further includes:

The status information to be returned is determined according to the identification of the target button.

Optionally, determining the status information to be returned based on the identification of the target button includes:

In response to the identification of the target button as the return button, the status information is generated based on the currently displayed application, page and focus location information in the system; or,

In response to the target button being identified as a volume button, generating the status information according to the current volume of the system; or,

In response to the identification of the target button as a startup button associated with any application, generate the status information according to the application currently displayed in the system; or,

In response to the identification of the target button as a main interface button, the status information is generated according to the interface currently displayed in the system.

In a third aspect, embodiments of the present disclosure provide a cross-system key testing device, which is configured on the test system side and includes:

A sending module, configured to send key instructions to the system to be tested through remote procedure call RPC modules, where the key instructions include the identification of the target key and the target control mode;

A receiving module, configured to receive status information returned by the system under test through the RPC module;

A determining module, configured to determine a test result corresponding to the target button identification based on the status information and the target button identification.

Optional, the determination module includes:

a determining unit configured to determine the type of the first application switched to the background of the system to be tested in response to the status information indicating that the application switching is successful;

An adjustment unit, configured to adjust the connection state between the first application and the test system according to the type of the first application.

Optional, the adjustment unit is specifically used for:

When the first application is a resident application, maintain the connection with the first application;

When the first application is a non-resident application, disconnect the connection with the first application and release the status information corresponding to the first application.

Optional, also includes:

An update module, configured to update the stored status information corresponding to the second application in response to the status information indicating a focus change or page change in the second application.

Optional, also includes:

An analysis module is used to analyze the obtained test cases to determine the identification of the target button and the target control mode.

Optional, the determination module is specifically used for:

In response to the identification of the target button as the return button, determine the test result corresponding to the return button based on the currently displayed application, page and/or focus location information in the system to be tested in the status information; or,

In response to the identification of the target button as a volume button, determine the test result corresponding to the volume button according to the current volume of the system to be tested in the status information; or,

In response to the identification of the target button as a startup button associated with any application, determine the test result corresponding to the startup button associated with any application according to the application currently displayed in the system to be tested in the status information; or ,

In response to the identification of the target button as a main interface button, the test result corresponding to the main interface button is determined according to the interface currently displayed in the system to be tested in the status information.

In a fourth aspect, embodiments of the present disclosure provide a cross-system key testing device, which is configured on the side of the system to be tested, including:

The receiving module is used to receive the key instructions sent by the test system through the remote procedure call RPC module, wherein the key instructions include the identification of the target key and the target control mode;

Start module, used to start the listening process;

A control module, configured to control the target button corresponding to the identification of the target button based on the target control mode;

A sending module, configured to send the status information obtained by the listening process to the test system through the RPC module.

Optional, also includes:

A determining module, configured to determine the status information to be returned according to the identification of the target button.

Optional, the determination module is specifically used for:

In response to the identification of the target button as the return button, the status information is generated based on the currently displayed application, page and focus location information in the system; or,

In response to the target button being identified as a volume button, generating the status information according to the current volume of the system; or,

In response to the identification of the target button as a startup button associated with any application, generate the status information according to the application currently displayed in the system; or,

In response to the identification of the target button as a main interface button, the status information is generated according to the interface currently displayed in the system.

In a fifth aspect, an embodiment of the present disclosure provides an electronic device, including: a processor; a memory for storing executable instructions of the processor; wherein the processor is configured to call and execute instructions stored in the memory. The instructions can be executed to implement the cross-system key testing method proposed in the first embodiment of the present disclosure, or to implement the cross-system key testing method proposed in the second embodiment of the disclosure.

In a sixth aspect, embodiments of the present disclosure provide a non-transitory computer-readable storage medium that, when instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to execute what is proposed in the first embodiment of the present disclosure. cross-system key testing method, or perform the cross-system key testing method proposed by the embodiment of the second aspect of the present disclosure.

In a seventh aspect, embodiments of the present disclosure provide a computer program product. When the computer program is executed by a processor of an electronic device, the electronic device can perform the cross-system key testing method proposed in the embodiment of the first aspect of the disclosure, or execute The cross-system key testing method proposed by the embodiment of the second aspect of the present disclosure.

With the cross-system key testing method, device, electronic equipment and storage medium provided by the present disclosure, the test system can send key instructions to the system to be tested through the remote procedure call RPC module, where the key instructions include the identification of the target key and the target control mode. , and then the status information returned by the system to be tested can be received through the RPC module, and the test result corresponding to the target button ID can be determined based on the status information and the target button ID. As a result, the test system can send key commands to the system under test through the RPC module, and receive the status information returned by the system under test. Then, the corresponding test results can be determined based on the status information and the identification of the target button, thus avoiding multiple attempts. Query to determine the test results of the target button, which simplifies the button test process, saves time, and improves the efficiency of the button test.

Description of the drawings

In order to more clearly illustrate the technical solutions in the embodiments of the disclosure or the background technology, the drawings required to be used in the embodiments or the background technology of the disclosure will be described below.

Figure 1 is a flow chart of a cross-system key testing method according to an embodiment of the present disclosure;

Figure 2 is a flow chart of a cross-system key testing method according to an embodiment of the present disclosure;

Figure 3 is a flow chart of a cross-system key testing method according to an embodiment of the present disclosure;

Figure 4 is a flow chart of a cross-system key testing method according to an embodiment of the present disclosure;

Figure 5 is a schematic structural diagram of a cross-system key testing device according to an embodiment of the present disclosure;

Figure 6 is a schematic structural diagram of a cross-system key testing device according to an embodiment of the present disclosure;

Figure 7 is a schematic structural diagram of an electronic device according to an embodiment of the present disclosure.

Detailed ways

Embodiments of the present disclosure are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present disclosure and are not to be construed as limitations of the present disclosure.

The following describes the cross-system key testing method, device, electronic device, and storage medium according to the embodiments of the present disclosure with reference to the accompanying drawings.

The cross-system key testing method of the embodiment of the present disclosure can be executed by the cross-system key testing device provided by the embodiment of the present disclosure, and the device can be configured in an electronic device.

FIG. 1 is a schematic flowchart of a cross-system key testing method provided by an embodiment of the present disclosure. The method can be executed by a testing system.

As shown in Figure 1, the cross-system key testing method can include the following steps:

Step 101: Send a key command to the system under test through a remote procedure call RPC module, where the key command includes the identification of the target key and the target control mode.

Among them, remote procedure call (RPC) can request services from a remote computer through the network without knowing the underlying network technology. It usually adopts the client device and server device mode, and the party requesting the service is the client device. , the party providing services is the server device.

Therefore, the test system in this disclosure is the client device that requests RPC services, and the system under test is the server device that provides services. That is, the test system can send key instructions to the system under test through the RPC module, so that the system under test can perform test operations on the corresponding keys based on the key instructions, etc.

In addition, the system to be tested can be any system, such as a mobile phone system, a television system, a computer system, etc. This disclosure does not limit this.

In addition, the key command can be any form of command, which can include the identification of the target key and the target control mode.

In addition, the target button can be a button to be tested or controlled. The logo style or presentation form of the target button can be set in advance, for example, it can be a "start" button, a "return" button, "1", Volume "+" button, etc., this disclosure does not limit this.

In addition, the target control mode can be a control process performed on the target button, for example, it can be: increasing the volume, returning to the previous level, exiting the current page, etc. This disclosure does not limit this.

Step 102: Receive status information returned by the system to be tested through the RPC module.

It can be understood that the test system can send key press instructions to the test system through the RPC module, so that the system under test can control the target key according to the target control mode, and then the status information of the target key after manipulation can be processed through The RPC module is sent to the test system, so that the test system can receive the status information returned by the system under test through the RPC module.

Among them, the status information can be used to represent the status after processing by the target control mode. It can be of many types, such as the content of the current interface, volume information, current application information, application switching results, etc. This disclosure does not Make limitations.

For example, the status information returned by the system under test received by the test system through the RPC module is: volume is 10; or the status information returned by the system under test received by the test system through the RPC module can also be: application 2 and so on. This disclosure does not limit this.

Therefore, in the embodiment of the present disclosure, when performing a key test, the test system can first send a key instruction to the system to be tested, and then receive the status information returned by the system to be tested, thereby avoiding multiple queries to determine the status information of the target key. Provides conditions for improving testing efficiency.

Step 103: Determine the test result corresponding to the target button ID based on the status information and the target button ID.

In addition, the target button identification can be of various types, such as "return button", "volume button", "start button associated with any application", "main interface button", etc. This disclosure does not limit this.

For example, if the label of the target button is "Volume +" and the status information is "Volume Up", then it can be determined that the test result of "Volume +" is: normal. Or, if the mark of the target button is "Volume -" and the status information is "Volume remains unchanged", then it can be determined that the test result of "Volume -" is: abnormal. Or, if the target button is identified as "menu" and the status information is "menu interface", then it can be determined that the test result of "menu" is: normal.

It should be noted that the above examples are only schematic illustrations and cannot be used as limitations on the target buttons, status information, test results, etc. in the embodiments of the present disclosure.

It can be understood that the status information may also include the application, page, current volume, etc. currently displayed in the system to be tested. Therefore, in the embodiment of the present disclosure, the status information may also be based on the content included in the status information and the identification of the target button. , determine the test results corresponding to the target button identification, etc.

Optionally, in response to the target button being identified as the return button, the test result corresponding to the return button may be determined based on the currently displayed application, page and/or focus location information in the system to be tested in the status information.

For example, when the target button is identified as the return button, if the application currently displayed in the system under test in the status information is: Application 1, compared with the original "Application 2", "Application 2" After returning to "Application 1", it can be determined that the test result corresponding to the return button is: normal.

Or, when the target button is identified as a return button, such as "back button", if the page currently displayed in the system to be tested in the status information is: Page 2 in Application 1, the request to the system to be tested is not sent through the RPC module. The page before the test system sends the key command is: Page 1 in Application 1, then it can be determined that the test result corresponding to the returned key is: normal.

Or, in the case where the target button is identified as the return button, if the position information of the current focus in the system under test in the status information is: the input box in application 1, before sending the key command to the system under test through the RPC module The page is: input interface, then it can be determined that the test result corresponding to the return button is: normal.

It should be noted that the above examples are only schematic illustrations and cannot be used as limitations on the target key identification, status information, test results of the target key identification, etc. in the embodiments of the present disclosure.

Optionally, in response to the identification of the target button as a volume button, determine the test result corresponding to the volume button based on the current volume of the system to be tested in the status information.

For example, when the target button is identified as: volume + button, if the current volume of the system under test in the status information is: 15, and compared with the original "14", the volume has increased, then it can be determined The test result of "Volume + Keys" is: normal; or, if the current volume of the system under test in the status information is: 13, which is smaller than the original "14", then it can be determined that the "Volume + Keys" "The test results are: abnormal, etc., this disclosure does not limit this.

Optionally, in response to the target button being identified as a startup button associated with any application, determine the test result corresponding to the startup button associated with any application based on the application currently displayed in the system to be tested in the status information.

Among them, any application can be a video application, a game application, a browser application, an office application, a fitness application, etc., and this disclosure does not limit this.

For example, if the target button is identified as the startup button associated with "XX Video", and if the application currently displayed in the system is: XX Video, then it can be determined that the test result of the startup button associated with "XX Video" is: normal. Or, if the target button is identified as the startup button associated with "YY Browser", and if the application currently displayed in the system is: AA game, then it can be determined that the test result of the startup button associated with "YY Browser" is: abnormal.

It should be noted that the above examples are only schematic illustrations and cannot be used as a limitation on the test results of any application and the startup button associated with any application in the embodiments of the present disclosure.

Optionally, in response to the identification of the target button as the main interface button, determine the test result corresponding to the main interface button according to the interface currently displayed in the system to be tested in the status information.

For example, when the target button is identified as a main interface button and the interface currently displayed in the system is: main interface, then it can be determined that the test result of the "main interface button" is: normal. Or, in the case where the target button is identified as the main interface button, if the interface currently displayed in the system is: XX browser, then it can be determined that the test result of the "main interface button" is: abnormal, etc., this disclosure does not Make limitations.

Therefore, in the embodiment of the present disclosure, the test system can determine the test results corresponding to the target button identification based on the received status information returned by the system to be tested and the identification of the target button, thereby avoiding multiple queries to determine the status information of the target button. That is to say, the target button is tested through non-active polling, which simplifies the button test process, saves testing time, reduces the amount of data processing, and improves the efficiency of button testing.

In the embodiment of the present disclosure, the test system can send key instructions to the system to be tested through the remote procedure call RPC module, where the key instructions include the identification of the target key and the target control mode, and can then receive the information returned by the system under test through the RPC module. status information, and determine the test results corresponding to the target button ID based on the status information and the target button ID. As a result, the test system can send key commands to the system under test through the RPC module, and receive the status information returned by the system under test. Then, the corresponding test results can be determined based on the status information and the identification of the target button, thus avoiding multiple attempts. Query to determine the test results of the target button, which simplifies the button test process, saves time, and improves the efficiency of the button test.

FIG. 2 is a schematic flowchart of a cross-system key testing method provided by an embodiment of the present disclosure. The method can be executed by the testing system. As shown in Figure 2, the cross-system key testing method can include the following steps:

Step 201: Analyze the obtained test case to determine the identity of the target button and the target control mode.

Among them, a test case can be a set of data consisting of preconditions, inputs, execution conditions, expected results, etc., to complete the test of a specific requirement or goal, and a document that embodies the test plan, method, technology and strategy.

Optionally, test cases uploaded by users can be obtained through a specific interface. For example, test cases uploaded by testers can be obtained through the python interface, and this disclosure does not limit this.

It can be understood that the obtained test case can be parsed to determine the content of the test case, and then the identification of the corresponding target button and the target control mode can be determined based on the test content.

For example, if the test case is "whether focus is found normally", then the corresponding target button can be the "return button", the target control mode can be "trigger the return button", etc. This disclosure does not limit this.

Step 202: Send a key press instruction to the system under test through the RPC module, where the key press instruction includes the identification of the target key and the target control mode.

Step 203: Receive status information returned by the system to be tested through the RPC module.

It should be noted that, for the specific contents and implementation methods of step 202 and step 203, reference can be made to the descriptions of other embodiments of the present disclosure, and will not be described again here.

Step 204: In response to the status information indicating that the application switching is successful, determine the type of the first application to be switched to the background of the system to be tested.

It can be understood that after receiving the status information returned by the system to be tested, the test system can parse the status information to determine the specific content indicated by the status information, etc. This disclosure does not limit this.

The first application may have multiple types, such as a resident application, a non-resident application, etc., which is not limited in this disclosure.

In addition, the type of application can be set in advance. For example, communication applications and office applications can be resident applications; game applications and tool applications can be non-resident applications, etc. Therefore, the test system can determine the type of the first application after receiving the status information returned by the system to be tested. This disclosure does not limit this.

Alternatively, the resident application list or the non-resident application list can also be set in advance, so that by traversing the resident application list, when the resident application list contains the first application name or identification, the first application can be determined to be the resident application. ; Or when it is determined that the first application identifier is not included in the resident application list, it may be determined that the first application is a non-resident application.

It should be noted that the above examples are only schematic illustrations and cannot be used as limitations on the manner of determining the type of the first application to be switched to the background of the system to be tested in the embodiments of the present disclosure.

Step 205: Adjust the connection status between the first application and the test system according to the type of the first application.

It can be understood that the types of the first applications are different, and the connection status between the first application test systems may be the same, or may be different, etc., and this disclosure does not limit this.

Optionally, when the first application is a resident application, the connection with the first application can be maintained, so that the test system can maintain the connection with the first application and communicate with the first application in a timely manner, or Get the first application information in time.

Optionally, when the first application is a non-resident application, disconnect the connection with the first application and release the status information corresponding to the first application.

It can be understood that when the first application is a non-resident application, the test system can disconnect from the first application and then release the status information corresponding to the first application, that is, delete the status information corresponding to the first application. , release memory.

Therefore, in the embodiment of the present disclosure, the test system can adjust the connection status between the first application and the test system according to the type of the first application to determine whether to maintain or disconnect the connection with the first application, so as to maximize the Resource utilization and avoid resource waste.

Optionally, in response to the status information indicating a focus change or page change in the second application, update the stored status information corresponding to the second application.

For example, in the case where the second application is "XX Game", if the status information indicates a focus change, for example, the focus can be moved from the "input box" to the "menu" control, then the updated stored status information is: The focus of "XX Game" changes, moving from the "Input Box" to the "Menu" control.

Or, in the case where the second application is "YY Browser", if the status information indicates that the page changes, for example, from the "main page" to the "search page", then the status information stored in "YY Browser" can be updated. for "Search Page".

It should be noted that the above examples are only schematic illustrations and cannot be used as limitations on the manner of updating the stored status information corresponding to the second application in the embodiments of the present disclosure.

In this disclosed embodiment, the test system can first parse the obtained test cases to determine the identification of the target key and the target control mode, and then can send key instructions to the system under test through the RPC module, and receive the return from the system under test through the RPC module. status information, when the status information indicates that the application switching is successful, determine the type of the first application to be switched to the background of the system to be tested, and when the first application is a resident application, maintain the connection with the first application. When the application is a non-resident application, the connection with the first application is disconnected and the status information corresponding to the first application is released. Therefore, after determining the identification of the target key and the target control mode, the key instructions can be sent to the system to be tested and the status information returned by the system to be tested can be received. When the status information is used to indicate successful application switching, the system can be configured according to the first The type of application determines the connection relationship with the first application, thereby saving memory space and improving memory utilization.

FIG. 3 is a schematic flowchart of a cross-system key testing method provided by an embodiment of the present disclosure. The method can be executed by the system to be tested. As shown in Figure 3, the cross-system key testing method can include the following steps:

Step 301: Receive the key command sent by the test system through the remote procedure call RPC module, where the key command includes the identification of the target key and the target control mode.

It can be understood that after the system under test receives the key press command sent by the test system through the RPC module, it can analyze the key press command to determine the identification of the target key and the target control mode.

In addition, the target button can be a button to be tested or controlled. The logo style or presentation form of the target button can be set in advance, for example, it can be a "start" button, a "return" button, "1", Volume "+" button, etc., this disclosure does not limit this.

In addition, the target control mode can be a control process performed on the target button, for example, it can be: increasing the volume, returning to the previous level, exiting the current page, etc. This disclosure does not limit this.

Step 302: Start the listening process.

It can be understood that after receiving the key press command sent by the test system, the system to be tested can start a monitoring process to monitor the test operation to be performed. For example, the memory can be monitored, the running status can be monitored, etc. This disclosure does not limit this.

Step 303: Based on the target control mode, control the target button corresponding to the identification of the target button.

For example, if the label of the target button is "Volume +" and the target control mode is "Volume Increase", then the "Volume +" button can be triggered to increase the volume.

Alternatively, if the target button is labeled "Exit" and the target control mode is "Exit current interface", then the "Exit" button can be triggered to exit the current interface.

It should be noted that the above examples are only schematic illustrations and cannot be used as limitations on the target control mode, identification of target buttons, etc. in the embodiments of the present disclosure.

Step 304: Send the status information obtained by the listening process to the test system through the RPC module.

It can be understood that after the system to be tested starts the monitoring process, it can control the target button corresponding to the target button's logo based on the target control mode. During this period, the monitoring process can monitor the control of the target button by the system to be tested. , and obtain the corresponding status information, and then send the status information obtained by the listening process to the test system through the RPC module.

In this disclosed embodiment, the system to be tested can first receive the key command sent by the test system through the remote procedure call RPC module. The key command includes the identification of the target key and the target control mode. Then the monitoring process can be started, and then the control can be based on the target. mode, control the target button corresponding to the target button's logo, and then send the status information obtained by the listening process to the test system through the RPC module. Therefore, after parsing the received key command, the system to be tested can start the listening process and control the target key based on the target control mode. Afterwards, the status information obtained by the listening process can be sent to the test system, so that the test system The test result of the target button can be determined based only on the status information returned by the system to be tested. This eliminates the need for the test system to query multiple times to determine the test result, simplifying the button test process, saving time, and improving the efficiency of button test.

FIG. 4 is a schematic flowchart of a cross-system key testing method provided by an embodiment of the present disclosure. The method can be executed by the system to be tested. As shown in Figure 4, the cross-system key testing method can include the following steps:

Step 401: Receive the key command sent by the test system through the remote procedure call RPC module, where the key command includes the identification of the target key and the target control mode.

Step 402: Start the listening process.

Step 403: Based on the target control mode, control the target button corresponding to the identification of the target button.

It should be noted that, for the specific contents and implementation methods of steps 401 to 403, reference can be made to the descriptions of other embodiments of the present disclosure, and will not be described again here.

Step 404: Determine the status information to be returned according to the identification of the target button.

There may be multiple identifications of the target button. The identification of different target buttons and the determined status information to be returned may be the same or may be different, etc. This disclosure does not limit this.

It can be understood that, after the system to be tested controls the target button corresponding to the identification of the target button based on the target control mode, the corresponding status information will be obtained.

Optionally, in response to the target button being identified as the return button, status information is generated based on the currently displayed application, page and focus location information in the system.

For example, if the target button is identified as: Back button, and the "Back" button is triggered on Page 1 in Application 1, it can indicate that a return operation has been performed, possibly returning to the previous Page 2 in Application 1. If the current focus is on the input box in page 2, then based on the currently displayed: application 1, page 2 and the input box in page 2, the generated status information can be: the input box currently in page 2 of application 1 location.

Or, when the target button is identified as: return button, such as the back button, if the "return button" is triggered in application 1, then it is possible to exit from application 1, and the corresponding application may also have changed. . If the currently displayed application is: Application 2, the page is the home page of Application 2, and the focus is at the "Select" control on the home page of Application 2, then the generated status information can be: the home page of Application 2, the focus is at The "Featured" control on the homepage.

It should be noted that the above examples are only schematic illustrations and cannot be used as limitations on the manner of generating status information in the embodiments of the present disclosure.

Optionally, in response to the target button being identified as a volume button, status information is generated based on the current volume of the system.

For example, when the target button is identified as a volume button, if the current volume of the system is: 15, then the generated status information can be: the current volume is 15. Alternatively, if the current volume of the system is 0, the generated status information may be: it is currently in a mute state, etc. This disclosure does not limit this.

Optionally, in response to the identification of the target key being a startup key associated with any application, status information is generated according to the application currently displayed in the system.

Among them, any application can be a video application, a game application, a browser application, an office application, a fitness application, etc., and this disclosure does not limit this.

For example, if the identification of the target button is the start button associated with "XX Video", and if the application currently displayed in the system is: XX Video, then the generated status information can be: XX Video is on; or XX Video is on. . Or, if the identification of the target button is the start button associated with "YY Browser", and if the application currently displayed in the system is: AA game, then the generated status information can be: AA game is in the open state.

It should be noted that the above examples are only schematic illustrations and cannot be used as limitations on any application, status information, etc. in the embodiments of the present disclosure.

Optionally, in response to the identification of the target key as the main interface key, status information is generated according to the interface currently displayed in the system.

For example, when the target button is identified as a main interface button, if the interface currently displayed in the system is: main interface, then the generated status information can be: main interface. Or, in the case where the target button is identified as the main interface button, if the interface currently displayed in the system is: XX browser, then the generated status information can be: XX browser, etc. This disclosure does not limit this.

Step 405: Send the status information obtained by the listening process to the test system through the RPC module.

It should be noted that, for the specific content and implementation manner of step 405, reference can be made to the descriptions of other embodiments of the present disclosure, and will not be described again here.

In this disclosed embodiment, the system to be tested can first receive the key command sent by the test system through the remote procedure call RPC module, and then can start the monitoring process, and then can control the target key corresponding to the identification of the target key based on the target control mode, and According to the identification of the target button, the status information to be returned is determined, and then the status information obtained by the listening process is sent to the test system through the RPC module. Therefore, the system to be tested can first parse the key commands received through the RPC module, and then start the listening process, and control the target keys based on the target control mode. After that, the status information to be returned can be determined, and the listening process can be The obtained status information is sent to the test system, so that the test system can determine the test results of the target button only based on the status information returned by the system to be tested. This eliminates the need for the test system to query multiple times to determine the test results, simplifying the button test process. , saves time and improves the efficiency of key testing.

An embodiment of the present disclosure also provides a cross-system key testing device. Figure 5 is a schematic structural diagram of a cross-system key testing device according to an embodiment of the present disclosure.

As shown in FIG. 5 , the cross-system key testing device 500 is configured on the test system side and includes: a sending module 510 , a receiving module 520 and a determining module 530 .

Among them, the sending module 510 is used to send key instructions to the system to be tested through the remote procedure call RPC module, where the key instructions include the identification of the target key and the target control mode.

The receiving module 520 is configured to receive the status information returned by the system to be tested through the RPC module.

The determination module 530 is configured to determine the test result corresponding to the target button identifier according to the status information and the target button identifier.

Optionally, the determination module 530 includes:

a determining unit configured to determine the type of the first application switched to the background of the system to be tested in response to the status information indicating that the application switching is successful;

An adjustment unit, configured to adjust the connection state between the first application and the test system according to the type of the first application.

Optional, the adjustment unit is specifically used for:

When the first application is a resident application, maintain the connection with the first application;

When the first application is a non-resident application, disconnect the connection with the first application and release the status information corresponding to the first application.

Optional, also includes:

An update module, configured to update the stored status information corresponding to the second application in response to the status information indicating a focus change or page change in the second application.

Optional, also includes:

An analysis module is used to analyze the obtained test cases to determine the identification of the target button and the target control mode.

Optional, the determination module is specifically used for:

In response to the identification of the target button as the return button, determine the test result corresponding to the return button based on the currently displayed application, page and/or focus location information in the system to be tested in the status information; or,

In response to the identification of the target button as a volume button, determine the test result corresponding to the volume button according to the current volume of the system to be tested in the status information; or,

In response to the identification of the target button as a startup button associated with any application, determine the test result corresponding to the startup button associated with any application according to the application currently displayed in the system to be tested in the status information; or ,

In response to the identification of the target button as a main interface button, the test result corresponding to the main interface button is determined according to the interface currently displayed in the system to be tested in the status information.

For the functions and specific implementation principles of the above-mentioned modules in the embodiments of the present disclosure, reference may be made to the above-mentioned method embodiments and will not be described again here.

In the cross-system key testing device of the embodiment of the present disclosure, the test system can send key instructions to the system to be tested through the remote procedure call RPC module. The key instructions include the identification of the target key and the target control mode, and can then be received through the RPC module. The status information returned by the system to be tested is determined, and the test result corresponding to the target button ID is determined based on the status information and the target button ID. As a result, the test system can send key commands to the system under test through the RPC module, and receive the status information returned by the system under test. Then, the corresponding test results can be determined based on the status information and the identification of the target button, thus avoiding multiple attempts. Query to determine the test results of the target button, which simplifies the button test process, saves time, and improves the efficiency of the button test.

FIG. 6 is a schematic structural diagram of a cross-system key testing device according to an embodiment of the present disclosure.

As shown in FIG. 6 , the cross-system key testing device 600 is configured on the side of the system to be tested, and includes: a receiving module 610 , a starting module 620 , a control module 630 and a sending module 640 .

Among them, the receiving module 610 is used to receive the key instructions sent by the test system through the remote procedure call RPC module, where the key instructions include the identification of the target key and the target control mode.

Start module 620, used to start the listening process.

The control module 630 is configured to control the target button corresponding to the identification of the target button based on the target control mode.

The sending module 640 is configured to send the status information obtained by the listening process to the test system through the RPC module.

Optional, also includes:

A determining module, configured to determine the status information to be returned according to the identification of the target button.

Optional, the determination module is specifically used for:

In response to the identification of the target button as the return button, the status information is generated based on the currently displayed application, page and focus location information in the system; or,

In response to the target button being identified as a volume button, generating the status information according to the current volume of the system; or,

In response to the identification of the target button as a startup button associated with any application, generate the status information according to the application currently displayed in the system; or,

In response to the identification of the target button as a main interface button, the status information is generated according to the interface currently displayed in the system. For the functions and specific implementation principles of the above-mentioned modules in the embodiments of the present disclosure, reference may be made to the above-mentioned method embodiments and will not be described again here.

In the cross-system key testing device according to the embodiment of the present disclosure, the system to be tested can first receive the key instructions sent by the test system through the remote procedure call RPC module. The key instructions include the identification of the target key and the target control mode, and then the monitoring can be started. The process can then control the target button corresponding to the target button's logo based on the target control mode, and then send the status information obtained by the listening process to the test system through the RPC module. Therefore, after parsing the received key command, the system to be tested can start the listening process and control the target key based on the target control mode. Afterwards, the status information obtained by the listening process can be sent to the test system, so that the test system The test result of the target button can be determined based only on the status information returned by the system to be tested. This eliminates the need for the test system to query multiple times to determine the test result, simplifying the button test process, saving time, and improving the efficiency of button test.

FIG. 7 is a structural block diagram of an electronic device according to an embodiment of the present disclosure.

As shown in FIG. 7 , the electronic device 200 includes: a memory 210 and a processor 220 , and a bus 230 connecting different components (including the memory 210 and the processor 220 ).

The memory 210 is used to store executable instructions of the processor 220; the processor 201 is configured to call and execute the executable instructions stored in the memory 202 to implement the cross-system key testing method proposed in the above embodiments of the present disclosure.

Bus 230 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a graphics accelerated port, a processor, or a local bus using any of a variety of bus structures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect ( PCI) bus.

Electronic device 200 typically includes a variety of electronic device-readable media. These media can be any available media that can be accessed by electronic device 200, including volatile and nonvolatile media, removable and non-removable media.

Memory 210 may also include computer system readable media in the form of volatile memory, such as random access memory (RAM) 240 and/or cache memory 250 . Electronic device 200 may further include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, storage system 260 may be used to read and write to non-removable, non-volatile magnetic media (not shown in Figure 7 and commonly referred to as a "hard drive"). Although not shown in FIG. 7, a disk drive for reading and writing removable non-volatile disks (e.g., "floppy disks"), and removable non-volatile optical disks (e.g., CD-ROM, DVD-ROM) may be provided. or other optical media) that can read and write optical disc drives. In these cases, each drive may be connected to bus 230 through one or more data media interfaces. The memory 210 may include at least one program product having a set (eg, at least one) of program modules configured to perform the functions of embodiments of the present disclosure.

A program/utility 280 having a set of (at least one) program modules 270, which may be stored, for example, in the memory 210, such program modules 270 including, but not limited to, an operating system, one or more application programs, other programs Modules, as well as program data, each of these examples or some combination may include an implementation of a network environment. Program modules 270 generally perform functions and/or methods in the embodiments described in this disclosure.

Electronic device 200 may also communicate with one or more external devices 290 (e.g., keyboard, pointing device, display 291, etc.), may also communicate with one or more devices that enable a user to interact with electronic device 200, and/or with Any device (eg, network card, modem, etc.) that enables the electronic device 200 to communicate with one or more other computing devices. This communication may occur through input/output (I/O) interface 292. Furthermore, the electronic device 200 may also communicate with one or more networks (eg, a local area network (LAN), a wide area network (WAN), and/or a public network, such as the Internet) through the network adapter 293. As shown, network adapter 293 communicates with other modules of electronic device 200 via bus 230. It should be understood that, although not shown in the figures, other hardware and/or software modules may be used in conjunction with electronic device 200, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives And data backup storage system, etc.

The processor 220 executes various functional applications and data processing by running programs stored in the memory 210 .

It should be noted that, for the implementation process of the electronic device according to the embodiment of the present disclosure, please refer to the foregoing explanation of the cross-system key testing method according to the embodiment of the present disclosure, and will not be described again here.

For the electronic device according to the embodiment of the present disclosure, the test system can send key instructions to the system to be tested through remote procedure call RPC module, where the key instructions include the identification of the target key and the target control mode, and can then receive the key instructions to be tested through the RPC module. The system returns the status information and determines the test results corresponding to the target button ID based on the status information and the target button ID. As a result, the test system can send key commands to the system under test through the RPC module, and receive the status information returned by the system under test. Then, the corresponding test results can be determined based on the status information and the identification of the target button, thus avoiding multiple attempts. Query to determine the test results of the target button, which simplifies the button test process, saves time, and improves the efficiency of the button test.

In order to implement the above embodiments, embodiments of the present disclosure also propose a non-transitory computer-readable storage medium. When the instructions in the storage medium are executed by the processor of the electronic device, the electronic device can perform the cross-processing as mentioned above. System key testing method.

In order to implement the above embodiments, embodiments of the present disclosure also provide a computer program product. When the computer program is executed by a processor of an electronic device, the electronic device can perform the cross-system key testing method as described above.

Other embodiments of the disclosure will be readily apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. The present disclosure is intended to cover any variations, uses, or adaptations of the disclosure that follow the general principles of the disclosure and include common common sense or customary technical means in the technical field that are not disclosed in the disclosure. . It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It is to be understood that the present disclosure is not limited to the precise structures described above and illustrated in the accompanying drawings, and various modifications and changes may be made without departing from the scope thereof. The scope of the disclosure is limited only by the appended claims.

The above are only specific embodiments of the present disclosure, but the protection scope of the present disclosure is not limited thereto. Any person familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present disclosure. should be covered by the protection scope of this disclosure. Therefore, the protection scope of the present disclosure should be subject to the protection scope of the claims.

Claims (20)

A cross-system key testing method, characterized in that it is executed by a testing system, and the method includes: Send key press instructions to the system under test through remote procedure call RPC module, where the key press instructions include the identification of the target key and the target control mode; Receive status information returned by the system under test through the RPC module; According to the status information and the identification of the target key, the test result corresponding to the identification of the target key is determined. The method according to claim 1, characterized in that, after receiving the status information returned by the system to be tested through the RPC module, it further includes: In response to the status information indicating that the application switch is successful, determine the type of the first application switched to the background of the system to be tested; Adjust the connection state between the first application and the test system according to the type of the first application. The method of claim 2, wherein adjusting the connection state between the first application and the test system according to the type of the first application includes: When the first application is a resident application, maintain the connection with the first application; When the first application is a non-resident application, disconnect the connection with the first application and release the status information corresponding to the first application. The method according to claim 1, characterized in that, after receiving the status information returned by the system to be tested through the RPC module, it further includes: In response to the status information indicating a focus change or a page change in the second application, the stored status information corresponding to the second application is updated. The method according to any one of claims 1 to 4, characterized in that, before sending the key command to the system to be tested through the remote procedure call RPC module, it also includes: The obtained test cases are parsed to determine the identification of the target button and the target control mode. The method according to any one of claims 1 to 4, wherein determining the test result corresponding to the target key identification based on the status information and the identification of the target key includes: In response to the identification of the target button as the return button, determine the test result corresponding to the return button based on the currently displayed application, page and/or focus location information in the system to be tested in the status information; or, In response to the identification of the target button as a volume button, determine the test result corresponding to the volume button according to the current volume of the system to be tested in the status information; or, In response to the identification of the target button as a startup button associated with any application, determine the test result corresponding to the startup button associated with any application according to the application currently displayed in the system to be tested in the status information; or , In response to the identification of the target button as a main interface button, the test result corresponding to the main interface button is determined according to the interface currently displayed in the system to be tested in the status information. A cross-system key testing method, characterized in that it is executed by the system to be tested, and the method includes: Receive the key instructions sent by the test system through the remote procedure call RPC module, where the key instructions include the identification of the target key and the target control mode; Start the listening process; Based on the target control mode, control the target button corresponding to the identification of the target button; Through the RPC module, the status information obtained by the listening process is sent to the test system. The method according to claim 7, characterized in that, before sending the status information obtained by the listening process to the test system, it further includes: The status information to be returned is determined according to the identification of the target button. The method of claim 8, wherein determining the status information to be returned according to the identification of the target button includes: In response to the identification of the target button as the return button, the status information is generated based on the currently displayed application, page and focus location information in the system; or, In response to the target button being identified as a volume button, generating the status information according to the current volume of the system; or, In response to the identification of the target button as a startup button associated with any application, generate the status information according to the application currently displayed in the system; or, In response to the identification of the target button as a main interface button, the status information is generated according to the interface currently displayed in the system. A cross-system key testing device, characterized in that it is configured on the test system side, and the device includes: A sending module, configured to send key instructions to the system to be tested through remote procedure call RPC modules, where the key instructions include the identification of the target key and the target control mode; A receiving module, configured to receive status information returned by the system under test through the RPC module; A determining module, configured to determine a test result corresponding to the target button identification based on the status information and the target button identification. The device according to claim 10, characterized in that the determining module includes: a determining unit configured to determine the type of the first application switched to the background of the system to be tested in response to the status information indicating that the application switching is successful; An adjustment unit, configured to adjust the connection state between the first application and the test system according to the type of the first application. The device according to claim 11, characterized in that the adjustment unit is specifically used for: When the first application is a resident application, maintain the connection with the first application; When the first application is a non-resident application, disconnect the connection with the first application and release the status information corresponding to the first application. The device of claim 10, further comprising: An update module, configured to update the stored status information corresponding to the second application in response to the status information indicating a focus change or page change in the second application. The device according to any one of claims 10 to 13, further comprising: An analysis module is used to analyze the obtained test cases to determine the identification of the target button and the target control mode. The device according to any one of claims 10 to 13, characterized in that the determining module is specifically used to: In response to the identification of the target button as the return button, determine the test result corresponding to the return button based on the currently displayed application, page and/or focus location information in the system to be tested in the status information; or, In response to the identification of the target button as a volume button, determine the test result corresponding to the volume button according to the current volume of the system to be tested in the status information; or, In response to the identification of the target button as a startup button associated with any application, determine the test result corresponding to the startup button associated with any application according to the application currently displayed in the system to be tested in the status information; or , In response to the identification of the target button as a main interface button, the test result corresponding to the main interface button is determined according to the interface currently displayed in the system to be tested in the status information. A cross-system key testing device, characterized in that it is configured on the side of the system to be tested, and the device includes: The receiving module is used to receive the key instructions sent by the test system through the remote procedure call RPC module, wherein the key instructions include the identification of the target key and the target control mode; Start module, used to start the listening process; A control module, configured to control the target button corresponding to the identification of the target button based on the target control mode; A sending module, configured to send the status information obtained by the listening process to the test system through the RPC module. The device of claim 16, further comprising: A determining module, configured to determine the status information to be returned according to the identification of the target button. The device according to claim 17, characterized in that the determining module is specifically used to: In response to the identification of the target button as the return button, the status information is generated based on the currently displayed application, page and focus location information in the system; or, In response to the target button being identified as a volume button, generating the status information according to the current volume of the system; or, In response to the identification of the target button as a startup button associated with any application, generate the status information according to the application currently displayed in the system; or, In response to the identification of the target button as a main interface button, the status information is generated according to the interface currently displayed in the system. An electronic device, characterized by including: processor; memory for storing executable instructions for the processor; Wherein, the processor is configured to call and execute executable instructions stored in the memory to implement the cross-system key testing method as described in any one of claims 1-6, or to implement the method as claimed in claim 7- The cross-system key testing method described in any one of 9. A non-transitory computer-readable storage medium that, when instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to perform the cross-system keystrokes as described in any one of claims 1-6 test method, or perform the cross-system key testing method as described in any one of claims 7-9.

Images