Top Banner
Online Auction System SRS & Report Product By : Dilip J. Prajapati Mail Id: [email protected]
58
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Online auction system srs  riport

Online Auction System

SRS & Report

Product By :Dilip J. Prajapati

Mail Id:[email protected]

Page 2: Online auction system srs  riport

DATE PRACTICAL: 1

AIM: Study various problem domain and select one problem and identify the problem definition. Also specify and elaborate the model for your System

1.1Problem Definition

Online Auction System

1.2 Software Development Life Cycle Model

1.2.1Feasible study of Online Auction System

Economical feasibility

Economic justification is generally the “Bottom Line” considerationfor most systems. Economic justification includes a broad range of concerns that includes cost benefit analysis. In this we weight the cost and the benefits associated with the candidate system and if it suits the basic purpose of the organization i.e. profit making, the project is making to the analysis and design phase. The financial and theeconomic questions during the preliminary investigation are verified to estimate the following:

The cost to conduct a full system investigation.The cost of hardware and software for the class of application being considered.The benefits in the form of reduced cost. The proposed system will give the minute information, as a result the performance is improved which in turn may be expected to provide increased profits.

This feasibility checks whether the system can be developed with the available funds. The HMS is not require enormous amount of money to be developed. This can be done economically if planned judicially, so it is economically feasible. The cost of project depends upon the number of man hours required.

Operational Feasibility

It is mainly related to humanorganizations and political aspects. The points to be considered are:

What changes will be brought with the system? What organization structures are disturbed? What new skills will be required? Do the existing staff members have these skills? If not, can they be trained in

Page 3: Online auction system srs  riport

due course of time? The system is operationally feasible as it very easy for the End users to operate it. It only needs basic information about Windows platform.

 Technical feasibility

A study of resource availability that may affect the ability to achieve an acceptable system. This evaluation determines whether the technology needed for the proposed system is available or not.

Can the work for the project be done with current equipment existing software technology & available personal?

Can the system be upgraded if developed? If new technology is needed then what can be developed? This is concerned with specifying equipment and software that will successfully

satisfy the user requirement. The technical needs of the system may include: Front-end and back-end selectionAn important issue for the development of a project is the selection of suitable front-end and back-end. When we decided to develop the project we went through an extensive study to determine the most suitable platform that suits the needs of the organization aswell as helps in development of the project. The aspects of our study included the following factors.

Front-end selection:

It must have a graphical user interface that assists employees that are not from IT background

Scalability and extensibility.Flexibility.Robustness.According to the organization requirement and the culture.Must provide excellent reporting features with good printing support.Platform independent.Easy to debug and maintain.Event driven programming facility.

According to the above stated features we selected VB6.0 as the front-end for developing our project

Back-end Selection:

Multiple user support.Efficient data handling.Provide inherent features for security.Efficient data retrieval and maintenance.Stored procedures.Popularity.

Page 4: Online auction system srs  riport

Operating System compatible.Easy to install.

Various drivers must be available.Easy to implant with the Front-end.

Schedule feasibility

Time evaluation is the most important consideration in the development of project. The time schedule required for the developed of this project is very important since more development time effect machine time, cost and cause delay in the development ofother systems. A reliable Online Auction System can be developed in the considerable amount of time.

1.2.2Requirement analysis and specification

During the requirement analysis gather the all the requirement of the software. As per the requirement planning about software how it work?What flow of it? After that mase SRS that contain the all requirement of software .It is the most important part of the software development because software developed based on that phase

1.2.3System Design

What is a Methodology?

Software engineering is carry out of using preferred procedure techniques to progress the quality of a software development effort. A methodology is defined as a collection of procedures, techniques, tools, and documentation aids which will help developers in their efforts (both product and process related activities) to implement a new system. For successful implementation, a well-organized and systematicapproach iscrucial. Therefore, several methodologies were developed to encourage the systematic approach to planning, analysis, design, testing and implementation. Methodologies offer various tools and techniques to assist in analysis, design and testing in terms of detailed design of software, data flowcharts and database design.

Why Methodology?

To complete a project within time and budget with the expected scope and quality we need methodologies which provide for a framework.

Page 5: Online auction system srs  riport

Most methodologies have a general planning, developing and managing stages in. common. They suggest the development team the ways of thinking, learning and arriving at a regular feasible solution.To select an ideal methodology was based on project requirements and goals.

