JP2008077278A - Test simulator - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide technology for improving reliability of a product by efficiently performing a test by automatic generation/execution of test conditions obtained in combination of conditions of software and conditions of hardware to improve a covering rate of the test. <P>SOLUTION: This test simulator has: a storage device simulator 7 executing the test on each the condition of a software condition table; an LSI access table creation part 6 creating an LSI access table from LSI access information output in the execution; a hardware/software condition generation part 4 generating a hardware/software condition table from the created LSI access table, a hardware fault table, the software condition table, and the kind of a fault; and a test execution part 5 executing the test under each the condition of the generated hardware/software condition table. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a test simulator technique, and more particularly to a technique effective when applied to a test coverage simulator for embedded software development of a storage apparatus.

  For example, regarding the technique of the test simulator, the techniques described in Patent Document 1 and Patent Document 2 can be cited.

  Patent Document 1 provides a means for extracting all processes related to data to be tested and patterns in execution conditions from a test target program, and combining the extracted processes and execution conditions. In consideration of the above, a technique for automatically generating test conditions is disclosed.

Patent Document 2 provides a means for reading out a memory address of a failure occurrence condition from a failure information file and simulating an interrupt operation according to an interrupt type which is a failure content of the same memory address as this memory address. A technique for simulating a hardware failure by specifying a memory address that causes a failure is disclosed.
Japanese Patent Laid-Open No. 11-15695 JP 05-81076 A

  By the way, regarding the test simulator technology as described above, for example, in the technology of Patent Document 1, test conditions are automatically generated in consideration of only test conditions in software. In this case, there is a failure in hardware. There are no conditions for what happens.

  In Patent Document 2, a hardware failure is simulated by designating a memory address that causes a hardware failure. In this case, the timing at which the failure occurs cannot be designated.

  Also, in the test simulator technology, embedded software as the subject of the present invention is closely related to hardware, and it covers not only software conditions but also operations when a failure occurs in hardware. is required.

  Conventional tests are performed using actual machines and simulators based on actual machine specifications, and the test conditions are created by the developer. However, the types of failures that occur in hardware are enormous, and the tests cover the software conditions. May not be sufficient, leaving bugs.

  Therefore, an object of the present invention is to efficiently perform testing by automatically generating and executing test conditions that match software conditions and hardware conditions, to improve the coverage of tests, and to improve product reliability. It is to provide the technology that can.

  Of the inventions disclosed in the present application, the outline of typical ones will be briefly described as follows. In other words, the present invention automatically generates a test condition that combines a hardware failure condition and a software condition, and performs a test without any leakage efficiently by performing from the test execution to the output of the result, It is intended to improve product quality.

  Specifically, a storage device simulator that executes a test of each condition in the software condition table, an LSI access table creation unit that creates an LSI access table from the LSI access information output at the time of execution, and the created LSI access Table, hardware fault table and software condition table, hardware / software condition generation unit that generates hardware / software condition table from failure type, and test in each condition of the generated hardware / software condition table And a test execution unit for executing.

  Of the inventions disclosed in the present application, effects obtained by typical ones will be briefly described as follows. In other words, according to the present invention, by automatically generating and executing test conditions that combine software conditions and hardware conditions, efficient testing is performed, test coverage is improved, and product reliability is increased. Can do.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. Note that components having the same function are denoted by the same reference symbols throughout the drawings for describing the embodiment, and the repetitive description thereof will be omitted.

  First, an example of the configuration and operation of a test simulator in one embodiment of the present invention will be described with reference to FIG. FIG. 1 is a block diagram illustrating an example of the configuration and operation of a test simulator.

  The test simulator according to the present embodiment includes a computer system having a CPU, a memory, a database, and the like, and each functional block is realized by executing each program stored in the memory under the control of the CPU.

  Each function block includes a function-specific source selection tool 1 that extracts a source necessary for a test based on a function specified from the function-specific source table, a compiler 2 that compiles the source to generate a test target program, and an extraction source. Software analysis test condition generation tool 3 that creates a software condition table, hardware / software condition generation unit 4 that generates a hardware / software condition table from an LSI access table, a hardware failure table, a software condition table, and a failure type, A test execution unit 5 that executes a test under each condition of the hardware / software condition table, an LSI access table creation unit 6 that creates an LSI access table from LSI access information, and a storage device simulator 7 that executes a test for each condition in the software condition table , Test variables, cash register There is a function block, such as test results display tool 8 to display the information and test results of the other log.

  The database or the memory is provided with tables such as a function-specific source table 11, a software condition table 12, an LSI access table 13, a hardware failure table 14, and a hardware / software condition table 15, which will be described in detail later. ing. The database or memory stores information such as extraction source 21, source 22, test target program 23, LSI access information 24, variable / register log information 25, variable / register log 26, and test result 27.

  Hereinafter, the operation of the test simulator of the present embodiment will be described with reference to FIG. First, prior to the operation of the test simulator, work by a hardware developer and a software developer is necessary.

  The hardware developer creates a hardware failure table 14 from the hardware specifications using a test simulator.

  The software developer creates a function-specific source table 11 using a test simulator. Further, the function is specified by the function selection source selection tool 1 of the test simulator, and the source necessary for the test is extracted. This extracted source is stored as the extraction source 21. Then, the extracted source is applied to the software analysis / test condition generation tool 3 to create a software condition table 12. At the same time, the source 22 is compiled by the compiler 2 to create a test target program 23 in an object file format.

  Further, the software developer inputs the failure type of the condition to be created to the hardware / software condition generation unit 4 of the test simulator.

  Thus, the preliminary work by the hardware developer and software developer is completed.

  Subsequently, the operation of the test simulator is as follows. The following test simulator operations are automatically performed under the control of the CPU.

  First, tests for all conditions in the software condition table 12 are executed on the storage device simulator 7. At the time of execution on the storage device simulator 7, LSI access information 24 is output. The LSI access table creation unit 6 creates an LSI access table 13 from the output LSI access information 24.

  Further, the hardware / software condition generation unit 4 generates the hardware / software condition table 15 from the hardware failure table 14, the LSI access table 13, the software condition table 12, and the failure type. Then, the test execution unit 5 executes the test under all the conditions in the hardware / software condition table 15.

  Further, in the storage apparatus simulator 7, the variables and register logs at the time of the test are registered in the variable / register log information 25. Then, the test result 27 is displayed by the test result display tool 8. Further, the variable / register log 26 is displayed by the test result display tool 8. Furthermore, the test result 27 and the variable / register log 26 can be output.

  In the operation of the test simulator as described above, it is possible to generate a test condition combining a hardware failure condition and a software condition, and automatically perform from the test execution to the result display / output. After the test, the software developer can check the test result 27 and the variable / register log 26 with the test result display tool 8.

  Next, an example of the configuration of each table will be described with reference to FIGS. 2 is a hardware failure table, FIG. 3 is a function-specific source table, FIG. 4 is a software condition table, FIG. 5 is an LSI access table, and FIG. 6 is an explanatory diagram showing an example of the configuration of the hardware / software condition table. is there.

  In FIG. 2, the hardware fault table 14 includes items of LSI name, register, fault type, fault / interrupt No., and indicates the fault type and fault interrupt No. in each register of each LSI name. For example, the register “0x55100˜” of the LSI name “LSI1” has the failure type “CHK1” and the failure interrupt number “1”, and the others are as shown in FIG.

  In FIG. 3, a function-specific source table 11 is provided with items of function name, source name, and location, and represents the location of each function name in each source name. For example, the source name “src1” of the function name “function 1” has a location “/ project / home / src”, and others are as shown in FIG.

  4, the software condition table 12 includes items of software condition No, input 1, input 2,..., Global variable 1, global variable 2,..., And represents the input and global variable in each software condition No. Yes. For example, in software condition No. “1”, input 1 is “1”, input 2 is “2”, global variable 1 is “1”, global variable 2 is “1”, and others are as shown in FIG. It is.

  In FIG. 5, the LSI access table 13 includes items of software condition No., step, LSI name, and access register, and represents the LSI name and access register in each step of each software condition No. For example, in step “15” of software condition No. “1”, the LSI name is “LSI1”, the access registers are “0x55100” and “0x56100”, and the others are as shown in FIG.

  In FIG. 6, the hardware / software condition table 15 includes items of hardware / software condition No, software condition No, step, LSI name, access register, fault / interrupt No., and each hardware / software condition No. Software condition No., step, LSI name, access register, and failure / interrupt No. in FIG. For example, the hardware / software condition No. “1” is the software condition No. “1”, the step is “15”, the LSI name is “LSI1”, the access register is “0x55100-”, and the failure / interrupt No is “1”. In the hardware / software condition No. “2”, the same software condition No., step, LSI name, access register, failure / interrupt No. is “2”, and others are as shown in FIG. It is.

  Next, an example of the operation of each functional block will be described with reference to FIGS. First, an example of the operation of the test automatic execution part centering on the test execution part will be described with reference to FIG. FIG. 7 is a flowchart showing an example of the operation of the automatic test execution part centering on the test execution part.

  In FIG. 7, the test execution unit 5 first reads the software condition table 12 (S101), selects a test condition that has not been executed from the software condition table 12 (S102), and stores it in accordance with the selected test condition. The environment of the device simulator 7 is set (S103). Further, the storage system simulator 7 tests the test target program 23 on this simulator, and outputs the LSI access information 24 to the LSI access table creation unit 6 (S104). Further, the LSI access table creation unit 6 adds the LSI access information 24 to the LSI access table 13 (S105). Then, the test execution unit 5 determines whether or not all the software conditions have been executed (S106), and if executed (Yes), the process proceeds to the next, and if not executed (No), the processes of S102 to S105 are performed. repeat.

  Subsequently, the hardware / software condition generation unit 4 creates a hardware / software condition table 15 (S107). Further, the test execution unit 5 selects a test condition that has not been executed from the hardware / software condition table 15 (S108), and sets the environment of the storage system simulator 7 in accordance with the selected test condition (S109). Further, the storage system simulator 7 tests the test target program 23 on this simulator and outputs the variable / register log information 25 (S110). Then, the test execution unit 5 determines whether or not all the hardware and software conditions have been executed (S111). If executed, the test execution unit 5 ends (Yes), and if not executed (No), S108 to S110. Repeat the process.

  As described above, the operation of the automatic test execution part centering on the test execution part 5 is performed.

  Next, an example of the operation of the LSI access table creation unit will be described with reference to FIG. FIG. 8 is a flowchart showing an example of the operation of the LSI access table creation unit.

  In FIG. 8, the LSI access table creation unit 6 first acquires the software condition No from the test execution unit 5 (S201), and also acquires the LSI access information 24 (S202). Then, the LSI access table creation unit 6 acquires the step and register address that accessed the LSI and adds them to the LSI access table 13 (S203).

  The operation of the LSI access table creation unit 6 is performed as described above.

  Next, an example of the operation of the hardware / software condition generation unit will be described with reference to FIGS. FIG. 9 is a flowchart showing an example of the operation of the hardware / software condition generation unit. 10 to 12 are explanatory diagrams illustrating an example of creation of a hardware / software condition table.

  In FIG. 9, the hardware / software condition generation unit 4 first specifies a failure type by the software developer (S301), and acquires a failure of the specified failure type from the hardware failure table 14 (S302). . Further, the hardware / software condition generation unit 4 obtains a failure that may occur in the path under one software condition of the LSI access table 13 (S303), and obtains all combinations of the troubles that occur (S303). In S304, the obtained combination is added to the hardware / software condition table 15 (S305). Then, the hardware / software condition generation unit 4 determines whether or not the checks in the paths of all conditions have been completed (S306), and if completed (Yes), terminates the process, and if not completed (Yes) No) repeats the processing of S303 to S305.

  Specifically, the creation of the hardware / software condition table 15 narrows down the hardware failure table 14 to the failure type designated by the user (software developer) as shown in FIG. In the example of FIG. 10, the failure type of the hardware failure table 14 is extracted as “CHK1”, and the LSI name and register are “0x55100” of “LSI1”, “0x56100” of “LSI1”, and “LSI2”, respectively. “0x65100” of “LSI”, “0x75100” of “LSI3”, and “0x85100” of “LSI4” are narrowed down.

  Subsequently, as shown in FIG. 11, a failure that may occur is identified using the LSI access table 13. In the example of FIG. 11, when the software condition No. of the LSI access table 13 is “1”, it is specified that interrupt Nos. “1” and “3” may occur at step “15”.

  Subsequently, as shown in FIG. 12, a condition that satisfies all combinations of interrupts generated using the hardware / software condition table 15 is created. In the example of FIG. 12, when the software condition No. in the hardware / software condition table 15 is “1”, (1) only the failure of the interrupt No “1” occurs in the register “0x55100” in step “15”. 2) Only the failure of interrupt No. “3” occurs in register “0x56100” in step “15”, (3) The failure of interrupt No. “1” occurs in register “0x55100” in step “15”, and interrupt occurs in register “0x56100” Three types of failure, “No 3”, have been created.

  As described above, the operation of the hardware / software condition generation unit 4 is performed, and the hardware / software condition table 15 is created.

  Next, an example of the configuration and operation of the storage apparatus simulator will be described with reference to FIGS. FIG. 13 is an explanatory diagram showing an example of the configuration of the storage apparatus simulator. FIG. 14 is a flowchart showing an example of the operation of the failure occurrence function part centered on the arbitrary failure occurrence part, FIG. 15 is an example of the operation of the LSI access information output part, and FIG. 16 is the variable / register log information output part.

  In FIG. 13, the storage device simulator 7 includes a test target program 71, an OS 72, a memory simulation unit 73, an LSI simulation unit 74, a CPU simulation unit 75, a variable / register log information output unit 76, and an LSI access information output unit as simulator environments. 77, an arbitrary fault occurrence unit 78, a simulation engine 79, and the like.

  In FIG. 14, first, the arbitrary failure occurrence unit 78 sets a failure (interrupt) timing from the hardware / software condition table 15 (S401), and acquires step information from the CPU simulation unit 75 (S402). Then, the arbitrary failure occurrence unit 78 determines whether or not it is a failure occurrence step (S403). If it is not a failure occurrence step (No), the LSI simulation unit 74 is requested to perform normal processing (S404). Normal processing is performed (S405). On the other hand, in the case of a failure occurrence step in S403 (Yes), a failure request is transmitted to the LSI simulation unit 74 (S406), and the LSI simulation unit 74 sends an interrupt to the CPU simulation unit 75 (S407). Then, the CPU simulation unit 75 determines whether or not the test target program has ended (S408). If it has ended (Yes), the process ends. If it has not ended (No), S402 to S407 are performed. Repeat the process.

  As described above, the operation of the failure occurrence function portion centering on the arbitrary failure occurrence portion 78 of the storage apparatus simulator 7 is performed.

  In FIG. 15, the LSI access information output unit 77 first monitors the LSI simulation unit 74 (S501), and determines whether or not the LSI simulation unit 74 is accessed (S502). If there is no access (No) as a result of this determination, the process proceeds to the determination of S505. If there is an access (Yes), the accessed LSI, register address, and step information are acquired (S503). Register and step information is output to a file (S504). Then, the LSI access information output unit 77 determines whether or not the test target program has ended (S505). If it has ended (Yes), the process ends, and if it has not ended (No), S501 to S501. The process of S504 is repeated.

  As described above, the operation of the LSI access information output unit 77 of the storage apparatus simulator 7 is performed.

  In FIG. 16, the variable / register log information output unit 76 first acquires the address of the memory to which the variable is assigned from the test target program (S601), and monitors the LSI simulation unit 74 and the memory simulation unit 73 (S602). ). Then, the variable / register log information output unit 76 determines whether or not there is a change in the register value of the LSI simulation unit 74 (S603). If there is no change (No), the process proceeds to the determination of S606. If there is (Yes), the changed LSI name, register address, register value, and step information are acquired (S604), and the acquired information is registered in the DB of the variable / register log information 25 ( S605). Further, the variable / register log information output unit 76 determines whether or not there is a change in the value of the memory to which the variable is assigned (S606). If there is no change (No), the process proceeds to the determination of S609, where the change is made. If there is (Yes), the variable name, memory value, and step information are acquired (S607), and the acquired information is registered in the DB of the variable / register log information 25 (S608). Then, the variable / register log information output unit 76 determines whether or not the test target program has ended (S609). If it has ended (Yes), the process ends, and if it has not ended (No), The processes of S603 to S608 are repeated.

  As described above, the operation of the variable / register log information output unit 76 of the storage apparatus simulator 7 is performed.

  Next, an example of the operation of the test result display tool will be described with reference to FIGS. FIG. 17 is an explanatory diagram illustrating an example of a test result display tool, and FIGS. 18 and 19 are explanatory diagrams illustrating an example of a test result reference screen.

  In FIG. 17, first, the user (software developer) designates the software condition No. and the variable / register of the result determination target on the test result display tool 8. Then, the test result display tool 8 refers to the DB of the variable / register log information 25 and displays the specified software condition No. and the test result 27 of the value of the variable / register as a result determination target. In the example of FIG. 17, the DB of the variable / register log information 25 includes a conversion table representing variable names, steps, and values, and a register table representing LSI names, addresses, steps, and values. The software / software condition No. and the value of the variable / register to be judged are “1”, “0x1234”, “2”, “0x1234”, “3”, “0x1234”, and so on. ing.

  In FIG. 18, the test result reference screen of the test result display tool 8 displays the test result determination variable / register under the conditions specified by the user (software developer), so that the software developer has a normal result. You can discover the conditions that are not. In the example of FIG. 18, the hardware / software condition No. “3” is found in the variable 1 “0” and the register 1 “0x1111”.

  Subsequently, in FIG. 19, the software developer specifies a condition (hardware condition “3”) in which an abnormal result is obtained, and further specifies variables and registers necessary for specifying the cause. The status change history can be displayed on the test result reference screen. In the example of FIG. 19, “10”, “15”, “20”, and “25” are displayed as the steps. As the cause of the software, variable “1” is set at step “20”, and register 1 is set at step “25”. “0x1111” is displayed. Further, as a cause of hardware, failure No. “1” is displayed at step “15”.

  As described above, the test result display tool 8 is operated, and the test result 27 is displayed on the test result reference screen.

  Therefore, according to the test simulator of the present embodiment, the function-specific source selection tool 1, the compiler 2, the software analysis test condition generation tool 3, the hardware / software condition generation unit 4, the test execution unit 5, and the LSI access table creation unit 6. By providing the storage device simulator 7, the test result display tool 8, and the like, test conditions combining hardware fault conditions and software conditions are automatically generated, and the process from test execution to result output is performed. Thus, the test can be performed efficiently, the coverage rate of the test can be improved, and the reliability of the product can be improved. In addition, since the abnormal test that has been conventionally performed by the system test can be performed by the combination test, the return work can be reduced.

  As mentioned above, the invention made by the present inventor has been specifically described based on the embodiment. However, the present invention is not limited to the embodiment, and various modifications can be made without departing from the scope of the invention. Needless to say.

  The present invention relates to a test simulator technique, and in particular, can be used as a test coverage simulator for developing embedded software in a storage apparatus.

