Transcript Software Development

Software Development
Chapter 4
Software Testing and Tools
Testing
►
Software testing involves a series of processes to verify that :
 The finished product meets the original specification
 The software is robust
 The software is reliable
Testing can only find errors in a program, not prove there are
none
► Testing should be systematic
► Test data needs to be planned and the test process needs to
record a test log
► The actual test data selected depends on the test strategy
used
►
Test Strategies
►
Recapping testing methods..




►
Module Testing, on all components
Integration Testing, where the components function as an entity
System Testing or Black Box Testing
Acceptance Testing or Beta Testing, ensuring that the system is ready
for operational use
Software testing is a complex and expensive issue
Test Approaches
► There are a number of different testing approaches:
By scope
By purpose
By life-cycle phase
Component testing
Correctness testing
Requirements testing
Module testing
Performance testing
Design testing
Integration testing
Reliability testing
Acceptance testing
System testing
Security testing
Maintenance testing
• Testing ‘by scope’ starts at the component level then proceeds
through each phase until the final system is tested as a whole
• Testing ‘by purpose’ entails the whole reason for testing. It makes sure
the program is correct and runs to the original specification
• Testing ‘by life-cycle’ phase include the final software development
test, acceptance testing where the software is sold to the client
Components
►
►
►
►
Components are sometimes called units
They are the building blocks of software applications
They are defined as pieces of software such as sub-routines or
procedures that can be compiled and executed on their own
A component will be the work of a single programmer and they will also
test the code at a basic, White Box, level
Component Testing
►
►
With White Box testing component code is seen and it is the
workings of the code that are tested
The component can be tested in Static or Dynamic mode
 In static mode the component does not require to be executed. A
detailed catalogue of reviews and inspections is compiled for each
module
► Inspections contain a precise framework for rigorously checking
component
documentation and code
 In dynamic testing the component program is executed using test values
for normal, extreme and exceptional cases
Modules
►
►
►
►
Modules are a collection of dependant components or procedures designed
to be part of the main program
They are not complete programs in themselves, they can not run
independently
It often happens that a module becomes ready for testing before the main
program. It is common practice to write a small program, called a Driver or
Test-Harness to run the module and supply it with test data
Driver programs are commercially available
Stubs
►
►
►
►
A stub is a module that has the appropriate interface but does not contain a
lot of code
It might contain no more than a line of code to display what the module will
do when its complete
The system as a whole is laid out using stubs to ensure that the overall
structure is correct
Stubs are then converted into fully functional modules
Module Testing
►
►
►
►
►
Modules are created and tested within their sub-systems
When all modules have been tested the sub-system as a whole is tested then
sub-systems are brought together and the whole program is tested
At system level the type of testing is Black Box Testing
Black box testing takes the program specification as the sole source of test
cases
One advantage of this is that developers who test a system can be different
from those who create it
Module Test Progression
►
►
►
The testing process involves feedback
Testing might indicate errors in a module which would need debugged
and tested again
The usual strategy is to test software twice
The module is first tested within the company, this is Alpha Testing
It is followed by Acceptance or Beta Testing
Alpha Testing
►
►
►
►
Alpha testing can be regarded as ‘Does the software work?’
This is the stage in the development cycle where the software
is first able to run
This testing takes place on the software developers premises
Alpha testing is done for 2 reasons;
 To reassure the clients the software is working
 To find errors that can only be found in operational use
►
►
Alpha testing is performed on an early version of the code,
that might not have all intended functionality
Alpha testing should be conducted with as much
independence from the development team as possible
Beta (Acceptance) Testing
►
►
►
►
►
This is for the client to say ‘yes we will pay for the software’
Beta testing is the highest level of testing in the software development
cycle and is done prior to commercial release
It confirms that the program is as near to correct as possible
The software is tested by independent users who log and report back to
the development team, this process might be iterative if errors have to be
corrected
The functionality delivered in beta test releases might not be the final
product
Debugging
►
►
►
►
►
►
A bug is a fault in a program that causes it to function abnormally
Debugging is the process of locating and fixing errors
Programs that help to do this are called debuggers
Most software development tools offer debugging tools
Using a compiler the first task of the debugging tool is to link the object code
to source code to locate the error
The part of the compiler responsible for this is the Link-Loader
Debugging Tools
►
►
With the debugging features activated a program will run slower,
so it is only used when necessary
Debugging tools usually take the form of:




Dry Runs
Trace Tools
Watch Statements
Break Points
Dry Run
►
►
►
►
►
Bugs can be difficult to locate and correct, the temptation is to tweak the
code until it runs correctly, however this can lead to more errors
If a bug does not become apparent a dry run is conducted
A dry run is based on the listing of the code that the programmer works
through manually
A Trace Table is used to store and display program variables as the logic of
the algorithm unfolds, the actual output can then be checked against the
expected
Dry runs are used for locating logic errors and is only practical for simple
programs
Pupil task
Name and describe two methods of locating errors in a puzzle software.
Answer
Set breakpoints (1) – used to stop execution of the program at
predefined point (1)
Trace tables (1) – used to record the contents of a variable during
manual execution (1)
Dry run (1) – stepping through each line of code manually recording
variables (1)
Trace Tools
►
►
►
►
►
Some programming languages have TRACE facilities as a debugging feature
Tracing gives access to otherwise invisible information about a program
execution allowing the programmer to step through the program line by line
and stop at points to examine variable content
More enhanced tools allow investigation of memory locations and the
content of the stack
Programs that use large numbers of procedures use the stack to store all
their procedure calls
Using trace a program will run slower
Program Watch
►
►
►
►
A watch takes an identifier and displays its values as the program
progresses
The programmer steps through the code one line at a time and the
variable being traced is display on a watch screen
Many programmers prefer to put in watches in the form of output
statements that cause the value of the variable to be displayed at
points in a program where a bug exists
A draw back of program watching is the number of lines of code
increase as does programming time
Breakpoints
►
►
►
►
A break point is a marker set within the code of a program to halt program
execution at a predefined spot
The statement responsible will be highlighted and can be inspected while the
program is temporarily interrupted
The program then continues to completion or until another breakpoint is
found
Breakpoints are often used with traces
Pupil task
The project team is ready to beta test the software.
(i) Give two reasons why beta testing is necessary.
(ii) Name the two groups involved at this stage and
describe the role of each group.
Answers
i) • Checks software is reliable on the client’s computer.
• Checks client is happy with software and allows increased
reliability of testing.
• Allows client an opportunity to check that software meets
requirements.
• Allows programmers to observe the clients using the
software determining success of user interface etc.
(ii) • End users − provide feedback
• Programming team − maintenance
CASE Tools
Computer Aided Software Engineering
►
►
►
►
It refers to the collection of software programs that are designed to automate
the development cycle
The implementation of new systems requires many different complex tasks to
be organised and completed correctly and efficiently
Information generated has to be kept in synchronisation
The use of CASE tools eases the task of coordinating these activates from
analysis to implementation
Computer-Aided Software Engineering (CASE), in the field of
Software Engineering is the scientific application of a set of tools
and methods to a software system which is meant to result in
high-quality, defect-free, and maintainable software products.
It also refers to methods for the development of
information systems together with automated tools that can be
used in the software development process
Types of CASE Tools
Basic categories of CASE tools are available:
►





Diagramming tools that represent data models according to system
specifications.
Screen and Report Generators for creating system specifications.
Data Dictionaries that contain a history of changes made to a system
Code Generators to be able to generate code from data Diagrams
themselves.
Documentation generators that make the code more readable.
Development of CASE
►
►
Sine the early days of writing software there has been a need for
automated tools to help the software developer
As computer became more powerful ad the software that ran on them
grew larger and more complex, power tools with increasing functionality
were required
Categories of CASE Tools
►
CASE tools can be divided into two main groups
 Those that deal with the first three parts of the system development life
cycle (preliminary investigation, analysis, and design) and are referred to
as Front-End CASE Tools or Upper CASE Tools
 Those that deal mainly with the implementation, testing and installation
are referred to as Back-End CASE Tools or Lower CASE Tools
Upper CASE Tools
►
►
►
►
►
►
►
These are basically general-purpose analysis and design specification
tools
During the initial stages of system development, analysts have to
determine system requirements and analyse this information to design
the most effective system
Computerised CASE tools allow for changes to be made automatically,
very quickly and accurately
Data Dictionaries are data processing systems products that are
specifically designed to hold, maintain and organise information
They have facilities for producing a variety of reports
They allow developers to be more productive
The goal of a CASE tool is to refine the analysis and design stages to
allow automated production of code, around 75%
Data Dictionaries
A data dictionary is an automated tool for collecting and
organising detailed information about system components
► A data dictionaries main facility is to document data
elements, records, programs, files, users etc
► They also have the facility to cross-reference all system
components and contain details of:
►






Systems environment
Audit trails
Reports
Forms
Functions
Processes
Lower CASE Tools
►
►
►
►
These focus on the architecture of the system and its implementation and
maintenance
These tools are effective in helping with the generation of the program
code and are referred to as Code Generators
A code generator is a tool that enables automatic generation of code
from the analysis and design specifications
Generating code this way ensures that all code is produced with identical
naming conventions
Code Generators
►
►
Code generators produce a high quality of code that is easy to maintain and is
portable
They are able to interact with Upper CASE tools to aid in the development of
code
Document Generators
►
►
►
A further enhancement to CASE tools is document generators
A document generator is a CASE tool that generates technical documentation
from source code comments
The comments that are produced conform to a standard format
Object-Oriented CASE
►
►
►
►
CASE tools are well supported in object-oriented
programming systems (OOPS)
Earlier problems with OOPS focussed on models created for
software development systems and their different notations
This was overcome by the use of UML, Unified Modelling
Language, which is a new standard for producing diagrams
and charts
All current CASE tools have now adopted UML for specifying,
visualising and constructing software systems
UML
►
►
CASE tools offer automatic code generation from the UML
diagram
This tool produces a framework for the code which contains
objects and classes. An Executable Prototype is produced
 This is an executable source code program obtained directly from UML
►
One of the main features in UML is Reverse Engineering
where existing source code is reversed engineered into a set
of UML diagrams
RUP
Rational Unified Process
►
►
►
In conjunction with UML developers also employ RUP
This is a development process to deliver best practices during each stage
of a project
Using RUP risks are lowered during all stages
Advantages of CASE
►
►
►
►
►
Increase Speed
 CASE tools provide automation and reduce the time to complete tasks
Increased Accuracy
 CASE tools can provide on-going debugging and error checking which is vital for
early defect removal
Reduced Costs and Maintenance
 Overall system quality improves using CASE. There is also better documentation
so the net effort and cost involved is reduced
Better Documentation
 Using CASE tools vast amounts of documentation are produced. An important
aspect is CASE Repository, this is a developers database with information
relating to the projects stored. It can be regularly updated
Better Communication
 Information generated from one tool can be passed to another, allowing for
important information to be passed efficiently and effectively
Limitations Of CASE Tools
Although CASE tools are becoming more popular user can be
subject to some limitations:
►
Choice
 Over 1000 CASE tools exist and choosing one is difficult, a major
project in itself
►
Costs
 CASE tools are not cheap. Hardware, software, training and
consulting are all factors in the total cost equation
►
Training
 Users need time to learn the technology. A CASE consulting
industry has evolved to support uses of CASE tools
Pupil task
Describe two benefits of using Computer-Aided Software
Engineering (CASE) tools.
Answer
• Computerised generation of graphical designs and information
shared across the system would be monitored.
• Automated data dictionaries.
• Tools to track dependencies.
Do not allow compilers, editors, debuggers or other software
development type answers