paper i software testingresults.mu.ac.in/myweb_test/st_mca_journal format.pdf · srs document of...
TRANSCRIPT
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 1 IDOL, University of Mumbai
Paper I
Software Testing
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 2 IDOL, University of Mumbai
INDEX
Sr.No. Practical Description Page No.
Date Sign
1. 1.1 What is walk through review? 1.2 What is inspection review?
24/10/09
2. SRS document of hospital management system. Payroll system requirement analysis. SRS for CD-shop system.
24/10/09
3. To generate unit testing report for CD Library shop.
28/10/09
4. To create SRS for school management system.
29/10/09
5. To perform black box testing of given programs using equivalence class partitioning method.
a. Test given programs using Equivalence class partitioning
b. Find out any defects in given programs
c. Apply Equivalence class partitioning method of testing for application School management system
29/10/09
6. To perform black box testing of given programs using boundary value analysis (BVA) method
a. Test given programs using BVA b. Find out any defect in given
program c. Apply BVA for "School
Management system"
7/11/09
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 3 IDOL, University of Mumbai
7. To perform white box testing of given programs using branch coverage method
a. Test given programs using branch coverage
b. Apply branch coverage method for "School Management system"
7/11/09
8. To perform white box testing of given programs using path coverage method
14/11/09
9. To perform white box testing of given programs using condition coverage method
14/11/09
10. Introduction of WinRunner 18/11/09 11. To study Recording and Playback using
WinRunner 18/11/09
12. To study GUI Checkpoints in WinRunner 21/11/09 13. To study Bitmap Checkpoints in
WinRunner 21/11/09
14. To study Database Checkpoints in WinRunner
25/11/09
15. To study Text Checkpoints in WinRunner 25/11/09
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 4 IDOL, University of Mumbai
Date: 24/10/09 PRACTICAL NO.1
AIM:
1.1 What is walk through review? 1.2 What is inspection review?
DESCRIPTION: What is walk through review? What is inspection review? Review is "A process or meeting during which artifacts of software product are examined by project stockholders, user representatives, or other interested parties for feedback or approval”. Software Review can be on Technical specifications, designs, source code, user documentation, support and maintenance documentation, test plans, test specifications, standards, and any other type of specific to work product, it can be conducted at any stage of the software development life cycle. Purpose of conducting review is to minimize the defect ratio as early as possible in Software Development life cycle. As a general principle, the earlier a document is reviewed, the greater will be the impact of its defects on any downstream activities and their work products. Magnitude cost of defect fixing after the release of the product is around 60-100x. Review can be formal or informal. Informal reviews are referred as walkthrough and formal as Inspection. Walkthrough: Method of conducting informal group/individual review is called walkthrough, in which a designer or programmer leads members of the development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems or may suggest improvement on the article, walkthrough can be pre planned or can be conducted at need basis and generally people working on the work product are involved in the walkthrough process. The Purpose of walkthrough is to: · Find problems · Discuss alternative solutions · Focusing on demonstrating how work product meets all requirements.IEEE 1028 recommends three specialist roles in a walkthrough: Leader: who conducts the walkthrough, handles administrative tasks, and ensures orderly conduct (and who is often the Author) Recorder: who notes all anomalies (potential defects), decisions, and action items identified during the walkthrough meeting, normally generate minutes of meeting at the end of walkthrough session. Author: who presents the software product in step-by-step manner at the walk-through meeting, and is probably responsible for completing most action items. Walkthrough Process: Author describes the artifact to be reviewed to reviewers during the meeting. Reviewers present comments, possible defects, and improvement suggestions to the author. Recorder records all defect, suggestion during walkthrough meeting. Based on reviewer comments, author performs any necessary rework of the work product if required. Recorder prepares minutes of meeting and sends the relevant stakeholders and leader is normally to monitor overall walkthrough meeting activities as per the defined company process or responsibilities for conducting the reviews, generally performs monitoring activities, commitment against action items etc. Inspection: An inspection is a formal, rigorous, in-depth group review designed to identify problems as close to their point of origin as possible., Inspection is a recognized industry best practice to improve the quality of a product and to improve productivity, Inspections is a formal review and generally need is predefined at the start of the product planning, The objectives of the inspection process are to · Find problems at the earliest possible point in the software development process
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 5 IDOL, University of Mumbai
· Verify that the work product meets its requirement · Ensure that work product has been presented according to predefined standards · Provide data on product quality and process effectiveness · Inspection advantages are to build technical knowledge and skill among team members by reviewing the output of other people · Increase the effectiveness of software testing. IEEE 1028 recommends three following roles in an Inspection: Inspector Leader: The inspection leader shall be responsible for administrative tasks pertaining to the inspection, shall be responsible for planning and preparation, shall ensure that the inspection is conducted in an orderly manner and meets its objectives, should be responsible for collecting inspection data Recorder: The recorder should record inspection data required for process analysis. The inspection leader may be the recorder. Reader: The reader shall lead the inspection team through the software product in a comprehensive and logical fashion, interpreting sections of the work product and highlighting important aspects Author: The author shall be responsible for the software product meeting its inspection entry criteria, for contributing to the inspection based on special understanding of the software product, and for performing any rework required to make the software product meet its inspection exit criteria. Inspector: Inspectors shall identify and describe anomalies in the software product. Inspectors shall be chosen to represent different viewpoints at the meeting (for example, sponsor, requirements, design, code, safety, test, independent test, project management, quality management, and hardware engineering). Only those viewpoints pertinent to the inspection of the product should be present. Some inspectors should be assigned specific review topics to ensure effective coverage. For example, one inspector may focus on conformance with a specific standard or standards, another on syntax, and another for overall coherence. These roles should be assigned by the inspection leader when planning the inspection. All participants in the review are inspectors. The author shall not act as inspection leader and should not act as reader or recorder. Other roles may be shared among the team members. Individual participants may act in more than one role. Individuals holding management positions over any member of the inspection team shall not participate in the inspection Inspection Process: Following are review phases: · Planning · Overview · Preparation · Examination meeting Planning: · Inspection Leader perform following task in planning phase · Determine which work products need to be inspected · Determine if a work product that needs to be inspected is ready to be inspected · Identify the inspection team · Determine if an overview meeting is needed. The moderator ensures that all inspection team members have had inspection process training. The moderator obtains a commitment from each team member to participate. This commitment means the person agrees to spend the time required to perform his or her assigned role on the team. Identify the review materials required for the inspection, and distribute materials to relevant stake holders Overview: Purpose of the overview meeting is to educate inspectors; meeting is lead by Inspector lead and is presented by author, overview is presented for the inspection, this meeting normally acts as optional meeting, purpose to sync the entire participant and the area to be inspected. Preparation: Objective of the preparation phase is to prepare for the inspection meeting by critically reviewing the review materials and the work product, participant drill down on the document distributed by the lead inspector and identify the defect before the meeting Examination meeting: The objective of the inspection meeting is to identify final defect list in the work product being
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 6 IDOL, University of Mumbai
inspected, based on the initial list of defects prepared by the inspectors [identified at preparation phase and the new one found during the inspection meeting. The Lead Auditor opens the meeting and describes the review objectives and area to be inspected. Identify that all participants are well familiar with the content material, Reader reads the meeting material and inspector finds out any inconsistence, possible defects, and improvement suggestions to the author. Recorder records all the discussion during the inspection meeting, and mark actions against the relevant stake holders. Lead Inspector may take decision that if there is need of follow up meeting. Author updates the relevant document if required on the basis of the inspection meeting discussion Rework and Follow-up: Objective is to ensure that corrective action has been taken to correct problems found during an inspection.
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 7 IDOL, University of Mumbai
Date: 24/10/09 PRACTICAL NO.2
AIM: SRS document of hospital management system. Payroll system requirement analysis. SRS for CD-shop system.
DESCRIPTION:
(1) The system must be able to find old records or history of old patients. Every functionality of the system should be computerised. There should be a facility of data entry. Receptionist or computer will enter the data and management person can generate report on that data.
(2) In earlier system receptionists or computer has to keep registers such as patients register, employee register. Patients register includes personal and general information about the patients like case paper, treatment details, bills etc. Similarly employee register may include designation, address, phone number etc.
(3) There should be a facility of storing patient information according to the symptoms and diagnosis. The system should be able to calculate but for particular patient. The system should be able to handle indoor and outdoor patients
(4) The system should be able to maintain day to day treatment given to the patient. The administrator should to able to access through login and password.
(5) Most of the functionality, the doctor details are not mentioned in the requirement. Mention it in the requirement specific document.
(6) The system not mentioning emergency facility to patients separately. The system should include static page to display details about emergency facility provided by ambulance.
Appreciable part:
(1) The system is able to convert outdoor patient into indoor patient by using single model. (2) The system is able to search and sort historical records. The system is able to generate bill
automatically after receiving concerned information about the patients.
Defect deficiency (1)The system is not having model to handle insurance (2)Insurance (3)No module to handle stock of medicine
comment / suggestions (1)There should be a model which will have insurance details such as insurance number, patients mode of payment etc (2) Claim amount (3)There should be a module which should handle stock of medicine
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 8 IDOL, University of Mumbai
Payroll system requirement analysis: (1) There are different modules and those modules have login details, personal details, professional details,
salary details, other payment details and reports. Personal detail consist of 55 numbers. (2) There are two types of users that is administrator, clerk. The system should provide login and password
to these users. (3) Personal details: it includes social security number, full name of the employee, gender, address, date of
birth, marital status, and bank a/c number. (4) Professional details if employee will be employees ID, date of joining, past experience of termination
and overtime hours. (5) Salary details should include number of days a particular employee works, basic HRA, CA, TA, DA,
attendance detail of a particular employee are considered, provident fund, taxes, loans, bonus, mode of payment, cheque number, A/C number. The system should be able to generate payslip of a selected employee.
Defect / Deficiency (1) The system is insufficient in handling long term
leaves. (2) The system is not able to handle late mark details. (3) There are two separate modules to handle
allowances included in salary and deductions, subtraction from salary
(4) The system is for government sector, it is not providing facilities to handle VRS and retirement schemes.
Comments (1) Long term leaves should be handled in the system (2) In attendance module there should be a facility to
handle (3) Salary details and payment details modules can be
combined together.
(4) In professional details module, there should be facilities to handle VRS and retirement schemes
The designs of the system are crystal clear so that the developers can develop very fast. SRS for CD scope system:
(1) An application must have a login page for users and administrators to login to the system. If the user is new, then his account must be created in the system by letting him register through ‘New User ID’ option. Also if there are any existing users who want to change their password, then the login page must provide ‘Change password’ option to the user.
(2) once login to the system, administrator or user must get option to add, delete and update the existing users profile (i.e. user ID, name, membership type etc.) this option must be available to only users with administrative privilege.
(3) Also the administrator must be able to change or add information related to CD’s in the shop like CD’s name etc.
(4) Under the transaction details, administrator must be able to see all the available details in the shop. Also he must be able to get the information about the CD’s rented to the users and their information. If the customer is having a discount offer than application user must also decide the rent of him. If the customer brings the CD after date than application user must calculate appropriate fine for him.
(5) The user must be able to generate reports on various types like customer reports which may include customer ID, name, address, contact numbers, CD details which may include CD name, CD types, rent,
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 9 IDOL, University of Mumbai
availability etc. CD access report may give information about who were the members rented the particular CD and for how long. The fine reports may include information of customer who had to pay fine.
(6) The utility option in the application may include various user friendly options like calculators, changing the background colour, backup the database etc.
Defect / Deficiency
(1) There was a confusion in the terms that who is a customer and who is a member
Comments We can call user and customer with a one name to avoid confusion.
Functional requirement:
R1: add new customer Descriptions: The user selects customer details option from menu. Then he will be provided with the facilities to add new customer details in the database. R1.1: add new customer details Input: click on add button Output: user is asked to fill up the details name, address, mobile number etc. R1.2: save user record Input: click save button Output: entered details such as name, address, mobile number etc will be saved in the database. R2: modify customer record. Description: the user selects customer details option from the menu. Then he will be provided with the facility to modify customer details. R2.1: Modify existing customer details. Input: click on modify button Output: user is allowed to edit the existing data which will change the database R2.2: save modified record Input: click on save button Output: The detail of existing customer that are edited will be saved R3: Delete existing customer record Description: user is allowed to completely remove or delete the particular record in the database. Input: click on delete button Output: the particular record of customer is deleted from the database R4: navigation through all existing customers Description: for navigation buttons are provided to navigate through all the records which are available in the database. R4.1: moving to the previous record Input: click on first navigation buttons Output: The details of previous customer records will be displayed.
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 10 IDOL, University of Mumbai
R4.2: moving to the next record Input: click on last navigation buttons Output: The details of next customer records will be displayed. R4.3: moving to the first record Input: click on second navigation buttons Output: The details of first customer records will be displayed. R4.4: moving to the last record Input: click on third navigation buttons Output: directly details of last customer records will be displayed. R5: add CD details Description: the user selects add CD option from the menu. Then he will be provided with facility to add new CD details R5.1: select language of CD i.e. hindi, English or Marathi Input: click on any one of the radio button provided for language selection Output: one of the radio button for language will be selected and that language will be saved in database. R5.2: add CD details Input: click on add button. Output: user is asked to fill details in the CD i.e. name, address etc. R5.3: save CD details Input: click on save button after adding Output: the details will be saved. R5.4: update CD details Input: Click on update button and then save button. Output: The new value is stored in the data R5.5: Delete CD details Input: Click on delete button. Output: existing record of CD will be deleted from the database R6: CD issue details Description: The user selects CD from the transaction menu when a customer comes to issue CD. CD ID, CD name, customer ID, customer name entered manually. R6.1: save CD details with customer details Input: click on save button. Output: entered details such as CD ID, CD name, customer ID, customer name are saved in database. R6.2: showing CD details and customer details Input: click on show button. Output: All CD details and customer details from the database are shown. R7: CD return details
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 11 IDOL, University of Mumbai
Description: Whenever customer returns any issued CD, then all his return details will be entered in the CD returned from transaction. R7.1: Saving CD return details Input: click on save button. Output: All CD details like CD name, customer ID, customer name all are saved from the database. R7.2: Showing CD return details Input: click on show button. Output: All CD return details like CD name, customer ID, customer name all are saved from the database shown. R8: fine details form Description: User is allowed to select fine details form transaction menu. To fill in the fine details if any about the customer who have to pay fine Input: add save, delete, update, close, show buttons. Output: Fine details are added, saved, deleted, updated and showed. R9: add membership details Description: the membership details are added by using membership transaction from transaction menu. Details like customer ID and membership types are used. R10: search the CD. Description: once the user selects search CD option, he would be asked to enter CD name. The system should search the CD in detail of all the CD’s whose title matches with entered name. R10.1: search and display CD details. Input: enter CD name. Output: Detail of all the CD’s with matching titles are displayed with their details like CD number, title etc. R11: Search the customer with ID. Description: System should allow to search.
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 12 IDOL, University of Mumbai
Date: 28/10/09
AIM: To generate unit testing report for CD Library shop. DESCRIPTION: Unit testing: it focuses verification effort on the smallest unit of the software In unit testing important central parts are tested to uncover the errors within the boundary of the module. The unit test is a white box oriented and the step can be conducted parallel for multiple compounds. The main attribute of unit testing is the software components/units are tested individually or isolated from all other software compound of the system. The most important task of unit testing is to generate that the particular test objects execute it entire functionality, correct and completely as required by the specification. Unit testing is very closely related to development. The tester usually has access to the source code, which makes unit testing the dominant of whit box testing
Module Name:‐ Login Window Pre‐requisite:‐ Application should be installed Type of Testing:‐ Unit Testing
Serial No.
Requirement Test Case ID
Test Case Objective
Prerequisite Description Input Data Expected Output
Actual Output
Result
1 Application allows
administrator to login into
system
Login_01 To check login for admin
Run as application
Enter admin name in login field and his password
in password
field
Login:‐Administrator,pwd‐applet,Click Login
Login should be done
Login is done
Pass
2 Application allows
administrator to login into
system
Login_02 To check login for admin
Run as application
Enter admin name in login field and his password
in password
field
Login:‐Administrator, pwd‐xyz, Click
Login
Login should not be done
Login is not done
Pass
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 13 IDOL, University of Mumbai
3 Application allows clerk to login into
system
Login_03 To check login for clerk
Run as application
Enter Clerk name in login field and his password
in password
field
Login:‐Clerk, pwd‐Clerk, Click Login
Login should be done
Login is done
Pass
4 Application allows clerk to login into
system
Login_04 To check login for clerk
Run as application
Enter Clerk name in login field and his password
in password
field
Login:‐Clerk, pwd‐abc, Click Login
Login should not be done
Login is not done
Pass
5 Application allows to create new
user
Login_05 To create new clerk
Administrator pwd must be supplied
Enter admin pwd, clickon
new user, enter
username, pwd and click on create
New user must be created
user is created
User is created
pass
6 Application allows to create new
user
Login_06 To create new clerk
Administrator pwd is not supplied
Click on new user
Click on new user pwd field blank error
message displayed
Wrong admin pwd
Fail
7 Application allows to
change pwd
Login_07 To change pwd
Login id and pwd
Click on change pwd
Login:‐Administrator,pwd‐applet, newpwd:‐
abc
Password changed
Password changed
Pass
Project Name:‐ CD Library Version:‐1.0 Module Name:‐ MDIForm1 Pre‐requisite:‐ Application should be installed Type of Testing:‐ Unit Testing
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 14 IDOL, University of Mumbai
Serial No. Requirement Test Case ID
Test Case Objective Prerequisite Description Input Data
Expected Output
Actual Output Result
1
Application allows user to open CD Details Form MDIForm_01
To check the opening of form
Run as application
Click on the respective Menu items
Click CD Details Form
Form should load
Form is loaded Pass
2
Application allows user to open Customer Details Form MDIForm_02
To check the opening of form
Run as application
Click on the respective Menu items
Click Customer Details Details Form
Form should load
Form is loaded Pass
3
Application allows user to open CD Access Form MDIForm_03
To check the opening of form
Run as application
Click on the respective Menu items
Click CD Access Form
Form should load
Form is loaded Pass
4
Application allows user to open CD Return Form MDIForm_04
To check the opening of form
Run as application
Click on the respective Menu items
Click CD Return Form
Form should load
Form is loaded Pass
5
Application allows user to open Fine Details Form MDIForm_05
To check the opening of form
Run as application
Click on the respective Menu items
Click Fine Details Form
Form should load
Form is loaded pass
6
Application allows user to open Member Transaction Form MDIForm_06
To check the opening of form
Run as application
Click on the respective Menu items
Click on Member Transaction Form
Form should load
Form is loaded pass
7
Application allows user to open Customer Search Form MDIForm_07
To check the opening of form
Run as application
Click on the respective Menu items
Click on Customer Search Form
Form should load
Form is loaded Pass
8
Application allows user to open CD Search Form MDIForm_08
To check the opening of form
Run as application
Click on the respective Menu items
Click on CD Search Form
Form should load
Form is loaded Pass
9
Application allows user to open CD Return Search Form MDIForm_09
To check the opening of form
Run as application
Click on the respective Menu items
Click on CD Return Search Form
Form should load
Form is loaded Pass
10 Application MDIForm_10 To check Run as Click on Click on Fine Form Form Pass
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 15 IDOL, University of Mumbai
allows user to open Fine Search Form
the opening of form
application the respective Menu items
Search Form should load
is loaded
11
Application allows user to open Membership Search Form MDIForm_11
To check the opening of form
Run as application
Click on the respective Menu items
Click on Membership Search Form
Form should load
Form is loaded Pass
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 16 IDOL, University of Mumbai
Date: 29/10/09 PRACTICAL NO.4
AIM: To create SRS for school management system. 1: Introduction : The project for the Zilla Parishad School will prove very useful since it is very much reliable and GUI based.
A) Background
The Proposed project has many advantages over the present existing project. The main features of the proposed project are as follows: - The project is fully GUI based with many user-friendly features. It has high data security due to the presence of login passwords. There are many validations at most places to prevent invalid data entries. High durability of the data as compared to the present system. Searching of previously entered data on just entering the primary key. Report generation as per the most common needs of management. Additional supports provided during entry of data.
B)Overall Description 1.Collection of forms by the Students 2.Submission of forms by the Students 3.Admission Process get started 4.Student want to cancel the admission 5.New Teacher 6.Start of working day 7.Exams get started 8.Generation of Results 9.Management request for the Salary Report 10.Management request for the Student’s Attendance Report 11.Management request for the Teacher’s Attendance Report 12.Management request for the Student’s Result Report 13.Students get the admission in the school c) Environment Characteristics
The front end of the system is in Visual Basic & back end is MS-Access. i)H/W Pentium Processor, Mouse Keyboard, 512MB Ram, Screen, Manual Operator(Clerk) for data entry. ii)S/W Visual Basic 6.0, Windows XP/NT, Microsoft Access iii)User Clerk or data entry operator 2: Goals of implementation
The Proposed project has many advantages over the present existing project. The main features of the proposed project are as follows: -
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 17 IDOL, University of Mumbai
The project is fully GUI based with many user-friendly features. It has high data security due to the presence of login passwords. There are many validations at most places to prevent invalid data entries. High durability of the data as compared to the present system. Searching of previously entered data on just entering the primary key. Report generation as per the most common needs of management. Additional supports provided during entry of data. 3: Functional Requirement
R1 : Staff Master Description The staff details are entered through this form. Input: Entered Details in the form are saved if successful. Output: Success or error message. R1.1 )Add Button Description: Add a new record in the database Input: Click the add button Output: The fields are cleared and the user can enter new data. R1.2 )Modify Button Description: Modify an existing record in the database Input: Click the Modify button Output: The fields are altered as per the user needs. R1.3 )Update Button Description: Save the modified record to the database Input: Click the update button Output: The modified fields are saved if successful. R1.4 ) Save Button Description: Save a new record in the database Input: Click the save button Output: The fields are saved if successful. R1.5 )Cancel Button Description: Cancel the entered data in the fields Input: Click the cancel button Output: The fields are cleared and the pointer jumps to the last record. R1.6 )Delete Button Description: Delete an existing record in the database Input: Click the delete button Output: The current record is deleted R1.7) Search by name Description: Search through the database Input: Enter the name of the staff and click the search button Output: The pointer is navigated to the searched record if found otherwise a failure message is displayed. R1.8) Search by ID Description: Search through the database Input: Enter the id of the staff and click the search button Output: The pointer is navigated to the searched record if found otherwise a failure message is displayed.
R2 : Student Master Description
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 18 IDOL, University of Mumbai
The student details are entered through this form. Input: Entered Details in the form are saved if successful. Output: Success or error message. R2.1 )Add Button Description: Add a new record in the database Input: Click the add button Output: The fields are cleared and the user can enter new data. R2.2 )Modify Button Description: Modify an existing record in the database Input: Click the Modify button Output: The fields are altered as per the user needs. R2.3 )Update Button Description: Save the modified record to the database Input: Click the update button Output: The modified fields are saved if successful. R2.4 ) Save Button Description: Save a new record in the database Input: Click the save button Output: The fields are saved if successful. R2.5 )Cancel Button Description: Cancel the entered data in the fields Input: Click the cancel button Output: The fields are cleared and the pointer jumps to the last record. R2.6 )Delete Button Description: Delete an existing record in the database Input: Click the delete button Output: The current record is deleted R2.7) Search by name Description: Search through the database Input: Enter the name of the student and click the search button Output: The pointer is navigated to the searched record if found otherwise a failure message is displayed. R2.8) Search by ID Description: Search through the database Input: Enter the id of the student and click the search button Output: The pointer is navigated to the searched record if found otherwise a failure message is displayed.
R3 : Student Attendance Details
Description The student attendance details are entered through this form. Input: Entered Details in the form are saved if successful. Output: Success or error message. R3.1 )Add Button Description: Add a new record in the database Input: Click the add button Output: The fields are cleared and the user can enter new data. R3.2 )Modify Button Description: Modify an existing record in the database Input: Click the Modify button
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 19 IDOL, University of Mumbai
Output: The fields are altered as per the user needs. R3.3 )Update Button Description: Save the modified record to the database Input: Click the update button Output: The modified fields are saved if successful. R3.4 ) Save Button Description: Save a new record in the database Input: Click the save button Output: The fields are saved if successful. R3.5 )Cancel Button Description: Cancel the entered data in the fields Input: Click the cancel button Output: The fields are cleared and the pointer jumps to the last record. R3.6 )Delete Button Description: Delete an existing record in the database Input: Click the delete button Output: The current record is deleted R3.7) Search by division Description: Search through the database Input: Enter the division of the student and click the search button Output: The pointer is navigated to the searched record if found otherwise a failure message is displayed. R3.8) Search by Standard Description: Search through the database Input: Enter the standard of the student and click the search button Output: The pointer is navigated to the searched record if found otherwise a failure message is displayed.
R4 : Staff Attendance Details
Description The staff attendance details are entered through this form. Input: Entered Details in the form are saved if successful. Output: Success or error message. R4.1 )Add Button Description: Add a new record in the database Input: Click the add button Output: The fields are cleared and the user can enter new data. R4.2 )Modify Button Description: Modify an existing record in the database Input: Click the Modify button Output: The fields are altered as per the user needs. R4.3 )Update Button Description: Save the modified record to the database Input: Click the update button Output: The modified fields are saved if successful. R4.4 ) Save Button Description: Save a new record in the database Input: Click the save button Output: The fields are saved if successful. R4.5 )Cancel Button Description: Cancel the entered data in the fields
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 20 IDOL, University of Mumbai
Input: Click the cancel button Output: The fields are cleared and the pointer jumps to the last record. R4.6 )Delete Button Description: Delete an existing record in the database Input: Click the delete button Output: The current record is deleted
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 21 IDOL, University of Mumbai
R5 : Pay Slip Transaction
Description The pay slip details are entered through this form. Input: Entered Details in the form are saved if successful. Output: Success or error message. R5.1 )Add Button Description: Add a new record in the database Input: Click the add button Output: The fields are cleared and the user can enter new data. R5.2 )Modify Button Description: Modify an existing record in the database Input: Click the Modify button Output: The fields are altered as per the user needs. R5.3 )Update Button Description: Save the modified record to the database Input: Click the update button Output: The modified fields are saved if successful. R5.4 ) Save Button Description: Save a new record in the database Input: Click the save button Output: The fields are saved if successful. R5.5 )Cancel Button Description: Cancel the entered data in the fields Input: Click the cancel button Output: The fields are cleared and the pointer jumps to the last record. R5.6 )Delete Button Description: Delete an existing record in the database Input: Click the delete button Output: The current record is deleted R5.7) Navigational Buttons Description: Navigate through the database. Input: Click the respective buttons Output: The pointer is navigated to the searched record if found otherwise a failure message is displayed. R5.8) Pay Slip Button Description: Generate the pay slip for the respective employees Input: Click the pay slip button Output: A report is displayed, containing the pay slip details R6 :Result Transaction Details Description The result transaction details are entered through this form. Input: Entered Details in the form are saved if successful. Output: Success or error message. R6.1 )Add Button Description: Add a new record in the database Input: Click the add button Output: The fields are cleared and the user can enter new data. R6.2 )Modify Button Description: Modify an existing record in the database
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 22 IDOL, University of Mumbai
Input: Click the Modify button Output: The fields are altered as per the user needs. R6.3 )Update Button Description: Save the modified record to the database Input: Click the update button Output: The modified fields are saved if successful. R6.4 ) Save Button Description: Save a new record in the database Input: Click the save button Output: The fields are saved if successful. R6.5 )Cancel Button Description: Cancel the entered data in the fields Input: Click the cancel button Output: The fields are cleared and the pointer jumps to the last record. R6.6 )Delete Button Description: Delete an existing record in the database Input: Click the delete button Output: The current record is deleted R6.7) Navigational Buttons Description: Navigate through the database. Input: Click the respective buttons Output: The pointer is navigated to the searched record if found otherwise a failure message is displayed. R6.8) Get Total Button Description: Generate the total of marks for the respective student Input: Click the get total button Output: The total of the marks is displayed in a field named “Total”, Grade and Percentage are automatically calculated Non Functional Requirements 1. Correct entry and not fictional data. 2. Backup of back end database must be done at periodic intervals. 3. Response time is not real time. 4. Security of data – Data is not encrypted in the database, only username password facility is to be provided 5. Must run under configuration which are mentioned previously in hardware and software requirements.
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 23 IDOL, University of Mumbai
Date: 29/10/09 PRACTICAL NO.5
AIM:
To perform black box testing of given programs using equivalence class partitioning method.
a. Test given programs using Equivalence class partitioning b. Find out any defects in given programs
Apply Equivalence class partitioning method of testing for application School management system DESCRIPTION: Equivalence class partitioning Equivalence partitioning is a software testing technique that divides the input data of a software unit into partition of data from which test cases can be derived. In principle, test cases are designed to cover each partition at least once. This technique tries to define test case that uncovers classes of errors, thereby reducing the total number of test cases that must be developed. In rare cases equivalence partitioning is also applied to outputs of a software component, typically it is applied to the inputs of a tested component. The equivalence partitions are usually derived from the requirements specification for input attributes that influence the processing of the test object. An input has certain ranges which are valid and other ranges which are invalid. Invalid data here does not mean that the data is incorrect, it means that this data lies outside of specific partition. This may be best explained by the example of a function which takes a parameter "month". The valid range for the month is 1 to 12, representing January to December. This valid range is called a partition. In this example there are two further partitions of invalid ranges. The first invalid partition would be <= 0 and the second invalid partition would be >= 13. The testing theory related to equivalence partitioning says that only one test case of each partition is needed to evaluate the behaviour of the program for the related partition. In other words it is sufficient to select one test case out of each partition to check the behaviour of the program. To use more or even all test cases of a partition will not find new faults in the program. The values within one partition are considered to be "equivalent". Thus the number of test cases can be reduced considerably. An additional effect by applying this technique is that you also find the so called "dirty" test cases. An inexperienced tester may be tempted to use as test cases the input data 1 to 12 for the month and forget to select some out of the invalid partitions. This would lead to a huge number of unnecessary test cases on the one hand, and a lack of test cases for the dirty ranges on the other hand.
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 24 IDOL, University of Mumbai
SOURCE CODE: a) Test given programs using Equivalence class partitioning Program1: //This program categorize a person according to height #include<iostream.h> #include<conio.h> void main() { clrscr(); int height; cout<<"\nEnter height of a person in centimeter:"; cin>>height; if(height <= 150) cout<<"\nShort"; else if(height < 170) cout<<"\nMedium"; else cout<<"\nTall"; getch(); }
Test no. Prerequisite Input values
Expected result
Actual result
Remarks
T1.1 height<=150 150 Short Short Pass T1.2 151<=height<=170 170 Medium Tall Fail T1.3 height>=171 172 Tall Tall Pass T1.4 height <= 0 -5 Error Program
Quits Fail
T1.5 height >= 250 300 Error Program Quits
Fail
Program Number Line number Actual Deficiencies
Required Statement
1 16 Medium Height categorized as Tall
else if(height <= 170)
2 NA Error message not displayed on invalid input
if(height <= 0 || height >170 ) cout << “Input values are not
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 25 IDOL, University of Mumbai
valid” exit(1);
Corrected Program: #include<iostream.h> #include<conio.h> void main() { clrscr(); int height; cout<<"\nEnter height of a person in centimeter:"; cin>>height; if(height <= 150) cout<<"\nShort"; else if(height <= 170) cout<<"\nMedium"; else cout<<"\nTall"; if(height <= 0 || height >250) { cout << “Invalid input”; exit(1); } getch(); } Program 2: //This program categorize a person according to weight #include<iostream.h> #include<conio.h> void main() { clrscr(); int weight; cout<<"\nEnter weight of a person in kilograms:"; cin>>weight; if(weight <= 50)
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 26 IDOL, University of Mumbai
cout<<"\nThin"; else if( weight > 50 && weight <= 75 ) cout<<"\nMedium"; else cout<<"\nFat"; getch(); }
Test no. Prerequisite Input values
Expected result
Actual result
Remarks
T2.1 weight<=50 50 Thin Thin Pass T2.2 51<=weight<=75 75 Medium Medium Pass T2.3 weight>=76 80 Fat Fat Pass T2.4 weight <= 0 -5 Error Program
Quits Fail
T2.5 weight >= 250 255 Error Program Quits
Fail
Program Number Line number Actual Deficiencies
Required Statement
2 13 Extra code else if (weight <=75)
Corrected Program 2: #include<iostream.h> #include<conio.h> void main() { clrscr(); int weight; cout<<"\nEnter weight of a person in kilograms:"; cin>>weight; if(weight <= 50) cout<<"\nThin"; else if(weight <= 75 ) cout<<"\nMedium"; else cout<<"\nFat";
if(weight <= 0 || weight >250)
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 27 IDOL, University of Mumbai
{ cout << “Invalid input”; exit(1);
} getch(); } Program3: //This program categorize a person according to height and weight #include<iostream.h> #include<conio.h> void main() { clrscr(); int height,weight; cout<<"\nEnter height of a person in centimeter:"; cin>>height; cout<<"\nEnter weight of a person in kilograms:"; cin>>weight; if(height <=151) { if(weight <= 50) cout<<"\nShort in height and thin by weight"; else if( weight <= 75 ) cout<<"\nShort in height and medium by weight"; else cout<<"\nShort in height and fat by weight"; } else if(height <= 170) { if(weight <= 50) cout<<"\nMedium in height and thin by weight"; else if( weight <= 75 ) cout<<"\nMedium in height and medium by weight"; else cout<<"\nMedium in height and fat by weight"; } else { if(weight <= 50)
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 28 IDOL, University of Mumbai
cout<<"\nTall in height and thin by weight"; else if( weight <= 75 ) cout<<"\nTall in height and medium by weight"; else cout<<"\nTall in height and fat by weight"; } getch(); } Test no. Prerequisite Input
values Expected result
Actual result
Remarks
T3.1 (height<=150) and (weight<=50)
height = 150 weight =50
Short in height and thin by weight
Short in height and thin by weight
Pass
T3.2 (height<=150) and (51<=weight<=75)
height = weight =
Short in height and medium by weight
Short in height and medium by weight
Pass
T3.3 (height<=150) and (weight>=76)
height = weight =
Short in height and fat by weight
Short in height and fat by weight
Pass
T3.4 (151<=height<=170) and (weight<=50)
height = weight =
Medium in height and thin by weight
Medium in height and thin by weight
Pass
T3.5 (151<=height<=170) and (51<=weight<=75)
height = weight =
Medium in height and medium by weight
Medium in height and medium by weight
Pass
T3.6 (151<=height<=170) and (weight>=76)
height = weight =
Medium in height and fat by weight
Medium in height and fat by weight
Pass
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 29 IDOL, University of Mumbai
T3.7 (height>=171) and (weight>=76)
height = weight =
Tall in height and thin by weight
Tall in height and thin by weight
Pass
T3.8 (height>=171) and (weight<=50)
height = weight =
Tall in height and medium by weight
Tall in height and medium by weight
Pass
T3.9 (height>=171) and (weight>=76)
height = weight =
Tall in height and fat by weight
Tall in height and fat by weight
Pass
T3.10 (height<=0) and (weight<=0)
height = -5 weight =-10
Error Program quits
Fail
T3.11 (height>=250) and (weight >=250)
height = 260 weight =250
Error Program quits
Fail
Program Number Line number Actual
Deficiencies Required Statement
3 12 Incorrect values if (height<=150) Corrected Program 3: //This program categorize a person according to height and weight #include<iostream.h> #include<conio.h> void main() { clrscr(); int height,weight; cout<<"\nEnter height of a person in centimeter:"; cin>>height; cout<<"\nEnter weight of a person in kilograms:";
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 30 IDOL, University of Mumbai
cin>>weight; if(height <=150) { if(weight <= 50) cout<<"\nShort in height and thin by weight"; else if( weight <= 75 ) cout<<"\nShort in height and medium by weight"; else cout<<"\nShort in height and fat by weight"; } else if(height <= 170) { if(weight <= 50) cout<<"\nMedium in height and thin by weight"; else if( weight <= 75 ) cout<<"\nMedium in height and medium by weight"; else cout<<"\nMedium in height and fat by weight"; } else { if(weight <= 50) cout<<"\nTall in height and thin by weight"; else if( weight <= 75 ) cout<<"\nTall in height and medium by weight"; else cout<<"\nTall in height and fat by weight"; } if((height<=0 || height>=250)||(weight <= 0 || weight >=250)) { cout << “Invalid input”; exit(1); } getch(); } b) Apply Equivalence class partitioning method of testing an application “School Management
System” Application: School Management system Module: Staff Details Type of testing: Black box(Equivalent class partitioning) Field: Phone number
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 31 IDOL, University of Mumbai
Test case number
Prerequisite Input values Expected result
Actual result
Remark
SCM_01 9000000000<=number<=9999999999 9820469660 It Should accept
Phone number is accepted
Pass
SCM_02 Number>99999999999 982046966055 It should not be accepted
Phone number is not accepted
Pass
SCM_03 Number<9000000000 10 It should not be accepted
Phone number is not accepted
Pass
Application: School Management system Module: Staff Details Type of testing: Black box(Equivalent class partitioning) Field: Basic Payment Test case number
Prerequisite Input values
Expected result
Actual result
Remark
SCM_01 300<=basic payment<=15000
10000 It Should accept
Basic payment is accepted
Pass
SCM_02 Basic Payment>15000
15001 It should not be accepted
Basic payment is not accepted
Pass
SCM_03 Basic Payment <300
299 It should not be accepted
Basic payment is not accepted
Pass
Application: School Management system Module: Staff Details Type of testing: Black box(Equivalent class partitioning) Field: Date of Birth Test case number
Prerequisite Input values
Expected result
Actual result
Remark
SCM_01 Date of 05/10/1970 It Should Date of Pass
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 32 IDOL, University of Mumbai
Establishment>Date of Birth<Date of Joining
accept birth is accepted
SCM_02 Date of Joining <= Date of Birth
05/10/2000 It should not be accepted
Date of Birth is accepted
Fail
Note: Date of Establishment is assumed to be 05/10/1989 Date of Joining is assumed to be 05/10/1991 Application: School Management system Module: Staff Details Type of testing: Black box(Equivalent class partitioning) Field: Date Of Retirement Test case number
Prerequisite Input values
Expected result
Actual result
Remark
SCM_01 Date of Joining<=Date of Retirement
05/11/1991 It Should accept
Date of Retirement is accepted
Pass
SCM_02 Date of Joining>Date of Retirement
05/09/1991 It should not be accepted
Date of Retirement is accepted
Fail
SCM_03 Date of Retirement >=Date Of Establishment
05/11/1991 It should be accepted
Date Of Retirement is accepted
Pass
SCM_04 Date of Retirement <Date Of Establishment
05/11/1921 It should not be accepted
Date Of Retirement is accepted
Fail
Note: Date of Establishment is assumed to be 05/10/1989 Date of Joining is assumed to be 05/10/1991 Application: School Management system Module: Staff Details Type of testing: Black box(Equivalent class partitioning) Field: Search By ID Test case number
Prerequisite Input values
Expected result
Actual result
Remark
SCM_01 ID<1 0 It Should not be
Id is not accepted
Pass
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 33 IDOL, University of Mumbai
accepted SCM_02 0>ID<=Upper
limit 5 It should
be accepted
Id is accepted
Pass
SCM_03 ID>Upper Limit
299 It should not be accepted
Id is not accepted
Pass
Note: Upper limit is the last record in the particular table in the database Application: School Management system Module: Student Details Type of testing: Black box(Equivalent class partitioning) Field: Standard Test case number
Prerequisite Input values
Expected result
Actual result
Remark
SCM_01 Standard<1 0 It Should not be accepted
Standard is not accepted
Pass
SCM_02 0>Standard<=9 5 It should be accepted
Standard is accepted
Pass
SCM_03 Standard>9 15 It should not be accepted
Standard is not accepted
Pass
Application: School Management system Module: Student Details Type of testing: Black box(Equivalent class partitioning) Field: Total Annual Income Test case number
Prerequisite Input values
Expected result
Actual result
Remark
SCM_01 300<=total annual income<=15000
10000 It Should accept
Total Annual Income is accepted
Pass
SCM_02 Total Annual Income>15000
15001 It should not be accepted
Total Annual Income is not accepted
Pass
SCM_03 Total Annual Income <300
299 It should not be
Total Annual
Pass
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 34 IDOL, University of Mumbai
accepted Income is not accepted
Application: School Management system Module: PaySlip Details Type of testing: Black box(Equivalent class partitioning) Field: Dearness Allowance(DA) Test case number
Prerequisite Input values
Expected result
Actual result
Remark
SCM_01 300<=DA<=5000 10000 It Should accept
DA is accepted
Pass
SCM_02 DA>5000 15001 It should not be accepted
DA is not accepted
Pass
SCM_03 DA <300 299 It should not be accepted
DA is not accepted
Pass
Application: School Management system Module: PaySlip Details Type of testing: Black box(Equivalent class partitioning) Field: Travelling Allowance (TA) Test case number
Prerequisite Input values
Expected result
Actual result
Remark
SCM_01 300<=TA<=2000 10000 It Should accept
TA is accepted
Pass
SCM_02 TA>2000 15001 It should not be accepted
TA is not accepted
Pass
SCM_03 TA <300 299 It should not be accepted
TA is not accepted
Pass
Application: School Management system Module: PaySlip Details
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 35 IDOL, University of Mumbai
Type of testing: Black box(Equivalent class partitioning) Field: Housing Rent Allowance Allowance(HRA) Test case number
Prerequisite Input values
Expected result
Actual result
Remark
SCM_01 300<=HRA<=2500 10000 It Should accept
HRA is accepted
Pass
SCM_02 HRA>2500 15001 It should not be accepted
HRA is not accepted
Pass
SCM_03 HRA <300 299 It should not be accepted
HRA is not accepted
Pass
Application: School Management system Module: PaySlip Details Type of testing: Black box(Equivalent class partitioning) Field: Income Tax Test case number
Prerequisite Input values
Expected result
Actual result
Remark
SCM_01 0<=Income Tax<=15000
10000 It Should accept
Income tax is accepted
Pass
SCM_02 Income Tax>=Basic Payment
15001 It should not be accepted
Income tax is not accepted
Pass
SCM_03 Income Tax<0
-299 It should not be accepted
Income tax is not accepted
Pass
SCM_04 Income Tax>=Gross Payment
16000 It should not be accepted
Income tax is not accepted
Pass
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 36 IDOL, University of Mumbai
Date: 7/11/09 PRACTICAL NO.6
AIM:
To perform black box testing of given programs using boundary value analysis (BVA) method
a. Test given programs using BVA b. Find out any defect in given program
Apply BVA for "School Management system" DESCRIPTION: Boundary value analysis Boundary value analysis is a software testing design technique in which tests are designed to include representatives of boundary values. Values on the edge of an equivalence partition or at the smallest value on either side of an edge. The values could be either input or output ranges of a software component. Since these boundaries are common locations for errors that result in software faults they are frequently exercised in test cases. The boundaries are the values on and around the beginning and end of a partition. If possible test cases should be created to generate inputs or outputs that will fall on and to either side of each boundary. This would result in three cases per boundary. The test cases on each side of a boundary should be in the smallest increment possible for the component under test. In the example above there are boundary values at 0,1,2 and 11,12,13. If the input values were defined as decimal datatype with 2 decimal places then the smallest increment would be the 0.01. Where a boundary value falls within the invalid partition the test case is designed to ensure the software component handles the value in a controlled manner.Boundary value analysis can be used throughout the testing cycle and is equally applicable at all testing phases. After determining the necessary test cases with equivalence partitioning and subsequent boundary value analysis, it is necessary to define the combinations of the test cases when there are multiple inputs to a software component.
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 37 IDOL, University of Mumbai
SOURCE CODE: a) Testing given programs using BVA // This program accepts any number between 1000 and 10000 (including both) and checks whether it is prime or not. Given program: #include<iostream.h> #include<conio.h> #include<stdlib.h> void main() { clrscr(); int lower = 1000; int upper = 10000; int num; cout<<"\nEnter any number between 1000 and 10000:\n"; cin>>num; if(num<lower || num>upper) { cout<<"Entered number is not in given range"; exit(0); } int flag = 0; for(int i=2;i<=num/2;i++) { if(num%i==0) { cout<<"Entered number is not prime"; flag = 1; break; } } if(flag == 1) { cout<<"entered number is prime"; } getch(); }
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 38 IDOL, University of Mumbai
Test cases for BVA of given program: Test case number
Prerequisite Input value
Expected result
Actual result
Remark
1 num=1000 1000 not prime number
Message: “Not prime number”
pass
2 num=10000 10000 not prime number
Message: “Not prime number”
prime
3 num=999 999 Not in range
Message ”Entered number is not in given range”
Pass
4 num=10001 10001 Not in range
Message ”Entered number is not in given range”
Pass
5 num in range 1000 to 10000
1002 not prime number
Message: “Not prime number”
Pass
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 39 IDOL, University of Mumbai
b) Find out any defect in given program Defect/ Deficiency in given program: Program number
Line number Actual defect/deficiency
Expected statement
1 29 Flag value is set incorrectly
If (flag==0)
Corrected program: #include<iostream.h> #include<conio.h> #include<stdlib.h> void main() { clrscr(); int lower = 1000; int upper = 10000; int num; cout<<"\nEnter any number between 1000 and 10000:\n"; cin>>num; if(num<lower || num>upper) { cout<<"Entered number is not in given range"; exit(0); } int flag = 0; for(int i=2;i<=num/2;i++) { if(num%i==0) { cout<<"Entered number is not prime"; flag = 1; break; } } if(flag == 0) { cout<<"entered number is prime"; } getch(); }
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 40 IDOL, University of Mumbai
c) Apply BVA for “School Management system” Application: School Management system Module: Student Details Type of testing: Black box(BVA) Field: Standard of a student Test case number
Prerequisite Input values
Expected result
Actual result
Remark
SMS_SD_01 Standard =1 1 It should be accepted
Standard is accepted
Pass
SMS_SD_02 Standard = 10
10 It should be accepted
Standard is accepted
Pass
SMS_SD_03 Standard < 1 0 It should not be accepted
Standard is not accepted
Pass
SMS_SD_04 Standard>10 11 It should not be accepted
Standard is not accepted
Pass
SMS_SD_05 1 <= Standard <= 10
5 It should be accepted
Standard is accepted
Pass
Application: School Management system Module: Staff Details Type of testing: Black box(BVA) Field: Phone number Test case number
Prerequisite Input values Expected result
Actual result
Remark
SMS_SD_01 Number= 9000000000 9000000000 It Should accept
Phone number is accepted
Pass
SMS_SD_02 Number=99999999999 99999999999 It should be accepted
Phone number is accepted
Pass
SMS_SD_03 Number<9000000000 10 It should not be accepted
Phone number is not accepted
Pass
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 41 IDOL, University of Mumbai
SMS_SD_04 Number>9999999999 10000000000000 It should not be accepted
Phone number is not accepted
Pass
SMS_SD_05 9000000000<=number<=9999999999 9820469660 It Should accept
Phone number is accepted
Pass
Application: School Management system Module: Staff Details Type of testing: Black box(BVA) Field: Basic Payment Test case number
Prerequisite Input values Expected result
Actual result
Remark
SMS_SD_01 Basic Payment= 300
300 It Should accept
Basic Payment is accepted
Pass
SMS_SD_02 Basic Payment = 15000
15000 It should be accepted
Basic Payment is accepted
Pass
SMS_SD_03 Basic Payment<300
10 It should not be accepted
Basic Payment is not accepted
Pass
SMS_SD_04 Basic Payement >15000
16000 It should not be accepted
Basic Payment is not accepted
Pass
SMS_SD_05 300<= Basic Payement <=15000
700 It Should accept
Basic Payement is accepted
Pass
Application: School Management system Module: Staff Details Type of testing: Black box(BVA) Field: Search By ID Test case Prerequisite Input values Expected Actual Remark
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 42 IDOL, University of Mumbai
number result result SMS_SD_01 ID= 1 1 It Should
accept ID is accepted
Pass
SMS_SD_02 ID= Upper limit Upper limit It should be accepted
ID is accepted
Pass
SMS_SD_03 ID<1 0 It should not be accepted
ID is not accepted
Pass
SMS_SD_04 ID>Upper limit Upper limit +2
It should not be accepted
ID is not accepted
Pass
SMS_SD_05 1<= ID <=Upper limit
2 It Should accept
ID is accepted
Pass
Note: Upper limit is the last record in the particular table in the database Application: School Management system Module: Student details Type of testing: Black box(BVA) Field: Total Annual Income Test case number
Prerequisite Input values Expected result
Actual result
Remark
SMS_SD_01 Total Annual Income = 300
300 It Should accept
Total Annual Income is accepted
Pass
SMS_SD_02 Total Annual Income = 15000
15000 It should be accepted
Total Annual Income is accepted
Pass
SMS_SD_03 Total Annual Income <300
10 It should not be accepted
Total Annual Income is not accepted
Pass
SMS_SD_04 Total Annual Income >15000
16000 It should not be accepted
Total Annual Income is not accepted
Pass
SMS_SD_05 300<= Total 700 It Should Total Pass
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 43 IDOL, University of Mumbai
Annual Income <=15000
accept Annual Income is accepted
Application: School Management system Module: PaysSlip Details Type of testing: Black box(BVA) Field: Dearness Allowance (DA) Test case number
Prerequisite Input values Expected result
Actual result
Remark
SMS_SD_01 DA = 300 300 It Should accept
DA is accepted
Pass
SMS_SD_02 DA = 5000 5000 It should be accepted
DA is accepted
Pass
SMS_SD_03 DA <300 10 It should not be accepted
DA is not accepted
Pass
SMS_SD_04 DA >5000 6000 It should not be accepted
DA is not accepted
Pass
SMS_SD_05 300<= DA <=5000
700 It Should accept
DA is accepted
Pass
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 44 IDOL, University of Mumbai
Application: School Management system Module: PaysSlip Details Type of testing: Black box(BVA) Field: Travelling Allowance (TA) Test case number
Prerequisite Input values Expected result
Actual result
Remark
SMS_SD_01 TA = 300 300 It Should accept
TA is accepted
Pass
SMS_SD_02 TA = 2000 2000 It should be accepted
TA is accepted
Pass
SMS_SD_03 TA <300 10 It should not be accepted
TA is not accepted
Pass
SMS_SD_04 TA >2000 6000 It should not be accepted
TA is not accepted
Pass
SMS_SD_05 300<= TA <=2000 700 It Should accept
TA is accepted
Pass
Application: School Management system Module: PaysSlip Details Type of testing: Black box(BVA) Field: Housing Rent Allowance (HRA) Test case number
Prerequisite Input values Expected result
Actual result
Remark
SMS_SD_01 HRA = 300 300 It Should accept
HRA is accepted
Pass
SMS_SD_02 HRA = 2500 2000 It should be accepted
HRA is accepted
Pass
SMS_SD_03 HRA <300 10 It should not be accepted
HRA is not accepted
Pass
SMS_SD_04 HRA >2500 6000 It should not be accepted
HRA is not accepted
Pass
SMS_SD_05 300<= HRA <=2500
700 It Should accept
HRA is accepted
Pass
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 45 IDOL, University of Mumbai
Application: School Management system Module: PaysSlip Details Type of testing: Black box(BVA) Field: Income Tax Test case number
Prerequisite Input values Expected result
Actual result
Remark
SMS_SD_01 Income Tax = 0 0 It Should accept
Income Tax is accepted
Pass
SMS_SD_02 Income Tax = 15000
15000 It should be accepted
Income Tax is accepted
Pass
SMS_SD_03 Income Tax <0 -5 It should not be accepted
Income Tax is not accepted
Pass
SMS_SD_04 Income Tax >15000
16000 It should not be accepted
Income Tax is not accepted
Pass
SMS_SD_05 0<= Income Tax <=15000
700 It Should accept
Income Tax is accepted
Pass
Application: School Management system Module: PaysSlip Details Type of testing: Black box(BVA) Field: Provident Fund Test case number
Prerequisite Input values Expected result
Actual result
Remark
SMS_SD_01 Provident Fund = 0 0 It Should accept
Provident Fund is accepted
Pass
SMS_SD_02 Provident Fund = 15000
15000 It should be accepted
Provident Fund is accepted
Pass
SMS_SD_03 Provident Fund <0 -5 It should not be accepted
Provident Fund is not accepted
Pass
SMS_SD_04 Provident Fund 16000 It should Provident Pass
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 46 IDOL, University of Mumbai
>15000 not be accepted
Fund is not accepted
SMS_SD_05 0<= Provident Fund <=15000
700 It Should accept
Provident Fund is accepted
Pass
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 47 IDOL, University of Mumbai
Date: 7/11/09 PRACTICAL NO.7
AIM:
To perform white box testing of given programs using branch coverage method
a. Test given programs using branch coverage b. Apply branch coverage method for "School Management system"
DESCRIPTION: Branch coverage: A branch is the outcome of a decision, so branch coverage simply measures which decision outcomes have been tested. This sounds great because it takes a more in-depth view of the source code than simple statement coverage, but branch coverage can also leave you wanting more. Determining the number of branches in a method is easy. Boolean decisions obviously have two outcomes, true and false, whereas switches have one outcome for each case—and don't forget the default case! The total number of decision outcomes in a method is therefore equal to the number of branches that need to be covered plus the entry branch in the method (after all, even methods with straight line code have one branch).
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 48 IDOL, University of Mumbai
SOURCE CODE: a) Testing given programs using Branch coverage method
Given program: #include<iostream.h> #include<conio.h> void main() { clrscr(); int length = 0; int count = 0; cout<<"\nEnter length:"; cin>>length; cout<<"\nEnter count:"; cin>>count; while(count <= 6) { if(length >= 100) length = length - 2; else length = count * length; count = count + 1; } cout"\n Length = "<<length; getch(); }
Software Testing M.C.A – Semester V ________________________________________________________________________
________________________________________________________________________ 49 IDOL, University of Mumbai
Test cases for given program using branch coverage: Test cases: Test Case number
Input values Expected output
Actual output
Remark Count Length
1 5 101 594 594 Pass 2 5 100 588 588 Pass 3 5 99 493 493 Pass 4 7 102 102 102 Pass 5 8 103 103 103 Pass 6 9 104 104 104 Pass 7 6 100 98 98 Pass 8 -10 55 4920 4920 Pass 9 3 -107 27016 27016 Pass 10 6 -100 -600 -600 Pass Test Matrix:
Branch/loop Possible value
Test cases
1 2 3 4 5 6 7 8 9 10 Count <= 6 T * * * * * * * F * * * Length>=100 T * * * * * * F * * *