WO2013007068A1

WO2013007068A1 - Automatic test system and method oriented to functions of hardware apparatus

Info

Publication number: WO2013007068A1
Application number: PCT/CN2011/080802
Authority: WO
Inventors: 程旭; 郑衍松; 黄侃; 李皓; 张涛; 陈守亮
Original assignee: 北京北大众志微系统科技有限责任公司; 济南众志信息技术有限公司
Priority date: 2011-07-11
Filing date: 2011-10-14
Publication date: 2013-01-17
Also published as: CN102346235A

Abstract

An automatic test system and method oriented to functions of a hardware apparatus. The system comprises a field programmable gate array (FPGA) test target platform used as a test platform of a tested hardware apparatus, and further comprises an FPGA bit file management and burning sub-system, a basic input/output system (BIOS) file management and burning sub-system, and an automatic test system platform. After initialization is completed, during a test, the automatic test system platform provides test control for the test target platform, saves an automatic test script file and a test case suite required for the automatic test, and saves a test result. During the test, the automatic test script is used to complete an automatic test process, and the test case suite is used to complete the function test. The test system has generality and strong expandability. Specific environment initialization, execution control, and result analysis modules can be added according to actual requirements.

Description

Automatic test system and method for hardware device function

Technical field

The present invention relates to the field of development and testing technologies for hardware device functions, and in particular, to an automatic test system and method for hardware device functions.

Background technique

Functional verification and performance evaluation based on FPGA (Field Programmable Gate Array) prototype system is an important part of the integrated circuit development process. In the FPGA-based computer prototype system development platform, assembler testing of various hardware device modules (such as hard disk controllers, USB controllers, network adapters, etc.) is a necessary step for hardware device functional verification. Currently there are several problems in this type of testing:

First, in order to ensure the coverage of the test and to meet the stress test requirements in a specific situation, the test process for a single functional module may involve a large number of test procedures, and it is difficult to test by a manual operation for a large number of test programs involved. .

Second, for different tests, the criteria for determining the success of the test from the test results are not the same, and some test vectors may involve comparative analysis of binary data. If you use the manual method to test, it often needs to be implemented by other tools, which will inevitably affect the test efficiency.

Third, for the recording and statistics of a large number of test results, it is equally difficult to implement manual test methods that rely on manpower.

Therefore, at present, for such tests, the test process is generally completed by writing test scripts. However, due to differences in modules and differences in program characteristics of test scripts, the expressions of the results obtained by testing different modules are not the same, and often need to be Different unit tests write different test scripts, which inevitably result in less efficient and costly results because they are not versatile.

Among the existing automatic test related patents, the focus of the test scheme is different, and it is not suitable for the software test of each device function in the FPGA-based computer prototype system development platform. For example, the patent application number 200710076906.1 "a software automatic testing tool and method for embedded devices" mainly targets software testing of embedded devices such as mobile phones and fixed machines, and its technical solutions are required. Establish a special test case XML script and parse it. The patent "Multi-chip automatic test method based on programmable logic device" with application number 200710134884.X focuses on testing the electrical characteristics in the FPGA circuit and cannot meet the system level hardware. Test requirements for equipment functions; patent "Embedded software automatic test system and its test method" with application number 200610126966.5 and patent "Application for an embedded software automated test device and method" with application number 200410064302.1 The test method proposed for the software system.

Therefore, this requires a general-purpose automatic test system and method for hardware device functions to solve the problems in the current test. Summary of the invention

The technical problem to be solved by the present invention is to provide an automatic test system and method for hardware device functions, which is used to solve the problem that the test in the existing hardware device test system is complicated and non-universal.

In order to solve the above problems, the present invention proposes an automatic test system for hardware device functions, including a field programmable gate array (FPGA) test target platform as a test platform for a hardware device under test, and further includes:

The FPGA bit file management and programming subsystem is connected to the FPGA test target platform through the FPGA interface, and is set as: Manage the specific bit files required by the hardware device function module running on the FPGA test target platform; The FPGA interface burns to the FPGA test target platform a bit file corresponding to the currently tested hardware device function module;

The basic input/output system (BIOS) file management and programming subsystem is connected to the FPGA test target platform through the BIOS emulator, and is set to: Burn the BIOS file required for testing to the BIOS emulator when preparing for testing;

The automatic test system platform is connected to the FPGA test target platform through a hardware debugger, and is set to: provide test control on the test target platform, save the automatic test script file and test case set required for automatic test, and use the automatic test in the test. The script completes the automated test process, completes the functional test through the test case set, and is used to save the test results. Preferably, the BIOS file provided by the BIOS file management and programming subsystem to the BIOS emulator includes:

Used to wait for a corresponding infinite loop address after the initialization process and before starting the test;

After skipping the infinite loop corresponding to the above-mentioned infinite loop address, the BIOS initializes the segment descriptor used by the test environment, and the corresponding protection mode, and finally jumps to address 0x0:0x0 to enter the protection mode;

The segment descriptor includes a segment descriptor of a code segment CS having a base address of 0x00000000, and the code segment starts from a physical address of 0x00000000;

The protection mode starts from 0x0000:0x00B00000, that is, the physical address OxOOBOOOOO;

Data segment DS, ES, FS, and stack segment SS segment descriptor base address is 0x00000000. When the segment register corresponding to the segment descriptor is read or written, the actual physical address read and write is equal to the logical address used.

Preferably, the test code structure of the test case file saved by the automatic test system platform includes:

Start with a text segment, indicate the 32-bit instruction mode, and begin with an offset of 0;

A memory area used to save result data during the test process and at the end;

A fixed address that should be used to notify the test script that the test has completed after the test has finished.

Preferably, the automatic test system platform expresses the test result after the test ends includes one of the following methods: whether the execution ends, whether the execution is successful, the test result is saved, and the test result is compared.

Preferably, the automatic test script file of the automatic test system platform includes absolute path information for saving a folder where the test script file is located.

The present invention also provides a test method based on the above-mentioned automatic test system for hardware device functions, including: The global test initialization step initializes the automatic test system platform, sets the breakpoint information required for the test run, counts the test case file set, obtains a list of test files, and performs the following two steps for each test case file in the list:

The single file test preparation step, reset the FPGA test target platform, perform BIOS initialization, load the test case file required for the current test into the memory of the FPGA test target platform, and after entering the protection mode, set the test program to terminate the address breakpoint;

Single file test execution step, execute the test case program in protected mode, use a specific memory area according to the specified memory usage specification, and save the result in the specified test result data area. After the test execution ends, jump to the termination. The address triggers the termination address breakpoint set in the preparation step. The test result is processed according to the corresponding result representation mode during the test and/or after the test.

Preferably, the test code structure of the test case file includes:

The beginning of the text segment, indicating the 32-bit instruction mode, the beginning of the offset of 0; the memory area used to save the result data during the test process and at the end;

Preferably, in the process of initializing the BIOS, the method includes: configuring a loop waiting for a corresponding infinite loop address after the initialization process and before starting the test execution; configured to skip the infinite loop corresponding to the infinite loop address, and the BIOS initializes the The segment descriptor used by the test environment, and the corresponding protection mode, and finally jump to address 0x0:0x0 to enter the protection mode;

Preferably, the manner in which the automatic test system platform expresses the test result includes the following manner One: Whether to execute the end, whether the execution is successful, save the test results, and compare the test results.

Preferably, the global test initialization step further comprises: adding the absolute path information of the folder where the test script file is located to the automatic test script file of the automatic test system platform.

The automatic test system and the automatic test method of the invention use the support of a hardware debugger (such as FS2) to implement a universal automatic test system by defining a unified test execution specification, and support automatic execution of test modules of different hardware module units, and Analyze and judge the test results and statistics. Compared with the prior art, the automatic test system and method use software to test hardware device functions, and has the following main features:

First, the FPGA target test platform is a complete general-purpose PC hardware system that can run BIOS (Basic Input/Output System) or even an operating system;

Second, the main focus is on the functional verification of one or some hardware modules in the system-level hardware environment, complementing the simulation verification and hardware electrical feature verification, which is of great significance for the operating system development of the target hardware platform;

Third, based on the hardware debugger, the full implementation control of the FPGA target test platform can be realized in the automatic test system platform to meet the needs of various tests;

Fourth, the test can be implemented based on the Tel language, and can run on the Windows/Linux operating system across platforms to meet different hardware environment requirements;

Fifth, the test system has strong scalability, and can add specific environment initialization, execution control, and result analysis modules according to actual needs. BRIEF abstract

Figure 1 is a schematic structural view of an automatic test system;

Figure 2 is an automatic test flow chart of the automatic test system;

3 is a flow chart showing the operation of a specific application embodiment of the automatic test system.

Preferred embodiment of the invention

In order to make the objects, technical solutions and advantages of the present invention more clear, the present invention will be described below with reference to the accompanying drawings. Further details are given.

As shown in Figure 1, a schematic diagram of the composition of an automatic test system for hardware device functions using an FPGA as an example is given. The automatic test system for hardware device functions includes the following parts:

FPGA test target platform, which is the system development platform of FPGA, the FPGA-based hardware device on it is the tested object, and in some environments can also be changed to other system development board platforms;

The FPGA bit file management and programming subsystem is connected to the FPGA test target platform through the FPGA interface, and is responsible for managing the hardware device function modules running on the FPGA test target platform, and the specific bit files required by the hardware device function modules are The hardware platform developer provides the FPGA bit file management and programming subsystem. When preparing for testing, the bit file corresponding to the currently tested hardware device function module is programmed into the FPGA board through the FPGA interface.

The BIOS file management and programming subsystem is connected to the FPGA test target platform through the BIOS emulator, and is responsible for maintaining the BIOS (Basic Input/Output System) chip program for the FPGA test target platform to ensure the FPGA test target. The normal operation of the platform, which burns the BIOS program used for the test to the BIOS emulator when preparing for testing. Among them, the BIOS emulator can also provide a high-efficiency BIOS usage, which avoids the need to change the BIOS chip when updating the BIOS program.

The automatic test system platform is connected to the FPGA test target platform through a hardware debugger, and is an operation control platform of the automatic test system for providing control functions for the test target platform. The hardware debugger is an FS2 hardware debugger or other suitable hardware debugger. The automatic test system platform stores the automatic script files and test case sets required for automatic testing. The automatic test process is completed by the automatic test script during the test, and the function test is completed through the test case set.

In order to ensure the normal execution of the automatic test script, it is necessary to specify the memory layout of the FPGA test target platform. The following specifications are made in the BIOS version used by the FPGA test target platform: First, after the BIOS completes the necessary initialization process, it starts execution. Before the test, enter a loop waiting, the address of the infinite loop is 0xF000: 0x3F2F;

Second, after skipping the infinite loop corresponding to the above-mentioned infinite loop address, the BIOS initializes the segment descriptor used by the test environment, and jumps to address 0x0:0x0 to enter the protection mode to continue execution. The protection mode has the following characteristics: The segment descriptor base address of segment CS is 0x00000000, that is, the code segment is from the object. Start at address 0x00000000; after entering this protection mode, execution will start from 0x0000:0x00B00000 (ie, physical address OxOOBOOOOO); the segment descriptor base addresses of data segments DS, ES, FS and stack segment SS are both 0x00000000, then When these segment registers are used for memory read and write, the physical address actually read and written is equal to the value of the logical address used. It should be noted that in the above specification, according to the set segment descriptor, theoretically all 4G memory address space can be read and written, but considering the actual hardware configuration and the security of other code and data in the memory, it is recommended to use The area is 0x100000 to 0x800000 and the area above OxAOOOOO, and be careful not to overlap with the I/O address space.

As shown in Fig. 2, a schematic diagram of an automatic test flow of an automatic test system based on the functions of the hardware device shown in Fig. 1 is given. The automated test process implements an automated test process through automated test scripts executed in the debug environment. No manual intervention is required during the test, which greatly reduces the workload and improves test efficiency. The automated testing process is divided into three phases:

Phase 1, global test initialization phase

In the global test initialization phase, the initialization of the automatic test system platform and the FPGA target test platform is mainly performed, and the breakpoints required for the test run are set. In addition, this stage needs to analyze and save the file name information of the test target file set, which will be used in the subsequent testing process. This process only needs to be performed once in an automated test process.

The second phase, single file test preparation phase In the single file test preparation phase, it is responsible for the environmental preparation work before each test file is run. The main tasks include: resetting the FPGA test platform and waiting for the BIOS to be initialized; loading the files to be tested into the memory of the FPGA platform; after the FPGA platform enters the protection mode, setting the test program to terminate the address breakpoint, so that The monitoring test program is executed later.

Phase III, single file test execution phase

During the single file test execution phase, the test target file will continue to be executed in the protected mode that was previously initialized.

During the test, the test program can use a specific memory area as needed according to the specified memory usage specifications, and save the result in the specified test result data area. After the test execution is completed, it will jump to the termination address, triggering the breakpoint set by the automatic test system. Upon reaching the termination address After the breakpoint, the automatic test system will determine the execution result of the test program according to the settings and save it in the result directory.

For each file that has not been tested, the second and third phase processes described above will be executed in sequence until all files have been tested.

In the automatic test process shown in Figure 2, the following steps are specifically included:

First, set the triggers required for the test, check the legality of the test file directory, and obtain a list of test files; check the validity of the result file directory. Legitimacy testing avoids reading and writing errors when reading test files or saving test results.

Then, non-empty detection is performed on the obtained test file list. If all the test files have been tested, the test process is ended. If it is non-empty, it indicates that there are still files to be tested, then the next one is obtained from the test file list. The test file further determines whether the test file has been tested. If it has been tested, it returns a test to check whether the test file list is not empty. If it is not tested, it enters the single file test preparation phase.

In the single file test preparation phase, the RESET (reset) instruction is first issued to reset the FPGA platform, and the first breakpoint (breakpoint 1) is set in the infinite loop phase before entering the protection mode, and then the GO instruction is issued, and the FPGA platform starts to execute the test. During the test, it is judged whether the first breakpoint is reached, and if it does not arrive, the judgment is continued. If the first breakpoint is reached, the current test file is loaded into the memory (the address is OxOOBOOOOO); then, skip The infinite loop at the first breakpoint sets the second breakpoint (breakpoint 2: EIP 0x00000000) in the first instruction of the protection mode, issues the GO instruction, and the FPGA platform continues to execute, determining whether the second breakpoint is reached during the process. If it does not arrive, continue to judge. If the second breakpoint has been reached, the instruction pointer (EIP) address is changed to the test file entry address OxOOBOOOOO, and the single file test execution phase is entered.

In the single file test execution phase, the third breakpoint needs to be set as the test termination address breakpoint (breakpoint 3: EIP 0x00F00000), then the GO command is issued, the test code begins execution, and during execution, it is determined whether the third breakpoint is reached. If the judgment is continued, if the third breakpoint has been reached, the test result data is saved to a file and processed as needed. After the single file test is finished, it returns to determine whether the test file list is not empty, until all the test files have been tested, and the whole test process ends. As shown in Figure 3, the basic operation flow chart of the automatic test system with the FS2 hardware debugger as an example is given. The basic operation flow includes the following steps:

S301: Turn on the power of the FPGA board as the test target platform, turn on the power switch to power on and start the FPGA board;

S302: The bit file corresponding to the FPGA board is burned from the FPGA bit file management and programming subsystem to the FPGA board via the FPGA interface, and the bit file includes a bit file suitable for the target function module to be tested;

S303: burning a BIOS file required for testing from the BIOS file management and burning subsystem to the BIOS emulator;

S304: Press the reset button on the FPGA board to initialize the state of the FPGA board and execute the HALT command in the FS2 backend control system in the automatic test system;

S305: Initialize the hardware debugger, in the menu bar of the FS2 console (Console) program, select File->Source, load the ice-tle.tcl script attached to the FS2, and load the ICE basic running environment support;

S306: Establish a suitable test target file set folder, configure a test file (including but not limited to a test case file) and a test script on the computer system where the FS2 debugger and the test script are located, and create a new directory in the computer system (guarantee this) The absolute path of the mail directory does not contain spaces), H does not have "C:/SomeDir", create a bin directory in the newly created directory, and copy all test binaries into the bin directory;

S307: According to the path of the folder where the test target file set is located, modify the first instruction in the automatic test script file auto_run_test.tcl, and change the path to the absolute path of the newly created directory in step S306;

S308: Load an automatic test script to execute the test. In the console of the FS2 (Console), execute File->Source, load the modified automatic test script file auto_run_test.tcl, and start the test;

S309: Collect test result data. After all tests are completed, all test results are saved in the result directory under the test directory. The result directory can be pre-established or automatically created before the first test. In order to ensure that the test target assembly code and the automatic test system can be well coupled and functioning properly, some specifications of the test target assembly code format and memory usage are required. At present, the test system mainly has the following specifications for the test target assembly code.

