White Box Testing Technique
White box testing examines the basic program structure and it derives the test data from the program logic, ensuring that all statements and conditions have been executed at least once.
White box tests verify that the software design is valid and also whether it was built according to the specified design.
Different methods used are:
Statement coverage – executes all statements at least once. (each and every line)
Decision coverage – executes each decision direction at least once.
Condition coverage –executes each and every condition in the program with all possible outcomes at least once.
Black Box Testing Technique
Black-box test technique treats the system as a "black-box", so it doesn't explicitly use knowledge of the internal structure. Black-box test design is usually described as focusing on testing functional requirements. Synonyms for black box include: Behavioral, Functional, Opaque-box, and Closed-box.
White box testing examines the basic program structure and it derives the test data from the program logic, ensuring that all statements and conditions have been executed at least once.
White box tests verify that the software design is valid and also whether it was built according to the specified design.
Different methods used are:
Statement coverage – executes all statements at least once. (each and every line)
Decision coverage – executes each decision direction at least once.
Condition coverage –executes each and every condition in the program with all possible outcomes at least once.
Black Box Testing Technique
Black-box test technique treats the system as a "black-box", so it doesn't explicitly use knowledge of the internal structure. Black-box test design is usually described as focusing on testing functional requirements. Synonyms for black box include: Behavioral, Functional, Opaque-box, and Closed-box.
Black box testing is conducted on integrated, functional components whose design integrity has been verified through completion of traceable white box tests. Black box testing traces the requirements focusing on system externals. It validates that the software meets the requirements irrespective of the paths of execution taken to meet each requirements.
Three successful techniques for managing the amount of input data required includes :
· Equivalence Partitioning
· Boundary Analysis
· Error Guessing
Equivalence Partitioning:
Equivalence partitioning is the process of methodically reducing the huge(infinite)set of possible test cases into a much smaller, but still equally effective set. An Equivalence class is a subset of data that is representative of a larger class. Equivalence partitioning is a technique for testing equivalence classes rather than undertaking exhaustive testing of each value of the larger class, when looking for equivalence partitions, think about ways to group similar inputs, similar outputs, and similar operations of the software. These groups are the equivalence partitions.
For example
A program that edits credit limits within a given range ($20,000-$50,000) would have three equivalence classes:
Less than $20,000(invalid)
Between $20,000 and $50,000 (valid)
Greater than $50,000(invalid)
Boundary value analysis:
If one can safely and confidently walk along the edge of a cliff without falling off, he can almost certainly walk in the middle of a field. If software can operate on the edge of its capabilities, it will almost certainly operate well under normal conditions.
This technique consist of developing test cases and data that focus on the input and output boundaries of a given function. In same credit limit example, boundary analysis would test:
Low boundary plus or minus one ($19,999 and $20,001)
On the boundary ($20,000 and $50,000)
Upper boundary plus or minus one ($49,999 and $50,001)
Error Guessing
This is based on the theory that test cases can be developed based upon the intuition and experience of the Test-Engineer.
Example: In the example of date, where one of the inputs is the date, a test may try February 29, 2000 or 9.9.99
Incremental testing
Incremental testing is a disciplined method of testing the interfaces between unit-tested programs as well as between system components. It involves adding unit-tested programs to a given module or component one by one, and testing each result and combination.
There are two types of incremental testing:
Top-down: - This begins testing from top of the module hierarchy and work down to the bottom using interim stubs to simulate lower interfacing modules or programs. Modules are added in descending hierarchical order.
Bottom-up: - This begins testing from the bottom of the hierarchy and works up to the top. Modules are added in ascending hierarchical order. Bottom-up testing requires the development of driver modules, which provide the test input, call the module or program being tested, and display test output.
There are procedures and constraints associated with each of these methods, although bottom-up testing is often thought to be easier to use. Drivers are often easier to create than stubs, and can serve multiple purposes. Output is also often easier to examine in bottom-up testing, as the output always comes from the module directly above the module under test.
· Equivalence Partitioning
· Boundary Analysis
· Error Guessing
Equivalence Partitioning:
Equivalence partitioning is the process of methodically reducing the huge(infinite)set of possible test cases into a much smaller, but still equally effective set. An Equivalence class is a subset of data that is representative of a larger class. Equivalence partitioning is a technique for testing equivalence classes rather than undertaking exhaustive testing of each value of the larger class, when looking for equivalence partitions, think about ways to group similar inputs, similar outputs, and similar operations of the software. These groups are the equivalence partitions.
For example
A program that edits credit limits within a given range ($20,000-$50,000) would have three equivalence classes:
Less than $20,000(invalid)
Between $20,000 and $50,000 (valid)
Greater than $50,000(invalid)
Boundary value analysis:
If one can safely and confidently walk along the edge of a cliff without falling off, he can almost certainly walk in the middle of a field. If software can operate on the edge of its capabilities, it will almost certainly operate well under normal conditions.
This technique consist of developing test cases and data that focus on the input and output boundaries of a given function. In same credit limit example, boundary analysis would test:
Low boundary plus or minus one ($19,999 and $20,001)
On the boundary ($20,000 and $50,000)
Upper boundary plus or minus one ($49,999 and $50,001)
Error Guessing
This is based on the theory that test cases can be developed based upon the intuition and experience of the Test-Engineer.
Example: In the example of date, where one of the inputs is the date, a test may try February 29, 2000 or 9.9.99
Incremental testing
Incremental testing is a disciplined method of testing the interfaces between unit-tested programs as well as between system components. It involves adding unit-tested programs to a given module or component one by one, and testing each result and combination.
There are two types of incremental testing:
Top-down: - This begins testing from top of the module hierarchy and work down to the bottom using interim stubs to simulate lower interfacing modules or programs. Modules are added in descending hierarchical order.
Bottom-up: - This begins testing from the bottom of the hierarchy and works up to the top. Modules are added in ascending hierarchical order. Bottom-up testing requires the development of driver modules, which provide the test input, call the module or program being tested, and display test output.
There are procedures and constraints associated with each of these methods, although bottom-up testing is often thought to be easier to use. Drivers are often easier to create than stubs, and can serve multiple purposes. Output is also often easier to examine in bottom-up testing, as the output always comes from the module directly above the module under test.
0 comments:
Post a Comment