SOFTWARE TESTING (10IS65) UNIT-1: CHAPTER-1: A PERSPECTIVE ON TESTING: Basic definitions, Test cases,

Insights from a Venn diagram, Identifying test cases, Error and fault taxonomies, Levels of testing.

1.1BASIC DEFINITIONS: Define the following : a) Error b) Fault c) Failure d) Incident e) Test f) Test case (6M) Jan

2015, July 2014 ?

Error- error is also known as mistake. While coding these mistakes are known as bugs. Errors tend to propagate-a requirements error magnified during design and amplified during coding phase. Fault- fault is the result of an error. Fault is the representation of an error, where representation can be source code, dataflow diagram, chart and so on. Fault is also known as defect. Faults can be elusive. Faults of omission Occur when we fail to enter correct information. Faults of commission Occur when we enter something into a representation that is incorrect. Failure-failure occurs when a fault is executed which is considered as A source code or object code. Failure happens for faults of commission, faults of omission, faults that never happen to execute and that do not execute for a long time. Incident-an incident is the symptom associated with a failure that alerts the user to the occurrence of a failure. Test- Testing is obviously concerned with errors, faults, failures, and incidents. A test is the act of exercising software with test cases. There are two distinct goals of a test: either to find failures, or to demonstrate correct execution. Test case-test case has an identity and is associated with a program behavior. A test case also has a set of inputs and expected outputs.

What is software testing? why do we test? Why it is so important in SDLC? (5M) Jan 2014?

Software testing is the process of judging the quality and functionality of the software product. There are two main reasons for testing: to make a judgment about quality or acceptability, and to discover problems. It is so important in SDLC development phases, because there are three opportunities for errors that result in faults that propagate

through the remainder of the development life cycle. The 1st three phases are putting bugs IN; the testing phase is finding bugs; and the last 3 phases are getting bugs OUT. The fault resolution step is also another opportunity for errors and faults. The process of testing can be subdivided into: test planning, test case Development, running test cases, and evaluating test results.

A life cycle model of testing

1.2 TEST CASES:

Typical test case information should have an identity and a purpose. It also includes the record of the

execution history of a test case with the date, result, Version and when and by whom it was run. Test cases

need to be developed, reviewed, used, Managed and saved.

1.3 INSIGHTS FROM A VENN DIAGRAM:

Structural view focuses on what the program is and behavioral view focuses on what a program does.

Consider the set S of specified behaviors and the set P of Programmed behaviors as shown in the Venn

diagram. The intersection of S and P entails the behaviors that are both specified and implemented.

The new circle in the below diagram represents the test cases. Consider the relationships among the sets S,P,

and T. There may be specified behaviors that are not tested (regions 2 and 5), Specified behaviors that are

tested (regions 1 and 4), and test cases that correspond to unspecified behaviors (regions 3 and 7). Similarly,

there may be programmed behaviors that are not tested (regions 2 and 6), programmed behaviors that are

tested (regions 1 and 3), and test cases that correspond to un-programmed behaviors (regions 4 and 7). If the

test cases are not available for the specified behaviors then the testing is inevitably incomplete. If certain test

cases correspond to unspecified behaviors, then the test case is unnecessary. A good tester brings the region

where these sets all intersect as large as possible. The test cases in the set T are identified by a testing

method.

Typical test case information

Specified and implemented program behaviors Specified, implemented, and tested behaviors.

1.4 IDENTIFYING TEST CASES:

Difference between functional testing and structural testing (6M) Jan 2015, July 2014 ?

FUNCTIONAL TESTING STRUCTURAL TESTING

Functional testing also termed as black box testing,

in which the content of a black box is not known,

and the function of the black box is understood

from its input and output.

Functional testing uses only the specification to

identify test cases.

Two advantages of Functional test cases are, 1)

they are independent of how the software is

implemented, 2) test case development can occur

in parallel with the implementation thus reducing

project development time.

Two disadvantages of Functional test cases are, 1)

significant redundancies exist among test cases, 2)

possibility of gaps of untested software.

The results of test cases identified by two

functional methods are given below. Method A

identifies a larger set of test cases than does

Method B. Both the test cases are completely

contained within the set of specified behavior.

Comparing functional test case identification

methods

Structural testing is also known as white box or

clear box testing. Clear box testing allows the

tester to identify test cases based on how the

function is actually implemented.

Structural testing uses the program source code to

identify test cases.

When functional test cases are executed in

combinational with structural test coverage

Metrics, both of the problems of redundancies and

gaps are recognized and resolved.

Two disadvantage of Structural test cases are, 1)

they are dependent of how the software is

implemented, 2) test case development can occur

after the implementation thus the project

development time is increased.

The results of test cases identified by two

structural methods are given below. Method A

identifies a larger set of test cases than does

Method B. Both the test cases are completely

contained within the set of programmed behavior.

Comparing structural test case identification

methods

1.5 ERROR AND FAULT TAXONOMIES:

Explain the IEEE error and fault taxonomy and IEEE standard anomaly process in software testing. (8M) Jan 2014 ? Error and fault represents process and product. Process refers to how we do something, and the product is the

end result of a process. Testing is concerned with discovering faults in a product. Software quality assurance

(SQA) is concerned with reducing errors in the Development process. Faults are classified as in: error in the

development phase, the consequences of corresponding failures, difficulty to resolve, risk of no resolution.

The fault taxonomy is given below.

The IEEE standard defines a detailed anomaly resolution process built around four phases (another life cycle):

recognition, investigation, action, and disposition. Some of the more useful anomalies are given

1.6 LEVELS OF TESTING:

Levels of testing echo the levels of abstraction found in the waterfall model of the software development life

cycle. The diagram below emphasizes the correspondence between testing and design levels. In terms of

functional testing , the three levels of definition known as, specification, preliminary design, and detailed

Design corresponds to 3 levels of testing – system, integration, and unit testing. Structural testing is most

appropriate at the unit level, while functional testing is most appropriate at the system level.

Levels of abstraction and testing in the waterfall model

UNIT-1: CHAPTER-2: EXAMPLES: Generalized pseudo code, The triangle problem, The NextDate

function, The commission problem, The SATM (Simple Automatic Teller Machine) problem, The currency converter, Saturn windshield wiper.

2.1 GENERALIZED PSEUDO CODE: Pseudo code is a language neutral way to express program source

code.

2.2 THE TRIANGLE PROBLEM STATEMENT:

Explain the triangle problem statement along with flow chart for traditional

implementation.(7M) Jan 2014 ?

TRADITIONAL IMPLEMENTATION: Traditional implementation of triangle problem is given by Fortran-

like language. But here C language is used to represent the triangle problem.

#include<stdio.h> int main() { int a,b,c; char istriangle;

printf("enter 3 integers which are sides of triangle\n"); scanf("%d%d%d",&a,&b,&c); printf("a=%d\t,b=%d\t,c=%d",a,b,c); // to check is it a triangle or not

if( a<b+c && b<a+c && c<a+b ) istriangle='y'; else istriangle ='n'; if (istriangle=='y') if ((a==b) && (b==c)) printf("equilateral triangle\n"); else if ((a!=b) && (a!=c) && (b!=c)) printf("scalene triangle\n"); else printf("isosceles triangle\n"); else printf("Not a triangle\n"); return 0; }

FLOWCHART FOR THE TRADITIONAL TRIANGLE PROGRAM IMPLEMENTATION:

STRUCTURED IMPLEMENTATION OF TRIANGLE PROGRAM: Dataflow diagram of the triangle

program is represented below. Three procedures are used to write the main program.

#include<stdio.h> int main() { int a,b,c,c1,c2,c3; char istriangle;

//step 1: get input do { printf("\nenter 3 integers which are sides of triangle\n"); scanf("%d%d%d",&a,&b,&c); printf("\na=%d\tb=%d\tc=%d",a,b,c); c1 = a>=1 && a<=10; c2= b>=1 && b<=10; c3= c>=1 && c<=10; if (!c1) printf("\nthe value of a=%d is not the range of permitted value",a); if (!c2) printf("\nthe value of b=%d is not the range of permitted value",b); if (!c3) printf("\nthe value of c=%d is not the range of permitted value",c); } while(!(c1 && c2 && c3));

//step 2: to check is it a triangle or not if( a<b+c && b<a+c && c<a+b ) istriangle='y'; else istriangle ='n';

//step 3: determine triangle type if (istriangle=='y') if ((a==b) && (b==c)) printf("equilateral triangle\n"); else if ((a!=b) && (a!=c) && (b!=c)) printf("scalene triangle\n"); else printf("isosceles triangle\n"); else printf("Not a triangle\n"); return 0; }

DATAFLOW DIAGRAM FOR A STRUCTURED TRIANGLE PROGRAM IMPLEMENTATION:

2.3 THE NEXTDATE FUNCTION: NextDate function illustrates the complexity of logical relationships

among the input variables.

Explain the next date function problem statement along with the implementation?

PROBLEM STATEMENT:

IMPLEMENTATION: #include<stdio.h> int check(int day,int month) { if((month==4||month==6||month==9 ||month==11) && day==31) return 1; else return 0; } int isleap(int year) { if((year%4==0 && year%100!=0) || year%400==0) return 1; else

return 0; }

int main() { int day,month,year,tomm_day,tomm_month,tomm_year; char flag; do { flag='y'; printf("\nenter the today's date in the form of dd mm yyyy\n"); scanf("%d%d%d",&day,&month,&year); tomm_month=month; tomm_year= year; if(day<1 || day>31) { printf("value of day, not in the range 1...31\n"); flag='n'; } if(month<1 || month>12) { printf("value of month, not in the range 1....12\n"); flag='n'; } else if(check(day,month)) { printf("value of day, not in the range day<=30"); flag='n'; }

if(year<=1812 || year>2013) {

printf("value of year, not in the range 1812.......2013\n"); flag='n'; } if(month==2) { if(isleap(year) && day>29) { printf("invalid date input for leap year"); flag='n'; } else if(!(isleap(year))&& day>28) { printf("invalid date input for not a leap year"); flag='n'; } } }while(flag=='n'); switch (month)

{ case 1: case 3: case 5: case 7: case 8: case 10:if(day<31) tomm_day=day+1; else { tomm_day=1; tomm_month=month+1; } break; case 4: case 6: case 9: case 11: if(day<30) tomm_day=day+1; else { tomm_day=1; tomm_month=month+1; } break; case 12: if(day<31) tomm_day=day+1; else { tomm_day=1; tomm_month=1;

if(year==2013) { printf("the next day is out of boundary value of year\n"); tomm_year=year+1; } else tomm_year=year+1; } break; case 2: if(day<28) tomm_day=day+1; else if(isleap(year)&& day==28) tomm_day=day+1; else if(day==28 || day==29) { tomm_day=1; tomm_month=3;

} break; } printf("next day is : %d %d %d",tomm_day,tomm_month,tomm_year); return 0;}

2.4 THE COMMISSION PROBLEM: It is a mix of computation and decision making.

Explain the commission problem statement along with the implementation?

PROBLEM STATEMENT:

IMPLEMENTATION:

2.5 THE SATM SYSTEM: A simple automated teller machine (SATM) system could be used to discuss

integration and system testing.

Explain in detail various levels of software testing with embedded device like SATM as an

example. (15M) Jan 2015, July 2014, July 2013?

PROBLEM STATEMENT: The SATM system communicates with bank customers via the 15 screens. Using a

terminal with features, SATM customers can select any of three transaction types: deposits, Withdrawals, and

balance inquiries. These transactions done on 2 types of accounts: Checking and savings.

2.6 THE CURRENCY CONVERTER:

The currency conversion program is another event-driven program that emphasizes code associated with a

graphical user interface (GUI).

2.7 SATURN WINDSHIELD WIPER CONTROLLER: