Software Engineering week 5
-
Upload
ulric-wells -
Category
Documents
-
view
25 -
download
0
description
Transcript of Software Engineering week 5
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
MADALINA [email protected]
Criteria for design
MADALINA [email protected]
Five principles for good design
• Linguistic modular units• Few interfaces• Small interfaces• Explicit interfaces• Information hiding
MADALINA [email protected]
MADALINA [email protected]
Waterfall model
Testing
“Program testing can be used to show
the presence of defects, but never their
absence”Edsger W.
Dijkstra
MADALINA [email protected]
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
MADALINA [email protected]
Errors
• Errors in the programs could be either:
– Compile time (syntax errors, etc.): cheap to fix
– Run-time (logical errors): expensive to fix
MADALINA [email protected]
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
MADALINA [email protected]
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?
MADALINA [email protected]
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
MADALINA [email protected]
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)
MADALINA [email protected]
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
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
MADALINA [email protected]
What should not happen in a review?
• Improvements to the program• Blaming programmers• Finger pointing
MADALINA [email protected]
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
MADALINA [email protected]
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
MADALINA [email protected]
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
MADALINA [email protected]
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
MADALINA [email protected]
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
MADALINA [email protected]
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
MADALINA [email protected]
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
MADALINA [email protected]
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
MADALINA [email protected]
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; }
MADALINA [email protected]
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
MADALINA [email protected]
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
MADALINA [email protected]