Automatic testing method, device and equipment based on Android vehicle-mounted terminal system

Abstract

The invention relates to the field of automated testing, and discloses an automated testing method, device and equipment based on an Android vehicle-mounted infotainment system, which comprises the following steps: defining test tasks in a plurality of scenes, including a plurality of test items in different scenes; sending the test items under different scenes to a test database, calling the test file corresponding to each scene, and performing automatic test on all the test items under the same test task type; judging based on a difference value between a configuration parameter initial value obtained under a preset constraint condition and a configuration parameter obtained by testing, generating a test result, and storing the test result in a test database; responding to a to-be-tested item in at least one target scene selected by the user side in the plurality of test tasks, and obtaining a test result of the to-be-tested item from the test database; and generating a performance evaluation report according to a test result. According to the scheme, all tests can complete automatic tasks under the unmanned condition, manpower input is greatly saved, and the test speed and the test efficiency are improved.

Description

Technical Field

[0001] The present application relates to the field of automated testing technology, and in particular to an automated testing method, device, and equipment based on an Android vehicle system. Background Art

[0002] With the booming electric vehicle industry, the number of electric vehicle companies is increasing, much like the proliferation of mobile phone manufacturers in the past. The host computer, as the primary interface for electric vehicle interaction, is also attracting significant attention. Therefore, the development efficiency of host manufacturers is a key factor in this transformation. If we can achieve a product's development, testing, and acceptance cycle several months or even six months faster than others while ensuring product quality, we will have a significant advantage over other manufacturers in the same product category. Shortening the development cycle while ensuring quality requires not only improving R&D capabilities but also multi-faceted testing to uncover more issues, often through automated testing. Only with more automated testing solutions can we improve testing efficiency for everyone without increasing labor costs, thereby increasing the efficiency of identifying issues and ultimately gaining a quality advantage over other manufacturers.

[0003] Exposing problems early also helps R&D resolve them before they're discovered late, potentially delaying projects. Automated testing can also ensure quality by completing more tests within the same timeframe, or shorten the testing cycle for the same number of tests, potentially reducing manual effort. The Android system is increasingly favored by OEMs, so developing solutions tailored to the Android system is urgent.

[0004] Patent [CN116841273A, Domain Controller Testing Method, System, and Centralized Multi-Domain Testing Platform, Method] focuses on the implementation of individual test items and how to implement the test paths for these test items. Patent [CN117992323A, In-Vehicle Entertainment System Automated Testing Method, Device, and Electronic Device], on the other hand, focuses on a command testing solution and does not specifically describe the testing scheme. It simply states that command testing is performed by parsing structures and using scripts and tables, but does not directly implement visual test configuration.

[0005] Patent [CN104503875A, Android Device Testing Method and System] is a testing solution for Android devices. Relying on the Android system, while it describes some specific test items and system call interface information, it focuses on connecting all test items in a series in different orders and applying them to as many scenarios as possible, equivalent to creating an app that can be used in different situations. Patent [CN112100012B, Android Device Testing Method, Android Device, and Storage Medium] also combines multiple test items into a single app for simultaneous testing, triggered by inserting a specific file from a USB drive. It also describes the test items and test solutions for some of these test items.

[0006] As can be seen, some of the existing technologies focus on test items and implementing specific solutions for each test item, while others focus on how to trigger the test. However, how to integrate all test items and configure and test multiple scenarios has become a pressing challenge. Summary of the Invention

[0007] Therefore, it is necessary to address the above technical issues and provide an automated testing method, device, and equipment based on the Android vehicle system. This method can be optimized and applied uniformly across various scenarios, making it more widely applicable. By directly triggering commands to operate the interface, all test configurations and plans can be visualized, making observation more intuitive, without the need to connect to other additional equipment, and thus avoiding device dependence.

[0008] In a first aspect, the present application provides an automated testing method based on an Android vehicle system, the method comprising:

[0009] Defining test tasks under multiple scenarios, wherein the test tasks include multiple test items under different scenarios;

[0010] Send test items under different scenarios to the test database, call the test files corresponding to each scenario, and perform automated testing on all test items under the same test task type;

[0011] Based on the initial values ​​of the configuration parameters obtained under the preset constraints, the difference between the configuration parameters obtained during the test is judged, the test results are generated, and stored in the test database;

[0012] In response to a to-be-tested item in at least one target scenario selected by a user terminal from a plurality of test tasks, a test result of the to-be-tested item is acquired from the test database; and a performance evaluation report is generated according to the test result.

[0013] Optionally, the definition of the test task includes: accessing an interface, configuring interface parameters according to different scenario requirements, and setting a test task type;

[0014] According to the set test task type, test items are established in multiple scenarios; wherein, the test items include functional test items and routine test items; the performance test items include PCB test, whole machine test, and baking test; the routine test items include USB test, USB music test, camera test, Bluetooth test, WiFi test, screen projection test and mic test on the vehicle side.

[0015] Optionally, the test task types include a number test task and a time test task.

[0016] Optionally, sending the test items under different scenarios to the test database, calling the test files corresponding to each scenario, and performing automated testing on all test items under the same test task type includes:

[0017] In the designated area of ​​the interface, test tasks under different scenario requirements are displayed;

[0018] Arrange the names of all test items included in the test task and generate a test item list after sorting;

[0019] Use a pre-set language to write a script to read the test item list, and use the pre-established automated testing platform to test the test items from the top of the test item list in sequence until the execution is completed according to the configured parameters or stopped midway;

[0020] When executing a test task, the test item to be tested is selected and then the test is started. All test items are tested individually according to the pre-set order. After the test is completed, the test results are recorded and the next test item is jumped to.

[0021] If no operation is performed, after all test tasks are executed according to the configuration parameters, the test ends normally and the configuration parameters are passed to the code;

[0022] During the test, the control status is read and the first action instruction is triggered to detect whether the test task stops executing;

[0023] If the first action instruction is triggered again, a new test task is created; if the first action instruction is triggered after the configuration parameters are modified, a new test task is created according to the new configuration parameters;

[0024] If the second action instruction is triggered during the test, the next round of testing of the test task will be started directly; and after the test is completed, the test results will be verified to be valid by comparing the configuration parameters obtained from the test with the initial values ​​of the configuration parameters.

[0025] Optionally, the pre-establishment of the automated testing platform includes:

[0026] Use SDK tools to parse configuration parameters, obtain control information and status information of the interface elements to be tested, and store relevant records of the information in the test database for script calls;

[0027] Read the test files used to execute the test tasks in the test database, read the contents of the test files one by one, and convert them into variables in the script; wherein the test files are code files formulated by the test plans of different stages from production to R&D to mass production to after-sales;

[0028] Set up the interface calling module to call the CAN interface and complete the initial value of the configuration parameters based on the preset constraints.

[0029] Set up and complete the sending and receiving of corresponding message data according to test requirements;

[0030] Acquire the message data transmitted by the CAN interface; analyze the action instructions of the vehicle end contained in the message data; wherein the machine

[0031] Action commands on the vehicle side include click, slide, long press and read status;

[0032] According to the set configuration test parameters, complete the message data sending and receiving, interface configuration, data acquisition, automated testing and test verification process.

[0033] Optionally, reading a test file from a test database for executing a test task includes:

[0034] Compiling a header file, and setting breakpoint information for generating at least one snapshot file in the header file;

[0035] Compiling the test program;

[0036] The header file and the test program are encapsulated to obtain the test file to test the test item; wherein the test file includes the header file and the test program; wherein the header file includes breakpoint information for generating at least one snapshot file.

[0037] Optionally, the preset constraint conditions include:

[0038] Environmental constraints, used to specify the ambient temperature range of the test item;

[0039] Functional constraints, which are used to specify product functionality and quality;

[0040] Format constraints are used to specify the file format of the test item.

[0041] Optionally, obtaining the test results of the items to be tested from the test database and generating the performance evaluation report according to the test results includes: obtaining the test results of each test item in the test item list;

[0042] Generate log files based on relevant screenshots, logs, and test result verification information obtained during the automated testing process for all test items.

[0043] In a second aspect, the present application provides an automated testing device based on an Android vehicle system, comprising:

[0044] A task formulation module is used to define test tasks under multiple scenarios, wherein the test tasks include multiple test items under different scenarios;

[0045] The test module is used to send test items under different scenarios to the test database, call the test files corresponding to each scenario, and perform automated testing on all test items under the same test task type;

[0046] A verification module is used to determine the difference between the initial values ​​of the configuration parameters obtained under the preset constraints and the configuration parameters obtained during the test, generate test results, and store them in a test database;

[0047] The acquisition module is used to obtain the test results of the to-be-tested item from the test database in response to at least one to-be-tested item in a target scenario selected by the user terminal from multiple test tasks; and generate a performance evaluation report according to the test results.

[0048] In a third aspect, the present application provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of any one of the methods described in the first aspect when executing the computer program.

[0049] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of any one of the methods in the first aspect.

[0050] The above-mentioned automated testing method, device and equipment based on the Android car system, by defining test items and enabling all tests to complete automated tasks with or without people, can greatly save manpower investment, speed up testing, improve testing efficiency, help developers deal with bugs in advance, and speed up the development cycle; at the same time, it also meets the design requirements of multiple scenarios, such as automation of production lines and automation of laboratories. In scenarios beyond the requirements, it truly realizes automated processing, effectively reducing the learning cost of operators and the communication cost of operators in different scenarios.

[0051] This solution breaks the limitations of traditional testing methods and can integrate various complex and changing test scenarios for unified and efficient optimization processing, thereby greatly broadening its application scope. Whether it is simple functional verification or complex system interaction testing, it can easily handle it.

[0052] The core advantage of this automated testing solution lies in its convenient user interface. By using a trigger command mechanism, testers no longer need to manually navigate the vehicle system interface. Instead, they can simply issue the corresponding commands to directly and precisely operate the interface. This significantly improves testing efficiency and reduces errors caused by manual operation. More importantly, the solution visualizes all test configurations and plans. Testers can clearly see all test parameters, processes, and expected results on an intuitive interface, making observations clear and easy. This visual design makes the testing process more transparent, allowing testers to identify and resolve issues promptly.

[0053] Furthermore, the automated testing method, system, and device are capable of operating independently without the need for connecting to additional equipment, significantly improving testing flexibility and convenience. This avoids increased testing costs and inaccurate test results due to device compatibility issues. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Figure 1 Flowchart of the automated testing method based on the Android vehicle system provided by the specific embodiment of the present invention;

[0055] Figure 2 A schematic diagram of an automated testing process in one embodiment;

[0056] Figure 3 This is a structural block diagram of an automated testing device based on an Android vehicle system in one embodiment;

[0057] Figure 4 FIG. 1 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0058] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0059] Under the current circumstances of various car manufacturers, different solutions often need to be designed in different operating scenarios to meet the testing requirements in different scenarios.

[0060] First, it consumes manpower. Each test solution requires at least three people to design, develop code, and test and verify the solution. If there are nine different scenarios, nine different designs may be required. Even if there is overlap in personnel and solutions, it is not a task that three people can handle. This solution only requires three people and can meet the needs of multiple test scenarios. The manpower saved is a cost saving for the company.

[0061] Second, it consumes system performance and space. Multiple solutions, each designed to meet testing requirements, must be packaged into the system if they are to function in different scenarios. Multiple solutions for multiple scenarios can take up considerable system space, but this is completely avoidable, saving the company energy and costs.

[0062] Third, operators in different scenarios need to master the test solutions for each scenario, and the operations performed by different operators may not be universal. Therefore, when staff is tight, borrowing operators from other scenarios to operate other scenarios takes time, increases learning costs, and also increases communication costs. This solution makes all operation scenarios simple to learn, quick to use, and easy to use. At the same time, when switching to other scenarios, there is no learning cost, and there is no communication cost when communicating with operators in other scenarios.

[0063] Fourth, different testing methods are used in different scenarios. From production to R&D to mass production, different testing and quality standards may be applied at different stages due to different methods. However, these standards can be unified. If unified, everyone's goals will be consistent and single at all stages, which is beneficial for R&D, testing, and quality. Recognizing unified standards reduces communication costs between departments, indirectly improving work efficiency and saving labor costs.

[0064] The automated testing method, device, and equipment for the Android vehicle system provided in the embodiments of this application address the above existing problems through unified planning and design. They are applicable to all aspects and scenarios, from production to mass production to after-sales service, requiring only three aspects: solution design, code development, and testing and verification. The solution can be packaged into a single file and integrated into the system to meet multiple scenarios and save space. In practical applications, this can be beneficial for companies in reducing labor costs, communication costs, improving work efficiency, reducing energy consumption, saving raw materials, saving processes, and making operation, control, and use easier.

[0065] Furthermore, the automated testing methods, devices, and equipment based on the Android vehicle system provided in the embodiments of this application can be applied to various testing environments in different scenarios. With advantages such as comprehensive scenario optimization, convenient interface operation, visual test configuration, and no need for additional equipment, it brings a new solution to the field of intelligent automotive testing.

[0066] The method can be applied to a terminal, a server, or a system including a terminal and a server, and implemented through interaction between the terminal and the server. The terminal can be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, etc.

[0067] In one embodiment, Figure 1 As shown, an automated testing method based on an Android vehicle system is provided. The method is described by taking the vehicle terminal as an example, and includes the following steps:

[0068] Step S101, defining test tasks under multiple scenarios, wherein the test tasks include multiple test items under different scenarios;

[0069] Step S102: Send the test items under different scenarios to the test database, call the test files corresponding to each scenario, and perform automated testing on all test items under the same test task type;

[0070] Step S103, based on the difference between the initial values ​​of the configuration parameters obtained under the preset constraints and the configuration parameters obtained by the test, a test result is generated and stored in the test database;

[0071] Step S104 , in response to the user terminal selecting at least one to-be-tested item in a target scenario from a plurality of test tasks, obtaining a test result of the to-be-tested item from the test database; and generating a performance evaluation report according to the test result.

[0072] In step S101 of the above embodiment, defining the test task includes: accessing the interface, configuring the interface parameters according to different scenario requirements, and setting the test task type;

[0073] Establish test items in multiple scenarios according to the set test task type;

[0074] Among them, the test items include functional test items and routine test items; the performance test items include PCB test, whole machine test, and baking test; the routine test items include USB test, USB music test, camera test, Bluetooth test, WiFi test, screen projection test and mic test on the car side.

[0075] The test task types include number test tasks and time test tasks.

[0076] In step S102 of the above embodiment, sending the test items under different scenarios to the test database and calling the test files corresponding to each scenario to perform automated testing on all test items under the same test task type includes:

[0077] In the designated area of ​​the interface, test tasks under different scenario requirements are displayed;

[0078] Arrange the names of all test items included in the test task and generate a test item list after sorting;

[0079] Use a pre-set language to write a script to read the test item list, and use the pre-established automated testing platform to test the test items from the top of the test item list in sequence until the execution is completed according to the configured parameters or stopped midway;

[0080] When executing a test task, the test item to be tested is selected and then the test is started. All test items are tested individually according to the pre-set order. After the test is completed, the test results are recorded and the next test item is jumped to.

[0081] If no operation is performed, after all test tasks are executed according to the configuration parameters, the test ends normally and the configuration parameters are passed to the code;

[0082] During the test, the control status is read and the first action instruction is triggered to detect whether the test task stops executing;

[0083] If the first action instruction is triggered again, a new test task is created; if the first action instruction is triggered after the configuration parameters are modified, a new test task is created according to the new configuration parameters;

[0084] If the second action instruction is triggered during the test, the next round of testing of the test task will be started directly; and after the test is completed, the test results will be verified to be valid by comparing the configuration parameters obtained from the test with the initial values ​​of the configuration parameters.

[0085] In the above embodiment, the pre-establishment of the automated testing platform includes:

[0086] Use SDK tools to parse configuration parameters, obtain control information and status information of the interface elements to be tested, and store relevant records of the information in the test database for script calls;

[0087] Read the test files used to execute the test tasks in the test database, read the contents of the test files one by one, and convert them into variables in the script; wherein the test files are code files formulated by the test plans of different stages from production to R&D to mass production to after-sales;

[0088] Set up the interface calling module to call the CAN interface and complete the initial value of the configuration parameters based on the preset constraints.

[0089] Set up and complete the sending and receiving of corresponding message data according to test requirements;

[0090] Acquire the message data transmitted by the CAN interface; analyze the action instructions of the vehicle end contained in the message data; wherein the machine

[0091] Action commands on the vehicle side include click, slide, long press and read status;

[0092] According to the set configuration test parameters, complete the message data sending and receiving, interface configuration, data acquisition, automated testing and test verification process.

[0093] In the above embodiment, reading the test file in the test database for executing the test task includes:

[0094] Compiling a header file, and setting breakpoint information for generating at least one snapshot file in the header file;

[0095] Compiling the test program;

[0096] The header file and the test program are encapsulated to obtain the test file to test the test item; wherein the test file includes the header file and the test program; wherein the header file includes breakpoint information for generating at least one snapshot file.

[0097] In step S103 of the above embodiment, the preset constraint conditions include:

[0098] Environmental constraints, used to specify the ambient temperature range of the test item;

[0099] Functional constraints, which are used to specify product functionality and quality;

[0100] Format constraints are used to specify the file format of the test item.

[0101] In step S104 of the above embodiment, obtaining the test results of the items to be tested from the test database and generating the performance evaluation report according to the test results include: obtaining the test results of each test item in the test item list;

[0102] Generate log files based on relevant screenshots, logs, and test result verification information obtained during the automated testing process for all test items.

[0103] In one embodiment, if a test is started, it can be designed to continue the test after the power is turned off and on again, thus ensuring the continuity of the test. As long as the end criteria are not met or the test is stopped midway, the test will continue;

[0104] In one embodiment, the test can be performed by number or by time. These two configurations are required in different scenarios. For the test by number, the number of tests and the interval between each run can be configured until the test is terminated. For the test by time, the single test time and the interval between each run can be configured until the test is terminated.

[0105] In one embodiment, the test records of this case can be freely configured and stored in system memory or on a USB drive, which makes it easy to export the test records.

[0106] In different scenarios, whether by test number, test time, long run or short run, after selecting a plan, detailed information of the current running plan will be displayed, such as the current test number, the time until the next test, the current test time, the time until the next test, etc., so that operators can understand the detailed progress of the operation;

[0107] All test items can be selected or unselected, or double-clicked to arbitrarily configure the test items in the left list to the test order list on the right. The order of the test items on the left will not affect the order on the right. In other words, the left test item that is double-clicked for the first time will be the first test item on the right, and so on. In this way, you can flexibly configure the number of test items and the order of the test items.

[0108] After the test plan is started, you can stop it or skip the configured time interval to proceed to the next round of testing, which allows for flexible configuration of the test plan.

[0109] Example 1: Based on the inventive concept of the above specific embodiment, the present invention provides the following specific test scheme to further illustrate the working principle and operation process of the test, such as Figure 2 As shown, specifically including:

[0110] Enter the interface and configure the interface parameters according to the needs of the current scenario. The two main directions are testing by number of times or testing by time;

[0111] Select the test items you want to test on the left. Select All to test all of them. Double-click the test items on the left and a new order of test items will be displayed on the right. After clicking Start Detection, the test items will be tested from top to bottom until the execution is completed according to the configured parameters or stopped midway.

[0112] Whether you are testing by time or by time, after configuring all parameters and the test items you want to test, start the test. All test items will be tested individually according to the new order of double-clicking. After the test is completed, the test results are recorded and the next test item is jumped to. If you do not perform any operation, the test item will complete all tasks according to the configured parameters, and the test will end normally. The configuration parameters are passed to the code.

[0113] During the test, you can click "Stop Test" to stop the test task and it will not be executed again. At this time, you can click "Start Test" again without modifying any parameters. A new test task will be created, but the parameters will be the same as the original one. If you change some configuration parameters at this time and click "Start Test" again, a new test task will be created based on the new configuration parameters.

[0114] During the test, click "Stop Waiting" and the next round of testing will no longer pay attention to the remaining time of the time interval, and will directly start the next round of testing of the detection task. This is convenient for operators to set the time interval incorrectly, resulting in a long waiting time, and directly skip it to save time.

[0115] Each test item is developed according to the hardware supported by the current project, such as conventional USB test, USB music test, camera test, Bluetooth test, WiFi test, mic test, etc. These are basically the functions that mobile phone or car machine projects will support. There are also some test items, such as screen projection, arhud, etc., which can be added to the list even if they are not platform-specific functional tests. The purpose is to cover all test items. For the test plan of the test items, you can refer to the plan of the above patent document and design different plans in combination with your own design requirements and quality requirements. This patent does not focus on the implementation of the plan for specific test items. Each interface is a separate code file.

[0116] In this embodiment, all test items are automated as much as possible. For example, in Wi-Fi testing, the system turns on Wi-Fi, searches for hotspots, and searches for Wi-Fi in both the 2.4G and 5G frequency bands. The signal strength must be above a certain level for the test to be considered passed. For example, in a camera test, the system turns on the camera, automatically captures and saves a screenshot to verify whether an image is displayed. The screenshot can then be exported and viewed using a USB drive. The system then turns off the camera and exits the test interface. For example, in a USB test, a photo with a specified file name in the root directory of the USB drive is displayed in the interface. If the file exists, the manual test passes. I will not go into detail about each test item; the examples are provided to illustrate that all test items supported by the current system are automated through direct or indirect solutions. If an operator is watching, the operator can see the information through interface displays and prompts. If no operator is watching, all automated test items will also save screenshots, logs, test results, and other information to log files, which can then be exported and viewed when an operator intervenes. Therefore, all test items in this case can be automated with or without personnel. Automated testing can greatly save manpower, speed up testing, and improve testing efficiency, which helps developers deal with bugs in advance and speed up the development cycle. It also meets the design requirements of many scenarios, such as automation of production lines and laboratories. In scenarios beyond the requirements, automating all processes can also reduce the learning costs of operators and the communication costs of operators in different scenarios.

[0117] Example 2: Example 2 of the present invention applies the above-mentioned specific implementation plan to an App, provides an App interface, and sets the type of test task to run by number by configuring parameters. "Startup" can be checked, the log is stored locally, and the camera screenshot is stored in USB3. The number of tests is 10,000 times, and the interval between each test is 2 minutes. The interval can also be set to seconds. After the test starts, you can view the detection status, current number of tests, remaining number of tests, remaining time interval, log storage location and other information. For the test items, double-click "USB3.0 Detection" first, then double-click "USB3.0 Music Detection", then double-click "T-BOX Audio Detection", and then double-click "Bluetooth Detection". The test sequence is arranged and tested in the order of double-clicking. Click "Start Detection" to start the test.

[0118] Check in the App interface again, and set the test task type to run by time by configuring the parameters. "Startup" can be checked, the log is stored locally, and the camera screenshot is stored in USB3. The test time is 10,000 minutes, and the interval between each test is 4 minutes. Each test item requires an estimated time. According to the sum of the estimated time for each test item, a minimum time interval is preset to ensure that all test items can be tested and completed. After the test starts, you can view the detection status, elapsed time, remaining time for this round of detection, and the current number of detections, so that the operator can intuitively record information, log storage location and other information. For the test items, double-click "USB3.0 Detection" first, then double-click "USB3.0 Music Detection", then double-click "T-BOX Audio Detection", and then double-click "Bluetooth Detection". The test sequence is arranged and tested in the order of double-clicking. Click "Start Detection" to start the test.

[0119] The two different test solutions described above essentially meet the diverse needs of vehicle computers across multiple scenarios, including production, testing, laboratory, development, debugging, testing, durability, stability, mass production, and after-sales. These test solutions for different scenarios are flexible, reliable, simple, easy to operate, and save labor costs.

[0120] Based on the same inventive concept, the present application also provides an automated testing device for an Android vehicle system for implementing the aforementioned automated testing method for an Android vehicle system. The solution provided by this device is similar to the solution described in the aforementioned method. Therefore, the specific limitations of the following embodiments for completing one or more missing data can be found in the above-mentioned limitations of the missing data completion method and will not be repeated here.

[0121] In one embodiment, Figure 3 As shown, an automated testing device based on an Android vehicle system is provided, comprising: a task formulation module 210, a testing module 220, a verification module 230 and an acquisition module 240, wherein:

[0122] A task formulation module 210 is used to define test tasks under multiple scenarios, wherein the test tasks include multiple test items under different scenarios;

[0123] The test module 220 is used to send test items under different scenarios to the test database, call the test files corresponding to each scenario, and perform automated testing on all test items under the same test task type;

[0124] A verification module is used to determine the difference between the initial values ​​of the configuration parameters obtained under the preset constraints and the configuration parameters obtained during the test, generate test results, and store them in a test database;

[0125] The acquisition module is used to obtain the test results of the to-be-tested item from the test database in response to at least one to-be-tested item in a target scenario selected by the user terminal from multiple test tasks; and generate a performance evaluation report according to the test results.

[0126] In one embodiment, a computer device is provided, comprising a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the steps of any one of the methods in the first aspect are implemented.

[0127] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, memory, a communication interface, a display screen, and an input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The communication interface of the computer device is used to communicate with an external terminal via wired or wireless communication. The wireless communication can be achieved via Wi-Fi, a mobile cellular network, NFC (near-field communication), or other technologies. When executed by the processor, the computer program implements an automated testing method based on an Android vehicle system. The display screen of the computer device can be a liquid crystal display or an electronic ink display. The input device of the computer device can be a touch layer covering the display screen, or keys, a trackball, or a touchpad provided on the computer device housing, or an external keyboard, touchpad, or mouse.

[0128] Those skilled in the art will understand that Figure 4 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0129] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0130] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the above-mentioned embodiments. In particular, any reference to memory, database, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The databases involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processors involved in the various embodiments provided herein may be, but are not limited to, general-purpose processors, central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), programmable logic devices (PLDs), data processing logic devices based on quantum computing, and the like.

[0131] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0132] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. An automated testing method based on an Android vehicle system, characterized in that: The method comprises: Defining test tasks under multiple scenarios, wherein the test tasks include multiple test items under different scenarios; Send test items under different scenarios to the test database, call the test files corresponding to each scenario, and perform automated testing on all test items under the same test task type; Based on the initial values ​​of the configuration parameters obtained under the preset constraints, the difference between the configuration parameters obtained during the test is judged, the test results are generated, and stored in the test database; In response to a to-be-tested item in at least one target scenario selected by a user terminal from a plurality of test tasks, a test result of the to-be-tested item is acquired from the test database; and a performance evaluation report is generated according to the test result.

2. The method according to claim 1, characterized in that The definition of the test task includes: accessing the interface, configuring the interface parameters according to different scenario requirements, and setting the test task type; Establish test items in multiple scenarios according to the set test task type; Among them, the test items include functional test items and routine test items; the performance test items include PCB test, whole machine test, and baking test; the routine test items include USB test, USB music test, camera test, Bluetooth test, WiFi test, screen projection test and mic test on the car side.

3. The method according to claim 2, characterized in that The test task types include number test tasks and time test tasks.

4. The method according to claim 1, wherein The sending of test items under different scenarios to the test database and calling the test files corresponding to each scenario to perform automated testing on all test items under the same test task type includes: In the designated area of ​​the interface, test tasks under different scenario requirements are displayed; Arrange the names of all test items included in the test task and generate a test item list after sorting; Use a pre-set language to write a script to read the test item list, and use the pre-established automated testing platform to test the test items from the top of the test item list in sequence until the execution is completed according to the configured parameters or stopped midway; When executing a test task, the test item to be tested is selected and then the test is started. All test items are tested individually according to the pre-set order. After the test is completed, the test results are recorded and the next test item is jumped to. If no operation is performed, after all test tasks are executed according to the configuration parameters, the test ends normally and the configuration parameters are passed to the code; During the test, the control status is read and the first action instruction is triggered to detect whether the test task stops executing; If the first action instruction is triggered again, a new test task is created; if the first action instruction is triggered after the configuration parameters are modified, a new test task is created according to the new configuration parameters; If the second action instruction is triggered during the test, the next round of testing of the test task will be started directly; and after the test is completed, the test results will be verified to be valid by comparing the configuration parameters obtained from the test with the initial values ​​of the configuration parameters.

5. The method according to claim 4, characterized in that The pre-establishment of the automated test platform includes: Use SDK tools to parse configuration parameters, obtain control information and status information of the interface elements to be tested, and store relevant records of the information in the test database for script calls; Read the test files used to execute the test tasks in the test database, read the contents of the test files one by one, and convert them into variables in the script; wherein the test files are code files formulated by the test plans of different stages from production to R&D to mass production to after-sales; Set up the interface calling module to call the CAN interface and complete the initial value of the configuration parameters based on the preset constraints. Set up and complete the sending and receiving of corresponding message data according to test requirements; Acquire the message data transmitted by the CAN interface; analyze the action instructions of the vehicle end contained in the message data; wherein the machine Action commands on the vehicle side include click, slide, long press and read status; According to the set configuration test parameters, complete the message data sending and receiving, interface configuration, data acquisition, automated testing and test verification process.

6. The method according to claim 5, characterized in that The reading of the test files in the test database for executing the test task includes: Compiling a header file, and setting breakpoint information for generating at least one snapshot file in the header file; Compiling the test program; The header file and the test program are encapsulated to obtain the test file to test the test item; wherein the test file includes the header file and the test program; wherein the header file includes breakpoint information for generating at least one snapshot file.

7. The method according to claim 5, characterized in that The preset constraints include: Environmental constraints, used to specify the ambient temperature range of the test item; Functional constraints, which are used to specify product functionality and quality; Format constraints are used to specify the file format of the test item.

8. The method according to claim 1, characterized in that The obtaining of the test results of the test items from the test database and generating the performance evaluation report according to the test results includes: obtaining the test results of each test item in the test item list; Generate log files based on relevant screenshots, logs, and test result verification information obtained during the automated testing process for all test items.

9. An automated testing device based on an Android vehicle system, characterized in that: include: A task formulation module is used to define test tasks under multiple scenarios, wherein the test tasks include multiple test items under different scenarios; The test module is used to send test items under different scenarios to the test database, call the test files corresponding to each scenario, and perform automated testing on all test items under the same test task type; A verification module is used to determine the difference between the initial values ​​of the configuration parameters obtained under the preset constraints and the configuration parameters obtained during the test, generate test results, and store them in a test database; an acquisition module, configured to acquire, from the test database, a test result of a to-be-tested item in at least one target scenario selected by a user terminal from a plurality of test tasks; A performance evaluation report is generated according to the test results.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

Images