| || |
Digest Number 1258
User Kidambi Seshadri (firstname.lastname@example.org) posted:
The following paragraphs clarify your query:
Volume Testing :
Volume Testing, as its name implies, is testing that
purposely subjects a system (both hardware and
software) to a series of tests where the volume of
data being processed is the subject of the test. Such
systems can be transactions processing systems
capturing real time sales or could be database updates
and or data retrieval.
Volume testing will seek to verify the physical and
logical limits to a system's capacity and ascertain
whether such limits are acceptable to meet the
projected capacity of the organisation's business
The purpose of Volume Testing is to find weaknesses in
the system with respect to its handling of large
amounts of data during short time periods. For
example, this kind of testing ensures that the system
will process data across physical and logical
boundaries such as across servers and across disk
partitions on one server.
Smoke Test :
1) A rudimentary form of testing applied to electronic
equipment following repair or reconfiguration, in
which power is applied and the tester checks for
sparks, smoke, or other dramatic signs of fundamental
2) By extension, the first run of a piece of software
after construction or a critical change.
Mutation testing :
Mutation Testing has been well-known to computer
scientists for decades. It is the process of
"re-writing" source code (hence the name Mutation) in
order to flush out ambiguities that may exist in the
code. These ambiguities can cause failures in software
if not detected and fixed by the developer. Because
these faults are often very subtle, they can easily
pass conventional testing and debugging only to be
passed on to the customer.
Although powerful, Mutation Testing is complicated and
time-consuming to perform without an automated tool.
Lacking a tool to bring its benefits to the commercial
market, Mutation Testing has not spread far outside
the research community.
Mutation Testing originated as a means of creating
more effective test suites. By creating more effective
test suites, the tester can be more confident that his
program is adequately tested.
The classical approach to Mutation Testing begins by
creating many versions of a program. Each of these
versions is "mutated" to introduce a single fault.
These "mutant" programs are then run against test
cases with the goal of causing each faulty version to
fail. Each time a test case causes a faulty version to
fail, that mutant is considered "killed" and the test
case is saved. When all mutants have been killed, the
saved test cases will comprise the test suite used to
test the original program.
This approach to Mutation Testing is useful for
creating test suites, but is little help for finding
bugs in the original program.
Benefits of Mutation Testing
Mutation Testing brings a whole new level of
error-detection to the software developer. This
powerful method is able to uncover ambiguities in code
previously thought impossible to detect automatically.
Mutation testing has been shown to be an effective
form of fault-based testing in the sense that if given
a sufficiently rich set of mutation operators,
mutation testing generalises other testing methods
based on various path and data flow coverage criteria.
Mutation testing is, however, an expensive testing
method (both in computing and human resources) due to
the large number of generated mutants that must be
executed and examined.
How does a manager measure the adequacy of the test
E.g. to decide when to release?
(1) Track error detection and release when below a
(2) Mutation testing
* Deliberately introduce bugs
* Measure how many of those bugs are found
* Use statistical reasoning to predict how
many other bugs remain in the code
* Injected bugs and residual bugs are
* Bugs are equivalent in effect
In a layman's terms "Seed the program with defects. Do
your test sets catch the errors? If not there is a
defect elsewhere in the program".
To end this point to an authoritative reference
A testing methodology in which two or more program
mutations are executed using the same test cases to
evaluate the ability of the test cases to detect
differences in the mutations.
Source: IEEE Std. 610.12-1990