Mapping White Box issues to Black Box entry point using Runtime Analysis

Mapping White Box issues to Black Box entry point using Runtime Analysis

The testing technique disclosed in the following article allows application testing to bridge the gap between tests performed on the external portions of an application, or Black Box Testing, and tests performed on the source code of the application, or White Box Testing. This is done by the use of Runtime Analysis, the analysis of code being executed in a runtime environment. This novel concept allows for much easier fixing of problems, combined with accurate detection techniques.

At present there exist two dominant testing techniques, Black Box Testing and White Box Testing. Each method has its own strengths and weaknesses.

Black Box testing tools invoke an application from the outside. These tools are referred to as "Black-Box" testing tools since they look at the application as a black box with a set of defined and declared interfaces, with no knowledge of how it is structured internally. Black box testing tools perform their tests by invoking interfaces in different ways and with different inputs, and then use the information exposed through these interfaces to determine if the application has a

p

 roblem. For example, a web application testing tool would interact with the application through its defined HTTP interfaces, submit different HTTP requests to it and analyze the returned HTTP responses to determine if an issue exists (e.g. a security issue implied by a returned exception, a

p

 erformance issue implied by a delayed response, a functional issue implied by a response that does not match explicitly set criteria). The mentioned interfaces can be network protocols such as TCP or HTTP,

p

           rogrammable interfaces such as APIs and SDKs, input files processed by the application, and many others - but all defined interfaces and all not requiring insight into the code and internals of the application.

Because Black Box testing performs tests from an end user's perspective, the problems it finds are very likely to be real issues that need to be fixed because they can be reproduced by anyone with access to the application's interfaces. This makes them easier to prioritize and easier to see immediate return on investment from fixing them.

However, there are some problems with Black Box testing. For one, it cannot test all existing

p

 arts of the application due to being unable to access underlying code. Without knowing the underlying structure it is difficult to design test cases unique to that application, which may mean bugs slipping through the testing process. Another challenge is that the results it provides may be hard to fix because there is not enough information about what is going wrong inside the application. In large applications simply finding the code that is causing a problem to occur on the interface, and then finding the best place to fix the problem can be a trial.

On the other hand, White Box testing too...