MADE BY Darshan Singh Roll No. RD3801A32 downloaded from maintained by sudarshan kumar

White-box testing is a verification technique software engineers/System Analyst/Software Developer can use to examine if their code works as expected. White-box testing is testing that takes into account the internal mechanism of a system or component. White- box testing is also known as structural testing, clear box testing, and glass box testing. downloaded from maintained by sudarshan kumar

The test design process, at all levels, is at least as effective at catching bugs as is running the test case designed by that process. Each time we write a code module, we should write test cases for it based on the guidelines. A possible exception to this recommendation is the accessor methods (i.e., getters and setters) of the projects. We should concentrate our testing effort on code that could easily be broken. Generally, accessor methods will be written error-free. downloaded from maintained by sudarshan kumar

A Control Graph describes the sequence in which the different instructions of a program get executed. In other words, a Control Graph describes how the control flows through the program. In order to draw the Control Flow Graph of a program, all the statements must be numbered first. The different statements serves as nodes of the CFG. The CFG for any program can be easily drawn by knowing how to represent the sequence, selection, and iteration type of the statements (as program is made up of these type of statements). downloaded from maintained by sudarshan kumar

Based on the analysis of how control flows through a program Examples of test coverage criteria 1. Statement coverage (all nodes) 2. Branch coverage (all edges) 3. Path coverage (all paths) 4. Condition coverage downloaded from maintained by sudarshan kumar

Based on the analysis of how data flows through a program. Data-Flow based Testing method selects the paths of a program according to the locations of the definitions and uses of different variables in a program. In Control Flow Graph, a node represent a single statement, not a single-entry-single-exit chain of statements. I. Set DEF(n) contains variables that are defined at node n (i.e., they are written) II. Set USE(n) variables that are read downloaded from maintained by sudarshan kumar

Implementation as Control Flow Based Testing (Flow Graph of Purchasing Property) We can compute the number of independent paths through the code downloaded from maintained by sudarshan kumar

1 int foo (int a, int b, int c, int d, float e) { 2 float e; 3 if (a == 0) { 4 return 0; 5 } 6 int x = 0; 7 if ((a==b) OR ((c == d) AND bug(a) )) { 8 x=1; 9 } 10 e = 1/x; 11 return e; 12 } We consider various aspects of this flow graph in order to ensure that we have an adequate set of test cases. The adequacy of the test cases is often measured with a metric called coverage. Coverage is a measure of the completeness of the set of test cases. Good testing technique is to use the simplest set of input that could possibly test your situation – its better not to input values that cause complex, error-prone calculations when you are predetermining the values. downloaded from maintained by sudarshan kumar

Statement coverage is a measure of the percentage of statements that have been executed by test cases. Your objective should be to achieve 100% statement coverage through your testing. Identifying your cyclomatic number and executing this minimum set of test cases will make this statement coverage achievable. In Test Case 1, we executed the program statements on lines 1-5 out of 12 lines of code. As a result, we had 42% (5/12) statement coverage from Test Case 1. We can attain 100% statement coverage by one additional test case, Test Case 2: the method call foo(1, 1, 1, 1, 1.), expected return value of 1. With this method call, we have achieved 100% statement coverage because we have now executed the program statements on lines downloaded from maintained by sudarshan kumar

Branch coverage is a measure of the percentage of the decision points (Boolean expressions) of the program have been evaluated as both true and false in test cases. The small program in Figure 3 has two decision points – one on line 3 and the other on line 7. For decision/branch coverage, we evaluate an entire Boolean expression as one true-or-false predicate even if it contains multiple logical-and or logical-or operators – as in line 7. We need to ensure that each of these predicates (compound or single) is tested as both true and false. Table 1 shows our progress so far: 3 if (a == 0) { 7 if ((a==b) OR ((c == d) AND bug(a) )) { downloaded from maintained by sudarshan kumar

Condition coverage is a measure of percentage of Boolean sub-expressions of the program that have been evaluated as both true or false outcome in test cases. In line 7 there are three sub-Boolean expressions to the larger statement (a==b), (c==d), and bug(a). Condition coverage measures the outcome of each of these sub-expressions independently of each other. With condition coverage, you ensure that each of these sub expressions has independently been tested as both true and false. downloaded from maintained by sudarshan kumar

Test connections between variable definitions (write) and variable uses (read) Variation of the control flow graph A node represents a single statement, not a single-entry- single-exit chain of statements Set DEF(n) contains variables that are defined at node n (i.e., they are written) Set USE(n): variables that are read downloaded from maintained by sudarshan kumar

After the initial testing is complete, mutation testing is taken up. The Idea behid mutation testing is to make few arbitrary changes to a program at a time. Each time the program is changed, it is called as a mutated program and the change effected is called as a mutant. A mutated program is tested against the full test suite of the program. If there exists at least one test case in the test suite for which a mutant gives an incorrect result, then the mutant is said to be dead. If a mutant remains alive even after all the test cases have been exhausted \, the test data is enhanced to kill the mutant. The process of generation and killing of mutants can be automated by predefining a set of primitive changes that can be applied to the program. downloaded from maintained by sudarshan kumar

Properly planned with explicit input/output combinations, white-box testing is a controlled V&V technique. You run a test case, you know what lines of code you execute, and you know what the answer should be. If you dont get the right answer, the test case reveals a problem (a fault). Fortunately, you know which lines of code to look at based upon the test case that fails. Because of this control, removing defects in unit test is more economical than later phases in the development cycle. Later testing phases that involve block-box testing can be more chaotic. In those phases, a test case no longer reveals a problem (and an approximate location of where the problem needs to be fixed). Instead, a failed black-box test case reveals a symptom of a problem (a failure). It can be difficult, time consuming, and take an unpredictable amount of time to find the root cause of the symptom (the fault that caused the failure) so that the software engineer knows what to change in the code. downloaded from maintained by sudarshan kumar

Thanks downloaded from maintained by sudarshan kumar