CN107329889B - A method of automatic testing of C compiler - Google Patents
A method of automatic testing of C compiler Download PDFInfo
- Publication number
- CN107329889B CN107329889B CN201710412800.8A CN201710412800A CN107329889B CN 107329889 B CN107329889 B CN 107329889B CN 201710412800 A CN201710412800 A CN 201710412800A CN 107329889 B CN107329889 B CN 107329889B
- Authority
- CN
- China
- Prior art keywords
- file
- compiler
- chip
- test
- breakpoints
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000012360 testing method Methods 0.000 title claims abstract description 73
- 238000000034 method Methods 0.000 title claims abstract description 29
- 238000004088 simulation Methods 0.000 claims abstract description 24
- 230000004044 response Effects 0.000 claims description 7
- 230000008569 process Effects 0.000 claims description 6
- 238000012545 processing Methods 0.000 claims description 3
- 230000000712 assembly Effects 0.000 claims 1
- 238000000429 assembly Methods 0.000 claims 1
- 238000006243 chemical reaction Methods 0.000 claims 1
- 238000011161 development Methods 0.000 abstract description 8
- 238000010586 diagram Methods 0.000 description 3
- 230000007547 defect Effects 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 238000004422 calculation algorithm Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000005094 computer simulation Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Prevention of errors by analysis, debugging or testing of software
- G06F11/3668—Testing of software
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Prevention of errors by analysis, debugging or testing of software
- G06F11/3668—Testing of software
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Prevention of errors by analysis, debugging or testing of software
- G06F11/3698—Environments for analysis, debugging or testing of software
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明公开了一种C编译器自动化测试的方法，该方法在C源文件中嵌入汇编，通过C编译器、汇编器、链接器编译得到的HEX文件后，结合下位机硬件仿真器来验证预期的结果，从而达到验证CSCC编译器的目的。本发明实现C编译器快速自动化测试，同时结合整个IDE的开发环境，也间接测试了整个C编译器工具链的正确性，解决C编译器手动编译、进入仿真设置繁琐的、操作速度慢等问题。
The invention discloses a method for automatic testing of a C compiler. The method embeds an assembly in a C source file, and after compiling a HEX file obtained by a C compiler, an assembler and a linker, combines with a hardware emulator of a lower computer to verify expectations , so as to achieve the purpose of verifying the CSCC compiler. The invention realizes the fast automatic test of the C compiler, and at the same time combines the development environment of the entire IDE, and indirectly tests the correctness of the entire C compiler tool chain, and solves the problems of manual compilation of the C compiler, complicated settings for entering the simulation, and slow operation speed. .
Description
Technical Field
The invention belongs to the technical field of C compilers, and particularly relates to a method for quickly and automatically testing a chip C compiler.
Background
An Integrated Development Environment (IDE Integrated Development Environment) of a chip plays an important role as a platform for manufacturers to develop the chip, IDE software generally comprises a C compiler and an assembler, along with the rapid demand of the chip market, the Development efficiency of the traditional assembler is difficult to meet, and the C compiler plays a key role in the embedded field nowadays. In the process of developing the C compiler by the chip manufacturer, a problem is involved in how to verify the correctness of the C compiler and the related tool chain (C compiler, assembler, linker).
When the compiler test mode comprises a traditional compiler test mode and a Ctcgen tool test mode, the traditional compiler test mode: according to the grammar, a test program generator is designed, and then the test cases are compiled by a compiler to be tested, and expected test results are contained in the test program, so that the comparison of the test results can be carried out, but the defects are all defects in the aspect of deep test.
Disclosure of Invention
Based on this, the first objective of the present invention is to provide a method for automated testing of a C compiler, which solves the problems of tedious manual testing and slow speed of the C compiler.
Another objective of the present invention is to provide a method for automated testing of C compiler, which realizes rapid automated testing of C compiler, and combines the development environment of the entire IDE to indirectly test the correctness of the tool chain of the entire C compiler, and can liberate testers and reduce the work intensity.
In order to achieve the purpose, the technical scheme of the invention is as follows:
a method for automatically testing a C compiler is characterized in that assembly is embedded in a C source file, an HEX file is obtained by compiling a CSCC (C compiler), a CSASM (assembler) and a CSLINK (linker), and an expected result is verified by combining a lower computer hardware simulator, so that the aim of verifying the CSCC compiler is fulfilled.
The method comprises the following specific steps:
101. clicking a batch processing file to run;
102. creating a log folder and a log file of the test;
103. reading an initial configuration file init.xml, and obtaining the configurations of a test case folder of a C project to be tested, a path of a C compiler and the like;
104. reading a C project file list with a suffix name of csuprj of a test case folder;
105. calling a ProjectParser.dll module, analyzing the C engineering file, and acquiring configuration parameters in the C engineering file; the parameters mainly comprise a source file name, a chip model, a source file and the like;
106. generating a makefile according to the configuration parameters, wherein the makefile is mainly called by make.exe;
107. generating a script.lik file according to the configuration parameters, wherein the file is mainly called by a CSLinker;
108. exe, namely constructing and compiling the C engineering file;
109. judging whether the compiling is correct or not, and determining the existence of a hex machine code file;
110. downloading an rbf file according to the model of the chip, and reconstructing a simulation model of the chip;
111. calling RunTest.exe, and checking the running result of the lower computer;
112. saving the result of the printing operation;
113. and (5) looping back to the step 105 until all test cases are run.
The specific flow of the simulation model for reconstructing the chip is as follows:
201. the PC sends a connection command;
202. the FPGA receives and analyzes the command;
203. PC waits for response;
204. loading a chip RBF simulation time sequence file;
205. waiting for the response of the FPGA;
206. judging whether the time sequence file is sent completely;
207. and finishing the reconstruction of the chip simulation model.
The test operation flow comprises the following steps:
301. entering simulation;
302. break points are set at 0x002 and 0x003 of a PC (program counter);
303. executing full-speed operation;
304. reading the stopped PC;
305. judging whether the test case is correct or incorrect according to the writing method of the previous test case;
306. storing the result into a log file;
307. and (6) exiting.
The automatic testing method realizes the quick automatic testing of the C compiler, simultaneously combines the development environment of the whole IDE, indirectly tests the correctness of the tool chain of the whole C compiler, and solves the problems of complicated manual compiling, entering simulation setting, low operation speed and the like of the C compiler. Thereby greatly freeing the tester and reducing the working strength.
Drawings
FIG. 1 is a flow diagram of a C compiler automated compilation operation as implemented by the present invention.
FIG. 2 is a block diagram of an upper and lower computer in which the present invention is implemented.
FIG. 3 is a flow chart of a simulation model of a reconstruction chip implemented in the present invention.
FIG. 4 is a flow chart of the results of running test compilation as practiced by the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
The test scheme implemented by the invention needs a reference compiler, preferably a PICC compiler of Microchip company, but the difference exists between the running library (PICC RunTime Lib) called by the PICC compiler and the running library (CSCC RunTime Lib) of Chihai, so that the generated object code has indeterminate difference. The current feasible technical scheme is as follows: according to the characteristics of the kernel of the chip, assembly is embedded in a C source file, an HEX file is obtained by compiling through a CSCC (C compiler), a CSASM (assembler) and a CSLINK (linker), and an expected result is verified by combining a lower computer hardware simulator, so that the aim of verifying the CSCC compiler is fulfilled.
A platform is provided for the C compiler to implement the rapid automated testing of the C compiler, as shown in fig. 1, the specific steps are described as follows:
s101, clicking a batch processing file to start running;
the file is a batch file with the suffix of bat, and is mainly used for facilitating one-key test of testers and improving the working efficiency.
S102, creating a log folder and a log file of the test;
folders and log files are created using the time of Python, log module, named according to the time of each click. And recording the operation result of the platform in the log file in the whole process. Meanwhile, the information printed by the console window is recorded, so that errors in the test process can be conveniently searched.
S103, reading an initial configuration file init.xml, and acquiring the configurations of a test case folder of the C project to be tested, a path of a C compiler and the like;
after the tester writes all the test cases, the tester places the test cases in an environment position of a specified position, such as a certain path of an IDE (integrated development environment) according to the compiler exe provided by a developer of the C compiler, and the tester can configure the path of the C engineering file set and the path of the C compiler to test the C compiler of the current version.
S104, reading a C project file list with a test case folder suffix name of csuprj;
the C project file can be placed in any place of the folder, the Python algorithm can search all the C project files under the folder, the file paths are stored in a Python list, and each C project test case can be tested circularly through the list.
S105, calling a ProjectParser.dll module, analyzing the C engineering file, and acquiring configuration parameters in the C engineering file; the parameters mainly comprise a source file name, a chip model, a source file and the like;
the Python script analyzes the C engineering file by calling a ProjectParser. dll module, the format of the engineering file is similar to an xml file, and the main acquired parameters are as follows: output folders, project file paths, project file names, chip families, chip models, C compiler options, assembler options, linker options, code options, assembly file lists, and the like. This information is necessary to generate the makefile and script.
S106, generating a makefile according to the configuration parameters, wherein the makefile is mainly called by make.
The standard IDE has makefile files, and a compiler, an assembler and a linker are called by make.
S107, generating a script file according to the configuration parameters, wherein the file is mainly called by a CSLinker;
s108, executing make.exe, which is equivalent to the construction and compiling of the C engineering file;
s109, judging whether the compiling is correct or not, and determining the existence of the hex machine code file;
s110, downloading an rbf file according to the model of the chip, and reconstructing a simulation model of the chip;
this step is mainly prepared for testing hex machine code, and the significance of reconstructing the simulation model of the chip is that when the tested C project contains different chip models, it is not feasible for automated testing if manual switching is required if the actual chip is used. The simulation model of the reconstructed chip is described in detail in the second section.
S111, calling RunTest.exe, and checking the running result of the lower computer;
s112, saving the result of the printing operation
And S113, circularly returning to the step S105 until all the test cases are operated.
And reconstructing the simulation model of the chip, wherein after the automatic compilation of the project is finished, the PC and the FPGA realize communication through a USB according to the chip type parameters provided by the C project file, and the time sequence file of the RBF simulation model of the chip is sent to a lower computer simulation board to realize the reconstruction of the simulation model of the chip. The block diagram of the PC and the FPGA is shown in FIG. 2, and a specific flow chart of the module is shown in FIG. 3. The specific process comprises the following steps:
s201, the PC sends a connection command;
s202, receiving and analyzing a command by the FPGA;
s203, the PC waits for response;
s204, loading a chip RBF simulation time sequence file;
s205, waiting for the response of the FPGA;
s206, judging whether the time sequence file is sent completely;
s207, reconstructing the chip simulation model;
and S208, printing result information.
As shown in fig. 4, the result of the test operation is that after the compiling is completed and the chip simulation model is reconstructed, the hardware of the lower computer is communicated:
s301, entering simulation;
firstly, sending a connection establishing instruction (PSFSD) to an FPGA by a PC end; the version number of the FPGA is given back to the PC; if the FPGA end reads correct data, a response instruction (FSPDACK) is sent back, if the instruction is found to be read wrongly, an error information receiving instruction (FSPERR) is sent back, the PC end resends the connection instruction to the FPGA, and if the instruction is still wrong, a user is prompted to have a problem in connection.
S302, setting breakpoints at 0x002 and 0x003 of the PC;
and the PC sends a breakpoint information instruction PSFB to the FPGA. The breakpoint command sent by the PC includes 16bytes of data, which respectively correspond to 6 breakpoints and 2 macro breakpoints, and each breakpoint data includes 2 bytes. The first 12 data correspond to 6 breakpoints, the last 4 data correspond to 2 macro breakpoints, and the high byte is in front, and debugging breakpoints are set at addresses 0x002 and 0x003 according to the protocol.
S303, executing full-speed operation;
the running program has two modes, Freun and run. The difference between these two modes is that a run mode is selected because a break point encountered in a Free run will not stop, and a run will stop when a break point is encountered, where the break point is to be stopped. When the situation is met, a timer is set in a running thread, and when the time of the thread exceeds the timed time, the thread is forced to stop running and return an error code.
S304, reading the stopped PC;
after receiving the trace debugging instruction PSFTRACE, the FPGA sends a data return instruction FSPRB to the PC and returns SFR and RAM data. The PC end receives the instruction and the data, and after the verification result is correct, if more RAM data need to be read, the PSFCACK instruction is returned, and the data continues to be received; if no more data needs to be read, a PSFEACK instruction is returned indicating that no error is received. The return PC (program counter) can be obtained by parsing the packet.
S305, judging whether the test case is correct or incorrect according to the previous compiling method of the test case;
setting a condition for judging normal operation of a program in each C file test case, wherein according to the characteristics of an 8-bit singlechip chip, general users of 002H and 003H addresses of a PC of the program cannot access the program, and embedding the following assembly statements in the C program as judgment:
if (a ═ b) { asm ("goto 003H"); // if successful, PC points to 003
Else { asm ("goto 002H"); // if wrong, PC points to 002
}
Breakpoints are set at test case PC-0 x02 and PC-0 x 03. If the test point of the peripheral test passes after the test case runs, the PC is stopped at 0x03 by call PASSED, and if the test point passes, the PC is stopped at 0x02 by call FAILED, and then the test result is output.
S306, storing the result into a log file;
according to the prior process of automated compiling test of the C compiler, one step is a logging module of logger, python determines the correctness of operation by calling a module of Runtest. exe and the return value of exe, thereby achieving the verification of the operation result.
And S307, exiting.
The automatic testing method realizes the quick automatic testing of the C compiler, simultaneously combines the development environment of the whole IDE, indirectly tests the correctness of the tool chain of the whole C compiler, and solves the problems of complicated manual compiling, entering simulation setting, low operation speed and the like of the C compiler. Thereby greatly freeing the tester and reducing the working strength.
The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents and improvements made within the spirit and principle of the present invention are intended to be included within the scope of the present invention.
Claims (9)
1. A method for automatically testing a C compiler is characterized in that the method embeds assemblies in C source files, and verifies an expected result by combining a lower computer hardware simulator after HEX files are compiled by CSCC, CSASM and CSLINK, thereby achieving the aim of verifying the CSCC compiler; the method comprises the following specific steps:
101. clicking a batch processing file to run;
102. creating a log folder and a log file of the test;
103. reading an initial configuration file init.xml, and obtaining the configurations of a test case folder of a C project to be tested, a path of a C compiler and the like;
104. reading a C project file list with a suffix name of csuprj of a test case folder;
105. calling a ProjectParser.dll module, analyzing the C engineering file, and acquiring configuration parameters in the C engineering file; the parameters mainly comprise a source file name, a chip model and a source file;
106. generating a makefile according to the configuration parameters, wherein the makefile is called by make.
107. Generating a script.lik file according to the configuration parameters, wherein the file is called by a CSLinker;
108. exe, namely constructing and compiling the C engineering file;
109. judging whether the compiling is correct or not, and determining the existence of a hex machine code file;
110. downloading an rbf file according to the model of the chip, and reconstructing a simulation model of the chip;
111. calling RunTest.exe, and checking the running result of the lower computer;
112. saving the result of the printing operation;
113. and (5) looping back to the step 105 until all test cases are run.
2. The method for automated testing of a C compiler according to claim 1, wherein the specific process for reconstructing the simulation model of the chip is:
201. the PC sends a connection command;
202. the FPGA receives and analyzes the command;
203. PC waits for response;
204. loading a chip RBF simulation time sequence file;
205. waiting for the response of the FPGA;
206. judging whether the time sequence file is sent completely;
207. and finishing the reconstruction of the chip simulation model.
3. The method for automated testing of C compiler according to claim 2, wherein the flow of the test run is:
301. entering simulation;
302. setting breakpoints at 0x002 and 0x003 of the program counter;
303. executing full-speed operation;
304. reading the program counter after stopping;
305. judging whether the test case is correct or incorrect according to the writing method of the previous test case;
306. storing the result into a log file;
307. and (6) exiting.
4. The method for C compiler automation testing according to claim 1 where in step 102 folders and log files are created using time of Python, log module, named according to time per click.
5. The method according to claim 1, wherein in step 105, the Python script analyzes the C engineering file by calling the project server. Output folder, project file path, project file name, chip family, chip model, C compiler option, assembler option, linker option, code option, assembly file list.
6. The method of claim 1, wherein in step 106, the conversion of the plurality of source files into a hex file is performed by making.
7. The method for automated testing of C compiler according to claim 3, wherein in step 302, the breakpoint command sent by the PC includes 16bytes of data, which respectively corresponds to 6 breakpoints and 2 macro breakpoints, each breakpoint data includes 2 bytes; the first 12 data correspond to 6 breakpoints, the last 4 data correspond to 2 macro breakpoints, the high byte is in front, and debugging breakpoints are set at addresses 0x002 and 0x003 according to a protocol.
8. The method for automated testing of C-compiler according to claim 3, wherein in step 303, run program selects run mode.
9. The method for automated testing of C compiler according to claim 3, wherein in step 305, the following assembly statement is embedded in the C program as the judgment.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710412800.8A CN107329889B (en) | 2017-06-05 | 2017-06-05 | A method of automatic testing of C compiler |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710412800.8A CN107329889B (en) | 2017-06-05 | 2017-06-05 | A method of automatic testing of C compiler |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107329889A CN107329889A (en) | 2017-11-07 |
| CN107329889B true CN107329889B (en) | 2021-01-19 |
Family
ID=60194540
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710412800.8A Active CN107329889B (en) | 2017-06-05 | 2017-06-05 | A method of automatic testing of C compiler |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107329889B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107783873B (en) * | 2017-11-23 | 2021-08-06 | 芯海科技（深圳）股份有限公司 | Method for realizing automatic testing platform of burner |
| CN114816880B (en) * | 2018-05-24 | 2025-01-10 | 上海微小卫星工程中心 | Verification and Testing Methods for Reconfigurable FPGA Software |
| CN111124880B (en) * | 2019-11-04 | 2021-08-17 | 北京大学 | Method and system for generating compiler test input based on historical data |
| CN112444731B (en) * | 2020-10-30 | 2023-04-11 | 海光信息技术股份有限公司 | Chip testing method and device, processor chip and server |
| CN113203935B (en) * | 2021-03-11 | 2024-06-28 | 江西创成微电子有限公司 | Chip testing method, system and readable storage medium |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6389379B1 (en) * | 1997-05-02 | 2002-05-14 | Axis Systems, Inc. | Converification system and method |
| US7480606B2 (en) * | 1998-08-31 | 2009-01-20 | Versity Design, Inc. | VCD-on-demand system and method |
| CN104077170A (en) * | 2013-03-27 | 2014-10-01 | 株式会社特博睿 | Psm compiler optimizer and method for processing bulk dml |
| CN104965750A (en) * | 2015-06-05 | 2015-10-07 | 浪潮集团有限公司 | Python language based Rapidio switcher logic simulation verification platform and method |
| CN105630677A (en) * | 2015-12-22 | 2016-06-01 | 深圳市东微智能科技有限公司 | Device debugging method |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7519951B2 (en) * | 2003-09-30 | 2009-04-14 | International Business Machines Corporation | Multi-attribute dynamic link library packaging |
| CN100492387C (en) * | 2007-04-10 | 2009-05-27 | 北京飞天诚信科技有限公司 | Method and system for software protected development based on Keil C51 |
| CN105023241A (en) * | 2015-07-29 | 2015-11-04 | 华南理工大学 | Fast image interpolation method for mobile terminal |
-
2017
- 2017-06-05 CN CN201710412800.8A patent/CN107329889B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6389379B1 (en) * | 1997-05-02 | 2002-05-14 | Axis Systems, Inc. | Converification system and method |
| US7480606B2 (en) * | 1998-08-31 | 2009-01-20 | Versity Design, Inc. | VCD-on-demand system and method |
| CN104077170A (en) * | 2013-03-27 | 2014-10-01 | 株式会社特博睿 | Psm compiler optimizer and method for processing bulk dml |
| CN104965750A (en) * | 2015-06-05 | 2015-10-07 | 浪潮集团有限公司 | Python language based Rapidio switcher logic simulation verification platform and method |
| CN105630677A (en) * | 2015-12-22 | 2016-06-01 | 深圳市东微智能科技有限公司 | Device debugging method |
Non-Patent Citations (1)
| Title |
|---|
| "编译软件 Hex文件烧写";zero99;《https://www.stmcu.org.cn/module/forum/thread-611348-1-1.html》;20170405;第1-5页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107329889A (en) | 2017-11-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107329889B (en) | A method of automatic testing of C compiler | |
| US8924937B1 (en) | Method and system for generating verification information and tests for software | |
| CN109189479B (en) | Parallel automatic verification method for processor instruction set | |
| CN107783873B (en) | Method for realizing automatic testing platform of burner | |
| CN102346235A (en) | Automatic test system and method for hardware device function | |
| CN109101680B (en) | FPGA prototype automatic verification method and system based on GitLab-CI | |
| US10049031B2 (en) | Correlation of violating change sets in regression testing of computer software | |
| RU2010114709A (en) | METHOD FOR AUTOMATIC GENERATION SCENARIO FOR CHECKING THE CORRECTNESS OF THE FUNCTIONAL SOFTWARE OF THE SYSTEM INSTALLED ON THE BOARD OF THE AIRCRAFT AND THE DEVICE FOR APPLICATION OF THE METHOD | |
| US10592703B1 (en) | Method and system for processing verification tests for testing a design under test | |
| CN109614107B (en) | Integration method and device of software development kit | |
| CN110688313B (en) | Fault injection method for software testing under VxWorks operating system | |
| JP6142705B2 (en) | Iterative generation of symbolic test drivers for object-oriented languages | |
| US9158665B2 (en) | Unit test of multi-threaded object-oriented applications using mocks | |
| Yang et al. | Specification-based test repair using a lightweight formal method | |
| Bonfiglio et al. | Software faults emulation at model-level: Towards automated software fmea | |
| CN114281709A (en) | A unit testing method, system, electronic device and storage medium | |
| CN114661615A (en) | FPGA software testing method and device | |
| JP2013218492A (en) | Software test automatic evaluation device and method | |
| CN110955605A (en) | Method for verifying single step dynamic execution by CPU | |
| US10579761B1 (en) | Method and system for reconstructing a graph presentation of a previously executed verification test | |
| CN115034165A (en) | Chip simulation verification method, system, equipment and storage medium | |
| JP4957521B2 (en) | Software partial test system, method and program used therefor | |
| CN115168131A (en) | Fault injection CPU abnormal function verification method | |
| KR100777103B1 (en) | Test Driver Generation Device and Method | |
| Halabi et al. | Mutation testing tools for Java programs–a survey |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |