|
-
-
TALC2000 test execution is powerful. Tests can run unattended or
at the direction of a tester sitting at the PC.
|
|
-
Preparing Test Cases for Execution
-
TALC2000 test case usage is based solely on the menu
concept. Each test case created is saved as part of a menu.
Linking test cases requires no more than point and click
selection of menus and point and click selection of test cases
from those menus in the order you wish the test cases to be
linked.
Individual test cases or complete test "Scripts" (more than
one test case linked together to be played back as a single
test) can be selected for re-run from any TALC2000
"Menu".
A "Script" can contain individual test cases from multiple
"Menus", and can call other scripts. Although most of your scripts
(probably at least 90%) will be little more than lists of test
cases to be run, scripts can also contain variables, branches,
loops, various "if" conditions and so on. Values returned from
test cases can be used to control script flow, and special API
functions can be called at any time. In short, although script
creation is extremely simple it also provides the power required to
run the most complex tests.
TALC2000 is exceptionally easy to use to create various
testing scenarios using recorded test cases. This
functionality is the fundamental reason that testers don't
require programming skills. It is also core to the design
philosophy of the product where experience has shown that
business users and analysts need to be heavily involved in
the testing process, and need a tool that they can use without
needing to acquire programming skills.
|
|
|
-
Start test runs automatically
-
Test playback can be started manually, at a preset time, or even following receipt of a
message from the host.
|
|
|
-
Automatically adjusts to Host response times
-
Test playback speed is automatically synchronized to varying
host application response times. There is no need to add
special "wait" steps.
Maximum playback speed is determined by host performance, but is
usually about four times faster than a skilled human operator.
|
|
|
-
Real time test verification
-
TALC2000 verifies test case output in real time, so that test
progress can be controlled based on results to date. However,
all test output is also saved for later offline verification and
analysis.
Because TALC2000 saves all host application data as
character and attribute streams (instead of bitmaps) and
compresses this data, storing the results requires little disk
space. A typical application screen image, including all
attribute data, usually requires less than 1000 bytes of
storage.
|
|
|
-
Unattended test execution
-
You will probably want to run most major tests unattended,
often overnight. Offline validation and error documentation
can then be performed next day with absolutely no loss of
information.
Where errors are identified they are automatically logged,
and the tester can add notes and application output (control
and test) to a report destined for the programming team
responsible for the technical work. The level of
documentation available assists greatly in overcoming
(human) communication problems, and reduces the level of
rework likely to be required.
|
|
|
-
"Event" Management
-
TALC2000 provides Event/Action lists which give you the
power to control what happens during test playback based on
output generated by the system under test.
Adding an event is very simple and is all menu driven,
primarily point and click.
Control is achieved by watching for the occurrence or removal of a
nominated string of characters, such as an application error
message, somewhere on the screen. When detected the test
case playback operation is suspended while the appropriate
defined action is completed. Actions can be many things
including inserting additional key strokes, running special
procedures or stopping or starting or re-starting playback etc.
Up to 50 "events" and "actions" can be associated with a
single test case. Events and actions can be nested so that an
action taken may generate another event which will then be
processed.
An example of how this might be used another way is to
have an event which may be a system broadcast message
which advises all terminals logged on that the test database
has been reset, the associated action could be to increment
the base date used for testing and run the test again. In this
way you could have various test scripts running depending
on messages sent to each testing terminal.
|
|
|
 TALC2000 Showase List
Validation & Reporting
|
