Test system and test method

Abstract

The invention relates to a test system and a test method, and relates to the technical field of test, and the method comprises the steps: obtaining test working condition information; generating a test case from the test condition information through a preset tool; calling an API (Application Program Interface), which is used for realizing a boundary scan test, of the Lauterbach simulator on the basis of the test case, and reading input and output signals between a chip pin related to the tested equipment and a processor core corresponding to the upper computer module; monitoring a chip software memory related to the tested equipment from the input and output signals; and performing test analysis on the monitored chip software memory to obtain a test result. According to the application, the test system capable of realizing boundary scan test is established based on the API interface of the third-party equipment Lauterbach simulator open source, and the monitoring on the chip software memory can be realized, so that in the test process of the corresponding type of the integrated equipment, whether the relevant software operation accords with the designed operation strategy or not can be accurately determined, and the test accuracy can be improved.

Description

Technical Field

[0001] This application relates to the field of testing technologies, and particularly to a testing system and a testing method. Background Art

[0002] With the rapid development of the Internet and the maturity of automotive intelligent technologies, the automotive industry has been continuously developing. Before a vehicle is put on the market, it is first necessary to test its various functions through a testing system.

[0003] Currently, traditional testing systems only integrate devices of the input / output (IO) type, or communication type, or sensor type, and then perform corresponding type of tests based on the integrated devices. For example, a testing system only integrates IO type devices and then performs IO function tests on the vehicle based on these IO type devices.

[0004] However, because such a testing system does not have the function of boundary scan testing and cannot monitor the chip software memory, during the testing process of the corresponding type of integrated devices, it is impossible to determine whether the relevant software operation conforms to the designed operation strategy, thus affecting the testing accuracy. Summary of the Invention

[0005] In view of this, this application provides a testing system and a testing method, mainly aiming to improve the technical problem that in the existing testing systems, due to the lack of the function of boundary scan testing, the monitoring of the chip software memory cannot be achieved, and during the testing process of the corresponding type of integrated devices, it is impossible to determine whether the relevant software operation conforms to the designed operation strategy, that is, the boundary scan testing cannot be realized, thus affecting the testing accuracy.

[0006] In a first aspect, this application provides a testing system, including: a host computer module and a Lauterbach emulator;

[0007] The Lauterbach emulator is connected to the computer device where the host computer module is located, and the Lauterbach emulator is also connected to the device under test;

[0008] The host computer module is used to generate test cases through a preset tool based on test condition information, and call the API interface of the Lauterbach emulator for implementing boundary scan testing based on the test cases, read the input / output signals between the chip pins related to the device under test and the corresponding processor core of the host computer module, so as to monitor the chip software memory related to the device under test from the input / output signals, where the monitored chip software memory is used for test analysis, and the test condition information includes test scenario data, test rule information, and expected result information.

[0009] Optionally, the test system further includes: a communication simulation board, and / or an IO simulation board, and / or a sensor simulation board, which are respectively connected to the computer device and the device under test;

[0010] The host computer module is further configured to call the API interface of the communication simulation board based on the test case, control the communication device related to the device under test, and monitor the communication data of the communication device; and / or,

[0011] Call the API interface of the IO simulation board based on the test case, control the IO device related to the device under test, and monitor the input and output data of the IO device; and / or,

[0012] Call the API interface of the sensor simulation board based on the test case, control the sensor device related to the device under test, and monitor the sensor signal of the sensor device.

[0013] Optionally, the communication simulation board includes: an SPI simulation board, and / or an IIC simulation board, and / or a CAN simulation board, and / or a LIN simulation board, and / or an Ethernet simulation board;

[0014] The IO simulation board includes: an ID / OD simulation board, and / or an IA / OA simulation board, and / or an IP / OP simulation board, and / or an Hbri simulation board;

[0015] The sensor simulation board includes: an IMU simulation board, and / or a PSI5 simulation board, and / or a camera simulation board, and / or a radar simulation board.

[0016] Optionally, the device under test includes a device under test controller and / or a device under test chip.

[0017] In a second aspect, the present application provides a test method, including:

[0018] Obtain test condition information, where the test condition information includes test scenario data, test rule information, and expected result information;

[0019] Generate a test case from the test condition information through a preset tool;

[0020] Call the API interface for implementing boundary scan testing of the Lauterbach emulator based on the test case, and read the input and output signals between the chip pins related to the device under test and the corresponding processor core of the host computer module;

[0021] Monitor the chip software memory related to the device under test from the input and output signals;

[0022] Test and analyze the monitored chip software memory to obtain test results.

[0023] Optionally, before the step of testing and analyzing the monitored chip software memory to obtain test results, the method further includes:

[0024] Based on the test case, call the API interface of the communication class simulation board to control the communication device related to the device under test, and monitor the communication data of the communication device; and / or,

[0025] Based on the test case, call the API interface of the IO class simulation board to control the IO device related to the device under test, and monitor the input and output data of the IO device; and / or,

[0026] Based on the test case, call the API interface of the sensor class simulation board to control the sensor device related to the device under test, and monitor the sensor signal of the sensor device.

[0027] Optionally, the step of testing and analyzing the monitored chip software memory to obtain test results includes:

[0028] Judge whether the communication data of the communication device reaches the first expected result; and / or,

[0029] Judge whether the input and output data of the IO device reaches the second expected result; and / or,

[0030] Judge whether the sensor signal of the sensor device reaches the third expected result;

[0031] If the communication data reaches the first expected result, and / or the input and output data reaches the second expected result, and / or the sensor signal reaches the third expected result, then judge whether the chip software memory reaches the fourth expected result, and determine that the test passes when the chip software memory reaches the fourth expected result.

[0032] In a third aspect, the present application provides a test device, including:

[0033] An acquisition unit, configured to acquire test condition information, where the test condition information includes test scenario data, test rule information, and expected result information;

[0034] A generation unit, configured to generate a test case by using a preset tool with the test condition information;

[0035] A calling unit, configured to call an API interface of a Lauterbach emulator for implementing boundary scan testing based on the test case, and read input / output signals between chip pins related to the device under test and a processor core corresponding to the host computer module; monitor chip software memory related to the device under test from the input / output signals;

[0036] An analysis unit, configured to perform test analysis on the monitored chip software memory to obtain a test result.

[0037] In a fourth aspect, the present application provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the method described in the second aspect is implemented.

[0038] In a fifth aspect, the present application provides an electronic device, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, and when the processor executes the computer program, the method described in the second aspect is implemented.

[0039] In a sixth aspect, the present application provides a vehicle, including the test system described in the first aspect or the electronic device described in the fifth aspect.

[0040] By means of the above technical solution, the present application provides a test system and a test method. The test system includes a host computer module and a Lauterbach emulator; the Lauterbach emulator is connected to the computer device where the host computer module is located, and the Lauterbach emulator is also connected to the device under test; the host computer module is configured to generate a test case through a preset tool based on the test working condition information, and call the API interface of the Lauterbach emulator for implementing boundary scan testing based on the test case, and read the input / output signals between the chip pins related to the device under test and the processor core corresponding to the host computer module, so as to monitor the chip software memory related to the device under test from the input / output signals. Among them, the monitored chip software memory is used for test analysis, and the test working condition information includes test scenario data, test rule information, and expected result information. The present application builds a test system that can implement boundary scan testing based on the open-source API interface of a third-party device, the Lauterbach emulator, and can call the API interface of the Lauterbach emulator for implementing boundary scan testing based on the test case, read the input / output signals between the chip pins related to the device under test and the processor core corresponding to the host computer module, so as to monitor the chip software memory related to the device under test from the input / output signals, and further accurately determine whether the relevant software operation conforms to the designed operation strategy during the test process of the integrated device, which can improve the test accuracy.

[0041] The above description is only an overview of the technical solution of the present application. In order to understand the technical means of the present application more clearly, it can be implemented according to the content of the specification. And in order to make the above and other purposes, features and advantages of the present application more obvious and understandable, the following specifically illustrates the specific implementation manners of the present application. Brief Description of the Drawings

[0042] The drawings herein are incorporated into and constitute a part of this specification, showing embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application.

[0043] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, other drawings can also be obtained based on these drawings without creative efforts.

[0044] Figure 1 It shows a schematic structural diagram of a test system provided by an embodiment of the present application;

[0045] Figure 2 It shows a schematic flow diagram of a test method provided by an embodiment of the present application;

[0046] Figure 3 It shows a schematic diagram of an example architecture of a test system provided by an embodiment of the present application;

[0047] Figure 4 It shows a schematic structural diagram of a test device provided by an embodiment of the present application. Detailed Description of the Embodiments

[0048] In order to be able to understand the above objects, features and advantages of the present application more clearly, the following will further describe the solution of the present application. It should be noted that, without conflict, the embodiments of the present application and the features in the embodiments can be combined with each other.

[0049] In order to improve the technical problem that the current test system in the prior art does not have the function of boundary scan testing, cannot monitor the software memory of the chip, and thus cannot determine whether the relevant software operation conforms to the designed operation strategy during the testing process of the integrated device of the corresponding type, that is, cannot implement boundary scan testing, which affects the test accuracy. This embodiment provides a test system, as Figure 1 shown, this test system may include a host computer module 11 and a Lauterbach emulator 12.

[0050] Among them, the Lauterbach emulator 12 is connected to the computer device where the host computer module 11 is located, and the Lauterbach emulator 12 is also connected to the device under test 13. The host computer module 11 is used to generate test cases for the test working condition information through a preset tool, and based on the test cases, call the API interface of the Lauterbach emulator 12 for boundary scan testing to read the input and output signals between the chip pins related to the device under test 13 and the corresponding processor core of the host computer module 11, so as to monitor the chip software memory related to the device under test 13 from the input and output signals, where the monitored chip software memory is used for test analysis.

[0051] Among them, the test working condition information may include test scenario data (such as test conditions, basic parameter data, etc.), test rule information (such as method functions, execution steps, etc.), and expected result information (such as expected results, which may include different expected results of the relevant test data of the device under test 13, etc.). In this embodiment, the test working condition information can be used to generate corresponding test cases with one key through a specific preset tool (such as a specific script tool).

[0052] The third-party device, the Lauterbach emulator 12, can be an embedded CPU emulator, which is developed and produced by Lauterbach Company in Germany. In this embodiment, the host computer module 11 can be a software host computer capable of calling and controlling the emulator class API interface, such as a software host computer built using the Python language or the C++ language. Through this software host computer (i.e., the host computer module 11), the calling control of the API interface of the Lauterbach emulator is realized, the monitoring of the chip software memory related to the device under test 13 is realized, and the test of boundary scan is realized. Compared with the current manual test of boundary scan, this system can effectively improve the work efficiency and the real-time performance of the test process.

[0053] For example, at the physical level, the Lauterbach emulator 12 needs to be connected to the JTAG interface of the device under test 13, and the API interface of the Lauterbach emulator 12 is to implement the interaction of the JTAG protocol, and the interaction of the JTAG protocol can be realized by using the API interface of the Lauterbach emulator 12. Among them, a scanning unit can be specifically added between the chip pins and the corresponding processor core of the host computer module 11. This scanning unit isolates the input signal or output signal between the chip pins and the processor core, and can read and write the values of the corresponding memory of these signals according to instructions.

[0054] Based on the open-source API interface of the third-party device Lauterbach emulator, this embodiment constructs a test system that can implement boundary scan testing. It can call the API interface of the Lauterbach emulator for boundary scan testing based on test cases, read the input and output signals between the chip pins related to the device under test and the corresponding processor core of the host computer module, so as to monitor the chip software memory related to the device under test from the input and output signals. Furthermore, during the testing process of the corresponding type of integrated device, it can accurately determine whether the relevant software operation conforms to the designed operation strategy, improving the testing accuracy.

[0055] Furthermore, in some embodiments, this test system may further include at least one of a communication simulation board, an IO simulation board, and a sensor simulation board.

[0056] Exemplarily, the communication simulation board may include a Serial Peripheral Interface (SPI) simulation board, and / or an Inter-Integrated Circuit (IIC) simulation board, and / or a Controller Area Network (CAN) simulation board, and / or a Local Interconnect Network (LIN) simulation board, and / or an Ethernet simulation board, etc.; this communication simulation board is connected to the computer device where the host computer module 11 is located, and the communication simulation board is also connected to the device under test 13; the host computer module 11 is further configured to call the API interface of the communication simulation board based on test cases to control the communication device related to the device under test 13 and monitor the communication data of this communication device, where the monitored communication data is used for test analysis.

[0057] For example, the host computer module 11 may also be a software host computer capable of calling and controlling the communication class API interface, such as a software host computer built using the Python language or the C++ language. Through this software host computer (i.e., the host computer module 11), the API interfaces of the SPI simulation board, IIC simulation board, CAN simulation board, LIN simulation board, Ethernet simulation board, etc. can be called and controlled, thereby realizing the control of the communication device related to the device under test 13 and monitoring the communication data.

[0058] The IO simulation board may include a Digital Input / Output (ID / OD) simulation board, and / or an Analog Input / Output (IA / OA) simulation board, and / or an Input / Output of Pulse Width Modulation (PWM) (IP / OP) simulation board, and / or an H-bridge Output (Hbri) simulation board, etc.; this IO simulation board is connected to the computer device where the host computer module 11 is located, and this IO simulation board is also connected to the device under test 13; the host computer module 11 is further configured to call the API interface of the IO simulation board based on test cases to control the IO device related to the device under test 13 and monitor the input and output data of the IO device, where the monitored input and output data is used for test analysis.

[0059] For example, the host computer module 11 can also be a software host computer capable of calling and controlling an IO class API interface. For example, the software host computer can be built using the Python language or the C++ language. Through this software host computer (i.e., the host computer module 11), the calling and control of the API interfaces of the ID / OD simulation board, IA / OA simulation board, IP / OP simulation board, Hbri simulation board, etc. are realized, and then the control of the relevant IO devices of the device under test 13 and the monitoring of the input and output data of the IO devices are realized.

[0060] The sensor class simulation board can include: an inertial sensor (IMU) simulation board, and / or a peripheral sensor interface (PSI5) simulation board, and / or a camera simulation board, and / or a radar simulation board, etc.; the sensor class simulation board is connected to the computer device where the host computer module 11 is located, and the sensor class simulation board is also connected to the device under test 13; the host computer module 11 is also used to call the API interface of the sensor class simulation board based on the test case, control the sensor devices related to the device under test 13, and monitor the sensor signals of the sensor devices, where the monitored sensor signals are used for test analysis.

[0061] For example, the host computer module 11 can also be a software host computer capable of calling and controlling a sensor class API interface. For example, the software host computer can be built using the Python language or the C++ language. Through this software host computer (i.e., the host computer module 11), the calling and control of the API interfaces of the IMU simulation board, PSI5 simulation board, camera simulation board, radar simulation board, etc. are realized, and then the control of the sensor devices related to the device under test 13 and the monitoring of the sensor signal data of the sensor devices are realized.

[0062] In some embodiments, the device under test 13 can include a device under test controller and / or a device under test chip. Based on the open-source API interfaces of the IO class simulation board, communication class simulation board, sensor class simulation board, and Lauterbach emulator, this embodiment builds a test system for realizing boundary scan automation. During the process of automatically testing the device under test controller and / or the device under test chip, the relevant chip software memory is monitored to determine whether the relevant software operation conforms to the designed operation strategy to meet different test requirements, and the test accuracy can be improved.

[0063] Further, to illustrate the specific test process of the above test system, based on Figure 1 the test system shown in the embodiment, this embodiment provides a test method, which can be specifically applied to the execution of the host computer module 11, such as Figure 2 shown, and the method includes:

[0064] Step 201, obtain test condition information.

[0065] For this embodiment, the test condition information can be pre-configured. For example, the test conditions are edited in a certain file, such as an EXCEL table file containing information related to the test conditions. The test condition information involved in this embodiment can be test condition information related to vehicle functions.

[0066] For example, the test objective is to test the performance of the battery system when the vehicle is running in winter. The device under test is the battery system device. The test scenario data can include corresponding test scenario data (such as temperature values, humidity values, etc. corresponding to different times), test rule information (such as the test method for the battery system performance and specific function functions to be called, etc.), and expected result information (such as the expected battery performance values at different temperature values and humidity values).

[0067] Step 202: Generate test cases from the test condition information through a preset tool.

[0068] In the host computer module (software host computer) of this embodiment, the edited test conditions can be used to generate corresponding automation scripts through a preset tool to obtain test cases.

[0069] Step 203: Based on the test cases, call the API interface of the Lauterbach emulator to read the input and output signals between the chip pins related to the device under test and the corresponding processor core of the host computer module.

[0070] Step 204: Monitor the chip software memory related to the device under test from the input and output signals.

[0071] This embodiment can analyze based on the generated test cases to find the corresponding API interface combinations, which can include the API interface of the Lauterbach emulator, and then call the API interface of the Lauterbach emulator to monitor the chip software memory related to the device under test, and further monitor the relevant information of the chip software memory.

[0072] Step 205: Perform test analysis on the monitored chip software memory to obtain test results.

[0073] For example, compare the monitored chip software memory with a preset standard value, and then it can be determined whether the relevant functions of the device under test are qualified. If the chip software memory is within the standard range, it means that the relevant functions of the device under test meet the requirements.

[0074] Such as Figure 1In the illustrated embodiment, the test system may further include: a communication simulation board, and / or an IO simulation board, and / or a sensor simulation board. That is, in this embodiment, the API interfaces of the communication simulation board, and / or the API interfaces of the IO simulation board, and / or the API interfaces of the sensor simulation board can also be called. Therefore, in this embodiment, by calling the API interface of the Lauterbach emulator to monitor the chip software memory related to the device under test, in addition to monitoring the relevant information of the chip software memory, the data acquisition of the communication API interface, and / or the data acquisition of the sensor API interface, and / or the data acquisition of the IO API interface can also be observed. For example, the communication data of the communication device related to the device under test is monitored, and / or the input and output data of the IO device related to the device under test is monitored, and / or the sensor signal of the sensor device related to the device under test is monitored. Then, by comprehensively analyzing these monitored data, a more accurate test result can be obtained.

[0075] By applying the technical solution of this embodiment, first, the test working condition information is obtained; then, the test working condition information is used to generate test cases; then, based on the test cases, the API interface of the Lauterbach emulator is called to control and monitor the chip software memory related to the device under test; furthermore, based on the monitored chip software memory, test analysis is performed to obtain the test result. Based on the open-source API interface of the third-party device Lauterbach emulator, this embodiment constructs a test system that can implement boundary scan testing, which can control and monitor the chip software memory. Furthermore, during the testing process of the corresponding type of integrated device, it can accurately determine whether the relevant software operation conforms to the designed operation strategy, and can improve the test accuracy.

[0076] In some examples, before step 204, the method of this embodiment further includes: based on the test cases obtained in step 202, calling the API interface of the communication simulation board to control the communication device related to the device under test and monitor the communication data of the communication device; and / or, based on the test cases obtained in step 202, calling the API interface of the IO simulation board to control the IO device related to the device under test and monitor the input and output data of the IO device; and / or, based on the test cases obtained in step 202, calling the API interface of the sensor simulation board to control the sensor device related to the device under test and monitor the sensor signal of the sensor device.

[0077] Further, in some examples, based on the above example content, correspondingly, step 204 may specifically include: performing test analysis based on the monitored chip software memory, combined with the monitored communication data (communication data of the communication device related to the device under test), and / or input / output data (input / output data of the IO device related to the device under test), and / or sensor signals (sensor signals of the sensor device related to the device under test), to obtain a test result.

[0078] Exemplarily, step 204 may specifically include: determining whether the communication data of the communication device reaches a first expected result; and / or, determining whether the input / output data of the IO device reaches a second expected result; and / or, determining whether the sensor signals of the sensor device reach a third expected result. The first expected result, the second expected result, and the third expected result may be obtained from the expected result information of the test condition information.

