particular review process or type of review being done

Modelling tools (D)
Modelling tools help to validate models of the system or software. For example a
tool can check consistency of data objects in a database and can find inconsistencies
and defects. These may be difficult to pick up in testing
– you may have tested with
one data item and not realize that in another part of the database there is conflicting
information related to that item. Modelling tools can also check state models or
object models.
Modelling tools are typically used by developers and can help in the design of the
software.
One strong advantage of both modelling tools and static analysis tools is that they
can be used before dynamic tests can be run. This enables any defects that these
tools can find to be identified as early as possible, when it is easier and cheaper to
fix them. There are also fewer defects left to propagate into later stages, so devel-
opment can be speeded up and there is less rework. (Of course this is difficult to
show, since those defects aren
’t there now!)
Note that
‘model-based testing tools’ are actually tools that generate test inputs or
test cases from stored information about a particular model (e.g. a state diagram), so
are classified as test design tools (see Section 6.1.5).
Features or characteristics of modelling tools include support for:
l
identifying inconsistencies and defects within the model;
l
helping to identify and prioritize areas of the model for testing;
l
predicting system response and behaviour under various situations, such as
level of load;
l
helping to understand system functions and identify test conditions using a
modelling language such as UML.
6.1.5 Tool support for test specification
The tools described in this section support the testing activities described in
Chapter 4.
Test design tools
Test design tools help to construct test cases, or at least test inputs (which is part of
a test case). If an automated oracle is available, then the tool can also construct the
expected result, so it can actually generate test cases (rather than just test inputs).
For example, if the requirements are kept in a requirements management or test
management tool, then it is possible to identify the input fields, including the range
of valid values. This range information can be used to identify boundary values and
equivalence partitions. If the valid range is stored, the tool can distinguish between
values that should be accepted and those that should generate an error message. If
the error messages are stored, then the expected result can be checked in detail. If
the expected result of the input of a valid value is known, then that expected result
can also be included in the test case constructed by the test design tool.
Another type of test design tool is one that helps to select combinations of
possible factors to be used in testing, to ensure that all pairs of combinations of
operating system and browser are tested, for example. Some of these tools may use
orthogonal arrays. See [Copeland 2003] for a description of these combination
techniques.
Modelling tool A tool
that supports the
creation, amendment
and verification of
models of the software
or system.
Test design tool A tool
that supports the test
design activity by
generating test inputs
from a specification that
may be held in a CASE
tool repository, e.g.
requirements
management tool, from
specified test conditions
held in the tool itself, or
from code.
Section 1 Types of Test Tool 167

Note that the test design tool may have only a partial oracle
– that is, it may know
which input values are to be accepted and rejected, but it may not know the exact
error message or resulting calculation for the expected result of the test. Thus the test
design tool can help us to get started with test design and will identify all of the
fields, but it will not do the whole job of test design for us
– there will be more
verification that may need to be done.
Another type of test design tool is sometimes called a
‘screen scraper’, a
structured template or a test frame. The tool looks at a window of the graphical
user interface and identifies all of the buttons, lists and input fields, and can set up a
test for each thing that it finds. This means that every button will be clicked for
example and every list box will be selected. This is a good start for a thorough set of
tests and it can quickly and easily identify non-working buttons. However, unless
the tool has access to an oracle, it may not know what should actually happen as a
result of the button click.
Yet another type of test design tool may be bundled with a coverage tool. If a
coverage tool has identified which branches have been covered by a set of
existing tests for example, it can also identify the path that needs to be taken in
order to cover the untested branches. By identifying which of the previous
decision outcomes need to be True or False, the tool can calculate an input value
that will cause execution to take a particular path in order to increase coverage.
Here the test is being designed from the code itself. In this case the presence of an
oracle is less likely, so it may only be the test inputs that are constructed by the
test design tool.
Features or characteristics of test design tools include support for:
l
generating test input values from:
– requirements;
– design models (state, data or object);
– code;
– graphical user interfaces;
– test conditions;
l
generating expected results, if an oracle is available to the tool.
The benefit of this type of tool is that it can easily and quickly identify the tests
(or test inputs) that will exercise all of elements, e.g. input fields, buttons, branches.
This helps the testing to be more thorough (if that is an objective of the test!)
Then we may have the problem of having too many tests and need to find a way
of identifying the most important tests to run. Cutting down an unmanageable
number of tests can be done by risk analysis (see Chapter 5). Using a combination
technique such as orthogonal arrays can also help.
Test data preparation tools
Setting up test data can be a significant effort, especially if an extensive range or
volume of data is needed for testing. Test data preparation tools help in this area.
They may be used by developers, but they may also be used during system or
acceptance testing. They are particularly useful for performance and reliability
testing, where a large amount of realistic data is needed.
Test data preparation tools enable data to be selected from an existing database or
created, generated, manipulated and edited for use in tests. The most sophisticated
tools can deal with a range of files and database formats.
Test data preparation
tool A type of test tool
that enables data to be
selected from existing
databases or created,
generated, manipulated
and edited for use in
testing.
168
Chapter 6 Tool support for testing

Features or characteristics of test data preparation tools include support to:
l
extract selected data records from files or databases;
l
‘massage’ data records to make them anonymous or not able to be identified
with real people (for data protection);
l
enable records to be sorted or arranged in a different order;
l
generate new records populated with pseudo-random data, or data set up
according to some guidelines, e.g. an operational profile;
l
construct a large number of similar records from a template, to give a large set
of records for volume tests, for example.
6.1.6 Tool support for test execution and logging
Test execution tools
When people think of a
‘testing tool’, it is usually a test execution tool that they
have in mind, a tool that can run tests. This type of tool is also referred to as a
‘test
running tool
’. Most tools of this type offer a way to get started by capturing or
recording manual tests; hence they are also known as
‘capture/playback’ tools,
‘capture/replay’ tools or ‘record/playback’ tools. The analogy is with recording a
television programme, and playing it back. However, the tests are not something
which is played back just for someone to watch!
Test execution tools use a scripting language to drive the tool. The scripting
language is actually a programming language. So any tester who wishes to use a test
execution tool directly will need to use programming skills to create and modify the
scripts. The advantage of programmable scripting is that tests can repeat actions (in
loops) for different data values (i.e. test inputs), they can take different routes
depending on the outcome of a test (e.g. if a test fails, go to a different set of tests)
and they can be called from other scripts giving some structure to the set of tests.
When people first encounter a test execution tool, they tend to use it to
‘capture/
playback
’, which sounds really good when you first hear about it. However, the
approach breaks down when you try to replay the captured tests
– this approach does
not scale up for large numbers of tests as described in Section 6.2.3. The main
reason for this is that a captured script is very difficult to maintain because:
l
It is closely tied to the flow and interface presented by the GUI.
l
It may rely on the circumstances, state and context of the system at the time
the script was recorded. For example, a script will capture a new order number
assigned by the system when a test is recorded. When that test is played back,
the system will assign a different order number and reject subsequent requests
that contain the previously captured order number.
l
The test input information is
‘hard-coded’, i.e. it is embedded in the individual
script for each test.
Any of these things can be overcome by modifying the scripts, but then we are no
longer just recording and playing back! If it takes more time to update a captured
test than it would take to run the same test again manually, the scripts tend to be
abandoned and the tool becomes
‘shelf-ware’.
There are better ways to use test execution tools to make them work well and
actually deliver the benefits of unattended automated test running. There are at least five
test execution tool
A type of test tool that is
able to execute other
software using an
automated test script,
e.g. capture/playback.
Capture/playback tool
(capture/replay 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.
Section 1 Types of Test Tool 169

levels of scripting and also different comparison techniques. Data-driven scripting is an
advance over captured scripts but keyword-driven scripts give significantly more
benefits [Fewster and Graham 1999], [Buwalda et al. 2001]. [Mosley and Posey
2002] describe
‘control synchronized data-driven testing’. See also Section 6.2.3.
There are many different ways to use a test execution tool and the tools themselves
are continuing to gain new useful features. For example, a test execution tool can help
to identify the input fields that will form test inputs and may construct a table which is
the first step towards data-driven scripting.
Although they are commonly referred to as testing tools, they are often used for
regression testing, where tests are run that have been run before, such as in Contin-
uous Integration. One of the most significant benefits of using this type of tool is that
whenever an existing system is changed (e.g. for a defect fix or an enhancement), all
of the tests that were run earlier could potentially be run again, to make sure that the
changes have not disturbed the existing system by introducing or revealing a defect.
Features or characteristics of test execution tools include support for:
l
capturing (recording) test inputs while tests are executed manually;
l
storing an expected result in the form of a screen or object to compare to, the
next time the test is run;
l
executing tests from stored scripts and optionally data files accessed by the
script (if data-driven or keyword-driven scripting is used);
l
dynamic comparison (while the test is running) of screens, elements, links,
controls, objects and values;
l
ability to initiate post-execution comparison;
l
logging results of tests run (pass/fail, differences between expected and actual
results);
l
masking or filtering of subsets of actual and expected results, for example
excluding the screen-displayed current date and time which is not of interest
to a particular test;
l
measuring timings for tests;
l
synchronizing inputs with the application under test, e.g. wait until the
application is ready to accept the next input, or insert a fixed delay to
represent human interaction speed;
l
sending summary results to a test management tool.
Test harness/unit test framework tools (D)
These two types of tool are grouped together because they are variants of the type of
support needed by developers when testing individual components or units of software.
A test harness provides stubs and drivers, which are small programs that interact with
the software under test (e.g. for testing middle-ware and embedded software). See
Chapter 2 for more detail of how these are used in integration testing. Some unit test
framework tools provide support for object-oriented software, others for other devel-
opment paradigms. Unit test frameworks can be used in agile development to automate
tests in parallel with development. Both types of tool enable the developer to test,
identify and localize any defects. The framework or the stubs and drivers supply any
information needed by the software being tested (e.g. an input that would have come
from a user) and also receive any information sent by the software (e.g. a value to be
displayed on a screen). Stubs may also be referred to as
‘mock objects’.
Unit test framework
tool A tool that provides
an environment for unit
or component testing in
which a component can
be tested in isolation or
with suitable stubs and
drivers. It also provides
other support for the
developer, such as
debugging capabilities.
[Note: This is actually the
definition for unit test
framework. The term unit
test framework tool is not
defined in the ISTQB
Glossary.]
170
Chapter 6 Tool support for testing

Test harnesses or drivers may be developed in-house for particular systems.
Advice on designing test drivers can be found in [Hoffman and Strooper 1995].
There are a large number of
‘xUnit’ tools for different programming languages,
e.g. JUnit for Java, NUnit for .Net applications, etc. There are both commercial tools
and also open-source tools. Unit test framework tools are very similar to test execu-
tion tools, since they include facilities such as the ability to store test cases and
monitor whether tests pass or fail, for example. The main difference is that there is no
capture/playback facility and they tend to be used at a lower level, i.e. for component
or component integration testing, rather than for system or acceptance testing.
Features or characteristics of test harnesses and unit test framework tools include
support for:
l
supplying inputs to the software being tested;
l
receiving outputs generated by the software being tested;
l
executing a set of tests within the framework or using the test harness;
l
recording the pass/fail results of each test (framework tools);
l
storing tests (framework tools);
l
support for debugging (framework tools);
l
coverage measurement at code level (framework tools).
Test comparators
Is it really a test if you put some inputs into some software, but never look to see
whether the software produces the correct result? The essence of testing is to check
whether the software produces the correct result, and to do that, we must compare
what the software produces to what it should produce. A test comparator helps to
automate aspects of that comparison.
There are two ways in which actual results of a test can be compared to the
expected results for the test. Dynamic comparison is where the comparison is done
dynamically, i.e. while the test is executing. The other way is post-execution
comparison, where the comparison is performed after the test has finished executing
and the software under test is no longer running.
Test execution tools include the capability to perform dynamic comparison while
the tool is executing a test. This type of comparison is good for comparing the
wording of an error message that pops up on a screen with the correct wording for
that error message. Dynamic comparison is useful when an actual result does not
match the expected result in the middle of a test
– the tool can be programmed to
take some recovery action at this point or go to a different set of tests.
Post-execution comparison is usually best done by a separate tool (i.e. not the test
execution tool). This is the type of tool that we mean by a test comparator or test
comparison tool and is typically a ‘stand-alone’ tool. Operating systems normally
have file comparison tools available that can be used for post-execution comparison
and often a comparison tool will be developed in-house for comparing a particular
type of file or test result.
Post-execution comparison is best for comparing a large volume of data, such as
comparing the contents of an entire file with the expected contents of that file, or
comparing a large set of records from a database with the expected content of those
records. For example, comparing the result of a batch run (e.g. overnight processing
of the day
’s online transactions) is probably impossible to do without tool support.
Test comparator A test
tool to perform
automated test
comparison of actual
results with expected
results.
Test comparison The
process of identifying
differences between the
actual results produced
by the component or
system under test and the
expected results for a
test. Test comparison can
be performed during test
execution (dynamic
comparison) or after test
execution.
Section 1 Types of Test Tool 171

Whether a comparison is dynamic or post-execution, the test comparator needs
to know what the correct result is. This may be stored as part of the test case itself
or it may be computed using a test oracle. See Chapter 4 for information about test
oracles.
Features or characteristics of test comparators include support for:
l
dynamic comparison of transient events that occur during test execution;
l
post-execution comparison of stored data, e.g. in files or databases;
l
masking or filtering of subsets of actual and expected results.
Coverage measurement tools (D)
How thoroughly have you tested? Coverage tools can help answer this question.
A coverage tool first identifies the elements or coverage items that can be
counted, and where the tool can identify when a test has exercised that coverage
item. At component testing level, the coverage items could be lines of code or code
statements or decision outcomes (e.g. the True or False exit from an IF statement).
At component integration level, the coverage item may be a call to a function or
module. Although coverage can be measured at system or acceptance testing levels,
e.g. where the coverage item may be a requirement statement, there aren
’t many
(if any) commercial tools at this level; there is more tool support at component
testing level or to some extent at component integration level.
The process of identifying the coverage items at component test level is called
‘instrumenting the code’, as described in Chapter 4. A suite of tests is then run through
the instrumented code, either automatically using a test execution tool or manually. The
coverage tool then counts the number of coverage items that have been executed by the
test suite, and reports the percentage of coverage items that have been exercised, and
may also identify the items that have not yet been exercised (i.e. not yet tested).
Additional tests can then be run to increase coverage (the tool reports accumulated
coverage of all the tests run so far).
The more sophisticated coverage tools can provide support to help identify the
test inputs that will exercise the paths that include as-yet unexercised coverage items
(or link to a test design tool to identify the unexercised items). For example, if not
all decision outcomes have been exercised, the coverage tool can identify the

tải về 6.34 Mb.

Chia sẻ với bạn bè của bạn: