software engineering week 5

MADALINA [email protected]

Software Engineeringweek 5

Madalina CroitoruIUT Montpellier

Software design

• Computer programs are composed of multiple, interacting modules

• The goal of system design is to:– Decide what the modules are– Decide what the modules should contain– Decide how the modules should interact


Criteria for design


Five principles for good design

• Linguistic modular units• Few interfaces• Small interfaces• Explicit interfaces• Information hiding



Waterfall model

Testing

“Program testing can be used to show

the presence of defects, but never their

absence”Edsger W.

Dijkstra


Testing

• Critically important for quality software

• Industry averages:– 30-85 errors per 1000 lines of code– 0.5 – 3 errors per 1000 lines of code

NOT detected before delivery

• The ability to test a system depends on a good, detailed requirements document


Errors

• Errors in the programs could be either:

– Compile time (syntax errors, etc.): cheap to fix

– Run-time (logical errors): expensive to fix


Systematic about testing

• Analogy: scientific experiment, in chemistry– To find out whether some process works– Need to state the expected result before

the experiment– Must know the precise conditions under

which the experiment runs– The experiment must be repeatable


What about the goal of testing?

• What to measure?• Achieve an acceptable level of

confidence that the system behaves correctly under all circumstances of interest

• What– … is a level of confidence?– … is correct behavior?– … are circumstances of interest?


Testing strategies

• Never possible for the designer to anticipate EVERY use of the system

• Offline strategies:– Syntax checking– Dry runs / Inspections / Reviews

• Online strategies:– Black box testing– White box testing


Syntax checking

• Detecting errors at compile time is preferable to having them occur at run time

• Syntax checking• Programs doing deeper tests:

– This line never gets executed– This variable does not get initialised(Java compiler: warnings)


Inspection / Review

• Review– informal

• …• Inspection

– formal


Why review?

• Everyone makes mistakes• Programming is a social activity (or

should be)• Find errors in program early (before it

is run the first time)• Improve programming skills of all

involved• Anything can be reviewed (…, use

cases, documentation, …) MADALINA CROITORU

[email protected]

How to hold a review meeting?

• Purpose: evaluate a software product to

– determine its suitability for its intended use

– identify discrepancies from specifications and standards

• Participants read documents in advance

– then bring their comments to a meeting for discussion

• A review

– may provide recommendations and suggest alternatives

– may be held at any time during a project

– need not reach conclusions on all points


What should not happen in a review?

• Improvements to the program• Blaming programmers• Finger pointing


More formal: inspection

• Idea behind inspection: Michael Fagan (IBM, 1976)

• Purpose: detect and identify software product anomalies by systematic peer evaluation

• The inspection leader is not the author

– is a trained “moderator”

– organizes the selection of inspectors

– distributes the documents

– leads the meeting

– ensures all follow up actions are taken


How to inspect?

• Set an agenda and maintain it• Limit debate and rebuttal• Do not attempt to solve every problem

noted• Take written notes• Insist on advance preparation• Conduct meaningful training for all

participants• Inspect your earlier inspections


Dry runs

• A team of programmers mentally execute the code using simple test data

• Expensive in terms of human resources

• Impossible for a lot of systems


Black box testing

• We ignore the internals of the system and focus on the RELATIONSHIP between inputs and outputs

• Exhaustive testing would mean examining output of system for every conceivable input – not practical

• Use equivalence partitioning and boundary analysis


Black Box Testing

• Examines all functions and compares actual to expected result

• Typically used in later testing stages– System tests– Acceptance tests

int binsearch (int[] a, int v) { int low = 0; int high = length - 1 while (low <= high) { int mid = (low + high) / 2; if (a[mid] > value) high = mid – 1; else if (a[mid] < value) low = mid + 1; else return mid; } return -1; }

“array search”Input:int array aint vOutput:index of v in a or-1 if v not in a


Equivalence partitioning

• Let us say the system asks for a number between 100 and 999

• Three equivalence classes of input:– Less than 100– 100 to 999– Greater than 999


Boundary Analysis

• Most programs fail at input boundaries

• The system asks for a number between 100 and 999 inclusive

• The boundaries are 100 and 999• We then use the values:99 100 101 998 999

1000


White box testing

• We use the knowledge of the internal structure of systems to guide development of tests

• Examine every possible run of a system

• If not possible, aim to test every statement at least once


White Box Testing

• Examines paths and decisions by looking inside the program

• Typically used in early testing stages– Unit tests– Integration tests

int binsearch (int[] a, int v) { int low = 0; int high = length – 1; while (low <= high) { int mid = (low + high) / 2; if (a[mid] > value) high = mid – 1; else if (a[mid] < value) low = mid + 1; else return mid; } return – 1; }


Testing plans

• Rigorous test plans have to be devised

• Generated usually from requirements analysis document (for black box) and program code (for white box)

• Distinguish between:– Unit tests– Integration tests– System tests


Alpha and beta testing

• In-house testing is called alpha testing

• Beta testing involves distributed TESTED code to prospective customers for evaluation and use

• Delivering buggy beta code is embarrassing


software engineering week 5

Documents

checkingdetecting errors

befind errors

compile time syntax

fixruntime logical errors

experiment runsthe experiment

scientific experiment

modules aredecide

goal of testing