Test method, electronic equipment and test system of expansion card

Abstract

This application provides a testing method, electronic device, and testing system for an expansion card. The testing method includes: configuring a configuration file based on the instruction content of a controller that the expansion card can receive, and the expected data content corresponding to the instruction content; generating a test instruction based on the configuration file; sending the test instruction to the expansion card; receiving the firmware response from the expansion card in response to the test instruction, and the returned data; and testing whether the expansion card has successfully communicated based on the returned data. Specifically, the method involves configuring the configuration file based on the instruction content of the controller that the expansion card can receive, and the expected data content corresponding to the instruction content, generating a test instruction based on the configuration file, and sending the test instruction to the expansion card. The method also involves receiving the firmware response from the expansion card in response to the test instruction, and the returned data, and testing whether the expansion card has successfully communicated based on the returned data.

Description

[Technical Field]

[0001] This application belongs to the field of electronic equipment technology, and in particular relates to a testing method, electronic equipment and testing system for an expansion card. [Previous Technology]

[0002] The server includes an expansion card and a Baseboard Management Controller (BMC). The expansion card and BMC each have their own firmware. After initial firmware completion, accuracy cannot be guaranteed, requiring simultaneous testing of both the expansion card's firmware and the BMC's firmware to verify their correctness. Since both the expansion card's and BMC's firmware are still in the development stage, their correctness is relatively weak. Therefore, multiple tests are often required, which is time-consuming and labor-intensive. Furthermore, the development of the expansion card's and BMC's firmware is often asynchronous, hindering timely joint testing and impacting their respective development progress. In addition, the development of the expansion card's and BMC's firmware generally falls under two separate development teams. Joint testing by these two teams is necessary; however, poor communication and collaboration can prevent successful completion of each test, consuming manpower from both teams and further delaying the development of the expansion card's and BMC's firmware.

[0003] Before testing the correctness of the firmware, it is necessary to test whether the expansion card and BMC can communicate. [Summary of the Invention]

[0004] In view of this, the present application provides a testing method, electronic device and testing system for expansion cards, which independently tests the communication status of expansion cards to improve the efficiency and accuracy of subsequent firmware testing of expansion cards.

[0005] The first aspect of this application provides a testing method for an expansion card, including: configuring a configuration file according to the instruction content of a controller that the expansion card can receive and the expected data content corresponding to the instruction content; generating a test instruction according to the configuration file; sending the test instruction to the expansion card; receiving the return data returned by the expansion card's firmware in response to the test instruction; and testing whether the expansion card has successfully communicated based on the return data.

[0006] The above technical solution configures a setting file based on the instruction content of the controller that the expansion card can receive and the expected data content corresponding to the instruction content. A test instruction is generated according to the setting file and sent to the expansion card. Then, the expansion card's firmware responds with the return data returned by the test instruction. Finally, the expansion card's communication is tested based on the return data. Without the need for a BMC, the communication status of the expansion card can be tested independently, thereby improving the efficiency and accuracy of subsequent firmware testing of the expansion card.

[0007] In some embodiments, generating test instructions based on a configuration file includes: reading the sending parameters of the configuration file; filling the sending parameters into a preset instruction format to generate test instructions.

[0008] In some embodiments, the testing method further includes: parsing the returned data based on the receiving parameters of the setting file; if the parsing is successful, generating a log file based on the parsed returned data; testing whether the expansion card communicates successfully based on the returned data, including: determining the status flag bits in the log file; if the status flag bits indicate success, determining that the expansion card communicates successfully; if the status flag bits indicate failure, determining that an abnormal warning is triggered.

[0009] In some embodiments, if parsing fails after parsing the returned data, an exception warning is triggered.

[0010] In some embodiments, after generating test instructions according to the setting file, the test method further includes: determining whether the number of test instructions is greater than a preset number; if it is less than the preset number, sending test instructions to the expansion card; if it is greater than the preset number, stopping the test.

[0011] In some embodiments, before configuring the configuration file according to the instruction content of the controller that the expansion card can receive, the test method further includes: obtaining the device address and channel address of the expansion card to obtain the instruction content of the controller that the expansion card can receive.

[0012] In some embodiments, the transmission method of test commands and return data is in-band or out-of-band.

