Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
What is Black Box and White Box Testing Strategy

What is Black Box and White Box Testing Strategy

Ratings: (0)|Views: 3,704|Likes:
Published by Sanjay Dudani
What is Black Box and White Box Testing Strategy
Computer Software Engineering
What is Black Box and White Box Testing Strategy
Computer Software Engineering

More info:

Published by: Sanjay Dudani on Nov 25, 2009
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





What is a White Box Testing Strategy?
White box testing strategy deals with the internal logic and structure of the code. White box testing isalso called as glass, structural, open box or clear box testing. The tests written based on the white boxtesting strategy incorporate coverage of the code written, branches, paths, statements and internal logicof the code etc.In order to implement white box testing, the tester has to deal with the code and hence is needed topossess knowledge of coding and logic i.e. internal working of the code. White box test also needs thetester to look into the code and find out which unit/statement/chunk of the code is malfunctioning.
Advantages of White box testing are:
i) As the knowledge of internal coding structure is prerequisite, it becomes very easy to find out whichtype of input/data can help in testing the application effectively.ii) The other advantage of white box testing is that it helps in optimizing the codeiii) It helps in removing the extra lines of code, which can bring in hidden defects.
Disadvantages of white box testing are:
i) As knowledge of code and internal structure is a prerequisite, a skilled tester is needed to carry outthis type of testing, which increases the cost.ii) And it is nearly impossible to look into every bit of code to find out hidden errors, which may createproblems, resulting in failure of the application.
Types of testing under White/Glass Box Testing Strategy:Unit Testing:
The developer carries out unit testing in order to check if the particular module or unit of code isworking fine. The Unit Testing comes at the very basic level as it is carried out as and when the unit of the code is developed or a particular functionality is built.
Static and dynamic Analysis:
Static analysis involves going through the code in order to find out any possible defect in the code.Dynamic analysis involves executing the code and analyzing the output.
Statement Coverage:
In this type of testing the code is executed in such a manner that every statement of the application isexecuted at least once. It helps in assuring that all the statements execute without any side effect.
Branch Coverage:
No software application can be written in a continuous mode of coding, at some point we need tobranch out the code in order to perform a particular functionality. Branch coverage testing helps in1
validating of all the branches in the code and making sure that no branching leads to abnormal behaviorof the application.
Security Testing:
Security Testing is carried out in order to find out how well the system can protect itself fromunauthorized access, hacking – cracking, any code damage etc. which deals with the code of application.This type of testing needs sophisticated testing techniques.
Mutation Testing:
A kind of testing in which, the application is tested for the code that was modified after fixing aparticular bug/defect. It also helps in finding out which code and which strategy of coding can help indeveloping the functionality effectively.Besides all the testing types given above, there are some more types which fall under both Black boxand White box testing strategies such as: Functional testing (which deals with the code in order to checkits functional performance), Incremental integration testing (which deals with the testing of newlyadded code in the application), Performance and Load testing (which helps in finding out how theparticular code manages resources and give performance etc.) etc.
What is white box testing?
White box testing traditionally refers to the use of program source code as a test basis, that is, as thebasis for designing tests and test cases.(IEEE standards define a test as "a set of one or more test cases.") A looser definition says that "white box testing is based on internal structures of the software",but it is very unclear what kinds of "internal structure" are covered by this. Some authorities, forexample, include user-facing menus and even business processes. The term "gray box testing" is now in widespread use for internal software structures that are not actually source code - for example, classhierarchies or module call trees. In the following discussion, "white box testing" is held to besynonymous with "code-based testing."Those two terms are opposed to "requirements-based" or "specification-based" testing, also known asblack box testing. The implication there is that you can't see the inner workings of a black-painted box;and in fact, you don't need to see the inner workings to test whether a given set of inputs results in therequired or specified set of outputs. But if you do need to test the inner workings, painting the boxwhite would leave them just as invisible as when the box was black, so the terms "clear box testing" and"glass box testing" are also used. (The word "analysis" is sometimes used in place of "testing.")White-box testing usually involves tracing possible execution paths through the code and working outwhat input values would force the execution of those paths. Quite simple techniques exist by which thetester (usually the developer who wrote the code) can work out the smallest number of paths necessaryto test, or "cover," all the code. Some types of static analysis tool will do the same job, more quickly andmore reliably.White box testing, on its own, cannot identify problems caused by mismatches between the actualrequirements or specification and the code as implemented but it can help identify some types of designweaknesses in the code. Examples include control flow problems (e.g., closed orinfinite loops or unreachable code), and data flow problems (e.g., trying to use a variable which has no defined value).Static code analysis (by a tool) may also find these sorts of problems, but doesn't help the2
tester/developer understand the code to the same degree that personally designing white-box testcases does.White box testing is usually associated with component testing (i.e.,unit testing), and with the conceptthat, at minimum, 100% of the component's code statements should be tested before the component isreleased for use ("100% code coverage"). But it may be dangerous to design white box test cases simplyto achieve such a standard. This is not only because it will miss disconnects between code andspecifications, but because the test cases are often artificial and unrepresentative of how thecomponent will actually be used. The test cases may even be impossible to execute (corresponding to"unachievable" or "infeasible" paths. A tool will avoid generating these).A better approach may be to design enough test cases to cover all requirements specified for thecomponent (black box testing), then use a code coverage monitor to record how much of the code isactually covered (executed) when the test cases are run. Often, the code will fall into two parts: codestatements that correspond directly to the requirements and get covered by the black box test cases;and code statements that deal with aspects of the target execution environment, which may not beexplicitly specified but which the developer is expected to provide. This second type of code oftenprovides error handling for exceptions thrown by hardware or software conditions (e.g., by a databasemanagement system), and often goes untested - which may cause severe problems when such anexception occurs in live use. The developer would use white box techniques to work out how to drivethe testing of those statements not covered by the black box test cases.
What is a Black Box Testing Strategy?
Black Box Testing is not a type of testing; it instead is a testing strategy, which does not needany knowledge of internal design or code etc. As the name "black box" suggests, no knowledgeof internal logic or code structure is required. The types of testing under this strategy are totallybased/focused on the testing for requirements and functionality of the work product/softwareapplication. Black box testing is sometimes also called as "Opaque Testing",

Activity (37)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
haleem81 liked this
Anandhi Raghul liked this
Fasi Mughal liked this
swapnil32 liked this
sunnals liked this
Abdullah Shakir liked this
Sandeep Dhiman liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->