This is part 3 of the testing-series of posts where I cover White-Box testing (inspired by Microsoft’s upcoming Testing Series of good advise from PAG). You can check out the earlier post <strong>here</strong> .

White-Box testing (Glass Box/Clear Box/Open Box testing)

White box testing assumes that the tester can take a look at the code for the application and create test cases which look for any potential failure scenarios. You need to determine the suitable input data for testing of various APIs and the special code paths that need testeing by analyzing the source code for the application. One needs to ensure that the test plans need to be updated before starting with White–Box testing.

A failure of a white box test may result in a change which requires all the <strong>black box testing</strong> to be repeated and re-determination of white-box paths.

  • Profile The Application Code Blocks. Profiling is the activity which allows you to monitor the behavior of a particular code path in run time when the code is actually in execution. Typically you would profile your code for one or more of the following:

    • Code Coverage. Profiling for code coverage with the help of a tool ensures that there is no redundant or dead code which never gets called for any execution path.

    • Memory allocation pattern. This helps you in studying direct and indirect memory allocations while executing a code path, detect and analyze memory leaks (for unmanaged code), etc. For example you can analyze in which GC generations (Gen 0, Gen 1, Gen2) the maximum objects reside or are there any side affect allocations taking place in a loop which are increasing the memory utilization significantly. This can help you optimize the memory utilization of the code block. You can use various tools such as CLR profiler, Intel Vtune, etc. for this purpose.

    • Contention and deadlock issues. You can analyze the code for deadlocks using tools like WinDbg which are a part of the Windows debugging toolkit.

    • Time taken for executing a code path. You can profile the time taken by the scenarios for which performance is critical. This may require custom instrumentation of the code path which may be distributed across physically different machines. There are also various third party tools available which help you measure the time taken for execution of a particular scenario.

      If the code needs to be integrated with web application one should also check out the Request Execution Time (ASP.NET\Request Execution Time) perf. counter. You can create a test harnesses such that the overhead of the harness is minimal and most of the processing time is spend within the code.

If during profiling you find that a particular condition needs to be tested under load such as potential deadlock issues or inefficient memory cleanup which is visible only under scenarios you can provide inputs on the type of metrics which should be chosen while load testing the code and what are the things you should be looking for when stress testing the code.

  • Testing internal subroutines. You need to test the various internal functions to ensure that they are processing the right data without any loss or inconsistency and returning the expected output.
  • Test various loops and conditional statements. You should test various types of loops such as simple, concatenated, nested loops etc and the accuracy of conditional statements in the code components such as relational expressions, simple conditions, compound conditions, Boolean expressions, etc.
  • Testing various scenarios identified. Various potential scenarios should have been identified in earlier in the process of reviewing the implementation. You must test these scenarios by first analyzing the code and then submitting the inputs which tend to exploit the weakness in the code (if any).
  • Security Testing. During the process of source code review if you identify that a particular code access security is not able to restrict undesirable access in the targeted deployment environment you should test this scenario by first analyzing the code and then simulating the deployment environment to identify any scenarios where the code block may expose sensitive information to hackers.

More Information - check out http://tinyurl.com/32ye3