Experiment 5

Aim: Program to add two numbers, each number should be of one or two digits. Perform
Adhoc testing.

Perfomance Instructions:

Adhoc testing is an informal testing type with an aim to break the system. This testing is
usually an unplanned activity. It does not follow any test design techniques to create test
cases. In fact is does not create test cases altogether! This testing is primarily performed if
the knowledge of testers in the system under test is very high. Testers randomly test the
application without any test cases or any business requirement document. Ad hoc Testing
does not follow any structured way of testing and it is randomly done on any part of
application. Main aim of this testing is to find defects by random checking. Adhoc testing
can be achieved with the testing technique called Error Guessing. Error guessing can be
done by the people having enough experience on the system to "guess" the most likely
source of errors.
Some Advantages –
1. Ad-hoc testing gives freedom to the tester to apply their own new ways of testing the
application which helps them to find out more number of defects compared to the formal
testing process.
2. This type of testing can be done at anytime anywhere in the Software Development
Life cycle (SDLC) without following any formal process.
3. This type of testing is not only limited to the testing team but this can be done by the
developer while developing their module which helps them to code in a better way.
Some Disadvantages –
1. Since ad-hoc testing is done without any planning and in unstructured way so
recreation of bugs sometime becomes a big trouble.
2. The test scenarios executed during the ad-hoc testing are not documented so the tester
has to keep all the scenarios in their mind which he/she might not be able to recollect in
future.
3. Ad-hoc testing is very much dependent on the skilled tester who has thorough
knowledge of the product it cannot be done by any new joiner of the team.
Sample Inputs
Input is two numbers each should be one or two digits
#include<stdio.h>
void main()
{
int a, b, c;
scanf("%2d",&a);
scanf("%2d",&b);
c=a+b;
printf("%2d\n",c);
}

Sample Outputs
The program output will be addition of two numbers
Result:
Test Case Inputs (a, b) Expected Output Actual output
Id
1 2,3 5 5
2 23, 45 68 68
3 -97, -99 -196 -2
4 -38, 99 61 5
5 20,30 50 50
6 53, 45 98 98
7 10,77 87 87
8 1,1 2 2
9 -34,90 56 1
10 11,12 23 23
11 -45,78 23 1
12 72,34 106 106
13 -99,55 -44 0
 Experiment 6

Aim:To determine the nature of roots of a quadratic equations. Perform DD Path Testing
Consider the following program segment that returnroots of quadratic equation

1) int main ( )
2) {
3) int a, b, c, d, boolean = 0;
4) double D;
5) printf (“nt Enter `a' coefficient :");
6) scanf ("%d", & a) ;
7) printf ("nt Enter `b' coefficient :”);
8) scanf ("%&d", & b);
9) printf (“ Enter `c' coefficient :”);
10) scanf, ("%d”, & c) ;
11) if ((a > =0) && (a < = 00) && (b > = 0) && (b < =100) && (c > =0) && (c < =100))
{
12) boolean = 1;
13) if (a = = 0) {
14) boolean = -1;
15) }
16) }
17) if (boolean = = 1) {
18) d = b * b - 4 * a * c;
19) if (d = = 0) {
20) printf ("roots are equal and are r1= r2 = %f - b/(2 * float)&));
21) }
22) else if (d > 0) {
23) D = sqrt (d);
24) printf ("roots are real and are r1=%f and r2=%f; (-b - D)/(2 * a), (-b + D)/(2 * a));
25) }
26) else {
27) D = sqrt (-d) / (2 * a);
28) printf ("roots are imaginary");
29) }
30) }
31) else if (boolean = = -1) {
32) printf ("Not a quadratic equation");
33) }
34) else {
35) printf ("Invalid input range ...);
36) }
37) getch ( ):
38) return 0;
39) }

A. Draw the control flow graph for this program segment

B. Draw the DD Path Graph.

C. Calculation of Cyclomatic Complexity V(G) by three methods.

D. Determine the number of independent paths

Perfomance Instructions:

White box testing: White box testing sometimes called open box testing or glass box testing
or clear box testing or structural testing. In white box testing test cases are derived from the
source code internals of the software, specifically including branches, individual conditions,
and statements. It is concerned with the level up to which test cases exercise or cover the
logic (source code) of the program. By examining and testing the program code white box
testing tests the external functionality of the code. In White Box testing the tester must have
the complete knowledge about the internal structure of the source code. Using white box
testing methods the tester can derive following test cases:
1. Test case that ensures that all independent path have been exercised at least once.
2. Test cases that checks all the decision on their true or false sides.
3. Test cases that execute all loops at their boundaries and within their operational
bound.
4. Test cases that exercise internal data structures to ensure their validity. Following are
the white box testing techniques:
• Basis Path testing
• Data Flow testing
• Mutation Testing
Basis Path testing
With the help of basis path testing, test case designer can derive a logical complexity measure
of a procedural design and can use this measure to find the basis set of execution paths. Test
cases that are derived to exercise the basis set ensures that every statement in the program
will execute at least one time during testing.
Steps for basis path testing
• construct the flow graph from the source code or flow chart
• Identify independent path in the flow graph
• Calculate cyclomatic complexity, V(G).
• Design the test cases.

Flow graph

Flow graph of a program can be represented using a graphical representation known as a

“Flow Graph”.A Flow graph is a directed graph in which nodes are either entire statements or
fragment of statements. Edges represent the flow of control.Flow graph depicts the logical
control flow using the notation given in fig 2.4

Fig: Structured programming constructs

Cyclomatic complexity can be computed in one of the tree ways:

1. The number of regions in a flow graph corresponds to the cyclomatic complexity.
2. Cyclomatic complexity V(G) of a flow graph G, is defined as V(G)= E-N+2

Where E is the Number of edges in the flow graph

N is th number of nodes in flow graph.
3. Cyclomatic complexity V(G) of a flow graph G, can also be defined as V(G) = P+1
Where P is the number of predicate node in the flow graph
Independent path :Number of independent path = V(G) which makes a basis set.
We must execute these paths at least once in order to test the program thoroughly.
 Sample Input: input will be three integers 50, 50, 2

Sample Output: roots are real root

Result:
A. Control flow graph for the program segment is as follows:
 B. DD Path Graph

Decision table for the above program :

Nodes in Corresponding Nodes Justification

Flow Graph of DD Path Graph

1- 9 a Are Sequential Nodes

10 b Decision Nodes
11 c Decision Nodes

12, 13 d Sequential Nodes

14 e Two Edges Combined

15, 16, 17 f Sequential Nodes

18 g Decision Nodes

19 h Decision Nodes

20, 21 i Sequential Node

22 j Decision Node

23, 24 k Sequential Node

25, 26, 27 I Sequential Nodes

28 m Three Edges Combined

29 n Decision Node

30, 31 o Sequential Node

32, 33, 34 p Sequential Nodes

35 q Three edges Combined

36, 37 r Sequential Exit Nodes

C. Cyclomatic Complexity V(G) by three methods

Method 1: V(G) = e - n + 2 ( Where e are edges & n are nodes)

V(G)=24-19+2=5+2=7
 Method 2: V(G) = P + 1 (Where P is No. of predicate nodes with out degree = 2)

V(G) = 6 + 1 = 7 (Nodes d, b, g, I, o & k are predicate nodes with 2 outgoing edges)

Method 3: V(G) = Number of enclosed regions + 1 = 6+1=7

( Here R1, R2, R3, R4, R5 & R6 are the enclosed regions and 1 corresponds to
one outer region)

Cyclomatic Complexity =V(G) = 7 and is same by all the three methods.

D. Draw independent paths

Number of independent paths = V(G)=7

Path 1:

abf gnpqr

Path 2:

abf gnoqr

Path 3:

abce gnpq r

Path 4:

abcde gnoq r

Path 5:

abf ghim qr

Path 6:

abf ghikm qr

Path 7:

abf ghjl mqr

 Experiment 7
Aim: Create a test plan document for any application (e.g. Library Management System)

Theory:

Test planning developed early phase of the software development and which includes
followed by -:

Project Name -: Library Management System

Product Name -: Dues calculation and tracking books
Product Release Version -: 7.6.1
1] Introduction
2] Objectives and scope
3] Environment
4] Roles and Responsibility
5] Schedule
6] Testing strategies
7] Features to be tested
8] Features to be not tested
9] Entry and exit criteria
10] Dependency
11] Risk and mitigation‟s
12] Control procedures
13] Tools uses
14] Approval Date -: 26/3/2018
Prepared by -: Mr./Ms______________

Library Management Sample Test Plan

Prepared by: Ms / Mr. ……………

Prepared Date: …/…/…

Introduction -:
The Library Management System application for assisting a librarian in managing library
books. The system would provide basic set of features to add/update clients, add/update
books, search for books, dues if any and manage check-in / checkout processes. This test plan
is a basic guideline for future testing in the LMS.

Scope -:
The system would provide basic set of features to add/update members, add/update books,
dues if any and manage check in specifications for the systems based on the client‟s
statement of need.
Environment Requirement -:
Hardware -: Three Dual Core or above machines needed
Software -: Microsoft Windows XP installed

Testing Strategies -:
1. Unit Testing :
Definition : Test smallest testable parts of an application, called units, are individually
and independently scrutinized for proper operation.
Participants/ Tested by : Developers
Methodology : Used for the Database test, records in each table, Basic function test, add
a student, add a book, Network test

2. System and Integration Testing -:

Definition : Integration testing is the phase in software testing in which individual
software modules are combined and tested as a group.
Participants/ Tested by : System Tester
Methodology : It is used for the Database test, Queries for insert, update, delete the records

3. Performance and Stress Testing -:

Definition : Determine how a system performs in terms of responsiveness and stability
under a particular workload.
Participants/ Tested by : Tester
Methodology : It is used for the Database test, records in each table, Basic
function test, Network test

4.User Acceptance Testing -:

Definition : Formal testing with respect to user needs, requirements, and business
processes conducted to determine whether or not a system satisfies Participants/
Tested by : Users / End Users
Methodology : It is used for Whole System Test

5. Automated Regression Testing -:

Definition : Uncover new errors, or regressions, in existing functionality after changes
have been made to a system, such as functional enhancements, patches or configuration
changes. Participants/ Tested by : Tester
Methodology : It is used for Whole System Test

Test Schedule -:

S. N Particulars Est. Start T. Est. End T. Actual Start T. Actual End T.

1 Login 0.0s 1.0s
2 Book Trans. 2.0s 8.0s

3 Report Gen. 10.0s 11.0s

Result: Library Management Sample Test Cases
Consider, library management system user is registered and logged in, then the
detail for system test cases are as -:
Project Name-: Library Management Project Code-: Lib_Mgmt
Prepared by-: Jaskirat Singh Prepared Date- 27/9/18
Reviewed by-: Kushagr Aggarwal Review Date-:27/9/18
Total number of test cases = 5
Total number of test cases pass = 4
Total number of test cases fail = 1
Percentage of pass test cases = 80
Percentage of fail test cases = 20
For
1] Display available books on student name or Id
2] Dues calculation
3] Add category wise book
4] Search books by book name
5] Search book by author name
Actual
TC_ID TC Desc. TC Proc. Input Data Expected Res. Res. Status
Library Mgmt 1] Enter student name or
System Should Student Id Student Name =” “ Available books
Lib_Mgmt1 be open 2] Click on search or Student Id = “ “ should be displayed
1] Enter student name or
Student Id
2] Enter issued date 1] Student Name = ”
3] Enter received date “ or Student Id = “ “
Library Mgmt 4] Click on calculate dues 2] Issued date = “ „
System Should (Based policy to avail the 3] Received date = “ Dues should be
Lib_Mgmt2 be open books for specified days) “ calculated
1] Enter Book name
Library Mgmt 2] Enter author name Book name = “ “
System Should 3] Enter book category Author name = “ “ Category wise book
Lib_Mgmt3 be open 4] Click on add book Book category = “ “ should be added
Library Mgmt Book should be
System Should 1] Enter Book name displayed based on
Lib_Mgmt4 be open 2] Click on search Book name = “ “ entered book
Library Mgmt Book should be
System Should 1] Enter author name displayed based on
Lib_Mgmt5 be open 2] Click on search Author name = “ “ author name
 Experiment 8
AIM: Study of Any Testing Tool (Win Runner)

Introduction to Win Runner

• WinRunner is Mercury‟s legacy automated testing tool.

• WinRunner is a test automation tool, designed to help customers save testing time
and effort by automating the manual testing process.
• You can create test scripts that check all aspects of your application, and then run
these tests on each new build.
• As WinRunner runs tests, it simulates a human user by moving the mouse cursor
over the application, clicking Graphical User Interface (GUI) objects, and entering keyboard
input.
• It create a summary report showing the test status

Winrunner Testing Process

Testing with WinRunner Involves six Stages

1) Create a GUI map: - WinRunner learns to recognize objects in an application in order

to run tests - The preferred way to teach your objects depends on the GUI map mode
2) Create tests: - Winrunner writes scripts automatically when recording actions in
application - One can program directly in Mercury interactive script language(TSL)
3) Debug tests: - You debug the test to check that they operate smoothly and without
interruption
4) Run test: - Run test in verify mode t test your application - It compares the current data
of application being tested to the expected data captured earlier - If any mismatch are found,
winrunner captures them as actual results
5) View results: - After each run it displays result in report - The report details all the
major events that occurred during the run such as checkpoint, error message, system message,
user message
6) Report defects: - If a test run fails due to a defect it will report directly in report
window

Features of WinRunner are: -

• Functional Regression Testing Tool
• Windows Platform Dependent
• Only for Graphical User Interface (GUI) based Application
• Based on Object Oriented Technology (OOT) concept
• Only for Static content
• Record/Playback Tool
Winrunner environment
• Windows - C++, Visual Basic, Java, PowerBuilder, Stingray, Smalltalk
• Web - Web Applications
• Other technologies - SAP, Siebel, Oracle, PeopleSoft, ActiveX

Exploring the WinRunner Window

The first time you start WinRunner, the Welcome to WinRunner window
opens. From the welcome window you can create a new test, open an
existing test, or view an overview of WinRunner in your default browser.

Each test you create or run is displayed by WinRunner in a test window. You
can open many tests at one time.

1. The WinRunner window displays all open tests.

2. Each test appears in its own test window. You use this window to record, program,
and edit test scripts.
3. Buttons on the Standard toolbar help you quickly open, run, and save tests.
4. The User toolbar provides easy access to test creation tools.
5. The status bar displays information about selected commands and the current test run.

The Standard toolbar provides easy access to frequently performed tasks,

such as opening, executing, and saving tests, and viewing test results.