26-02-2013, 11:27 AM
Failure ,Error , Fault
Failure ,Error.docx (Size: 19.46 KB / Downloads: 24)
• Failure:
A failure is said to occur whenever the external behavior of a
system does not confirm to that prescribed in the system specification.
A failure is the inability of a software system or component to perform its required functions within specified performance requirements
• Error:
An error is a state of the system. In the absence of any corrective
action by the system, an error state could lead to a failure which would
not be attributed to any event subsequent to the error.
An error is a mistake, misconception, or misunderstanding on the part of a software
developer.
• Fault:
A fault is the adjudged cause of an error.
A fault (defect) is introduced into the software as the result of an error. It is an
anomaly in the software that may cause it to behave incorrectly, and not according
to its specification.
Faults or defects are sometimes called “bugs.”
• A fault may remain undetected for a long time, until some event activates it.
• When an event activates a fault, it first brings the program into an intermediate error state.
• If computation is allowed to proceed from an error state without any corrective
action, the program eventually causes a failure. As an aside, in fault-tolerant computing.
• behavior chain: fault→error→failure.
• The behavior chain can iterate for a while, that is, failure of one component can lead to a failure of another interacting component.
• failure means “the customer’s expectation has not been met and/or the customer is unable to do useful work with product.
• “failure is a matter of function only [and is thus] related to purpose, not to whether an item is physically intact or not”.
Testing objectives:-
The stakeholders in a test process are the programmers, the test engineers, the
project managers, and the customers. A stakeholder is a person or an organization
who influences a system’s behaviors or who is impacted by that system.
Different stakeholders view a test process from different perspectives as explained
below:
• It does work: While implementing a program unit, the programmer may
want to test whether or not the unit works in normal circumstances. The
programmer gets much confidence if the unit works to his or her satisfaction.
The same idea applies to an entire system as well—once a system
has been integrated, the developers may want to test whether or not the
system performs the basic functions.
• It does not work: Once the programmer (or the development team) is
satisfied that a unit (or the system) works to a certain degree, more tests
are conducted with the objective of finding faults in the unit (or the system).
Here, the idea is to try to make the unit (or the system) fail.
• Reduce the risk of failure: Most of the complex software systems contain
faults, which cause the system to fail from time to time. This concept of
“failing from time to time” gives rise to the notion of failure rate. As
faults are discovered and fixed while performing more and more tests, the
failure rate of a system generally decreases. Thus, a higher level objective
of performing tests is to bring down the risk of failing to an acceptable
level.
• Reduce the cost of testing: The different kinds of costs associated with a
test process include
the cost of designing, maintaining, and executing test cases,
the cost of analyzing the result of executing each test case,
the cost of documenting the test cases, and
the cost of actually executing the system and documenting it.
Therefore, the less the number of test cases designed, the less will be the
associated cost of testing. However, producing a small number of arbitrary
test cases is not a good way of saving cost. The highest level of objective
of performing tests is to produce low-risk software with fewer number
of test cases. i.e The idea is effectiveness of test cases.