Dr. Pedro Mejia Alvarez Software Testing Slide 1 Software Testing: Building Test Cases.

Dr. Pedro Mejia Alvarez Software Testing Slide 1

Software Testing: Building Test Cases


Topics covered

Software Testing Process Software Testability Test Cases Black box testing Search and Sort Cases Debuging the application

Dr. Pedro Mejia Alvarez Software Testing Slide 3Introduction to Software Testing, 3

Fault Detection: “Waiting” or causing (or finding) for the error or failure to ocurr.Fault Location: Finding where the fault(s) ocurred, its causes and its consequences.Fault Recovery: Fixing the fault and NOT causing others.Regresion Testing: Testing the software again with the same data that caused the original fault

Dynamics of Faults


Software inspections. Concerned with analysis of the static system representation to discover problems (static verification)• May be supplement by tool-based document and code

analysis Software Testing. Concerned with exercising and

observing product behaviour (dynamic verification)• The system is executed with test data and its operational

behaviour is observed.• Used to Detect Faults.

Software Debugging. Concerned with finding and removing the faults.

Fault Tolerance. If faults still ocurr during operation: detect, remove and recover the system from faults.

Static and dynamic verification


The Software Testing process

Design testcases

Prepare testdata

Run programwith test data

Compare resultsto test cases

Testcases

Testdata

Testresults

Testreports


Software Testability

Plainly speaking – how hard it is to find faults in the software

Testability is determined by two practical problems• How to provide the test values to the software• How to observe the results of test execution

The degree to which a system or component The degree to which a system or component facilitates the establishment of test criteria and facilitates the establishment of test criteria and the performance of tests to determine whether the performance of tests to determine whether

those criteria have been metthose criteria have been met


Observability and Controllability

ObservabilityObservability

• Software that affects hardware devices, databases, or remote files have low observability

ControllabilityControllability

• Easy to control software with inputs from keyboards• Inputs from hardware sensors or distributed software is harder

Data abstraction reduces controllability and observability

How easy it is to observe the behavior of a program in terms of its outputs, How easy it is to observe the behavior of a program in terms of its outputs, effects on the environment and other hardware and software componentseffects on the environment and other hardware and software components

How easy it is to provide a program with the needed inputs, in terms of How easy it is to provide a program with the needed inputs, in terms of values, operations, and behaviorsvalues, operations, and behaviors


Components of a Test Case

A test case is a multipart artifact with a definite structure

Test case valuesTest case values

Expected resultsExpected results

The result that will be produced when The result that will be produced when executing the test if the program satisfies it executing the test if the program satisfies it

intended behaviorintended behavior

The values that directly satisfy one test The values that directly satisfy one test requirementrequirement


Affecting Controllability and Observability PreconditionsPreconditions

PostconditionsPostconditions

1. Verification Values : Values needed to see the results of the test case values

2. Exit Commands : Values needed to terminate the program or otherwise return it to a stable state

Executable test scriptExecutable test script

Any conditions that must be observed after executing the software

Any conditions necessary for the correct execution of the software

A test case that is prepared in a form to be executed automatically on the test software and produce a report


Search• Binary Search• Interpolation Search

Sort • Heap Sort• Merge Sort.

Algorithms to Test


Black Box Testing.

Study the algorithmsProgramming.Pre-conditions & Post-Conditions of each algorithm.Develop Test Cases.Develop Oracle. Run the test.Record Inputs and Outputs.Record Invalid OutputsIf invalid Outputs or Execution Errors then: Debug the program: Finding the fault.

Testing the algorithms


Test case design

Involves designing the test cases (inputs and outputs) used to test the system.

The goal of test case design is to create a set of tests that are effective in validation and defect testing.

Design approaches:• Black Box Testing: Partition testing;• White Box Testing:

• Structural testing.• Criteria based on Structures.


Black-box testing

IeInput test data

OeOutput test results

System

Inputs causinganomalousbehaviour

Outputs which revealthe presence ofdefects


Equivalence partitioning

System

Outputs

Invalid inputs Valid inputs

Oracle

Test Data Generation

Valid/ Invalid Output

Random Number Generation


Testing guidelines

Testing guidelines are hints for the testing team to help them choose tests that will reveal defects in the system• Choose inputs that force the system to generate valid

outputs;• Choose inputs that force the system to generate faults

(invalid outputs);• Check if valid inputs generate invalid outputs.• Check if invalid outputs generate valid outputs.• Design inputs that cause buffers to overflow;• Repeat the same input or input series several times;• Force computation results to be too large or too small.


Partition testing

Input data and output results often fall into different classes where all members of a class are related.

Each of these classes is an equivalence partition or domain where the program behaves in an equivalent way for each class member.

Test cases should be chosen from each partition.


Search routine - input partitions


Sort Routine – Partitions

Sequences: Array of 1,000 elements

Sort an array with all elements not sorted. Sort an array with all elements sorted. Sort an array with many equal elements.

Oracle: Simple: Check that first element in array is less or equal than

next. Check how many elements are not correctly sorted. Check what input makes out to be incorrect.


Defect testing and debugging are distinct processes.

Verification and validation is concerned with establishing the existence of defects in a program.

Debugging is concerned with locating and repairing these errors.

Debugging involves formulating a hypothesis about program behaviour then testing these hypotheses to find the system error.

Testing and debugging


The debugging process

Locateerror

Designerror repair

Repairerror

Retestprogram

Testresults

Specification Testcases


Debugging

What can debuggers do?

Run programs Make the program stops on specified places or on specified

conditions Give information about current variables’ values, the memory and

the stack Let you examine the program execution step by step - stepping Let you examine the change of program variables’ values - tracing

! To be able to debug your program, you must compile it with the -g option (creates the symbol table) !CC –g my_prog


GDB – Running Programs

Running a program: run (or r) -- creates an inferior process that runs your program.

if there are no execution errors the program will finish and results will be displayed

in case of error, the GDB will show:- the line the program has stopped on and - a short description of what it believes has caused the error


Test automation

Testing is an expensive process phase. Testing workbenches provide a range of tools to reduce the time required and total testing costs.

Systems such as Junit support the automatic execution of tests.

Most testing workbenches are open systems because testing needs are organisation-specific.

They are sometimes difficult to integrate with closed design and analysis workbenches.


A testing workbench

Dynamicanalyser

Programbeing tested

Test resultsTest

predictions

Filecomparator

Executionreport

Simulator

Sourcecode

Testmanager

Test data Oracle

Test datagenerator

Specification

Reportgenerator

Test resultsreport


What do we need to improve testing?

Run programs

Dr. Pedro Mejia Alvarez Software Testing Slide 1 Software Testing: Building Test Cases.

Documents

Transcript of Dr. Pedro Mejia Alvarez Software Testing Slide 1 Software Testing: Building Test Cases.