Software Engineering Course Code: 331 Lecture 06

Software Quality Definition

Explicitly stated functional and performance requirements Explicitly documented development standards, and Implicit characteristics that are expected of all professionally developed software (Pressman)

Software Quality Assurance

Quality assurance a set of establish framework (procedures & standard) used by an organization to achieve high quality software SQA is applied at every stage of the software process Quality standard is selected to apply to the software process

SQA Activities

Prepare SQA plan Conduct of Formal Technical Reviews Software Testing Enforcement of Standards Control of Change Measurement Record keeping and Reporting

Testing is a process of executing a program with the intent of finding errors, locate errors and to proof system correctness Testing is conducted based on the developed test cases

Software Testing

Capture actual output Compare actual output with expected output

Actual == Expected : Test case succeed Actual != Expected : Test case failed

All test cases result must be recorded

Software Testing(Cont)

To identify errors in software developed Test case design methods produces tests to be used on the software Development of test strategy for a set of tests that uncovers all possible errors Thorough testing is not as effective as expected in most cases

Validation

Testing Terminology
Are we building the product right? Ensure software meets customers needs

Verification

Are we building the right product? Ensure software meet specification (error-free)

Testing Principles

All test should be traceable to customer requirements. Tests should be planned before testing begins. Testing should begin with individual components and move towards to integrated cluster of components. The most effective testing should be conducted by an independent third party.

Developer (individual units)

Who Should Test The Software?

Independent test group (ITG)

Test Cases

Test case : unit of testing activity Test cases have 3 parts :

Goal

Aspect of the system being tested

Input and system state

Data provided to the system under stated condition

Expected behavior

The output or action the system should take according to its requirements

Type Of Test Cases

Test cases are derived for

Valid and expected input Invalid and unexpected input Test if the system does less than specified requirement Test if the system does more than specified requirement

White Box Testing

Derived from knowledge of programs structure & implementation Structural testing - analyse code & use knowledge of the structure of a component to derive test data Logical paths are tested by providing test cases that exercise specific sets of conditions and/or loops

Thorough white box testing would lead to 100 percent correct programs Exhaustive testing are impractical - too many tests! A limited number of logical paths can be selected and exercised Important data structures can be probed for validity

White Box Testing (Continued)

White Box Test Cases

Guarantee that all independent paths have been exercised at least once Exercise all logical decisions on their true and false sides Execute all loops at their boundaries and within their operational bounds Exercise internal data structures to ensure their validity

Basis path testing

White Box Testing Techniques

Flow graph notation Cyclomatic complexity Derived test cases Graph metrics Condition testing Data Flow testing

Control structure testing

Flow Graph Notation

Node

2,3 6 7
R3 R2

4,5
R1

4 8 5

9 10
R4

Region

11

Cyclomatic Complexity

Provide quantitative measure for program logical complexity. Defined number of independent path

Any path that introduce one ser of processing statements or new condition Path 1 : 1-11 Path 2 : 1-2-3-4-5-10-1-11 Path 3 : 1-2-3-6-8-9-10-1-11

Eg :

How Is Cyclomatic Complexity Computed?

Number of regions V(G) = E N + 2

l
2.

The flow graph has 4 regions E : Number of flow graph edges N : Number of flow graph nodes

l l

V(G) = 11 edges 9 nodes + 2 = 4

3.

V(G) = P + 1
l

P : Number of predicate nodes

Deriving Test Cases

i=1; 2 total.input = total.valid=0; sum=0; do while value[i] <> -999 and total.input<100 increment total.input by 1; 4 if value[i] >= minimum AND value[i] <= maximum then increment total.valid by 1; sum = sum + value[i] 5 else skip 7 end if increment i by 1 End do If total.valid > 0 then average = sum / total valid; 9 else average = -999; 10 End if 11
12 13

1 2
3 6

3 10 12 13 8 9 11 4 5 6 7

Deriving Test Cases (cont) Determine cyclomatic complexity

V(G) = 6 regions V(G) = 17 edges 13 nodes + 2 = 6 V(G) = 5 predicates nodes + 1 = 6 Path 1 = 1-2-10-11-13 Path 2 = 1-2-10-12-13 . Path 1 test case : set values and match with expected result

Determine a basis set of linearly independent graph

Prepare test cases

Discussion on White Box Testing

Advantages

Find errors on code level Typically based on a very systematic approach, covering the complete internal module structure Does not find missing or additional functionality Does not really check the interface Difficult for large and complex module

Constraints

Black Box Testing

Derived from program specification Functional testing of a component of a system Examine behaviour through inputs & the corresponding outputs Input is properly accepted, output is correctly produced Disregard internal logical structure

Black Box Testing (Continued)

Incorrect or missing functions Interface errors Errors in data structures or external database access Performance errors Initialisation and termination errors

Graph Based Testing Methods Equivalence Partitioning Boundary Value Analysis Comparison Testing Orthogonal Array Testing

Black Box Testing Techniques

Equivalence Partitioning

Divide input domain into classes of data Based on an evaluation of equivalence classes for an input condition Guidelines to define equivalence classes

Range input : One valid and two invalid equivalence Specific value : One valid and two invalid equivalence A member of a set : One valid and one invalid

Complement equivalence partitioning Test both sides of each boundary

Boundary Value Analysis

Look at output boundaries for test cases Test min, min-1, max, max+1, typical values Example : 1 <= x <=100

Valid : 1, 2, 99, 100 Invalid : 0 and 101

Discussion on Black Box Testing

Advantages

Find missing functionality Independent from code size and functionality Find some coding errors No systematic search for low level errors Specification errors not found

Constraints

Unit Testing

Verification of the smallest unit in software - the module White box oriented Can be conducted in parallel for multiple modules Unit test cases designed based on source code - examine likely causes for errors Test environment includes driver and/or stubs

Interface - tested to ensure that information properly flows into and out of the unit Local data structures - examined to ensure that data stored temporarily maintains its integrity in an algorithms execution Boundary conditions - tested to ensure that module operates properly at boundaries

Unit Testing Considerations

Independent paths - to ensure all statements in a module executed at least once Error-handling paths

Unit Testing Considerations (Continued)

Act as main program Accept test data Past to the component to be tested Print results

Unit Test Environment

RESULTS
Stub

Interface Local data structures Boundary conditions Independent path Error Handling path

Stub

Replace module that are subordinate (called by) component to be tested Use subordinates module interface Do minimal data manipulation Print verification entry Return control to the module

Notes :

Driver and stub are software that must be written. Both are not delivered with final product

Test cases

Regression Testing

New module or major changes in software. Helps to ensure changes does not introduce

Unintended behavior Additional errors Most advised : Use automated capture-play back tools

Re-execute the subset of all test cases

This tool enable the software engineer to capture test cases and results for subsequent playback and

A series of black box tests that demonstrate conformity with requirements Test that software functions as expected by customer Test plan and details can be based on software requirements specification

Validation Testing

Alpha Test

Conducted at developers site by customer Software is used in a natural setting with the developer looking over the shoulder Errors and usage problems recorded, correction can possibly be done quickly Test conducted in a controlled environment

Beta Test

Conducted at one or more customer sites by end user(s) Developer generally not present Live application of software in uncontrolled environment Customer records all problems and reports them to developer at regular intervals Software modified based on problems reported before final release to customers

System Testing

A series of tests to fully exercise a computer-based system Verify that all system elements have been properly integrated and perform allocated functions Software is one element to be integrated Software engineer to anticipate potential interfacing problems

Recovery Testing

Force the software to fail in a variety of ways Verify that recovery is properly performed If recovery is automatic, re-initialisation, checkpointing mechanisms, data recovery, and restart are evaluated for correctness If recovery requires human intervention, mean time to repair is evaluated

Security Testing

Verify that protection mechanisms built into the system will protect it from improper penetration Tester plays the role(s) of individual who desires to penetrate the system System designer to make penetration cost greater than the value of information obtained

Stress Testing

Stress & Performance Testing

Performance Testing

Summary