It is a block diagram which shows an example of a structure and operation | movement of a test simulator in one embodiment of this invention. It is explanatory drawing which shows an example of a structure of a hardware failure table | surface in the test simulator in one embodiment of this invention. It is explanatory drawing which shows an example of a structure of the function-specific source table in the test simulator in one embodiment of this invention. It is explanatory drawing which shows an example of a structure of a software condition table | surface in the test simulator in one embodiment of this invention. It is explanatory drawing which shows an example of a structure of an LSI access table in the test simulator in one embodiment of this invention. It is explanatory drawing which shows an example of a structure of a hardware / software condition table | surface in the test simulator in one embodiment of this invention. It is a flowchart which shows an example of operation | movement of the test automatic execution part centering on a test execution part in the test simulator in one embodiment of this invention. It is a flowchart which shows an example of operation | movement of a LSI access table preparation part in the test simulator in one embodiment of this invention. It is a flowchart which shows an example of operation | movement of a hardware / software condition production | generation part in the test simulator in one embodiment of this invention. It is explanatory drawing which shows an example of preparation of a hardware / software condition table | surface in the test simulator in one embodiment of this invention. It is explanatory drawing which shows an example of preparation of a hardware / software condition table (following FIG. 10) in the test simulator in one embodiment of this invention. It is explanatory drawing which shows an example of creation of a hardware / software condition table (following FIG. 11) in the test simulator in one embodiment of this invention. It is explanatory drawing which shows an example of a structure of a storage apparatus simulator in the test simulator in one embodiment of this invention. It is a flowchart which shows an example of operation | movement of the failure generation function part centering on the arbitrary failure generation part of a storage apparatus simulator in the test simulator in one embodiment of this invention. It is a flowchart which shows an example of operation | movement of the LSI access information output part of a storage apparatus simulator in the test simulator in one embodiment of this invention. It is a flowchart which shows an example of operation | movement of the variable and register log information output part of a storage apparatus simulator in the test simulator in one embodiment of this invention. It is explanatory drawing which shows an example of the test result of a test result display tool in the test simulator in one embodiment of this invention. It is explanatory drawing which shows an example of the test result reference screen (test result) of a test result display tool in the test simulator in one embodiment of this invention. It is explanatory drawing which shows an example of the test result reference screen (state change history) of a test result display tool in the test simulator in one embodiment of this invention.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 ... Source selection tool according to function, 2 ... Compiler, 3 ... Software analysis test condition generation tool, 4 ... Hardware / software condition generation part, 5 ... Test execution part, 6 ... LSI access table creation part, 7 ... Storage apparatus simulator , 8 ... Test result display tool,
11 ... Source table according to function, 12 ... Software condition table, 13 ... LSI access table, 14 ... Hardware failure table, 15 ... Hardware / software condition table,
21 ... Extraction source, 22 ... Source, 23 ... Test target program, 24 ... LSI access information, 25 ... Variable / register log information, 26 ... Variable / register log, 27 ... Test result,
71 ... Program to be tested, 72 ... OS, 73 ... Memory simulation unit, 74 ... LSI simulation unit, 75 ... CPU simulation unit, 76 ... Variable / register log information output unit, 77 ... LSI access information output unit, 78 ... Arbitrary failure Generating unit, 79 ... simulation engine.

Claims (5)

A storage system simulator that executes a test of each condition in the software condition table;
An LSI access table creation unit for creating an LSI access table from the LSI access information output during execution of the storage device simulator;
Hardware / software conditions for generating a hardware / software condition table from the LSI access table created by the LSI access table creation unit, a hardware fault table and software condition table created in advance, and a specified fault type A generator,
A test simulator, comprising: a test execution unit that executes a test under each condition of the hardware / software condition table generated by the hardware / software condition generation unit. The test simulator according to claim 1,
A test simulator, further comprising a database of variables and register log information for registering variables and register logs at the time of testing in the storage apparatus simulator. The test simulator according to claim 2,
A test simulator, further comprising a test result display tool for displaying a test variable registered in the variable / register log information database, register log information, and a test result. In the test simulator according to claim 3,
A test simulator further comprising a function-specific source selection tool that extracts a source necessary for a test based on a specified function from a function-specific source table created in advance. The test simulator according to claim 4,
A test simulator further comprising a software analysis / test condition creation tool for creating a software condition table from a source extracted by the function-specific source selection tool.

Images