Object-Oriented Testing Methods
Uploaded by
ScribdTranslationsObject-Oriented Testing Methods
Uploaded by
ScribdTranslationsOBJECT-ORIENTED TESTING METHODS
The goal of testing, put simply, is to find the greatest
possible amount of errors with a manageable amount of effort applied
during a realistic period. Although this fundamental goal remains
invariable for object-oriented software (OO), the nature of the
OO programs change in the strategy and tactics of testing. It could
It can be argued that, as reusable class libraries grow in
size, a greater reuse will mitigate OO systems in their need to
heavy tests. The opposite is exactly true.
To properly test OO systems, three things must be done:
Expand the definition of testing to include discovery techniques.
of errors applied to object-oriented analysis and design models.
2) Significantly change the strategy for unit testing and
integration.
3) Explain the unique characteristics of OO software through design
test cases.
Validation test in Object-Oriented software:
The architecture of object-oriented software (OO) results in a
series of layered subsystems that encapsulate collaborating classes. Each one
of these system elements (subsystems and classes) perform functions that
they help to achieve the system requirements. It is necessary to test a system
OO at several different levels with the intention of discovering errors that
may occur as classes collaborate with each other and as the
subsystems communicate through architectural layers
Validation in OO software focuses on actions visible to the
user and in the outputs of the system recognizable by him. To assist, it
they must resort to use cases.
Each test case must be uniquely and explicitly identified.
Other requirements:
Establish the purpose of the test.
Develop a list of test steps.
A list of specified states.
A list of messages and operations that will be exercised with the test.
A list of exceptions that can occur.
A list of external conditions.
Additional information.
Scenario-based test design
Contemplates errors of:
Incorrect specifications
Interactions between subsystems
example,
Consider a class in which a number of attributes are defined during the
first iteration of analysis. A strange attribute is attached to the class (due to
a misinterpretation of the problem domain). Then they can
two operations are specified to manipulate the attribute. An is carried out
review and a domain expert points out the problem.
What are the steps?
OO tests are strategically analogous to system testing
conventional, but tactically different. Since the OO analysis and the
design models are similar in structure and content to the OO program
resulting, the 'tests' begin with the review of those models. Once
the code generated, the OO test starts 'small', with the tests
of class. A series of tests are designed to exercise the operations of the class
and they examine whether there are errors as one class collaborates with others
classes. To the extent that classes integrate to form a
subsystem, thread-based, usage, and group tests are applied, along with
failure-based approaches, in order to fully exercise collaborative classes.
Finally, use cases are used (developed as part of the model of
requirements) to discover software validation errors
APPLICATION OF CONVENTIONAL DESIGN METHODS FOR CASES OF
TEST
White box testing methods can be applied to operations.
defined for a class. Basic route techniques, loop testing or flow
data can help ensure that all statements were tested in
an operation. However, the concise structure of many operations of
class makes some argue that the effort applied to the test of
white box can be better redirected to test at a class level.
Black box testing methods are just as appropriate for systems
Object-Oriented as for the developed systems, using methods of
conventional software engineering. Use cases can provide
useful input in the design of black box tests and those based on
state.
FAILURE BASED TESTS
Failure-based tests miss two main types of errors:
Incorrect specifications
2) Interactions between subsystems.
When errors occur due to an incorrect specification, the
the product does not do what the customer wants. It can do the right thing or omit
important functionality. But in any circumstance, the quality
(compliance with the requirements) is affected. The errors associated with the
interaction of subsystems occurs when the behavior of a
subsystem creates circumstances (for example, events, data flow) that
they cause another subsystem to fail.
This requires designing test cases that review the design or the code.
There are 3 types of failures: unexpected result, operation
incorrect and incorrect invocation.
Tests based on failures, test design that has a high
probability of discovering faults here we can find two main types
of errors:
Incorrect specifications.
Interaction between subsystems.
CONCLUSION
As has been seen, the objective of the OO tests remains the same as the
from the conventional tests. But in this case, what changes is the
strategy through which that objective is reached. The environment OO the focus of
the tests are no longer of the modules but are now of the classes.
The tests begin when modeling is done, then they continue with
unit tests for each class (such as failure-based tests,
random testing and partition testing). The tests are conducted afterwards.
integration (based on thread or usage) and finally, tests are conducted
validation, for which conventional methods can be performed
black box.
