Damian Gordon

Requirements testing tools

Static analysis tools

Test design tools

Test data preparation tools

Test running tools - character-based, GUI

Comparison tools

Test harnesses and drivers

Performance test tools

Dynamic analysis tools

Debugging tools

Test management tools

Coverage measurement

Staticanalysis

Test management tools

Test design

Test data preparation

Coveragemeasures

Test running

Dynamicanalysis

Debug

Performancemeasurement

Comp. Test

Req Anal

Code

Function

Design

Sys Test

Int Test

Acc Test

Requirementstesting

Test harness& drivers

Comparison

Automated support for verification and validation of requirements models◦ consistency checking◦ animation

Provide information about the quality of software

Code is examined, not executed Objective measures

◦ cyclomatic complexity◦ others: nesting levels, size

Generate test inputs◦ from a formal specification or CASE repository◦ from code (e.g. code not covered yet)

Data manipulation◦ selected from existing databases or files◦ created according to some rules◦ edited from other sources

Interface to the software being tested Run tests as though run by a human tester Test scripts in a programmable language Data, test inputs and expected results held in

test repositories Most often used to automate regression testing

Character-based◦ simulates user interaction from dumb terminals◦ capture keystrokes and screen responses

GUI (Graphical User Interface)◦ simulates user interaction for WIMP applications

(Windows, Icons, Mouse, Pointer)◦ capture mouse movement, button clicks, and

keyboard inputs◦ capture screens, bitmaps, characters, object states

Detect differences between actual test results and expected results◦ screens, characters, bitmaps◦ masking and filtering

Test running tools normally include comparison capability

Stand-alone comparison tools for files or databases

Used to exercise software which does not have a user interface (yet)

Used to run groups of automated tests or comparisons

Often custom-build Simulators (where testing in real environment

would be too costly or dangerous)

Load generation◦ drive application via user interface or test harness◦ simulates realistic load on the system & logs the

number of transactions Transaction measurement

◦ response times for selected transactions via user interface

Reports based on logs, graphs of load versus response times

Provide run-time information on software (while tests are run)◦ allocation, use and de-allocation of resources, e.g.

memory leaks◦ flag unassigned pointers or pointer arithmetic faults

Used by programmers when investigating, fixing and testing faults

Used to reproduce faults and examine program execution in detail◦ single-stepping◦ breakpoints or watchpoints at any statement◦ examine contents of variables and other data

Management of testware: test plans, specifications, results

Project management of the test process, e.g. estimation, schedule tests, log results

Incident management tools (may include workflow facilities to track allocation, correction and retesting)

Traceability (of tests to requirements, designs)

Objective measure of what parts of the software structure was executed by tests

Code is instrumented in a static analysis pass Tests are run through the instrumented code Tool reports what has and has not been covered

by those tests, line by line and summary statistics

Different types of coverage: statement, branch, condition, LCSAJ, et al

documents what the tester actually did◦ useful for capturing ad hoc tests (e.g. end users)◦ may enable software failures to be reproduced

produces a detailed “script”◦ records actual inputs◦ can be used by a technical person to implement a

more maintainable automated test ideal for one-off tasks

◦ such as long or complicated data entry

will not be very understandable◦ it is a programming language after all!◦ during maintenance will need to know more than can

ever be ‘automatically commented’ will not be resilient to many software changes

◦ a simple interface change can impact many scripts do not include verification

◦ may be easy to add a few simple screen based comparisons

If all tests arerobust, the

unexpectedchange is

missed

If all tests aresensitive, they

all show theunexpected change

Three tests,each changesa different field

Unexpectedchange occursfor every test

Test output

there are many choices to be made◦ dynamic / post execution, compare lots / compare

little, resilience to change / bug finding effective scripts can soon become very complex

◦ more susceptible to change, harder to maintain there is a lot of work involved

◦ speed and accuracy of tool use is very important usually there is more verification that can

(and perhaps should) be done◦ automation can lead to better testing (not

guaranteed!)

The effort required to automate any one test varies greatly◦ typically between 2 and 10 times the manual test effort

and depends on:◦ tool, skills, environment and software under test◦ existing manual test process which may be:

unscripted manual testing scripted (vague) manual testing scripted (detailed) manual testing

Step 4: checkit worked OK

“Try this”“Try that”

“What about ...”“What if ...”

Step 3: enter the inputsStep 2: thinkup specific

inputs

Step 1: identifyconditionsto test

WizzoComputer

WizzoComputer

Step Input Expected Result Pass1 Run up Scribble Document menu displayed2 Open file with sorted list Menus displayed3 Select Add items to List Item box displayed4 Add some items to List Items added in order5 Move an item Item moved, list is unsorted6 Add an item Item added at end of List7 Delete item from List Item deleted8 Delete item not in List Error message displayed

9 Save changes in new file New file created

Step 4: checkit worked OK

Step 3: enter the inputsStep 2: thinkup specific

inputs

Step 1: readwhat to do

Step Input Expected Result Pass 1 Run up Scribble Document menu displayed 2 Open file with sorted list Menus displayed 3 Select Add items to List Item box displayed 4 Add two items to List Items added in order 5 Move an item Item moved, list is unsorted

6 Add an item Item added at end of List

7 Delete item from List Item deleted

8 Delete item not in List Error message displayed

9 Save changes in new file New file created

WizzoComputer

Step Input Expected Result Pass1 Double click “Scribble”

icon.Scribble opened, List menudisabled.

2 Click on “File” menu. File menu appears, optionsenabled: Open, New, Exit.

3 Click on “Open” option. “Open” dialogue box listsdocument "countries.dcm" incurrent folder.

4 Select “countries.dcm”and click OK button.

“Open” dialogue boxremoved, file “countries.dcm”opened and displayed. Listmenu enabled.

Step 3: checkit worked OK

Step 2: enter the inputs

Step 1: readwhat to do

as the test suite grows ever larger, so do the maintenance costs◦ maintenance effort is cumulative, benefits are not

the test suite takes on a life of its own◦ testers depart, others arrive, test suite grows larger

nobody knows exactly what they all do … dare not throw away tests in case they’re important

inappropriate tests are automated◦ automation becomes an end in itself

keep pruning◦ remove dead-wood: redundant, superceded,

duplicated, worn-out◦ challenge new additions (what’s the benefit?)

measure costs & benefits◦ maintenance costs◦ time or effort saved, faults found?

commit and maintain resources◦ “champion” to promote automation◦ technical support◦ consultancy/advice

scripting◦ develop and maintain library◦ data driven approach, lots of re-use

run many times◦ regression tests◦ mundane

expensive to perform manually◦ time consuming and necessary◦ multi-user tests, endurance/reliability tests

difficult to perform manually◦ timing critical◦ complex / intricate

Automate

not run often◦ if no need (rather than expensive to run manually)◦ one off tests (unless several iterations likely and build

cost can be minimised) not important

◦ will not find serious problems usability tests

◦ do the colours look nice? some aspects of multi-media applications

Automate