Gray box testing

A black-box tester is unaware of the internal structure of the application to be tested, while a white-box tester has access to the internal structure of the application. A gray-box tester partially knows the internal structure, which includes access to the documentation of internal data structures as well as the algorithms used.

Gray-box testers require both high-level and detailed documents describing the application, which they collect in order to define test cases.

Need for gray-box testing
Gray-box testing is beneficial because it takes the straightforward technique of black-box testing and combines it with the code-targeted systems in white-box testing.

Gray-box testing is based on requirement test case generation because it presents all the conditions before the program is tested by using the assertion method. A requirement specification language is used to make it easy to understand the requirements and verify its correctness.

Gray-box testing assumptions for object-oriented software
Object-oriented software consists primarily of objects; where objects are single indivisible units having executable code and/or data. Some assumptions are stated below which are needed for the application of use gray-box testing.

Activation of Methods
State Reporting in Class Under Test (CUT).
Report Testing is inherent in Class Under Test.
Examples
Architectural model
Unified Modeling Language - UML Design Model
Finite-state machine - State Model.
Techniques
Cem Kaner defines "gray-box testing as involving inputs and outputs, but test design is educated by information about the code or the program operation of a kind that would normally be out of view of the tester". Gray-box testing techniques are:

Matrix Testing: states the status report of the project.
Regression testing: it implies rerunning of the test cases if new changes are made.
Pattern Testing: verify the good application for its design or architecture and patterns.
Orthogonal array testing: used as subset of all possible combination.