Functional Decomposition: The methodology should have stages according to the interrelated activities which can be grouped into different functional areas.

Requirement Changes: If required, methodology provides scope to change the requirement.

Manage Risks: Determined the risk is an important activity to develop a project. Iterative approach: Iteration allows refinement of requirement as well as design. Documentation: Methodology provides support for large documentation. Analysis and Design Support: A well defined structure of the methodology helps

for analysis and designing to development process.. Implementation: The system should be implemented as per plan. Testing Support: More testing, more reliable the product is. Object Oriented Approach: Object oriented concepts will be used in developing

the project as it supports component reusability.

1.2.4 System Coding

Although the implementation is the fruition of chain of the efforts starting with analysis. It is most demanding stage in the development of hospital management system. There are more needed persistence, accuracy and attention in detailDuring the implementing stage of the system i select the language vb.net and database and connecting both in proper way. After the coding of software we need to check our software fulfill the need of user.

1.2.5 Testing

Testing is a critical for a newly developed system as a prerequisite for it being but into an environment where the end user can use it. Exhaustive testing is conducted to ensure accuracy and reliability and to ensure that bugs are deleted as early possible as. In the process of designing the system.Three level of testing will be conducted

Unit test

Unit test is where the system is tested partially and independently ,component by component,to ensure that particular portion or module workable within it.In the development of the hospital management system, each component will be tested independently before finally integrating each of them into one system.

System Test

Page 6: Online auction system srs  riport

A system normally consist of all component that makeup the total system to function .It will be require to ensure the smooth running of the system as a whole ,and it should perform as expected and as required.Here,technical and functional testing will be performed.The technical testing will involve the process of testing the system compability with the hardware, operating system, data integrity in the database and user authentication access rights.

User Acceptance Test

User will be involved so as to analyze acceptability and usability and also to identify areas that may require modification before the system can fully be commissioned for use.

1.2.6 Maintenance

Once software development is completed and system has been deployed,it must be maintain for continue success. There are several kind of maintenance.Bugs that remains in the original system that gradually appear during use and must be fixed it.A success full application also lead to enhancement request and long-lived application

Page 7: Online auction system srs  riport

DATE:-

EXPERIMENT NO: -2

AIM:- To perform the system analysis task for your system

Page 8: Online auction system srs  riport

Software Requirements Specification

for

Mess Management System

Version 1.0 approved

Prepared by Dilip J. Prajapati

<organization>

<date created>

Page 9: Online auction system srs  riport

Table of ContentsTable of Contents...........................................................................................................................iiRevision History.............................................................................................................................ii1. Introduction..............................................................................................................................1

1.1 Purpose..............................................................................................................................................11.2 Document Conventions.....................................................................................................................11.3 Intended Audience and Reading Suggestions...................................................................................11.4 Product Scope...................................................................................................................................11.5 References.........................................................................................................................................1

2. Overall Description..................................................................................................................22.1 Product Perspective...........................................................................................................................22.2 Product Functions.............................................................................................................................22.3 User Classes and Characteristics......................................................................................................22.4 Operating Environment.....................................................................................................................22.5 Design and Implementation Constraints...........................................................................................22.6 User Documentation.........................................................................................................................32.7 Assumptions and Dependencies.......................................................................................................3

3. External Interface Requirements...........................................................................................33.1 User Interfaces..................................................................................................................................33.2 Hardware Interfaces..........................................................................................................................33.3 Software Interfaces...........................................................................................................................43.4 Communications Interfaces..............................................................................................................4

4. System Features.......................................................................................................................4 4.1 System Feature........................................................................................................................4

4.2 User Details ………………..............................................................................................................4 4.3 Product Details……………...……………………………………………………………..4

4.4 Seller Details..……………………………………………………………………………..4

5. Other Nonfunctional Requirements.......................................................................................55.1 Performance Requirements...............................................................................................................55.2 Security Requirements......................................................................................................................55.3 Software Quality Attributes..............................................................................................................55.4 Business Rules..................................................................................................................................5

6. Other Requirements................................................................................................................5Appendix A: Glossary....................................................................................................................5Appendix B: Analysis Models.......................................................................................................5Appendix C: To Be Determined List............................................................................................6

Revision History

Name Date Reason For Changes Version

PEN NO:-130843131016 page no:

Page 10: Online auction system srs  riport

1. Introduction

Since the internet has become a popular place to buy and sell goods, online auctioning services have made their way into most homes. Online auction system is web based application, in which the seller can sell the goods by sitting in his own house ,so the main advantage of this application is that there is no more system compatibility requirement problem. The main advantage of the online auction system is that the user can have the better choices for their investment and also it is time saving , and through this system user can invest in their own selected firm.

1.1 Purpose

Our main purpose for this project is people invest their money to get maximum profit and knowledge

about our online trading system. Here all type of user can go and analyses the data of different field and

get maximum profit for future investment.

1.2 Document Conventions

Typeface Indicates

Mainly for headings and are numbered properly

Mainly Used in References

1.3 Intended Audience and Reading Suggestions

Information in this document is at a level that can be reviewed and understood by the different People.

The documents people includes Developers, Team Members.

1.4 Product Scope

This web application system will be a online auction system which consists of the seller, buyer of consumer products. The admin web application will allow the online auction administrator to sell and buy the products through the desired person(administrator). In this the seller will post the product with the help of images and description of the product. The buyer have to select the product and bid accordingly.and the bidding will have a specific time limit which will be set by a seller of the product The buyer with the highest bid, the product will be sold to the bidder.

PEN NO:-130843131016 page no:

Page 11: Online auction system srs  riport

2. Overall Description

2.1 Product Perspective

The online auction system is an independent system.this system involves two users i.e buyer and seller. The Database connection is provided online to make faster and easy acess to data retrieval.

2.2 Product Functions

- Customer must have a valid User Id and password to login to the system.

- If there is a new user he has to register for this auction process.

- If a wrong password is given three times in succession, that account will be locked and the

customer will not be able to use it. When an invalid password is entered a warning is given to

the user that his account is going to get locked.

- User can search the product he want and also in the particular price he wants i.e- maximum and

minimum price.

- User can view his monthly as well as annual auctions. He can also view future auctions.

- Administrator can take a back up of the database for every auction that is happening,

periodically.

- All users are authenticated to avail the services

- FAQ section is also included for end users benefit.

2.3 User Classes and Characteristics

The user (seller and buyer) may have the basic knowledge about computer and internet.so that they can use this website.

2.4 Operating Environment

This Application will run over all Kind of operating system (Windows xp,vista,win-07,Linux,etc.)containing web browser

2.5 Design and Implementation Constraints

The Mess Management System shall be a Web application system running over web browser environment. The system shall be developed using java.

PEN NO:-130843131016 page no:

Page 12: Online auction system srs  riport

2.6 Assumptions and Dependencies

This system can be used only if the user login with correct password and UserID

The further transactions can be carried on only with the permision of the administrator

3. External Interface Requirements

3.1 User Interfaces

The Interface will be in the form of a webapp. It is designed to be functional and minimal in its styling. All products will be displayed in a image and description format. HTML and CSS will be used to setup the page layout and add minimal styling to make the interface user friendly.

3.2 Hardware Interfaces

- Processor : Pentium 3 or above

- System bus : 32 bit

- Ram : 256 MB or more

- HDD : 40 GB

- Monitor : SVGA color

- Keyboard : 101 Keys

- Modem : 56 Kbps/ADSL broadband

- Mouse : PS2/serial

3.3 Software Interfaces

The server will be hosted using Apache Webserver (Version 2.2.17). It will also have a MySQL relational database. The main backend processing will be done using java including connecting to and accessing the database and processing requests.

PEN NO:-130843131016 page no:

Page 13: Online auction system srs  riport

3.4 Communications Interfaces

The main communication protocol will be Hyper Text Transfer Protocol (HTTP). This will be used to transfer information back and forth from the client to the server. HTTP GET and POST will be used to send the information securely over the web browser.

4. System Features

4.1 System Feature

Login Module will provide security and authentication to the seller and buyer. This system will only allow the administrator to see the other functionality of the system who having a valid username and Password.

4.2 User Details

User Module will contains the all information about the seller and buyer who are registered under the online auction system. All user information like name, address, mobile-number, email id, etc are handled by the user details module.

4.3 Product Details

Product Module will contains the all information about the product. All the information about the product name , type, price, bid-time, description, photos, maximum bidder name, final bidding price.etc.

4.4 Seller Details

Seller Module will contains the all information about the seller who are registered under the online auction system.all seller information like name, seller_ID, address, mobile-number, email-id,etc are handled by the student details module.

5. Other Nonfunctional Requirements

5.1 Performance Requirements

The physical machine to be used in the online action needs to have internet access in order to connect to the database. This software will not assume that a code scanner hardware is available on the machine, and so the USER_ID input will be done via keyboard and mouse. user need internet access on their devices as well, since all the data will be stored on the server database which the software will need to connect to.

PEN NO:-130843131016 page no:

Page 14: Online auction system srs  riport

5.2 Security Requirements

The online auction System will uses the secure authentication for the online auction System Administrator. Login Id & Password is associated with the System Administrator to Provide Security over the system.

No detail of the competitor bidder will be shown as it can be a case of fraud.

5.3 Software Quality Attributes

The detail of the buyers and seller is kept secret. No case of fraud is possible.

5.4 Business Rules

Once the bidding work is completed the personal meeting of buyer and seller is fixed by the administrator and when the buyer and seller deal is being completed and the 2% commission amount is paid by them to the administrator by hard cash or by online payment transaction in his bank account.If the commission is not paid to the administrator then the deal is not said to be completed.

PEN NO:-130843131016 page no:

Page 15: Online auction system srs  riport

DATE:-

EXPERIMENT NO: -3

AIM:- To perform the function & Data oriented diagram for the system

PEN NO:-130843131016 page no:

Page 16: Online auction system srs  riport

DATE:

EXPERIMENT NO: -3.1

AIM:- To perform the Data Flow Diagram (DFD) diagram for the system

LEVEL 0(CONTEXT LEVEL):-

Online Auction System

Seller Buyer

Post The Product

View the Auction Updates

Search the Product

View Products

PEN NO:-130843131016 page no:

Page 17: Online auction system srs  riport

LEVEL 1:-

1.Registration

2.Login

3.Search/view all

Product

4.Sell the Product

5.Bidding the

Product

6.Conformation

Bidding(communication)

Seller Buyer

sign up

Conformation

Sign up

Conformation

Statues Update

Post Product

Communication Communication

Search Product

View Product

Product

Modify

Modify

Fet

ch

Fetch Fetch

Customer

Modify

PEN NO:-130843131016 page no:

Page 18: Online auction system srs  riport

DATE:

EXPERIMENT NO: -3.2

AIM:- To perform the Entity Relationship diagram for the system

E-R Diagram

Admin

Product(Item)Buyer

SellerMenage Sellers

Bidding

SellingManage Buyers

User_name Password

S_ID

Password

S_User_name

Phone no.

S_Product

Address

Mail_ID

P_ID

P_ID

P_Name

P_Type Price

Bid_Time

Description

Max_Bid_Pirce

PhotosB_ID

B_User_Name

Password

AddressMail_ID

Phone_no

P_ID

Biddig_Price

PEN NO:-130843131016 page no:

Page 19: Online auction system srs  riport

DATE:-

EXPERIMENT NO: -4

AIM:- To perform the user’s view analysis for the system

PEN NO:-130843131016 page no:

Page 20: Online auction system srs  riport

DATE:

EXPERIMENT NO: -4.1

AIM:- To perform the UseCase diagram for the system.

PEN NO:-130843131016 page no:

Page 21: Online auction system srs  riport

Registration

Login

Search/View Product

Sell Product

Biding for a Product

Manage Product

Logout

Online Auction

Administrator

Seller

Buyer

PEN NO:-130843131016 page no:

Page 22: Online auction system srs  riport

DATE:-

EXPERIMENT NO: -5

AIM:- To draw the structural view diagram for the system

PEN NO:-130843131016 page no:

Page 23: Online auction system srs  riport

DATE:

EXPERIMENT NO: -5.1

AIM:- To perform the Class diagram for the sytem.

Customer

ID:U_Name:Address:Phone no:Email ID:

Bid ()Get Product Auction ()

Post Product ()Send message()

sold product()

Product

p_id:p_name:p_price:

p_photos:Description:bid_start:max_bid:category:

Sold product

Name:sold_date:max_price:

buyer:seller:

Operations

Category

c_id:name:

Super category:

PEN NO:-130843131016 page no:

Page 24: Online auction system srs  riport

DATE:

EXPERIMENT NO: -5.2

AIM:- To perform the Object diagram for the system.

Customer

ID,U_Name,Address,Phone no,Email

ID

Product

p_id, p_name, p_price, p_photos,

Description, bid_start, max_bid,

category

Sold Product

Name, sold_date, max_price, buyer,

seller

1 *

*

1

*

*

PEN NO:-130843131016 page no:

Page 25: Online auction system srs  riport

DATE:-

EXPERIMENT NO: -6

AIM:- To draw the behavioral view diagram for the system

PEN NO:-130843131016 page no:

Page 26: Online auction system srs  riport

DATE:-EXPERIMENT NO: -6.1

AIM:- To perform the Sequence diagram for the sytem.

Buyer Auction System Seller

Registration

Conformation

Login

Authentication check

Search product

View product

Search product

Requirement

Suggestion

Bidding the product

Auction close

Auctiontime

expired

Registration

Conformation

Authentication check

Login

Post the product

Conformation

Post the product

Conformation

Final update status

PEN NO:-130843131016 page no:

Page 27: Online auction system srs  riport

DATE:

EXPERIMENT NO: -6.2

AIM:- To perform the Collaboration diagram for the system.

Online Auction

System

User(Seller/Buyer)

1. Authentication 2. Validate user

3. Product Search 4. View Product

5.Post product 6.Conformation

7.Bid product8. View update

9. Communication 10. Provied communication

PEN NO:-130843131016 page no:

Page 28: Online auction system srs  riport

DATE:

EXPERIMENT NO: -6.3

AIM:- To perform the State Chart diagram for the system.

Login

Req. for Product

Details

Buying

Biding

Communication

Invalid User

Authentication User

Product Available

Req. satisfy

Req. Not satisfy

Low Bid

Max Bid

PEN NO:-130843131016 page no:

Page 29: Online auction system srs  riport

DATE:

EXPERIMENT NO: -6.4

AIM:- To perform the Activity diagram for the system.

Login

Valid

User type

Post Product Search Product

Check Product Availability

Biding

Max bid

Buy Product

Communication

Inva

lid id

/pas

swor

d

valid id&password

Buyer

no

Seller

yes

yes

no

Communication with winer Buyer

PEN NO:-130843131016 page no:

Page 30: Online auction system srs  riport

DATE:

EXPERIMENT NO: -6.5

AIM:- To perform the Swimlan diagram for the system.

SellerAuction System

Buyer

Login

Post Product

Login

Check Post

Product Availability

no

View Post

Biding

View Post

Max bidno

Win the product

yes

More biding

no

yes

PEN NO:-130843131016 page no:

Page 31: Online auction system srs  riport

DATE:-

EXPERIMENT NO: -7

AIM:- To perform the implementation’s view analysis for the system

PEN NO:-130843131016 page no:

Page 32: Online auction system srs  riport

DATE:

EXPERIMENT NO: -7.1

AIM:- To perform the Componant diagram for the system.

Auction Management

User Detail

Manage

Product Detail

Bid Detail

Sold Detail

PEN NO:-130843131016 page no:

Page 33: Online auction system srs  riport

DATE:-

EXPERIMENT NO: -8

AIM:- To perform the enviormental’s view analysis for the system

PEN NO:-130843131016 page no:

Page 34: Online auction system srs  riport

DATE:

EXPERIMENT NO: -8.1

AIM:- To perform the Deployment diagram for the system.

Database Server

Web Server

Auction System

Auction System Auction System Auction System

PEN NO:-130843131016 page no:

Page 35: Online auction system srs  riport

DATE:-

EXPERIMENT NO: -9

AIM:- To implement the system along with the data base connectivity. (Mandatory)

PEN NO:-130843131016 page no:

Page 36: Online auction system srs  riport

DATE:

EXPERIMENT NO: -9

AIM:- Snapshots of the User interface along with outcomes

1. Login Page

-Select Seller/Buyer.

PEN NO:-130843131016 page no:

Page 37: Online auction system srs  riport

2. Registration

PEN NO:-130843131016 page no:

Page 38: Online auction system srs  riport

3. If Seller Login then open Add product page

.

4. If Buyer Login then open Category page and Category wise Search Product.

PEN NO:-130843131016 page no:

Page 39: Online auction system srs  riport

5. Select The category then open this category product show.

PEN NO:-130843131016 page no:

Page 40: Online auction system srs  riport

6. Select Any one product and click on photo then open full description this product and bid the product.

.

PEN NO:-130843131016 page no:

Page 41: Online auction system srs  riport

7. When auction has to started count down also started with that bid price is display into Bid price list.

PEN NO:-130843131016 page no:

Page 42: Online auction system srs  riport

PEN NO:-130843131016 page no:

Page 43: Online auction system srs  riport

Date:

PRACTICAL No:-10

AIM: To design the various test cases to perform the testing of the system and Also perform the following testing using the various testing tools

10.1 Unit testing

Definition:

Unit Testing is a level of software testing where individual units/ components of a software are tested. The purpose is to validate that each unit of the software performs as designed.

A unit is the smallest testable part of software. It usually has one or a few inputs and usually a single output. In procedural programming a unit may be an individual program, function, procedure, etc. In object-oriented programming, the smallest unit is a method, which may belong to a base/ super class, abstract class or derived/ child class. (Some treat a module of an application as a unit. This is to be discouraged as there will probably be many individual units within that module.)

Unit testing frameworks, drivers, stubs, and mock/ fake objects are used to assist in unit testing.

METHOD:-

Unit Testing is performed by using the White box Testing method.

When is it performed?

Unit Testing is the first level of testing and is performed prior to integration testing..

Who performs it?

Unit Testing is normally performed by software developers themselves or their peers. In rare cases it may also be performed by independent software testers.

TASKS

Unit Test Plan o Prepareo Reviewo Reworko Baseline

Unit Test Cases/Scripts

PEN NO:-130843131016 page no:

Page 44: Online auction system srs  riport

o Prepareo Reviewo Reworko Baseline

Unit Test o Perform

Advantage:-

Unit testing increases confidence in changing/ maintaining code. If good unit tests are written and if they are run every time any code is changed, we will be able to promptly catch any defects introduced due to the change. Also, if codes are already made less interdependent to make unit testing possible, the unintended impact of changes to any code is less.

Codes are more reusable. In order to make unit testing possible, codes need to be modular. This means that codes are easier to reuse.

Development is faster. How? If you do not have unit testing in place, you write your code and perform that fuzzy ‘developer test’ (You set some breakpoints, fire up the GUI, provide a few inputs that hopefully hit your code and hope that you are all set.) If you have unit testing in place, you write the test, write the code and run the test. Writing tests takes time but the time is compensated by the less amount of time it takes to run the tests; You need not fire up the GUI and provide all those inputs. And, of course, unit tests are more reliable than ‘developer tests’. Development is faster in the long run too. How? The effort required to find and fix defects found during unit testing is very less in comparison to the effort required to fix defects found during system testing or acceptance testing.

The cost of fixing a defect detected during unit testing is lesser in comparison to that of defects detected at higher levels. Compare the cost (time, effort, destruction, humiliation) of a defect detected during acceptance testing or when the software is live.

Debugging is easy. When a test fails, only the latest changes need to be debugged. With testing at higher levels, changes made over the span of several days/ weeks/ months need to be scanned.

Methodology: White box testing

DEFINITION :-

White Box Testing (also known as Clear Box Testing, Open Box Testing, Glass Box Testing, Transparent Box Testing, Code-Based Testing or Structural Testing) is a software testing method in which the internal structure/ design/ implementation of the item being tested is known to the tester. The tester chooses inputs to exercise paths through the code and determines the appropriate outputs. Programming know-how and the implementation knowledge is essential. White box testing is testing beyond the user interface and into the nitty-gritty of a system.

This method is named so because the software program, in the eyes of the tester, is like a white/ transparent box; inside which one clearly sees.

PEN NO:-130843131016 page no:

Page 45: Online auction system srs  riport

EXAMPLE:-

A tester, usually a developer as well, studies the implementation code of a certain field on a webpage, determines all legal (valid and invalid) AND illegal inputs and verifies the outputs against the expected outcomes, which is also determined by studying the implementation code.

White Box Testing is like the work of a mechanic who examines the engine to see why the car is not moving.

