Categories of Software Errors

《Testing Computer Software》

Categories of Software Errors

1.       User Interface Errors

 

a.       Functionality：It doesn’t do something it should do.

b.      Communication:

c.       Command structure: it is easy to get lost in the program?

d.      Missing commands: Does the program force you to think in a grid, unnatural, or inefficient way?

e.      Performance: speed of the essence in interactive software. Anything that makes the user feel that the program is working slowly is a problem.

f.        Output: Most programs display, print, graph, or save information.

2.       Error Handling

Errors in dealing with errors are common. Error handling errors include failure to anticipate the possibility of errors and protect against them, failure to notice error conditions and failure to deal with a detected error in a reasonable way.

3.       Boundary-related errors

If any aspect of a program’s use or functioning can be described as running from most to less biggest to smallest, soonest to latest, first to last, briefest to longest, you can check boundaries at the edges of these ranges of values.

4.       Calculation errors

Simple arithmetic is difficult and error-prone in some languages.

The category also includes computational errors due to incorrect algorithms.

5.       Initial And Later states

A function might only fail the first time you use it. That first time, you may get odd displays, wrong calculations, infinite loops, or out-of-memory error messages. Some of these come back each time you restart the program.

6.       Control flow errors

The control flow of a program describes what it will do next, under what circumstances. A control flow error occurs then the program does the wrong thing next.

7.       Errors in handling or interpreting data

One model can pass date to another module or to another program. A set of data might be passed back and forth many times. In the process it might be corrupted or misinterpreted. The latest changes to the data might be lost, or might reach some parts of the system but not others.

8.       Race conditions

The classic race is between two events, call them A and B. Either A or B can happen next. If A comes first, the program works. If B happens before A, the program fails because it expected A to always occur before B.

9.       Load conditions

The Program may misbehave when overloaded. It may fail under a high volume (much work over a long period) or high stress (maximum load at one time). All programs have limits. The issues are whether the program can meet its stated limits and how horribly it dies when the limits are exceeded.

10.   Hardware

Programs send bad data to devices, ignore error codes coming back, and try to use devices that are busy or aren’t there. Even if the hardware is broken, the software is also broken if it doesn’t recognize and recover from hardware failure.

11.   Source and version control

Enforcement of source and version control “standards” is often delegated to Quality Assurance groups. In our view, identification if source and version control problems is a Testing function; enforcement is not.

12.   Documentation

The documentation is not software but it is part of the software product. Poor documentation can lead users to believe that the software is not working correctly.

13.   Testing errors

If the program leads you to make mistakes, it has design problems.