[0079] If the communication data reaches the first expected result, and / or the input / output data reaches the second expected result, and / or the sensor signals reach the third expected result, it is necessary to continue to determine whether the monitored chip software memory reaches a fourth expected result, and if the chip software memory reaches the fourth expected result, it is determined that the test passes. Similarly, the fourth expected result may be obtained from the expected result information of the test condition information.

[0080] For example, for the IO test: physically, the Lauterbach emulator needs to be connected to the JTAG interface of the device under test, and the pins of the IO simulation board need to be connected to the IO pins of the device under test. After controlling the input and output of the pins of the IO simulation board, determine whether the input / output data corresponding to the IO pin reaches the corresponding expected value a. If it does not reach the corresponding expected value a, it means that the device under test fails the IO test; if it reaches the corresponding expected value a, then read and write the value of the variable memory corresponding to the IO pin of the device under test according to the API interface of the Lauterbach emulator called, and determine whether the memory value reaches the corresponding expected value b. If the memory value reaches the corresponding expected value b, it means that the device under test passes the IO test, and if the memory value does not reach the corresponding expected value b, it means that the device under test fails the IO test. Through the solution of this embodiment, the chip software memory related to the device under test can be combined to comprehensively analyze the IO test result of the device under test, and the accuracy of the test can be improved.

[0081] Such as Figure 3As shown in the figure, this embodiment can analyze based on the generated test cases to find the corresponding API interface combinations, which may include the API interfaces of the Lauterbach emulator, and / or the API interfaces of the communication simulation board, and / or the API interfaces of the IO simulation board, and / or the API interfaces of the sensor simulation board. Then, these API interfaces are called to control the devices related to the device under test, and by observing the feedback of these API interfaces, the relevant data of the monitored device is obtained, and then comprehensive test analysis can be realized to obtain more accurate test results.

[0082] For example, based on the generated test cases, the API interfaces of the IO simulation board and the Lauterbach emulator API interfaces are called to control the IO devices and chip software memory related to the device under test, and observe the feedback of the API interfaces of the communication simulation board, and / or the feedback of the API interfaces of the sensor simulation board, and / or the feedback of the API interfaces of the IO simulation board, and / or the feedback of the Lauterbach emulator API interfaces. Then, comprehensive test analysis can be realized based on the monitored relevant data to obtain more accurate test results.

[0083] For another example, based on the generated test cases, the API interfaces of the communication simulation board are called to control the communication devices related to the device under test, and observe the feedback of the API interfaces of the communication simulation board, and / or the feedback of the API interfaces of the sensor simulation board, and / or the feedback of the API interfaces of the IO simulation board, and / or the feedback of the Lauterbach emulator API interfaces. Then, comprehensive test analysis can be realized based on the monitored relevant data to obtain more accurate test results.

[0084] This embodiment is based on the open-source API interfaces of the IO simulation board, the communication simulation board, the sensor simulation board, and the Lauterbach emulator to build a test system for realizing boundary scan automation. During the process of automatically testing the controller under test and / or the chip under test, the relevant chip software memory is monitored to determine whether the relevant software operation conforms to the designed operation strategy to meet different test requirements and improve the test accuracy.

[0085] Further, as Figure 3 a specific implementation of the method shown, this embodiment provides a test device, as Figure 4 shown, the device includes: an acquisition unit 31, a generation unit 32, a call unit 33, and an analysis unit 34.

[0086] The acquisition unit 31 is configured to acquire test condition information, and the test condition information includes test scenario data, test rule information, and expected result information;

[0087] A generating unit 32, configured to generate test cases from the test condition information through a preset tool;

[0088] An invoking unit 33, configured to, based on the test cases, invoke an API interface of a Lauterbach emulator for implementing boundary scan testing, read input and output signals between chip pins related to the device under test and corresponding processor cores of a host computer module; and monitor chip software memory related to the device under test from the input and output signals;

[0089] An analyzing unit 34, configured to perform test analysis on the monitored chip software memory to obtain test results.

[0090] In some examples, the invoking unit 33 is further configured to, based on the test cases, invoke an API interface of a communication type simulation board to control communication devices related to the device under test and monitor communication data of the communication devices; and / or, based on the test cases, invoke an API interface of an IO type simulation board to control IO devices related to the device under test and monitor input and output data of the IO devices; and / or, based on the test cases, invoke an API interface of a sensor type simulation board to control sensor devices related to the device under test and monitor sensor signals of the sensor devices.

[0091] In some examples, the analyzing unit 34 is specifically configured to determine whether the communication data of the communication devices reaches a first expected result; and / or, determine whether the input and output data of the IO devices reaches a second expected result; and / or, determine whether the sensor signals of the sensor devices reach a third expected result; if the communication data reaches the first expected result, and / or the input and output data reaches the second expected result, and / or the sensor signals reach the third expected result, then determine whether the chip software memory reaches a fourth expected result, and determine that the test passes when the chip software memory reaches the fourth expected result.

[0092] It should be noted that other corresponding descriptions of each functional unit involved in a test device provided in this embodiment can refer to the corresponding descriptions in the embodiment in Figure 3 and will not be elaborated here.

[0093] Based on the method as shown in Figure 3 above, correspondingly, this embodiment further provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the method as shown in Figure 3 above is implemented.

[0094] Based on such understanding, the technical solution of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, a USB flash drive, a mobile hard disk, etc.), and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods of various implementation scenarios of the present application.

[0095] Based on the above-mentioned method as Figure 3 shown, and Figure 4 the virtual device embodiment as shown, in order to achieve the above object, the embodiment of the present application further provides an electronic device, which can be configured on the vehicle side (such as a new energy vehicle), and the device includes a storage medium and a processor; the storage medium is used for storing a computer program; the processor is used for executing the computer program to implement the method as Figure 3 shown.

[0096] Optionally, the above-mentioned physical device may further include a user interface, a network interface, a camera, a radio frequency (RF) circuit, sensors, an audio circuit, a WI-FI module, etc. The user interface may include a display screen (Display), an input unit such as a keyboard (Keyboard), etc., and the optional user interface may further include a USB interface, a card reader interface, etc. The network interface may optionally include a standard wired interface, a wireless interface (such as a WI-FI interface), etc.

[0097] Those skilled in the art can understand that the above-mentioned physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine some components, or arrange different components.

[0098] The storage medium may further include an operating system and a network communication module. The operating system is a program for managing the hardware and software resources of the above-mentioned physical device, and supports the operation of an information processing program and other software and / or programs. The network communication module is used for realizing communication between the components inside the storage medium, and communication with other hardware and software in the information processing physical device.

[0099] Furthermore, the embodiment of the present application further provides a vehicle, including the above-mentioned test system or electronic device.

[0100] Through the description of the above embodiments, those skilled in the art can clearly understand that the present application can be implemented by means of software plus a necessary general hardware platform, or can also be implemented by hardware. By applying the solution of this embodiment, based on the open-source API interfaces of the IO class simulation board, communication class simulation board, sensor class simulation board, and Lauterbach emulator, a test system for realizing boundary scan automation is built. During the process of automatically testing the controller under test and / or the chip under test, the relevant chip software memory is monitored to determine whether the relevant software operation conforms to the designed operation strategy to meet different test requirements and improve the test accuracy.

[0101] It should be noted that in this article, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the term "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or device. Without further limitation, an element defined by the statement "comprising a..." does not exclude the existence of additional identical elements in the process, method, article, or device comprising the element.

[0102] The above are only specific embodiments of the present application, enabling those skilled in the art to understand or implement the present application. Various modifications to these embodiments will be obvious to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to these embodiments described herein, but rather to the broadest scope consistent with the principles and novel features claimed herein.

Claims

1. A test system, characterized in that, it includes: a host computer module and a Lauterbach emulator; the Lauterbach emulator is connected to the computer device where the host computer module is located, and the Lauterbach emulator is also connected to the device under test; the host computer module is used to generate test cases for the test working condition information through a preset tool, and based on the test cases, call the API interface of the Lauterbach emulator for implementing boundary scan testing, read the input and output signals between the chip pins related to the device under test and the corresponding processor core of the host computer module, so as to monitor the chip software memory related to the device under test from the input and output signals, wherein, the monitored chip software memory is used for test analysis, and the test working condition information includes test scenario data, test rule information and expected result information.

2. The test system according to claim 1, characterized in that, the test system further includes: a communication class emulator board, and / or an IO class emulator board, and / or a sensor class emulator board respectively connected to the computer device and the device under test; the host computer module is further used to call the API interface of the communication class emulator board based on the test cases, control the communication device related to the device under test, and monitor the communication data of the communication device; and / or, call the API interface of the IO class emulator board based on the test cases, control the IO device related to the device under test, and monitor the input and output data of the IO device; and / or, call the API interface of the sensor class emulator board based on the test cases, control the sensor device related to the device under test, and monitor the sensor signal of the sensor device.

3. The test system according to claim 2, characterized in that, the communication class emulator board includes: an SPI emulator board, and / or an IIC emulator board, and / or a CAN emulator board, and / or a LIN emulator board, and / or an Ethernet emulator board; the IO class emulator board includes: an ID / OD emulator board, and / or an IA / OA emulator board, and / or an IP / OP emulator board, and / or an Hbri emulator board; the sensor class emulator board includes: an IMU emulator board, and / or a PSI5 emulator board, and / or a camera emulator board, and / or a radar emulator board.

4. A test method, characterized in that, it includes: obtaining test working condition information, where the test working condition information includes test scenario data, test rule information and expected result information; generating test cases for the test working condition information through a preset tool; calling the API interface of the Lauterbach emulator for implementing boundary scan testing based on the test cases, and reading the input and output signals between the chip pins related to the device under test and the corresponding processor core of the host computer module; monitoring the chip software memory related to the device under test from the input and output signals; performing test analysis on the monitored chip software memory to obtain a test result.

5. The method according to claim 4, characterized in that, Before testing and analyzing the monitored chip software memory to obtain a test result, the method further includes: Based on the test case, calling the API interface of the communication class simulation board to control the communication device related to the device under test and monitor the communication data of the communication device; and / or, Based on the test case, calling the API interface of the IO class simulation board to control the IO device related to the device under test and monitor the input and output data of the IO device; and / or, Based on the test case, calling the API interface of the sensor class simulation board to control the sensor device related to the device under test and monitor the sensor signal of the sensor device.

6. The method according to claim 5, wherein, the testing and analyzing the monitored chip software memory to obtain a test result includes: judging whether the communication data of the communication device reaches a first expected result; and / or, judging whether the input and output data of the IO device reaches a second expected result; and / or, judging whether the sensor signal of the sensor device reaches a third expected result; if the communication data reaches the first expected result, and / or the input and output data reaches the second expected result, and / or the sensor signal reaches the third expected result, then judging whether the chip software memory reaches a fourth expected result, and determining that the test passes when the chip software memory reaches the fourth expected result.

7. A test device, wherein, the device includes: an acquisition unit configured to acquire test condition information, where the test condition information includes test scenario data, test rule information, and expected result information; a generation unit configured to generate a test case from the test condition information through a preset tool; a call unit configured to, based on the test case, call the API interface of the Lauterbach emulator for implementing boundary scan testing to read the input and output signals between the chip pins related to the device under test and the corresponding processor core of the host computer module; and monitor the chip software memory related to the device under test from the input and output signals; an analysis unit configured to test and analyze the monitored chip software memory to obtain a test result.

8. A computer-readable storage medium having a computer program stored thereon, wherein, the computer program, when executed by a processor, implements the method according to any one of claims 4 to 6.

9. An electronic device including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein, the processor, when executing the computer program, implements the method according to any one of claims 4 to 6.

10. A vehicle, wherein, it includes: the system according to any one of claims 1 to 3, or the electronic device according to claim 9.

Images