Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1998-08-26
2001-06-05
Iqbal, Nadeem (Department: 2184)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C709S241000
Reexamination Certificate
active
06243833
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
This invention generally relates to computer system drivers. More specifically, this invention relates to generating test data for computer system drivers.
2. Background Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely sophisticated devices, and computer systems may be found in many different settings. Modern computer systems vary in their design and architecture, with many different models available to achieve the desired combination of speed, power and efficiency for any given computing environment.
Computer systems typically include operating system software that controls the basic functions of the computer, and one or more software applications that run under the control of the operating system to perform desired tasks. For example, a typical IBM Personal Computer may run the OS/2 operating system, and under the control of the OS/2 operating system, a user may execute an application program, such as a word processor. As the capabilities of computer systems have increased, the software applications designed for high performance computer systems have become extremely powerful.
One example of a specific area of computer-related technology that has become increasingly more complex over the years is the use and application of “device drivers.” Drivers are typically small, dedicated software routines that act as intermediaries between the operating system and/or an application and a piece of hardware. For instance, when a user wishes to print a document, the word processing program must communicate with the printer driver in order to access the printer. The printer driver knows how to control the printer to accurately reproduce the document being printed from the word processing program. Other software programs that need to provide printed output would also access the printer via the printer driver. Similarly, other driver programs are written to control other types of computer-related peripheral devices such as CD-ROM drives, scanners, etc. Since drivers are typically adapted to function with a given combination of software and hardware, new drivers are commonly loaded into a system whenever a new software program or hardware peripheral is added to a computer system.
One reason that drivers have been increasing in complexity is because computer hardware has been increasing in complexity. There are many different types of hardware available today that were not readily available only a few short years ago. This includes devices such as DVD disk drives, TV adapter cards, and other similar devices. Each device driver is generally tailored to a specific hardware product and, in some cases, a specific configuration of a given hardware product. Minor changes in hardware will often necessitate changes in the corresponding device drivers. As with other software programs, these driver updates or modifications are termed “revisions.” New features added to existing hardware components may also cause minor driver revisions. In fact, if there are major revisions to hardware, the device drivers associated with the newly revised hardware may have to be completely rewritten.
Not only are new device drivers increasing complex, existing drivers are also being modified on a more frequent schedule today. These modifications to the drivers tend to be smaller than the wholesale changes needed when a new version of hardware is introduced. Drivers occasionally need to be “updated” or partially rewritten if a “bug” is discovered in the operation of the driver. “Bugs” are programming errors in the device driver software which cause the driver to function incorrectly. Because of the increased complexity of drivers, eliminating one bug in a device driver may introduce another bug, which will then necessitate yet another change to the driver software. In addition, operating systems are always adding new functionality to the system, sometimes affecting the interaction and operation of device drivers.
These frequent changes to device drivers, for whatever reason, carry a concomitant requirement that drivers be tested very frequently. Whenever a change is implemented for a given device driver, the driver should be tested to ensure that the driver performs as it is intended to perform. Driver testing is usually performed by having a driver tester, as part of a test group, write an error and/or a diagnostic test case for every error or diagnostic test to which the driver can respond. The error test cases ensure that a driver can respond correctly to any possible error. Diagnostic test cases ensure that the hardware is functioning in accordance with the expectations for the device driver. Once again, as the driver software is updated to reflect new capabilities or new hardware, the diagnostic test cases for the driver software must also be updated to reflect and test the changes. Small changes in the driver software may require only small changes to be made from the previous versions of the test cases. However, significant changes in the driver software (such as when new hardware is developed or a driver for a new operating system is written) can cause large changes in the test cases, or, in comes cases, may force the developers to completely rewrite the diagnostic test cases for the new drivers.
The constant revision of the diagnostic test software and related testing of device drivers is extremely time consuming, even when small changes to the device driver are being made. Driver testers must compare the new driver's error and diagnostic test cases versus the old driver's error and diagnostic test cases. This process, which is performed manually, can be extremely laborious because there can be hundreds of different errors, and searching through the entire list just to delete one error and/or add another error is a lengthy endeavor. In addition, once the test cases have been generated for the new driver, the driver tester must then actually test the driver. This is also a lengthy process because the driver tester must simulate each error and verify that the device driver actually detects the error and responds to the error in the desired way.
In addition, the process of creating test and diagnostic cases for device drivers is, in itself, prone to the introduction of errors. The person writing the device driver software must be aware of the many different errors and the available diagnostic tests that the driver can support. These different errors and diagnostic tests must be transcribed and given to the driver tester. The driver tester then needs to use these errors and diagnostic tests to generate the error test cases and the diagnostic test cases, respectively. At each stage in this process, there is room for error. For instance, the person writing the driver may not transcribe the errors correctly, and this transcription mistake will end up in the final test and diagnostic cases.
Without an easier and more error-free way of generating error and diagnostic test cases for drivers and subsequently testing the drivers, software drivers will, of necessity, continue to be tested in a tedious, laborious, and error-prone manner. With the continued rapid introduction of new hardware products and the on-going introduction of new features for existing products, current driver testing procedures will be increasingly inadequate as time goes on.
DISCLOSURE OF INVENTION
The preferred embodiments of the present invention provide an apparatus and method for automatically generating error and diagnostic testing data from a device driver to be used in the error testing process. After generation, these test data are then used as input to a single generic test case that simulates the primitive errors for a given device driver and compares the expected result with the actual result.
In addition, the most preferred embodiments of the present invention generate the necessary test data using production driver code tables and/or driver maps containing primi
Hitchcock Glenn Daniel
Prissel Lee Patrick
International Business Machines - Corporation
Iqbal Nadeem
Schmeiser Olsen & Watts
LandOfFree
Apparatus and method for self generating error simulation... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Apparatus and method for self generating error simulation..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Apparatus and method for self generating error simulation... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2503502