Transcript Slides
Implementation Phase
Programming-in-the-many
Most real-life products are too large to be
implemented by one programmer
Implemented by a team
Working at the same time on different
components of the product
Testing/Module reuse/CASE tool
Implementation Phase
Fourth Generation Languages (4GL)
1GL: a binary machine code
2GL: assemblers (1940-50s)
3GL: high level languages (FORTRAN,
ALGOL 60, COBOL, etc)
4GL: DB2, Oracle, PowerBuilder, SQL
(1970s)
shorter (30-50 MCI),
easier to maintain/use,
CASE Tool: more productive, cost effective
Implementation Phase
Good Programming Practice
Use of consistent and meaningful identifier
names
Self-documenting code/documentation
Use of Parameters
Code layout for increased readability
Coding style for incremental programming
(Module reuse)
Implementation Phase
(Types of Errors)
Syntax Errors
Logic/Algorithm Errors
Branching too soon/ too late
Testing the wrong condition
Initialization errors
Data type mismatch
Incorrect formula or computation
Documentation Errors - mismatch between
documentation and code; leads to difficulties
especially during maintenance
Implementation Phase
(Types of Errors)
Capacity Errors - system performance
degradation at capacity
Hardware Errors
Throughput/performance Errors
Computation/precision Errors
Stress/overload Errors
Recovery Errors - error handling faults
Standards/Procedures - created/introduced as
the system is tested & modified
Implementation Phase
(Testing Principles)
Process of finding errors
Impossible to completely test software
Creativity and hard work required
Error prevention
Independent testers
Implementation Phase
(Testing Steps)
Select what is to be measured by the test and
decide how the code will be tested
Develop the test cases for the code and
determine the correct results for the test cases
Execute the test cases and compare the actual
results with the expected results
Regression Testing -If errors are discovered,
earlier test cases should be re-executed.
Black-box Testing
focused on inputs and outputs of a module:
equivalence partitioning, equivalence class
contains similar test cases (reduce redundancy)
equivalence Testing & Boundary Value Analysis
If valid input is a range of values, there are a
minimum of three equivalence classes: one below
the range, one within the range, and one above the
range
If valid input is a value from a discrete set of
values, there are two equivalence classes: valid,
discrete values and any other input values.
Black-box Testing
Functional Testing
demonstrate that all functions work according to
requirements and specification document
determining all the functions of the module
test data are devised to test each function
separately
If the module consists of a hierarchy of lower-level
functions, functional testing proceeds recursively.
OSBERT OGLES BY CASE STUDY (13.16)