A method, device, equipment and medium for automatically testing a call scene
By calling serial port instruction scripts and call response scripts on the test terminal, triggering and responding to call operations is solved, and the problem of manual operation dependence in the existing technology is solved, fast and efficient emergency call scenario testing is achieved, and labor costs and testing are reduced. cycle.
Patent Information
- Application Number
- CN202210718007.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-06-23
- Publication Date
- 2024-12-13
- Estimated Expiration
- 2042-06-23
AI Technical Summary
The existing emergency call scenario stability testing methods rely on manual operations, resulting in long test cycles and inability to quickly locate problems, increasing labor and time costs, and can only answer and hang up operations on one pair of devices.
By calling the serial port command script on the test terminal, the call button of the secure auxiliary calling device is automatically triggered, and the call duration control script and response script files are used to simulate multiple device scenarios, realize automated testing and reduce manual participation.
It realizes automated testing of call scenarios, improves testing efficiency, reduces labor costs, and can simulate different scenarios on multiple devices, automatically compares test results, and quickly locates problems.
Smart Images
Figure CN115118817B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of testing technology, and in particular to an automatic testing method, device, equipment and medium for a call scene. Background Art
[0002] With the rapid development of intelligent automobile industry, the functions of vehicles are becoming more and more powerful. Safety auxiliary equipment, especially the one-button emergency call function, is particularly important, which can protect our safety in critical emergency moments. Therefore, in the test phase, it is necessary to ensure the stability of the emergency call scene test of the safety auxiliary equipment. The existing emergency call scene stability test method is to manually press the emergency button on the safety auxiliary equipment to trigger the emergency call, and the alarm receiver manually answers, hangs up, delays the answering and other corresponding operations. It is necessary to manually trigger multiple cycles of testing and manually proofread the test results.
[0003] The above test method needs to cover multiple scenarios. The entire process test takes a long test cycle and cannot quickly locate the problem. Manual comparison of a large number of reported results increases manpower and time costs. In addition, a complete answer and hang up operation can only be tested on a pair of devices. Summary of the invention
[0004] The embodiments of the present invention provide a method, device, equipment and medium for automatically testing a call scene, so as to realize automatic testing of the call scene, reduce manual participation and lower costs.
[0005] In a first aspect, this embodiment provides an automatic testing method for a call scenario, which is applied to a test terminal, wherein the test terminal is connected to at least one safety auxiliary call device and also establishes a communication connection with a call receiving terminal, and the method includes:
[0006] After entering the call scene test mode, calling the serial command script containing the call type to be tested, wherein the call type to be tested is pre-set on the test interaction interface;
[0007] Through the serial port command script, each connected safety auxiliary call device is controlled to trigger a call button matching the call type to be tested, so that each safety auxiliary call device sends a call request to the call receiving end;
[0008] Generate a call duration control script and a call response script file respectively according to the preset call setting mode and call response type;
[0009] By means of the call duration control script and the call response script file, the call receiving end is controlled to respond to each of the call requests in sequence to perform a call test;
[0010] The current test result is determined based on the response test information fed back by the call receiving end after responding to each call request, combined with the test log information generated in real time.
[0011] In a second aspect, this embodiment provides an automatic testing device for a call scenario, which is integrated in a test terminal, wherein the test terminal is connected to at least one safety auxiliary call device and also establishes a communication connection with a call receiving end, and the device includes:
[0012] A command script calling module, used to call a serial port command script containing a call type to be tested after entering a call scene test mode, wherein the call type to be tested is pre-set on a test interaction interface;
[0013] A call button control module, used to control each connected safety auxiliary call device to trigger a call button matching the call type to be tested through the serial port command script, so that each of the safety auxiliary call devices sends a call request to the call receiving end;
[0014] A response script generation module, used to generate a call duration control script and a call response script file according to a preset call setting mode and a call response type;
[0015] A call response control module, used to control the call receiving end to respond to each of the call requests in sequence through the call duration control script and the call response script file, so as to perform a call test;
[0016] The test result determination module is used to determine the current test result based on the response test information fed back by the call receiving end after responding to each call request, combined with the test log information generated in real time.
[0017] In a third aspect, this embodiment provides an electronic device, which serves as a test terminal, and the electronic device includes:
[0018] at least one processor; and
[0019] a memory communicatively connected to the at least one processor; wherein,
[0020] The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the automatic testing method for the call scenario described in any embodiment of the present invention.
[0021] In a fourth aspect, this embodiment provides a computer-readable storage medium, and the computer program is executed by the at least one processor to enable the at least one processor to execute the automatic testing method for the call scenario described in any embodiment of the present invention.
[0022] An embodiment of the present invention provides an automatic testing method, device, equipment and medium for a call scene. The method is applied to a test terminal, which is connected to at least one safety auxiliary call device and also establishes a communication connection with a call receiving end. The method includes: after entering a call scene test mode, calling a serial port command script containing a call type to be tested, wherein the call type to be tested is pre-set on a test interaction interface; through the serial port command script, controlling each connected safety auxiliary call device to trigger a call button matching the call type to be tested, so that each of the safety auxiliary call devices sends a call request to the call receiving end; generating a call duration control script and a call response script file according to a pre-set call setting mode and a call response type respectively; through the call duration control script and the call response script file, controlling the call receiving end to respond to each of the call requests in turn to perform a call test; determining the current test result according to the response test information fed back by the call receiving end after responding to each call request, combined with the test log information generated in real time. The above technical solution triggers the call button on the safety auxiliary call device by calling the serial command script containing the call type to be tested, realizes automatic triggering and is free from the constraints of manually pressing the button to trigger the emergency call operation, uses the executable script to control the call receiving end to automatically respond to the call request, and uses the multi-process method to simulate the long-term duplication operation of multiple safety auxiliary call devices in different scenarios. Various scenarios can be added during the operation of the device without affecting the call process. The business scenario operation is encapsulated in an executable script file, and the return results of the call success and failure are automatically compared to automatically determine the current test results, reducing the time of manual comparison. The diversity of scenarios covering the stability test can be automated, which improves the test efficiency and reduces labor costs.
[0023] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present invention, nor are they intended to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS
[0024] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.
[0025] Figure 1 A flowchart of an automatic testing method for a call scenario provided in Embodiment 1 of the present invention;
[0026] Figure 2 A flowchart of an automatic testing method for a call scenario provided in Embodiment 2 of the present invention;
[0027] Figure 3 A schematic diagram of the structure of an automatic testing device for a call scenario provided in Embodiment 3 of the present invention;
[0028] Figure 4 A schematic diagram of the structure of an electronic device provided in Embodiment 4 of the present invention. DETAILED DESCRIPTION
[0029] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.
[0030] It should be noted that the terms "original", "target", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.
[0031] Embodiment 1
[0032] Figure 1 A flow chart of an automatic testing method for a call scenario provided in Embodiment 1 of the present invention is applicable to the situation where a call scenario is automatically tested. The method can be executed by an automatic testing device for a call scenario. The automatic testing device for a call scenario can be implemented in the form of hardware and / or software. The device can be configured in a test terminal, and the test terminal is connected to at least one safety auxiliary call device and also establishes a communication connection with a call receiving end.
[0033] like Figure 1 As shown, the automatic testing method for a call scenario provided in the first embodiment may specifically include the following steps:
[0034] S101. After entering a call scenario test mode, calling a serial port command script containing a call type to be tested, wherein the call type to be tested is pre-set on a test interaction interface.
[0035] In this embodiment, the execution subject can be understood as a test terminal, and the safety assistance calling device is physically connected to the test terminal. Exemplarily, the safety assistance calling device is physically connected to the test terminal via a standard RS-232-C serial port line.
[0036] It is understandable that from the user's perspective, before conducting a call scenario test, the test terminal provides the user with a test interaction interface, in which the user can set relevant test information. For example, the user can select the call type, call setting mode, and call response type. Among them, the call types include: emergency call, business consultation, and event understanding.
[0037] In this step, the test terminal encapsulates serial command scripts of various call types, and different serial command scripts correspond to different call types. The operations triggered by each type of call button are encapsulated into serial command scripts. For example, the keyword corresponding to the emergency call can be named "emergency call", which is simple to use and easy to read.
[0038] Specifically, when the user triggers the call scene test on the test interaction interface, the call scene test mode is entered, and the serial port command script containing the call type to be tested is called according to the call type to be tested set by the user on the test interaction interface.
[0039] S102. Control each connected safety auxiliary calling device to trigger a call button matching the call type to be tested through a serial port command script, so that each safety auxiliary calling device sends a call request to the call receiving end.
[0040] In this embodiment, before triggering a call, a corresponding control process needs to be created based on the safety assistance call device. Specifically, the number of connections of the safety assistance call device that establishes a physical connection can be determined, and the same number of control processes as the number of connections can be created. After detecting that the local port is available, each control process is started using a pre-created device simulator.
[0041] After starting each control process, the test terminal starts the corresponding safety auxiliary call device through the assigned local port based on each control process, so that each safety auxiliary call device triggers the call button matching the call type to be tested by running the serial port command script, thereby causing the safety call device to send a call request to the call receiving end. It should be noted that the test terminal is in communication connection with the call receiving end.
[0042] S103: Generate a call duration control script and a call response script file respectively according to a preset call setting mode and a call response type.
[0043] It is clear that from the user's perspective, before conducting a call scenario test, the test terminal provides the user with a test interaction interface, in which the user can set the test information. The user sets the call setting mode and call response type in the test interaction interface. The call setting mode can be understood as a mode of the call time interval, including a fixed call time mode and a random call time mode. The call response type can be understood as the type of response of the call receiving end after receiving the call, including immediate answer, delayed answer, and hang up.
[0044] Specifically, obtain the call setting mode and call response type pre-selected on the test interaction interface; generate a corresponding control script according to the call setting mode; extract the scene instruction keyword from the call response type, and generate a call response script file according to the scene instruction keyword.
[0045] Exemplarily, assuming that the pre-set call setting mode is a fixed call time mode and the call response type is answer immediately, after the test terminal obtains the call setting mode and the call response type, it generates a fixed call time mode script as a call duration control script, and at the same time generates a call response script file according to the immediate answer scenario instruction keywords.
[0046] S104. Control the call receiving end to respond to each call request in sequence through the call duration control script and the call response script file to perform a call test.
[0047] In this step, the call receiving end is controlled to sort the call requests according to the receiving time, and then the current call request to be responded to is selected in turn; the call receiving end is controlled to respond to the current call request through the call response type contained in the call response script file; after the call is connected, the call receiving end is controlled to hang up after the call duration is reached through the call duration contained in the call duration control script.
[0048] For example, assuming that the preset call setting mode is a fixed call time mode, the fixed time is 2 minutes, and the call response type is immediate answer, the control call receiving end sorts the call requests according to the receiving time, selects the current call request to be responded to in turn, hangs up after 2 minutes of the call, connects the next call, and controls the call receiving end to answer the call request immediately upon receiving it.
[0049] S105: Determine the current test result based on the response test information fed back by the call receiving end after responding to each call request and the test log information generated in real time.
[0050] The response test information is generated by the call receiving end according to the response log information generated when responding to each call request. The response log information records whether the current test response is successful or failed.
[0051] Specifically, the response test information fed back by the call receiving end is received. If the information recorded in the response test information indicates that the current test response is correct, the test success is used as the current test result; otherwise, the current test result is determined based on the test log information generated in real time. Further, the test log information generated in real time after entering the call scene test mode is obtained, and it is determined whether the information recorded in the test log information indicates that the current test response is correct; if so, the test success is used as the current test result; if not, the test failure is used as the current test result.
[0052] An embodiment of the present invention provides an automatic testing method for a call scenario, which is applied to a test terminal, wherein the test terminal is connected to at least one safety auxiliary call device and also establishes a communication connection with a call receiving end. The method includes: after entering a call scenario test mode, calling a serial port command script containing a call type to be tested, wherein the call type to be tested is pre-set on a test interaction interface; through the serial port command script, controlling each connected safety auxiliary call device to trigger a call button matching the call type to be tested, so that each safety auxiliary call device sends a call request to the call receiving end; generating a call duration control script and a call response script file according to a pre-set call setting mode and a call response type, respectively; through the call duration control script and the call response script file, controlling the call receiving end to respond to each call request in turn to perform a call test; determining the current test result according to the response test information fed back by the call receiving end after responding to each call request, combined with the test log information generated in real time. The above technical solution triggers the call button on the safety auxiliary call device by calling the serial command script containing the call type to be tested, realizes automatic triggering and is free from the constraints of manually pressing the button to trigger the emergency call operation, uses the executable script to control the call receiving end to automatically respond to the call request, and uses the multi-process method to simulate the long-term duplication operation of multiple safety auxiliary call devices in different scenarios. Various scenarios can be added during the operation of the device without affecting the call process. The business scenario operation is encapsulated in an executable script file, and the return results of the call success and failure are automatically compared to automatically determine the current test results, reducing the time of manual comparison. The diversity of scenarios covering the stability test can be automated, which improves the test efficiency and reduces labor costs.
[0053] Embodiment 2
[0054] Figure 2A flow chart of an automatic testing method for a call scenario provided in Embodiment 2 of the present invention. This embodiment is a further optimization of the above embodiment. In this embodiment, "through the serial port command script, controlling each connected safety auxiliary call device to trigger a call button matching the call type to be tested" is further limited and optimized, and "according to a pre-set call setting mode and a call response type, respectively generating a call duration control script and a call response script file" is limited and optimized, and "through the call duration control script and the call response script file, controlling the call receiving end to respond to each of the call requests in sequence" is limited and optimized, and "according to the response test information fed back by the call receiving end after responding to each call request, combined with the test log information generated in real time, determining the current test result" is limited and optimized.
[0055] like Figure 2 As shown, this embodiment 2 provides an automatic testing method for a call scene, which specifically includes the following steps:
[0056] S201. After entering the call scenario test mode, call a serial port command script containing the call type to be tested.
[0057] The call type to be tested is pre-set on the test interaction interface.
[0058] S202: Determine the number of connections of the security auxiliary call device that establishes physical connection, and create the same number of control processes as the number of connections.
[0059] It is known that the safety assistance call device to be tested needs to be physically connected to the test terminal. Specifically, according to the actual number of devices to be tested, that is, the number of connections of the safety assistance call devices that establish a physical connection with the test terminal, the process pool is used to create the same number of control processes by reading the current number of connections.
[0060] S203: After detecting that the local port is available, start each control process using a pre-created device simulator.
[0061] Specifically, it is detected whether the local port is available, and if available, each control process is started using a pre-created device simulator.
[0062] S204: start the corresponding safety assistance calling device through the allocated local port based on each control process, so that each safety assistance calling device triggers a call button matching the call type to be tested by running the serial port command script.
[0063] Specifically, each control process starts the corresponding safety assistance call device through the assigned local port, so that each safety assistance call device triggers the call button matching the call type to be tested by running the serial port command script, thereby achieving the purpose of simulating the concurrent execution of multiple safety assistance call devices.
[0064] S205: Acquire the call setting mode and call response type pre-selected on the test interaction interface.
[0065] The call setting mode includes a fixed call time mode and a random call time mode, and the call response type includes immediate answer, delayed answer, and hang up. Before the call scene test, the call setting mode and call response type are pre-selected on the test interaction interface. Specifically, the pre-selected call setting mode and call response type are obtained.
[0066] S206, determining whether the call setting mode is a fixed call time mode, if yes, executing step S207; otherwise, executing step S208.
[0067] S207: If the call setting mode is the fixed call time mode, the fixed call time mode script is used as the call duration control script.
[0068] S208. If the call setting mode is the random call time mode, the random call time mode script is used as the call duration control script.
[0069] The execution program interface processor of the test terminal encapsulates a fixed talk time mode script corresponding to the fixed talk time mode and a random talk time mode script corresponding to the random talk time mode.
[0070] Specifically, it is determined whether the acquired call setting mode is a fixed call time mode or a random call time mode. If the call setting mode is a fixed call time mode, the fixed call time mode script is used as the call duration control script; otherwise, the random call time mode script is used as the call duration control script.
[0071] S209: extracting scenario instruction keywords from the call response type, and generating a call response script file according to the scenario instruction keywords.
[0072] The scenario instruction keywords are keywords pre-encapsulated by scripts to implement various operation steps and are combined to construct simulation scenarios. Specifically, according to the pre-set scenario combination, the scenario instruction keywords are extracted from the call response type, and a call response script file is generated according to the scenario instruction keywords.
[0073] S210: Control the call receiving end to sort the call requests according to the receiving time, and select the current call requests to be responded to in sequence.
[0074] It is understandable that the call request received by the receiving end may be sent by a safety assistance call device, or there may be a situation where two or more devices send call requests. At this time, the control call receiving end sorts the call requests according to the receiving time, and selects the current call requests to be responded to in turn.
[0075] S211. Control the call receiving end to respond to the current call request through the call response type included in the call response script file.
[0076] The call response type includes immediate answer, delayed answer and hang up. According to the call response type included in the call response script file, the call receiving end is controlled to respond to the current call request. Exemplarily, if the call response type included in the call response script is delayed answer, the call receiving end is controlled to delay answering the current call.
[0077] S212: After the call is connected, the call receiving end is controlled to hang up after the call duration is reached by using the call duration included in the call duration control script.
[0078] Specifically, the call duration control script includes the call duration. After the call is connected, the call receiving end is controlled to hang up after the call duration. For example, if the call duration included in the call duration control script is 60 seconds, the call receiving end is controlled to hang up after the call duration is 60 seconds.
[0079] S213: Receive response test information fed back by the call receiving end.
[0080] The response test information is generated by the call receiving end according to the response log information generated when responding to each call call request. From the perspective of the call receiving end, the call receiving end responds to the call call request, and the response result may be that the current test response is correct or the current test response is wrong.
[0081] From the perspective of the test terminal, receive the response test information fed back by the call receiving end.
[0082] S214. Determine whether the information recorded in the response test information indicates that the current test response is correct. If so, execute step S215; if not, execute step S216.
[0083] Specifically, it is determined whether the information recorded in the corresponding test information indicates that the current test response is correct, so as to perform test result statistics.
[0084] S215. If the information recorded in the response test information indicates that the current test response is correct, the test success is taken as the current test result.
[0085] Specifically, if the information recorded in the response test information indicates that the current test response is correct, the test success is taken as the current test result.
[0086] S216. If the information recorded in the response test information indicates that the current test response is wrong, obtain the test log information generated in real time after entering the call scenario test mode, and determine whether the information recorded in the test log information indicates that the current test response is correct. If so, execute step S215; otherwise, execute step S217.
[0087] Specifically, if the information recorded in the response test information indicates that the current test response is wrong, it is necessary to further determine whether the information recorded in the test log information indicates that the current test response is correct based on the test log information generated in real time after entering the call scene test mode.
[0088] S217: If the information recorded in the test log information indicates that the current test response is wrong, the test failure is taken as the current test result.
[0089] The technical solution of this embodiment provides a method of remotely controlling the button trigger of the safety auxiliary call device through command encapsulation keywords, automatically triggering the emergency call operation without the constraints of manually pressing the button, using executable scripts to control the alarm machine to automatically answer the call immediately or delay the call, hang up and other operations, using a multi-process method to simulate multiple devices in different scenarios for long-term copying operation, and can add various scenarios to the device operation process at will without affecting the call process, encapsulating the business scenario operation in an executable script file, and automatically comparing the results through the return results of the call success and failure, and automatically uploading the report to reduce the time of manual comparison. Compared with the manual testing scheme in the prior art, this technical scheme realizes the automation of call scene testing, improves the testing efficiency, and reduces the labor cost. In addition, it can realize the automation of scene diversity that meets the coverage stability test. Through the various scenarios set in the safety auxiliary equipment emergency call scene stability automation system, the receiving end performs response analysis, automatically cycles multiple scene tests, calculates the success rate, identifies error logs, and mines potential problems, so as to reduce the accident rate and improve the safety of safety auxiliary equipment.
[0090] Continue to refer Figure 2 , the method further comprises:
[0091] S218. Count the current test results and accumulate the number of tests.
[0092] S219, determine whether the cumulative number of tests is less than the set total number of tests. If so, return to step S201 to re-execute the calling operation of the serial port command script to continue the call test; otherwise, execute step S220.
[0093] S220: Generate a test report based on the statistical current test results.
[0094] In this embodiment, statistics are collected for each test result, including test success and test failure, and the number of tests is accumulated. If the cumulative number of tests does not reach the set total number of tests, the test continues and the calling operation of the serial port command script is re-executed; if the cumulative number of tests reaches the set total number of tests, a test report is generated based on the statistical current test results, and the test ends. The test report can be fed back to the interface of the test terminal, or fed back to the user end through other means, such as email.
[0095] Furthermore, the step of generating a test report based on the statistics of each current test result can be expressed as: counting the successful test results including successful tests in each current test result, and obtaining the successful number of successful test results; determining the ratio of the number of successes to the total number of tests, and using the ratio as the test success rate of the call scenario test; generating a test report including each current test result and the test success rate.
[0096] This optional embodiment automatically compares the results of successful and failed calls, automatically generates and uploads test reports, and reduces the time for manual comparison. In addition, it can automatically cycle multiple scenario tests, calculate success rates, identify error logs, and mine potential problems, thereby reducing the rate of accidents and improving the safety of safety auxiliary equipment.
[0097] Embodiment 3
[0098] Figure 3 The schematic diagram of the structure of an automatic test device for a call scene provided in the third embodiment of the present invention is applicable to the case of automatically testing a call scene. The device can be implemented in the form of hardware and / or software and is generally integrated in a test terminal. The test terminal is connected to at least one safety auxiliary call device and also establishes a communication connection with a call receiving end. Figure 3 As shown, the device includes: an instruction script calling module 31, a call button control module 32, a response script generating module 33, a call response control module 34 and a test result determining module 35, wherein:
[0099] The command script calling module 31 is used to call the serial command script containing the call type to be tested after entering the call scene test mode, wherein the call type to be tested is pre-set on the test interaction interface;
[0100] The call button control module 32 is used to control each connected safety auxiliary call device to trigger a call button matching the call type to be tested through a serial port command script, so that each safety auxiliary call device sends a call request to the call receiving end;
[0101] A response script generation module 33, used to generate a call duration control script and a call response script file according to a preset call setting mode and a call response type;
[0102] A call response control module 34 is used to control the call receiving end to respond to each call request in sequence through the call duration control script and the call response script file to perform a call test;
[0103] The test result determination module 35 is used to determine the current test result based on the response test information fed back by the call receiving end after responding to each call request, combined with the test log information generated in real time.
[0104] Optionally, the device further comprises:
[0105] The times statistics module is used to count the current test results and accumulate the number of tests;
[0106] The report generation module is used to return to re-execute the calling operation of the serial port command script to continue the call test when the cumulative number of tests is less than the set total number of tests; otherwise, a test report is generated based on the statistical current test results.
[0107] Optional report generation module, specifically for:
[0108] Count the successful test results including the successful test results in each current test result, and obtain the successful number of successful test results;
[0109] Determine the ratio of the number of successes to the total number of tests, and use the ratio as the test success rate of the call scenario test;
[0110] Generate a test report containing the current test results and test success rate.
[0111] Optionally, the call button control module 32 is specifically used for:
[0112] Determine the number of connections of the safety auxiliary calling device that establishes the physical connection, and create the same number of control processes as the number of connections;
[0113] After detecting that the local port is available, each control process is started using a pre-created device simulator;
[0114] Based on each control process, the corresponding safety auxiliary call device is started through the allocated local port, so that each safety auxiliary call device triggers a call button matching the call type to be tested by running the serial port command script.
[0115] Optionally, the response script generation module 33 is specifically used for:
[0116] Obtain the call setting mode and call response type pre-selected on the test interaction interface;
[0117] If the call setting mode is the fixed call time mode, the fixed call time mode script is used as the call duration control script; otherwise, the random call time mode script is used as the call duration control script;
[0118] Extract scenario instruction keywords from the call response type, and generate a call response script file according to the scenario instruction keywords.
[0119] Optionally, the call response control module 34 is specifically configured to:
[0120] Controlling the call receiving end to sort the call requests according to the receiving time, and selecting the current call requests to be responded to in turn;
[0121] Control the call receiving end to respond to the current call request through the call response type contained in the call response script file;
[0122] After the call is connected, the call duration contained in the call duration control script is used to control the call receiving end to hang up after the call duration.
[0123] Optionally, the test result determination module 35 is specifically used to:
[0124] Receiving response test information fed back by the call receiving end, the response test information is generated by the call receiving end according to response log information generated when responding to each call request;
[0125] If the information recorded in the response test information indicates that the current test response is correct, the test success is taken as the current test result; otherwise,
[0126] Obtaining the test log information generated in real time after entering the call scenario test mode, and determining whether the information recorded in the test log information indicates that the current test response is correct;
[0127] If yes, the test success is taken as the current test result;
[0128] If not, the test failure is taken as the current test result.
[0129] The automatic testing device for call and conversation scenarios provided in the embodiments of the present invention can execute the automatic testing method for call and conversation scenarios provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.
[0130] Embodiment 4
[0131] Figure 4 A schematic diagram of the structure of an electronic device provided for Embodiment 4 of the present invention. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or required herein.
[0132] like Figure 4 As shown, the electronic device 40 includes at least one processor 41, and a memory connected to the at least one processor 41, such as a read-only memory (ROM) 42, a random access memory (RAM) 43, etc., wherein the memory stores a computer program that can be executed by at least one processor, and the processor 41 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 42 or the computer program loaded from the storage unit 48 to the random access memory (RAM) 43. In the RAM 43, various programs and data required for the operation of the electronic device 40 can also be stored. The processor 41, the ROM 42, and the RAM 43 are connected to each other through a bus 44. An input / output (I / O) interface 45 is also connected to the bus 44.
[0133] A number of components in the electronic device 40 are connected to the I / O interface 45, including: an input unit 46, such as a keyboard, a mouse, etc.; an output unit 47, such as various types of displays, speakers, etc.; a storage unit 48, such as a disk, an optical disk, etc.; and a communication unit 49, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 49 allows the electronic device 40 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.
[0134] The processor 41 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the processor 41 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 41 executes the various methods and processes described above, such as an automatic testing method for a call scene.
[0135] In some embodiments, the automatic testing method for call conversation scenarios can be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as a storage unit 48. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 40 via the ROM 42 and / or the communication unit 49. When the computer program is loaded into the RAM 43 and executed by the processor 41, one or more steps of the automatic testing method for call conversation scenarios described above can be performed. Alternatively, in other embodiments, the processor 41 can be configured to perform the automatic testing method for call conversation scenarios in any other appropriate manner (for example, by means of firmware).
[0136] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.
[0137] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that when the computer program is executed by the processor, the functions / operations specified in the flow chart and / or block diagram are implemented. The computer program may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.
[0138] In the context of the present invention, a computer-readable storage medium may be a tangible medium that may contain or store a computer program for use by or in combination with an instruction execution system, device or equipment. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
[0139] To provide interaction with a user, the systems and techniques described herein may be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form (including acoustic input, voice input, or tactile input).
[0140] The systems and techniques described herein may be implemented in a computing system that includes backend components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes frontend components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.
[0141] A computing system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The client and server relationship is generated by computer programs running on the corresponding computers and having a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system to solve the defects of difficult management and weak business scalability in traditional physical hosts and VPS services.
[0142] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps described in the present invention can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solution of the present invention can be achieved, and this document does not limit this.
[0143] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims
1. An automatic testing method for a call scenario, characterized in that: Applied to a test terminal, the test terminal is connected to at least one safety auxiliary call device and also establishes a communication connection with a call receiving terminal, the method includes: After entering the call scene test mode, calling the serial command script containing the call type to be tested, wherein the call type to be tested is pre-set on the test interaction interface; Through the serial port command script, each connected safety auxiliary call device is controlled to trigger a call button matching the call type to be tested, so that each safety auxiliary call device sends a call request to the call receiving end; Generate a call duration control script and a call response script file respectively according to the preset call setting mode and call response type; By means of the call duration control script and the call response script file, the call receiving end is controlled to respond to each of the call requests in sequence to perform a call test; Determine the current test result according to the response test information fed back by the call receiving end after responding to each call request, combined with the test log information generated in real time; The method of controlling each connected safety auxiliary call device to trigger a call button matching the call type to be tested through the serial port command script includes: Determine the number of connections of the safety auxiliary calling device that establishes the physical connection, and create the same number of control processes as the number of connections; After detecting that the local port is available, using a pre-created device simulator to start each of the control processes; Based on each of the control processes, the corresponding safety auxiliary call device is started through the allocated local port, so that each safety auxiliary call device triggers a call button matching the call type to be tested by running the serial port command script; The method of generating a call duration control script and a call response script file according to a preset call setting mode and a call response type respectively includes: Obtaining a call setting mode and a call response type pre-selected on the test interaction interface; If the call setting mode is a fixed call time mode, the fixed call time mode script is used as the call duration control script; otherwise, the random call time mode script is used as the call duration control script; A scenario instruction keyword is extracted from the call response type, and a call response script file is generated according to the scenario instruction keyword.
2. The method according to claim 1, characterized in that Also includes: Counting the current test results and accumulating the number of tests; When the cumulative number of tests is less than the set total number of tests, the call operation of the serial port command script is returned and re-executed to continue the call test; Otherwise, a test report is generated according to the statistical current test results.
3. The method according to claim 2, characterized in that Generating a test report according to the statistical current test results includes: Counting the successful test results including the successful test in each of the current test results, and obtaining the number of successful test results; Determine a ratio of the number of successes to the total number of tests, and use the ratio as a test success rate of the call scenario test; Generate a test report including the current test results and the test success rate.
4. The method according to claim 1, characterized in that: The step of controlling the call receiving end to respond to each of the call requests in sequence through the call duration control script and the call response script file includes: Controlling the call receiving end to sort the call requests according to the receiving time, and sequentially selecting the current call requests to be responded to; Controlling the call receiving end to respond to the current call request by means of the call response type contained in the call response script file; After the call is connected, the call receiving end is controlled to hang up after the call duration is continued according to the call duration included in the call duration control script.
5. The method according to claim 1, characterized in that The step of determining the current test result based on the response test information fed back by the call receiving end after responding to each call request and the test log information generated in real time includes: Receiving response test information fed back by the call receiving end, wherein the response test information is generated by the call receiving end according to response log information generated when responding to each call request; If the information recorded in the response test information indicates that the current test response is correct, the test success is taken as the current test result; otherwise, Acquire test log information generated in real time after entering the call scene test mode, and determine whether the information recorded in the test log information indicates that the current test response is correct; If yes, the test success is taken as the current test result; If not, the test failure is taken as the current test result.
6. An automatic testing device for a call scene, characterized in that: Integrated in a test terminal, the test terminal is connected to at least one safety auxiliary call device and also establishes a communication connection with a call receiving terminal, the device includes: A command script calling module, used to call a serial port command script containing a call type to be tested after entering a call scene test mode, wherein the call type to be tested is pre-set on a test interaction interface; A call button control module, used to control each connected safety auxiliary call device to trigger a call button matching the call type to be tested through the serial port command script, so that each of the safety auxiliary call devices sends a call request to the call receiving end; A response script generation module, used to generate a call duration control script and a call response script file according to a preset call setting mode and a call response type; A call response control module, used to control the call receiving end to respond to each of the call requests in sequence through the call duration control script and the call response script file, so as to perform a call test; A test result determination module, used to determine the current test result based on the response test information fed back by the call receiving end after responding to each call request, combined with the test log information generated in real time; The call button control module is specifically used for: Determine the number of connections of the safety auxiliary calling device that establishes the physical connection, and create the same number of control processes as the number of connections; After detecting that the local port is available, each control process is started using a pre-created device simulator; based on each control process, the corresponding safety auxiliary call device is started through the allocated local port, so that each safety auxiliary call device triggers a call button matching the call type to be tested by running the serial port command script; Optional, response script generation module, specifically used for: Obtain the call setting mode and call response type pre-selected on the test interaction interface; If the call setting mode is the fixed call time mode, the fixed call time mode script is used as the call duration control script; otherwise, the random call time mode script is used as the call duration control script; Extract scenario instruction keywords from the call response type, and generate a call response script file according to the scenario instruction keywords.
7. An electronic device, characterized in that: As a test terminal, the electronic device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the automatic testing method for the call scenario according to any one of claims 1-5.
8. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the automatic testing method for a call scenario according to any one of claims 1 to 5 when executed.