Visible-to-speak automatic test method and system, electronic equipment and storage medium

Abstract

The invention discloses a visible-to-speak automatic test method and system, electronic equipment and a storage medium, and relates to the field of control testing, and the method comprises the steps: obtaining a test control instruction; starting a control for scanning a page in a screen according to the obtained test control instruction, and screening out a control supporting a visible-to-speak function; according to the screened control supporting the visible-to-speak function, generating an automatic test case corresponding to the control; wherein the step of generating the automatic test case of the corresponding control comprises the steps of simulating a hit process of the control based on a control display state in a preset scene and a control voice hit based on the control display state, and executing a preset operation process of the corresponding control after hit; recording test data based on the control test case, and performing statistics and classification; and based on statistical classification of the test data, generating evaluation information of test efficiency and test accuracy. According to the application, the visible-to-speak page floating window is set, so that the page scanning module crosses the UI interaction module to perform traversal scanning on the page control.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of control testing, in particular to a visible-to-say automation testing method, a visible-to-say automation testing system, a visible-to-say automation testing device, an electronic device, a storage medium and a vehicle. BACKGROUND

[0002] Visible-to-say is a control that a user sees on a screen, which can be directly hit to execute the function of the control above by speaking. The traditional testing method is for a tester to look at the control on the screen, speak according to the control seen, and see if it is hit to execute. This testing method has the disadvantages of low efficiency, long time consumption, etc., and the correctness of the test result may not be accurately judged when the human force is tested.

[0003] Therefore, a visible-to-say automation testing scheme is needed, which is controlled by a tester, starts the test button on the screen, automatically scans all the controls in the entire screen, identifies which controls support the visible-to-say function, improves the testing efficiency, automatically generates test cases, performs simulated hit execution operations, generates test reports and saves the test results, and greatly improves the testing efficiency and testing accuracy. SUMMARY

[0004] The purpose of the present application is to provide a visible-to-say automation testing method, a visible-to-say automation testing system, a visible-to-say automation testing device, an electronic device, a storage medium and a vehicle, which at least solve one of the technical problems of how to display a test window and a tested window on the same page, how to lock a test object, and how to generate a test case.

[0005] The present application provides the following scheme:

[0006] According to one aspect of the present application, a visible-to-say automation testing method is provided, which comprises:

[0007] obtaining a test control instruction;

[0008] According to the obtained test control instruction, starting to scan the controls of a page in the screen, and screening out controls supporting the visible-to-say function;

[0009] According to the screened out controls supporting the visible-to-say function, generating an automation test case corresponding to the controls;

[0010] The generation of the automation test case corresponding to the controls comprises simulating the hit process of the controls and the preset operation process of the corresponding controls after being hit based on the control display state under the preset scene and the control voice hit based on the control display state;

[0011] record test data based on the control test case and statistically classify;

[0012] based on the statistical classification of the test data, generate evaluation information of test efficiency and test accuracy.

[0013] According to two aspects of the present application, a visible-to-say automated testing system is provided, which comprises:

[0014] UI interaction module, page scanning module, test case generation module, page hit module, test result collection module and cloud service module;

[0015] The UI interaction module is used to receive test control instructions and feedback test process data.

[0016] The page scanning module is used to traverse and scan the controls of the page in the current screen, and filter out the controls supporting visible-to-say.

[0017] The test case generation module is used to generate corresponding automated test cases based on the visible-to-say controls filtered out by the page scanning.

[0018] The page hit module is used to check the hit of the corresponding visible-to-say controls of the page according to the automated test cases.

[0019] The test result collection module is used to analyze and arrange the results of the hit check locally, and upload the test results to the cloud service module after the analysis and arrangement are completed.

[0020] The cloud service module is used to store the test results and the test cases for obtaining the test results.

[0021] Further, the UI interaction module comprises:

[0022] Based on the AndroID Debug BrIDge command, the UI interaction module sets a floating window for the visible-to-say page to be tested.

[0023] Based on the UI interaction module, the command for testing the visible-to-say page is obtained.

[0024] According to the command for testing the visible-to-say page, the page scanning module traverses and scans the controls of the page in the current screen, bypassing the display content of the UI interaction module.

[0025] Further, the UI interaction module further comprises:

[0026] The storage address and the storage file name of the test results are pre-set in the UI interaction module.

[0027] According to the storage address and storage file name of the test result preset in the UI interaction module, the test process of the visible speakable page is started;

[0028] According to the storage address and storage file name of the test result preset in the UI interaction module and the start of the visible speakable page, the test result is stored in the cloud service module and the test case of the test result is obtained.

[0029] Further, the page scanning module comprises:

[0030] The controls of the page in the current screen are iteratively scanned, and the controls supporting visible speakable are screened out, including a tree-shaped hierarchical iterative scanning mode and a recursive mode, and in the middle, it is judged for each control whether it supports visible speakable;

[0031] If yes, the control is loaded into the visible speakable control list corresponding to the page, for the test case generation module to generate the corresponding automatic test case.

[0032] Further, the test case generation module comprises:

[0033] The visible speakable control list is called to generate a test case corresponding to each control in the list;

[0034] The test case comprises a control unique identifier ID, a horizontal coordinate of the control in the screen, a vertical coordinate of the control in the screen, a type of the control, a control type, a control title, a control support intent, a control support voice command, a control sub-title and a control description.

[0035] The test case is randomly generated based on the access authority of the historical data.

[0036] Further, the page hit module comprises:

[0037] The test case of the control is taken out, and matching is performed according to the control title, the control support intent, the control support voice command and the control sub-title to determine whether it is hit.

[0038] The test script is generated based on voice simulation reading;

[0039] The test script comprises matching according to the combination of the control title, the control support intent, the control support voice command and the control sub-title to determine whether it is hit.

[0040] If it is hit, a hit effect is played on the control according to the horizontal center point and the vertical center point of the control in the screen to feed back that the control can be normally hit and is displayed in the UI interaction module.

[0041] If not hit, the result of the hit failure is written into a local file for generating a visible test report.

[0042] According to the three aspects of the present application, a visible automation testing device is provided, which comprises:

[0043] An instruction obtaining module is configured to obtain a test control instruction.

[0044] A control screening module is configured to start scanning the controls of a page in a screen according to the obtained test control instruction, and screen out controls supporting the visible function.

[0045] A test case module is configured to generate an automation test case corresponding to the controls according to the screened controls supporting the visible function.

[0046] The generation of the automation test case corresponding to the controls comprises simulating a hit process of the controls and a preset operation process of the corresponding controls after the hit based on the display state of the controls under a preset scenario and the control voice hit based on the display state of the controls.

[0047] A data processing module is configured to record test data based on the test case of the controls and perform statistics and classification.

[0048] An evaluation report module is configured to generate evaluation information of test efficiency and test accuracy based on the statistics and classification of the test data.

[0049] According to the four aspects of the present application, an electronic device is provided, which comprises a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete mutual communication through the communication bus.

[0050] The memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the visible automation testing method.

[0051] According to the five aspects of the present application, a computer readable storage medium is provided, which stores a computer program executable by an electronic device, and when the computer program runs on the electronic device, the electronic device executes the steps of the visible automation testing method.

[0052] According to the six aspects of the present application, a vehicle is provided, which comprises:

[0053] An electronic device is configured to implement the steps of the visible automation testing method.

[0054] A processor is configured to run a program, and when the program runs, the data output from the electronic device executes the steps of the visible automation testing method.

[0055] A storage medium for storing a program, which, when executed, performs the steps of the visible-to-say automation test method on data output from the electronic device.

[0056] Through the above scheme, the following beneficial technical effects are obtained:

[0057] The application sets a floating window of a page to be tested visible-to-say page through the UI interaction module, so that the page scanning module traverses and scans the controls of the page in the current screen beyond the display content of the UI interaction module.

[0058] The application uses the control unique identifier ID, the horizontal coordinate of the control in the screen, the vertical coordinate of the control in the screen, the type of the control, the control type, the control title, the control support intent, the control support voice command, the control sub-title and the control description to make the test case correspond to the control under the current page. BRIEF DESCRIPTION OF DRAWINGS

[0059] Figure 1 is a flowchart of a visible-to-say automation test method provided by one or more embodiments of the application.

[0060] Figure 2 is a structural diagram of a visible-to-say automation test system provided by one or more embodiments of the application.

[0061] Figure 3 is a structural diagram of a visible-to-say automation test device provided by one or more embodiments of the application.

[0062] Figure 4 is a schematic diagram of a visible-to-say automation test process provided by one specific embodiment of the application.

[0063] Figure 5 is a schematic diagram of a visible-to-say automation test timing provided by one specific embodiment of the application.

[0064] Figure 6 is a structural block diagram of an electronic device for a visible-to-say automation test method provided by one or more embodiments of the application. DETAILED DESCRIPTION

[0065] The technical solutions of the application will be described below in detail with reference to the drawings. Obviously, the described embodiments are part of the embodiments of the application, rather than all the embodiments. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the application.

[0066] Figure 1is a flowchart of a visible-to-say automated test method provided by one or more embodiments of the present application.

[0067] As shown in the visible-to-say automated test method includes: Figure 1

