Software processing method, board card, medium and program product

Abstract

The invention provides a software processing method, which is applied to a to-be-tested board card and comprises the following steps: acquiring a software package to be filled into the to-be-tested board card; in response to a received filling instruction, analyzing the software package to obtain information corresponding to an installation package configuration file required by local startup of the to-be-tested board card; and writing information corresponding to the installation package configuration file into a target file of the to-be-tested board card. The invention further provides a board card, a computer readable medium and a computer program product.

Description

Technical Field

[0001] The present disclosure relates to the field of testing technology, and in particular to a software processing method, a board, a medium, and a program product. Background Art

[0002] Typically, after high-temperature aging production testing of a single board or backplane, a complete system test is performed. Before starting the complete system test, some manual preparation is required: first, the main control board in the computer room is connected to a PC (Personal Computer) via a serial cable. Then, on the PC, the software version to be installed is copied to the main control board, and the driver boot program is configured. Only after the main control board successfully boots up can the peripheral boards load the version and begin the complete system test.

[0003] However, such manual filling operation is complicated and prone to errors. Each filling takes a long time, the test efficiency of single board or backplane is low, and it is difficult to achieve batch filling. Summary of the Invention

[0004] The present disclosure provides a software processing method, a board, a medium, and a program product.

[0005] In a first aspect, an embodiment of the present disclosure provides a software processing method, which is applied to a board to be tested, and includes: obtaining a software package to be installed into the board to be tested; in response to receiving a installation instruction, parsing the software package to obtain information corresponding to an installation package configuration file required for local startup of the board to be tested; and writing the information corresponding to the installation package configuration file into a target file of the board to be tested.

[0006] In a second aspect, an embodiment of the present disclosure provides a board comprising a memory and a processor; the memory stores a computer program that can be executed by the processor, and when the computer program is executed by the processor, the software processing method described in the first aspect is implemented.

[0007] In a third aspect, an embodiment of the present disclosure provides a computer-readable medium having a computer program stored thereon, and when the computer program is executed by a processor, the software processing method described in the first aspect is implemented.

[0008] In a fourth aspect, an embodiment of the present disclosure provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the software processing method described in the first aspect.

[0009] The board to be tested in the embodiment of the present disclosure obtains the software package to be installed, and in response to receiving the installation instruction, parses the software package to obtain information corresponding to the installation package configuration file required for local startup of the board to be tested, and writes the information into the target file of the board to be tested, thereby realizing automated software installation, improving the production testing efficiency of the board, and reducing costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In the accompanying drawings of the embodiments of the present disclosure:

[0011] Figure 1 A flowchart of a software processing method provided in an embodiment of the present disclosure.

[0012] Figure 2 A schematic diagram of the environment of the brush slot provided in an embodiment of the present disclosure.

[0013] Figure 3 A schematic diagram of the tooling test environment provided in an embodiment of the present disclosure.

[0014] Figure 4 A flowchart of the parsing software package provided in an embodiment of the present disclosure.

[0015] Figure 5 A schematic diagram of the process of writing information provided by an embodiment of the present disclosure into a target file.

[0016] Figure 6 A schematic diagram of the structure of a board provided in an embodiment of the present disclosure.

[0017] Figure 7 A flowchart of an exemplary software processing method for a first main control board provided in an embodiment of the present disclosure.

[0018] Figure 8 A flowchart of an exemplary software processing method for a second main control board provided in an embodiment of the present disclosure.

[0019] Figure 9 A flowchart of an exemplary software processing method for a main control board under test provided in an embodiment of the present disclosure.

[0020] Figure 10 A flowchart of an exemplary parsing software package provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0021] In order to enable those skilled in the art to better understand the technical solutions of the present disclosure, the embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0022] The present disclosure will be described more fully hereinafter with reference to the accompanying drawings, but the illustrated embodiments may be embodied in different forms, and the present disclosure should not be construed as limited to the embodiments set forth below. Rather, these embodiments are provided so that the present disclosure will be thorough and complete and will fully understand the scope of the present disclosure to those skilled in the art.

[0023] The accompanying drawings of the embodiments of the present disclosure are used to provide a further understanding of the embodiments of the present disclosure and constitute a part of the specification. Together with the detailed embodiments, they are used to explain the present disclosure and do not constitute a limitation of the present disclosure. The above and other features and advantages will become more apparent to those skilled in the art by describing the detailed embodiments with reference to the accompanying drawings.

[0024] The present disclosure may be described with reference to plan views and / or cross-sectional views by way of ideal schematic views of the present disclosure. Therefore, the exemplary illustrations may be modified according to manufacturing techniques and / or tolerances.

[0025] In the absence of conflict, the various embodiments of the present disclosure and the various features therein may be combined with each other.

[0026] The terms used in this disclosure are only used to describe specific embodiments and are not intended to limit the disclosure. As used in this disclosure, the term "and / or" includes any and all combinations of one or more related enumerated items. As used in this disclosure, the singular forms "a" and "the" are also intended to include plural forms, unless the context clearly indicates otherwise. As used in this disclosure, the terms "comprising" and "made of" specify the presence of the features, wholes, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or groups thereof.

[0027] Unless otherwise defined, all terms (including technical and scientific terms) used in this disclosure have the same meanings as those commonly understood by those skilled in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning unless expressly defined in this disclosure.

[0028] The present disclosure is not limited to the embodiments shown in the drawings, but includes modifications of the configurations formed based on the manufacturing process. Therefore, the regions illustrated in the drawings have schematic properties, and the shapes of the regions shown in the drawings illustrate the specific shapes of the regions of the elements, but are not intended to be limiting.

[0029] In some related technologies, after the single board or backplane is produced and processed and undergoes high-temperature aging testing, it will enter the whole machine testing process. Usually, the preparation work is completed manually before starting the whole machine test: connecting the serial port line to the main control board, copying the software version to be installed to the main control board on the PC, configuring the driver boot program, etc. After the main control board is successfully started, the peripheral board can load the software version and start the whole machine test. However, manual filling of the software version has the disadvantages of complex operation, easy errors, and low testing efficiency. For example, each filling takes a long time and cannot be processed in batches. Therefore, there is an urgent need for a solution that can improve the efficiency of software filling.

[0030] In the first aspect, the embodiment of the present disclosure provides a software processing method, which is applied to a board to be tested, referring to Figure 1 , which includes steps S1 to S3.

[0031] S1. Obtain a software package to be loaded into the board to be tested.

[0032] S2. In response to receiving the filling instruction, the software package is parsed to obtain information corresponding to the installation package configuration file required for local startup of the board to be tested.

[0033] S3. Write the information corresponding to the installation package configuration file into the target file of the board to be tested.

[0034] The board to be tested in the embodiment of the present disclosure obtains the software package to be installed, and in response to receiving the installation instruction, parses the software package to obtain information corresponding to the installation package configuration file required for local startup, and writes the information into the target file of the board to be tested, thereby completing the preparation work before the whole machine test, reducing manual intervention, automatically performing software installation, improving the production test efficiency of the board, and reducing costs.

[0035] The board under test is the target for the software package. After obtaining the software package, the board under test deletes the historical version of the software package corresponding to the specified directory and moves the current version into the directory. When the board under test receives the installation instruction, parsing of the software package is triggered. The disclosed embodiments do not impose any specific restrictions on the sender of the installation instruction.

[0036] In some embodiments, when the board to be tested is an environmental board in a primary state in a flush slot environment or a tooling test environment, or a board to be tested in a tooling environment, a NEP (Next Embedded Platform, a universal test platform) for providing functions such as an RF (Robot Framework) interpreter, logs, and fault diagnosis sends a filling instruction to the board to be tested. Among them, the RF interpreter is an open source and universal automated testing framework that can be used for acceptance testing and acceptance test-driven development. When the board to be tested is an environmental board in a standby state in a flush slot environment, the environmental board in the primary state in the flush slot environment receives the filling instruction sent by the NEP and forwards it across boards to the environmental board in the standby state.

[0037] The brush slot environment is an environment for performing a brush slot test. In some embodiments, the brush slot test includes a backplane signal test.

[0038] In some embodiments, the installation package configuration file includes software version information such as upper-layer business processes and dynamic libraries.

[0039] In some embodiments, the target file includes: file information to be added required for local startup, and file information to be activated required for local startup.

[0040] The embodiment of the present disclosure does not impose any special restrictions on the file type of the target file, which may be an XML (Extensible Markup Language) file or other file types.

[0041] In some embodiments, the installation device to which the board to be tested belongs is provided with at least two environment boards, and step S1 includes:

[0042] In a case where the board to be tested is an environmental board in a master state among at least two environmental boards, in response to completion of the slot refresh test, a software package to be filled is obtained.

[0043] In the case that the board to be tested is a board in a standby state among at least two environmental boards, the software package to be filled sent by the environmental board in a master state is received.

[0044] In an embodiment of the present disclosure, in a slot-refreshing environment, there may be at least two environmental boards, one of which is in the primary state, while the other is in the standby state. If the board to be tested is the primary environmental board, the software package to be loaded is obtained in response to the completion of the slot-refreshing test. If the board to be tested is the standby environmental board, the software package to be loaded is obtained from the primary environmental board of the at least two environmental boards.

[0045] In some embodiments, obtaining the software package to be packaged includes: downloading the software package to be packaged from a host computer.

[0046] In an embodiment of the present disclosure, the host computer obtains the software package to be filled after the slot refresh test is completed, and downloads the software package to the active environment board among at least two environment boards, so that the environment board obtains the software package.

[0047] After the active environmental board among the at least two environmental boards obtains the software package, if the board to be tested is one of the at least two environmental boards in a standby state, the board to be tested can obtain the software package from the active environmental board. In some embodiments, the standby environmental board obtains the software package from the active environmental board via FTP (File Transfer Protocol). FTP is a standard protocol for file transfer.

[0048] In some embodiments, the installation device to which the board to be tested belongs is provided with a unique environment board, and step S1 includes:

[0049] In a case where the board to be tested is the environment board, in response to completion of the tooling test, a software package to be packaged is obtained.

[0050] In the case that the board to be tested is at least one target board to be tested, the software package to be filled sent by the environment board is received, wherein the target board to be tested is a main control board controlled by the environment board in the installation device.

[0051] In an embodiment of the present disclosure, the environment board in the tooling test environment is unique, and the unique environment board is used to perform global management and control of at least one target board under test, and each target board under test is a main control board controlled by the environment board. In the case where the board to be tested is the environment board, in response to the completion of the tooling test, the software package to be filled is obtained; in the case where the board to be tested is at least one target board under test, the software package to be filled sent by the unique environment board is received. In some embodiments, the environment board can perform various management and control on each target board under test, such as version management, system control information transmission, and monitoring and management of whether the operating status of each hardware unit in the board is normal.

[0052] In some embodiments, obtaining the software package to be packaged includes: downloading the software package to be packaged from a host computer.

[0053] In an embodiment of the present disclosure, the host computer obtains the software package to be filled in response to the completion of the tooling test, and downloads the software package to the only environment board in the tooling test environment, so that the environment board obtains the software package. That is, when the board to be tested is the only environment board in the tooling test environment, the software package is obtained from the host computer.

[0054] After the unique environment board in the tool test environment obtains the software package, if the board under test is at least one target board under test in the tool test environment, the board under test can obtain the software package from the unique environment board. In some embodiments, the target board under test obtains the software package from the unique environment board via FTP, which is a standard protocol for file transfer.

[0055] In some embodiments, when the sending end of the filling instruction is NEP, each environmental board in the brush slot environment, the environmental board in the tooling test environment and the board under test can directly receive the filling instruction sent by NEP.

[0056] It is worth noting that the embodiment of the present disclosure does not impose any special restrictions on the number of target boards to be tested. When there are multiple target boards to be tested, batch filling of the boards can be achieved, greatly improving the efficiency of automated testing.

[0057] In order to more clearly understand the technical solutions provided by the embodiments of the present disclosure, the application environment of the embodiments of the present disclosure is described below through specific examples.

[0058] As a specific form of the embodiment of the present disclosure, refer to Figure 2 , in the brush slot environment after high-temperature aging test, it can support two main control boards (i.e. environmental boards) for software filling. The first main control board is connected to the host computer for communication, and the second main control board is connected to the first main control board for communication. The excitation line card is used to provide excitation signals for the TMPU (Tested Main Processing Unit). The first main control board is the environmental board in the main state, and the second main control board is the environmental board in the standby state. When the first main control board fails, the second main control board can take over the work of the first main control board to ensure the continuous operation of the system.

[0059] As a specific form of the embodiment of the present disclosure, refer to Figure 3After undergoing high-temperature aging testing, the main control board can support software loading for one EMPU (Environment Main Processing Unit) and eight target boards under test in a test environment. The EMPU receives excitation signals from the stimulus board, and each target board under test communicates with the host computer. The EMPU manages each target board under test on the chassis, performing tasks such as version management, transmitting system control information, and monitoring the health of each hardware unit within the board.

[0060] In some embodiments, before step S2, the method further includes: deleting the historical version of the software package; and adjusting the startup mode corresponding to the board to be tested to the local startup mode.

[0061] The startup mode is adjusted to the local startup mode so that after the board to be tested is filled, if the filled software package is used, the board to be tested can automatically start locally without manual intervention.

[0062] In some embodiments, reference Figure 4 , step S2 includes steps S21 to S22.

[0063] S21. Acquire extended header information of all extended areas from the software package; the extended header information includes: file type, and offset of a starting position of the installation package configuration file relative to a starting position of the software package.

[0064] S22. For each of the entire extended areas, in response to determining that the extended area is a target extended area based on the file type corresponding to the extended area, read information corresponding to the installation package configuration file required for local startup from the software package based on the offset in the extended header information of the target extended area; wherein the target extended area is the extended area where the information corresponding to the installation package configuration file required for local startup of the board to be tested is located.

[0065] The software package in this embodiment includes multiple extension areas, and the extension header information of all the extension areas in the software package is stored in the cache. The extension header information includes: the file type, and the offset of the starting position of the installation package configuration file relative to the starting position of the software package. Among them, the file type is used to determine whether the installation package configuration file required for local startup is stored in the extension area. In some embodiments, the extension header information may also include the file size. Based on the file type corresponding to each extension area in the cache, it is determined whether the extension area is the target extension area. In response to the judgment result that the extension area is the target extension area, the information corresponding to the installation package configuration file is read from the software package based on the offset of the installation package configuration file.

[0066] In some embodiments, obtaining the extended header information of all extended areas from the software package includes: determining the total number of extended areas in the software package; determining a total number of words to be read based on the total number of extended areas and the number of bytes corresponding to the extended header of each extended area; and reading the extended header information of all extended areas from the software package according to the total number of words to be read.

[0067] In an embodiment of the present disclosure, the number of bytes corresponding to the extended headers of each extended area is the same, and the product of the total number of extended areas and the number of bytes corresponding to the extended headers is determined as the total number of words to be read.

[0068] In some embodiments, step S2 further includes:

[0069] Determine whether the file type of the extended area is a local startup type.

[0070] In a case where the file type of the extended area is a local startup type, it is determined that the extended area is the target extended area.

[0071] In the embodiments of the present disclosure, the file type is used to determine whether the extended area stores an installation package configuration file required for local startup. If the file type of the extended area is of the local startup type, the determination result can be determined that the extended area is the target extended area. If the file type of the extended area is not of the local startup type, the determination result can be determined that the extended area is not the target extended area.

[0072] In some embodiments, in response to the determination that the extended area is not the target extended area, the process continues to determine whether the next extended area is the target extended area.

[0073] In some embodiments, reading information corresponding to the installation package configuration file required for local startup from the software package according to the offset in the extended header information of the target extended area includes:

[0074] Determining, according to the offset in the extended header information of the target extension area, a target pointer corresponding to the installation package configuration file in the target extension area in the software package;

[0075] According to the target pointer, information corresponding to each installation package configuration file required for local startup is read from the software package.

[0076] In some embodiments, the information corresponding to the installation package configuration file includes the name, version number, and path of the installation package configuration file.

[0077] The offset in this embodiment refers to the offset of the starting position of the installation package configuration file relative to the starting position of the software package. The target pointer corresponding to the installation package configuration file is determined based on the offset. The target pointer points to the starting position of the installation package configuration file, so that the information corresponding to the installation package configuration file required for local startup is read from the software package based on the target pointer of a target extension area.

[0078] In some embodiments, a temporary file system is mounted on the hard disk of the board to be tested to read information corresponding to the installation package configuration file, and after the reading is completed, the mounted file system is unmounted.

[0079] As an example, a software package is read and it is determined that the total number of extension areas in the software package is 5 and the number of bytes corresponding to the extension header of each extension area is 5. Based on the total number of extension areas and the number of bytes corresponding to the extension header of each extension area, the total number of words to be read is determined to be 25.

[0080] According to the total number of words to be read, the total number of extension areas and the number of bytes corresponding to each extension header, the extension header information of all extension areas is read from the software package, and all the extension area information is stored in the cache.

[0081] Take one of the five extension areas in turn and perform the following operations in turn: read an extension header information from the cache, and determine whether the extension area corresponding to the extension header information is the target extension area based on the file type corresponding to the extension header information. If so, read the information corresponding to the installation package configuration file in the target extension area from the software package; if not, read the next extension header information from the cache, and determine whether the extension area corresponding to the next extension header information is the target extension area. In some embodiments, three target extension areas are determined from the five extension areas, and the target extension areas store the installation package configuration files required for the local startup of the board to be tested, namely, installation package configuration file A (corresponding to offset a), installation package configuration file B (corresponding to offset b), and installation package configuration file C (corresponding to offset c).

[0082] The information corresponding to the installation package configuration file in the target extension area is read from the software package and includes:

[0083] When the extended header information corresponding to installation package configuration file A is read, a temporary file system is mounted on the hard disk of the board under test. The extended area containing installation package configuration file A is determined as the target extended area based on the file type corresponding to the extended header information. Based on the offset a corresponding to installation package configuration file A, a target pointer corresponding to offset a is determined. Based on the target pointer, the XML file of installation package configuration file A is parsed to obtain the name, version number, and path of installation package configuration file A. The mounted temporary file system is then unmounted.

[0084] When the extended header information corresponding to installation package configuration file B is read, a temporary file system is mounted on the hard disk of the board under test. The extended area where installation package configuration file B is located is determined as the target extended area based on the file type corresponding to the extended header information. Based on the offset b corresponding to installation package configuration file B, a target pointer corresponding to offset b is determined. Based on the target pointer, the XML file of installation package configuration file B is parsed to obtain the name, version number, and path of installation package configuration file B. The mounted temporary file system is then unmounted.

[0085] When the extended header information corresponding to installation package configuration file C is read, a temporary file system is mounted on the hard disk of the board under test. The extended area where installation package configuration file C is located is determined as the target extended area based on the file type corresponding to the extended header information. Based on the offset c corresponding to installation package configuration file C, a target pointer corresponding to offset c is determined. Based on the target pointer, the XML file of installation package configuration file C is parsed to obtain the name, version number, and path of installation package configuration file C. The mounted temporary file system is then unmounted.

[0086] In some embodiments, reference Figure 5 , step S3 includes steps S31 to S32.

[0087] S31 . Divide the information corresponding to the installation package configuration file to obtain information to be added and information to be activated required for local startup of the board to be tested.

[0088] S31. Write the information to be added into a first target file, and write the information to be activated into a second target file.

[0089] In an embodiment of the present disclosure, the information corresponding to the installation package configuration file is divided according to a preset format into information to be added and information to be activated required for local startup of the board to be tested, and the information is stored in a first target file and a second target file, respectively. The present embodiment of the disclosure does not impose any particular restrictions on the file types of the information to be added and the information to be activated. In some embodiments, the information to be added and the information to be activated are XML files.

[0090] In the disclosed embodiment, no special restrictions are imposed on the division results of the information corresponding to the installation package configuration file.

[0091] In some embodiments, after step S3, the method further includes: testing the board to be tested according to the target file to obtain a test result; and sending the test result.

[0092] In the disclosed embodiments, the board to be tested is tested according to the target file, i.e., the software installation test items corresponding to the installed software package are executed to obtain test results. In some embodiments, the test results are sent to the NEP, which stores the test results in a sandbox, which serves as a storage area for test logs. In other embodiments, the test results are sent to the target terminal for user viewing.

[0093] In some embodiments, the method further includes: parsing the software package to obtain a binary file, and writing the binary file into a memory; the binary file is used to test the board to be tested.

[0094] In an embodiment of the present disclosure, a software package is parsed to obtain a binary file. In some embodiments, the binary file includes software version information such as underlying drivers, product management, and driver libraries, and can be used to test the board to be tested. In some embodiments, the memory to which the binary file is written is a non-volatile storage medium.

[0095] In some embodiments, the software processing method in the above embodiments of the present disclosure can be applied to boards of various communication devices, such as routers, switches, etc., but the present disclosure is not limited thereto.

[0096] In the above-mentioned embodiment of the present disclosure, the software package to be installed is obtained through the board to be tested, and in response to receiving the installation instruction, the software package is parsed to obtain information corresponding to the installation package configuration file required for local startup, and the information is written into the target file of the board to be tested, thereby completing the preparation work before the whole machine test, reducing manual intervention, automatically performing software installation, improving the production test efficiency of the board, and reducing costs.

[0097] The board to be tested can be one of multiple environmental boards in the flash slot environment, or it can be an environmental board or a board to be tested in the tooling environment. When the board to be tested is a board to be tested, multiple boards to be tested can be controlled by the global management of the same environmental board, thereby realizing batch filling of the boards to be tested, greatly improving the efficiency of automated testing.

[0098] In the second aspect, the present disclosure provides a board card, referring to Figure 6 , which includes a memory 602 and a processor 601; the memory 602 stores a computer program that can be executed by the processor 601, and when the computer program is executed by the processor 601, the software processing method described in the first aspect is implemented.

[0099] The processor 601 and the memory 602 are connected via one or more I / O interfaces 603 , and the interfaces 603 are configured to implement information exchange between the processor 601 and the memory 602 .

[0100] The processor 601 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 602 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read-write interface) 603 is connected between the processor 601 and the memory 602, and can realize information exchange between the processor 601 and the memory 602, including but not limited to a data bus (Bus), etc.

[0101] It should be noted that this board is a board corresponding to the above-mentioned software processing method. All implementation methods in the above-mentioned method embodiments are applicable to the embodiments of this board and can achieve the same technical effects.

[0102] In a third aspect, an embodiment of the present disclosure provides a computer-readable medium having a computer program stored thereon, and when the computer program is executed by a processor, the software processing method described in the first aspect is implemented.

[0103] It should be noted that the computer-readable medium is a medium corresponding to the above-mentioned software processing method. All implementation methods in the above-mentioned method embodiments are applicable to the embodiments of the computer-readable medium and can achieve the same technical effects.

[0104] In a fourth aspect, an embodiment of the present disclosure provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the software processing method described in the first aspect.

[0105] It should be noted that the computer program product is a program product corresponding to the above-mentioned software processing method. All implementation methods in the above-mentioned method embodiments are applicable to the embodiments of the computer program product and can achieve the same technical effects.

[0106] In order to enable those skilled in the art to more clearly understand the technical solutions provided by the embodiments of the present disclosure, the technical solutions provided by the embodiments of the present disclosure are described in detail below through specific examples.

[0107] Example 1

[0108] For example, as a specific form of the embodiment of the present disclosure, refer to Figure 2In a slot-scanning environment, both the first and second main control boards are environment boards. They are numbered according to their corresponding slot numbers to form SSN (Smallslot number) and LSN (Large slot number) main control boards. The SNN main control board is the first main control board and is in active mode, while the LSN main control board is the second main control board and is in standby mode.

[0109] Reference Figure 7 The software package filling process of the first main control board in the active state includes steps 701 to 704.

[0110] Step 701: After the slot refresh test is completed, the host computer obtains the software package to be filled and downloads it to a designated directory of the first main control board (the environment main control board in the active state).

[0111] Step 702: The NEP sends a software installation instruction to the first main control board.

[0112] Step 703 : In response to receiving the software installation instruction, the first main control board obtains and parses the software package, executes the software installation test items, and sends the test results to the NEP.

[0113] The first main control board obtains and parses the software package including:

[0114] Obtain the software package from the host computer.

[0115] Delete the historical version of the software package in the specified directory of the first main control board and move the software package into the directory.

[0116] Parse the software package to obtain a corresponding binary file, and write the binary file to a non-volatile storage medium. The binary file includes software version information such as underlying drivers, product management, and driver libraries, and is used to test the first main control board.

[0117] Change the startup mode of the first main control board to local startup mode.

[0118] The software package is read to determine that the total number of extensions in the software package is 5, and the number of bytes corresponding to the extension header of each extension is 5. Based on the total number of extensions and the number of bytes in the extension headers in the extensions, the total number of words to be read is determined to be 25. Extended header information for all extensions in the software package is read based on the total number of words to be read and stored in a cache. The extended header information includes the file type and the offset of the starting position of the installation package configuration file relative to the starting position of the software package.

[0119] Based on the total number of extensions, the following operations are performed on one of the five extensions: an extension header is read from the cache, and based on the file type of the extension header, it is determined whether the extension corresponding to the extension header is the target extension. If so, the information corresponding to the installation package configuration file in the target extension is read from the software package. If not, the next extension header is read from the cache, and a determination is made as to whether the extension corresponding to the next extension header is the target extension. In this embodiment, there are three target extensions, including installation package configuration file A (corresponding to offset a), installation package configuration file B (corresponding to offset b), and installation package configuration file C (corresponding to offset c).

[0120] When the extended header information corresponding to installation package configuration file A is read, a temporary file system is mounted on the hard disk of the board under test. The extended area where installation package configuration file A is located is determined as the target extended area based on the file type corresponding to the extended header information. Based on the offset a corresponding to installation package configuration file A, the position of the target pointer corresponding to offset a is determined. The XML file of installation package configuration file A and its corresponding information (name, version number, and path) are parsed to obtain the file. The mounted temporary file system is then unmounted.

[0121] When the extended header information corresponding to installation package configuration file B is read, a temporary file system is mounted on the hard disk of the board under test. The extended area where installation package configuration file B is located is determined as the target extended area based on the file type corresponding to the extended header information. Based on the offset b corresponding to installation package configuration file B, the position of the target pointer corresponding to offset b is determined, and the XML file of installation package configuration file B and its corresponding information (name, version number, and path) are parsed to obtain. The mounted temporary file system is then unmounted.

[0122] When the extended header information corresponding to the installation package configuration file C is read, a temporary file system is mounted on the hard disk of the board under test. The extended area where the installation package configuration file C is located is determined as the target extended area based on the file type corresponding to the extended header information. Based on the offset c corresponding to the installation package configuration file C, the position of the target pointer corresponding to the offset c is determined, and the XML file of the installation package configuration file C and its corresponding information (name, version number, and path) are parsed to obtain. The mounted temporary file system is then unmounted.

[0123] The information corresponding to the installation package configuration file A, the information corresponding to the installation package configuration file B and the information corresponding to the installation package configuration file C are divided to obtain the information to be added and the information to be activated required for the local startup of the board to be tested, and are written into the corresponding target files respectively.

[0124] The first main control board performs a test according to the target file, obtains a test result, and sends the test result to the NEP.

[0125] In step 704, the NEP receives the test results and saves them in a sandbox for storing test logs.

[0126] Reference Figure 8 The software package filling process of the second main control board in the standby state includes steps 801 to 805.

[0127] Step 801: After the slot refresh test is completed, the host computer obtains the software package to be filled and downloads it to the designated directory of the first main control board (the environment main control board in the active state).

[0128] Step 802: The NEP sends a software installation instruction to the first main control board.

[0129] Step 803: The first main control board receives the software installation instruction and sends the software installation instruction to the second main control board (the environment main control board in the standby state) across boards.

[0130] Step 804: The second main control board receives the software installation instruction, receives the software package from the first main control board via FTP, obtains and parses the software package, executes the software installation test items, and sends the test results to the NEP.

[0131] The second main control board obtains and parses the software package including:

[0132] Delete the historical version of the software package in the specified directory of the second main control board and move the software package into the directory.

[0133] The software package of the first main control board is received via FTP, parsed to obtain the corresponding binary file, and written to a non-volatile storage medium. The binary file includes software version information such as the underlying driver, product management, and driver library, and is used to test the second main control board.

[0134] Change the boot mode of the second main control board to local boot mode.

[0135] The software package is read to determine that the total number of extensions in the software package is 5, and the number of bytes corresponding to the extension header of each extension is 5. Based on the total number of extensions and the number of bytes, the total number of words to be read is determined to be 25. Based on the total number of words to be read, the total number of extensions, and the number of bytes corresponding to the extension headers, the extended header information of all extensions in the software package is read and stored in a cache. The extended header information includes the file type and the offset of the starting position of the extension relative to the starting position of the software package.

[0136] The following operations are performed on each of the five extension areas: an extension header is read from the cache, and based on the file type of the extension header, the extension area corresponding to the extension header is determined to be the target extension area. If so, the information corresponding to the installation package configuration file in the target extension area is read from the software package. If not, the next extension header is read from the cache, and the extension area corresponding to the next extension header is determined to be the target extension area. In this embodiment, there are three target extension areas, including installation package configuration file A (corresponding to offset a), installation package configuration file B (corresponding to offset b), and installation package configuration file C (corresponding to offset c).

[0137] When the extended header information corresponding to the installation package configuration files A, B, and C is read, a temporary file system is mounted on the hard disk of the board under test. The extension area where the installation package configuration file is located is determined as the target extension area based on the file type corresponding to the extended header information. Based on the offset corresponding to the installation package configuration file, the target pointer corresponding to the offset is determined. The XML file of the installation package configuration file and its corresponding information: name, version number, and path are parsed, and the mounted temporary file system is unmounted.

[0138] The information corresponding to the installation package configuration file is divided to obtain information to be added and information to be activated required for local startup of the board to be tested, and the information is written into corresponding target files respectively.

[0139] The second main control board performs a test according to the target file, obtains a test result, and sends the test result to the NEP.

[0140] Step 805: NEP receives the test results and saves them to the sandbox.

[0141] In this example, the environment board in the main or standby state responds to the received filling instruction, parses the software package, obtains the information corresponding to the installation package configuration file required for local startup, and writes the information into the target file, thereby realizing automated software filling, improving the production test efficiency of the board and reducing costs.

[0142] Example 2

[0143] For example, as a specific form of the embodiment of the present disclosure, refer to Figure 2 In the tooling test environment, the environment main control board is the environment board, and the main control boards numbered 1 to 8 are the main control boards under test. The software package installation process for the environment boards in the tooling test environment is roughly the same as steps 901 to 904 in Example 1. To avoid repetition, we will not elaborate on them here.

[0144] Reference Figure 9The software package filling process of the main control board under test includes steps 901 to 904.

[0145] Step 901: After the production test of the tested main control board, the host computer obtains the software package to be filled and downloads it to the designated directory of the environment main control board.

[0146] Step 902: The NEP sends a software installation instruction to the main control board under test.

[0147] Step 903: The main control board under test receives the software installation instruction, obtains and parses the software package, executes the software installation instruction, and sends the test result to the NEP.

[0148] The software package obtained and parsed by the main control board under test includes:

[0149] Delete the historical version of the software package in the specified directory of the tested main control board and move the software package into it.

[0150] The software package for the environment's main control board is received via FTP, parsed to obtain the corresponding binary file, and written to a non-volatile storage medium. The binary file includes software version information such as the underlying driver, product management, and driver library, and is used to test the main control board under test.

[0151] Adjust the startup mode of the main control board under test to local startup mode.

[0152] The software package is read to determine that the total number of extensions in the software package is 7, and the number of bytes corresponding to the extension header of each extension is 5. Based on the total number of extensions and the number of bytes, the total number of words to be read is determined to be 35. Based on the total number of words to be read, the total number of extensions, and the number of bytes corresponding to the extension headers, the extended header information of all extensions in the software package is read and stored in a cache. The extended header information includes the file type and the offset of the starting position of the extension relative to the starting position of the software package.

[0153] Take one of the seven extension areas in turn and perform the following operations in turn: read an extension header information from the cache, and based on the file type of each extension header information, determine whether the extension area corresponding to the extension header information is the target extension area. If so, read the information corresponding to the installation package configuration file in the target extension area from the software package; if not, read the next extension header information from the cache, and determine whether the extension area corresponding to the next extension header information is the target extension area. In this embodiment, there are five target extension areas, including installation package configuration file A (corresponding to offset a), installation package configuration file B (corresponding to offset b), installation package configuration file C (corresponding to offset c), installation package configuration file D (corresponding to offset d), and installation package configuration file E (corresponding to offset e).

[0154] When the extended header information corresponding to installation package configuration files A-E is read, a temporary file system is mounted on the hard disk of the board under test. The extension area containing the installation package configuration file is determined as the target extension area based on the file type corresponding to the extended header information. The target pointer corresponding to the offset in the installation package configuration file is determined based on the offset. The XML file of the installation package configuration file and its corresponding information, including name, version number, and path, are parsed to obtain the file. The mounted temporary file system is then unmounted.

[0155] The information corresponding to the installation package configuration file is divided to obtain information to be added and information to be activated required for local startup of the board to be tested, and the information is written into corresponding target files respectively.

[0156] The main control board under test performs a test according to the target file, obtains a test result, and sends the test result to the NEP.

[0157] Step 904: NEP receives the test results and saves them to the sandbox.

[0158] In this example, an environment main control board in the tooling test environment can perform global control over multiple main control boards under test. The main control board under test responds to the received filling instruction, parses the software package, obtains the information corresponding to the installation package configuration file required for local startup, and writes the information into the target file, thereby realizing automated software filling, improving the production testing efficiency of the board and reducing costs.

[0159] Example 3

[0160] For example, as a specific form of the embodiment of the present disclosure, refer to Figure 10 The parsing process of the software package by the board to be tested includes steps 1001 to 1009.

[0161] Step 1001: Open and read the software package to be filled.

[0162] Step 1002: Read the extended header information of each extended area in the software package and store it in the cache.

[0163] Specifically, the total number of extensions in the software package is first obtained. The total number of words to be read is calculated based on the total number of extensions and the number of bytes corresponding to the extension header of each extension. Based on the total number of words to be read, the total number of extensions, and the number of bytes corresponding to the extension header, the extension header information of each extension in the software package is read and stored in a cache.

[0164] Step 1003: Read an extension header from the cache according to the total number of extension areas, wherein the extension header includes: the file type and the offset of the starting position of the extension area relative to the starting position of the software package.

[0165] Step 1004 , determining whether the file type corresponding to the extended header information is a local startup type, if so, executing step 1005 , if not, executing step 1006 .

[0166] Step 1005: Obtain information corresponding to the installation package configuration file based on the offset of the starting position of the installation package configuration file relative to the starting position of the software package.

[0167] Specifically, first determine the target pointer corresponding to the installation package configuration file in the target extension area in the software package based on the offset of the starting position of the installation package configuration file relative to the starting position of the software package, and then read the information corresponding to the installation package configuration file required for local startup from the software package based on the target pointer.

[0168] Step 1006: Increase the extended header count by one to obtain an adjusted extended header count. In the initial state, the extended header count is 0.

[0169] Step 1007, determine whether the adjusted extension header count value is equal to the total number of extension areas. If so, it means that the information corresponding to all installation package configuration files required for local startup has been read from all extension areas, and execute step 1008. If not, execute step 1003.

[0170] Step 1008 , divide the information corresponding to all the read installation package configuration files to obtain the information to be added and the information to be activated required for local startup of the board to be tested, and write the information to be added and the information to be activated into the first target file and the second target file respectively.

[0171] Among them, the processor is a device with data processing capabilities, including but not limited to the central processing unit (CPU); the memory is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically such as SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read-write interface) is connected between the processor and the memory, and can realize information exchange between the memory and the processor, including but not limited to the data bus (Bus), etc.

