department of information technology

1

Department of Information Technology

Computer Programming & Problem Solving

Ch 10Testing & Documentation Topics

KIC/Computer Programming & Problem Solving

Validation vs. VerificationTesting Process FunctionDebuggingTesting ProcessTesting in SmallTesting in LargeDocumentation

2KIC/Computer Programming & Problem Solving

Outline

3

Verification vs. Validation

Validation Verification

During validation we check “Are we building the right product?”

During verification we check “Are we building the product right ?”

It involves checking that the software should do what the user really requires

It involves checking that the software should confirm to its specification.


4

Testing

Testing has a dual function to establish the presence of defects in a

program and it is used to help judge whether or not the program is

usable in practice.

Testing can only demonstrate the presence of an error.

It cannot show that there are no errors in a program.


5

Debugging

After testing when defects or error have been found in the program these must be removed. Debugging is concerned with locating and correcting these defects.

Locate error

Design error repair

Repair error

Re-test Program


6

Testing Process

• The testing process should proceed in stages where testing is carried out incrementally in conjunction with system implementation.

• The most widely used testing process consists of five stages. These are

1. Unit Testing: Individual components are tested to ensure that they operate correctly. Each component is tested independently, without other system components.


7

Testing Process

2. Module Testing: A module is a collection of dependent components such as collection of procedures or functions. A module encapsulates related components so can be tested without other system modules.

3. Sub-system Testing: this phase involves testing collections of modules which have been integrated into sub-systems. This test should concentrate on the detection of interface errors.


8

Testing Process

4. System testing: The sub-systems are integrated to make-up the entire system. The testing process is concerned with finding errors which result from unanticipated interactions between subsystems and system components. It is also concerned with validating that the system meets its functional and non-functional requirement.

5. Acceptance Testing: this is the final stage in the testing process before the system is accepted for operational use. The system is tested with actual data rather than the simulated data. Acceptance testing is sometimes called alpha testing.


9

Testing Process

Bespoke systems are developed for single client. The alpha testing process continues until the system developer and the client agree that the delivered system is an acceptable implementation of system requirement.

When a system is to be marketed as a software product, a testing process called beta testing is often used. Beta testing involves delivering a system to a number of potential customers as in the case of Generic product.

In general the sequence of testing activities is Component Testing, Integration testing then User Testing.


10

Testing Process

Unit Testing

Module Testing

Sub-system Testing

System Testing

Acceptance Testing

Component Testing

Integrated Testing

User Testing


Testing in SmallTesting in small addresses the testing of individual

modules. There are two main approaches:• White Box testing

– White-box testing uses the internal structure of the program to derive the test data. Hence it is also called structured testing.

• Black Box Testing– Testing a piece of software as a black box means

operating the software without relying on any knowledge of the way it has been designed and coded. Hence it is also called functional testing.

11


Testing in Small

White-box testing• Statement coverage• Edge Coverage• Condition coverage• Path coverage

12


Testing in Small White-box testing

Statement coverageThe first step in white-box testing strategy is to ensure that our test cases goes through all the program statements at least once. This is called statement coverage criteria.

13



Edge CoverageEdge coverage criterion is used to test that the test case goes through every true/false part of the if-else statement and performs the complete loop correctly. Basically here we check the flow of control through the program.

14



Condition coverageCondition coverage is used to further strengthen the edge coverage. This help to point out the edges that might be hidden in the control flow graph of the program specially when we have compound conditions in the if –else condition.

15



Path coverageIn Path coverage criterion, we select a test case which passes through all the paths leading from the initial to the final statement of the program.

16


Testing in Small

Black box testingBlack box testing also called functional testing, is based on the definition of what a (piece of) program is intended to do (i.e, it is based on the program’s specification, rather than on its structure).

17


Testing in Small

Black Box Testing White Box Testing

Black box testing is called the functional testing.

White box testing is called the structural testing.

Test sets are developed and the results evaluated solely on the basis of the specification.

White box testing uses the internal structure of the software to to device test cases.

Black box testing tests what the program is suppose to do.

White box tests what the program does.

18


Testing in Large

Module testingBottom-up and Top-Down testingSystem TestingStress TestingPerformance Testing

19


Testing in Large Module Testing

Module testing• Modules are ultimately mapped into different

constructs-say, a procedure, a package, a task or even a full program that is part of a system of programs that interact together an operating system to form a complete application.

• To test a module we need a complete environment which provides all that is necessary for the execution of the module itself.

20


Testing in Large Module Testing

Here are some examples:– A module may use a procedure that is not part of

that module.– A module may access non-local data structure.– A module is itself used by another module.– All these situation should be simulated in order to

make the testing of the module possible.

21


Testing in Large Top-Down Testing

• Top-down testing tests the high levels of a system before testing its detailed components. The program is represented as a single abstract component with sub-components represented by stub.

• After the top-level component has been tested, its sub-components are implemented and tested in the same way. This process continues recursively until the bottom-level components are implemented the whole system can then be completely tested.

22


Testing in Large Top-Down TestingAdvantages:

– Unnoticed design errors can be detected at an early stage in the testing process.

– A limited working-system is available at the early stage of the development.

– It demonstrates the feasibility of the system to management

– Validation can begin in the early stages of the testing process

Disadvantages– If the component is a complex one, it may be difficult to

produce a program stub.– Test output may be difficult to observe.

23

Testing in Large Bottom-up testing

Bottom-up testing where testing starts with the fundamental components and work upwards. It involves testing the modules at the lower levels in the hierarchy and then working up the hierarchy of the module until the final module is tested.Disadvantage:

Architectural faults are not discovered until much of the system has been tested.

24


Testing in Large System testing

The process of testing an integrated system to verify that it meets specified requirements.

25



Testing in Large Stress testing

Stress testing is conducted to see the behavior of the systems as the load is increased. This type of tests have two functions:

– It tests the failure behavior of the system– It stresses the system and the defects can be

found out.

26

Testing in Large Performance testing

performance testing is testing that is performed to determine how fast some aspect of a system performs under a particular workload

27


System Documentation

The system Documentation includes all of the documents describing the implementation of the system from the requirements specification to the final acceptance test plan.• WHY?

– Business IT systems are too large and complex to rely on verbal communication and memory.

– Maintenance without

documentation should be worse with computer systems

– Mistakes and inconsistency.– Unreliability.– Difficulties for other staff.– Maintenance problems.– Unnecessary additional

investigations.– Loss of expertise.

28


System Documentation

Documents that are produced to aid the maintenance process include:

– The requirement document– A document describing overall system architecture– For each program in the system, a description of the

architecture of that program.– Program source code with comments where ever necessary.– Validation documents describing how each program is

validated and how the validation information relates to the requirements.

– A system maintenance guide.

29



30

department of information technology

Documents

subsystem testing

acceptance testing

beta testing

areunit testing

alpha testing process

system components

testing collections

system implementation