1. DATE
PRACTICAL: 1
AIM: Study various problem domain and selectone problem and identify the
problem definition. Also specify and elaborate the model for your
System
1.1ProblemDefinition
Online Auction System
1.2 Software DevelopmentLife 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
2. 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 as
well 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.
3. 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 of
other systems. A reliable Online Auction System can be developed in the considerable
amount of time.
1.2.2Requirementanalysis 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.3SystemDesign
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.
4. 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 SystemCoding
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 detail
During 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
5. 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
8. PEN NO:-130843131016 page no:
Table of Contents
Table of Contents ...........................................................................................................................8
Revision History .............................................................................................................................8
1. Introduction..............................................................................................................................9
1.1 Purpose..................................................................................................................................9
1.2 Document Conventions ...........................................................................................................9
1.3 Intended Audience and Reading Suggestions............................................................................9
1.4 Product Scope ........................................................................................................................9
1.5 References .............................................................................. Error! Bookmark not defined.
2. Overall Description................................................................................................................10
2.1 Product Perspective .............................................................................................................. 10
2.2 Product Functions ................................................................................................................. 10
2.3 User Classes and Characteristics............................................................................................ 10
2.4 Operating Environment......................................................................................................... 10
2.5 Design and Implementation Constraints ................................................................................. 10
2.6 User Documentation ...............................................................................................................3
2.7 Assumptions and Dependencies............................................................................................. 11
3. External Interface Requirements .........................................................................................11
3.1 User Interfaces ..................................................................................................................... 11
3.2 Hardware Interfaces.............................................................................................................. 11
3.3 Software Interfaces.................................................................................................................4
3.4 Communications Interfaces.....................................................................................................4
4. System Features......................................................................................................................12
4.1 System Feature ......................................................................................................................12
4.2 User Details ………………...................................................... Error! Bookmark not defined.
4.3 ProductDetails……………...……………………………………………………………..4
4.4 SellerDetails..……………………………………………………………………………..4
5. Other Nonfunctional Requirements.......................................................................................5
5.1 Performance Requirements......................................................................................................5
5.2 Security Requirements ............................................................................................................5
5.3 Software Quality Attributes.....................................................................................................5
5.4 Business Rules .......................................................................................................................5
6. Other Requirements ...................................................................Error! Bookmark not defined.
Appendix A: Glossary.......................................................................Error! Bookmark not defined.
Appendix B: Analysis Models..........................................................Error! Bookmark not defined.
Appendix C: To Be Determined List...............................................Error! Bookmark not defined.
Revision History
Name Date Reason For Changes Version
9. PEN NO:-130843131016 page no:
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
Font Times New Roman
Bold Mainly for headings and are numbered properly
Italics Mainly Used in References
Blue-Underline Used for URLs
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.
10. PEN NO:-130843131016 page no:
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 Classesand 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 Designand Implementation Constraints
The Mess Management System shall be a Web application system running over web browser
environment. The system shall be developed using java.
11. PEN NO:-130843131016 page no:
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.
12. PEN NO:-130843131016 page no:
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 SellerDetails
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.
13. PEN NO:-130843131016 page no:
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.
14. PEN NO:-130843131016 page no:
DATE:-
EXPERIMENT NO: -3
AIM:- To perform the function & Data oriented diagram for the system
15. PEN NO:-130843131016 page no:
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
16. PEN NO:-130843131016 page no:
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
Sign In
Authentication
Statues Update
Post Product
Communication Communication
Search Product
View Product
Product
Modify
Modify
Fetch
Fetch
update
Fetch
Authentication
SignIn
Customer
Verification
Modify
21. PEN NO:-130843131016 page no:
DATE:-
EXPERIMENT NO: -5
AIM:- To draw the structural view diagram for the system
22. PEN NO:-130843131016 page no:
DATE:
EXPERIMENT NO: -5.1
AIM:- To perform the Class diagramfor 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:
23. PEN NO:-130843131016 page no:
DATE:
EXPERIMENT NO: -5.2
AIM:- To perform the Object diagram for the system.
Customer
ID,U_Name,Addres
s,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
*
*
24. PEN NO:-130843131016 page no:
DATE:-
EXPERIMENT NO: -6
AIM:- To draw the behavioral view diagram for the system
25. PEN NO:-130843131016 page no:
DATE:-
EXPERIMENT NO:-6.1
AIM:- To perform the Sequence diagramfor the sytem.
Buyer Auction System Seller
Registration
Conformation
Login
Authentication
check
Search product
View product
Search product
Requirement
Suggestion
Bidding the
product
Auction close
Auction
time
expired
Registration
Conformation
Authentication check
Login
Post the product
Conformation
Post the product
Conformation
Final update status
26. PEN NO:-130843131016 page no:
DATE:
EXPERIMENT NO: -6.2
AIM:- To perform the Collaboration diagramfor 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 product
8. View update
9. Communication
10. Provied communication
27. PEN NO:-130843131016 page no:
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
28. PEN NO:-130843131016 page no:
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
Invalidid/password
valid id&password
Buyer
no
Seller
yes
yes
no
Communication
with winer Buyer
29. PEN NO:-130843131016 page no:
DATE:
EXPERIMENT NO: -6.5
AIM:- To perform the Swimlan diagram for the system.
Seller
Auction
System
Buyer
Login
Post Product
Login
Check Post
Product
Availability
no
View Post
Biding
View Post
Max bid
no
Win the
product
yes
More biding
no
yes
30. PEN NO:-130843131016 page no:
DATE:-
EXPERIMENT NO: -7
AIM:- To perform the implementation’s view analysis for the system
31. PEN NO:-130843131016 page no:
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
32. PEN NO:-130843131016 page no:
DATE:-
EXPERIMENT NO: -8
AIM:- To perform the enviormental’s view analysis for the system
33. PEN NO:-130843131016 page no:
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
34. PEN NO:-130843131016 page no:
DATE:-
EXPERIMENT NO: -9
AIM:- To implement the system along with the data base
connectivity. (Mandatory)
35. PEN NO:-130843131016 page no:
DATE:
EXPERIMENT NO: -9
AIM:- Snapshots of the User interface along with outcomes
1. Login Page
-Select Seller/Buyer.
37. PEN NO:-130843131016 page no:
3. If Seller Login then open Add product page
.
4. If Buyer Login then open Category page and Category wise Search Product.
42. PEN NO:-130843131016 page no:
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 Prepare
o Review
o Rework
o Baseline
Unit Test Cases/Scripts
43. PEN NO:-130843131016 page no:
o Prepare
o Review
o Rework
o 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.
44. PEN NO:-130843131016 page no:
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.
45. PEN NO:-130843131016 page no:
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 Prepare
o Review
o Rework
o Baseline
Integration Test Cases/Scripts
o Prepare
o Review
o Rework
o 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.
46. PEN NO:-130843131016 page no:
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:-
47. PEN NO:-130843131016 page no:
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.
