WHITE BOX TESTING
Testing of a function with knowing the internal structure of the organization or by checking the input and output relationships with regard to the structure or interior of the object
It is usually done by developers. the application is tested as code or module or component
It is mainly used for business functionality
It is also known as glass box testing or clear box testing or open box testing or structural testing or unit testing
Knowledge of internal coding is prerequisite
Easy to find out which type data helps testing the application effectively
Removes external line of code helps in bring hidden effects
Helps in optimizing the code
It refers to testing with detail knowledge of internal modules
These tools concentrate more on the algorithms, data structure used in the development of modules
These tools perform testing on individual modules
Knowledge require to do white box testing
Need to understand the internals of the module like data structures and algorithms and
Have access to the source code
Typical white box test design techniques include
Control flow testing
Data flow testing
BLACK BOX TESTING
Testing of a function with out knowing the internal structure of the program or by checking the input and output relation ships with out regard to the internal structure of the object it is also called system testing, closed box testing
This method dont use code to determine the test suite rather knowing the problem that we are trying to solve with three types data
Easy to commute data
Boundary or extreme data
Major testing focuses
Specifications based on
User oriented usage errors
Tester no needs knowledge of implementation, including specific programming language
Tests are done in user point of view
Test cases are designed as soon as specifications are completed
Only small number of possible inputs can actually be tested
With out clear and concise specifications, test cases are hard to design
There may be unnecessary repetition of test inputs if the tester is not informed
Refers to testing of interface, functionality
Performance testing of system module and the whole system
Knowledge require to do black box testing
Understanding /functionality of the application
Typical black box test design techniques include
Boundary value analysis
Decision table testing
State transition tables
Use case testing
Testing of combined parts of an application to determine if they function together correctly
Individual software modules are combined and tested as group
Two units that have already tested are combined into components and the interface between them is tested
Interface between modules
Integrated functional areas
Interacting protocols & messages
Developers and test team
What we need
Integration test strategy
Integration test environment and test suite
Interface design documents
Three types of integration testing
Top down testing
It is an approach to integration testing where component at the top of the component hierarchy is tested first, with lower level component being simulated by stubs.
Tested components are then used to test the lower level components.
The process repeats until the lowest level components have been tested.
Modules are integrated by moving downward through control hierarchy
Bottom up testing
It is an approach to integration testing where the lowest level components are tested first, then used to facilitate the testing of higher level components.
The process is repeated until the component at the top of the hierarchy is tested
Clusters are integrated by moving upwards in the program structure.
Requires testing along functional data and control flow paths
Main functionality is test
Ex:- wealth view banking
1) Low level modules are combined into clusters that perform a specific software stub function.
2) A driver is written to co-ordinate test case input and output.
3) Test cluster is tested.
4) Drivers are removed and clusters are combined moving upward in the program structure.
Retesting of an application after fixes or modifications of the software or its environment
Retesting of an application when ever a new build is added or deleted
Testing activities occur only after changes.
Usually refers to testing activities during software maintenance phase.
Automated testing tools can be especially used for this type
(No. of bugs in release found by re-executing state/No of bugs found by running all test.(for 1st or nth time)) * 100
- Software change analysis
.Understand & analyze various software changes.
- Software change impact analysis
. Understand & analyze various software change impacts.
- Define regression test strategy & criteria.
- Define, select, and reuse test cases to form a regression test suite.
- Perform regression at the different levels.
. @ Unit level.
. @ Integration level.
. @ Function level.
. @ System level.
- Report & analyze regression test results.
- Repeat testing after changes.
- But scratch the surface and you find three fundamentally different versions:
1) . Procedural: run the same tests again.
2) . Risk-oriented: expose errors caused by change.
3) . Refractory support: help programmer discover implications of her code