Paper I Software Testingresults.mu.ac.in/myweb_test/ST_MCA_journal format.pdf · SRS document of hospital management system. ... There should be a facility of storing patient information

Software Testing M.C.A – Semester V ________________________________________________________________________

________________________________________________________________________ 1 IDOL, University of Mumbai

Paper I

Software Testing



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



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



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



· 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



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.




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



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,



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.



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



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.



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



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



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


Run as application


Click Customer Details Details Form

Form should load

Form is loaded Pass

3

Application allows user to open CD Access Form MDIForm_03


Run as application


Click CD Access Form

Form should load

Form is loaded Pass

4

Application allows user to open CD Return Form MDIForm_04


Run as application


Click CD Return Form

Form should load

Form is loaded Pass

5

Application allows user to open Fine Details Form MDIForm_05


Run as application


Click Fine Details Form

Form should load

Form is loaded pass

6

Application allows user to open Member Transaction Form MDIForm_06


Run as application


Click on Member Transaction Form

Form should load

Form is loaded pass

7

Application allows user to open Customer Search Form MDIForm_07


Run as application


Click on Customer Search Form

Form should load

Form is loaded Pass

8

Application allows user to open CD Search Form MDIForm_08


Run as application


Click on CD Search Form

Form should load

Form is loaded Pass

9

Application allows user to open CD Return Search Form MDIForm_09


Run as application


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



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


Run as application


Click on Membership Search Form

Form should load

Form is loaded Pass




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: -



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



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



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



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



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



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.




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.



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



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)



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)



{ 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)



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



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:";



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



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


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


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


Expected result

Actual result

Remark

SCM_01 Date of 05/10/1970 It Should Date of Pass



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


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


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


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


Expected result

Actual result

Remark

SCM_01 ID<1 0 It Should not be

Id is not accepted

Pass



accepted SCM_02 0>ID<=Upper

limit 5 It should

be accepted

Id is accepted

Pass

SCM_03 ID>Upper Limit


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


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


Pass

Application: School Management system Module: Student Details Type of testing: Black box(Equivalent class partitioning) Field: Total Annual Income Test case number


Expected result

Actual result

Remark

SCM_01 300<=total annual income<=15000


Total Annual Income is accepted

Pass

SCM_02 Total Annual Income>15000


Total Annual Income is not accepted

Pass

SCM_03 Total Annual Income <300

299 It should not be

Total Annual

Pass



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


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


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



Type of testing: Black box(Equivalent class partitioning) Field: Housing Rent Allowance Allowance(HRA) Test case number


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


Expected result

Actual result

Remark

SCM_01 0<=Income Tax<=15000


Income tax is accepted

Pass

SCM_02 Income Tax>=Basic Payment


Income tax is not accepted

Pass

SCM_03 Income Tax<0

-299 It should not be accepted


Pass

SCM_04 Income Tax>=Gross Payment



Pass




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.



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(); }



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


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


Pass



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(); }



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


Expected result

Actual result

Remark

SMS_SD_01 Standard =1 1 It should be accepted


Pass

SMS_SD_02 Standard = 10

10 It should be accepted


Pass

SMS_SD_03 Standard < 1 0 It should not be accepted


Pass

SMS_SD_04 Standard>10 11 It should not be accepted


Pass

SMS_SD_05 1 <= Standard <= 10



Pass

Application: School Management system Module: Staff Details Type of testing: Black box(BVA) Field: Phone number Test case number


Actual result

Remark

SMS_SD_01 Number= 9000000000 9000000000 It Should accept


Pass

SMS_SD_02 Number=99999999999 99999999999 It should be accepted


Pass

SMS_SD_03 Number<9000000000 10 It should not be accepted


Pass



SMS_SD_04 Number>9999999999 10000000000000 It should not be accepted


Pass

SMS_SD_05 9000000000<=number<=9999999999 9820469660 It Should accept


Pass

Application: School Management system Module: Staff Details Type of testing: Black box(BVA) Field: Basic Payment Test case number


Actual result

Remark

SMS_SD_01 Basic Payment= 300


Basic Payment is accepted

Pass

SMS_SD_02 Basic Payment = 15000


Basic Payment is accepted

Pass

SMS_SD_03 Basic Payment<300


Basic Payment is not accepted

Pass

SMS_SD_04 Basic Payement >15000


Basic Payment is not accepted

Pass

SMS_SD_05 300<= Basic Payement <=15000


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



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


Actual result

Remark

SMS_SD_01 Total Annual Income = 300



Pass

SMS_SD_02 Total Annual Income = 15000



Pass

SMS_SD_03 Total Annual Income <300



Pass

SMS_SD_04 Total Annual Income >15000



Pass

SMS_SD_05 300<= Total 700 It Should Total Pass



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


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


DA is accepted

Pass



Application: School Management system Module: PaysSlip Details Type of testing: Black box(BVA) Field: Travelling Allowance (TA) Test case number


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


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


HRA is accepted

Pass



Application: School Management system Module: PaysSlip Details Type of testing: Black box(BVA) Field: Income Tax Test case number


Actual result

Remark

SMS_SD_01 Income Tax = 0 0 It Should accept

Income Tax is accepted

Pass

SMS_SD_02 Income Tax = 15000



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


Income Tax is not accepted

Pass

SMS_SD_05 0<= Income Tax <=15000



Pass

Application: School Management system Module: PaysSlip Details Type of testing: Black box(BVA) Field: Provident Fund Test case number


Actual result

Remark

SMS_SD_01 Provident Fund = 0 0 It Should accept

Provident Fund is accepted

Pass

SMS_SD_02 Provident Fund = 15000



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



>15000 not be accepted

Fund is not accepted

SMS_SD_05 0<= Provident Fund <=15000



Pass




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).



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(); }



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 * * *

Documents

Paper I Software Testingresults.mu.ac.in/myweb_test/ST_MCA_journal format.pdf · SRS document of hospital management system. ... There should be a facility of storing patient information