This U.S. non-provisional patent application claims priority under 35 U.S.C. §119 of Korean Patent Application No. 10-2007-0040127, filed on Apr. 25, 2007, the entire contents of which are hereby incorporated by reference.
1. Field of the Invention
The present invention disclosed herein relates to embedded software test, and more particularly but not by way of limitation, to a method for automatically generating a test case.
2. Description of Related Art
Typical embedded software is tested by monitoring and debugging an emulator. The monitoring may be synchronous or asynchronous. In synchronous monitoring, a source code debugger such as the remote Kernal GNU DeBugger KGDB is used to stop a program at a certain location in a source code and monitor a value of the corresponding location. In asynchronous monitoring, an independent monitoring daemon is used to monitor the entire embedded software, which may lead to inaccurate measurement of a source code that is to be monitored.
In both the synchronous monitoring scheme and the asynchronous monitoring technique, a code area, a data area, global variables, and a stack area may be monitored. Many such tests are performed on an ad-hoc basis rather than on an objective basis because determination of monitoring target symbols and analysis of the results may vary depending on the developers' experience/knowledge levels. Furthermore, simple monitoring techniques focus on test automation rather than identification of a test target (i.e., an input of a test case), generation of the test case, and analysis of the test results.
Embedded software is typically linked with hardware, a hardware abstraction layer (HAL), an OS kernel, device drivers, and upper-level application software. In an embedded system, the interfaces between such layers must be tested. This is, however, difficult to achieve using conventional test technology.
An embodiment of the invention provides an apparatus and method for automatically extracting interface symbols to test an interface of embedded software.
An embodiment of the invention also provides an apparatus and method for automatically generating a test case to test an interface of embedded software.
An embodiment of the invention provides a method for testing software. The method includes: identifying an interface test feature associated with the software, the interface test feature being associated with an interface symbol, the interface symbol enabling measurement of the interface test feature; and extracting a location in the software associated with the interface symbol.
An embodiment of the invention provides an apparatus for testing software. The apparatus includes: a test target analyzer configured to receive the software, identify at least one interface between a plurality of layers in the software, and identify a location in the software for the at least one interface; and a test case generator coupled to the test target analyzer, the test case generator configured to generate a test case for the software based on the identified at least one interface and the location.
Embodiments of the invention thus facilitate the testing of software at interfaces between layers in the software.
The accompanying figures are included to provide a further understanding of the present invention, and are incorporated in and constitute a part of this specification. The drawings illustrate exemplary embodiments of the present invention and, together with the description, serve to explain principles of the present invention. In the figures:
Preferred embodiments of the present invention will be described below in more detail with reference to the accompanying drawings. The present invention may, however, be embodied in different forms and should not be constructed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the present invention to those skilled in the art.
An embodiment of the invention provides an apparatus and method for automatically generating a test case for a LINUX-based LCD device driver. In this instance, an evaluation board can be emulated prior to actual product development. An embodiment of the invention exemplifies an LCD device driver as embedded software.
Referring to
The host system 10 generates a test case for testing an interface of the embedded software 41. In addition, the host system 10 controls the emulator 20 to execute the generated test case. The emulator 20 executes the test case generated by the host system 10, and outputs the results. The evaluation board 30 is provided to test the embedded software 41 together with hardware. The LINUX server 40 loads the embedded software 41 into the evaluation board 30 under the control of the emulator 20.
The host system 10 includes a test target analyzer 11, a test case generator 12, a test executing engine 13, and a result analyzer 14. The test target analyzer 11 receives a source (or object) code of the embedded software 41 from the LINUX server 40. From an executable linker format (ELF), the test target analyzer 11 automatically identifies a location in the source (or object) code where an interface symbol corresponding to each interface is mapped. The test case generator 12 generates a test case for testing the interface of the embedded software 41. The test case is generated in a script format so that it can be executed in the emulator 20. The test execution engine 13 receives the test case from the test case generator 12, provides the received test case to the emulator 20, and controls the emulator 20. The result analyzer 14 receives the execution results of the test case from the emulator 20, and analyzes the received execution results.
Variations to the embodiment illustrated in
The present invention tests the structure of embedded software (i.e., an LCD device driver) loaded into an embedded system, for example a mobile application (AP), and tests an interface in an LCD emulation test.
Referring to
The embedded system 30 may include a variety of device drivers for supporting physical devices mounted on the evaluation board 30, examples of which include data transfer-related device drivers (such as a USB driver and a serial bus driver) and audio-related device drivers such as Audio code 1997 (AC97) and Infrared Data Association (IrDA) links.
The embedded software 33 runs in such a way that software units in respective layers are tightly coupled with each other. The software units in the respective layers are classified into a kernel-dependent software unit (SUk), a device-dependent software unit (SUd), and a processor-dependent software unit (SUp). An exemplary SUk is an OS application program interface for providing an OS service. An exemplary SUd is software of an LCD controller for supporting a physical device. An exemplary SUp is software of the HAL 32, which is dependent on a target processor, such as for hardware device initialization and configuration.
Referring to
The LCD controller of the LCD device driver exemplified herein corresponds to the HUi.
Referring to
The five interfaces illustrated in
An OS of an exemplary LCD device driver is based on LINUX. Therefore, the device driver follows the LINUX standard file operations, and upper-level application software can invoke (or enable) the device driver only through standard file operations such as a function open( ), a function close( ), a function read( ), a function write( ), a function mset( ), and a function ioctl( ).
An interface of the LCD device driver is a unit where functions defined in LCD file operations are present between the software unit SUk/SUd/SUp and the hardware unit HUd/HUi in a call relationship.
Referring to
The LCD device driver includes a total of 74 interfaces for a function s3c2440fb_init( ), a function fb_open( ), a function fb_release( ), a function fb_read( ), a function fb_write( ), a function fb_mmap( ), and a function fb_ioctl( ). The 74 interfaces are classified into 32 HPI1's, 2 HPI2's, and 40 OPI3's, based on the interface pattern.
Table 2 illustrates the interface test characteristics of the LCD device driver and interface symbols that must be monitored for the respective characteristics.
From an executable linker format (ELF) file of a target source, the test target analyzer 11 identifies a location where an interface symbol of the interface test characteristics of the LCD device driver, which is shown in Table 2, is mapped in a test target source code. The ELF file is used to store all information on a source that is programmed by the developer for the use of a debugger. When a call stack is difficult to identify, for example, by backtrace, “objdump” is a command for identifying a source address and “readelf” is a command for indicating ELF file format information.
Referring to
An HPI1
An HPI1
An HPI1
In order to detect a location where the timer-related interface test characteristics of an HPI2 are mapped to a source code, a symbol related to a timer of a frame buffer is extracted from an ELF file generated by a command objdump −t.
An HPI2
In order to detect a location where the interrupt & memory management-related interface test characteristics of an OPI3 are mapped to a source code, an address for an interface symbol of the OPI3 is extracted from an ELF file generated by a command objdump −IS.
An OPI3
The OPI3
An OPI3
An OPI3
An OPI3
An OPI3
An OPI3
An OPI3
An OPI3
In the case of an OPI3
In the case of an OPI3
An OPI3
The test case generator 12 generates a test case that covers a test target LCD device driver interface detected by the test target analyzer 11. The test case is constructed to include an interface symbol corresponding to an input, which is to be monitored in each interface, data of the interface symbol, and an expected output.
A test case for each of the LCD device driver interface characteristics is determined according to each LCD device driver interface location and type. Table 3 shows expected output reference locations that can be used instead of expected output values. The reason for this is that an output value changes every time it is monitored through operation of the emulator 20.
Test cases generated by the test case generator 12 are constructed in the format of a test script suitable for batch run by the emulator 20. An interface symbol in Table 3 is a location for setting a break point (BP) of a test script, and an expected output reference location in Table 3 is a location that is to be monitored for determination of pass/fail at the location of the interface symbol.
Referring to
An exemplary embodiment of the present invention provides a method for automatically generating an interface test case for the interface test of a LINUX-based LCD device driver. The LINUX-based LCD device driver is exemplified as being developed on an S3C2440 board having a TRACE32-ICD emulator and an ARM processor.
Referring to
Referring to
The test target analyzer 11 identifies a layer of the LCD device driver 41 (step 220). That is, the test target analyzer 11 identifies an inter-layer interface of the LCD device driver 41 according to classified definitions. For example, it is determined whether the structure of sub-functions of the LCD device driver 41 corresponds to the interface defined in Table 1. The test target analyzer 11 identifies the call relationship of the LCD device driver (step 230). That is, only sub-functions called between interfaces are selected as a test target.
For the sub-functions called between interfaces, the test target analyzer 11 identifies an interface of the LCD device driver, which is defined in Table 2, and an interface symbol to be tested in the interface (step 240). In order to automatically identify a location where the interface symbol is mapped in the source code, the test target analyzer 11 maps the interface symbols of the LCD device driver corresponding to HPI1, HPI2, OPI1, OPI2 and OPI3 from the ELF file and the object code of the LCD device driver (step 250). The test target analyzer 11 extracts a location of the mapped symbol and the test case generator 12 sets each break point in the interface extracted by the test target analyzer 11 (step 260). The test case generator 12 sets each break point as an input of a test case (step 270). The test case generator 12 determines monitoring symbols that are to be monitored for determination of pass/fail for each interface (step 280). Based on this, an expected output of a corresponding interface is set (step 290). That is, a test case is generated using the input and the expected output. At this point, the test case is generated in a script format suitable for batch run in the emulator (step 300).
The method for generating the test case for the interface test of the LINUX-based LCD device driver according to the present invention combines the debugging/monitoring function of the emulator with the interface testing function, thereby supporting fault detection and fault cause estimation and automating the test for the LINUX-based LCD device driver.
Accordingly, the present invention automatically identifies the interface symbols for software of all layers that are organically linked with the LCD device driver, including the LINUX-based LCD device driver and the kernel related thereto.
In addition, the present invention automatically generates the test case for the interface test of the LINUX-based LCD device driver. The present invention automatically identifies the test case covering the interface of the identified LINUX-based LCD device driver, and adds a function for automatically determining the pass/fail of a test input symbol to the test case, thereby determining the test pass/fail automatically when the generated test case is executed.
As described above, the present invention makes it possible to automatically generate a test case for the interface test of a device driver.
In addition, the present invention can automatically identify the test case covering the interface of the device driver, and can add the function for automatically determining the pass/fail of the test input symbol to the test case, thereby making it possible to automatically determine the test pass/fail when the generated test case is executed.
The above-disclosed subject matter is to be considered illustrative, and not restrictive, and the appended claims are intended to cover all such modifications, enhancements, and other embodiments, which fall within the true spirit and scope of the present invention. Thus, to the maximum extent allowed by law, the scope of the present invention is to be determined by the broadest permissible interpretation of the following claims and their equivalents, and shall not be restricted or limited by the foregoing detailed description.
Number | Date | Country | Kind |
---|---|---|---|
10-2007-0040127 | Apr 2007 | KR | national |
Number | Name | Date | Kind |
---|---|---|---|
5740352 | Philipp et al. | Apr 1998 | A |
6938243 | Zeevi et al. | Aug 2005 | B1 |
6986125 | Apuzzo et al. | Jan 2006 | B2 |
7047176 | Klevans et al. | May 2006 | B2 |
7093238 | Givoni et al. | Aug 2006 | B2 |
7210128 | Fallah et al. | Apr 2007 | B2 |
7243059 | Crowell | Jul 2007 | B2 |
7404178 | Cepulis | Jul 2008 | B2 |
7950004 | Vieira et al. | May 2011 | B2 |
20010049594 | Klevans | Dec 2001 | A1 |
20030037314 | Apuzzo et al. | Feb 2003 | A1 |
20030126517 | Givoni et al. | Jul 2003 | A1 |
20040215440 | Crowell | Oct 2004 | A1 |
20040250244 | Albrecht | Dec 2004 | A1 |
20050028146 | Quick | Feb 2005 | A1 |
20050289517 | Balfe et al. | Dec 2005 | A1 |
20060253739 | Godefroid et al. | Nov 2006 | A1 |
20070214451 | Watzl | Sep 2007 | A1 |
20070234314 | Godwin et al. | Oct 2007 | A1 |
20080282229 | Kim et al. | Nov 2008 | A1 |
Number | Date | Country |
---|---|---|
1020010038541 | May 2001 | KR |
1020040087767 | Oct 2004 | KR |
1020050111323 | Nov 2005 | KR |
1020070021879 | Feb 2007 | KR |
2004072733 | Aug 2004 | WO |
Number | Date | Country | |
---|---|---|---|
20080270996 A1 | Oct 2008 | US |