B
back-to-back testing:
Testing in which two or more variants of a component or system are
executed with the same inputs, the outputs compared, and
analyzed in cases of
discrepancies. [IEEE 610]
{mosgoogle left}
baseline: A specification or
software product that has been formally reviewed or agreed upon, that
thereafter serves as the basis for further development, and that can be changed
only through a formal change control process. [After IEEE 610]
basic block: A sequence of
one or more consecutive executable statements containing no
branches.
basis test set: A set of
test cases derived from the internal structure or specification to ensure that
100% of a specified coverage criterion is achieved.
bebugging: See error
seeding. [Abbott]
behavior: The response of a
component or system to a set of input values and preconditions.
benchmark test: (1) A
standard against which measurements or comparisons can be made.
(2) A test that is be used to compare components or systems
to each other or to a standard
as in (1). [After IEEE 610]
bespoke software: Software
developed specifically for a set of users or customers. The
opposite is off-the-shelf software.
best practice: A superior
method or innovative practice that contributes to the improved
performance of an organization under given context, usually
recognized as best by other
peer organizations.
beta testing: Operational
testing by potential and/or existing users/customers at an external site not
otherwise involved with the developers, to determine whether or not a component
or system satisfies the user/customer needs and fits within the business
processes. Beta testing is often employed as a form of external acceptance
testing in order to acquire feedback from the market.
big-bang testing: A type of
integration testing in which software elements, hardware
elements, or both are combined all at once into a component
or an overall system, rather
than in stages. [After IEEE 610] See also integration
testing.
black box technique: See
black box test design technique.
black box testing: Testing,
either functional or non-functional, without reference to the
internal structure of the component or system.
black box test design techniques:
Documented procedure to derive and select test cases
based on an analysis of the specification, either functional
or non-functional, of a
component or system without reference to its internal
structure.
blocked test case: A test
case that cannot be executed because the preconditions for its
execution are not fulfilled.
bottom-up testing: An
incremental approach to integration testing where the lowest level
components are tested first, and then used to facilitate the
testing of higher level
components. This process is repeated until the component at
the top of the hierarchy is
tested. See also integration testing.
{mosgoogle left}
boundary value: An input
value or output value which is on the edge of an equivalence
partition or at the smallest incremental distance on either
side of an edge, for example the
minimum or maximum value of a range.
boundary value analysis: A
black box test design technique in which test cases are designed based on
boundary values.
7
boundary value coverage: The
percentage of boundary values that have been exercised by
test suite.
boundary value testing: See
boundary value analysis.
branch: A basic block that
can be selected for execution based on a program construct in
which one of two or more alternative program paths are
available, e.g. case, jump, go to, ifthen-else.
branch condition: See
condition.
branch condition combination
coverage: See multiple condition coverage.
branch condition combination
testing: See multiple condition testing.
branch condition coverage:
See condition coverage.
branch coverage: The
percentage of branches that have been exercised by a test suite. 100% branch
coverage implies both 100% decision coverage and 100% statement coverage.
branch testing: A white box
test design technique in which test cases are designed to execute branches.
bug: See defect.
business process-based testing:
An approach to testing in which test cases are designed
based on descriptions and/or knowledge of business
processes.
C
Capability Maturity Model (CMM):
A five level staged framework that describes the key
elements of an effective software process. The Capability
Maturity Model covers practices for planning, engineering and managing software
development and maintenance. [CMM]
Capability Maturity Model
Integration (CMMI): A framework that describes the key
elements of an effective product development and maintenance
process. The Capability
Maturity Model Integration covers practices for planning,
engineering and managing
product development and maintenance. CMMI is the designated
successor of the CMM.
[CMMI]
capture/playback tool: A
type of test execution tool where inputs are recorded during
manual testing in order to generate automated test scripts
that can be executed later (i.e.
replayed). These tools are often used to support automated
regression testing.
capture/replay tool: See
capture/playback tool.
CASE: Acronym for Computer
Aided Software Engineering.
CAST: Acronym for Computer
Aided Software Testing. See also test automation.
cause-effect graph: A
graphical representation of inputs and/or stimuli (causes) with their
associated outputs (effects), which can be used to design
test cases.
cause-effect graphing: A
black box test design technique in which test cases are designed
from cause-effect graphs. [BS 7925/2]
cause-effect analysis: See
cause/effect graphing.
cause-effect decision table:
See decision table.
certification: The process
of confirming that a component, system or person complies with its specified
requirements, e.g. by passing an exam.
8
changeability: The
capability of the software product to enable specified modifications to be implemented.
[ISO 9126] See also maintainability.
checker: See reviewer.
Chow's coverage metrics: See
N-switch coverage. [Chow]
classification tree method:
A black box test design technique in which test cases, described by means of a
classification tree, are designed to execute combinations of representatives of
input and/or output domains. [Grochtmann]
code analyzer: See static
code analyzer.
code coverage: An analysis
method that determines which parts of the software have been executed (covered)
by the test suite and which parts have not been executed, e.g. statement coverage,
decision coverage or condition coverage.
code-based testing: See
white box testing.
co-existence: The capability
of the software product to co-exist with other independent
software in a common environment sharing common resources.
[ISO 9126] See portability testing.
commercial off-the-shelf software:
See off-the-shelf software.
comparator: See test
comparator.
compatibility testing: See
interoperability testing.
complete testing: See
exhaustive testing.
completion criteria: See
exit criteria.
complexity: The degree to
which a component or system has a design and/or internal
structure that is difficult to understand, maintain and
verify. See also cyclomatic
complexity.
compliance: The capability
of the software product to adhere to standards, conventions or
regulations in laws and similar prescriptions. [ISO 9126]
compliance testing: The
process of testing to determine the compliance of component or
system.
component: A minimal
software item that can be tested in isolation.
component integration testing:
Testing performed to expose defects in the interfaces and
interaction between integrated components.
component specification: A
description of a components function in terms of its output
values for specified input values under specified
conditions, and required non-functional
behavior (e.g. resource-utilization).
component testing: The
testing of individual software components. [After IEEE 610]
compound condition: Two or
more single conditions joined by means of a logical operator (AND, OR or XOR),
e.g. A>B AND C>1000.
concrete test case: See low
level test case.
concurrency testing: Testing
to determine how the occurrence of two or more activities
within the same interval of time, achieved either by
interleaving the activities or by
simultaneous execution, is handled by the component or
system. [After IEEE 610]
9
condition: A logical
expression that can be evaluated as True or False, e.g. A>B. See also test condition.
condition combination coverage:
See multiple condition coverage.
condition combination testing:
See multiple condition testing.
condition coverage: The
percentage of condition outcomes that have been exercised by a test suite. 100%
condition coverage requires each single condition in every decision statement to
be tested as True and False.
condition determination coverage:
The percentage of all single condition outcomes that
independently affect a decision outcome that have been
exercised by a test case suite.
100% condition determination coverage implies 100% decision
condition coverage.
condition determination testing:
A white box test design technique in which test cases are
designed to execute single condition outcomes that
independently affect a decision
outcome.
condition testing: A white
box test design technique in which test cases are designed to
execute condition outcomes.
condition outcome: The
evaluation of a condition to True or False.
confidence test: See smoke
test.
configuration: The composition
of a component or system as defined by the number, nature, and interconnections
of its constituent parts.
configuration auditing: The
function to check on the contents of libraries of configuration
items, e.g. for standards compliance. [IEEE 610]
configuration control: An
element of configuration management, consisting of the
evaluation, co-ordination, approval or disapproval, and
implementation of changes to
configuration items after formal establishment of their
configuration identification. [IEEE
610]
configuration identification:
An element of configuration management, consisting of
selecting the configuration items for a system and recording
their functional and physical
characteristics in technical documentation. [IEEE 610]
configuration item: An
aggregation of hardware, software or both, that is designated for
configuration management and treated as a single entity in
the configuration management
process. [IEEE 610]
configuration management: A
discipline applying technical and administrative direction and surveillance to:
identify and document the functional and physical characteristics of a
configuration item, control changes to those characteristics,
record and report change
processing and implementation status, and verify compliance
with specified requirements.
[IEEE 610]
configuration testing: See
portability testing.
confirmation testing: See
re-testing.
conformance testing: See
compliance testing.
consistency: The degree of uniformity, standardization, and
freedom from contradiction
among the documents or parts of a component or system. [IEEE
610]
10
control flow: An abstract
representation of all possible sequences of events (paths) in the
execution through a component or system.
control flow graph: See
control flow.
control flow path: See path.
conversion testing: Testing
of software used to convert data from existing systems for use in replacement
systems.
COTS: Acronym for Commercial
Off-The-Shelf software.
coverage: The degree,
expressed as a percentage, to which a specified coverage item has been exercised
by a test suite.
coverage analysis:
Measurement of achieved coverage to a specified coverage item during test
execution referring to predetermined criteria to determine whether additional
testing is required and if so, which test cases are needed.
coverage item: An entity or
property used as a basis for test coverage, e.g. equivalence
partitions or code statements.
coverage tool: A tool that
provides objective measures of what structural elements, e.g.
statements, branches have been exercised by the test suite.
custom software: See bespoke
software.
cyclomatic complexity: The
number of independent paths through a program. Cyclomatic
complexity is defined as: L N + 2P, where
- L = the number of edges/links in a graph
- N = the number of nodes in a graph
- P = the number of disconnected parts of the graph (e.g. a
calling graph and a subroutine).
[After McCabe]
cyclomatic number: See
cyclomatic complexity.
Subscribe to this comment's feed
| < Prev | Next > |
|---|