[0068] Step S1, obtaining a test control instruction;

[0069] Step S2, according to the test control instruction obtained, starting to scan the controls of the page in the screen, and screening out the controls supporting the visible-to-say function;

[0070] Step S3, according to the screened out visible-to-say function supporting controls, generating an automated test case corresponding to the controls;

[0071] Among them, generating an automated test case corresponding to the controls includes simulating the hit process of the controls and the preset operation process of the corresponding controls after hitting based on the control display state under the preset scene and the control voice hit based on the control display state;

[0072] Step S4, recording the test data based on the control test case and classifying and counting;

[0073] Step S5, based on the classification and counting of the test data, generating evaluation information of test efficiency and test accuracy.

[0074] ​Specifically, the visible speakable function control displays relevant information under a current page and waits for a voice instruction to be captured, and the state is a voice instruction capture based on the displayed content. In addition to the visible speakable function control, non-visible speakable controls can also be displayed on the page. The user does not necessarily know which controls are visible speakable, or the tester needs to consider the vehicle operating state and the mixed state of multiple types of controls to propose a test method. The automated test case serves as a servo module for the tester to promote visible speakable testing, and realizes voice hits based on the control display state under a preset scenario and the control display state, simulates the hit process of the control and the preset operation process of the corresponding control after the hit. Record the test data based on the test case and classify and count the test data based on the classification and counting of the test data, generate evaluation information of test efficiency and test accuracy, that is, through the probability distribution of the hit rate, form the display control of the identifier on the control under the test scenario and the setting control of the corresponding voice instruction. For example, further edit a MAP including a scene item, an identifier item, and a voice instruction item, etc. for the continuous development of visible speakable. For example, the A control is a visible speakable control for controlling the opening and closing of the window. When the window is open and the vehicle speed is high, the control display identifier is "whether to close the window", and the priority of the captured voice instruction is that the "close the window" instruction is directly executed. For the "open the window" or "increase ventilation" instruction, the interactive confirmation of "whether to increase the window" is fed back. Similarly, when the temperature in the vehicle is high, the control display identifier is "whether to open the window", and the priority of the captured voice instruction is that the "open the window" instruction is directly executed. For the "close the window" instruction, the interactive confirmation of "whether to open the control" is fed back.

[0075] Figure 2 is a structural diagram of a visible speakable automated test system provided by one or more embodiments of the present application.

[0076] As Figure 2 shown, the visible speakable automated test system comprises:

[0077] a UI interaction module, a page scanning module, a test case generation module, a page hit module, a test result collection module, and a cloud service module;

[0078] The UI interaction module is used to receive test control instructions and feed back test process data.

[0079] The page scanning module is used to traverse and scan the controls of the page in the current screen, and filter out the visible speakable controls.

[0080] The test case generation module is used to generate corresponding automated test cases based on the visible speakable controls filtered out by the page scanning.

[0081] a page hit module configured to check a hit of a visible speakable control corresponding to a page according to an automated test case;

[0082] a test result collection module configured to analyze and arrange a result of the hit check locally, and upload the test result to a cloud service module after the analysis and arrangement are completed;

[0083] a cloud service module configured to store the test result and a test case for obtaining the test result.

[0084] Specifically, the UI interaction module and the tested page are displayed on one screen, and the page scanning module scans over the display content of the UI interaction module. The UI interaction module is provided to a tester for terminal interaction. The test case generation module generates a test case according to a preset test case generation rule. The page hit module captures a control hit by a voice instruction based on the running of the test case, and the check process includes whether the instruction is aimed at the currently hit control, whether the instruction overflows to hit other controls, and the like. The test result collection module analyzes the entire test process and the check result, and uploads all data to the cloud service module after the statistics, so that the cloud service module is shared to other development terminals or test control terminals, the current product is developed and adjusted, or the test strategy is adjusted, so that the product or the test presents an expected effect.

[0085] In this embodiment, the UI interaction module includes:

[0086] based on an AndroID Debug BrIDge command, the UI interaction module is set as a floating window of a visible speakable page to be tested;

[0087] based on the UI interaction module, a command of a test visible speakable page is obtained;

[0088] According to the command of the test visible speakable page, the page scanning module scans over the display content of the UI interaction module, and traverses and scans the controls of the page in the current screen.

[0089] Specifically, based on the AndroID Debug BrIDge command, the UI interaction module is set as a floating window of a visible speakable page to be tested, the controls in the floating window are distinguished from the controls outside the floating window, the page scanning module scans over the display content of the UI interaction module, and only traverses and scans the controls of the page outside the floating window in the current screen, so that the test process is under the real-time control of the tester.

[0090] In this embodiment, the UI interaction module further includes:

[0091] the storage address and the storage file name of the test result are pre-set in the UI interaction module;

[0092] According to the storage address and storage file name of the test result preset in the UI interaction module, the test process of the visible-to-speak page is started.

[0093] According to the storage address and storage file name of the test result preset in the UI interaction module and the start of the visible-to-speak page, the test result is stored in the cloud service module and the test case of the test result is obtained.

[0094] Specifically, in addition to controlling the start of the test process, the UI interaction module also controls the storage of the process data and result data that may be generated.

[0095] In this embodiment, the page scanning module includes:

[0096] The controls of the page in the current screen are iteratively scanned to filter out the controls supporting visible-to-speak, including using a tree hierarchical iterative scanning method and in a recursive manner, and judging whether each control supports visible-to-speak in the middle.

[0097] If yes, the control is loaded into the visible-to-speak control list corresponding to the page, for the test case generation module to generate the corresponding automated test case.

[0098] Specifically, the page scanning module first marks the controls supporting visible-to-speak from all controls, and generates the corresponding automated test case according to the specific visible-to-speak supporting control to test the visible-to-speak control.

[0099] In this embodiment, the test case generation module includes:

[0100] The visible-to-speak control list is called to generate a test case corresponding to each control in the list;

[0101] The test case includes a control unique identifier ID, a horizontal coordinate of the control in the screen, a vertical coordinate of the control in the screen, a type of the control, a control type, a control title, a control intent supported by the control, a control voice command supported by the control, a control subtitle, and a control description.

[0102] The test case is randomly generated based on the access permission of the historical data.

[0103] Specifically, the historical data of manual testing can be used as input data for automatic test case generation, and a deep learning model is used for automatic test case generation. The information of the control unique identifier ID, the horizontal coordinate of the control in the screen, the vertical coordinate of the control in the screen, the type of the control, the control type, the control title, the control intent supported by the control, the control voice command supported by the control, the control subtitle, and the control description is locked, so that the test case uniquely corresponds to the visible-to-speak control object.

[0104] In the embodiment, the page hit module comprises:

[0105] The test case of the control is taken out, and matching is performed according to the control title, the control support intent, the control support voice command and the control subtitle, to determine whether a hit is made.

[0106] The test script is generated based on voice simulation reading.

[0107] The test script comprises matching in a combined manner according to the control title, the control support intent, the control support voice command and the control subtitle, to determine whether a hit is made.

[0108] If a hit is made, a hit effect is played at the positive center point of the horizontal coordinate of the control in the screen and the vertical coordinate of the control in the screen, to feed back that the control can be normally hit and display in the UI interaction module.

[0109] If a hit is not made, a result of a hit failure is written into a local file, to generate a visible-sayable test report.

[0110] Specifically, the page hit module checks the test result, to determine whether a hit is made, for example, the control title, the control support intent, the control support voice command and the control subtitle are registered in the page hit module, and only the triggering of the target control and the invalidity of the non-target control are determined based on the test script. Similarly, the test script determines that a hit is not made, if the target control fails to be triggered or the triggering of the target control also hits the non-target control.

[0111] The case of a hit not being made is recorded in detail in the visible-sayable test report, to adjust the development strategy and the test strategy.

[0112] Figure 3 is a structural diagram of a visible-sayable automatic testing device provided by one or more embodiments of the present application.

[0113] As shown in Figure 3 the visible-sayable automatic testing device comprises an instruction acquisition module, a control screening module, a test case module, a data processing module and an evaluation report module.

[0114] The instruction acquisition module is configured to acquire a test control instruction.

[0115] The control screening module is configured to start scanning the controls of a page in a screen according to the acquired test control instruction, and screen out controls supporting a visible-sayable function.

[0116] The test case module is configured to generate an automatic test case of a corresponding control according to the screened controls supporting the visible-sayable function.

[0117] The generating of the automation test case corresponding to the control comprises simulating a hitting process of the control and performing a preset operation process of the corresponding control after the hitting based on the control display state under the preset scene and the control voice hit based on the control display state.

[0118] The data processing module is configured to record test data based on the control test case and to statistically classify the test data.

[0119] The evaluation report module is configured to generate evaluation information of test efficiency and test accuracy based on the statistical classification of the test data.

[0120] It is worth noting that, although the system / device only discloses the instruction obtaining module, the control screening module, the test case module, the data processing module and the evaluation report module, it does not mean that the device is limited to the above basic functional modules. On the contrary, the meaning expressed by the present application is that, on the basis of the above basic functional modules, a person skilled in the art can add one or more functional modules to form an infinite number of embodiments or technical solutions in combination with the prior art. That is to say, the system / device is open rather than closed, and it cannot be considered that the protection scope of the present application is limited to the above disclosed basic functional modules just because the present embodiment discloses only individual basic functional modules.

[0121] Figure 4 is a schematic diagram of the visible automatic test flow provided by one embodiment of the present application.

[0122] Figure 5 is a schematic diagram of the visible automatic test timing provided by one embodiment of the present application.

[0123] In one embodiment, based on the development application of the Android platform, a visible automatic test system is disclosed.

[0124] The system comprises a cloud service module, a UI interaction module, a page scanning module, a test case generation module, a page hitting module and a test result collection module, wherein:

[0125] 1. The function of the cloud service module is mainly responsible for storing test results.

[0126] 2. The function of the UI interaction module mainly includes:

[0127] (1) Test personnel information input, including the test result name to be saved;

[0128] (2) Start test interaction button;

[0129] (3) Information for displaying pop-up window and the like for prompting;

[0130] (4) Manually notify the cloud module to upload the local test results to the cloud.

[0131] 3. The page scanning module mainly functions to traverse and scan all controls of a page in the current screen, and filter out controls supporting visible-to-speak.

[0132] 4. The test case generation module generates corresponding automatic test cases based on the visible-to-speak controls scanned by the page scanning.

[0133] 5. The page hitting module hits and checks the corresponding visible-to-speak controls of the page according to the automatic test cases.

[0134] 6. The test result collection module will arrange the hitting and checking results locally, and after the arrangement and analysis are completed, upload the test results to the cloud service module.

[0135] Based on the above specific embodiments, the visible-to-speak automatic test process is disclosed as shown in Figure 4 .

[0136] 1. The tester operates the screen to the page to be tested:

[0137] (1) The tester first switches to the page to be tested for visible-to-speak;

[0138] (2) The adb (AndroID Debug BrIDge) command is used to start the floating window of the UI interaction module, which is not in the page to be tested, and the floating window will not be scanned into the object to be tested by the subsequent scanning process.

[0139] 2. The tester clicks the start button of the UI interaction module to start the test:

[0140] (1) The tester first inputs the test result name to be saved on the floating window, which is used as the file name of the cloud to be finally uploaded;

[0141] (2) The tester clicks the start test button in the UI interaction module to start the test task thread.

[0142] 3. The page scanning module scans the page:

[0143] The page scanning module will scan the current page to be tested, and the scanning method is a tree-level traversal scanning method, which is recursively performed. In the middle, it is determined whether each control supports visible-to-speak (such as whether it supports click operation and whether the state is set to available). If so, it is added to a visible-to-speak control list of the page for subsequent test case generation. The traversal algorithm is as follows:

[0144] / **

[0145] *Tree traversal of all views

[0146] ** /

[0147] voID traverseView(ParentView){

[0148] if ParentView is not null:

[0149] / / Access the current view

[0150] visit(view)

[0151] / / Recursively traverse subviews

[0152] for each child in view.children:

[0153] traverseView(child)

[0154] }

[0155] / **

[0156] *Filter controls of the "visible and speakable" type and add them to the control list.

[0157] ** /

[0158] voID visit(view){

[0159] if (view instanceof visible control) {

[0160] The view can be added to the list of controls.

[0161] }

[0162] }

[0163] 4. The test case generation module generates test cases:

[0164] The test case generation module generates test cases for each visible and speakable control based on the previously scanned list. Each visible and speakable control contains the following information:

[0165] {

[0166] / / Unique identifier ID of the control

[0167] viewID,

[0168] / / The horizontal coordinate of the view on the screen

[0169] viewLocationXInScreen,

[0170] / / view in screen y coordinate

[0171] viewLocationYInScreen,

[0172] / / view type

[0173] viewWIDgetType,

[0174] / / view title

[0175] viewTitle,

[0176] / / view supported intention

[0177] viewIntention,

[0178] / / view supported voice command

[0179] viewCmd,

[0180] / / view subtitle

[0181] viewSubTitle,

[0182] / / view description

[0183] viewDescreption,

[0184] / /

[0185] viewSource

[0186] }

[0187] The test case generation module generates corresponding test cases based on the above control information. Among them, the control unique identifier ID (viewID), the horizontal coordinate of the view in the screen (viewLocationXInScreen), the vertical coordinate of the view in the screen (viewLocationYInScreen), and the type of the view (viewWIDgetType) are fixed and unchanged, consistent with the information reported by the control itself. The control type (viewType), title (viewTitle), supported intention (viewIntention), supported voice command (viewCmd), subtitle (viewSubTitle), and description of the view (viewDescreption) are randomly generated. The randomly generated data is also extracted and generated based on the historical database reported by the control before.

[0188] The properties of each visible and speakable control are control type (viewType), title (viewTitle), supported intention (viewIntention), supported voice command (viewCmd), and subtitle (viewSubTitle). After scanning these controls, the properties of the control are supplemented according to the control type (viewType). That is, the title (viewTitle), supported intention (viewIntention), supported voice command (viewCmd), and subtitle (viewSubTitle). These intentions have different property values as fillings according to different control types. The data is derived from a local database, and values are filled to the control from the database. For example, the control scans the type switchWIDget type, that is, the switch type, finds the test case of the switch type from the database, and fills other properties, such as the title (viewTitle) of the scanned control, the intention of the database reading reply tts, the voice command of the database reading "on, off" command, and the subtitle of the control sub-control title, which is empty if there is none. The database sets N corresponding property values for each type of visible and speakable control, and the generated case is also randomly selected from the N types.

[0189] In addition, the database itself can be updated from the cloud regularly. As the number of control types increases, the number of actual supportable statements increases, and the test personnel can regularly extend the content in the data to automatically test later, without the need for manpower to repeat case testing. The use case of the visible and speakable database is a use case that has been run by manpower before and passed, and is recorded in the database. For the same type of control and the same property, manpower is no longer needed to test. Therefore, it can replace manual testing of previous repeated use cases.

[0190] For each visible and speakable control, different combinations of test cases are generated. Finally, a full case use case collection data of a control list is generated.

[0191] 5, The page hit module performs hit verification according to the test case:

[0192] (1) The page hit module performs hit verification on each control according to the test case set provided in the previous step.

[0193] (2) Extract the case corresponding to the view and match it according to the title (viewTitle), supported intent (viewIntention), supported voice command (viewCmd), and subtitle (viewSubTitle) to confirm whether it matches. The match determination method is to read the generated test script through voice simulation. The test script is matched according to the title, supported intent, voice command, and a combination of title and subtitle. A match is considered to be achieved if the following condition is met:

[0194] a. Matching of wording and title;

[0195] b. Matching the wording with the title and subtitle;

[0196] c. Script and headline + intent matching;

[0197] d. Matching of script and title with voice commands;

[0198] (3) If a hit is achieved, a hit animation will be played on the control based on the center point of the control's horizontal and vertical coordinates on the screen, providing feedback to the tester to indicate that the control has been successfully hit. At the same time, the hit result will be written to a local file.

[0199] (4) If a match cannot be found, the result of the failed match is written directly to a local file.

[0200] (5) Finally, compile a test report of the current page that can be viewed and discussed locally.

[0201] 6. Upload test results to the cloud module:

[0202] (1) The cloud module will upload the test results to the cloud. After successful upload, it will prompt the user through the UI interaction module that the upload was successful and delete the local file to free up disk space.

[0203] (2) If the upload fails, the user will be notified via the UI interaction module. The user can then manually upload the local test results through the UI interaction module.

[0204] 7. Testers retrieve test results from the cloud:

[0205] Testers retrieve test results from a cloud platform.

[0206] In another screenshot embodiment, the disclosure is as follows Figure 5 The visible-to-say automated test sequence is shown below:

[0207] 1. Testers first adjust the test page to the test state and use adb commands to open the floating window of the UI interaction module.

[0208] 2、Testers input the name of the test result on the floating window of the UI interaction module, so that the test result can be queried on the cloud later. After preparation is completed, click the start button on the floating window of the UI interaction module to perform automated testing.

[0209] 3、The UI interaction module notifies the page scanning module to scan the page being tested.

[0210] 4、The page scanning module scans the page being tested. Visible and speakable controls of the page are scanned into the control list for testing.

[0211] 5、The page scanning module provides the test case generation module with the results of page scanning.

[0212] 6、The test case generation module generates different test cases for each visible and speakable control in the page based on the historical visible and speakable database, and provides the page hit module.

[0213] 7、If the test case hits the visible and speakable control, the page hit module will notify the corresponding control on the page being tested to play the animation effect to inform the tester that the control hit is successful. The test result is provided to the test result collection module for each test case.

[0214] 8、After all test cases are run, the test result collection module will organize the test case set into a final test report, indicating which controls hit and which controls did not hit.

[0215] 9、The test result collection module uploads the final test report to the cloud module.

[0216] 10、The tester can obtain the final result report of the visible and speakable automated testing of the page through the cloud module.

[0217] Through the above embodiments, the present application realizes full automation of page visible and speakable testing, and automatically generates test results and uploads them to the cloud. It no longer completely relies on the traditional manual testing method, and the main advantages include:

[0218] 1、Improve testing efficiency and speed: Automated testing can quickly execute test cases, which is faster and more efficient than manual testing. This helps to complete more tests in a short time and speeds up the product delivery cycle.

[0219] 2、Reduce costs: Although initial implementation of automated testing may require some investment, it can reduce testing costs in the long run. It reduces the time, human resources and costs required for manual testing.

[0220] 3、Increase test coverage: Automated testing can cover a wider range of test scenarios, ensuring the quality and stability of software.

[0221] 4. Improve test accuracy: Automated testing can reduce the impact of human factors on test results, thereby improving the accuracy and consistency of testing.

[0222] 5. Facilitate repeated execution: Automated test cases can be easily repeated in different car environments and configurations, ensuring that the software performs normally in various situations.

[0223] 6. Find defects earlier: Through automated testing, defects in software can be found and diagnosed earlier, helping to solve problems as soon as possible.

[0224] 7. Release test personnel energy: Automated testing can free testers from tedious and repetitive tasks, allowing them to focus more on designing higher-value test cases and conducting exploratory testing.

[0225] Figure 6 An electronic device structure block diagram of the visible automatic test method provided by one or more embodiments of the present application.

[0226] As Figure 6 shown, the present application provides an electronic device, comprising: a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete the communication among each other through the communication bus;

[0227] The memory stores a computer program, which, when executed by the processor, causes the processor to execute the steps of the visible automatic test method.

[0228] The present application also provides a computer readable storage medium storing a computer program executable by an electronic device, which, when the computer program runs on the electronic device, causes the electronic device to execute the steps of the visible automatic test method.

[0229] The present application also provides a vehicle, comprising:

[0230] An electronic device for implementing the steps of the visible automatic test method;

[0231] A processor, the processor runs a program, and when the program runs, the data output from the electronic device executes the steps of the visible automatic test method;

[0232] A storage medium for storing a program, which, when running, executes the steps of the visible automatic test method for data output from the electronic device.

[0233] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The communication bus can be divided into an address bus, a data bus, a control bus, and the like. For the convenience of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0234] The electronic device includes a hardware layer, an operating system layer running above the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and a memory. The operating system can be any one or more computer operating systems that implement control of the electronic device through a process, such as a Linux operating system, a Unix operating system, an Android operating system, an iOS operating system, or a Windows operating system. In embodiments of the present application, the electronic device can be a handheld device such as a smartphone or a tablet computer, or an electronic device such as a desktop computer or a laptop computer, and is not particularly limited in embodiments of the present application.

[0235] The execution subject of the electronic device control in embodiments of the present application can be the electronic device, or a functional module in the electronic device that can call and execute a program. The electronic device can obtain firmware corresponding to the storage medium, which is provided by a vendor, and the firmware corresponding to different storage media can be the same or different, which is not limited herein. After obtaining the firmware corresponding to the storage medium, the electronic device can write the firmware corresponding to the storage medium into the storage medium, specifically, burn the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented by using existing technology, which is not described in detail in embodiments of the present application.

[0236] The electronic device can also obtain a reset command corresponding to the storage medium, which is provided by a vendor, and the reset command corresponding to different storage media can be the same or different, which is not limited herein.

[0237] At this time, the storage medium of the electronic device is a storage medium into which the corresponding firmware is written, and the electronic device can respond to the reset command corresponding to the storage medium in the storage medium into which the corresponding firmware is written, so that the electronic device resets the storage medium into which the corresponding firmware is written according to the reset command corresponding to the storage medium. The process of resetting the storage medium according to the reset command can be implemented by using existing technology, which is not described in detail in embodiments of the present application.

[0238] For the convenience of description, the above apparatus is described in various units, modules, and the like in terms of functions. Of course, the functions of the units and modules can be implemented in one or more software and / or hardware in implementing the present application.

[0239] Those skilled in the art can understand that, unless otherwise defined, all terms (including technical terms and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. It should also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless specifically so defined.

[0240] For the convenience of description, the above apparatus is described in various units, modules, and the like in terms of functions. Of course, the functions of the units and modules can be implemented in one or more software and / or hardware in implementing the present application.

[0241] From the above description of the embodiments, those skilled in the art can clearly understand that the present application can be implemented by means of software and the necessary universal hardware platforms. Based on such an understanding, the technical solutions of the present application can be embodied in the form of a software product, which can be stored in a storage medium, such as a ROM / RAM, a magnetic disk, an optical disk, and the like, and includes a number of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments of the present application.

[0242] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for some or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A visible speak-up automated testing method, characterized by, The visible-sayable automation testing method comprises: obtaining a test control instruction; starting scanning the controls of the page in the screen according to the obtained test control instruction, and screening out the controls supporting the visible-sayable function; generating the automation test case of the corresponding control according to the screened out visible-sayable function control; wherein, generating the automation test case of the corresponding control comprises simulating the hitting process of the control and executing the preset operation process of the corresponding control after hitting based on the control display state under the preset scene and the control voice hit based on the control display state; recording the test data based on the control test case and classifying and counting the test data; generating the evaluation information of the test efficiency and the test accuracy based on the classified and counted test data.

2. A visible speak-up automated test system, characterized by, The visible-sayable automation testing system comprises: a UI interaction module, a page scanning module, a test case generation module, a page hitting module, a test result collection module and a cloud service module; the UI interaction module is used for receiving a test control instruction and feeding back test process data; the page scanning module is used for scanning the controls of the page in the current screen, and screening out the controls supporting the visible-sayable function; the test case generation module is used for generating the corresponding automation test case based on the visible-sayable control screened out by the page scanning; the page hitting module is used for checking the hitting of the visible-sayable control corresponding to the page according to the automation test case; the test result collection module is used for analyzing and arranging the result of the hitting check locally, and uploading the test result to the cloud service module after the analysis and arrangement are completed; the cloud service module is used for storing the test result and the test case of the test result.

3. The visible-then-say automated test system of claim 2, wherein, The UI interaction module comprises: based on the AndroID Debug BrIDge command, the UI interaction module is set as the floating window of the visible-sayable page to be tested; based on the UI interaction module, the command for testing the visible-sayable page is obtained; according to the command for testing the visible-sayable page, the page scanning module scans the controls of the page in the current screen by bypassing the display content of the UI interaction module.

4. The visible-then-say automated test system of claim 3, wherein, The UI interaction module further comprises: pre-setting the storage address and the storage file name of the test result in the UI interaction module; starting the test process of the visible-sayable page according to the pre-set storage address and storage file name of the test result in the UI interaction module; storing the test result and the test case of the test result in the cloud service module according to the pre-set storage address and storage file name of the test result in the UI interaction module and starting the test of the visible-sayable page.

5. The visible-then-say automated test system of claim 4, wherein, The page scanning module comprises: scanning the controls of the page in the current screen, and screening out the controls supporting the visible-sayable function comprises using the tree-shaped hierarchical scanning mode and the recursive mode, and judging whether each control supports the visible-sayable function in the middle; if yes, the control is loaded into the visible-sayable control list corresponding to the page, and is used for the test case generation module to generate the corresponding automation test case.

6. The visible-then-say automated test system of claim 5, wherein, The test case generation module comprises: calling the visible-sayable control list, and generating the test case corresponding to each control in the list; The test case includes a control unique identifier ID, a horizontal coordinate of the control in a screen, a vertical coordinate of the control in the screen, a type of the control, a control type, a control title, a control supported intent, a control supported voice command, a control subtitle, and a control description. The test case is randomly generated based on the access permission of the historical data.

7. The visible-then-say automated test system of claim 6, wherein, The page hitting module includes: The test case of the control is taken out, and matching is performed according to the control title, the control supported intent, the control supported voice command, and the control subtitle to determine whether a hit is made. The test script is generated based on voice simulation reading. The test script includes matching in a combined manner according to the control title, the control supported intent, the control supported voice command, and the control subtitle to determine whether a hit is made. If a hit is made, a hit effect is played on the control according to a center point of the horizontal coordinate and the vertical coordinate of the control in the screen to feed back that the control can be normally hit and display the UI interaction module. If a hit is not made, a result of a hit failure is written into a local file to generate a visible-sayable test report.

8. A visible speak-up automated testing device, characterized by, The visible-sayable automatic test device includes: An instruction acquisition module configured to acquire a test control instruction; A control screening module configured to start scanning a control of a page in a screen according to the acquired test control instruction, and screen out a control supporting a visible-sayable function; A test case module configured to generate an automatic test case of the corresponding control according to the screened control supporting the visible-sayable function; The generation of the automatic test case of the corresponding control includes simulating a hitting process of the control and a preset operation process of the corresponding control after the hitting based on a control display state under a preset scene and a control voice hit based on the control display state. A data processing module configured to record test data based on the control test case and statistically classify the test data; An evaluation report module configured to generate evaluation information of test efficiency and test accuracy based on the statistical classification of the test data.

9. An electronic device, comprising: The visible-sayable automatic test device includes: A processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory complete mutual communication through the communication bus; The memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the visible-sayable automatic test method in claim 1.

10. A computer-readable storage medium, characterized in that, The memory stores a computer program executable by the electronic device, and when the computer program runs on the electronic device, the electronic device executes the steps of the visible-sayable automatic test method in claim 1.

Images