White box testing is a test case design approach that employs the control architecture of the procedural design to produce test cases. Using white box testing approaches, the software engineering can produce test cases that can:
1) Guarantee that all independent paths in a module have been exercised at least once,
2) Exercise all logical decisions,
3) Execute all loops at their boundaries and in their operational bounds,
4) Exercise internal data structures to maintain their validity
2. Black Box Testing
"Testing of a function without knowing internal structure of the program."
Black box testing approaches concentrate on the fundamental requirements of the software. Black box testing allows the software engineer to produce groups of input situations that will fully exercise all functional requirements for a program. Black box testing is not an alternative to white box techniques. It is a complementary approach that is likely to uncover a different type of errors that the white box approaches.
Black box testing tries to find errors in the following categories:
1) Incorrect or missing functions,
2) Interface errors,
3) Errors in data structures or external database access,
4) Performance errors,
5) Initialization and termination errors.
By applying black box approaches we produce a set of test cases that fulfill requirements:
1) Test cases that reduce the number of test cases to achieve reasonable testing,
2) Test cases that tell use something about the presence or absence of classes of errors.
3. Unit Testing
Unit testing concentrates verification on the smallest element of the program – the module. Using the detailed design description important control paths are tested to establish errors within the bounds of the module.
The most ‘micro’ scale of testing to test particular functions or code modules. Typically done by the programmer and not by testers• Unit - smallest testable piece of software• A unit can be compiled/ assembled/ linked/ loaded; and put under a test harness• Unit testing done to show that the unit does not satisfy the functional specification and/ or its implemented structure does not match the intended design structure
4. Validation Testing
As a culmination of testing, software is completely assembled as a package, interfacing errors have been identified and corrected, and a final set of software tests validation testing are started. Validation can be defined in various ways, but a basic one is valid succeeds when the software functions in a fashion that can reasonably expected by the customer.
5. Verification Testing
The process of evaluating a system or component to determine whether the products of the given development phase satisfy the conditions imposed at the start of that phase.
6. Testing for Real-Time Systems
The time-dependent nature of real-time applications adds a new difficult element to testing. Not only does the developer have to look at black and white box testing, but also the timing of the data and the parallelism of the tasks. In many situation test data for real-time system may produce errors when the system is in one state but to in others. Comprehensive test cases design methods for real-time systems have not evolved yet. However, a four-stage approach can be put forward:
Task testing: The first stage is to test independently the tasks of the real-time software.
Behavioral testing: Using system models produced with CASE tools the behavior of the real-time system and examine its actions as a result of external events.
Inter-task testing: Once errors in individual tasks and in system behaviour have been observed testing passes to time-related external events.
Systems testing: Software and hardware are integrated and a full set of systems tests are introduced to uncover errors at the software and hardware interface.
Related Topics
Guru’s Software Testing
Software Testing Tools – All free and Open-Source
Software Testing Techniques
Software Testing Techniques - II
Also Available
Server Virtualization – World’s Hottest Topic – A Good Research Work