Test method, device, equipment and system of electronic device and storage medium

Abstract

The invention provides an electronic device testing method, device, equipment and system and a storage medium. The method relates to the technical field of product testing, and comprises the following steps: obtaining a test demand of a target device, the test demand comprising an identifier of the target device or an identifier of a work station to which the target device belongs, obtaining a corresponding target test case from a case storage platform in which a plurality of different device test cases are pre-stored, and obtaining corresponding target test parameters from a parameter storage platform in which a plurality of different device test parameters are pre-stored, generating a target test task according to the target test case and the target test parameters, and testing the target device. According to the method, independent development of special test programs for electronic devices of different models and versions can be reduced, reuse of test cases and test parameters and rapid adaptation of product iteration are realized through a centralized resource management platform, the development and maintenance cost is reduced, the overall test efficiency of the electronic devices is remarkably improved, and the test efficiency of the electronic devices is improved. And the requirements of large-scale production and multi-model rapid adaptation are met.

Description

Technical Field

[0001] This application relates to the field of product testing technology, and in particular to a testing method, apparatus, equipment, system and storage medium for electronic devices. Background Technology

[0002] With the rapid development of intelligent driving technology, electronic components such as cameras, inertial measurement units, lidar, and domain controllers have become key parts of vehicle manufacturing, placing higher demands on the quality and efficiency of their production testing. To ensure the stability, accuracy, and consistency of products before they leave the factory, manufacturers typically need to conduct production testing on electronic components.

[0003] In related technologies, for any electronic device, it is usually necessary to develop a dedicated test program and configure specific test parameters and test cases to test the device. However, with the rapid iteration of intelligent driving technology, the increasing variety of product types, and the continuously shortening update cycle of different models and functional versions, the above-mentioned testing methods will reduce the overall testing efficiency of electronic devices. Summary of the Invention

[0004] This application provides testing methods, apparatus, equipment, systems, and storage media for electronic devices, which are used to improve the overall testing efficiency of electronic devices.

[0005] In a first aspect, this application provides a testing method for electronic devices, applied to a testing device, the method comprising:

[0006] Obtain the test requirements of the target device, wherein the test requirements include the identifier of the target device or the identifier of the workstation to which the target device belongs;

[0007] The target test cases corresponding to the test requirements are obtained from the test case storage platform, which stores test cases for multiple different devices.

[0008] The target test parameters corresponding to the test requirements are obtained from the parameter storage platform, which stores test parameters for multiple different devices.

[0009] Based on the target test cases and the target test parameters, generate the target test task;

[0010] The target device is tested according to the target test task.

[0011] In one possible implementation, the number of target test cases is multiple, and the step of generating target test tasks based on the target test cases and the target test parameters includes:

[0012] According to the preset business execution order, multiple target test cases are assembled to obtain the target test suite;

[0013] The values ​​of the target test parameters are filled into the corresponding parameters in the target test suite to generate the target test task.

[0014] In one possible implementation, if the number of target devices is at least one, the step of testing the target devices according to the target test task includes:

[0015] The target test tasks are loaded onto the actuators corresponding to each target device.

[0016] In response to a test start operation on any target device, the actuator corresponding to the target device is controlled to perform a target test task and test the target device.

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

[0018] Acquire test data, which includes test results of the at least one target device;

[0019] The test data is converted into a preset structure through a standardized data interface to obtain standardized test data after format conversion.

[0020] The standardized test data is synchronized to an external system for storage, and the external system includes at least one of a production execution system, a local database, and a remote cloud storage.

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

[0022] During the testing of the target device according to the target test task, multiple test infrastructures required by the target test task are accessed through the device control abstraction interface, and the multiple test infrastructures are coordinated through the resource manager.

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

[0024] During the testing of the target device according to the target test task, the execution status of the target test task is monitored;

[0025] When the execution status is abnormal, an exception alarm is triggered and an exception log is recorded.

[0026] Secondly, this application provides a testing apparatus for electronic devices, the apparatus comprising:

[0027] The infrastructure layer is used to implement driver encapsulation for underlying hardware devices and provide hardware interfaces for the domain layer.

[0028] The domain layer is used to encapsulate functions based on the hardware interfaces provided by the infrastructure layer, targeting the business needs of different target devices, generating reusable business function modules, and providing callable business interfaces for the export layer.

[0029] The export layer is used to collect the business interfaces provided by the domain layer, generate a set of functions, and provide a call entry point for the application layer and framework layer.

[0030] The application layer is used to classify and manage target test cases, and implement the business logic of specific test cases based on the call entry points provided by the export layer.

[0031] The framework layer is used to perform the methods described in any of the first aspects above.

[0032] Thirdly, this application provides a testing device, including: a processor and a memory;

[0033] The memory stores computer-executed instructions;

[0034] The processor executes computer execution instructions stored in the memory to implement the method as described in any of the first aspects.

[0035] Fourthly, this application provides a testing system for electronic devices, comprising: a cloud-based testing resource management center and the testing equipment described in the third aspect.

[0036] The cloud-based test resource management center includes a test case storage platform and a parameter storage platform. The test case storage platform stores test cases for multiple different devices, and the parameter storage platform stores test parameters for multiple different devices.

[0037] Fifthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any of the first aspects.

[0038] In a sixth aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the first aspects.

[0039] This application provides a testing method, apparatus, device, system, and storage medium for electronic devices. The testing equipment can acquire test requirements for a target device, including the identifier of the target device or the identifier of the workstation to which the target device belongs. It retrieves target test cases corresponding to the test requirements from a test case storage platform and target test parameters corresponding to the test requirements from a parameter storage platform. It then generates a target test task by combining the target test cases and target test parameters, and performs tests on the target device based on the target test task. In this process, through the centralized design of the test case storage platform and the parameter storage platform, the test logic and quantification standards of different electronic devices can be constructed into a standardized resource library. This allows for rapid matching and adaptation of new product test requirements based directly on the standardized content in the resource library. This effectively addresses the current situation of continuously enriching product types and shortening update cycles in the field of intelligent driving, significantly reducing the development cost and adjustment time of test programs, avoiding inefficiency caused by repetitive work, and thus improving the overall testing efficiency of electronic devices. Attached Figure Description

[0040] 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.

[0041] Figure 1 A schematic diagram illustrating the application scenarios provided in the embodiments of this application;

[0042] Figure 2 A schematic flowchart of an embodiment of the testing method for the electronic device provided in this application;

[0043] Figure 3 A schematic flowchart of Embodiment 2 of the test method for the electronic device provided in this application;

[0044] Figure 4 A schematic flowchart of Embodiment 3 of the test method for the electronic device provided in this application;

[0045] Figure 5 A schematic flowchart of Embodiment 4 of the test method for the electronic device provided in this application;

[0046] Figure 6 A schematic flowchart of Embodiment 5 of the test method for the electronic device provided in this application;

[0047] Figure 7 A schematic diagram of the structure of a testing apparatus for electronic devices provided in an embodiment of this application;

[0048] Figure 8 A schematic diagram of the layered architecture and components of the electronic device testing apparatus provided in the embodiments of this application;

[0049] Figure 9This is a schematic diagram of the structure of the test equipment provided in the embodiments of this application;

[0050] Figure 10 This is a schematic diagram of the structure of a testing system for electronic devices provided in an embodiment of this application.

[0051] 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

[0052] 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.

[0053] Figure 1 This is a schematic diagram illustrating an application scenario provided in an embodiment of this application. Please refer to [link / reference]. Figure 1 The testing process includes testing equipment and the electronic devices under test. The testing equipment and the electronic devices under test are connected via wired or wireless communication links. The testing equipment is used to perform functional and performance tests on the electronic devices. The electronic devices under test include core components for intelligent driving and in-vehicle electronics, specifically including various types such as cameras, LiDAR, domain controllers (DC), inertial measurement units (IMUs), and electronic control units (ECUs).

[0054] In related technologies, existing testing solutions for various electronic devices in the aforementioned scenarios involve developing dedicated test programs for each individual device's functional characteristics, requiring the configuration of specific test cases and parameters for each program. Due to the lack of a unified test development framework and standards, the test program logic for different devices cannot be reused, necessitating significant reinvestment of manpower for program development and debugging when new devices or feature versions are released. However, with the rapid iteration of intelligent driving technology, the types of electronic devices are continuously expanding, and the update cycles for different models and feature versions are constantly shortening. The aforementioned "one device, one dedicated program" testing approach results in extremely low efficiency in the development and reuse of test resources, insufficient flexibility and adaptability of the testing process, ultimately leading to a significant decrease in the overall testing efficiency of electronic devices, making it difficult to meet the quality inspection requirements of large-scale production.

[0055] To address the aforementioned issues, the inventors, while researching optimization schemes for electronic device testing, discovered that the core reason for the low efficiency of existing testing lies in the binding of test cases, test parameters, and dedicated programs, lacking a unified scheduling mechanism. The testing of various devices can essentially be broken down into standardized processes of requirement matching, resource scheduling, and task execution. Based on this, after numerous experiments, the inventors found that test resource reuse can be achieved through identifier association and centralized storage. Specifically, test requirements, including the target device identifier or its associated workstation identifier, are first obtained. Then, target test cases and target test parameters corresponding to these requirements are retrieved from a pre-built unified test case storage platform and parameter storage platform, respectively. This automatically generates target test tasks and executes the tests, eliminating the need to develop dedicated programs for individual devices. Through standardized resource scheduling and task generation processes, the problem of low test resource reuse is solved. Based on this, this application proposes a testing method for electronic devices to achieve standardization and automation in electronic device testing, thereby improving the overall testing efficiency of electronic devices.

[0056] 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.

[0057] The execution subject of the method embodiments of this application can be a test device or a test apparatus for electronic devices disposed within the test device. The test apparatus for electronic devices can be implemented by software or by a combination of software and hardware. The test apparatus for electronic devices can be a processor within the test device. For ease of understanding, the technical solution of this application will be described below using a test device as an example.

[0058] Figure 2 This is a schematic flowchart illustrating an embodiment of the testing method for the electronic device provided in this application. Please refer to [link / reference]. Figure 2 The method includes:

[0059] S201. Obtain the test requirements for the target device.

[0060] The target device is the electronic device that needs to be tested. In this step, test requirements, including key identification information, can be obtained. This key identification information can be the identifier of the target device or the identifier of the workstation to which the target device belongs.

[0061] The identifier for a target device can refer to information that uniquely identifies a single device or a specific type of device, such as model number or function type. For example, if the target device is camera A, then camera A's identifier could be "VC100". Here, VC is an abbreviation for the function type of camera (Video Camera), and the number 100 is the model number for this type of camera.

[0062] The identifier for the workstation to which the target device belongs can refer to information that uniquely identifies the test station where the target device is located, such as the workstation number and the workstation function type. For example, if the target device is camera A, the identifier for its workstation could be "CAM03". Here, CAM is an abbreviation for the camera test workstation function, and the number 03 is the workstation number.

[0063] Optionally, test requirements can be obtained through any of the following methods.

[0064] Method 1: Obtain from the Manufacturing Execution System (MES). For example, the test equipment can interface with the enterprise's MES system and automatically issue test requirements, including the target device identifier VC100 or the workstation identifier CAM03, based on the production plan.

[0065] Method 2: Obtain by scanning the graphic code of the target device. For example, the test equipment can scan the graphic codes such as QR codes and barcodes on the surface of camera A, automatically parse the key identification information stored in the graphic code, and generate corresponding test requirements.

[0066] Method 3: Manual input. For example, testers can manually input the target device identifier (such as VC100) or workstation identifier (such as CAM03) through the operation interface of the test equipment to trigger the generation of test requirements.

[0067] S202. Obtain the target test cases corresponding to the test requirements from the test case storage platform.

[0068] In this step, suitable target test cases can be obtained from the pre-built test case storage platform based on the key identification information (target device identifier or workstation identifier) ​​in the test requirements.

[0069] In one specific implementation, the test case storage platform is a standardized carrier for centrally managing the test logic of various electronic devices. It stores test cases for different devices such as cameras, LiDAR, ECUs, and domain controllers. Each test case clearly defines the core content such as the test operation steps, execution logic, and judgment dimensions, and supports cross-scenario reuse.

[0070] For example, if the key identification information in the test requirements is the target device identifier "VC100", the test equipment can automatically match the associated test cases in the test case storage platform to obtain target test case 1. Target test case 1 can be an image sharpness test. The image sharpness test can have clearly defined operational steps: Control camera A to start its image acquisition function; Acquire standard test card image data; Analyze image resolution and sharpness data; Compare with preset standards to determine whether the standard is met.

[0071] S203. Obtain the target test parameters corresponding to the test requirements from the parameter storage platform.

[0072] In this step, target test parameters that are compatible with the target test cases can be obtained from a pre-built parameter storage platform based on key identification information in the test requirements.

[0073] Similarly, the parameter storage platform serves as a standardized carrier for centrally managing the quantitative standards for testing various electronic devices. It stores test parameters for different devices such as cameras, LiDAR, ECUs, and domain controllers. These test parameters include performance thresholds, configuration information, and environmental parameters. Each test parameter is uniquely associated with a test case in the test case storage platform, supporting flexible updates based on device model and test case version to ensure the accuracy of the test standards.

[0074] For example, if the key identification information in the test requirements is the target device identifier "VC100", the test equipment can automatically match the associated test parameters in the parameter storage platform to obtain the target test parameter A. Among them, the target test parameter 1 corresponds to the target test case 1, and may specifically include an image resolution ≥1080P and a sharpness value ≥80%.

[0075] S204. Generate the target test task based on the target test cases and target test parameters.

[0076] In this step, the obtained target test cases and target test parameters can be integrated to generate a complete and directly executable target test task.

[0077] In one specific implementation, the values ​​of the target test parameters can be filled into the parameters corresponding to the target test cases to generate the target test task. Specifically, the execution order, operation steps, and judgment dimensions of the target test cases can be analyzed first to identify the key nodes requiring quantification in each test case (i.e., the positions of the parameters to be filled). Then, the values ​​of the corresponding target test parameters are filled into the key judgment nodes of the target test cases, replacing the preset parameter placeholders in the target test cases, thus generating a directly executable target test task.

[0078] For example, for the target device identifier VC100, the obtained target test case 1 is "image clarity test" (operation steps: ① control camera A to start the image acquisition function; ② acquire standard test card image data; ③ analyze image resolution and sharpness data; ④ compare with preset standards to determine whether it meets the standard), and the corresponding target test parameter 1 is "image resolution ≥ 1080P, sharpness value ≥ 80%". When generating the target test task, the execution logic of target test case 1 can be analyzed first: the execution order is ①→②→③→④, the core judgment dimensions are "image resolution" and "sharpness value", and the key judgment node is the "preset standard" (i.e., parameter placeholder) in step ④; then the specific value of target test parameter 1 is filled into the placeholder, replacing the original vague expression; the finally generated target test task 1 that can be directly executed is: "① control the camera with the identifier VC100 to start the image acquisition function; ② acquire standard test card image data; ③ analyze the image resolution and sharpness data; ④ compare whether the measured resolution is ≥ 1080P and whether the sharpness value is ≥ 80%".

[0079] S205. Test the target device according to the target test task.

[0080] In this step, the test equipment can establish a communication connection with the target device and perform automated testing according to the generated target test task.

[0081] Specifically, the testing equipment can establish a stable connection with the target device through wired or wireless communication links, send execution instructions to the target device according to the target test task steps, collect the target device's response data in real time and compare it with preset test parameters, determine the pass / fail status of each test item, and generate test data including test items, measured data, judgment results, and anomaly details.

[0082] Among them, wired communication links include, but are not limited to, Controller Area Network (CAN) bus, CAN Flexible Data-Rate (CAN FD) bus, Universal Serial Bus (USB), and RS232 / RS485 serial communication bus, adapting to different data transmission rates and device interface requirements; wireless communication links include, but are not limited to, WiFi, Bluetooth, LoRa (Long Range), and Near Field Communication (NFC), suitable for scenarios without physical interface constraints.

[0083] For example, targeting device identifier VC100, the test equipment first establishes a connection with camera A via the CAN bus in the wired communication link; then, it executes the target test task 1 step by step: ① Sends an image acquisition start command to camera A, and the camera responds and starts the acquisition function; ② Controls the camera to acquire image data from the standard test card and transmits it back to the test equipment in real time via the CAN bus; ③ The test equipment analyzes the transmitted image to obtain the measured data: image resolution 1080P, sharpness value 85%; ④ Compares the measured data with the preset test parameters (resolution ≥ 1080P, sharpness value ≥ 80%), and determines that both indicators meet the requirements, and the test item is qualified. The generated test data may include: test item "image clarity test", measured data "resolution 1080P, sharpness value 85%", and judgment result "qualified".

[0084] In this embodiment, based on the obtained test requirements of the target device, corresponding target test cases and target test parameters can be obtained from the test case storage platform and the parameter storage platform, respectively. Then, target test tasks can be generated based on the target test cases and target test parameters to test the target device. In the above process, through the centralized design of the test case storage platform and the parameter storage platform, the test logic and quantitative standards of various electronic devices can be integrated into a standardized resource library. Test cases can be reused across models and scenarios (e.g., different cameras can share the basic test case of "image sharpness detection"), and test parameters and test cases form a fixed association mapping. There is no need to develop separate test programs for individual devices. When adding a new device model or optimizing test standards, only resources need to be added or modified on the corresponding platform, without refactoring the test program. This significantly reduces the development threshold and subsequent maintenance costs of the test solution, and improves the overall testing efficiency of electronic devices.

[0085] Figure 3 This is a schematic flowchart of Embodiment 2 of the testing method for the electronic device provided in this application. Please refer to... Figure 3 ,exist Figure 2 Based on the illustrated embodiment, since there are multiple target test cases, the specific implementation of step S204 may further include the following steps:

[0086] S301. Assemble multiple target test cases according to the preset business execution order to obtain the target test suite.

[0087] In this step, when there are multiple target test cases corresponding to the test requirements, the order of each test case can be determined according to the preset business execution logic, and then integrated into a target test suite with a coherent structure and standardized process, so as to ensure that the test process conforms to the actual test scenario and functional verification logic of electronic devices.

[0088] Optionally, the preset execution order of business processes can be pre-set based on factors such as the priority of device testing, functional relevance, and process dependencies. For example, basic functional tests can be executed first, followed by performance tests; initialization tests can be completed first, followed by core functional tests. The assembled target test suite can clearly define the execution order, dependencies, and jump rules of each target test case, avoiding confusion in the testing process or omission of key steps.

[0089] For example, if the key identification information in the test requirements is the target device identifier VC100, and the multiple target test cases obtained from the test case storage platform include: Test Case 1, Test Case 2, and Test Case 3, where Test Case 1 is an image acquisition initialization test, Test Case 2 is an image clarity test, and Test Case 3 is a low-light environment adaptability test, then the three test cases can be assembled according to the preset business execution order to obtain Target Test Suite 1. The execution order of Target Test Suite 1 can be: Test Case 1, Test Case 2, Test Case 3, with a clear jump rule that "the next test case can only be executed after the current test case is deemed qualified." The preset business execution order is: first perform basic initialization, then perform core function testing, and finally perform the environment adaptability test.

[0090] S302. Fill the values ​​of the target test parameters into the corresponding parameters in the target test set to generate the target test task.

[0091] In this step, based on the association mapping relationship between the parameter storage platform and the test case storage platform, the values ​​of the target test parameters corresponding to each target test case can be accurately filled into the corresponding positions of the target test suite to generate a target test task containing complete execution logic and quantitative judgment criteria.

[0092] In one specific implementation, the operation steps, core judgment dimensions, and parameter placeholders to be filled for each test case in the target test suite can be parsed first to clarify the parameter type and relationship corresponding to each placeholder; then, from the acquired target test parameters, the parameter values ​​corresponding to each test case can be selected and the placeholders in the test suite can be replaced one by one; at the same time, the preset execution order, inter-test case dependencies, and jump rules of the target test suite can be retained to ensure that the generated target test task is logically coherent and the judgment criteria are clear.

[0093] For example, for target test kit 1 with the target device identifier "VC100", the corresponding target test parameter 2 has been obtained from the parameter storage platform. Target test parameter 2 can be represented as a set of target parameters, including parameter 1, parameter 2, and parameter 3. Parameter 1 corresponds to test case 1 and may specifically include initialization time ≤ 2 seconds; parameter 2 corresponds to test case 2 and may specifically include image resolution ≥ 1080P and sharpness value ≥ 80; parameter 3 corresponds to test case 3 and may specifically include frame rate ≥ 25Hz when illumination intensity ≤ 500 lux.

[0094] The specific filling process is as follows: ① The key decision node of test case 1 is "initialization time ≤ [parameter placeholder 1]", and parameter 1 "≤ 2 seconds" is filled into this position; ② The key decision node of test case 2 is "resolution ≥ [parameter placeholder 2], sharpness value ≥ [parameter placeholder 3]", and parameter 2 "≥ 1080P" and "≥ 80%" are filled into the corresponding positions respectively; ③ The key decision node of test case 3 is "frame rate ≥ [parameter placeholder 4]", and parameter 3 "≥ 25Hz" is filled into this position.

[0095] The final target test task 2 is as follows: "① Control the camera with the identifier VC100 to start the image acquisition function, record the initialization time, and judge the standard: ≤2 seconds (if qualified, proceed to the next step, if unqualified, terminate the test); ② Collect image data from the standard test card, analyze the image resolution (≥1080P) and sharpness value (≥80%), and proceed to the next step after judging it to be qualified; ③ Simulate a 500 lux low light environment, collect images and count the frame rate (≥25Hz), and judge whether it meets the standard."

[0096] In this embodiment, multiple target test cases can be assembled according to a preset business execution order to obtain a target test suite. The values ​​of the target test parameters are then filled into the corresponding parameters within the target test suite to generate the target test task. In this process, assembling test cases according to a preset business execution order allows multiple dispersed target test cases to form a logically coherent target test suite, reducing process chaos caused by the disordered execution of multiple test items. This ensures that the testing process follows preset business logic, comprehensively covers multiple test dimensions, and guarantees that the testing process meets the actual needs of device testing.

[0097] Furthermore, by integrating test kit assembly with batch parameter filling, the need for separate sequence planning and parameter configuration for each test case is eliminated, reducing repetitive operations in multi-test scenarios. This is particularly beneficial for electronic devices requiring verification across multiple dimensions, significantly shortening test task generation time and improving the overall efficiency of the testing process.

[0098] Figure 4This is a schematic flowchart of Embodiment 3 of the testing method for the electronic device provided in this application. Please refer to... Figure 4 Based on Embodiment 1 or Embodiment 2, if the number of target devices is at least one, the specific implementation of step S205 may further include the following steps:

[0099] S401. Load the target test tasks onto the actuators corresponding to each target device.

[0100] In this step, for at least one target device, the generated target test tasks can be loaded one by one onto the independent executor corresponding to each target device based on the unique identifier of each target device, so as to achieve precise binding between test tasks and devices and provide a foundation for parallel testing of multiple devices.

[0101] Specifically, an executor is an independent operating unit that carries out the execution of the target test task. Each executor has a unique correspondence with a target device, and each executor runs in an independent thread or process, with no logical dependency or interference between them. During the loading process, the test equipment matches the corresponding executor through the target device identifier or workstation slot identifier, completely sends the target test task to the executor and caches it, putting the executor in a ready state, waiting for the start command. For example, target device 1 is camera A1, whose identifier can be "VC100-01", target device 2 is camera A2, whose identifier can be "VC100-02", workstation slot 1 can be identified as "CAM03-01 slot", and workstation slot 2 can be identified as "CAM03-02 slot".

[0102] For example, if the CAM03 workstation is configured with 4 independent slots, corresponding to 4 target devices, all of which are cameras identified as "VC100", and are labeled as VC100-01, VC100-02, VC100-03, and VC100-04 respectively, and the target test task 2 of "initialization → sharpness detection → low light adaptability" has been generated, then the electronic device can load the target test task 2 into the 4 independent actuators (actuator 1 to actuator 4) corresponding to the 4 slots respectively, and each actuator caches the test task bound to the corresponding camera.

[0103] For example, if the target devices are camera A1 and camera A2, and their corresponding target device identifiers are "VC100-01" and "VC100-02" respectively, and they are placed in slots 01 and 02 of the CAM03 workstation (slot identifiers are "CAM03-01" and "CAM03-02" respectively), and a target test task 2 consistent with the scene of the two slots has been generated, then the test equipment can use the unique mapping relationship between the target device identifier and the slot identifier to load the target test task 2 into actuator 1 corresponding to "CAM03-01" and actuator 2 corresponding to "CAM03-02" respectively. Actuator 1 caches the target test task 2 bound to "VC100-01", and actuator 2 caches the target test task 2 bound to "VC100-02". The two actuators independently store the task logic and parameter standards, do not interfere with each other, and are both in a ready state, waiting for their respective start test instructions.

[0104] S402. In response to the start test operation of any target device, control the actuator corresponding to the target device to execute the target test task and test the target device.

[0105] In this step, the actuator can respond only to the start test operation of the corresponding target device and independently execute the cached target test task, realizing flexible concurrent testing of multiple target devices, supporting test scenarios of "starting one by one" or "batch starting", and adapting to the high-efficiency testing needs of large-scale production.

[0106] Optionally, the test launch operation can be triggered manually or automatically by the system. Both triggering methods can be effective independently to adapt to the operational needs of different testing scenarios.

[0107] For example, regarding the four independent slots configured in the CAM03 workstation, if a manual triggering method is used, after placing the camera in each slot, the tester can press the physical start button of the corresponding slot to trigger the actuator of that slot to execute target test task 2. Alternatively, the tester can press the start button of the workstation, simultaneously triggering the actuators of each slot to execute target test task 2. If an automatic system triggering method is used, the test equipment can interface with the MES system. When the MES system issues the instruction "Start testing of slots 01-04 in CAM03 workstation" according to the production plan, the actuators corresponding to the four slots will automatically respond and execute target test task 2 for the cameras VC100-01 to VC100-04 respectively, without the need for manual operation by the tester.

[0108] It should be noted that when the startup operation corresponding to a target device is triggered, the test equipment only controls the actuator bound to that device to start the test, while other actuators remain in the ready state. The actuators can interact with the target device through a preset communication link according to the cached test task steps, independently complete data acquisition, parameter comparison, result judgment, and generate exclusive test data.

[0109] For example, for slots 01 and 02 of CAM03 workstation, the loading of target test task 2 has been completed. If a manually triggered "one-by-one start" method is used: after the tester places the VC100-01 camera in slot 01, they press the physical start button for that slot. Actuator 1 immediately responds and executes target test task 2. After the test is completed, actuator 1 generates test data 1 for VC100-01. During this process, actuator 2 remains in a ready state until the tester presses the start button for slot 02. Only then will it execute the same target test task 2 on VC100-02, independently completing data acquisition and result judgment, and generating test data 2 for VC100-02. The two test processes do not interfere with each other.

[0110] In this embodiment, target test tasks can be loaded onto the actuators corresponding to each target device. In response to a test initiation operation on any target device, the actuator corresponding to the target device is controlled to execute the target test task, thus testing the target device. In this process, by configuring an independent actuator for each target device and achieving precise binding of target test tasks, the testing processes of each target device can be independent and logically independent, avoiding process interference or data confusion when multiple devices are tested simultaneously. This ensures the independence and accuracy of each device's test and adapts to the needs of parallel testing scenarios involving multiple devices.

[0111] Furthermore, by supporting flexible start-up methods that support both manual and automatic system triggering, it can meet the refined operational needs of "deploying and starting one by one" in small-scale testing, and also adapt to the efficient testing scenarios of "batch deployment and batch start-up" in large-scale production. It can start the testing process of other devices without waiting for the testing of a single device to be completed, which greatly improves the overall efficiency of multi-device testing and reduces the testing cycle cost in large-scale production.

[0112] Figure 5 This is a schematic flowchart of Embodiment 4 of the testing method for the electronic device provided in this application. Please refer to... Figure 5 Based on any of the above embodiments, the testing method for electronic devices may further include:

[0113] S501, Obtain test data.

[0114] In this step, test data generated after the test task is executed can be obtained. The test data includes the test results of at least one target device, and the test results can record the entire test process information of the target device.

[0115] Optionally, test data can be acquired independently for a single target device, in batches for a test batch, or periodically according to a test cycle.

[0116] In one specific implementation, test data is automatically generated by the actuator corresponding to each target device after the test is completed, and is bound to the unique identifier of the target device (such as device identifier "VC100-01", workstation slot identifier "CAM03-01 slot") to ensure accurate traceability of data ownership. The specific content of the test data includes, but is not limited to: target device identifier, test item name, measured data of each test case, individual judgment result, overall judgment result, anomaly details, and test timestamp.

[0117] For example, for the VC100-01 camera in slot 01 of CAM03 station, after executing target test task 2, the independently acquired test data 1 is: "Device Identifier: VC100-01; Test Items: Image Acquisition Initialization Test → Image Clarity Test → Low Light Environment Adaptability Test; Measured Data: Initialization Time 1.6 seconds, Resolution 1080P, Sharpness Value 83%, Low Light Frame Rate 26Hz; Individual Judgment Result: Initialization Test Passed, Clarity Detection Passed, Low Light Adaptability Test Passed; Overall Judgment Result: Passed; Test Timestamp: 2024-05-2015:10:30"; Optionally, for the four cameras in slots 01 to 04 of this station, the batch acquired test data can include the independent test results of the above four devices, sorted and organized by "Device Identifier".

[0118] S502. Through the standardized data interface, the format of the test data is converted into a preset structure to obtain the standardized test data after format conversion.

[0119] In this step, the acquired test data can be formatted through a unified standardized data interface, transforming the fragmented and inconsistent test data into standardized test data that conforms to the preset structure.

[0120] For a pre-defined structure, a unified data model can be defined in advance based on the data requirements of an external system, with clear specifications for field names, data types, arrangement order, and expression standards.

[0121] In one optional implementation, the testing equipment can automatically parse the key fields in the test data, complete the unified naming of fields, data format standardization, and missing field completion according to the preset structure, and finally generate standardized test data with unified structure and standard format.

[0122] In addition, the storage format of standardized test data can be flexibly selected according to the interface requirements and data interaction needs of external systems, including but not limited to JavaScript Object Notation (JSON), Extensible Markup Language (XML), Comma-Separated Values ​​(CSV), and Database Table Structure (DTS).

[0123] For example, the test data for the VC100-02 camera includes: "Device Identifier: VC100-02; Test Items: Image Acquisition Initialization Test → Image Sharpness Test → Low Light Environment Adaptability Test; Measured Data: Initialization Time 1.9 seconds, Resolution 1080P, Sharpness Value 79%, Low Light Frame Rate 24Hz; Individual Judgment Results: Initialization Test Passed, Sharpness Detection Failed, Low Light Adaptability Test Failed; Overall Judgment Result: Failed; Anomaly Details: Sharpness Value Not Reaching ≥80% Standard, Low Light Frame Rate Not Reaching ≥25Hz Standard; Test Timestamp: 2024-05-2015:12:15"; The standardized test data after conversion according to the preset structure can be shown in Table 1:

[0124] Table 1

[0125]

[0126] S503. Synchronize standardized test data to an external system for storage.

[0127] In this step, standardized test data, converted to a preset structure, can be synchronized to a preset external system for storage, enabling secure retention, convenient retrieval, and cross-system sharing of test data. The external system includes at least one of the following: a production execution system, a local database, and remote cloud storage.

[0128] Optionally, data synchronization methods can include real-time synchronization or scheduled batch synchronization. Real-time synchronization refers to triggering the synchronization process immediately after standardized test data is generated, without waiting for batch accumulation, which is suitable for scenarios with high requirements for data timeliness; while scheduled batch synchronization refers to triggering the synchronization process once at a preset time interval (such as every 15 minutes) or a preset data volume threshold (such as accumulating 100 test data), which is suitable for large-scale batch testing scenarios.

[0129] For example, standardized test data for the four VC100 series cameras in slots 01 to 04 of CAM03 workstation can be synchronized to the MES system in real-time. Furthermore, the MES system can link the data with production plans and workstation information, automatically calculate the pass rate of the batch of cameras (e.g., 3 out of 4 devices pass, 1 fails, pass rate 75%), and trigger a traceability process for the non-conforming devices.

[0130] For example, in a testing scenario where 5,000 VC100 series cameras are produced daily, a timed batch synchronization method can be used to synchronize standardized test data to the local MySQL database: set to synchronize once every 30 minutes, all standardized test data generated during the local temporary storage of the test equipment is written to the database at once through the batch interface after the time is up, and a composite index is created by “device identifier plus test timestamp” during synchronization, and the data is stored in separate tables according to the test date.

[0131] In this embodiment, the acquired test data can be converted into a preset structure using a standardized data interface to obtain standardized test data. This standardized test data is then synchronized to an external system for storage. The test data may include test results for at least one target device, and the external system may include at least one of a production execution system, a local database, or remote cloud storage. In this process, converting fragmented and heterogeneous test data into standardized test data with a preset structure through a standardized data interface effectively solves the data interaction compatibility problem between different external systems. It improves the cross-system adaptation difficulties caused by the messy formats and inconsistent representations of traditional test data, enabling various external systems such as production execution systems, local databases, and remote cloud storage to directly recognize and parse standardized data without additional format adaptation processing, significantly improving the efficiency of data storage and interaction.

[0132] In one possible design, during the testing of the target device according to the target test task, multiple test infrastructures required by the target test task can be accessed through the device control abstraction interface, and the multiple test infrastructures can be coordinated through the resource manager.

[0133] The device control abstraction interface encapsulates the underlying access logic for various test infrastructures such as power supplies, serial ports, CAN buses, cameras, and IMUs, providing a standardized call entry point for different types of test infrastructure. Regardless of the hardware model or interface protocol of the test infrastructure, the test device can access resources through a unified interface function, eliminating the need to develop separate adaptation logic for specific hardware, thereby reducing the dependence of the target test task on the hardware environment.

[0134] For example, a low-light adaptability test for the VC100 series cameras requires simultaneous use of four types of test infrastructure: a power module, a CAN bus, the camera, and a light sensor. The power module supplies power to the camera, the CAN bus transmits control commands, the camera acquires test images, and the light sensor monitors ambient light intensity. The test equipment can directly call standardized interface functions such as "power on," "CAN data transmission," "image acquisition trigger," and "low-light mode activation" through the device control abstraction interface to coordinate the use of various test infrastructure components. This eliminates the need to concern oneself with low-level details such as the communication timing of the power module or the baud rate configuration of the CAN bus, thus reducing the target test task's dependence on the specific hardware environment.

[0135] Regarding the resource manager, it is responsible for coordinating and managing the entire lifecycle of the test infrastructure. Specifically, this includes: the startup and initialization of the test infrastructure, thread access scheduling, and post-test facility release, ensuring the orderly and stable collaborative operation of multiple facilities through a systematic management mechanism.

[0136] In one specific implementation, during the test infrastructure initialization phase, the resource manager can automatically detect the physical connection status and communication link connectivity of the required test infrastructure according to the needs of the target test task. It can then perform preprocessing operations such as hardware driver loading and core parameter configuration (e.g., serial port baud rate, camera acquisition resolution, CAN bus communication rate) to ensure that all types of test infrastructure are in a usable state that meets the test requirements. In multi-task concurrent test scenarios, the resource manager uses techniques such as thread exclusive locks and task priority scheduling to avoid resource contention caused by multiple test executors accessing the same shared test infrastructure (e.g., the CAN bus and common power module of the same workstation) at the same time.

[0137] For example, when the four actuators of the CAM03 workstation simultaneously test four VC100 series cameras in parallel, and all need to use the workstation's shared CAN bus to transmit control commands, the resource manager can allocate orderly access time slots to each actuator, and queue and schedule them according to the target test task startup order or preset priority, ensuring that the transmission of each control command is not lost or disordered, and guaranteeing the synchronization and accuracy of parallel testing of multiple devices.

[0138] Furthermore, after the test task is completed, the resource manager can automatically trigger the test infrastructure release process, shutting down the power output, disconnecting the serial port and CAN bus communication link, and releasing the image acquisition buffer and data storage temporary space in a preset order, so as to avoid problems such as excessive hardware load, shortened service life or insufficient resource allocation for subsequent test tasks caused by the test infrastructure being occupied for a long time.

[0139] For example, for the complete low-light adaptability test process of the VC100-03 camera, the coordination logic of the resource manager is as follows: ① When the test starts, the resource manager initializes the power module through the device control abstraction interface, configures the output voltage to 5V, and initializes the CAN bus, camera module, and light sensor. After verifying the readiness status of each test infrastructure and confirming that there are no connection abnormalities, it sends a facility readiness signal to the actuator; ② During the test, when the actuator needs to send a "low-light mode switch" command to the camera, the resource manager confirms through the bus occupancy status detection mechanism that no other actuator is currently accessing the CAN bus. Then, it allows the device control abstraction interface to call the "CAN data send" function to transmit the command. At the same time, it synchronously triggers the light sensor to perform ambient light intensity acquisition, ensuring the timing consistency between the control command transmission and the light intensity data acquisition, and providing accurate environmental parameter support for the test result analysis; ③ After the test, the resource manager calls the standardized interfaces such as "image buffer release", "CAN bus disconnection", and "power module shutdown" in the order of "data buffer release, communication link disconnection, and power off" to restore all occupied test infrastructure to the initial idle state, quickly releasing resources for the next camera test task.

[0140] In this embodiment, during the testing of the target device according to the target test task, multiple test infrastructures required by the target test task can be accessed through the device control abstraction interface, and the resource manager can coordinate the multiple test infrastructures. Through the collaborative work of the device control abstraction interface and the resource manager, not only can unified management and standardized calling of various test infrastructures such as power supplies, serial ports, and CAN buses be achieved, but the hardware compatibility and scalability of the test solution can also be significantly improved. When adding test infrastructure, only the underlying access logic encapsulation and standardized interface definition of the corresponding facility need to be added to the device control abstraction interface; there is no need to modify the core execution flow and control logic of the test task. Furthermore, through the dynamic scheduling and timely release of test infrastructure, the utilization rate of hardware resources can be greatly improved, effectively adapting to the multi-device parallel testing needs in the scenario of large-scale electronic device production, ensuring test stability, and improving test efficiency.

[0141] Figure 6 This is a flowchart illustrating Embodiment 5 of the testing method for the electronic device provided in this application. Please refer to... Figure 6 Based on any of the above embodiments, the testing method for electronic devices may further include:

[0142] S601. During the testing of the target device according to the target test task, monitor the execution status of the target test task.

[0143] In this step, as the testing equipment tests the target device according to the target test task, it can monitor the execution status of the target test task from dimensions such as test process progress, test data validity, and target device operating status.

[0144] Monitoring the progress of the test process can include verifying whether the test process proceeds in an orderly manner according to the preset sequence of steps of the target test cases, and monitoring whether the execution time of each step exceeds the preset timeout threshold to avoid test anomalies caused by process stalls or skipped steps. For example, for the test task of the VC100 series camera, the preset process is "power-on, parameter configuration, image acquisition, and result analysis". During the monitoring process, it is necessary to confirm whether there is an abnormal situation where "parameter configuration" is skipped and directly enters "image acquisition", and the execution time of each step does not exceed 5 seconds.

[0145] Monitoring the validity of test data can include checking whether the format of intermediate and result data generated during the test conforms to the preset structure, whether it includes key fields such as target device identifier, test parameters, and result judgment, and determining whether there are problems such as packet loss or errors during data transmission. For example, in IMU testing, it is necessary to check whether the format of the collected inertial data conforms to the preset structure, whether it includes key fields such as the IMU unique identifier, test sampling frequency, and result judgment identifier; and to determine whether there are problems such as frame loss or field order disorder during data transmission, ensuring the integrity and accuracy of each frame of data.

[0146] Monitoring the operational status of target devices can include real-time acquisition of key physical parameters to determine whether they are within a preset normal operating range. For example, when testing an automotive temperature sensor, it is necessary to monitor whether its power supply voltage is stable within the range of 12V±0.5V and whether its operating temperature is within the rated range of -40℃ to 85℃.

[0147] In one alternative implementation, during multi-dimensional monitoring, the testing equipment can collect and record monitoring data from each dimension in real time according to the standardized format of a unified log system, providing basic data support for subsequent anomaly detection and problem tracing.

[0148] S602. When the execution status is execution exception, trigger an exception alarm and record the exception log.

[0149] In this step, if the testing equipment determines that the execution status of the target test task is abnormal through multi-dimensional monitoring, it can trigger an abnormal alarm and record the abnormal log in a standardized format.

[0150] Optionally, the anomaly alarm can adopt a tiered response mechanism. For abnormal test process progress or serious abnormality in the operating status of the target device, a local audible and visual alarm can be immediately activated (a red indicator light stays on and a buzzer sounds intermittently), while a remote alarm notification is pushed to the production management platform, clearly indicating the monitoring dimension and key information to which the anomaly belongs, so as to facilitate a quick response by staff. For non-fatal anomalies such as the validity of test data, a local pop-up prompt can be triggered, without interrupting the current test process, only reminding for subsequent verification and correction.

[0151] Specifically, anomaly logs can be recorded based on standardized monitoring data and stored in a unified log system format. This includes: anomaly occurrence timestamp, unique identifier of the target device, monitoring dimension to which the anomaly belongs, and specific anomaly details. Simultaneously, logs can be synchronized in real-time to local databases and remote cloud environments, supporting retrieval by device identifier, anomaly type, time range, and other dimensions. This enables full traceability of the testing history, providing direct data support for staff to accurately pinpoint the root cause of anomalies.

[0152] For example, when the execution time of the "image acquisition" step of the VC100-02 camera reaches 7 seconds, exceeding the preset 5-second threshold, which is an abnormal test process progress, a local audible and visual alarm and a remote notification can be triggered immediately. At the same time, a standardized log is recorded, specifying the abnormality as test process progress, the device identifier as VC100-02, the abnormality description as the image acquisition step timeout of 2 seconds, and the monitoring data (such as power supply voltage 5.0V, normal CAN bus communication) to help staff quickly troubleshoot whether the problem is due to slow camera hardware response or test command configuration issues.

[0153] In this embodiment, the testing equipment can monitor the execution status of the target test task during the testing of the target device according to the target test task. When the execution status is abnormal, an abnormal alarm is triggered and an abnormal log is recorded. Through real-time status monitoring and abnormal closed-loop processing mechanism, the invalid time consumed by the test process due to abnormalities can be effectively reduced, and the controllability and reliability of the test process can be improved. At the same time, the standardized abnormal log can provide data support for fault tracing and test plan optimization, helping staff to quickly locate the root cause of the fault, shorten the problem investigation cycle, and avoid the recurrence of similar abnormalities.

[0154] Figure 7 This is a schematic diagram of the structure of a testing apparatus for electronic devices provided in an embodiment of this application. Please refer to [link / reference]. Figure 7 The testing apparatus 10 for electronic devices provided in this embodiment includes:

[0155] Infrastructure layer 11 is used to implement driver encapsulation for underlying hardware devices and provide hardware interfaces for the domain layer.

[0156] Domain layer 12 is used to encapsulate functions based on the hardware interfaces provided by the infrastructure layer, targeting the business needs of different target devices, generating reusable business function modules, and providing callable business interfaces for the export layer.

[0157] Export layer 13 is used to collect the business interfaces provided by the domain layer, generate a set of functions, and provide a call entry point for the application layer and framework layer.

[0158] Application layer 14 is used to classify and manage target test cases, and implement the business logic of specific test cases based on the call entry provided by the export layer;

[0159] Framework layer 15 is used to perform the testing method for the electronic device shown in the above method embodiment.

[0160] The testing device for electronic devices provided in this application embodiment can achieve decoupled collaboration between hardware adaptation, business encapsulation, and test execution through a layered architecture design of infrastructure layer, domain layer, export layer, application layer, and framework layer, significantly improving the versatility, reusability, and scalability of the testing solution. The framework layer in the testing device for electronic devices can execute the methods provided in the above-described method embodiments, with similar implementation principles and technical effects, which will not be elaborated upon here. The testing process provided in this application embodiment adopts a structured configuration description, reducing the uncertainty caused by differences in developer coding styles. Combined with unified device resource management and anomaly tolerance mechanisms, it effectively reduces software bugs and quality risks in production testing development, effectively improving the stability and consistency of the testing system. Moreover, through data-driven design, the decoupling of test logic and test data is achieved. Developers only need to write a general test process template once, which can be reused for multiple product variants and process scenarios, significantly reducing repetitive development workload. The standardized architecture design allows each functional module of the system to be loaded and upgraded independently, facilitating subsequent functional expansion and maintenance, and improving the overall flexibility and lifecycle management capabilities of the system.

[0161] Figure 8 This document shows a layered architecture and schematic diagram of each layer of the testing apparatus for electronic devices provided in embodiments of this application. Please refer to [link / reference]. Figure 8The top layer is the framework layer, located at the top of the diagram, and includes three modules: Load, Runner, and Result Manager. The Loader retrieves target test cases corresponding to test requirements from the test case storage platform and target test parameters from the parameter storage platform; it then generates target test tasks based on the target test cases and parameters. The Runner executes the target test tasks, and the Result Manager manages the test data. Optionally, there can be multiple Runners, each corresponding to a target device, enabling parallel testing of multiple devices and improving execution efficiency in batch testing scenarios.

[0162] Optionally, a visualization framework (Vcraft) can be integrated into the framework layer for visual presentation and interactive management of the entire testing process. This can include real-time display of the running status of each executor (e.g., idle, running, abnormally paused), the progress of the target test task (e.g., test case execution completion rate, number of remaining steps), and dynamic trends of test data.

[0163] Below the framework layer is the application layer, which is responsible for classifying and managing target test cases and implementing the functional positioning of specific test case business logic based on the calling entry points provided by the export layer. Optionally, test case classification modules can be created based on the target device type, such as cameras, LiDAR, and domain controllers, to achieve classified management of test cases. Each test case classification module includes multiple test cases (i.e., test case 1 to test case N) corresponding to that type of device, covering the testing requirements of that device in different dimensions.

[0164] Below the application layer is the export layer, which is the connecting layer between the application layer and the lower domain layer. It can integrate the business interfaces of the domain layer into a set of functions, providing standardized call entry points for the application layer and the framework layer, and decoupling the upper-layer modules from the business functions of the domain layer.

[0165] Below the export layer is the domain layer, which receives the hardware interfaces provided by the infrastructure layer. It encapsulates functions for the business requirements of different target devices, generating reusable business function modules and providing the export layer with callable business interface functional positioning. For example, for the device classification of the application layer, three dedicated business function modules can be encapsulated: camera (Domain Object - Cam), lidar (Domain Object - Lidar), and domain controller (Domain Object - CECU).

[0166] Under the camera business function module, components such as communication protocols (e.g., Gigabit Multimedia Serial Link 2, GMSL2 and GMSL3), algorithm engineering (e.g., camera calibration), and data parsing & construction (e.g., Embedded Engineering Build, EEBuild, serialization / deserialization) can be included. These components respectively implement the core business functions of communication link adaptation, calibration algorithm execution, and data format conversion and processing for this type of device. If the device classification in the application layer includes IMU, the domain layer can also encapsulate the IMU business function module. Correspondingly, under the IMU business function module, the communication protocol can also include the vehicle bus transmission of IMU data (IMU-CAN), and the algorithm engineering can also include IMU calibration.

[0167] Under the LiDAR business function module, components such as communication protocols (e.g., V1, LiDAR Assistant), algorithm engineering (e.g., electric axis calibration, transmitter calibration, polarization, noise, and vibration testing and optimization, and whole-machine calibration) and data parsing & construction (e.g., EE Build, point cloud parsing, and point cloud visualization) can be encapsulated, covering the business requirements of LiDAR communication interaction, core algorithm operation, and point cloud data processing. Under the domain controller business module, the Unified Diagnostic Services (UDS) component integrates communication protocols such as CAN bus, Internet Protocol (IP), diagnostic tool components (Diagnostic Kit, Dkit), and Diagnostic Unit Manager (DUM) to realize the core business functions of this type of control unit, such as diagnostic communication and bus interaction.

[0168] Below the domain layer is the infrastructure layer, which is responsible for "implementing driver encapsulation for underlying hardware devices and providing standardized hardware interfaces for the domain layer". It can be divided into two functional areas: "device driver" and "public service interface", which respectively undertake the core responsibilities of hardware driver adaptation and public service capability support.

[0169] The device driver partition can include two types of components: dedicated device drivers and general hardware drivers. Dedicated device driver modules can correspond to different hardware manufacturers. For example, the communication interface module of hardware manufacturer A encapsulates the driver logic for interfaces such as Mobile Industry Processor Interface (MIPI), Inter-Integrated Circuit (IIC), and Serial Peripheral Interface (SPI), while the communication interface module of hardware manufacturer B adapts to interfaces such as MIPI, IIC, SPI, and Universal Asynchronous Receiver / Transmitter (UART). The communication interface modules of the two manufacturers can provide matching hardware communication driver support for the corresponding business function modules of cameras and LiDAR in the domain layer, respectively.

[0170] The general-purpose hardware driver component can cover the driver logic of underlying hardware such as Controller Area Network (CAN bus), Power Management, Temperature Monitoring (Thermo), Programmable Logic Controller (PLC), Input / Output Control (IOC), and Relay Control, shielding the differences between different hardware models and protocols, and providing a generalized hardware interface calling capability for various business function modules in the domain layer.

[0171] The public service interface partition integrates multiple basic public service components, including business-related service interfaces such as the MES system, the Data Test and Analysis System (DTAS), and the Windows Communication Foundation (WCF). It also covers auxiliary service capabilities such as product information management, encryption / decryption, Secure Shell (SSH) protocol, and Secure Copy Protocol (SCP), providing basic support for the entire testing device in terms of system interaction, data security, and information management, and ensuring the availability of underlying services in the testing process.

[0172] The testing device for electronic devices provided in this application, through a five-level layered architecture design and component-based encapsulation of framework layer, application layer, export layer, domain layer and infrastructure layer, can achieve deep decoupling of hardware and business, flexible adaptation of multiple devices, improve batch testing efficiency and functional iteration flexibility, and ensure standardized testing process, reliable and traceable results.

[0173] Figure 9 This is a schematic diagram of the test equipment provided in an embodiment of this application. Please refer to... Figure 9 The test device 20 provided in this embodiment may include, but is not limited to, an industrial control computer, a test terminal, a dedicated test host, etc., and may include at least one processor 21 and a memory 22. Optionally, the test device 20 may also include a communication component 23. The processor 21, the memory 22, and the communication component 23 are connected via a bus 24.

[0174] In the specific implementation process, at least one processor 21 executes computer execution instructions stored in memory 22, causing at least one processor 21 to perform the above-described method.

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

[0176] 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.

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

[0178] 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.

[0179] Figure 10This is a schematic diagram of the structure of a testing system for electronic devices provided in an embodiment of this application. Please refer to [link / reference]. Figure 10 The electronic device testing system 30 includes: a cloud-based test resource management center 31 and Figure 9 The test equipment 32 shown is shown.

[0180] The cloud-based test resource management center 31 includes a test case storage platform 311 and a parameter storage platform 312. The test case storage platform 311 stores test cases for multiple different devices, and the parameter storage platform 312 stores test parameters for multiple different devices.

[0181] It should be noted that the working process of the electronic device testing system 30 can be referred to the process shown in the above method embodiment. The implementation principle and beneficial effects are similar, and will not be repeated here.

[0182] In this embodiment, the electronic device testing system 30 stores the production data and test cases in the cloud test resource management center 31. During production, the framework of the testing equipment 32 dynamically pulls and generates executable test content, reducing the risk of local data being tampered with and greatly enhancing the security of data and production content.

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

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

[0185] 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.

[0186] 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.

[0187] 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.

[0188] 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.

[0189] 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.

[0190] 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.

[0191] 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.

[0192] 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 testing method for electronic devices, characterized in that, Applied to a testing device, the method includes: Obtain the test requirements of the target device, wherein the test requirements include the identifier of the target device or the identifier of the workstation to which the target device belongs; The target test cases corresponding to the test requirements are obtained from the test case storage platform, which stores test cases for multiple different devices. The target test parameters corresponding to the test requirements are obtained from the parameter storage platform, which stores test parameters for multiple different devices. Based on the target test cases and the target test parameters, generate the target test task; The target device is tested according to the target test task.

2. The method according to claim 1, characterized in that, The number of target test cases is multiple, and the step of generating target test tasks based on the target test cases and the target test parameters includes: According to the preset business execution order, multiple target test cases are assembled to obtain the target test suite; The values ​​of the target test parameters are filled into the corresponding parameters in the target test suite to generate the target test task.

3. The method according to claim 1 or 2, characterized in that, If the number of target devices is at least one, the step of testing the target devices according to the target test task includes: The target test tasks are loaded onto the actuators corresponding to each target device. In response to a test start operation on any target device, the actuator corresponding to the target device is controlled to perform a target test task and test the target device.

4. The method according to claim 3, characterized in that, The method further includes: Acquire test data, which includes test results of the at least one target device; The test data is converted into a preset structure through a standardized data interface to obtain standardized test data after format conversion. The standardized test data is synchronized to an external system for storage, and the external system includes at least one of a production execution system, a local database, and a remote cloud storage.

5. The method according to claim 1 or 2, characterized in that, The method further includes: During the testing of the target device according to the target test task, multiple test infrastructures required by the target test task are accessed through the device control abstraction interface, and the multiple test infrastructures are coordinated through the resource manager.

6. The method according to claim 1 or 2, characterized in that, The method further includes: During the testing of the target device according to the target test task, the execution status of the target test task is monitored; When the execution status is abnormal, an exception alarm is triggered and an exception log is recorded.

7. A testing device for electronic devices, characterized in that, The device includes: The infrastructure layer is used to implement driver encapsulation for underlying hardware devices and provide hardware interfaces for the domain layer. The domain layer is used to encapsulate functions based on the hardware interfaces provided by the infrastructure layer, targeting the business needs of different target devices, generating reusable business function modules, and providing callable business interfaces for the export layer. The export layer is used to collect the business interfaces provided by the domain layer, generate a set of functions, and provide a call entry point for the application layer and framework layer. The application layer is used to classify and manage target test cases, and implement the business logic of specific test cases based on the call entry points provided by the export layer. A framework layer for performing the test method for the electronic device according to any one of claims 1 to 6.

8. A testing device, characterized in that, 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 test method for the electronic device as described in any one of claims 1-6.

9. A testing system for electronic devices, characterized in that, include: The cloud-based test resource management center and the test equipment described in claim 8, The cloud-based test resource management center includes a test case storage platform and a parameter storage platform. The test case storage platform stores test cases for multiple different devices, and the parameter storage platform stores test parameters for multiple different devices.

10. 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 test method for the electronic device as described in any one of claims 1-6.

Images