|
Testing Computer Software Second Edition
Common Software Errors - Hardware
|
This is the appendix from the best-selling book Testing Computer Software, 2nd ed.
Copyright © 1988 by Cem Kaner Copyright © 1993 by Cem Kaner, Jack Falk, Hung Quoc Nguyen
This is part 11 of 13.
[ 1 ]
[ 2 ]
[ 3 ]
[ 4 ]
[ 5 ]
[ 6 ]
[ 7 ]
[ 8 ]
[ 9 ]
[ 10 ]
[ 11 ]
[ 12 ]
[ 13 ]
|
HARDWARE
Programs send bad data to devices, ignore error codes coming back, try to use devices that aren't there, and so on. Even if the problem is truly due to a hardware failure, there is also a software error if the software doesn't recognize that the hardware is no longer working correctly.
WRONG DEVICE
For example, the program prints data on the screen instead of the printer.
WRONG DEVICE ADDRESS
In many systems, a program writes data to a device by writing them to one or a few addresses in memory. The physical copying of data from these special memory locations to the devices themselves is taken care of by hardware. The program might write the data to the wrong memory location(s).
DEVICE UNAVAILABLE
See "Required resource not available" earlier in this Appendix.
DEVICE RETURNED TO WRONG TYPE OF POOL
For example, in a multi-processing system there might be many dot matrix printers and many laser printers. A program uses a dot matrix printer, then signals that it's done with it. On returning it to the pool of available devices, the resource manager erroneously marks it as an available laser printer.
DEVICE USE FORBIDDEN TO CALLER
For example, you might not be allowed to use this expensive or delicate device. Programs running under your user ID can't use the device and must be able to recover from the refusal.
SPECIFIES WRONG PRIVILEGE LEVEL FOR A DEVICE
To use a device (for example, to read a certain file or to place a long distance phone call), the program must supply a code that indicates its privilege level (often the privilege level of the person using the program.) If its privilege level (or priority) is high enough, the program gets
the device.
NOISY CHANNEL
The program starts using a device, such as a printer or a modem. A communication channel links the computer and the connected device. Electrical interference, timing problems or other oddities might cause imperfect transmission of information over the channel (we.e., the computer sends a 3 but the device receives a 1). How does the program detect transmission errors? What does it do to signal or correct them?
CHANNEL GOES DOWN
The computer is sending data through one modem across a telephone line to another computer (and modem). One of the modems is unplugged halfway through the transmission. How do the sending and receiving computers recognize that they are no longer connected, how long does it take them, and what do they do about it? Similarly, how does a computer recognize that it's connected to a no-longer-printing printer, and what does it do about it?
TIME-OUT PROBLEMS
The program sends a signal to a device and expects a response within a reasonable time. If it gets no response, eventually the program must give up, deciding perhaps that the connected device is broken. What if it just didn't wait long enough?
WRONG STORAGE DEVICE
The program looks for data or a code overlay on the wrong floppy disk, removable hard disk, cartridge, or tape reel. Some programs announce that the information isn't there, then ask you to insert the right disk. Some look for the information on other drives first, then ask. Others just die. In one particularly feisty operating system, programs could destroy a floppy disk's directory while looking for a file that wasn't there.
DOESN'T CHECK DIRECTORY OF CURRENT DISK
Insert one disk (hard disk pack, tape), work with it, then remove it and insert a different one into the same drive. Some operating systems don't detect the swap. They copy the directory of a disk into memory and don't read it again from the disk unless you explicitly tell them to. If you don't force a reboot or a directory reread, they'll use the old directory when trying to read or write to the new disk, reading gibberish and destroying the new disk's data when they write.
DOESN'T CLOSE A FILE
When the program finishes with a file (especially if it's been writing to the file), it should close the file. Otherwise, changes made to the file during this session might not be saved on disk, or further changes may be added inadvertently. Open files can be destroyed or corrupted when you turn the machine off. Programs should close all open files as part of their exit procedures.
UNEXPECTED END OF FILE
While reading a file, the program reaches the end-of-file marker. Suppose the program expects to find specific data later in the file. Does it ignore the end-of-file and try to keep reading? Does it crash?
DISK SECTOR BUGS AND OTHER LENGTH-DEPENDENT ERRORS
Disk storage is done in chunks (sectors) of perhaps 256 or 512 bytes. Many other values, usually powers of 2, are common. Some programs fail when they try to save or read a file that is an exact multiple of a sector size. For example, if sectors are 1024 bytes, a program might be unable to save files that are 1024, 2048, 3072, etc., bytes long. (Similarly, a program that copies data to an output buffer of a fixed size might fail if the number of bytes to go is the same size as the buffer.)
The last character of each sector, or only the last character of the file, might be miscopied, copied twice, or dropped. In more extreme cases, the program corrupts the entire file or overwrites the next file on disk.
WRONG OPERATION OR INSTRUCTION CODES
The program sends a command to the terminal that is supposed to reposition the cursor onscreen but it turns on inverse video display mode instead. The program sends a command to the printer to do a form feed, but the printer line feeds instead. Devices are not standardized. Two printers probably require two different commands to do the same thing. Similarly for terminals, plotters, and A/D converters. The program must issue the right command for this device to get the right task done.
MISUNDERSTOOD STATUS OR RETURN CODE
The program sends a command to the printer telling it to turn on boldfacing. The printer may respond, saying it can or can't do this. It may indicate why it can't carry out the command (e. g., no paper, no ribbon, no such command, option module not installed.). Many programs ignore these codes, or compare them against a list of codes written for the wrong machine or compiled years ago.
DEVICE PROTOCOL ERROR
The communication protocol between the computer and a device or between two computers specifies such things as when the computer can send data, at what speed, and with what characteristics (parity, stop bits, etc.). It also specifies whether and how the receiving device will signal that it got the data, that it's ready for more, or that it can't take any more until it clears some of the buffer that it's working with.
A device might send data or respond out of turn, or it might send the data in the wrong format.
UNDERUTILIZES DEVICE INTELLIGENCE
As a simple example, if the printer can print boldface text directly, why try to simulate boldface by printing on top of the same character three or four times? One possible answer is that the program was designed with less capable printers in mind, and has not been updated to take advantage of this printer's features.
A connected device might be able to define its own fonts, detect its own error states, etc., but the program using the device must recognize this or it won't make any use of these advanced capabilities.
This can be a touchy issue. Printers' control codes differ by so much that it is very expensive to try to support all the built-in features of every printer. Some printer manufacturers have made this problem even more complex by including certain control codes in one ROM version for a printer, but including different codes in other ROMS, plugged into the same (from appearance and model number) printer.
PAGING MECHANISM IGNORED OR MISUNDERSTOOD
This is a memory storage issue. Memory might be divided into sections called pages. A program might not be able to read from all pages at once or switch pages (or memory banks) correctly.
Larger computers use disk storage as virtual memory. The program refers to data without knowing whether they reside in memory or on disk. If the program references a nonresident set of data or code, a page fault has occurred. The computer fetches the page containing this information from disk automatically, overwriting data that were resident. The operating system usually takes care of paging (swapping data and code between main memory and a disk), but a few programs try to do it themselves. A program might overwrite a memory area without first saving new data that were stored there.
A program that thrashes is constantly generating page faults: the computer spends more time moving data in and out of main memory than it does executing the program. With a little reorganization of the code or the data, many programs can avoid thrashing.
IGNORES CHANNEL THROUGHPUT LIMITS
Examples:
- The program tries to send 100 characters per second across a connection that only supports transmission of up to 10 characters per second.
- The program can send data at a fast rate until the connected device's input buffer is full. Then it has to stop until the device makes more room in its input buffer. Some programs don't recognize signals that the device is no longer ready to receive more data.
ASSUMES DEVICE IS OR ISN'T, OR SHOULD BE OR SHOULDN'T BE INITIALIZED
Before sending text to the printer, a word processing program sends an initialization message telling the printer to print ten characters per inch in a certain font, without making them bold or italicized. Should it have sent this message? This wastes time if the printer was already initialized. It is irritating if you deliberately initialized the printer to a different setting before trying to print the file. On the other hand, if the printer is set to an unsuitable font, the printout will be unsatisfactory and the failure to initialize will have wasted time and paper. Which error is more serious?
ASSUMES PROGRAMMABLE FUNCTION KEYS ARE PROGRAMMED CORRECTLY
A programmable function key might be able to generate any code or any reasonably short sequence of codes when pressed. The program might expect these keys to generate specific codes, but if you can reprogram the keys, the program might be wrong. For example, suppose that function key normally generates . A program says Press PF-1 to Print. It switches to its Print Menu when it receives . What if you reprogram so that it generates instead? Press PF-1 to Print is no longer true.
If the program relies on the assignment of special values to programmable function keys,
when it starts it has to make sure that those keys have been assigned those values.
|