WHITE BOX TESTING ADVANTAGES

Testing can be commenced at an earlier stage. One need not wait for the GUI to be available.

Testing is more thorough, with the possibility of covering most paths.

WHITE BOX TESTING DISADVANTAGES

Since tests can be very complex, highly skilled resources are required, with thorough knowledge of programming and implementation.

Test script maintenance can be a burden if the implementation changes too frequently. Since this method of testing it closely tied with the application being testing, tools to

cater to every kind of implementation/platform may not be readily available.

PEN NO:-130843131016 page no:

Page 46: Online auction system srs  riport

10.2 Integration testing

DEFINITION:-

Integration Testing is a level of software testing where individual units are combined and tested as a group.

The purpose of this level of testing is to expose faults in the interaction between integrated units. Test drivers and test stubs are used to assist in Integration Testing.

TASKS

Integration Test Plan o Prepareo Reviewo Reworko Baseline

Integration Test Cases/Scripts o Prepareo Reviewo Reworko Baseline

Integration Test o Perform

When is Integration Testing performed?

Integration Testing is performed after unit testing and before system testing.

Who performs Integration Testing?

Either Developers themselves or independent Testers perform Integration Testing.

APPROACHES

Big Bang is an approach to Integration Testing where all or most of the units are combined together and tested at one go. This approach is taken when the testing team receives the entire software in a bundle. So what is the difference between Big Bang Integration Testing and System Testing? Well, the former tests only the interactions between the units while the latter tests the entire system.

Top Down is an approach to Integration Testing where top level units are tested first and lower level units are tested step by step after that. This approach is taken when top down development approach is followed. Test Stubs are needed to simulate lower level units which may not be available during the initial phases.

PEN NO:-130843131016 page no:

Page 47: Online auction system srs  riport

Bottom Up is an approach to Integration Testing where bottom level units are tested first and upper level units step by step after that. This approach is taken when bottom up development approach is followed. Test Drivers are needed to simulate higher level units which may not be available during the initial phases.

Sandwich/Hybrid is an approach to Integration Testing which is a combination of Top Down and Bottom Up approaches.

METHOD

Any of black box testing ,white box testing and gray box testing methods can be used. Normally, the method depends on your definition of ‘unit’.

BLACK BOX TESTING:-

DEFINITION:-

Black Box Testing, also known as Behavioral Testing, is a software testing method in which the internal structure/ design/ implementation of the item being tested is not known to the tester. These tests can be functional or non-functional, though usually functional.

This method is named so because the software program, in the eyes of the tester, is like a black box; inside which one cannot see. This method attempts to find errors in the following categories:

Incorrect or missing functions Interface errors Errors in data structures or external database access Behavior or performance errors Initialization and termination errors

EXAMPLE:-

PEN NO:-130843131016 page no:

Page 48: Online auction system srs  riport

A tester, without knowledge of the internal structures of a website, tests the web pages by using a browser; providing inputs (clicks, keystrokes) and verifying the outputs against the expected outcome.

BLACK BOX TESTING TECHNIQUES

Following are some techniques that can be used for designing black box tests.

Equivalence partitioning: It is a software test design technique that involves dividing input values into valid and invalid partitions and selecting representative values from each partition as test data.

Boundary Value Analysis: It is a software test design technique that involves determination of boundaries for input values and selecting values that are at the boundaries and just inside/ outside of the boundaries as test data.

Cause Effect Graphing: It is a software test design technique that involves identifying the cases (input conditions) and effects (output conditions), producing a Cause-Effect Graph, and generating test cases accordingly.

ADVANTAGES

Tests are done from a user’s point of view and will help in exposing discrepancies in the specifications.

Tester need not know programming languages or how the software has been implemented.

Tests can be conducted by a body independent from the developers, allowing for an objective perspective and the avoidance of developer-bias.

Test cases can be designed as soon as the specifications are complete.

BLACK BOX TESTING DISADVANTAGES

Only a small number of possible inputs can be tested and many program paths will be left untested.

Without clear specifications, which is the situation in many projects, test cases will be difficult to design.

Tests can be redundant if the software designer/ developer has already run a test case. Ever wondered why a soothsayer closes the eyes when foretelling events? So is almost

the case in Black Box Testing.

PEN NO:-130843131016 page no: