Program Development.

1
Program Development.

• This includes
• testing a program
• proving a program correct
• debugging a program
• testing a program involves supplying data to
  the program and observing the results. It is
  carried out OUTSIDE the program (or procedure).
• proving a program correct involves study of the
  code and input and output conditions. It is
  carried out INSIDE the program.

2
Thoroughness of Testing

• A successful test establishes the presence of
  errors for one set of conditions.
• The problem is to produce test data which
  exhibits all possible behaviours of the program
  being tested.
• Black-Box Testing
• Equivalence partitioning.
• Functional testing.
• Mutation testing.
• Glass-Box Testing
• Statement Testing.
• Branch Testing.
• Path Testing.

3
Equivalence Partitioning.

• e.g. specifications for a database product state
  that it must be able to handle any number of
  records from 1 to 16,383.
• This leads to 3 equivalence classes.
• equivalence class 1 less than 1 record.
• equivalence class 2 from 1 to 16383 records.
• equivalence class 3 more than 16383 records.
• This might be tested for 0, 1, 2, 732, 16382,
  16383 and 16384 records. What results do you
  expect for each of these values ?

4
Example of Equivalence Partitioning.

• Consider a program which classifies triangles.
• Input 3 integers (giving the lengths of the
  sides).
• Determine the type of the triangle e.g.
• equilateral (output E) all sides equal.
• isosceles (output I) 2 sides equal.
• scalene (output S) no sides equal.
• right-angled (output R).
• add output N to indicate non-triangle
• exactly 3 values are required, all integers and
  all gt0.

5
Example Continued

• Possible errors
• fewer than 3 values are read in.
• one or more of the numbers non-integer.
• one or more of the numbers lt 0.
• longest side p gt sum of other 2 sides.
• N indicates any of these errors.
• Test cases are needed to check the program
  responds correctly to each of these situations.

6
Equivalence Partitioning

• Less than 3 numbers input.
• One, two or three numbers non-integer.
• One, two or three numbers negative.
• p gt sum of other two numbers.
• Choose examples in each set and check that the
  program gives the expected result.
• Assume that if the program is correct for one
  example in the class of input, it will be so for
  all members of that equivalence class.
• Typically an input condition is either a numeric
  value, a range of values, a set of related values
  or a Boolean condition.

7
Guidelines for equivalence Classes.

• input condition range 1 valid 2 invalid
  classes.
• input condition value 1 valid 2 invalid
  classes.
• input condition member of a set 1 valid 1
  invalid class.
• input condition Boolean 1 valid 1 invalid
  class.
• Also have equivalence classes for output.
• It has been noticed that more errors occur near
  the boundaries of these classes. Hence the
  development of boundary value analysis.

8
Boundary Value Analysis.

• (a) input condition specifies range bounded by
  values a and b. Design test cases to use values
  a and b and values close to them (both greater
  and smaller).
• (b) input condition specifies a number of values.
  Design test cases to use the maximum and minimum
  values and others close to them.
• (c) apply these guidelines to output conditions.
  e.g if a table of values is one output, design
  test data to generate the maximum and minimum
  number of entries in the table.
• (d) if internal program data structures have
  prescribed boundaries, ensure that the boundaries
  are tested.

9
Testing Principles.

• 1 Design test cases with the object of
  uncovering errors in the software.
• 2 Design tests systematically. Do not rely on
  intuition.
• 3 Establish a testing strategy that begins at
  the module level.
• 4 Record all testing results and save test cases
  for reapplication during software maintenance.
• Bugs lurk in corners and congregate at
  boundaries.

10
Functional Testing

• Functional testing focusses on the functionality
  of the program.
• Each of the functions implemented in the module
  is identified.
• Test data are defined to test each function
  separately.
• At this stage, the internal workings of the
  module are not considered.

11
Mutation Testing. (not needed for your
exercises).

• 1 the program is run with one particular set of
  data.
• 2 some parts of the program are altered and then
  the program is run again with the same set of
  data.
• This is intended to test the adequacy of the
  testing procedures and test cases.
• Set of mutant operators is defined e.g.
• change an addition to subtraction.
• exchange two variables.
• add unity to an arithmetic expression.
• change gt to lt

12
Glass Box Testing.

• Statement Testing ensure that every statement in
  the program is executed at least once.
• Branch Testing for every decision point in the
  program, ensure that each branch is chosen at
  least once.
• Path Testing Ensure that every distinct path
  through the program is executed at least once.
• You will need to apply glass-box testing to your
  program segments and document the results.

13
Work for Next Week

• Consider the modules in your current programming
  exercise, or the module issued as an example.
• For each module, produce a detailed testing
  scheme, using both black-box and glass-box
  methods.
• Hand in your documentation, program listing and
  testing strategy for ONE module.
• Apply the testing strategy to all modules as part
  of the workshop.

14
Functional Cohesion.

• A measure of the strength of the association of
  the elements within a module.
• Functional Cohesion every function within the
  module contributes directly to performing one
  single task.
• This means that a module which performs exactly
  one action or achieves a single goal has
  functional cohesion. e.g. push a value onto a
  stack or set a 4-letter code.
• Such a module can be fully tested, re-used in
  many contexts and is easy to maintain or extend.

15
Informational Cohesion.

• All actions in the module refer to the same data
  structure.
• There are several sections of code, all
  independent and each with exactly one entry point
  and one exit point.
• Since the module contains several independent
  pieces of code, it does not have functional
  cohesion. However the fact that all the
  independent sections refer to the same data
  structure gives it informational cohesion.

16
Communicational Cohesion.

• A module has communicational cohesion if it
  performs a series of actions -
• These actions are related by the sequnce of steps
  to be followed by the program -
• and, in addition, if these actions are all
  performed on the same data.

17
Procedural Cohesion.

• A module has procedural cohesion if it performs a
  series of actions related by a sequence of steps
  in a program.
• In such a module the processing elements must
  be related and they must be executed in a
  specific order.
• This implies the presence of a strong control
  structure.

18
Temporal Cohesion.

• A set of functions related in time.
• e.g. an initialisation module to be executed at
  the begining of a program.
• The only connection between these functions may
  be that they are carried out at the start of the
  program.
• It may be possible to replace one initialisation
  module which has only temporal cohesion with 2 or
  3 others which also have functional or
  informational cohesion as well. This will be much
  easier to understand, re-use or maintain.

19
Logical Cohesion.

• This contains a set of logically related
  functions.
• e.g. all input and output functions, all
  graphics, all operations relating to a particular
  file of data.
• Problems arising from this interface is
  difficult to understand, there is too much
  intertwining and hence it is difficult to re-use.
  
• With logical cohesion, the actions are
  intertwined, whereas with informational cohesion
  each section of code is completely independent.

20
Coincidental Cohesion.

• There is no significant relations ship between
  the component parts of the module. They are
  grouped together only by coincidence.
• This is evidence of a lack of design in splitting
  the program into modules. e.g. if the first 20
  statements are placed in one module, the next 20
  in another and so on, it is unlikely that such an
  arbitrary division would correspond to any
  underlying program logic.
• This should be avoided. Even if such modularity
  still works correctly (one must assume the
  division did not split a loop), it will be hard
  to understand or re-use.

21
Use of Cohesion.

• Software of a reasonable size is likely to
  contain modules of several different levels of
  cohesion.
• This is not important - the important thing is to
  strive for high cohesion (especially functional
  cohesion) wherever possible.
• Give the procedure a meaningful name and write a
  sentence saying what it does. Functional cohesion
  will correspond to a short, simple sentence.
• If this is a compound sentence, then it probably
  performs more than one function and may have
  procedural or communicational cohesion.
• If it contains words relating to time, then it
  probably has procedural or temporal cohesion.

22
Coupling.

• Coupling is the interdependence between software
  modules.
• Cohesion was the degree of interaction within a
  module and is something we wish to maximise.
• Coupling is the degree of interaction between
  modules and is something we wish to minimise.
• The higher the degree of coupling, the more
  likely is the ripple effect where changes
  inside one module affect the proper fucntioning
  of another module.
• It also makes the module impossible to understand
  in isolation - we must have listings of both
  modules to understand what is going on.