white box and block box testing
Posted in materials
No comments:
Tuesday, March 19, 2013
Black Box Testing
Black box tests are those which the software under test is treated as a black box. You can't "see" into it. The test provides inputs and responds to outputs without considering how the software works. Black box 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.
White Box Testing
White box testing is used to test areas that cannot be reached from a black box level. White box testing (a.k.a. clear box testing, glass box testing or structural testing) uses an internal perspective of the system to design test cases based on internal structure. It requires programming skills to identify all paths through the software. The tester chooses test case inputs to exercise paths through the code and determines the appropriate outputs. In electrical hardware testing, every node in a circuit may be probed and measured; an example is in-circuit testing (ICT).
Since the tests are based on the actual implementation, if the implementation changes, the tests probably will need to change, too. For example ICT needs updates if component values change, and needs modified/new fixture if the circuit changes. This adds financial resistance to the change process, thus buggy products may stay buggy. Automated optical inspection (AOI) offers similar component level correctness checking without the cost of ICT fixtures; however changes still require test updates.
While white box testing is applicable at the unit, integration and system levels of the software testing process, it is typically applied to the unit. While it normally tests paths within a unit, it can also test paths between units during integration, and between subsystems during a system level test. Though this method of test design can uncover an overwhelming number of test cases, it might not detect unimplemented parts of the specification or missing requirements, but one can be sure that all paths through the test object are executed.
Advantages and Disadvantages of White Box Testing
Advantages of White box testing are:
i) As the knowledge of internal coding structure is prerequisite, it becomes very easy to find out which type 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 code
iii) It helps in removing the extra lines of code, which can bring in hidden defects.
iv) Forces test developer to reason carefully about implementation
White-box testing is an important method for the early detection of errors during software development. In this process test case
generation plays a crucial role, defining appropriate and error-sensitive test data. White-box testing strategies include designing tests such that every line of source code is executed at least once, or requiring every function to be individually tested. Code coverage is a significant benefit provided by white box testing. It is much easier to determine if you've looked at all functions, libraries, etc, when you know what they all are.
Disadvantages of white box testing are:
i) As knowledge of code and internal structure is a prerequisite, a skilled tester is needed to carry out this 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 create problems, resulting in failure of the application.
iii) Not looking at the code in a runtime environment. That's important for a number of reasons. Exploitation of a vulnerability is dependent upon all aspects of the platform being targeted and source code is just of those components. The underlying operating system, the backend database being used, third party security tools, dependent libraries, etc. must all be taken into account when determining exploitability. A source code review is not able to take these factors into account.
iv) Very few white-box tests can be done without modifying the program, changing values to force different execution paths, or to generate a full range of inputs to test a particular function.
v) Miss cases omitted in the code
Difference between white box testing and black box testing:
White box testing:
White box testing is done by the Developers. This requires knowledge of the internal coding of the software.
White box testing is concerned with testing the implementation of the program. The intent of this testing is not to exercise all the different input or output conditions, but to exercise different programming structures and data structures used in the program. It is commonly called structural testing.
White box testing mainly applicable to lower levels of testing: Unit testing and Integration Testing.
Implementation knowledge is required for white box testing.
Black box testing:
Black box testing is done by the professional testing team. This does not require knowledge of internal coding of the application. Testing the application against the functionality of the application without the knowledge of internal coding of the software.
In Black box testing the structure of the program is not considered. Test cases are decided solely on the basis of the requirements or specification of the program or module.
Black box testing mainly applicable to higher levels of testing: Acceptance Testing and System Testing.
Implementation knowledge is not required for black box testing.
Black box tests are those which the software under test is treated as a black box. You can't "see" into it. The test provides inputs and responds to outputs without considering how the software works. Black box 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.
Advantages of Black Box Testing are
mentioned below:
- Ease of use: Since tester are not required to have knowledge about the internal coding, it is easier for testers to test the application and create test cases.
- Easier test cases preparation: Since tester will be having concerned towards functionality and GUI test cases preparation will be easier.
- Simplicity: For testing of large and complex systems black box testing simplifies the testing by having a concept of valid and invalid inputs and checking for correct outputs.
- Tester can be non-technical.
- Black box tests are reproducible.
- Tests are done from end users point of view which means better quality, meeting customers’ requirements.
- Expose ambiguities and complexities in application.
- Test cases can be designed as soon as the specifications are complete.
Disadvantages of Black Box Testing
are mentioned below:
- Reason for failure cannot be known.
- Not all the properties of software or application be tested.
- Maintaining test cases is difficult if the requirements are constantly changing.
- Only limited number of test cases can be executed.
- Without clear specification test cases cannot be prepared.
- Repetition of test cases might happen.
- Quality of coding and adherence to coding standards will be unknown.
White Box Testing
White box testing is used to test areas that cannot be reached from a black box level. White box testing (a.k.a. clear box testing, glass box testing or structural testing) uses an internal perspective of the system to design test cases based on internal structure. It requires programming skills to identify all paths through the software. The tester chooses test case inputs to exercise paths through the code and determines the appropriate outputs. In electrical hardware testing, every node in a circuit may be probed and measured; an example is in-circuit testing (ICT).
Since the tests are based on the actual implementation, if the implementation changes, the tests probably will need to change, too. For example ICT needs updates if component values change, and needs modified/new fixture if the circuit changes. This adds financial resistance to the change process, thus buggy products may stay buggy. Automated optical inspection (AOI) offers similar component level correctness checking without the cost of ICT fixtures; however changes still require test updates.
While white box testing is applicable at the unit, integration and system levels of the software testing process, it is typically applied to the unit. While it normally tests paths within a unit, it can also test paths between units during integration, and between subsystems during a system level test. Though this method of test design can uncover an overwhelming number of test cases, it might not detect unimplemented parts of the specification or missing requirements, but one can be sure that all paths through the test object are executed.
Advantages and Disadvantages of White Box Testing
Advantages of White box testing are:
i) As the knowledge of internal coding structure is prerequisite, it becomes very easy to find out which type 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 code
iii) It helps in removing the extra lines of code, which can bring in hidden defects.
iv) Forces test developer to reason carefully about implementation
White-box testing is an important method for the early detection of errors during software development. In this process test case
generation plays a crucial role, defining appropriate and error-sensitive test data. White-box testing strategies include designing tests such that every line of source code is executed at least once, or requiring every function to be individually tested. Code coverage is a significant benefit provided by white box testing. It is much easier to determine if you've looked at all functions, libraries, etc, when you know what they all are.
Disadvantages of white box testing are:
i) As knowledge of code and internal structure is a prerequisite, a skilled tester is needed to carry out this 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 create problems, resulting in failure of the application.
iii) Not looking at the code in a runtime environment. That's important for a number of reasons. Exploitation of a vulnerability is dependent upon all aspects of the platform being targeted and source code is just of those components. The underlying operating system, the backend database being used, third party security tools, dependent libraries, etc. must all be taken into account when determining exploitability. A source code review is not able to take these factors into account.
iv) Very few white-box tests can be done without modifying the program, changing values to force different execution paths, or to generate a full range of inputs to test a particular function.
v) Miss cases omitted in the code
Difference between white box testing and black box testing:
White box testing:
White box testing is done by the Developers. This requires knowledge of the internal coding of the software.
White box testing is concerned with testing the implementation of the program. The intent of this testing is not to exercise all the different input or output conditions, but to exercise different programming structures and data structures used in the program. It is commonly called structural testing.
White box testing mainly applicable to lower levels of testing: Unit testing and Integration Testing.
Implementation knowledge is required for white box testing.
Black box testing:
Black box testing is done by the professional testing team. This does not require knowledge of internal coding of the application. Testing the application against the functionality of the application without the knowledge of internal coding of the software.
In Black box testing the structure of the program is not considered. Test cases are decided solely on the basis of the requirements or specification of the program or module.
Black box testing mainly applicable to higher levels of testing: Acceptance Testing and System Testing.
Implementation knowledge is not required for black box testing.
Related posts
Share this post
0 comments: