Device testing method, electronic device, storage medium, and program product

Abstract

The device testing method, electronic device, storage medium, and program product provided in this application divide the test task into multiple test stages and release the test resources occupied by the test stage immediately after the completion of each test stage. This allows the released resources to be used immediately to execute other test tasks, shortens the idle time of test resources, improves the overall utilization rate of test resources, and enables more test tasks to be completed under the same resource conditions, thereby improving test efficiency.

Description

Technical Field

[0001] This application relates to the field of computers, and more particularly to a device testing method, electronic equipment, storage medium, and program product. Background Technology

[0002] During the production of equipment (such as terminals, chip modules, etc.), it is necessary to test and verify its functional stability, performance and compatibility.

[0003] In related technologies, human involvement is required in test decision-making. For example, when a new test task arrives, the tester issues the new test task to the test system, so that the test resources required for the test task can be used to measure the test task. In order to avoid the preemption of test resources, only one test task can be executed in each test cycle, resulting in low test efficiency. Summary of the Invention

[0004] This application provides device testing methods, electronic devices, storage media, and program products to improve device testing efficiency.

[0005] In a first aspect, embodiments of this application provide a device testing method, including...

[0006] The acquisition module is used to acquire task information for multiple test tasks. Each test task includes multiple test phases, and each test task is used to test one device under test.

[0007] The processing module is used to execute multiple test phases of any test task based on the task information of the test task, and obtain the test results. When any test phase is completed, the test resources of the test phase are released, and the released test resources are used to execute other test tasks among the multiple test tasks.

[0008] In one possible implementation, the multiple testing phases of the test task include a test execution phase, a monitoring phase, and a result analysis phase; the task information of the test task includes the test script of the test execution phase and information on the test resources required by the test task.

[0009] Based on the task information of the test task, multiple test phases of the test task are executed to obtain test results, including:

[0010] Based on the information about the test resources required by the test task, when entering the test execution phase of the test task, the test resources required by the test task are allocated to the test execution phase, and the test script is executed;

[0011] After the test script is executed successfully, the resources required for the test execution phase are released, and the monitoring phase of the test task is executed. The monitoring phase takes up a preset monitoring duration.

[0012] When the duration of the monitoring phase reaches the preset monitoring duration, the resources required for the monitoring phase are released, and the result analysis phase is executed.

[0013] After the result analysis phase is successfully executed, the test results are obtained.

[0014] In one possible implementation, the monitoring phase of performing the test task includes:

[0015] The test device corresponding to the test task is checked for abnormalities at preset time intervals; if so, an abnormality report is generated.

[0016] Output the aforementioned exception report.

[0017] In one possible implementation, the result analysis phase includes:

[0018] The state of the device under test is analyzed to obtain state information;

[0019] Output the status information.

[0020] In one possible implementation, the method further includes:

[0021] For any test phase, either the monitoring phase or the results analysis phase, the timer corresponding to that test phase is started when the test phase is entered.

[0022] When the timer's duration is greater than or equal to the preset duration, the test phase ends and the resources required for the test phase are released.

[0023] In one possible implementation, the method further includes:

[0024] After any test phase of the current test task is completed, a first test task is determined. The first test task is one of the test tasks to be tested among the plurality of test tasks. The test resources required by the first test task are matched with the test resources of the released test phase.

[0025] Allocate test resources for the test phase to the first test task to execute the first test task.

[0026] Secondly, embodiments of this application provide a device testing apparatus, comprising:

[0027] The acquisition module is used to acquire task information for multiple test tasks. Each test task includes multiple test phases, and each test task is used to test one device under test.

[0028] The processing module is used to execute multiple test phases of any test task based on the task information of the test task, and obtain the test results. When any test phase is completed, the test resources of the test phase are released, and the released test resources are used to execute other test tasks among the multiple test tasks.

[0029] In one possible implementation, the multiple testing phases of the test task include a test execution phase, a monitoring phase, and a result analysis phase; the task information of the test task includes the test script of the test execution phase and information on the test resources required by the test task.

[0030] The processing module is specifically used for:

[0031] Based on the information about the test resources required by the test task, when entering the test execution phase of the test task, the test resources required by the test task are allocated to the test execution phase, and the test script is executed;

[0032] After the test script is executed successfully, the resources required for the test execution phase are released, and the monitoring phase of the test task is executed. The monitoring phase takes up a preset monitoring duration.

[0033] When the duration of the monitoring phase reaches the preset monitoring duration, the resources required for the monitoring phase are released, and the result analysis phase is executed.

[0034] After the result analysis phase is successfully executed, the test results are obtained.

[0035] In one possible implementation, the processing module is specifically used for:

[0036] The test device corresponding to the test task is checked for abnormalities at preset time intervals; if so, an abnormality report is generated.

[0037] Output the aforementioned exception report.

[0038] In one possible implementation, the processing module is specifically used for:

[0039] The state of the device under test is analyzed to obtain state information;

[0040] Output the status information.

[0041] In one possible implementation, the processing module is also used for:

[0042] For any test phase, either the monitoring phase or the results analysis phase, the timer corresponding to that test phase is started when the test phase is entered.

[0043] When the timer's duration is greater than or equal to the preset duration, the test phase ends and the resources required for the test phase are released.

[0044] In one possible implementation, the processing module is also used for:

[0045] After any test phase of the current test task is completed, a first test task is determined. The first test task is one of the test tasks to be tested among the plurality of test tasks. The test resources required by the first test task are matched with the test resources of the released test phase.

[0046] Allocate test resources for the test phase to the first test task to execute the first test task.

[0047] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0048] The memory stores computer-executed instructions;

[0049] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0050] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0051] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0052] The device testing method, electronic device, storage medium, and program product provided in this application divide the test task into multiple test stages and release the test resources occupied by the test stage immediately after the completion of each test stage. This allows the released resources to be used immediately to execute other test tasks, shortens the idle time of test resources, improves the overall utilization rate of test resources, and enables more test tasks to be completed under the same resource conditions, thereby improving test efficiency. Attached Figure Description

[0053] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0054] Figure 1 This is a schematic diagram of the structure of a test system as exemplified by an embodiment of this application;

[0055] Figure 2 A flowchart illustrating a device testing method provided in this application;

[0056] Figure 3 This is a schematic diagram illustrating the execution of multiple test tasks as an example of an embodiment of this application;

[0057] Figure 4 A flowchart illustrating another device testing method provided in this application;

[0058] Figure 5 A schematic diagram of the equipment testing device provided in this application;

[0059] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0060] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0061] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0062] In related technologies, equipment testing can be achieved through the following methods:

[0063] Method 1: Semi-automated testing system based on manual scheduling

[0064] Testers manually configure test tasks and bind them to test resources (such as physical test machines). For example, when a new test task arrives, the tester issues a new test task to the test system. The test system then uses the test resources required by the test task to measure it. To avoid preemption of test resources, only one test task can be executed in each test cycle, resulting in low test efficiency.

[0065] For example, testers need to rely on experience to determine the availability of test resources and manually allocate test tasks. The execution order of test tasks and resource allocation depend on manual decisions, lacking dynamic detection of test resource conflicts.

[0066] Method 2: Automated testing system based on static rules

[0067] Test scheduling is implemented based on preset rules (such as a fixed number of test resources, fixed test case priorities, etc.). However, the following drawbacks exist:

[0068] Test resource conflict: When multiple test tasks run simultaneously, they may die or fail due to competition for the same test resources (such as hardware devices or network ports).

[0069] Rigid task scheduling: The scheduling strategy cannot be adjusted according to the dynamic needs of test tasks (such as the differences in resource consumption in different test phases), resulting in low resource utilization.

[0070] Lack of lifecycle management: Throughout the entire lifecycle of a test task, from creation to destruction, the allocation and release of test resources are not managed in stages, which can easily lead to the blockage of subsequent tasks due to untimely release of resources.

[0071] Therefore, this application provides a device testing method. This application divides the testing task into multiple testing stages and releases the testing resources occupied by the testing stage immediately after the completion of each testing stage. This allows the released resources to be used immediately to execute other testing tasks, shortens the idle time of testing resources, improves the overall utilization rate of testing resources, and enables more testing tasks to be completed under the same resource conditions, thereby improving testing efficiency.

[0072] Correspondingly, this application proposes a testing system. Figure 1 This is a schematic diagram of the structure of a test system 10, which is an example of an embodiment of this application. The test system 10 includes a task management system 101, a web page front-end 102, and a task database 103.

[0073] The web page front-end 102 can be used to view the status and information of test tasks arranged or not arranged by testers. Testers can send multiple test tasks to the task management system 101 with one click through the web page front-end 102. Each test task is used to test one device under test. The task database 103 stores the task information of the test tasks.

[0074] The task management system 101 receives instruction information about the test task sent by the web front-end 102. The task management system 101 can obtain task information about the test task from the task database 103, and then allocate test resources and start the test task according to the task information.

[0075] Specifically, the task management system 101 can divide the test task into multiple test phases and release the test resources occupied by the test phase immediately after the completion of each test phase, so that the released resources can be used immediately to execute other test tasks.

[0076] In this embodiment of the application, the device under test may be a terminal device or a chip module, etc.

[0077] The embodiments of this application can be used in testing scenarios for devices such as terminal devices and chip modules. Terminal devices include smartphones, tablets, and IoT devices running operating systems such as Android and Linux; chip modules include hardware components such as communication modules, baseband chips, and radio frequency chips. In actual R&D and production processes, these terminal devices and chip modules need to be tested to verify their functional stability, performance, and compatibility.

[0078] For example, when testing terminal devices, in the Android system, it is necessary to test application compatibility, system crash rate, hardware driver stability, etc.; in the Linux system, it is necessary to verify kernel stability, peripheral driver compatibility, etc.

[0079] For chip module testing, it is necessary to test communication protocol consistency, radio frequency performance, power consumption, etc.

[0080] In the above scenarios, testing tasks typically require testing resources, which may include, for example, multiple test machines (personal computers (PCs), test servers, etc.) as well as software environments, network configurations, etc.

[0081] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0082] Figure 2 This application provides a flowchart illustrating a device testing method applied to a device testing apparatus, which may be, for example, a server. Specifically, this method can be applied to, for example... Figure 1 The task management system shown is as follows: Figure 2 As shown, the method includes:

[0083] S201. Obtain task information for multiple test tasks, each test task including multiple test phases.

[0084] Each test task is used to test one device under test.

[0085] In one possible implementation, the multiple testing phases may include a test execution phase, a monitoring phase, and a results analysis phase.

[0086] The test execution phase refers to the execution of the test scripts for a test task. For example, the corresponding test suite or test tool can be automatically selected based on the test type (such as stress test, compatibility test, performance test) in the task information; the test script can be deployed to the test PC; and then test execution can be started.

[0087] In one possible implementation, during the test execution phase, each small step (such as the steps mentioned above) can be automatically checked for anomalies (such as application crashes, unresponsive interfaces, etc.); if an anomaly is found, a preset strategy is used to determine whether to send back intermediate data or send an email to notify the testers.

[0088] The monitoring phase involves collecting the hardware and software status of the device under test (DUT) at preset time intervals (e.g., every 6 hours) to detect any anomalies in the DUT corresponding to the test task. This includes checking for system restarts, complete machine restarts, whether the Secure Digital Memory Card (SD) card has been uninstalled, whether the Subscriber Identity Module Card (SIM) card has lost connection, memory leaks, and whether the Central Processing Unit (CPU) temperature is too high. If an anomaly is detected, an anomaly report can be generated and output to alert the testers.

[0089] The results analysis phase is a comprehensive and in-depth analysis of the device under test's status. For example, this includes: retrieving all log files collected during the entire test from the task database, and parsing system logs (logcat), kernel logs (dmesg), crash logs (tombstone), etc., to perform a series of functional checks, such as verifying whether the phone function is normal, whether SMS sending and receiving is normal, whether the WiFi connection is stable, and whether Bluetooth scanning is available; comparing all problems found with a known problem database to avoid duplicate submissions; automatically generating status information for newly confirmed problems, and outputting the status information (including log fragments, reproduction steps, environment information, etc.).

[0090] In one possible implementation, the results analysis phase can be completed offline, meaning it does not occupy the device under test and only relies on offline computing resources.

[0091] In one possible implementation, the test execution phase also includes a version download process, which involves downloading the firmware, system image, or application installation package of the device under test required for this test to the test PC and completing the writing or installation process.

[0092] In one possible implementation, after obtaining task information for multiple test tasks, the server can allocate test resources to any one of the test tasks, or allocate test resources to the highest priority test task according to the priority of the multiple test tasks, so that the test resources occupied by the test task in a certain test phase can be released and used for other test tasks.

[0093] S202. For any test task, execute multiple test phases of the test task according to the task information of the test task to obtain test results. For any test phase, when the test phase is completed, the test resources of the test phase are released and the released test resources are used to execute other test tasks in the multiple test tasks.

[0094] Specifically, for any test task, the server can execute each test stage according to the task information of the test task and in the execution order of multiple test stages. The execution order of multiple test stages is from front to back as follows: test execution stage → monitoring stage → result analysis stage.

[0095] The test results may include data generated after each test phase is completed, such as success or failure flags, generated log files, collected performance metrics, and exception information.

[0096] In one possible implementation, before executing each test phase, the server can check the availability of the required test resources for that phase. If the required test resources are available, the server can allocate the resources and initiate the phase execution logic; otherwise, it enters a waiting state until the resources are ready. During the execution of each test phase, the server can continuously monitor the execution status, logging key steps and output data. When a phase is completed (whether successfully or not), the system saves the execution result to the task status record and then continues processing the next test phase. After all phases are completed, the system summarizes the test results of each test phase to form a complete test report for the test task.

[0097] Once a test phase is completed, the server immediately triggers the resource release process for that test phase. For example, the release process includes checking which resources are currently occupied by the test phase; this information was recorded in the resource allocation table when the test phase started. Then, the server updates the status of these resources from "occupied" to "idle" one by one and clears the corresponding occupied record from the resource allocation table.

[0098] Once the test resources are released, the server can identify all test tasks that are currently waiting, especially those that are waiting for these resources.

[0099] In one possible implementation, the server can select a suitable test task from the waiting queue based on the priority and waiting time of the test tasks. If the released resources happen to meet the resource requirements of that stage, the server can allocate the resources to that test task. In this way, resources are rapidly transferred between different tasks. Taking a PC as an example: it is first used by task A for the test execution phase (about 10 minutes), and the device is released after task A completes; then it is immediately used by task B for its test execution phase (about 15 minutes), and the device is released after task B completes; then it is used by task C for the version download process of the test execution phase (about 5 minutes). After task A releases the PC, its monitoring phase (6 hours) and result analysis phase (10 minutes) run in the background without occupying the PC. In this way, compared with related technologies that release test resources only after the entire test task is completed, a single PC can serve the test phases of multiple tasks within 6 hours, thus improving resource utilization.

[0100] In one possible implementation, the server can execute multiple test tasks sequentially according to a queue. For example, if the queue of test tasks is Task 1, Task 2, and Task 3, the server can execute Task 1 first. For instance, after the resources for the test execution phase of Task 1 are released, the server can allocate those resources to Task 2 to execute Task 2.

[0101] In one possible implementation, the server can determine the first test task after any test phase of the current test task has been completed. The first test task is one of a plurality of test tasks to be tested, and the test resources required by the first test task match the test resources of the released test phase. Then, the test resources of that test phase are allocated to the first test task to execute it.

[0102] In other words, it is not necessary to execute according to the queue of test tasks. Instead, test tasks that match the test resources released in the current test task can be executed, so that the released resources can be used in a timely manner and improve resource utilization.

[0103] The above "matching" can be understood as the test resources required by the first test task matching all the test resources released in the test phase, or the test resources required by the first test task matching a portion of the test resources released in the test phase, that is, the portion of resources can be used as the test resources required by the first test task.

[0104] For example, Figure 3 This is a schematic diagram illustrating the execution of multiple test tasks as an example of an embodiment of this application. In each test phase, when the test phase ends, the server can obtain an update of the information indicating the end of the test phase. That is, the information can be used to indicate the completion of the test phase. For example, the information can be the status of the test phase, such as "completed".

[0105] In this embodiment, by acquiring task information of multiple test tasks, for any one test task, multiple test phases of the test task are executed according to the task information of the test task to obtain test results. For any one test phase, when the test phase is completed, the test resources of the test phase are released. The released test resources are used to execute other test tasks among the multiple test tasks, which shortens the idle time of test resources, improves the overall utilization rate of test resources, and allows more test tasks to be completed under the same resource conditions, thereby improving test efficiency.

[0106] In one possible implementation, the task information for the test task includes the test script for the test execution phase and information about the test resources required by the test task.

[0107] The information on the test resources required for the test task may include resource information such as the device under test, test tools, storage logs, network communication, auxiliary services, occupancy mode, and time parameters, which is used to schedule the server to accurately allocate and release resources for each test phase of the test task.

[0108] The following section explains how the server controls each stage of the test task.

[0109] Figure 4 This application provides a flowchart illustrating another device testing method applied to a device testing apparatus, which may be, for example, a server. Specifically, this method can be applied to, for example... Figure 1 The task management system shown is as follows: Figure 4 As shown, the method includes:

[0110] S401. When entering the test execution phase of a test task, allocate the test resources required for the test task and execute the test script.

[0111] When the server receives a test task, it can allocate the necessary test resources for the test execution phase based on the information of the test resources required by the test task, and then execute the test script.

[0112] For example, resource allocation adopts a transactional approach, meaning that the task can only enter the execution state after all required resources are successfully allocated; if the allocation of any resource fails, the already allocated portion will be immediately rolled back and released, and the test task will remain in a waiting state. After successful resource allocation, the server can bind the device under test to the test tool instance and deploy the test script to the test PC. The server can then start the execution of the test script to perform the test.

[0113] In one possible implementation, if an exception occurs during the execution of the test script (such as application crash, device disconnection, etc.), the server can decide whether to retry, skip, or terminate the entire test task based on a preset exception handling strategy.

[0114] S402. After the test script is executed successfully, release the resources required for the test execution phase and execute the monitoring phase of the test task. The monitoring phase takes up the preset monitoring time.

[0115] For example, after the test script executes successfully, the server triggers resource release during the test execution phase. Then, at the start of the monitoring phase, the server can start a scheduled task on the test PC to check for anomalies in the device under test according to a preset monitoring cycle (e.g., every 6 hours). Throughout the monitoring phase, the test resources required for the test execution phase have been released back to the resource pool and can be used by other test tasks for their test execution phases.

[0116] The monitoring phase occupies a preset monitoring duration, which is longer than the monitoring cycle duration. In other words, the preset monitoring duration can include multiple monitoring cycles.

[0117] S403. When the monitoring phase reaches the preset monitoring duration, release the resources required for the monitoring phase and execute the result analysis phase.

[0118] The server can continuously record the duration of the monitoring phase and compare it with the preset monitoring duration. When the cumulative monitoring duration reaches or exceeds the preset duration, the server can execute the resource release process required for the monitoring phase. After the resource release for the monitoring phase is completed, the results analysis phase can begin.

[0119] S404. After the results analysis phase is successfully executed, the test results are obtained.

[0120] It is understandable that the test results include the results of each test phase, including the test execution phase, the monitoring phase, and the results analysis phase.

[0121] In this embodiment, by controlling each testing stage and releasing resources, the utilization rate and turnover efficiency of testing resources are improved, the waiting and blocking between testing tasks are reduced, and pipelined parallel processing of multiple tasks is realized, solving the problems of resource idleness and low testing efficiency caused by the exclusive use of testing resources in related technologies.

[0122] In one possible implementation, for any test phase, either the monitoring phase or the results analysis phase, a timer is started upon entering that test phase. When the timer's duration is greater than or equal to a preset duration, the test phase ends, and the resources required by that test phase are released. This can prevent a test phase from having its resources occupied for an extended period due to a task crash, thus affecting the execution of other test tasks.

[0123] Figure 5 The schematic diagram of the equipment testing device provided in this application is as follows: Figure 5 As shown, the device testing apparatus 50 provided in this embodiment includes:

[0124] The acquisition module 501 is used to acquire task information for multiple test tasks. Each test task includes multiple test stages, and each test task is used to test one device under test.

[0125] The processing module 502 is used to execute multiple test phases of any test task according to the task information of the test task, and obtain test results. For any test phase, when the test phase is completed, the test resources of the test phase are released, and the released test resources are used to execute other test tasks among the multiple test tasks.

[0126] In one possible implementation, the multiple testing phases of the test task include a test execution phase, a monitoring phase, and a result analysis phase; the task information of the test task includes the test scripts for the test execution phase and information on the test resources required by the test task.

[0127] Processing module 502 is specifically used for:

[0128] Based on the information about the test resources required by the test task, allocate the test resources required by the test task to the test execution phase when entering the test execution phase of the test task, and execute the test script.

[0129] After the test script executes successfully, the resources required for the test execution phase are released, and the monitoring phase of the test task is executed. The monitoring phase takes up the preset monitoring duration.

[0130] When the monitoring phase reaches the preset monitoring duration, release the resources required for the monitoring phase and proceed to the results analysis phase.

[0131] After the results analysis phase is successfully executed, the test results are obtained.

[0132] In one possible implementation, processing module 502 is specifically used for:

[0133] The test device is checked at preset time intervals to see if any abnormalities occur; if so, an abnormality report is generated.

[0134] Output an exception report.

[0135] In one possible implementation, processing module 502 is specifically used for:

[0136] The status of the device under test is analyzed to obtain status information.

[0137] Output status information.

[0138] In one possible implementation, the processing module 502 is further configured to:

[0139] For either the monitoring phase or the results analysis phase, start the timer corresponding to the test phase when entering the test phase.

[0140] When the timer's duration is greater than or equal to the preset duration, the test phase ends and the resources required for the test phase are released.

[0141] In one possible implementation, the processing module 502 is further configured to:

[0142] After any test phase of the current test task is completed, the first test task is determined. The first test task is one of the test tasks to be tested among multiple test tasks, and the test resources required by the first test task are matched with the test resources of the released test phase.

[0143] Allocate test resources for the first test task during the testing phase to execute the first test task.

[0144] The device testing apparatus provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0145] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6As shown, the electronic device 60 provided in this embodiment includes at least one processor 601 and a memory 602. Optionally, the device 60 further includes a communication component 603. The processor 601, memory 602, and communication component 603 are connected via a bus 604.

[0146] In a specific implementation, at least one processor 601 executes computer execution instructions stored in memory 602, causing at least one processor 601 to perform the above-described method.

[0147] The specific implementation process of processor 601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0148] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0149] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0150] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0151] In one possible implementation, the electronic device can be a vehicle or a control component within a vehicle, and this application does not limit this.

[0152] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0153] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0154] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0155] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0156] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0157] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0158] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0159] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0160] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0161] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A device testing method, characterized by, include: Obtain task information for multiple test tasks. Each test task includes multiple test phases, and each test task is used to test one device under test. For any test task, multiple test phases of the test task are executed according to the task information of the test task to obtain test results. For any test phase, when the test phase is completed, the test resources of the test phase are released, and the released test resources are used to execute other test tasks among the multiple test tasks.

2. The method of claim 1, wherein, The test task includes multiple test phases, including a test execution phase, a monitoring phase, and a result analysis phase; the test task information includes the test script for the test execution phase and information on the test resources required by the test task. Based on the task information of the test task, multiple test phases of the test task are executed to obtain test results, including: Based on the information about the test resources required by the test task, when entering the test execution phase of the test task, the test resources required by the test task are allocated to the test execution phase, and the test script is executed; After the test script is executed successfully, the resources required for the test execution phase are released, and the monitoring phase of the test task is executed. The monitoring phase takes up a preset monitoring duration. When the duration of the monitoring phase reaches the preset monitoring duration, the resources required for the monitoring phase are released, and the result analysis phase is executed. After the result analysis phase is successfully executed, the test results are obtained.

3. The method of claim 2, wherein, The monitoring phase of executing the test task includes: The test device corresponding to the test task is checked for abnormalities at preset time intervals; if so, an abnormality report is generated. Output the aforementioned exception report.

4. The method of claim 2, wherein, The results analysis phase includes: The state of the device under test is analyzed to obtain state information; Output the status information.

5. The method according to any one of claims 2 to 4, characterized in that, The method further includes: For any test phase, either the monitoring phase or the results analysis phase, the timer corresponding to that test phase is started when the test phase is entered. When the timer's duration is greater than or equal to the preset duration, the test phase ends and the resources required for the test phase are released.

6. The method according to any one of claims 1 to 4, characterized in that, The method further includes: After any test phase of the current test task is completed, a first test task is determined. The first test task is one of the test tasks to be tested among the plurality of test tasks. The test resources required by the first test task are matched with the test resources of the released test phase. Allocate test resources for the test phase to the first test task to execute the first test task.

7. An apparatus testing device, characterized by include: The acquisition module is used to acquire task information for multiple test tasks. Each test task includes multiple test phases, and each test task is used to test one device under test. The processing module is used to execute multiple test phases of any test task according to the task information of the test task, and obtain test results. When any test phase is completed, the test resources of the test phase are released, and the released test resources are used to execute other test tasks among the multiple test tasks.

8. An electronic device, comprising: include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

10. A computer program product, characterised in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-6.

Images