[0013] In some embodiments, the number of test instructions is determined according to the number of configuration files, and each test instruction is generated by each configuration file.

[0014] A second aspect of this application provides an electronic device, including: a processor adapted to execute a computer program; a computer-readable storage medium storing a computer program, wherein when the computer program is executed by the processor, the test method described above is performed.

[0015] A third aspect of the present application provides a testing system, which includes an electronic device and an expansion card. The electronic device is used to: configure a setting file according to the instruction content of a controller that the expansion card can receive and the expected data content corresponding to the instruction content; generate a test instruction according to the setting file; send the test instruction to the expansion card; receive the return data returned by the firmware of the expansion card in response to the test instruction; and test whether the expansion card has successfully communicated based on the return data.

Implementation Method

[0017] In the embodiments of the application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships may exist. In addition, it should be understood that in the description of this application, words such as "first" and "second" are only used to distinguish the purpose of description and should not be construed as indicating or implying relative importance, nor should they be construed as indicating or implying order.

[0018] The following is a brief explanation of the relevant technologies:

[0019] The server includes an expansion card and a Baseboard Management Controller (BMC). The expansion card and the BMC each have their own firmware. Through the firmware, the BMC can send commands to the expansion card and receive data returned from the expansion card to control the expansion card to perform corresponding functions.

[0020] After the initial firmware completion, its accuracy cannot be guaranteed. It is necessary to run both the expansion card firmware and the BMC firmware simultaneously to test their correctness. Specifically, the BMC sends commands to the expansion card, and the expansion card responds with data. Developers analyze this data to test the correctness of the expansion card firmware and the BMC firmware. For example, by analyzing the data, it can be determined whether the expansion card can correctly and promptly respond to the BMC's commands. If it can, the firmware is correct; if not, it is not yet correct. If the firmware is still incorrect, further corrections and adjustments can be made to the expansion card firmware and / or the BMC firmware.

[0021] Since both the expansion card firmware and the BMC firmware are in the development stage, the correctness of both firmwares is relatively weak. Therefore, multiple tests are often required, which is time-consuming and labor-intensive. The development of the expansion card firmware and the BMC firmware is often out of sync, making timely joint testing impossible and affecting the development progress of their respective firmwares.

[0022] Furthermore, the firmware development for the expansion card and the BMC are generally handled by two separate development teams. These two teams need to conduct joint testing. During this joint testing process, if communication and collaboration are not smooth, each test cannot be completed successfully, and the data cannot be clearly reflected. Based on this unclear data, errors in the firmware cannot be identified. This consumes the manpower of both teams and delays the firmware development process for both the expansion card and the BMC. Firmware often requires updates, so after each update, joint testing is also necessary, further increasing the manpower consumption.

[0023] Before testing the correctness of the firmware, it is necessary to test whether the expansion card and BMC can communicate.

[0024] In view of this, the present application provides a testing method, electronic device and testing system for expansion cards, which independently tests the communication status of expansion cards, so as to improve the testing efficiency and accuracy of subsequent firmware of expansion cards.

[0025] The following is an explanation of some terms:

[0026] A configuration file is a computer file that can configure parameters and initial settings for computer programs.

[0027] Firmware refers to non-volatile memory such as ROM or Flash that contains embedded program code.

[0028] Out-of-band mode refers to the electronic device needing to connect to the UART serial port of the expansion card using a serial port cable, and completing the initialization configuration of the serial port in the automation program to realize communication between the electronic device and the expansion card.

[0029] UART refers to Universal Asynchronous Receiver / Transmitter (UART).

[0030] In-band mode refers to the electronic device achieving wireless communication with the serial port of the expansion card by means of manufacturer tools.

[0031] Please refer to Figure 1, which shows a test system for expansion card firmware according to an embodiment of this application. The test system 100 includes an electronic device 10 and an expansion card 21. The communication between the expansion card 21 and the electronic device 10 can be in-band or out-of-band. The expansion card 21 is used to install on devices such as servers, computers, and smartphones to add functionality to the device's computer system. The electronic device 10 is used to execute the test method for the expansion card according to an embodiment of this application.

[0032] In some embodiments, the electronic device 10 may be a server, computer, or mobile phone, etc., that has a display unit and the ability to perform data calculation, processing, and storage. The expansion card 21 may support the Serial Attached SCSI (SAS) protocol or the Peripheral Component Interconnect Express (PCIe) protocol. The expansion card 21 may be installed in the device under test 20.

[0033] Referring to Figure 2, this embodiment of the application also provides a testing method for an expansion card. The testing method is applied to a testing system 100 for expansion card firmware, specifically, it can be applied to an electronic device 10. The electronic device 10 can deploy a Linux operating system. The testing method includes the following steps:

[0034] Step S101: Configure the configuration file according to the instruction content of the controller that the expansion card can receive and the expected data content corresponding to the instruction content.

[0035] The contents of the controller's instructions and the expected data contents corresponding to the instructions can be preset in the electronic device or obtained in response to the input of the operator.

[0036] The controller refers to the Baseboard Management Controller (BMC). The received controller commands include the iicwr command. It is understood that since the expansion card 21 and the BMC communicate based on the Inter-Integrated Circuit (I2C) protocol, the firmware of the expansion card 21 supports CLI command calls and also supports the iicwr command derived from the CLI command. Therefore, the configuration file can be configured according to the iicwr command content. As shown in Figure 3, the configuration file includes a sending section. The sending section is used to add sending parameters. The sending parameters are used to provide parameters for the iicwr command. In one example, sending parameters are added to the configuration file according to the iicwr command content.

[0037] Expected data content refers to the data that the expansion card may return after responding to the command content. The command content can be combined with the expected data content configuration file. As shown in Figure 3, the configuration file includes a receiving section. The receiving section is used to add receiving parameters. In one example, sending parameters are added to the configuration file based on the expected data content.

[0038] Step S102: Generate test instructions according to the configuration file.

[0039] One configuration file generates one test command, and the number of test commands is determined by the number of configuration files. That is, by adding or deleting configuration files, the number of test commands can be increased or decreased. For example, N configuration files can generate N test commands, and deleting M configuration files can generate NM test commands. Test commands refer to commands used to test whether the firmware of expansion card 21 is correct. In one example, the sending part of the configuration file can be supplemented with the following content: I2c Address=B2 I2c Channel=1 Req:0:00:Checksum …… Req:1~2:0700:FunctionID.

[0040] Wherein, I2c Address indicates the bit address of the object to which the test command is sent, I2c Channel indicates the communication address of the object to which the test command is sent, and the sending object is expansion card 21. Req indicates the functional definition of the test command.

[0041] Req has four columns. The first column, Req, represents the part of the configuration file used to fill in the sending parameters for the test command. The second column represents the byte order. The third column represents the sending parameters (i.e., the bytes written) in the Req part of the test command. The fourth column represents the specific meaning of the sending parameters in the Req part. That is, the sending parameters also include the parameters pointed to by the third column of Req.

[0042] In one embodiment, the sending parameters of the setting file are read, and the sending parameters are filled into a preset instruction format to generate a test instruction. The preset instruction format includes the iicwr instruction format, which can be pre-stored in the electronic device 10. In one example, the iicwr instruction format is: iicwr <SlaveAddress(H)> <ChannelNumber(D)> <NumBytesToRead(D)> <WriteData(H)…>.

[0043] Where, <SlaveAddress(H)> represents the device address, <ChannelNumber(D)> represents the channel address, <NumBytesToRead(D)> represents the number of bytes to read, and <WriteData(H)...> represents the array of bytes to write.

[0044] The device address and channel address are used to specify the expansion card 21 that receives the test command. It is understood that the firmware of each expansion card 21 stores the device address and channel address so that external devices can find the expansion card 21. The number of bytes to read specifies the number of bytes of data returned by the expansion card 21. The send parameters (i.e., the send parameters in the third column of the Req section of the configuration file) specify the array of bytes to be written to customize the function of the test command.

[0045] After filling the sending parameters of the file sending part in the above two examples into the preset command format, the test command is obtained as: iicwr B2 1 4 F8 07 00. Among them, the address of the expansion card 21 is B2, the channel address is 1, the number of bytes to be read is 4, and after this test command is sent, 4 bytes of return data are returned.

[0046] In the example, 07 and 00 in the test command are two bytes in the byte array. F8 is the checksum of the test command (F8 is calculated by the electronic device 10 based on 07 00). The checksum is used to verify the transmitted data to prevent data transmission errors during communication. 07 00 indicates that the function of this test command is to obtain the ID of the expansion card 21.

[0047] Step S103: Send test command to expansion card.

[0048] Test commands can be sent to expansion card 21 in either in-band or out-of-band mode. The specific communication method depends on the initialization configuration. When the initialization configuration is in-band mode, the test commands are sent in in-band mode; when the initialization configuration is out-of-band mode, the test commands are sent out-of-band mode.

[0049] Step S104: Receive the firmware response from the expansion card in response to the test command.

[0050] The firmware of expansion card 21 receives test commands and, in response to the test commands, returns return data corresponding to the test commands.

[0051] For example, if expansion card 21 receives the test command iicwr B2 1 4 F8 07 00, then the returned data is FE 00 01.

[0052] Where FE is the checksum bit, calculated by expansion card 21 based on the returned data. 00 is the status flag bit, used to indicate the completion status of the test command. In this example, 00 indicates success (if the status flag bit is 01, it indicates failure). 01 in the returned data represents the ID.

[0053] Step S105: Test whether the expansion card communicates successfully based on the returned data.

[0054] In one application scenario, electronic device 10 configures a setting file according to the instructions of the controller that expansion card 21 can receive, generates a test command iicwr B2 1 4 F8 07 00 according to the setting file, and sends the test to expansion card 21. Then, it receives the firmware response from expansion card 21 in the return data FE 00 01 returned by the test command. According to the status flag bit 00 in the return data FE 00 01 indicating success, it is determined that the communication between electronic device 10 and expansion card 21 is successful, indicating that electronic device 10 has obtained the return data from expansion card.

[0055] It is understood that the above technical solution configures a setting file based on the instruction content of the controller that the expansion card 21 can receive, and the expected data content corresponding to the instruction content. A test instruction is generated according to the setting file and sent to the expansion card 21. Then, the firmware of the expansion card 21 responds with the return data returned by the test instruction. Finally, the communication with the expansion card 21 is tested based on the return data. Without the need for a BMC, the communication status of the expansion card 21 can be tested independently, thereby improving the efficiency and accuracy of subsequent firmware testing of the expansion card 21.

[0056] It is understood that servers generally include SAS protocol expansion cards 21 or PCIe protocol expansion cards 21. To meet the customized out-of-band monitoring requirements of the BMC, the firmware of the expansion card 21 itself needs to define a certain number of instruction formats according to the BMC requirements to return the data required by the BMC. In this embodiment of the application, for the communication test in the firmware test of the expansion card 21, the detection instruction is analogous to the general iicwr instruction of the expansion card 21 itself, and the preset instruction format is analogous to the general iicwr instruction format of the expansion card 21 itself, so as to analogize the command access of external chip devices such as the BMC to the expansion card 21. This avoids the occurrence of unstable, inaccurate and inefficient joint testing. The customized development and testing of the expansion card 21 are integrated and can be completed independently by the expansion card 21 developers, allowing development and testing to be carried out anytime and anywhere, without interference from external factors, and quickly completing the verification of all customized I2C instructions one by one. This greatly improves the development progress, reduces the debugging difficulty, and simplifies the debugging steps.

[0057] Understandably, only the developers of the expansion card 21 need to participate; the BMC firmware does not need to be completed, and the BMC developers do not need to participate in testing. This simplifies the testing method. The testing process is no longer limited by the development progress and manpower of the BMC development team, allowing for automated testing.

[0058] In some embodiments, step S104 further includes the following steps:

[0059] Based on the received parameters in the configuration file, the returned data is parsed, and after the returned data is successfully parsed, a log file is generated and stored based on the parsed returned data.

[0060] As shown in Figure 3, the receiving section of the configuration file is used to add receiving parameters. These receiving parameters are used to parse the returned data.

[0061] In one example, the following can be added to the receive section of the configuration file: Resq:0:00: Checksum Resq:1:00: completion code …… Resq:2:00: Expander ID.