For test code structure templates: This automated test system supports AT&T format assembly and Intel format assembly test files. Here, the AT&T format is used as an example to introduce the relevant conventions and structure templates for writing test code. For the test code memory usage specification: Since the execution environment of the test code is a protected mode environment temporarily constructed by the BIOS, the code segment and data segment configuration include: The code segment base address starts from the physical address 0x00000000, and the EIP starts from OxOOBOOOOO; The base address starts from the physical address 0x00000000. When the memory is read or written by EAX, EBX, etc., the physical address actually accessed is equal to the EAX/EBX... value. According to the set segment descriptor, theoretically all 4G memory address space can be read and written, but considering the actual hardware configuration and the security of other code and data in the memory, the area used by the automatic test system is 0x100000 to 0x800000 and 0xa00000. The above areas do not overlap with other device address spaces. The test code structure specification is as follows:

The test code should start with a text segment and should indicate a 32-bit command mode with an offset of 0, ie the opening portion should be shaped like this:

.text

.code32

.org 0 At the end of the test process and at the end, if there is result data that needs to be saved, it can be saved in the 1KB memory area starting with OxAOOOOO. When the test file is tested, the test script saves the part of the data to the result file.

After the test is finished, the test script is completed for notification, and should be redirected to a fixed address.

OxFOOOOO o As a reference, you can jump as follows:

Movl %0xf00000, %eax

Jmp *%eax In summary, the overall template for the test code can be expressed as follows: .text

.code32

.org 0

// Content of test code, you may save some data to memory start from

II 0xa00000(size 1KB)

// End of test, notify the script

Movl %0xf00000, %eax

Jmp *%eax For the test object file generation scheme, the test assembly code is compiled and linked with binutils' gas and Id, and objcopy is used to convert the elf format executable file into a binary file that can be executed directly from the file start address. When assembling with gas, the recommended parameter is "--32". When linking with Id, it is recommended to use the reference link script link.lds given below. The parameter is recommended: "-melf_i386 -T link.lds" . Specific examples of link.lds are as follows:

//link.lds:

OUTPUT_FORMAT("elB2-i386")

OUTPUT— ARCH(i386)

PHDRS text PT- LOAD;

Data PT — LOAD;

bssPT- LOAD;

stackPT LOAD; bootPT— LOAD AT (OxfffffOOO);

SECTIONS

. = SIZEOF— HEADERS;

.reset OxfffffOOO: {* (bootstrap)}: boot

.text OxOObOOOOO: {*.o(.text)}: text

• bss: {*.o(.bss)}: bss

.data OxOOblOOOO: {*.o(.data)}: data

.stack 0x800000: {*.o(statck)}: stack

/DISCARD/: {*(.note.GNU-stack .comment .note)}

Convert the binary file with objcopy, using the command parameter "-0 binary". To simplify the compilation process, it is recommended to use a Makefile. A Makefile script for reference is given below.

# Makefile:

OBJ = generic— 0 l .o

SRC = generic— 01. s all: a.bin

$(OBJ): $(SRC) Makefile

As -32 -o $@ $< a.out: $(OBJ) Makefile link.lds Id -melf— i386 -T link.lds $(OBJ) -o $ a.bin: a. out

Objcopy -O binary a. out a.bin clean:

Rm -f a. out a.bin $(OBJ)

After the test is over, the way the test results are expressed can be selected according to the specific needs of the test program. The representation of the test results can be implemented in a variety of ways. The following examples illustrate some basic results representation methods.

Method 1: Whether to execute the end

This type of test only needs to check if the test program is finished normally. In the test of some hardware modules, it may not be necessary to generate the result data. As long as the test program can be executed normally, it can prove that the test target hardware module works normally.

During this type of testing, it is necessary to judge the execution status of the test file to effectively detect the abnormal state during the running of the program. The main abnormal states include:

1. The program "runs away", the EIP or CS value is illegal and cannot be executed;

2, the program is in an infinite loop;

3. The program is caught in a blocking I/O or interrupt process, and cannot be recovered due to a defect in the hardware module;

4. The program cannot be executed due to some illegal instructions.

Method 2: Whether the execution is successful

At the end of this type of test, the test program judges whether the successful completion according to the test process, and changes the data of a specific address in the memory to 1 or 0 according to the success or failure of the test, where 1 means the test succeeds, and vice versa means the test fails. After the test of the file is completed, the automatic test system will read the value of the memory address and judge whether the test file is successfully executed according to the value.

In addition, in order to ensure the end of the normal execution of the test file, this test also needs to use the above test text. Piece execution status detection. An abnormal state also indicates that the test failed.

Method 3: Save the test results

This type of test saves the data stored in a specific location in memory at the end of the test program as a result file. In the test of some hardware modules, the result of the test success or failure cannot be clearly obtained. Instead, the working state of the hardware module needs to be analyzed and evaluated according to the result data generated by the test. This type of test can meet the testing needs of such hardware modules.

Similarly, such tests also require support for the test system to perform abnormal state judgment mechanisms.

Method 4: Compare test results

In such tests, the test system compares the results of the actual test with the reference results provided by the test program to determine whether the test results are correct or reasonable.

The reference result data can be provided in two ways: One is to directly provide the reference data file form, and after the program finishes running, the running result data file needs to be compared with the reference file to draw conclusions; the other can be passed in the assembly file. Define a special data area, store the reference data, and automatically compare the result data with the reference data through the memory comparison function of the FS2 debugger after the end of the operation to obtain the comparison result.

The above is only the embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention. All modifications, equivalents, improvements, etc., made within the spirit and scope of the invention are intended to be included within the scope of the appended claims.

Industrial Applicability The automatic test system and automatic test method of the present invention utilizes the support of a hardware debugger (such as FS2) to implement a universal automatic test system by defining a unified test execution specification, and supports automatic execution of test modules of different hardware module units. , and can analyze and judge the test results and statistics.

Claims

Claim

1. An automatic test system for hardware device functions, including a field programmable gate array (FPGA) test target platform as a test platform for a tested hardware device, and also includes:

The FPGA bit file management and programming subsystem is connected to the FPGA test target platform through the FPGA interface, and is set to: manage the bit file required by the hardware device function module running on the FPGA test target platform; pass the FPGA interface when preparing for testing Writing to the FPGA target platform a bit file corresponding to the currently tested hardware device function module;

The automatic test system platform is connected to the FPGA test target platform through a hardware debugger, and is set to: provide test control on the test target platform, save the automatic test script file and test case set required for automatic test, and use the automatic test in the test. The script completes the automated test process, completes the functional test through the test case set, and is used to save the test results.

2. The automatic test system according to claim 1, wherein the BIOS file provided by the BIOS file management and burning subsystem to the BIOS emulator comprises:

The segment descriptors of the data segments DS, ES, FS and the stack segment SS are both 0x00000000. When the segment register corresponding to the segment descriptor is read and written in memory, the physical address actually read and written is equal to the value of the logical address used.

3. The automatic test system according to claim 1, wherein the test code structure of the test case file saved by the automatic test system platform includes:

4. The automatic test system according to claim 1, wherein the automatic test system platform expresses the test result after the test is completed, including one of the following methods: whether the execution ends, whether the execution is successful, saves the test result, and compares Test Results.

5. The automatic test system according to claim 1, wherein the automatic test script file of the automatic test system platform includes absolute path information for saving a folder in which the test script file is located.

6. A test method for an automatic test system for hardware device functions according to claim 1, comprising:

The global test initialization step initializes the automatic test system platform, sets the breakpoint information required for the test run, counts the test case file set, obtains a list of test files, and performs the following two steps for each test case file in the list:

Single file test preparation step, reset field programmable gate array (FPGA) test target platform, perform basic input/output system (BIOS) initialization, load test case file of current test into FPGA test target platform memory, enter After the protection mode, set the test program to terminate the address breakpoint;

7. The method according to claim 6, wherein the test code structure of the test case file includes: Start with a text segment, indicate the 32-bit command mode, and begin with an offset of 0;

A memory area used to save result data during the test process and at the end;

8. The method according to claim 6, wherein, in the initializing the BIOS, the method includes: configuring a loop waiting for a corresponding infinite loop address after the initialization process and before starting the test execution; configuring to skip the infinite loop After the infinite loop corresponding to the address, the BIOS initializes the segment descriptor used by the test environment, and the corresponding protection mode, and finally jumps to address 0x0:0x0 to enter the protection mode;

Data segment DS, ES, FS, and stack segment SS segment descriptor base address is 0x00000000. When the segment address register corresponding to the segment descriptor is read or written in memory, the actual physical address read and write is equal to the logical address value used.

9. The method according to claim 6, wherein the automatic test system platform expresses the test result in one of the following ways: whether the execution ends, whether the execution is successful, the test result is saved, and the test result is compared.

10. The method according to claim 6, wherein the global test initialization step further comprises: adding the absolute path information of the folder where the test script file is located to the automatic test script file of the automatic test system platform.