ST MCA Journal Format

Software Testing
M.C.A Semester V
________________________________________________________________________
Paper I
Software Testing
________________________________________________________________________ 1 IDOL, University of Mumbai
Software Testing
M.C.A Semester V
________________________________________________________________________
INDEX
Sr.No. 1. 2. Practical Description 1.1 What is walk through review? 1.2 What is inspection review? SRS document of hospital management system. Payroll system requirement analysis. SRS for CD-shop system. To generate unit testing report for CD Library shop. To create SRS for school management system. 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 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
Page No.
Date
24/10/09 24/10/09
Sign
3. 4. 5.
28/10/09 29/10/09 29/10/09
Software Testing
M.C.A Semester V
________________________________________________________________________
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. 9. 10. 11. 12. 13. 14. 15.
To perform white box testing of given programs using path coverage method To perform white box testing of given programs using condition coverage method Introduction of WinRunner To study Recording and Playback using WinRunner To study GUI Checkpoints in WinRunner To study Bitmap Checkpoints in WinRunner To study Database Checkpoints in WinRunner To study Text Checkpoints in WinRunner
14/11/09 14/11/09 18/11/09 18/11/09 21/11/09 21/11/09 25/11/09 25/11/09
Software Testing
M.C.A Semester V
________________________________________________________________________
Date: 24/10/09
AIM: 1.1 What is walk through review? 1.2 What is inspection review? DESCRIPTION:
PRACTICAL NO.1
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 ________________________________________________________________________ 4 IDOL, University of Mumbai
Software Testing
M.C.A Semester V
________________________________________________________________________ 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 ________________________________________________________________________ 5 IDOL, University of Mumbai
Software Testing
M.C.A Semester V
________________________________________________________________________ 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
________________________________________________________________________
Date: 24/10/09
AIM:
PRACTICAL NO.2
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
________________________________________________________________________
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,
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
subtraction from salary (4) The system is for government sector, it is not providing 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 CDs in the shop like CDs 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 CDs 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, ________________________________________________________________________ 8 IDOL, University of Mumbai
Software Testing
M.C.A Semester V
________________________________________________________________________ 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. ________________________________________________________________________ 9 IDOL, University of Mumbai
Software Testing
M.C.A Semester V
________________________________________________________________________ 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 ________________________________________________________________________ 10 IDOL, University of Mumbai
Software Testing
M.C.A Semester V
________________________________________________________________________ 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 CDs whose title matches with entered name. R10.1: search and display CD details. Input: enter CD name. Output: Detail of all the CDs 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
________________________________________________________________________
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
ModuleName:LoginWindow Prerequisite:Applicationshouldbeinstalled TypeofTesting:UnitTesting
Serial Requirement Test No. CaseID 1 Application Login_01 allows administrator tologininto system
TestCase Objective Tocheck loginfor admin
Prerequisite Runas application
Description Enter admin namein loginfield andhis password in password field Enter admin namein loginfield andhis password in password field
InputData Login: Administrator,pwd applet,ClickLogin
Expected Output Login should bedone
Actual Output Loginis done
Result Pass
Application Login_02 Tocheck loginfor allows admin administrator tologininto system
Runas application
Login: Administrator, pwdxyz,Click Login
Login should notbe done
Loginis notdone
Pass
Software Testing
3 Application allowsclerk tologininto system Login_03 Tocheck loginfor clerk Runas application
M.C.A Semester V
EnterClerk namein loginfield andhis password in password field Login_04 Tocheck Runas EnterClerk loginfor application namein clerk loginfield andhis password in password field Login_05 Tocreate Administrator Enter new pwdmustbe admin clerk supplied pwd, clickon newuser, enter username, pwdand clickon create Login_06 Tocreate Administrator Clickon new pwdisnot newuser clerk supplied Login:Clerk,pwd Clerk,ClickLogin Login should bedone Loginis done Pass
________________________________________________________________________
Application allowsclerk tologininto system
Login:Clerk,pwd abc,ClickLogin
Login should notbe done
Loginis notdone
Pass
Application allowsto createnew user
Newusermustbe created
useris created
Useris created
pass
Application allowsto createnew user Application allowsto changepwd
Login_07
To change pwd
Loginidand pwd
Clickon change pwd
pwdfield Wrong admin blank pwd error message displayed Login: Password Password Administrator,pwd changed changed applet,newpwd: abc Clickonnewuser
Fail
Pass
ProjectName:CDLibrary Version:1.0 ModuleName: MDIForm1 Prerequisite:Applicationshouldbeinstalled TypeofTesting:UnitTesting
Software Testing
M.C.A Semester V
________________________________________________________________________
Serial No. Requirement TestCaseID Application allowsuser toopenCD DetailsForm MDIForm_01 Application allowsuser toopen Customer DetailsForm MDIForm_02 Application allowsuser toopenCD AccessForm
MDIForm_03
Application allowsuser toopenCD ReturnForm MDIForm_04
Application allowsuser toopenFine DetailsForm MDIForm_05 Application allowsuser toopen Tocheck Member the opening Transaction Form MDIForm_06 ofform Application allowsuser Tocheck toopen the Customer opening SearchForm MDIForm_07 ofform Tocheck Application allowsuser the toopenCD opening SearchForm MDIForm_08 ofform Application allowsuser Tocheck toopenCD the Return opening SearchForm MDIForm_09 ofform Application MDIForm_10 Tocheck
TestCase Objective Prerequisite Description Clickon the Tocheck respective the Menu opening Runas ofform application items Clickon the Tocheck respective the Menu opening Runas ofform application items Clickon the Tocheck respective the Menu opening Runas ofform application items Clickon the Tocheck respective the Menu opening Runas ofform application items Clickon the Tocheck respective the Menu opening Runas ofform application items Clickon the respective Menu items Clickon the respective Menu items Clickon the respective Menu items Clickon the respective Menu items Clickon
InputData
Expected Actual Output Output Result
Form ClickCD should DetailsForm load Click Customer Form Details should DetailsForm load
Form is loaded Pass
Form is loaded Pass
Form ClickCD should AccessForm load
Form is loaded Pass
Form ClickCD should ReturnForm load
Form is loaded Pass
Form ClickFine should DetailsForm load
Form is loaded pass
Runas application
Clickon Member Transaction Form
Form should load
Form is loaded pass
Runas application
Clickon Form Customer should SearchForm load
Form is loaded Pass
Runas application
Form ClickonCD should SearchForm load
Form is loaded Pass
9 10
Runas application Runas
ClickonCD Return SearchForm ClickonFine
Form should load Form
Form is loaded Pass Form Pass
Software Testing
allowsuser toopenFine SearchForm Application allowsuser toopen Membership SearchForm MDIForm_11 the opening ofform application
M.C.A Semester V
the respective Menu items Clickon the respective Menu items SearchForm should load is loaded
________________________________________________________________________
11
Tocheck the opening ofform
Runas application
Clickon Form Membership should SearchForm load
Form is loaded Pass
Software Testing
M.C.A Semester V
________________________________________________________________________
Date: 29/10/09
AIM:
PRACTICAL NO.4
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 Students Attendance Report 11.Management request for the Teachers Attendance Report 12.Management request for the Students 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: ________________________________________________________________________ 16 IDOL, University of Mumbai
Software Testing
M.C.A Semester V
________________________________________________________________________ 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 ________________________________________________________________________ 17 IDOL, University of Mumbai
Software Testing
M.C.A Semester V
________________________________________________________________________ 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 ________________________________________________________________________ 18 IDOL, University of Mumbai
Software Testing
M.C.A Semester V
________________________________________________________________________ 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 ________________________________________________________________________ 19 IDOL, University of Mumbai
Software Testing
M.C.A Semester V
________________________________________________________________________ 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
________________________________________________________________________ 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 ________________________________________________________________________ 21 IDOL, University of Mumbai
Software Testing
M.C.A Semester V
________________________________________________________________________ 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
________________________________________________________________________
Date: 29/10/09
AIM:
PRACTICAL NO.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 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 SOURCE CODE:
M.C.A Semester V
________________________________________________________________________
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. T1.1 T1.2 T1.3 T1.4 T1.5 Prerequisite Input values height<=150 150 151<=height<=170 170 height>=171 172 height <= 0 -5 height >= 250 300 Expected result Short Medium Tall Error Error Actual result Short Tall Tall Program Quits Program Quits Remarks Pass Fail Pass Fail Fail Required Statement else if(height <= 170) if(height <= 0 || height >170 ) cout << Input values are not
Program Number 1 2
Line number 16 NA
Actual Deficiencies Medium Height categorized as Tall Error message not displayed on invalid input
Software Testing
M.C.A Semester V 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 cout<<"\nThin"; else if( weight > 50 && weight <= 75 ) cout<<"\nMedium"; else cout<<"\nFat"; getch(); }
M.C.A Semester V
________________________________________________________________________
Test no. T2.1 T2.2 T2.3 T2.4 T2.5
Prerequisite
Input values weight<=50 50 51<=weight<=75 75 weight>=76 80 weight <= 0 -5 weight >= 250 255
Expected result Thin Medium Fat Error Error
Actual result Thin Medium Fat Program Quits Program Quits
Remarks Pass Pass Pass Fail Fail
Program Number 2
Line number 13
Actual Deficiencies Extra code
Required Statement 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 { cout << Invalid input; exit(1); } getch(); } Program3:
M.C.A Semester V
________________________________________________________________________
//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
________________________________________________________________________
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. T3.1 Prerequisite (height<=150) and (weight<=50) Input values height = 150 weight =50 height = weight = Expected result Short in height and thin by weight Short in height and medium by weight Short in height and fat by weight Medium in height and thin by weight Medium in height and medium by weight Medium in height and fat by weight Actual result Short in height and thin by weight Short in height and medium by weight Short in height and fat by weight Medium in height and thin by weight Medium in height and medium by weight Medium in height and fat by weight Remarks Pass
T3.2
(height<=150) and (51<=weight<=75)
Pass
T3.3
(height<=150) and (weight>=76)
height = weight =
Pass
T3.4
(151<=height<=170) height = and (weight<=50) weight =
Pass
T3.5
(151<=height<=170) height = and weight = (51<=weight<=75)
Pass
T3.6
(151<=height<=170) height = and (weight>=76) weight =
Pass
Software Testing T3.7 (height>=171) and (weight>=76) height = weight = Tall in height and thin by weight
M.C.A Semester V Tall in height and thin by weight Tall in Tall in height height and and medium medium by weight by weight Tall in Tall in height height and fat by and fat by weight weight Error Program quits Pass
________________________________________________________________________
T3.8
(height>=171) and (weight<=50)
height = weight =
Pass
T3.9
(height>=171) and (weight>=76)
height = weight =
Pass
T3.10
(height<=0) and (weight<=0)
T3.11
(height>=250) and (weight >=250)
height = -5 weight =-10 height = 260 weight =250
Fail
Error
Program quits
Fail
Program Number 3
Line number 12
Actual Deficiencies Incorrect values
Required Statement 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
________________________________________________________________________
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 Test case number SCM_01 Prerequisite
M.C.A Semester V Input values Expected result It Should accept Actual result Phone number is accepted Phone number is not accepted Phone number is not accepted Remark Pass
________________________________________________________________________
9000000000<=number<=9999999999 9820469660
SCM_02
Number>99999999999
982046966055 It should not be accepted 10 It should not be accepted
Pass
SCM_03
Number<9000000000
Pass
Application: School Management system Module: Staff Details Type of testing: Black box(Equivalent class partitioning) Field: Basic Payment Test case Prerequisite Input Expected Actual number values result result SCM_01 300<=basic 10000 It Should Basic payment<=15000 accept payment is accepted SCM_02 Basic 15001 It should Basic Payment>15000 not be payment accepted is not accepted SCM_03 Basic Payment 299 It should Basic <300 not be payment accepted is not accepted
Remark Pass
Pass
Pass
Application: School Management system Module: Staff Details Type of testing: Black box(Equivalent class partitioning) Field: Date of Birth Test case Prerequisite Input Expected Actual number values result result SCM_01 Date of 05/10/1970 It Should Date of
Remark Pass
Software Testing Establishment>Date accept of Birth<Date of Joining Date of Joining <= 05/10/2000 It should Date of Birth not be accepted
M.C.A Semester V birth is accepted Date of Birth is accepted Fail
________________________________________________________________________
SCM_02
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 Prerequisite Input Expected Actual number values result result 05/11/1991 It Should Date of SCM_01 Date of accept Retirement Joining<=Date is accepted of Retirement SCM_02 Date of 05/09/1991 It should Date of Joining>Date not be Retirement of Retirement accepted is accepted 05/11/1991 It should Date Of SCM_03 Date of be Retirement Retirement accepted is accepted >=Date Of Establishment SCM_04 Date of 05/11/1921 It should Date Of Retirement not be Retirement <Date Of accepted is accepted Establishment 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 Prerequisite Input Expected Actual number values result result SCM_01 ID<1 0 It Should Id is not not be accepted
Remark Pass
Fail
Pass
Fail
Remark Pass
Software Testing
M.C.A Semester V
________________________________________________________________________
accepted Pass It should Id is accepted be accepted Pass SCM_03 ID>Upper 299 It should Id is not accepted Limit not be accepted 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 Prerequisite Input Expected Actual Remark number values result result SCM_01 Standard<1 0 It Should Standard Pass not be is not accepted accepted SCM_02 0>Standard<=9 5 It should Standard Pass is be accepted accepted SCM_03 Standard>9 15 It should Standard Pass is not not be accepted accepted SCM_02 0>ID<=Upper limit 5
Application: School Management system Module: Student Details Type of testing: Black box(Equivalent class partitioning) Field: Total Annual Income Test case Prerequisite Input Expected number values result SCM_01 300<=total 10000 It Should annual accept income<=15000 SCM_02 Total Annual Income>15000 15001 It should not be accepted
SCM_03
Total Annual Income <300
299
It should not be
Actual result Total Annual Income is accepted Total Annual Income is not accepted Total Annual
Remark Pass
Pass
Pass
Software Testing accepted
M.C.A Semester V 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 Prerequisite Input Expected number values result SCM_01 300<=DA<=5000 10000 It Should accept SCM_02 DA>5000 15001 It should not be accepted SCM_03 DA <300 299 It should not be accepted
Actual result DA is accepted DA is not accepted DA is not accepted
Remark Pass Pass
Pass
Application: School Management system Module: PaySlip Details Type of testing: Black box(Equivalent class partitioning) Field: Travelling Allowance (TA) Test case Prerequisite Input Expected number values result SCM_01 300<=TA<=2000 10000 It Should accept SCM_02 TA>2000 15001 It should not be accepted SCM_03 TA <300 299 It should not be accepted
Actual result TA is accepted TA is not accepted TA is not accepted
Remark Pass Pass
Pass
Application: School Management system Module: PaySlip Details

Software Testing
M.C.A Semester V
________________________________________________________________________
Type of testing: Black box(Equivalent class partitioning) Field: Housing Rent Allowance Allowance(HRA) Test case Prerequisite Input Expected number values result SCM_01 300<=HRA<=2500 10000 It Should accept SCM_02 HRA>2500 15001 It should not be accepted SCM_03 HRA <300 299 It should not be accepted
Actual result HRA is accepted HRA is not accepted HRA is not accepted
Remark Pass Pass
Pass
Application: School Management system Module: PaySlip Details Type of testing: Black box(Equivalent class partitioning) Field: Income Tax Test case Prerequisite Input Expected Actual number values result result SCM_01 0<=Income 10000 It Should Income tax Tax<=15000 accept is accepted SCM_02 Income 15001 It should Income tax Tax>=Basic not be is not Payment accepted accepted SCM_03 Income -299 It should Income tax Tax<0 not be is not accepted accepted SCM_04 Income 16000 It should Income tax Tax>=Gross not be is not Payment accepted accepted
Remark Pass Pass
Pass
Pass
Software Testing
M.C.A Semester V
________________________________________________________________________
Date: 7/11/09
AIM:
PRACTICAL NO.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 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 SOURCE CODE: a) Testing given programs using BVA
M.C.A Semester V
________________________________________________________________________
// 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
________________________________________________________________________
Test cases for BVA of given program: Test case number 1 Prerequisite num=1000 Input value 1000 Expected result not prime number Actual result Message: Not prime number Message: Not prime number Message Entered number is not in given range Message Entered number is not in given range Message: Not prime number Remark pass
num=10000
10000
not prime number
prime
num=999
999
Not in range
Pass
num=10001
10001
Not in range
Pass
num in range 1000 to 10000
1002
not prime number
Pass
Software Testing
M.C.A Semester V
________________________________________________________________________
b) Find out any defect in given program Defect/ Deficiency in given program: Program Line number Actual Expected number defect/deficiency statement 1 29 Flag value is set If (flag==0) incorrectly 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 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 Prerequisite Input Expected number values result SMS_SD_01 Standard =1 1 It should be accepted SMS_SD_02 Standard = 10 It should 10 be accepted SMS_SD_03 Standard < 1 0 It should not be accepted SMS_SD_04 Standard>10 11 It should not be accepted SMS_SD_05 1 <= 5 It should Standard <= be 10 accepted Application: School Management system Module: Staff Details Type of testing: Black box(BVA) Field: Phone number Test case Prerequisite number SMS_SD_01 Number= 9000000000
M.C.A Semester V
________________________________________________________________________
Actual Remark result Standard Pass is accepted Standard Pass is accepted Standard Pass is not accepted Standard Pass is not accepted Standard Pass is accepted
Input values 9000000000
Expected result It Should accept
SMS_SD_02 Number=99999999999
99999999999
SMS_SD_03 Number<9000000000
10
Actual result Phone number is accepted It should Phone be number accepted is accepted It should Phone not be number accepted is not accepted
Remark Pass
Pass
Pass
Software Testing SMS_SD_04 Number>9999999999
M.C.A Semester V
________________________________________________________________________
10000000000000 It should Phone Pass not be number accepted is not accepted SMS_SD_05 9000000000<=number<=9999999999 9820469660 It Should Phone Pass accept number is accepted
Application: School Management system Module: Staff Details Type of testing: Black box(BVA) Field: Basic Payment Test case Prerequisite Input values number SMS_SD_01 Basic Payment= 300 300
Expected result It Should accept
SMS_SD_02 Basic Payment = 15000
15000
It should be accepted It should not be accepted It should not be accepted It Should accept
SMS_SD_03 Basic Payment<300
10
SMS_SD_04 Basic Payement >15000
16000
SMS_SD_05 300<= Basic Payement <=15000
700
Actual result Basic Payment is accepted Basic Payment is accepted Basic Payment is not accepted Basic Payment is not accepted Basic Payement is accepted
Remark Pass
Pass
Pass
Pass
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 number SMS_SD_01 ID= 1
M.C.A Semester V
________________________________________________________________________
result result It Should ID is Pass accept accepted SMS_SD_02 ID= Upper limit Upper limit It should ID is Pass be accepted accepted SMS_SD_03 ID<1 0 It should ID is not Pass not be accepted accepted SMS_SD_04 ID>Upper limit Upper limit It should ID is not Pass +2 not be accepted accepted SMS_SD_05 1<= ID <=Upper 2 It Should ID is Pass limit accept accepted 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 Prerequisite Input values Expected Actual Remark number result result SMS_SD_01 Total Annual 300 It Should Total Pass Income = 300 accept Annual Income is accepted SMS_SD_02 Total Annual 15000 It should Total Pass Income = 15000 be Annual accepted Income is accepted SMS_SD_03 Total Annual 10 It should Total Pass Income <300 not be Annual accepted Income is not accepted SMS_SD_04 Total Annual 16000 It should Total Pass Income >15000 not be Annual accepted Income is not accepted SMS_SD_05 300<= Total 700 It Should Total Pass 1
Software Testing Annual Income <=15000
M.C.A Semester V accept Annual Income is accepted
________________________________________________________________________
Application: School Management system Module: PaysSlip Details Type of testing: Black box(BVA) Field: Dearness Allowance (DA) Test case Prerequisite Input values number SMS_SD_01 DA = 300 300 SMS_SD_02 DA = 5000 5000
SMS_SD_03 DA <300
10
SMS_SD_04 DA >5000
6000
SMS_SD_05 300<= DA <=5000
700
Expected result It Should accept It should be accepted It should not be accepted It should not be accepted It Should accept
Actual Remark result DA is Pass accepted DA is Pass accepted DA is Pass not accepted DA is Pass not accepted DA is Pass accepted
Software Testing
M.C.A Semester V
________________________________________________________________________
Application: School Management system Module: PaysSlip Details Type of testing: Black box(BVA) Field: Travelling Allowance (TA) Test case Prerequisite Input values number SMS_SD_01 TA = 300 300 SMS_SD_02 TA = 2000 2000
SMS_SD_03 TA <300
10
SMS_SD_04 TA >2000
6000
SMS_SD_05 300<= TA <=2000
700
Actual Remark result TA is Pass accepted TA is Pass accepted Pass TA is not accepted TA is Pass not accepted TA is Pass accepted
Application: School Management system Module: PaysSlip Details Type of testing: Black box(BVA) Field: Housing Rent Allowance (HRA) Test case Prerequisite Input values number SMS_SD_01 HRA = 300 300 SMS_SD_02 HRA = 2500 2000
SMS_SD_03 HRA <300
10
SMS_SD_04 HRA >2500
6000
SMS_SD_05 300<= HRA <=2500
700
Actual Remark result HRA is Pass accepted HRA is Pass accepted HRA is Pass not accepted HRA is Pass not accepted HRA is Pass accepted
Software Testing
M.C.A Semester V
________________________________________________________________________
Application: School Management system Module: PaysSlip Details Type of testing: Black box(BVA) Field: Income Tax Test case Prerequisite Input values number SMS_SD_01 Income Tax = 0 0
SMS_SD_02 Income Tax = 15000 SMS_SD_03 Income Tax <0
15000
-5
SMS_SD_04 Income Tax >15000
16000
SMS_SD_05 0<= Income Tax <=15000
700
Actual result Income Tax is accepted Income Tax is accepted Income Tax is not accepted Income Tax is not accepted Income Tax is accepted
Remark Pass
Pass
Pass
Pass
Pass
Application: School Management system Module: PaysSlip Details Type of testing: Black box(BVA) Field: Provident Fund Test case Prerequisite Input values number SMS_SD_01 Provident Fund = 0 0
Expected result It Should accept It should be accepted It should not be accepted It should
SMS_SD_02 Provident Fund = 15000 SMS_SD_03 Provident Fund <0
15000
-5
SMS_SD_04 Provident Fund
16000
Actual result Provident Fund is accepted Provident Fund is accepted Provident Fund is not accepted Provident
Remark Pass
Pass
Pass
Pass
Software Testing >15000
M.C.A Semester V Fund is not accepted It Should Provident Pass accept Fund is accepted not be accepted
________________________________________________________________________
SMS_SD_05 0<= Provident Fund <=15000
700
Software Testing
M.C.A Semester V
________________________________________________________________________
Date: 7/11/09
AIM:
PRACTICAL NO.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" 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 caseand 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
________________________________________________________________________
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 Test cases for given program using branch coverage: Test cases: Test Case number 1 2 3 4 5 6 7 8 9 10 Input values Count 5 5 5 7 8 9 6 -10 3 6 Length 101 100 99 102 103 104 100 55 -107 -100 Expected output 594 588 493 102 103 104 98 4920 27016 -600
M.C.A Semester V
________________________________________________________________________
Actual output 594 588 493 102 103 104 98 4920 27016 -600
Remark Pass Pass Pass Pass Pass Pass Pass Pass Pass Pass
Test Matrix: Branch/loop Possible value 1 Count <= 6 Length>=100 T F T F * * * 2 * 3 4 * * * * * * * * * * * 5 Test cases 6 7 * 8 * 9 * 10 *

ST MCA Journal Format

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ST MCA Journal Format

Uploaded by

Copyright:

Available Formats

Software Testing

________________________________________________________________________ 1 IDOL, University of Mumbai

28/10/09 29/10/09 29/10/09

________________________________________________________________________ 2 IDOL, University of Mumbai

8. 9. 10. 11. 12. 13. 14. 15.

14/11/09 14/11/09 18/11/09 18/11/09 21/11/09 21/11/09 25/11/09 25/11/09

________________________________________________________________________ 3 IDOL, University of Mumbai

What is walk through review? What is inspection review?

________________________________________________________________________ 6 IDOL, University of Mumbai

________________________________________________________________________ 7 IDOL, University of Mumbai

SRS for CD scope system:

________________________________________________________________________ 11 IDOL, University of Mumbai

TestCase Objective Tocheck loginfor admin

Prerequisite Runas application

InputData Login: Administrator,pwd applet,ClickLogin

Expected Output Login should bedone

Actual Output Loginis done

Application Login_02 Tocheck loginfor allows admin administrator tologininto system

Login: Administrator, pwdxyz,Click Login

Login should notbe done

________________________________________________________________________ 12 IDOL, University of Mumbai

Application allowsclerk tologininto system

Login should notbe done

Application allowsto createnew user

Application allowsto createnew user Application allowsto changepwd

Clickon change pwd

ProjectName:CDLibrary Version:1.0 ModuleName: MDIForm1 Prerequisite:Applicationshouldbeinstalled TypeofTesting:UnitTesting

________________________________________________________________________ 13 IDOL, University of Mumbai

Application allowsuser toopenCD ReturnForm MDIForm_04

Expected Actual Output Output Result

Form is loaded Pass

Form is loaded Pass

Form ClickCD should AccessForm load

Form is loaded Pass

Form ClickCD should ReturnForm load

Form is loaded Pass

Form ClickFine should DetailsForm load

Form is loaded pass

Clickon Member Transaction Form

Form should load

Form is loaded pass

Clickon Form Customer should SearchForm load

Form is loaded Pass

Form ClickonCD should SearchForm load

Form is loaded Pass

Runas application Runas

ClickonCD Return SearchForm ClickonFine

Form should load Form

Form is loaded Pass Form Pass

________________________________________________________________________ 14 IDOL, University of Mumbai

Tocheck the opening ofform

Clickon Form Membership should SearchForm load

Form is loaded Pass

________________________________________________________________________ 15 IDOL, University of Mumbai

To create SRS for school management system.

________________________________________________________________________ 20 IDOL, University of Mumbai

________________________________________________________________________ 22 IDOL, University of Mumbai

________________________________________________________________________ 23 IDOL, University of Mumbai

Software Testing SOURCE CODE:

________________________________________________________________________ 24 IDOL, University of Mumbai

M.C.A Semester V valid exit(1);

Test no. T2.1 T2.2 T2.3 T2.4 T2.5

Expected result Thin Medium Fat Error Error

Actual result Thin Medium Fat Program Quits Program Quits