Automated testing method, apparatus, computer device, and storage medium

Abstract

This disclosure relates to an automated testing method, apparatus, computer device, and storage medium. It includes determining an operating mode based on configuration information in response to the startup of a target electronic device, wherein the target electronic device carries a target chip; when the operating mode is test mode, loading a test environment, wherein the test environment contains multiple test files, and the multiple test files have a unified calling interface; in the test environment, according to test instructions, calling the target test file from the multiple test files through the calling interface to execute tests, thereby testing the functional modules corresponding to the target chip. As can be seen, the embodiments of this application can call the target test file from multiple test files according to test instructions via the calling interface to execute tests, thereby achieving efficient and flexible testing of the functional modules corresponding to the target chip, improving the versatility and maintainability of test files, simplifying the test calling logic, and enhancing the scalability and stability of the test process.

Description

Technical Field

[0001] This disclosure relates to the field of firmware testing technology, and in particular to an automated testing method, apparatus, computer equipment, and storage medium. Background Technology

[0002] In the early stages of chip development, functional verification and performance evaluation are core aspects of ensuring chip stability. Researchers need to conduct comprehensive verification of the chip code and functional modules. Typically, chip verification involves mounting the chip under test on a corresponding electronic device (such as a development board or prototype). By loading test programs during the startup and operation of the electronic device, access and control of the chip's internal functional modules can be achieved, thereby completing functional testing and performance evaluation.

[0003] Existing technologies primarily rely on manual testing, requiring R&D personnel to repeatedly develop test plans for different chips and versions. This is labor-intensive, inefficient, and makes it difficult to simulate complex concurrency and high-load operation in real-world scenarios, resulting in the failure to expose potential chip defects in advance. Although UEFI provides standardized interfaces to decouple drivers from hardware, during the EDK2 startup phase, the test logic remains strongly coupled with specific chips. Test scripts need to be developed temporarily for specific chips, making them unusable across different chips. Furthermore, the testing of each module is independent, failing to form a unified test chain and environment, further restricting R&D efficiency. Summary of the Invention

[0004] In view of the above, this disclosure provides an automated testing method, apparatus, computer equipment, and storage medium to solve the problems existing in the related art.

[0005] A first aspect of this disclosure provides an automated testing method, the method comprising: responding to the startup of a target electronic device, determining an operating mode based on configuration information, wherein the target electronic device is equipped with a target chip; when the operating mode is a test mode, loading a test environment, wherein the test environment contains multiple test files, the multiple test files having a unified calling interface; and in the test environment, calling a target test file from the multiple test files through the calling interface according to test instructions to perform tests on the functional modules corresponding to the target chip.

[0006] A second aspect of this disclosure provides an automated testing apparatus applied to the automated test selection method of the first aspect. The apparatus includes: a determining module, configured to determine an operating mode based on configuration information in response to the startup of a target electronic device, wherein the target electronic device carries a target chip; a loading module, configured to load a test environment when the operating mode is a test mode, wherein the test environment contains multiple test files, and the multiple test files have a unified calling interface; and a calling module, configured to call the target test file from the multiple test files through the calling interface in the test environment according to test instructions to perform tests on the functional modules corresponding to the target chip.

[0007] A third aspect of this disclosure provides a computer device including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the above-described automated testing method.

[0008] A fourth aspect of this disclosure provides a computer-readable storage medium having a computer program / operation instructions stored thereon, which, when executed by a processor, implement the steps of the above-described automated testing method.

[0009] According to a fifth aspect of this disclosure, a computer program product is provided that, when executed by a processor, implements the steps of the above-described automated testing method.

[0010] The at least one technical solution adopted in this embodiment can achieve the following beneficial effects: by responding to the startup of the target electronic device and determining the operating mode according to configuration information, wherein the target electronic device is equipped with a target chip; when the operating mode is test mode, a test environment is loaded, wherein the test environment contains multiple test files, and the multiple test files have a unified calling interface; in the test environment, the target test file is called from the multiple test files through the calling interface according to the test instructions to perform the test, so as to test the functional modules corresponding to the target chip. It can be seen that, by responding to the startup of the target electronic device and determining the operating mode according to configuration information, and loading a test environment with multiple built-in test files having a unified calling interface in test mode, the target test file can be called from the multiple test files through the calling interface according to the test instructions to perform the test, thereby achieving efficient and flexible testing of the functional modules corresponding to the target chip, improving the universality and maintainability of the test files, simplifying the test calling logic, and enhancing the scalability and stability of the test process. Attached Figure Description

[0011] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0012] Figure 1 A flowchart illustrating an automated testing method provided in one embodiment of this disclosure;

[0013] Figure 2 This is a schematic diagram of the code architecture of EDK2 provided in an embodiment of the present disclosure; Figure 3 This is a schematic diagram of the structure of an automated testing device provided in one embodiment of the present disclosure; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure; Figure 5 This is a schematic diagram of the structure of a computer system provided in an embodiment of the present disclosure; Figure 6 A schematic diagram of a computer program product provided according to an embodiment of this disclosure. Detailed Implementation

[0014] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0015] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0016] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below. It should be noted that the concepts of "first", "second", etc., used in this disclosure are only used to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0017] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0018] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0019] In the early stages of chip development, functional verification and performance evaluation are core aspects of ensuring chip stability and reliability. During this phase, developers can conduct comprehensive verification of the chip code and functional modules using numerous test cases to identify logical vulnerabilities, performance bottlenecks, and compatibility issues. In related technologies, testing at this stage is primarily manual. Specifically, single-function tests can be used to verify the basic operational capabilities of each functional module within the chip. Simultaneously, stress testing can be used to simulate the chip's operating state under high-load scenarios, ensuring that the chip can still function normally under extreme conditions.

[0020] However, with the development of chip technology, manual testing has gradually become insufficient to meet the demands of large-scale and refined chip R&D, and its core pain points are becoming increasingly prominent. On the one hand, manual testing heavily relies on the professional skills and operational experience of R&D personnel. Each driver module's developers need to conduct extensive manual testing on their assigned functional modules, resulting in significant manpower investment and often requiring the formation of dedicated testing teams, leading to high labor costs. Simultaneously, manually executing test cases is inefficient, failing to cover all potential chip operating scenarios, especially in accurately simulating complex multi-module concurrent calls and dynamic load switching in real-world application environments, and lacking effective stress testing conditions. This makes it difficult to discover some deeply hidden chip code defects in advance, failing to effectively expose potential problems in real-world scenarios, thereby increasing the cost and cycle of subsequent chip iteration and optimization.

[0021] On the other hand, different series and models of chips differ significantly in hardware architecture, interface specifications, and functional module configurations. Even different iterations of the same chip may have subtle adjustments to their underlying hardware. This forces R&D personnel to redesign test plans, write test cases, and debug test environments for each chip and each version, making it difficult to reuse existing test plans and significantly increasing the time and manpower costs of test development. Furthermore, the independent testing by each driver module developer, lacking effective collaboration and integration, prevents the formation of a complete test chain and a unified test environment, further increasing test development costs and hindering the overall efficiency of chip development.

[0022] In related technologies, the Unified Extensible Firmware Interface (UEFI) can be used as a next-generation firmware interface standard to replace the traditional Basic Input Output System (BIOS), thus solving the problem of interface differences between different chips. UEFI possesses the core characteristics of modularity, scalability, and standardization. Its internal driver modules are designed and developed as independent function packages, each encapsulating specific hardware driver logic and functional implementations. More importantly, UEFI defines a unified upper-layer application calling interface. Upper-layer applications can call different driver modules through UEFI without needing to concern themselves with the specific details of the underlying hardware, thereby decoupling the driver code from the hardware platform and significantly improving the reusability of code across different chip products and hardware architectures.

[0023] The Extensible Firmware Interface Development Kit 2 (EDK2), as a mainstream development kit for UEFI, is the core carrier for chip firmware development. Its boot process covers key aspects such as chip initialization, driver loading, and module scheduling, and is a core scenario for early chip testing. However, in actual chip development and testing, although UEFI provides standardized calling interfaces and modular driver architectures, developers usually still rely on test scripts or single-use test scripts developed temporarily for specific chips when verifying chip functionality during the EDK2 boot phase.

[0024] However, due to the lack of an automated testing framework deeply integrated with the EDK2 startup process, the test logic and specific test cases are tightly coupled with the temporarily written chip code, deeply bound to the chip hardware architecture, functional configuration, and underlying implementation. They cannot exist independently of a specific chip, making it difficult to reuse and migrate the test logic and specific test cases directly between different chips, resulting in repeated development costs during new chip development. Furthermore, in related technologies, manual testing is still required during the EDK2 startup phase, making it impossible to automatically conduct complex stress tests or efficiently simulate high-load calls in real-world scenarios. This prevents the early detection of potential chip defects. In addition, developers of each driver module test independently, failing to form a unified and complete test chain and collaborative testing environment. This easily leads to disconnects in testing and verification between modules, incomplete coverage of interaction scenarios, and further reduces test completeness and overall development efficiency.

[0025] To address the aforementioned issues, this disclosure provides an automated testing method. In response to the startup of a target electronic device, an operating mode is determined based on configuration information. The target electronic device carries a target chip. When the operating mode is test mode, a test environment is loaded. This test environment contains multiple test files, each with a unified calling interface. Within the test environment, test instructions are executed by calling the target test file from the multiple test files via the calling interface to test the functional modules corresponding to the target chip. Therefore, this embodiment of the application, by responding to the startup of the target electronic device and determining the operating mode based on configuration information, loads a test environment with multiple built-in test files possessing a unified calling interface in test mode. This allows for efficient and flexible testing of the functional modules corresponding to the target chip by calling the target test file from the multiple test files via the calling interface according to test instructions. This improves the versatility and maintainability of the test files, simplifies the test calling logic, and enhances the scalability and stability of the testing process.

[0026] The automated testing method provided in this disclosure can be executed by a terminal or by a chip applied to the terminal.

[0027] For example, the aforementioned terminals may include one or more of the following: mobile phones, tablets, wearable devices, in-vehicle devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, handheld computers (PDAs), and wearable devices based on augmented reality (AR) and / or virtual reality (VR) technologies. They may also include, but are not limited to, remote control devices, wearable devices, streetlights, home appliances, and other smart terminals. This disclosure does not impose specific limitations on these aspects.

[0028] Figure 1 This is a flowchart illustrating an automated testing method provided in one embodiment of the present disclosure. Figure 1 As shown, in implementation Figure 1 Before proceeding with the method described, the test firmware needs to be prepared and deployed, which includes the following preliminary steps: First, a new TestApp Package is created within the EDK2 code architecture. This package contains multiple test files, each corresponding to one or more test cases, used to verify specific driver modules. The test files call underlying driver modules such as UFS DXE, I2C DXE, and GPIO DXE through UEFI standard interfaces, rather than directly manipulating hardware registers, thus decoupling the test logic from the hardware implementation. It should be understood that the specific process of creating this TestApp Package can be found in [reference needed]. Figure 2 Related descriptions.

[0029] Secondly, the complete code architecture containing the test function package is compiled into a UEFI firmware image using the EDK2 compilation toolchain. This image file can be, for example, an EDK2-Shell-sign.bin file, which integrates the test environment and all test files.

[0030] Finally, the compiled UEFI firmware image is burned into the memory of the target electronic device, replacing the original boot firmware. After the above deployment is completed, the automated testing method provided in this embodiment can be executed when the target electronic device restarts.

[0031] like Figure 1 As shown, the automated testing method provided in this disclosure includes: S101, in response to the startup of the target electronic device, determines the operating mode based on the configuration information, wherein the target electronic device is equipped with the target chip.

[0032] In some embodiments, after the target electronic device is powered on, the UEFI firmware built based on EDK2 begins to boot. The UEFI firmware first completes the necessary initialization operations for the target chip, and then enters the key stage of the boot process. In this stage, the UEFI firmware can read preset configuration information and determine the operating mode of this boot according to the configuration information, so as to choose to enter a non-test mode (such as the normal system boot process) or enter a test mode.

[0033] The target electronic device can be any of the development boards or terminal products equipped with the target chip, specifically a mobile phone, tablet, IoT device, or any electronic device requiring chip-level testing. The UEFI firmware, as the underlying firmware during the boot process of the target electronic device, is responsible for hardware initialization, driver loading, and boot process control. It should be noted that the UEFI firmware is a compiled product based on EDK2, burned into the memory of the target electronic device, and loaded and executed from this memory when the target chip boots.

[0034] In some embodiments, the configuration information described in this disclosure refers to control parameters pre-set in the target electronic device to guide the UEFI firmware in selecting the operating mode during the startup phase of the target electronic device. This configuration information can be one or more flag bits, UEFI variables, or configuration files stored in non-volatile memory, or it can be a trigger signal dynamically acquired through hardware pin states or external device input. The core function of the configuration information is to enable the UEFI firmware to determine, in the early stages of the startup process, whether to enter the normal system startup process (non-test mode) or the test mode specifically designed for chip functional verification, thereby achieving automated guidance of the test process.

[0035] As a preferred embodiment, the configuration information can be pre-stored in the memory of the target electronic device. Specifically, a UEFI variable or a specific configuration flag can be preset in the UEFI firmware. This UEFI variable or configuration flag is stored in a specific partition of the serial peripheral interface flash memory or non-volatile random access memory of the target electronic device. Here, the value of the UEFI variable or configuration flag can be directly set by the R&D personnel when compiling the UEFI firmware based on EDK2, or it can be written by a programming tool when flashing firmware on the chip production line, or it can be modified by firmware upgrade after product delivery.

[0036] In other embodiments, configuration information can also be determined by detecting the initial level state of specific hardware pins of the target electronic device. For example, during the startup phase of the target electronic device, the UEFI firmware reads the level of a preset test mode detection pin. If the pin is high, it determines that the startup has entered test mode; if it is low, it enters non-test mode. This method is suitable for R&D debugging or production line testing scenarios that require hardware to force entry into test mode. In other embodiments, configuration information can also be dynamically provided by an external device during startup. For example, when the target electronic device starts up, the UEFI firmware detects whether an external debugging tool is connected, or receives a specific handshake signal from a PC via a serial port, and determines the operating mode based on whether a preset instruction is received. It should be noted that the embodiments of this application do not limit the specific method of obtaining configuration information. As long as it can provide a basis for mode selection for the UEFI firmware during the startup phase of the target electronic device, it falls within the protection scope of the embodiments of this application.

[0037] As can be seen, this embodiment of the application introduces a configuration information judgment mechanism during the startup phase of the target electronic device, allowing R&D personnel to flexibly choose to enter the normal startup process or test mode according to actual needs. The configuration information can be obtained in various ways, such as being stored in memory, detected through hardware pins, or dynamically provided by external devices. These different configuration methods can meet the needs of different scenarios such as R&D debugging, production line testing, and field maintenance, without the need to develop different firmware versions for each scenario. Simultaneously, by making the determination of the operating mode independent of the normal startup process, the test environment is only loaded and executed in test mode, avoiding the intrusion of test code into the normal startup process and ensuring the startup efficiency and operational stability of the target electronic device in non-test mode.

[0038] S102, when the operating mode is test mode, loads the test environment, which contains multiple test files. These test files share a unified calling interface. Here, the unified calling interface can be a UEFI standard interface. The test files use this interface to call the underlying driver module, thus decoupling the test logic from the hardware platform.

[0039] In some embodiments, when the UEFI firmware determines that the current boot mode is test mode based on configuration information, the target electronic device enters the test process and begins loading the test environment. This test environment refers to a runtime space built for performing automated tests. Specifically, it can be a Shell test environment created within the EDK2 code architecture. This Shell test environment provides a command-line interface and script execution environment, supports a rich set of built-in commands and user-defined commands, and has high scalability. Specifically, the UEFI firmware can directly enter the Shell environment pre-deployed in the UEFI firmware by setting the boot path or calling specific boot options; at this point, the test environment is loaded.

[0040] In some embodiments, to test different driver modules, developers can create a dedicated test function package within the EDK2 code architecture, which can be named TestApp. This test function package can contain multiple pre-written test files, each corresponding to one or more test cases. By calling the UEFI standard interface of the driver module, the hardware functions managed by the driver module are indirectly verified. Simultaneously, each test file can contain corresponding test code to implement specific test logic. When the test file is called through a unified calling interface, its internal test code is executed, thereby completing the test of the corresponding functional module. Based on this, the EDK2 code architecture is compiled using the EDK2 compilation toolchain to generate a UEFI firmware image containing the test function package, and this UEFI firmware image is then burned into the memory of the target electronic device.

[0041] In some embodiments, multiple test files share a unified calling interface. A unified calling interface means that regardless of the driver module or testing purpose corresponding to a test file, they all expose the same type of call entry point. For example, they may have the same function prototype, the same parameter passing method, or the same command calling format. Based on this, during subsequent testing, upper-level test instructions do not need to concern themselves with the internal implementation details of specific test files; they can simply use the unified calling interface to invoke any test file to execute the test.

[0042] In practical applications, taking the testing of storage modules as an example, developers can write a test file named "StorageTest" in the test function package of the EDK2 code architecture. This test file has a unified calling interface. Then, the EDK2 compilation toolchain compiles the above code architecture to generate a UEFI firmware image containing this test function package, and burns this image into the memory of the target electronic device. Based on this, when the test environment is loaded during the boot process of the target electronic device, and the target electronic device receives the test instructions for the storage module, the UEFI firmware can locate the StorageTest test file through the unified calling interface and call its entry function. The target chip then executes the test code in the test file, thereby initiating various functional tests of the storage module.

[0043] As can be seen, this embodiment of the application achieves structured management and centralized deployment of test cases by creating a Shell test environment and a dedicated test function package within the EDK2 code architecture. Therefore, when the target electronic device enters test mode, the test files pre-burned into the memory can be quickly loaded and invoked in the test environment, eliminating the need to rebuild the environment for each test and significantly improving test preparation efficiency. Simultaneously, multiple test files use a unified calling interface, exposing the same type of call entry point regardless of the functional module the test file corresponds to, freeing upper-layer test instructions from concern themselves with internal implementation details. Furthermore, when the same test scheme is applied to different chips, only the same test files and calling interfaces need to be reused, eliminating the need to develop separate test code for each chip. This achieves seamless portability of test cases across different chips, greatly improving the reusability of test code and effectively reducing test development costs.

[0044] S103, in the test environment, according to the test instructions, the target test file is called from multiple test files through the call interface to execute the test, so as to test the functional modules corresponding to the target electronic device.

[0045] In some embodiments, once the test environment is loaded, the target electronic device enters a state of waiting for or receiving test instructions. These test instructions can be pre-configured automated script instructions or user-interactive instructions entered in real time by R&D personnel through an interactive interface. Regardless of the form of the test instructions, the ultimate goal is to select and execute the corresponding target test file from multiple test files through a unified calling interface, thereby verifying specific functional modules of the target chip.

[0046] In some embodiments, taking the testing of the storage driver module of a target electronic device as an example, after the Shell test environment is loaded, the developer can enter the test command corresponding to the storage driver module in the command line interface. After receiving the test command, the target electronic device can locate the target test file matching the command in multiple test files of the test function package through a unified calling interface, and the target chip executes the test code. Here, since the target test file integrates multiple test code segments, the target chip will sequentially test the register read / write function, DMA transfer performance, and interrupt response mechanism of the storage driver module according to preset logic during the test process.

[0047] As can be seen, this application's embodiments achieve precise matching and efficient calling between test instructions and test files through a unified calling interface and test file execution mechanism. This means that developers only need to input simple test instructions to trigger the target chip to automatically complete multiple sub-tests for specific functional modules, eliminating the need for manual execution item by item and greatly simplifying the testing process. Simultaneously, the standardized calling interface ensures good reusability of the test code; the same set of test files can be applied to different chip platforms, effectively improving testing efficiency and reducing development costs.

[0048] In some embodiments, the test instructions include automated test script instructions, which call a target test file from multiple test files to perform tests according to the test instructions via an interface, including: in response to the automated test script instructions, executing an automated test script, which sequentially calls one or more target test files to perform tests.

[0049] In some embodiments, test instructions include automated test script instructions. Thus, before testing, developers can write a series of test commands into an automated test script file, such as a shell script named "AutoTest.nsh". Based on this, when the target electronic device receives the automated test script instructions, it directly executes the automated test script, which sequentially calls one or more test files to perform tests according to a preset order. Here, the automated test script can contain multiple test commands, each of which can specify different test files through a unified calling interface, enabling sequential testing of multiple functional modules such as storage drivers, network drivers, and power management modules.

[0050] In other embodiments, the test instructions also include user interaction instructions, which call a target test file from multiple test files to execute the test according to the test instructions via an interface, including: in the test environment, in response to user input, generating a corresponding user interaction instruction; and calling the corresponding target test file to execute the test according to the user interaction instruction.

[0051] In some embodiments, test commands include user interaction commands. Thus, in the Shell testing environment, developers can input commands in real-time through the command-line interface of the Shell testing environment to interact with the target electronic device. Upon responding to the input from the developer in the testing environment, the target electronic device generates a corresponding user interaction command and, based on this command, retrieves the corresponding target test file from multiple test files through a unified API, triggering the execution of the test task. For example, if a developer inputs the command "RunTest Storage" in the command-line interface, the target electronic device parses the command, accurately locates the target test file named "StorageTest" through the unified API, and executes it, thereby achieving targeted testing of the storage driver module. This method offers greater operational flexibility, adapting to the rapid verification needs of developers for specific functional modules during the debugging phase. Different test cases can be flexibly selected and executed according to actual testing needs, significantly improving the efficiency of problem localization and analysis during the development process.

[0052] In some embodiments, the test instruction may directly include an identifier for the target test file, such as a filename or a preset test ID. The target electronic device can use this identifier to accurately locate and retrieve the corresponding test file through a unified call interface. Alternatively, a mapping table between test instructions and test files can be pre-configured. When a test instruction is received, the target electronic device can query the mapping table to determine the corresponding target test file and then complete the retrieval and execution.

[0053] In some embodiments, taking the testing of the storage driver module of the target electronic device as an example, when the target electronic device receives the "RunTest Storage" test instruction, it can find and execute the target test file named "StorageTest" through a unified calling interface. The target test file can integrate multiple test sub-items such as register read / write test, transmission test, and interrupt response test of the storage driver module. After the test is completed, the corresponding test results will be returned synchronously. Similarly, if it is necessary to test the network function module, when the system receives the "RunTest Network" test instruction, it will call the corresponding "NetworkTest" test file through a unified calling interface to fully verify the functions of chip initialization, packet transmission and reception, and link status detection of the network interface.

[0054] Based on the above approach, the embodiments of this application can achieve flexible testing of different functional modules in the EDK2 startup process. Whether it is automated batch testing on the production line or manual targeted testing on the R&D side, the test files can be retrieved and executed through a unified calling interface, which greatly simplifies the chip testing operation process and effectively improves the cross-product reusability and future maintainability of the test code.

[0055] In some embodiments, the test environment and multiple test files are pre-deployed in the boot firmware of the target electronic device. Figure 2 This is a schematic diagram illustrating the code architecture of EDK2 provided in one embodiment of this disclosure. Figure 2 As shown, in some embodiments, a test function package can be added to the existing EDK2 code architecture to build a standardized and reusable automated testing framework. This test function package can be replaced or extended according to different testing needs. A UEFI firmware image containing this function package is compiled using the EDK2 compilation toolchain, and then burned into the memory of the target electronic device. The following, combined with... Figure 2 The implementation of this testing framework will be explained in detail.

[0056] In some embodiments, within the original EDK2 code architecture 201, various hardware driver modules exist independently as driver execution environments (DXEs) adapted to the EDK2 DXE. Specifically, these driver modules include general-purpose flash memory driver modules (UFS DXE), analog device interface driver modules (ADI DXE), integrated circuit bus driver modules (I2C DXE), electronic fuse driver modules (Efuse DXE), universal serial bus driver modules (USBDXE), system status monitoring and processing driver modules (Ssmh DXE), general-purpose input / output driver modules (GPIO DXE), trusted operating system driver modules (TOS DXE), power management integrated circuit driver modules (PMIC DXE), and display module driver modules (Display DXE), etc. All of these driver modules conform to the UEFI standard interface design, achieving independent decoupling and independent upgrades on a functional package basis. The underlying hardware details are shielded by the standard interface, providing a foundation for unified calls from upper-layer applications.

[0057] In some embodiments, to achieve automated testing of the driver modules of the target chip, this application embodiment can build a dedicated testing system based on the existing EDK2 code architecture by adding a test function package. Specifically, firstly, a new function package (Pkg) named TestApp is created. This function package serves as the core carrier of the test application, directly calling the interfaces of existing driver modules such as UFS DXE, I2C DXE, and GPIO DXE through the UEFI standardized interface. Simultaneously, based on the functional characteristics of each driver module and the testing requirements of the target chip, corresponding functional test cases and performance test cases are constructed in the TestApp function package, forming... Figure 2 Test layer 202 on the Chinese code architecture.

[0058] like Figure 2 As shown, in the EDK2 code architecture, the TestApp package, which integrates all test cases, is presented in the form of TestAPP and deployed at the same layer as the existing Android Boot App and Download App. This test layer 202 specifically includes applications such as the Double Data Rate Memory Test App, the Storage Test App, the Security Module Test App, and the Universal Serial Bus Test App.

[0059] In some embodiments, the test environment and multiple test files are based on Figure 2 The core components of the dedicated testing system built on the architecture are pre-deployed in the boot firmware of the target electronic device and are fully compatible. Figure 2 The hierarchical calling logic. The test environment serves as the runtime platform, relying on... Figure 2 The architecture implements features such as command expansion and test mode switching for the Shell testing environment, providing dedicated space for the execution of test files; multiple test files are based on... Figure 2 Standard interface development for each driver module, deployed in Figure 2 The architecture can be invoked in the test environment, through... Figure 2 A bottom-up hierarchical architecture enables testing of the underlying hardware driver modules, ultimately relying on... Figure 2 The architecture enables cross-product compatibility testing.

[0060] As can be seen, this application embodiment did not make any disruptive modifications to the existing EDK2 code architecture and drivers when adding the aforementioned test application module. It only relied on the standardized interfaces of the existing drivers to achieve the interface between the test application and the underlying drivers. Furthermore, the newly added test application can directly reuse the interface resources of the existing driver modules, ensuring both the integrity of the original EDK2 architecture and cross-product and cross-model compatibility. It should be noted that the test applications built in this application embodiment (such as DDR Test APP, Stg Test APP, etc.) are platform-independent, calling the UEFI standardized driver interface rather than directly manipulating the underlying hardware. Therefore, when the target chip is changed, only the corresponding chip's driver module needs to be selected during the compilation process; the test application itself can be directly reused without modification, thus achieving the technical effect of adapting a single set of test code to multiple chip platforms.

[0061] As can be seen, by constructing the TestApp function package, this application achieves comprehensive test coverage of the underlying driver without modifying the original architecture and hardware driver of EDK2, relying on the standardized UEFI interface. This not only ensures the integrity of the architecture and the independence of the driver, but also enables the test application to have cross-platform reusability. One set of test code can be adapted to multiple chip models, significantly improving the efficiency of R&D testing and the maintainability of the code.

[0062] In some embodiments, when the operating mode is non-test mode, the system switches to the test environment in response to a preset trigger event; after switching to the test environment, the system executes the test by calling the corresponding target test file through the calling interface according to the test instructions input by the user.

[0063] In some embodiments, when the UEFI firmware determines that the current operating mode is non-test mode based on configuration information, the target electronic device enters the normal system boot process. However, in specific scenarios, such as during R&D debugging or production line sampling, when it is necessary to temporarily enter the test environment to verify certain functional modules of the target chip, the device can switch to the test environment by using a preset trigger event.

[0064] Specifically, the preset trigger event can be a user-triggered hardware operation, such as pressing and holding a specific button on the target electronic device, toggling a DIP switch, or shorting a specific test point; it can also be a command sent by an external device, such as receiving a specific handshake signal from a PC via a serial port, or detecting a USB debugging tool connection; or it can be an internal event, such as a timer timeout or a specific system state meeting preset conditions. Based on this, when the UEFI firmware detects a preset trigger event, the target electronic device can switch from its current non-test mode to test mode, load the test environment, and after switching to the test environment, developers can input test commands through a command-line interface. Upon receiving the user-input test commands, the target electronic device uses a unified calling interface to call the corresponding target test file from multiple test files to execute the test, thereby completing the verification of specific functional modules of the target chip.

[0065] As can be seen, this application's embodiment, by introducing a preset trigger event mechanism in non-test mode, achieves the technical effect of flexibly entering the test environment for targeted verification without changing the default startup mode of the target electronic device. Furthermore, R&D personnel do not need to re-flash firmware or modify configuration information for temporary testing needs; they can quickly switch to test mode through simple hardware operations or external commands, greatly improving the efficiency of R&D debugging and production line sampling. Simultaneously, this mechanism complements the existing configuration-based automatic test mode, forming a complete test mode switching system: supporting both automated testing of batch devices and on-demand testing of single devices, meeting diverse testing needs in different scenarios such as R&D, production lines, and on-site maintenance. In addition, the multiple implementation methods of preset trigger events (hardware operation, external commands, internal events) provide flexible choices for different application scenarios, enhancing the practicality and adaptability of this solution.

[0066] In some embodiments, after executing a test by calling a target test file from multiple test files through an interface according to a test instruction, the method further includes: collecting execution result data generated after each test in the multiple test files through a standardized log interface; parsing the execution result data of each of the multiple test files according to a preset judgment rule to determine the test status of each of the multiple test files, wherein the test status includes at least one of test passed, test failed, or test abnormal.

[0067] In some embodiments, after the target test file has been executed, the target electronic device can automatically collect the execution result data generated during the test through a standardized log interface. Specifically, each test file can output execution result data in a preset format during execution, such as execution result data corresponding to test sub-items like register read / write return values, DMA transfer data volume, and interrupt response time. This type of execution result data can be uniformly collected through the standardized log interface pre-built in the EDK2 code architecture.

[0068] After data acquisition, the target electronic device can parse the execution result data according to preset judgment rules. These preset judgment rules can be threshold comparison rules, data consistency verification rules, or status code mapping rules pre-configured in the firmware. For example, register read / write return values ​​can be compared with preset expected values, or specific error codes can be mapped to corresponding test states. After parsing, the target electronic device determines the test state of each test file. The test state includes at least one of the following: test passed, test failed, or test abnormal. A test passed indicates that all test sub-items meet expectations; a test failed indicates that a certain function does not meet expectations; and a test abnormality indicates that an unforeseen error occurred during the test (such as device reset, communication interruption, etc.). The parsed test states can be output through a log interface or stored in a designated storage area of ​​the target electronic device for later retrieval.

[0069] As can be seen, the embodiments of this application can unify the output format of various test files through a standardized log interface, avoiding the parsing difficulties caused by different output formats of different test modules, laying the foundation for subsequent automated processing. At the same time, the preset judgment rules realize the automated judgment of test results, enabling the target electronic device to parse the execution result data in real time and output a clear test status. R&D personnel do not need to check the original log line by line to quickly understand the test situation, which greatly improves the efficiency of test result analysis. Furthermore, by dividing the test status into pass, failure, or abnormal, it is convenient to summarize the statistics of batch tests. It can quickly screen abnormal devices in production line scenarios and accurately locate failed modules in R&D scenarios. In addition, the parsed test results can be output in real time or persistently stored through the log interface, which is convenient for subsequent traceability and analysis, further improving the automation level and traceability of the test process.

[0070] The foregoing primarily describes the solutions provided by the embodiments of this disclosure from the perspective of the server. It is understood that, in order to implement the above functions, the server includes the corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this disclosure can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0071] This disclosure embodiment can divide the server into functional units according to the above method example. For example, it can divide each function into separate functional modules, or it can integrate two or more functions into one management module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this disclosure embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0072] By dividing each functional module according to its corresponding function, an exemplary embodiment of this disclosure provides an automated testing apparatus, which can be a server or a chip applied to a server. Figure 3 This is a schematic diagram of an automated testing device provided in one embodiment of the present disclosure. Figure 3 As shown, the automated testing device 300 includes: The determination module 301 is used to determine the operating mode according to the configuration information in response to the startup of the target electronic device, wherein the target electronic device is equipped with a target chip.

[0073] The loading module 302 is used to load the test environment when the running mode is test mode, wherein the test environment contains multiple test files and the multiple test files have a unified calling interface.

[0074] The calling module 303 is used in the test environment to call the target test file from multiple test files through the calling interface according to the test instructions to perform tests on the functional modules corresponding to the target chip.

[0075] In one alternative approach, the test environment and the plurality of test files are pre-deployed in the boot firmware of the target electronic device.

[0076] In an alternative embodiment, the test instructions include automated test script instructions, and the calling module 303 is further configured to execute the automated test script in response to the automated test script instructions, wherein the automated test script sequentially calls one or more of the target test files to perform tests.

[0077] In an alternative approach, the test instructions include user interaction instructions, and the calling module 303 is further configured to generate corresponding user interaction instructions in response to user input operations in the test environment; and to call the corresponding target test file to execute the test according to the user interaction instructions.

[0078] In an alternative embodiment, the loading module 302 is further configured to switch to the test environment in response to a preset trigger event when the running mode is non-test mode; after switching to the test environment, it calls the corresponding target test file to execute the test according to the test instructions input by the user through the calling interface.

[0079] In one optional embodiment, the automated testing device 300 further includes a data acquisition module 304, which is used to acquire execution result data generated after each test is executed in the plurality of test files through a standardized log interface; and to parse the execution result data of each of the plurality of test files according to a preset judgment rule to determine the test status of each of the plurality of test files, wherein the test status includes at least one of test passed, test failed, or test abnormal.

[0080] This disclosure also provides an electronic device, including: at least one processor; a memory for storing at least one processor-executable instruction; wherein the at least one processor is used to execute the instruction to implement the steps of the method disclosed in this disclosure.

[0081] Figure 4 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of the present disclosure. Figure 4 As shown, the electronic device 400 includes at least one processor 401 and a memory 402 coupled to the processor 401, which can perform the corresponding steps in the methods disclosed in the embodiments of this disclosure.

[0082] The processor 401 described above can also be called a Central Processing Unit (CPU), which can be an integrated circuit chip with signal processing capabilities. Each step in the method disclosed in this embodiment can be implemented by the integrated logic circuitry in the hardware of the processor 401 or by instructions in software form. The processor 401 can be a general-purpose processor, a digital signal processor (DSP), an ASIC, a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this embodiment can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules can be located in the memory 402, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The processor 401 reads information from the memory 402 and, in conjunction with its hardware, completes the steps of the method described above.

[0083] Furthermore, various operations / processes according to this disclosure, implemented via software and / or firmware, can be transmitted from a storage medium or network to a computer system with a dedicated hardware architecture, for example, Figure 5 The computer system 500 shown is equipped with the programs that constitute the software. When various programs are installed, the computer system is able to perform various functions, including functions such as those mentioned above. Figure 5 This is a schematic diagram of the structure of a computer system provided in an embodiment of the present disclosure.

[0084] Computer system 500 is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of this disclosure described and / or claimed herein.

[0085] like Figure 5As shown, the computer system 500 includes a computing unit 501, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 502 or a computer program loaded from a storage unit 508 into a random access memory (RAM) 503. The RAM 503 may also store various programs and data required for the operation of the computer system 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0086] Multiple components in the computer system 500 are connected to the I / O interface 505, including: an input unit 506, an output unit 507, a storage unit 508, and a communication unit 509. The input unit 506 can be any type of device capable of inputting information into the computer system 500. The input unit 506 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of the electronic device. The output unit 507 can be any type of device capable of presenting information and may include, but is not limited to, a monitor, speaker, video / audio output terminal, vibrator, and / or printer. The storage unit 508 may include, but is not limited to, a hard disk and an optical disk. The communication unit 509 allows the computer system 500 to exchange information / data with other devices via a network such as the Internet, and may include, but is not limited to, a modem, network card, infrared communication device, wireless communication transceiver, and / or chipset, such as Bluetooth™ devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0087] The computing unit 501 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above. For example, in some embodiments, the methods disclosed in this disclosure can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program can be loaded and / or installed on an electronic device via ROM 502 and / or communication unit 509. In some embodiments, the computing unit 501 can be configured to perform the methods disclosed in this disclosure by any other suitable means (e.g., by means of firmware).

[0088] This disclosure also provides a computer-readable storage medium, wherein when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform the methods disclosed in this disclosure.

[0089] The computer-readable storage medium in this disclosure can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. The aforementioned computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specifically, the aforementioned computer-readable storage medium may include electrical connections based on one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0090] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0091] Figure 6 This is a schematic diagram of a computer program product provided according to an embodiment of the present disclosure. Figure 6 As shown, the computer program product 600 includes a computer program 601, which, when executed by a processor, implements the methods disclosed in the embodiments of this disclosure.

[0092] In embodiments of this disclosure, computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include, but are not limited to, object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)), or it can be connected to an external computer.

[0093] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0094] The modules, components, or units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the modules, components, or units do not necessarily constitute a limitation on the module, component, or unit itself.

[0095] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary hardware logic components that can be used include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0096] The above description is merely an illustration of some embodiments of this disclosure and the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0097] While specific embodiments of this disclosure have been described in detail by way of example, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of this disclosure. Those skilled in the art should understand that modifications can be made to the above embodiments without departing from the scope and spirit of this disclosure. The scope of this disclosure is defined by the appended claims.

Claims

1. An automated testing method, characterized in that, Applied to target electronic devices, including: In response to the startup of the target electronic device, an operating mode is determined based on configuration information, wherein the target electronic device is equipped with a target chip; When the running mode is test mode, a test environment is loaded, wherein the test environment contains multiple test files, and the multiple test files have a unified calling interface; In the test environment, the target test file is called from multiple test files through the calling interface according to the test instructions to perform the test on the functional modules corresponding to the target chip.

2. The method according to claim 1, characterized in that, The test environment and the multiple test files are pre-deployed in the boot firmware of the target electronic device.

3. The method according to claim 1, characterized in that, The test instructions include automated test script instructions. The step of calling the target test file from among the multiple test files and executing the test according to the test instructions via the calling interface includes: In response to the automated test script instructions, the automated test script is executed, and the automated test script sequentially calls one or more of the target test files to perform tests.

4. The method according to claim 1, characterized in that, The test instructions also include user interaction instructions, wherein the step of calling the target test file from among the multiple test files to execute the test according to the test instructions through the calling interface includes: In the test environment, in response to the user's input, a corresponding user interaction command is generated; The test is executed by calling the corresponding target test file according to the user interaction instructions.

5. The method according to claim 1, characterized in that, The method further includes: When the operating mode is non-test mode, the system switches to the test environment in response to a preset trigger event; After switching to the test environment, the corresponding target test file is invoked through the call interface to execute the test according to the test instructions input by the user.

6. The method according to claim 1, characterized in that, After the method calls the target test file from multiple test files to execute the test according to the test instruction through the calling interface, the method further includes: The execution result data generated after each test in multiple test files is collected using a standardized log interface. The execution result data of each of the multiple test files is parsed according to a preset judgment rule to determine the test status of each of the multiple test files, wherein the test status includes at least one of test passed, test failed, or test abnormal.

7. An automated testing device, characterized in that, include: A determination module is used to determine the operating mode based on configuration information in response to the startup of the target electronic device, wherein the target electronic device is equipped with a target chip; A loading module is used to load a test environment when the running mode is test mode, wherein the test environment contains multiple test files and the multiple test files have a unified calling interface; The calling module is used in the test environment to call the target test file from multiple test files through the calling interface according to the test instructions to perform tests on the functional modules corresponding to the target chip.

8. A computer device, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 6.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 6.

Images