Black-Box vs White-Box Testing

Black-box testing tests the software without looking at the code, using only the specification (inputs and expected outputs).
White-box testing tests the internal structure and logic of the code.

Comparison

Basis	Black-box testing	White-box testing
Information used for test-case design	Requirements/specification, input and output domains	Source code, control-flow and data-flow structure
Knowledge of code needed	No	Yes
Typical techniques	Equivalence class partitioning, boundary value analysis, decision table testing, cause-effect graphing, state-transition testing	Statement coverage, branch/decision coverage, condition coverage, path testing (basis paths), data-flow testing, mutation testing
Defect types detected	Missing or incorrect functions, interface errors, wrong output, input/output (boundary) errors, incorrect specification handling	Logical errors, unreachable or dead code, wrong conditions, loop errors, incorrect data usage, uncovered paths
Performed by	Testers / independent test team	Developers
Test level	Mostly system and acceptance	Mostly unit and integration
Limitations	Cannot find hidden code paths or dead code	Cannot find missing functionality

Conclusion

The two are complementary. Black-box testing checks that the software does what the customer asked for; white-box testing checks that the code is built correctly. A good test strategy uses both (grey-box testing combines them).