[0062] Among them, Resq has four columns. The first column, Resq, represents the part of the configuration file used for parsing the returned data. The second column represents the byte order. The third column represents the received parameters used for parsing the returned data. The fourth column represents the specific meaning of the received parameters in the Resq part (the specific meaning of the received parameters is also the explanation of the received parameters). It can be understood that the received parameters include the parameters pointed to by the third column of Resq.

[0063] The returned parameters and received parameters are parsed one by one in byte order. Successful parsing includes a one-to-one correspondence between the returned data and the received parameters, and that the bytes of the returned data have corresponding interpretations at their corresponding positions in the received data. Parsing failure includes a mismatch between the returned data and the received data, and / or the absence of corresponding interpretations at their corresponding positions in the received data.

[0064] For example, if the received parameter is 00 00 00, and the returned data FE 00 01 and 00 00 00 are in a one-to-one correspondence, then it is assumed that the bytes of the returned data have a corresponding interpretation at the corresponding position of the received data.

[0065] During the parsing of the returned data, a log file is generated based on the returned data of the received part (i.e., the parsed returned data), the test command, and the parameter pointed to by the third column of Req.

[0066] In one example, the contents of the log file are as follows: >>>>Reading:[0x0700 Get Expander ID.txt] Req[0] Checksum :FE Req[1~2] Function ID :0700 CMD>. / scrtnycli.x86-64-I 4 cli iicwr B2 1 4 FE 07 00 Resq[0] Checksum :FE Resq[1] completion Code :00 (Success) Resq[2] Expander ID :01.

[0067] The completion code in the log text indicates success, meaning that the electronic device 10 and the expansion card 21 have successfully communicated. It can be understood that generating a log file based on the parsed data allows for the collection and storage of test results at once, resulting in more intuitive and accurate output.

[0068] In some embodiments, the testing method further includes the following steps:

[0069] Step S201: If the returned data is successfully parsed, confirm that the automation program is running correctly, and proceed to step S301.

[0070] Understandably, successful parsing indicates that the firmware of expansion card 21 can respond to the detection command, and the parsed content can be used to determine whether the electronic device 10 and the expansion card have successfully communicated.

[0071] Step S202: If the returned data parsing fails, trigger an exception warning.

[0072] If the parsing fails, it means that the firmware of expansion card 21 cannot respond to the detection command, and there is a problem with the automation program that causes it to not run correctly, triggering an exception warning to inform the R&D personnel to intervene and repair it manually.

[0073] In some embodiments, step S105 includes the following steps:

[0074] Step S301: Determine the status flag bits in the log file.

[0075] Step S302: If the status flag bit indicates success, the expansion card communication is successful.

[0076] Step S303: If the status flag bit indicates failure, trigger an exception warning.

[0077] In the above example, the content of the log file is Resq[1] completion Code: 00 (Success), and the parameter of the status flag bit completion Code is 00, indicating success, which means that the electronic device 10 and the expansion card 21 communicate successfully.

[0078] Understandably, after successful parsing, the status flag bits in the log file can be used to determine whether the test command destination can be successfully reached. If the status flag bits indicate success, it is determined that the test command destination has been reached and communication with the expansion card 21 is successful. If the status flag bits indicate failure, it is determined that the test command destination cannot be reached, possibly due to expansion card communication failure. In this case, an exception warning is triggered, and the R&D personnel can intervene manually to perform anomaly analysis on the expansion card 21.

[0079] Understandably, the analysis of log text can be performed automatically by electronic device 10 or by R&D personnel.

[0080] In some embodiments, after generating test instructions according to the configuration file, the test method further includes:

[0081] Step S401: Determine whether the number of test instructions is greater than the preset number.

[0082] Step S402: If the number is less than the preset number, send a test command to the expansion card.

[0083] Step S403: If the number exceeds the preset quantity, stop the test.

[0084] Understandably, a threshold for the number of test commands can be preset to prevent testing from continuing indefinitely. The threshold can be a preset number, which is set according to the actual situation. If the number of test commands is less than the preset number, it means that testing can continue; if it is greater than the preset number, the testing stops.

[0085] In some embodiments, before configuring the configuration file, the test method further includes: determining whether the transmission mode of the test command and the returned data is in-band or out-of-band, and obtaining the address and channel address of the expansion card, so as to configure the configuration file according to the device address and channel address. That is, before configuring the configuration file, initialization settings can be performed first, including selecting the communication mode and obtaining the address used to specify a specific expansion card 21.

[0086] The following application scenario, using electronic device 10 to test the firmware of an expansion card 21, illustrates some of the above embodiments. Referring to Figure 4, electronic device 10 performs the following steps:

[0087] Step S1: Initialize settings. Configure the configuration file according to the instruction content of the controller that the expansion card can receive and the expected data content corresponding to the instruction content.

[0088] First, initialization settings are performed, including at least selecting that the electronic device 10 connects to the expansion card 21 via out-of-band mode and obtaining the address and channel address of the expansion card 21. Next, a configuration file is configured based on the instructions received by the controller that the expansion card can receive and the expected data content corresponding to the instructions.

[0089] Step S2: Determine whether the initialization was successful. If yes, proceed to step S3; otherwise, end.

[0090] Step S3: Read the sending parameters of the setting file and determine whether the sending parameters of the setting file have been read successfully. If yes, proceed to step S4; otherwise, end.

[0091] Step S4: Generate test instructions based on the read sending parameters.

[0092] Step S5: Determine whether the number of test commands is greater than the preset number. If yes, end. If no, proceed to step S6.

[0093] Step S6: Receive the firmware response from the expansion card and the return data returned by the test command.

[0094] Step S7: Determine whether the returned data was successfully parsed. If yes, proceed to step S8; otherwise, end.

[0095] Step S8: Generate a log file based on the parsed returned data.

[0096] Step S9: Determine whether the status flag bits in the log file indicate success. If yes, then the communication is confirmed to be successful, and return to step S3 to read the next configuration file. If not, then trigger an exception warning and end.

[0097] Please refer to Figure 5, which is a schematic diagram of the structure of an electronic device 10 provided in an embodiment of this application. In one embodiment, the electronic device 10 includes a memory 13 and at least one processor 14. Those skilled in the art should understand that the structure of the electronic device 10 shown in Figure 5 does not constitute a limitation of the embodiments of this application, and the electronic device 10 may also include more or fewer other hardware or software, or different component arrangements than shown in the figure.

[0098] As an optional implementation, the electronic device 10 includes a terminal capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions. Its hardware includes, but is not limited to, microprocessors, dedicated integrated circuits, programmable gate arrays, digital word processors, and embedded devices. As an optional implementation, the memory 13 is used to store computer programs and various data. The memory 13 may include any other computer-readable medium capable of carrying or storing data, such as read-only memory (ROM), random access memory (RAM), or programmable read-only memory (PROM).

[0099] As an optional implementation, the at least one processor 14 may include integrated circuits, such as a single-packaged integrated circuit or multiple integrated circuits with the same or different functions, including combinations of microprocessors, digital document processing chips, graphics processors, and various control chips. The at least one processor 14 is the control unit of the electronic device 10, which performs various functions of the electronic device 10 and processes data by running or executing programs or modules stored in the memory 13 and calling data stored in the memory 13. The memory 13 stores computer programs, and the at least one processor 14 can call the computer programs stored in the memory 13 to execute the test method for implementing the expansion card described above.

[0100] This application also provides a testing system 100, which includes an electronic device 10 and an expansion card 21. The electronic device 10 is used for...

[0101] Configure a configuration file based on the instruction content of the controller that the expansion card 21 can receive, and the expected data content corresponding to the instruction content;

[0102] Generate test instructions based on the configuration file;

[0103] Send test command to expansion card 21;

[0104] Receive the firmware response from expansion card 21 in response to the test command;

[0105] Test whether expansion card 21 can communicate successfully based on the returned data.

[0106] In some embodiments, the electronic device 10 is also used to read the sending parameters of the setting file; fill the sending parameters into a preset instruction format, and generate a test instruction.

[0107] In some embodiments, the electronic device 10 is further configured to parse the returned data based on the received parameters of the set file; if the parsing is successful, generate a log file based on the parsed returned data; determine the status flag bits in the log file; if the status flag bits indicate success, determine that the communication of the expansion card 21 is successful; if the status flag bits indicate failure, trigger an exception warning. If the parsing fails, trigger an exception warning.

[0108] In some embodiments, the electronic device 10 is further configured to determine whether the number of test commands is greater than a preset number; if it is less than the preset number, send test commands to the expansion card 21; if it is greater than the preset number, stop the test.

[0109] In some embodiments, the electronic device 10 is also used to obtain the device address and channel address of the expansion card 21 in order to obtain the instruction content of the controller that the expansion card 21 can receive.

[0110] This application also provides a storage medium. The storage medium stores computer instructions, which, when executed on a computing device, enable the computing device to perform the testing method for the expansion card provided in the aforementioned embodiments.

[0111] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented using electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can implement the described functions using different methods for each specific application; however, such implementation should not be considered beyond the scope of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0112] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit it. Although this application has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of this application without departing from the spirit and scope of the technical solutions of this application. [Simplified Explanation of the Diagram]

[0016] Figure 1 is a schematic diagram of the structure of a test system for an expansion card according to an embodiment of this application. Figure 2 is a schematic diagram of the first process of a test method for an expansion card according to an embodiment of this application. Figure 3 is a schematic diagram of an application scenario of a test method for an expansion card according to an embodiment of this application. Figure 4 is a schematic diagram of the second process of a test method for an expansion card according to an embodiment of this application. Figure 5 is a schematic diagram of the structure of an electronic device according to an embodiment of this application.

Claims

1. An improvement to a testing method for an expansion card, comprising: Configure the setting file according to the instruction content of the controller that the expansion card can receive, and the expected data content corresponding to the instruction content; Generate test instructions based on the configuration file; send the test instructions to the expansion card; receive the firmware response from the expansion card in response to the test instructions; Based on the returned data, test whether the expansion card communicates successfully; wherein, generating the test command according to the configuration file includes: reading the sending parameters of the configuration file, the sending parameters including the bit address indicating the object to which the test command is sent, the communication address indicating the object to which the test command is sent, and the function definition of the test command; filling the sending parameters into a preset command format to generate the test command.

2. The test method as described in request item 1, wherein, The testing method further includes: parsing the returned data based on the received parameters of the set file; if the parsing is successful, generating a log file based on the parsed returned data; the step of testing whether the expansion card communicates successfully based on the returned data includes: determining the status flag bits in the log file; if the status flag bits indicate success, determining that the expansion card communicates successfully; if the status flag bits indicate failure, determining that an exception warning is triggered.

3. The test method as described in request item 2, wherein, After parsing the returned data, the testing method further includes: if parsing fails, triggering an exception warning.

4. The test method as described in Request 1, wherein, After generating the test instructions according to the setting file, the testing method further includes: determining whether the number of test instructions is greater than a preset number; if it is less than the preset number, sending the test instructions to the expansion card; if it is greater than the preset number, stopping the test.

5. The test method as described in Request 1, wherein, Before configuring the setting file according to the instruction content of the controller that the expansion card can receive, the testing method further includes: obtaining the device address and channel address of the expansion card to obtain the instruction content of the controller that the expansion card can receive.

6. The test method as described in Request 1, wherein, The test command and the returned data are transmitted in-band or out-of-band.

7. The test method as described in Request 1, wherein, The number of test instructions is determined based on the number of configuration files, and each test instruction is generated from each configuration file.

8. An electronic device, improved in that it comprises: A processor, used to execute computer programs; A computer-readable storage medium storing a computer program that, when executed by the processor, performs the test method as described in any one of claims 1 to 7.

9. A testing system, improved in that the testing system includes an electronic device and an expansion card, the electronic device being configured to: configure a setting file according to the instruction content of a controller that the expansion card can receive, and the expected data content corresponding to the instruction content; generate a test instruction according to the setting file; send the test instruction to the expansion card; receive return data from the firmware of the expansion card in response to the test instruction; and test whether the expansion card has successfully communicated based on the return data; wherein... The step of generating the test instruction according to the setting file includes: reading the sending parameters of the setting file, the sending parameters including the bit address indicating the object to which the test instruction is sent, the communication address indicating the object to which the test instruction is sent, and the function definition of the test instruction; filling the sending parameters into a preset instruction format to generate the test instruction.

Images