- Incorrect or missing functions
- Interface errors
- Errors in data structures or external database access
- Behavior or performance errors
- Initialization and termination errors
- 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
- 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.
- black box testing: Testing, either functional or non-functional, without reference to the
- internal structure of the component or system.
- black box test design technique: Procedure to derive and/or select test cases based on an
- analysis of the specification, either functional or non-functional, of a component or system
- without reference to its internal structure.
Testing Strategies/Techniques
- black box testing should make use of randomly generated inputs (only a test range should be specified by the tester), to eliminate any guess work by the tester as to the methods of the function
- data outside of the specified input range should be tested to check the robustness of the program
- boundary cases should be tested (top and bottom of specified range) to make sure the highest and lowest allowable inputs produce proper output
- the number zero should be tested when numerical data is to be input
- stress testing should be performed (try to overload the program with inputs to see where it reaches its maximum capacity), especially with real time systems
- crash testing should be performed to see what it takes to bring the system down
- test monitoring tools should be used whenever possible to track which tests have already been performed and the outputs of these tests to avoid repetition and to aid in the software maintenance
- other functional testing techniques include: transaction testing, syntax testing, domain testing, logic testing, and state testing.
- finite state machine models can be used as a guide to design functional tests
- According to Beizer the following is a general order by which tests should be designed:
- Additional structural tests for branch coverage, as needed.
- Additional tests for data-flow coverage as needed.
- Domain tests not covered by the above.
- Special techniques as appropriate--syntax, loop, state, etc.
- Any dirty tests not covered by the above.
- Easy-to-compute data
- Typical data
- Boundary / extreme data
- Bogus data
| a | b | c | Roots |
| 1 | 2 | 1 | -1, -1 |
| 1 | 3 | 2 | -1, -2 |
| a | b | c | Roots |
| 1 | 4 | 1 | -3.73205, -0.267949 |
| 2 | 4 | 1 | -1.70711, -0.292893 |
| a | b | c | Roots |
| 2 | -4 | 2 | 1, 1 |
| 2 | -8 | 8 | 2, 2 |
| a | b | c | Roots |
| 1 | 1 | 1 | square root of negative number |
| 0 | 1 | 1 | division by zero |
- more effective on larger units of code than glass box testing
- tester needs no knowledge of implementation, including specific programming languages
- tester and programmer are independent of each other
- tests are done from a user's point of view
- will help to expose any ambiguities or inconsistencies in the specifications
- test cases can be designed as soon as the specifications are complete
- only a small number of possible inputs can actually be tested, to test every possible input stream would take nearly forever
- without clear and concise specifications, test cases are hard to design
- there may be unnecessary repetition of test inputs if the tester is not informed of test cases the programmer has already tried
- may leave many program paths untested
- cannot be directed toward specific segments of code which may be very complex (and therefore more error prone)
- most testing related research has been directed toward glass box testing
Black Box Testing Strategy
Black Box Testing Example
Advantages and Disadvantages
Advantages of Black Box Testing
Disadvantages of Black Box Testing
Source : http://softwaretestingfundamentals.com
Black box testing
Black bos testing takes an external perspective of the test object to derive test cases. These tests can be functional or non-functional, though usually functional. The test designer selects valid and invalid input and determines the correct output. There is no knowledge of the test object's internal structure.
This method of test design is applicable to all levels of software testing: unit, integration, functional testing, system and acceptance. The higher the level, and hence the bigger and more complex the box, the more one is forced to use black box testing to simplify. While this method can uncover unimplemented parts of the specification, one cannot be sure that all existent paths are tested.
Black Box Testing is not a type of testing; it instead is a testing strategy, which does not need any knowledge of internal design or code etc. As the name "black box" suggests, no knowledge of internal logic or code structure is required. The types of testing under this strategy are totally based/focused on the testing for requirements and functionality of the work product/software application. Black box testing is sometimes also called as "Opaque Testing", "Functional/Behavioral Testing" and "Closed Box Testing".
The base of the Black box testing strategy lies in the selection of appropriate data as per functionality and testing it against the functional specifications in order to check for normal and abnormal behavior of the system. Now a days, it is becoming common to route the Testing work to a third party as the developer of the system knows too much of the internal logic and coding of the system, which makes it unfit to test the application by the developer.
In order to implement Black Box Testing Strategy, the tester is needed to be thorough with the requirement specifications of the system and as a user, should know, how the system should behave in response to the particular action.
Various testing types that fall under the Black Box Testing strategy are: functional testing, stress testing, recovery testing, volume testing, User Acceptance Testing (also known as UAT), system testing, Sanity or Smoke testing, load testing, Usability testing, Exploratory testing, ad-hoc testing, alpha testing, beta testing etc.
These testing types are again divided in two groups: a) Testing in which user plays a role of tester and b) User is not required.
In this technique, we do not use the code to determine a test suite; rather, knowing the problem that we're trying to solve, we come up with four types of test data:
For example, suppose we are testing a function that uses the quadratic formula to determine the two roots of a second-degree polynomial ax2+bx+c. For simplicity, assume that we are going to work only with real numbers, and print an error message if it turns out that the two roots are complex numbers (numbers involving the square root of a negative number).
We can come up with test data for each of the four cases, based on values of the polynomial's discriminant (b2-4ac):
Easy data (discriminant is a perfect square):
Typical data (discriminant is positive):
Boundary / extreme data (discriminant is zero):
Bogus data (discriminant is negative, or a is zero):
As with glass-box testing, you should test your code with each set of test data. If the answers match, then your code passes the black-box test.
source : http://www.onestoptesting.com
Internal system design is not considered in this type of testing. Tests are based on requirements and functionality.
The technique of testing without having any knowledge of the interior workings of the application is Black Box testing. The tester is oblivious to the system architecture and does not have access to the source code. Typically, when performing a black box test, a tester will interact with the system's user interface by providing inputs and examining outputs without knowing how and where the inputs are worked upon.
A method of software testing that verifies the functionality of an application without having specific knowledge of the application's code/internal structure. Tests are based on requirements and functionality. It is performed by QA teams.
in a black box test on a software design the tester only knows the inputs and what the expected outcomes should be and not how the program arrives at those outputs. The tester does not ever examine the programming code and does not need any further knowledge of the program other than its specifications.
Hi....!!! I am a part time blogger.Here i shared some information which are collected from web.I hope you'll enjoy reading. Thank you!
ConversionConversion EmoticonEmoticon