[0172] Those skilled in the art will appreciate that all or some of the steps, systems, and functional modules / units in the apparatus disclosed above may be implemented as software, firmware, hardware, or a suitable combination thereof.

[0173] In hardware implementations, the division between functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be performed by several physical components in cooperation.

[0174] Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit (CPU), a digital signal processor, or a microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or temporary medium). As is well known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH) or other disk storage; compact disc (CD-ROM), digital versatile disc (DVD) or other optical disc storage; magnetic cassettes, tapes, disk storage or other magnetic storage; any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, as is well known to those skilled in the art, communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0175] The present disclosure has disclosed example embodiments, and although specific terms are employed, they are used and should be interpreted only in a general illustrative sense and not for purposes of limitation. In some instances, it will be apparent to those skilled in the art that, unless otherwise expressly indicated, features, characteristics, and / or elements described in conjunction with a particular embodiment may be used alone or in combination with features, characteristics, and / or elements described in conjunction with other embodiments. Therefore, it will be understood by those skilled in the art that various changes in form and detail may be made without departing from the scope of the present disclosure as set forth in the appended claims.

Claims

1. A software processing method, applied to a board to be tested, comprising: Obtaining a software package to be loaded into the board to be tested; In response to receiving the filling instruction, parsing the software package to obtain information corresponding to the installation package configuration file required for local startup of the board to be tested; Write the information corresponding to the installation package configuration file into the target file of the board to be tested.

2. The method according to claim 1, wherein The installation device to which the board to be tested belongs is provided with at least two environment boards, and the obtaining of the software package to be loaded into the board to be tested includes: When the board to be tested is an environmental board in a master state among the at least two environmental boards, in response to completion of the slot refresh test, obtaining a software package to be filled; In a case where the board to be tested is an environmental board in a standby state among at least two environmental boards, the software package to be filled sent by the environmental board in a master state is received.

3. The method according to claim 1, wherein The installation device to which the board to be tested belongs is provided with a unique environment board, and the obtaining of the software package to be loaded into the board to be tested includes: In a case where the board to be tested is the environment board, in response to completion of the tooling test, obtaining a software package to be packaged; When the board to be tested is at least one target board to be tested, the software package to be filled sent by the environment board is received; wherein the target board to be tested is a main control board controlled by the environment board in the installation device.

4. The method according to claim 2 or 3, wherein: The step of obtaining the software package to be filled includes: Download the software package to be filled from the host computer.

5. The method according to claim 1, wherein Before parsing the software package to obtain information corresponding to the installation package configuration file required for local startup of the board to be tested, the method further includes: Delete historical versions of software packages; The startup mode corresponding to the board to be tested is adjusted to the local startup mode.

6. The method according to claim 1, wherein The parsing of the software package to obtain information corresponding to the installation package configuration file required for local startup of the board to be tested includes: Acquire extended header information of all extended areas from the software package; the extended header information includes: file type, offset of the starting position of the installation package configuration file relative to the starting position of the software package; For each of all the extended areas, in response to determining that the extended area is a target extended area based on the file type corresponding to the extended area, information corresponding to the installation package configuration file required for local startup is read from the software package based on the offset in the extended header information of the target extended area; wherein the target extended area is the extended area where the information corresponding to the installation package configuration file required for local startup of the board to be tested is located.

7. The method according to claim 6, wherein: The step of obtaining the extended header information of all the extended areas from the software package includes: determining a total number of extensions in the software package; Determining the total number of words to be read according to the total number of the extension areas and the number of bytes corresponding to the extension header of each extension area; According to the total number of words to be read, extended header information of all extended areas is read from the software package.

8. The method according to claim 6, wherein: The method further comprises: Determine whether the file type of the extended area is a local startup type; In a case where the file type of the extended area is a local startup type, it is determined that the extended area is the target extended area.

9. The method according to claim 6, wherein: The step of reading information corresponding to the installation package configuration file required for local startup from the software package according to the offset in the extended header information of the target extended area includes: Determining, according to the offset in the extended header information of the target extension area, a target pointer corresponding to the installation package configuration file in the target extension area in the software package; According to the target pointer, information corresponding to the installation package configuration file required for local startup is read from the software package.

10. The method according to claim 1, wherein Writing the information corresponding to the installation package configuration file into the target file of the board to be tested includes: Dividing the information corresponding to the installation package configuration file to obtain the information to be added and the information to be activated required for local startup of the board to be tested; The information to be added is written into a first target file, and the information to be activated is written into a second target file.

11. The method according to claim 1, wherein After writing the information corresponding to the installation package configuration file into the target file of the board to be tested, the method further includes: Testing the board to be tested according to the target file to obtain a test result; The test result is sent.

12. The method according to claim 1, wherein The method further comprises: The software package is parsed to obtain a binary file, and the binary file is written into a memory; the binary file is used to test the board to be tested.

13. A board comprising a memory and a processor; the memory stores a computer program executable by the processor, and the computer program, when executed by the processor, implements the software processing method according to any one of claims 1 to 12.

14. A computer-readable medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the software processing method according to any one of claims 1 to 12 is implemented.

15. A computer program product comprising a computer program, wherein when the computer program is executed by a processor, the software processing method according to any one of claims 1 to 12 is implemented.

Images