Explore topic-wise InterviewSolutions in .

There are three levels in which WHITE box testing can be PRESENT:

1. UnitTesting
2. INTEGRETION Testing
3. REGRESSION testing

There are three levels in which white box testing can be present:

White box testing is NEEDED because of the following reasons:

• LOGICAL ERROR TEND to creep into our work when we design and implement functions, CONDITIONS or controls that are out of the program
• The design errors due to difference between logical flow of the program and the actual implementation
• Typographical errors and syntax checking

White box testing is needed because of the following reasons:

Data-flow testing looks at the lifecycle of a particular piece of data (i.e. a variable) in an application. By looking for patterns of data usage, risky areas of code can be found and more test cases can be APPLIED.

There are FOUR WAYS data can be USED: defined, used in a predicate, used in a calculation, and killed. Certain patterns, using a piece of data in a calculation after it has been killed, show an anomaly in the code, and therefore the POSSIBILITY of a bug.

Data-flow testing looks at the lifecycle of a particular piece of data (i.e. a variable) in an application. By looking for patterns of data usage, risky areas of code can be found and more test cases can be applied.

There are four ways data can be used: defined, used in a predicate, used in a calculation, and killed. Certain patterns, using a piece of data in a calculation after it has been killed, show an anomaly in the code, and therefore the possibility of a bug.

In general prerequisites for white box testing are the same as for black box testing. The only difference is the access to the APPLICATION SOURCE code. The white box TESTER should ask for detailed requirement, functional specifications, high-level design documents, detailed design documents and source code. The white box QA Engineer WOULD analyze the source code and prepare test CASES for testing the functionality to ensure that the code is behaving according with the requirements and specifications.

In general prerequisites for white box testing are the same as for black box testing. The only difference is the access to the application source code. The white box tester should ask for detailed requirement, functional specifications, high-level design documents, detailed design documents and source code. The white box QA Engineer would analyze the source code and prepare test cases for testing the functionality to ensure that the code is behaving according with the requirements and specifications.

It is not possible for testing each and every path of the loops in program. This MEANS exhaustive testing is IMPOSSIBLE for LARGE systems. This does not mean that white box testing is not effective. By selecting important logical PATHS and data structure for testing is practically possible and effective.

It is not possible for testing each and every path of the loops in program. This means exhaustive testing is impossible for large systems. This does not mean that white box testing is not effective. By selecting important logical paths and data structure for testing is practically possible and effective.

API testing is DONE to make sure that the basic UNITS of the software application function properly as desired. Reason why we perform API testing right from the initial stages of the product cycle to the final phase, ensuring that the product release in the market is error-free and worth every penny you invested. API testing process involves testing the methods of NET, JAVA, J2EE APIs for valid and invalid inputs, plus testing the APIs on Application servers.

API-testing targets the code-level, and can be done EVEN by TESTERS as WELL as developers.

API testing is done to make sure that the basic units of the software application function properly as desired. Reason why we perform API testing right from the initial stages of the product cycle to the final phase, ensuring that the product release in the market is error-free and worth every penny you invested. API testing process involves testing the methods of NET, JAVA, J2EE APIs for valid and invalid inputs, plus testing the APIs on Application servers.

API-testing targets the code-level, and can be done even by testers as well as developers.

A failure of a white box TESTING may result in a change that requires all BLACK box testing to be repeated and white box testing paths to be reviewed and possibly CHANGED.

A failure of a white box testing may result in a change that requires all black box testing to be repeated and white box testing paths to be reviewed and possibly changed.

Dirty test cases are those that check the functionalities for the negative scenarios. In dirty test cases we PROVIDE negative / invalid inputs and verify if the APPLICATION is behaving correctly. Here the application is tested for MAXIMUM amount of invalid inputs.

Example: For a banking application which ALLOWS fund transfer of maximum $10000 US per day. A dirty test case would be to try to transfer more than that values, i.e. say $10001 US. Here the application should sanely give an error that maximum allowed amount for transfer is $10000 US. It should not perform any transaction.

Dirty test cases are those that check the functionalities for the negative scenarios. In dirty test cases we provide negative / invalid inputs and verify if the application is behaving correctly. Here the application is tested for maximum amount of invalid inputs.

Example: For a banking application which allows fund transfer of maximum $10000 US per day. A dirty test case would be to try to transfer more than that values, i.e. say $10001 US. Here the application should sanely give an error that maximum allowed amount for transfer is $10000 US. It should not perform any transaction.

White box testing is a type of testing USED basically for checking the code of an APPLICATION, where as equivalence partitioning is a STRATEGY used for both white box and black box testing to decide the input values for the testing. In equivalence partitioning we will have to come up with multiple inputs in which each one represents a set of inputs of SIMILAR BEHAVIOR.

White box testing is a type of testing used basically for checking the code of an application, where as equivalence partitioning is a strategy used for both white box and black box testing to decide the input values for the testing. In equivalence partitioning we will have to come up with multiple inputs in which each one represents a set of inputs of similar behavior.

White box TESTING can be performed by anybody who has a good understanding of the code and the program logic. Generally developers PERFORM white box testing during unit testing for their own COMPONENTS. API TESTER also perform white box testing.

White box testing can be performed by anybody who has a good understanding of the code and the program logic. Generally developers perform white box testing during unit testing for their own components. API tester also perform white box testing.

ode coverage: Ensure that each code statement is executed once.

1. Branch Coverage or NODE Testing: Coverage of each code branch in from all possible was.
2. COMPOUND Condition Coverage: For multiple condition TEST each condition with multiple paths and COMBINATION of different path to reach that condition.
3. Basis Path Testing: Each independent path in the code is taken for testing.
4. Data Flow Testing: In this approach you track the specific variables through each possible calculation, thus defining the set of intermediate paths through the code. Data Flow Testing tends to reflect dependencies but it is mainly through sequences of data manipulation. In short each data variable is tracked and its use is verified. This approach tends to uncover bugs like variables used but not initialize, or declared but not used, and so on.
5. Path Testing: Path testing is where all possible paths through the code are defined and covered. Its a time consuming TASK.
6. Loop Testing: These strategies relate to testing single loops, concatenated loops, and nested loops. Independent and dependent code loops and values are tested by this approach.

ode coverage: Ensure that each code statement is executed once.

Let's say you have an entity that is stored across MULTIPLE tables and the test CASE is to delete the entity. In black-box testing, once the entity disappears from the GUI after deletion, your black-box test case is considered passed. But with white-box testing, you'd CHECK if all related rows are DELETED from the tables. If the deletion happens to delete only the parent record and leave behind orphan rows, the test case is considered failed.

Let's say you have an entity that is stored across multiple tables and the test case is to delete the entity. In black-box testing, once the entity disappears from the GUI after deletion, your black-box test case is considered passed. But with white-box testing, you'd check if all related rows are deleted from the tables. If the deletion happens to delete only the parent record and leave behind orphan rows, the test case is considered failed.

White Box testing is DONE by both developers and tester. In case of projects (eg: Railways , AERONAUTICS) there are standards (eg CENELAC)to be which demands testing to be done by a tester in such cases the white box testing is done by tester and not developer. The tester will have a knowledge of the coding LANGUAGE only then is he called a white box tester The tester does the white box testing USING rational tools LIKE Rational Test Real Time (RTRT) .

White Box testing is done by both developers and tester. In case of projects (eg: Railways , aeronautics) there are standards (eg CENELAC)to be which demands testing to be done by a tester in such cases the white box testing is done by tester and not developer. The tester will have a knowledge of the coding language only then is he called a white box tester The tester does the white box testing using rational tools like Rational Test Real Time (RTRT) .

Path coverage measures whether each of the POSSIBLE paths in each function have been covered for testing. A path is a unique sequence of branches from the function entry to the exit. A very through testing is possible by Path Coverage.

Path coverage is measures by an entity called CYCLOMATIC COMPLEXITY. The cyclomatic complexity of a software program is calculated from a connected GRAPH of the module (that SHOWS the topology of control flow within the program):

Cyclomatic complexity (CC) = E - N + P
where E = the number of edges of the graph
N = the number of nodes of the graph
P = the number of connected components

Path coverage measures whether each of the possible paths in each function have been covered for testing. A path is a unique sequence of branches from the function entry to the exit. A very through testing is possible by Path Coverage.

Path coverage is measures by an entity called cyclomatic complexity. The cyclomatic complexity of a software program is calculated from a connected graph of the module (that shows the topology of control flow within the program):

Cyclomatic complexity (CC) = E - N + P
where E = the number of edges of the graph
N = the number of nodes of the graph
P = the number of connected components

Everything is visible inside a glass box. When you PERFORM WHITE box testing , you can see the code and test it. But in BLACK box testing the tester does not know what is HAPPENING inside the code when he is GIVING a particular input. He only sees the output, but does not get to know how that output has come. In white box testing the tester can know what exactly is happening inside the code and why a particular out put is coming for a particular input. That's why it is called Glass box testing.

Everything is visible inside a glass box. When you perform white box testing , you can see the code and test it. But in black box testing the tester does not know what is happening inside the code when he is giving a particular input. He only sees the output, but does not get to know how that output has come. In white box testing the tester can know what exactly is happening inside the code and why a particular out put is coming for a particular input. That's why it is called Glass box testing.

• Draw the flowgraph corresponding to the PROCEDURAL design or code
• Determine the cyclomatic complexity of the flow graph.

1. V(G) = E-N+2
2. where, E=No. of edges, N=No. of NODES

• Determine the basis set of independent paths.(The cyclomatic complexity indicates the no. of paths REQUIRED.)
• Prepare TEST cases the will force EXECUTION of each path.

Cyclomatic complexity is the number of linearly independent paths through a program's SOURCE code. Cyclomatic complexity is computed using the control flow graph of the program: the nodes of the graph correspond to the commands of a program, and a directed edge connects two nodes if the SECOND command MIGHT be executed immediately after the first command.

CC = E − N + P

Where
CC= cyclomatic complexity
E = the number of edges of the graph
N = the number of nodes of the graph
P = the number of connected COMPONENTS.

Cyclomatic complexity is the number of linearly independent paths through a program's source code. Cyclomatic complexity is computed using the control flow graph of the program: the nodes of the graph correspond to the commands of a program, and a directed edge connects two nodes if the second command might be executed immediately after the first command.

CC = E − N + P

Where
CC= cyclomatic complexity
E = the number of edges of the graph
N = the number of nodes of the graph
P = the number of connected components.

Basic stuff REQUIRE for TEST cases is full FLEDGE knowledge of Functional design and STLC. Scenario plays a vital ROLE for having Test Cases.

Basic stuff require for Test cases is full fledge knowledge of Functional design and STLC. Scenario plays a vital role for having Test Cases.

Operations testing is designed to determine whether the system is executable during normal system operations. It evaluates both the process and the EXECUTION of the process. During DIFFERENT phases of SDLC, it can be used as follows

Phase 1: Requirements Phase: During this phase, operational requirements can be EVALUATED to determine the reasonableness and completeness of these requirements.

Phase 2: Design Phase: During this phase, the operating PROCEDURES should be designed and thus can be evaluated. 

Examples of Operations Testing

1. Verifying that the file labeling and protection procedures function PROPERLY. 
2. Determining that OS supports features, perform the predetermined tasks.

Operations testing is designed to determine whether the system is executable during normal system operations. It evaluates both the process and the execution of the process. During different phases of SDLC, it can be used as follows

Phase 1: Requirements Phase: During this phase, operational requirements can be evaluated to determine the reasonableness and completeness of these requirements.

Phase 2: Design Phase: During this phase, the operating procedures should be designed and thus can be evaluated. 

Examples of Operations Testing

TESTING a function with knowing the internal STRUCTURE it ALSO call as white box testing it takes PLACE in the developers AREA.

Testing a function with knowing the internal structure it also call as white box testing it takes place in the developers area.

Execution testing is used to determine whether the system can meet the specific performance criteria. It INCLUDES

1. Verifying the optimum use of hardware and software. 
2. Determining the response time to online USER requests. 
3. Determining transaction processing turnaround time. 

Execution testing can be done in any phase of SDLC. It can evaluate a single aspect of the system like a critical routine in the system. We can use hardware and software monitors or creating quick and dirty programs to evaluate the approximate performance of a completed system. This testing may be EXECUTED onsite or offsite for the performance of the test. It may be noted that the earlier the technique is used, the HIGHER is the assurance that the completed application will meet the performance criteria.

Execution testing is used to determine whether the system can meet the specific performance criteria. It includes

Execution testing can be done in any phase of SDLC. It can evaluate a single aspect of the system like a critical routine in the system. We can use hardware and software monitors or creating quick and dirty programs to evaluate the approximate performance of a completed system. This testing may be executed onsite or offsite for the performance of the test. It may be noted that the earlier the technique is used, the higher is the assurance that the completed application will meet the performance criteria.

Few major challenges faced during white box testing are as under:

1. Difficult for Software Developer to pinpoint the defects in his Own Creations: No one would like to point out errors from his own creations. So, does a developer. That is why a different test team is usually selected.
2. Even a completely tested code might not satisfy the REAL customer requirements: Usually the developers do not have a full appreciation and favor to external customer's requirements or the domain knowledge. This means that even after THOROUGH verification and validation, common user scenarios may GET left out. HENCE there REMAINS a great need to address all such scenarios.

Few major challenges faced during white box testing are as under:

Online systems should be stress tested by allowing people to ENTER transactions of a normal or above normal pace.

Batch systems can be stress tested with large input batches. Please note that the error conditions should be included in tested transactions. Transactions that are used in stress testing can be obtained from Test data generators, test transactions created by test GROUP or the transactions previously processed in the production environment.

In stress testing, the system should be run as it would in the production environment. Operators should use standard DOCUMENTATION and the people entering transactions or working with the system should be the clerical personnel that will use the system.

EXAMPLES of Stress Testing:

1. Enter transactions that determine that sufficient disk space has been allocated to the application. 
2. OVERLOADING the communication network with transactions.
3. Testing system overflow conditions by entering more transactions that can be accommodated by tables, queues and internal storage facilities etc.

Online systems should be stress tested by allowing people to enter transactions of a normal or above normal pace.

Batch systems can be stress tested with large input batches. Please note that the error conditions should be included in tested transactions. Transactions that are used in stress testing can be obtained from Test data generators, test transactions created by test group or the transactions previously processed in the production environment.

In stress testing, the system should be run as it would in the production environment. Operators should use standard documentation and the people entering transactions or working with the system should be the clerical personnel that will use the system.

Examples of Stress Testing:

The FOLLOWING are the KNOWLEDGE sources for white-box or structural TESTING 

1. High-level design. 
2. DETAILED design.
3. Control flow GRAPHS.

The following are the knowledge sources for white-box or structural testing 

If we decide to DEVELOP a program in terms of COMPATIBLE SLICES then we could code a slice and immediately test it. We can then code and test other slices and MERGE them into a fair solid program. This is known as slice SPLICING.

If we decide to develop a program in terms of compatible slices then we could code a slice and immediately test it. We can then code and test other slices and merge them into a fair solid program. This is known as slice splicing.

1. White box testing helps us to identify memory leaks. When we allocate memory using malloc( ) in C, we should explicitly RELEASE that memory also. If this is not done then over time, there would be no memory available for allocating memory on requests. This can be done using debuggers also that can tally allocated and freed memory. 
2. Performance analysis: Code coverage tests can identify the areas of a code that are EXECUTED most frequently. Extra efforts can be then made to check these sections of code. To do further performance improvement techniques like caching, co-processing or even parallel processing can be considered.
3. Coverage tests with instrumented code is one of the best means of identifying any violations of such concurrency constraints through critical sections.
4. White box testing is useful in identifying bottlenecks in resource usage. For example, it particular resource like RAM or ROM or even network is perceived as a bottleneck then instrumented code can help identify where the bottlenecks are and POINT TOWARDS possible solutions.
5. White box testing can help identify security holes in dynamically generated code. For exam in case of Java, some intermediate code may also be generated. Testing this intermediate code requires code knowledge. White box testing only does this.

A program slice is a set of program statements that contribute to or affect a value for a VARIABLE at some point in the program. This is an informal definition.

Let us see now more formal DEFINITIONS of a program slice.

"Given a program, P and a set of V of variables in P, a slice on the variable set V at statement n, written as S(V, n), is the set of all statements in P that contribute to the values of variables in V".

It may be noted that listing elements in a slice S(V, n) will be cumbersome because the elements are the program statement fragments.

We can further refine the definition of a program slice.

"Given a program P and a program graph G(P) in which statements and statement fragments are numbered and a set V of variables in P, the slice on the variable set V at statement fragment n, written as S(V, n), is the set of node numbers of all statement fragments in P prior to n that contribute to the values of variables in V at statement fragment n."

The basic idea is to SEPARATE a program into components (slices) that have some useful / functional meaning.

It may be noted that we have used the words "prior to" (in the 2nd definition) in the dynamic SENSE. Thus a slice, captures the execution time behavior of a program with respect to the variables in the slice. This develops a lattice or a directed, acyclic graph of slices in which nodes are slices and edges correspond to the subset RELATIONSHIP.

We have also used a word -"contribute' which means that data declaration statements have an effect on the value of a variable. We simply exclude all non-executable statements. 

A program slice is a set of program statements that contribute to or affect a value for a variable at some point in the program. This is an informal definition.

Let us see now more formal definitions of a program slice.

"Given a program, P and a set of V of variables in P, a slice on the variable set V at statement n, written as S(V, n), is the set of all statements in P that contribute to the values of variables in V".

It may be noted that listing elements in a slice S(V, n) will be cumbersome because the elements are the program statement fragments.

We can further refine the definition of a program slice.

"Given a program P and a program graph G(P) in which statements and statement fragments are numbered and a set V of variables in P, the slice on the variable set V at statement fragment n, written as S(V, n), is the set of node numbers of all statement fragments in P prior to n that contribute to the values of variables in V at statement fragment n."

The basic idea is to separate a program into components (slices) that have some useful / functional meaning.

It may be noted that we have used the words "prior to" (in the 2nd definition) in the dynamic sense. Thus a slice, captures the execution time behavior of a program with respect to the variables in the slice. This develops a lattice or a directed, acyclic graph of slices in which nodes are slices and edges correspond to the subset relationship.

We have also used a word -"contribute' which means that data declaration statements have an effect on the value of a variable. We simply exclude all non-executable statements. 

COVERAGE analyzers are a class of test tools that offer automated support for this approach to TESTING management. With this tool, the tester runs a set of test cases on a program that has been instrumented by the coverage analyzer. The analyzer then uses the information produced by the instrumentation code to generate a coverage report.

For EXAMPLE, in case of DD-path coverage, it identifies and labels all DD-paths in the original program. When the instrumented program is executed with test-cases, the analyzer tabulates the DD-paths traversed by each test case. So, a tester can experiment with different sets of test cases to determine the coverage of each set.

<font< p=""&GT;

Coverage analyzers are a class of test tools that offer automated support for this approach to testing management. With this tool, the tester runs a set of test cases on a program that has been instrumented by the coverage analyzer. The analyzer then uses the information produced by the instrumentation code to generate a coverage report.

For example, in case of DD-path coverage, it identifies and labels all DD-paths in the original program. When the instrumented program is executed with test-cases, the analyzer tabulates the DD-paths traversed by each test case. So, a tester can experiment with different sets of test cases to determine the coverage of each set.

<font< p="">