{"id":102,"date":"2018-07-21T09:02:55","date_gmt":"2018-07-21T09:02:55","guid":{"rendered":"http:\/\/csp9.epgpbooks.inflibnet.ac.in\/?post_type=chapter&p=102"},"modified":"2018-07-21T09:04:46","modified_gmt":"2018-07-21T09:04:46","slug":"white-box-testing","status":"publish","type":"chapter","link":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/chapter\/white-box-testing\/","title":{"rendered":"White Box Testing"},"content":{"raw":"
\r\n\r\nWHITE BOX TESTING<\/strong>\r\n\r\n \r\n

White box testing is a testing technique, that examines the program structure and derives test data from the program logic\/code. The other names of glass box testing are clear box testing,open box testing, logic driven testing or path driven testing or structural testing.White-box testing of software is predicated on close examination of procedural detail. Logical paths through the software are tested by providing test cases that exercise specific sets of conditions and\/or loops. The \"status of the program\" may be examined at various points to determine\u00a0 if\u00a0 the\u00a0 expected\u00a0 or\u00a0\u00a0 asserted\u00a0 status\u00a0 corresponds\u00a0 to\u00a0 the\u00a0 actual\u00a0 status. It\u00a0 inspects programmed behavior.<\/p>\r\n \r\n\r\nWhite box testing techniques<\/strong>\r\n\r\n \r\n\r\nStatement coverage,\u00a0\u00a0 Branch coverage,\u00a0\u00a0 Path coverage,\u00a0\u00a0 Condition coverage\u00a0 and Mutation testing\r\n\r\n \r\n\r\nSTATEMENT COVERAGE<\/strong>\r\n\r\n \r\n

Statement coverage is a white box test design technique which involves execution of all the executable statements in the source code at least once. It is used to calculate and measure the number of statements in the source code which can be executed given the requirements.<\/p>\r\n

Using this technique we can check what the source code is expected to do and what it should not.It can also be used to check the quality of the code and the flow of different paths in the program.The main drawback of this technique is that we cannot test the false condition in it.<\/p>\r\n

(Statement coverage = No of statements Executed\/Total no of statements in the source code * 100)<\/p>\r\n\r\n<\/div>\r\n

\r\n\r\nStatement Coverage Criterion<\/strong>\r\n\r\n \r\n\r\n-\u00a0 \u00a0Observing that a statement behaves properly for one input value\r\n\r\n \r\n\r\n-\u00a0 \u00a0 No guarantee that it will behave correctly for all input values\r\n\r\n \r\n\r\nExample 1:<\/strong>\r\n\r\n \r\n\r\nRead A\r\n\r\n \r\n\r\nRead B\r\n\r\n \r\n\r\nif A>B\r\n\r\n \r\n\r\nPrint \u201cA is greater than B\u201d\r\n\r\n \r\n\r\nelse\r\n\r\n \r\n\r\nPrint \"B is greater than A\"\r\n\r\n \r\n\r\nendif\r\n\r\n \r\n\r\nSet1 :If A =5, B =2\r\n\r\n \r\n\r\nNo of statements Executed: 5\r\n\r\n \r\n\r\nTotal no of statements in the source code: 7\r\n\r\n \r\n\r\nStatement coverage =5\/7*100 = 71.00 %\r\n\r\n \r\n\r\nSet1 :If A =2, B =5\r\n\r\n \r\n\r\nNo of statements Executed: 6\r\n\r\n \r\n\r\nTotal no of statements in the source code: 7\r\n\r\n \r\n\r\nStatement coverage =6\/7*100 = 85.20 %\r\n\r\n \r\n

This is purely a white box testing method. It tests the software\u2019s internal coding and infrastructure and so the programmer is the one who should take the initiative to do this. This technique is very suitable for drupal programmers and other programmers.<\/p>\r\n \r\n\r\n \r\n\r\nExample 2: Euclid\u2019s GCD Algorithm<\/strong>\r\n\r\n \r\n\r\nint f1(int x, int y){\r\n\r\n \r\n\r\nwhile (x != y){\r\n\r\n \r\n\r\nif (x>y) then\r\n\r\n \r\n\r\nx=x-y;\r\n\r\n \r\n\r\nelse y=y-x;\r\n\r\n}<\/span>\r\n\r\n<\/div>\r\n

\r\n\r\n \r\n\r\nreturn x;\r\n\r\n}\r\n\r\n<\/div>\r\nBy choosing the test set {(x=3,y=3),(x=4,y=3), (x=3,y=4)} all statements are executed at least once.\r\n\r\n \r\n\r\nBranch Coverage<\/strong>\r\n\r\n \r\n

In the branch coverage-based testing strategy, test cases are designed to make each branch condition to assume true and false values in turn. Branch testing is also known as edge testing as in this testing scheme, each edge of a program\u2019s control flow graph is traversed at least once. It is obvious that branch testing guarantees statement coverage and thus is a stronger testing strategy compared to the statement coverage-based testing.<\/p>\r\n \r\n\r\n \r\n\r\nTest cases are designed such that:<\/strong>\r\n\r\n \r\n\r\n- Different branch conditions is given true and false values in turn.\r\n\r\n \r\n\r\nBranch testing guarantees statement coverage:<\/strong>\r\n\r\n \r\n\r\n- a stronger testing compared to the statement coverage-based testing.\r\n\r\n \r\n\r\nExample: <\/strong>For Euclid\u2019s GCD computation algorithm\r\n\r\n \r\n\r\nTest cases for branch coverage can be:\r\n\r\n \r\n\r\n{(x=3,y=3), (x=4,y=3), (x=3,y=4)}\r\n\r\n \r\n\r\n \r\n\r\nCONDITION COVERAGE<\/strong>\r\n\r\n \r\n

In this structural testing, test cases are designed to make each component of a composite conditional expression to assume both true and false values. For example, in the conditional expression ((c1.and.c2).or.c3), the components c1, c2 and c3 are each made to assume both true and false values. Branch testing is probably the simplest condition testing strategy where only the compound conditions appearing in the different branch statements are made to assume the true and false values. Thus, condition testing is a stronger testing strategy than branch testing and branch testing is stronger testing strategy than the statement coverage-based testing. For a composite conditional expression of n components, for condition coverage, 2\u207f test cases are required. Thus, for condition coverage, the number of test cases increases exponentially with the number of component conditions. Therefore, a condition coverage-based testing technique is practical only if n (the number of conditions) is small.<\/p>\r\n \r\n

\r\n\r\nPATH COVERAGE<\/strong>\r\n\r\n<\/div>\r\n

The path coverage-based testing strategy requires us to design test cases such that all linearly independent paths in the program are executed at least once. A linearly independent path can be defined in terms of the control flow graph (CFG) of a program.<\/p>\r\n \r\n\r\nControl Flow Graph (CFG)<\/strong>\r\n\r\n \r\n

A control flow graph describes the sequence in which the different instructions of a program get executed. In other words, a control flow graph describes how the control flows through the program. In order to draw the control flow graph of a program, all the statements of a program must be numbered first. The different numbered statements serve as nodes of the control flow graph. An edge from one node to another node exists if the execution of the statement representing the first node can result in the transfer of control to the other node. The CFG for any program can be easily drawn by knowing how to represent the sequence, selection, and iteration type of statements in the CFG. After all, a program is made up from these types of statements.<\/p>\r\n \r\n

\r\n\r\nHow To Draw Control Flow Graph?<\/strong>\r\n\r\n \r\n\r\nNumber all the statements of a program.<\/strong>\r\n\r\n \r\n\r\nNumbered statements:<\/strong>\r\n\r\n \r\n\r\n-\u00a0 Represent nodes of the control flow graph.\r\n\r\n \r\n\r\nAn edge from one node to another node exists:<\/strong>\r\n\r\n \r\n\r\n-\u00a0 If execution of the statement representing the first node can result in transfer of control to the other node.\r\n\r\n \r\n\r\nExample<\/strong>\r\n\r\n \r\n\r\nint f1(int x,int y){\r\n\r\n \r\n\r\nwhile (x != y){\r\n\r\n \r\n\r\nif (x>y) then\r\n\r\n \r\n\r\nx=x-y;\r\n\r\n \r\n\r\nelse y=y-x;\r\n\r\n<\/div>\r\n}<\/span>\r\n
\r\n\r\nreturn x;\r\n\r\n}\r\n\r\n<\/div>\r\nExample CFG<\/strong>\r\n\r\n\"\"\r\n\r\n \r\n
\r\n

A path through a program is a node and edge sequence from the starting node to a terminal node of the control flow graph of a program. There can be more than one terminal node in a program. Writing test cases to cover all the paths of a typical program is impractical. For this reason, the path-coverage testing does not require coverage of all paths but only coverage of linearly independent paths.<\/p>\r\n \r\n\r\nIndependent Path<\/strong>\r\n\r\n \r\n

A linearly independent path is any path through the program that introduces at least one new edge that is not included in any other linearly independent paths. If a path has one new node compared to all other linearly independent paths, then the path is also linearly independent. This is because, any path having a new node automatically implies that it has a new edge. Thus, a path that is sub path of another path is not considered to be a linearly independent path.<\/p>\r\n \r\n\r\nMcCabe's Cyclomatic Metric<\/strong>\r\n\r\n \r\n

For more complicated programs it is not easy to determine the number of independent paths of the program. McCabe\u2019s cyclomatic complexity defines an upper bound for the number of linearly independent paths through a program. Also, the McCabe\u2019s cyclomatic complexity is very simple to compute. Thus, the McCabe\u2019s cyclomatic complexity metric provides a practical way of determining the maximum number of linearly independent paths in a program. Though the McCabe\u2019s metric does not directly identify the linearly independent paths, but it informs\u00a0approximately how many paths to look for. There are two different ways to compute the cyclomatic complexity. The answers computed by the three methods are guaranteed to agree.<\/span><\/p>\r\n\r\n<\/div>\r\n\u00a0 \u00a0 Method 1:<\/strong>\r\n\r\n \r\n

Given a control flow graph G of a program, the cyclomatic complexity V(G) can be computed as: V(G) = E \u2013 N + 2 where N is the number of nodes of the control flow graph and E is the number of edges in the control flow graph.<\/p>\r\n \r\n

For the CFG of example shown in fig.1, E=7 and N=6. Therefore, the cyclomatic complexity = 7-6+2 = 3.<\/p>\r\n \r\n

Method 2:<\/strong><\/p>\r\n \r\n

An alternative way of computing the cyclomatic complexity of a program from an inspection of its control flow graph is as follows: V(G) = Total number of bounded areas + 1 In the program\u2019s control flow graph G, any region enclosed by nodes and edges can be called as a bounded area. This is an easy way to determine the McCabe\u2019s cyclomatic complexity. But, what if the graph G is not planar, i.e. however you draw the graph, two or more edges intersect? Actually, it can be shown that structured programs always yield planar graphs. But, presence of GOTO\u2019s can easily add intersecting edges. Therefore, for non-structured programs, this way of computing the McCabe\u2019s cyclomatic complexity cannot be used. The number of bounded areas increases with the number of decision paths and loops. Therefore, the McCabe\u2019s metric provides a quantitative measure of testing difficulty and the ultimate reliability.<\/p>\r\n \r\n

For the CFG example shown in fig.1, from a visual examination of the CFG the number of bounded areas is 2. Therefore the cyclomatic complexity, computing with this method is also 2+1 = 3. This method provides a very easy way of computing the cyclomatic complexity of CFGs, just from a visual examination of the CFG. On the other hand, the other method of computing CFGs is more amenable to automation, i.e. it can be easily coded into a program which can be used to determine the cyclomatic complexities of arbitrary CFGs.<\/p>\r\n\r\n

\r\n\r\nAn upper bound:<\/strong>\r\n\r\n \r\n\r\n-\u00a0 \u00a0For the number of linearly independent paths of a program\r\n\r\n \r\n\r\nProvides a practical way of determining:<\/strong>\r\n\r\n \r\n

-\u00a0 The maximum number of linearly independent paths in a program. In this example the cyclomatic complexity value is 3. Therefore, 3 test cases are sufficient to test this program.<\/p>\r\n\r\n<\/div>\r\n \r\n\r\nMUTATION TESTING<\/strong>\r\n\r\n \r\n

In mutation testing, the software is first tested by using an initial test suite built up from the different white box testing strategies. After the initial testing is complete, mutation testing is taken up. The idea behind 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. These primitive changes can be alterations such as changing an arithmetic operator, changing the value of a constant, changing a data type, etc. A major disadvantage of the mutation-based testing approach is that it is computationally very expensive, since a large number of possible mutants can be generated. Since mutation testing generates a large number of mutants and requires us to check each mutant with the full test suite, it is not suitable for manual testing. Mutation testing should be used in conjunction of some testing tool which would run all the test cases automatically.<\/p>\r\n \r\n\r\nCONCLUSION<\/strong>\r\n

    \r\n \t
  • \u00a0White Box Testing is performed to detect errors with respect to execution of complete program.<\/li>\r\n \t
  • \u00a0Statement coverage and condition coverage are useful to test all lines of the program.<\/li>\r\n \t
  • Path coverage tests all possible paths in the program execution.<\/li>\r\n \t
  • Cyclomatic Complexity is useful for finding the paths.<\/li>\r\n<\/ul>\r\n\"\"","rendered":"
    \n

    WHITE BOX TESTING<\/strong><\/p>\n

     <\/p>\n

    White box testing is a testing technique, that examines the program structure and derives test data from the program logic\/code. The other names of glass box testing are clear box testing,open box testing, logic driven testing or path driven testing or structural testing.White-box testing of software is predicated on close examination of procedural detail. Logical paths through the software are tested by providing test cases that exercise specific sets of conditions and\/or loops. The “status of the program” may be examined at various points to determine\u00a0 if\u00a0 the\u00a0 expected\u00a0 or\u00a0\u00a0 asserted\u00a0 status\u00a0 corresponds\u00a0 to\u00a0 the\u00a0 actual\u00a0 status. It\u00a0 inspects programmed behavior.<\/p>\n

     <\/p>\n

    White box testing techniques<\/strong><\/p>\n

     <\/p>\n

    Statement coverage,\u00a0\u00a0 Branch coverage,\u00a0\u00a0 Path coverage,\u00a0\u00a0 Condition coverage\u00a0 and Mutation testing<\/p>\n

     <\/p>\n

    STATEMENT COVERAGE<\/strong><\/p>\n

     <\/p>\n

    Statement coverage is a white box test design technique which involves execution of all the executable statements in the source code at least once. It is used to calculate and measure the number of statements in the source code which can be executed given the requirements.<\/p>\n

    Using this technique we can check what the source code is expected to do and what it should not.It can also be used to check the quality of the code and the flow of different paths in the program.The main drawback of this technique is that we cannot test the false condition in it.<\/p>\n

    (Statement coverage = No of statements Executed\/Total no of statements in the source code * 100)<\/p>\n<\/div>\n

    \n

    Statement Coverage Criterion<\/strong><\/p>\n

     <\/p>\n

    –\u00a0 \u00a0Observing that a statement behaves properly for one input value<\/p>\n

     <\/p>\n

    –\u00a0 \u00a0 No guarantee that it will behave correctly for all input values<\/p>\n

     <\/p>\n

    Example 1:<\/strong><\/p>\n

     <\/p>\n

    Read A<\/p>\n

     <\/p>\n

    Read B<\/p>\n

     <\/p>\n

    if A>B<\/p>\n

     <\/p>\n

    Print \u201cA is greater than B\u201d<\/p>\n

     <\/p>\n

    else<\/p>\n

     <\/p>\n

    Print “B is greater than A”<\/p>\n

     <\/p>\n

    endif<\/p>\n

     <\/p>\n

    Set1 :If A =5, B =2<\/p>\n

     <\/p>\n

    No of statements Executed: 5<\/p>\n

     <\/p>\n

    Total no of statements in the source code: 7<\/p>\n

     <\/p>\n

    Statement coverage =5\/7*100 = 71.00 %<\/p>\n

     <\/p>\n

    Set1 :If A =2, B =5<\/p>\n

     <\/p>\n

    No of statements Executed: 6<\/p>\n

     <\/p>\n

    Total no of statements in the source code: 7<\/p>\n

     <\/p>\n

    Statement coverage =6\/7*100 = 85.20 %<\/p>\n

     <\/p>\n

    This is purely a white box testing method. It tests the software\u2019s internal coding and infrastructure and so the programmer is the one who should take the initiative to do this. This technique is very suitable for drupal programmers and other programmers.<\/p>\n

     <\/p>\n

     <\/p>\n

    Example 2: Euclid\u2019s GCD Algorithm<\/strong><\/p>\n

     <\/p>\n

    int f1(int x, int y){<\/p>\n

     <\/p>\n

    while (x != y){<\/p>\n

     <\/p>\n

    if (x>y) then<\/p>\n

     <\/p>\n

    x=x-y;<\/p>\n

     <\/p>\n

    else y=y-x;<\/p>\n

    }<\/span><\/p>\n<\/div>\n

    \n

     <\/p>\n

    return x;<\/p>\n

    }<\/p>\n<\/div>\n

    By choosing the test set {(x=3,y=3),(x=4,y=3), (x=3,y=4)} all statements are executed at least once.<\/p>\n

     <\/p>\n

    Branch Coverage<\/strong><\/p>\n

     <\/p>\n

    In the branch coverage-based testing strategy, test cases are designed to make each branch condition to assume true and false values in turn. Branch testing is also known as edge testing as in this testing scheme, each edge of a program\u2019s control flow graph is traversed at least once. It is obvious that branch testing guarantees statement coverage and thus is a stronger testing strategy compared to the statement coverage-based testing.<\/p>\n

     <\/p>\n

     <\/p>\n

    Test cases are designed such that:<\/strong><\/p>\n

     <\/p>\n

    – Different branch conditions is given true and false values in turn.<\/p>\n

     <\/p>\n

    Branch testing guarantees statement coverage:<\/strong><\/p>\n

     <\/p>\n

    – a stronger testing compared to the statement coverage-based testing.<\/p>\n

     <\/p>\n

    Example: <\/strong>For Euclid\u2019s GCD computation algorithm<\/p>\n

     <\/p>\n

    Test cases for branch coverage can be:<\/p>\n

     <\/p>\n

    {(x=3,y=3), (x=4,y=3), (x=3,y=4)}<\/p>\n

     <\/p>\n

     <\/p>\n

    CONDITION COVERAGE<\/strong><\/p>\n

     <\/p>\n

    In this structural testing, test cases are designed to make each component of a composite conditional expression to assume both true and false values. For example, in the conditional expression ((c1.and.c2).or.c3), the components c1, c2 and c3 are each made to assume both true and false values. Branch testing is probably the simplest condition testing strategy where only the compound conditions appearing in the different branch statements are made to assume the true and false values. Thus, condition testing is a stronger testing strategy than branch testing and branch testing is stronger testing strategy than the statement coverage-based testing. For a composite conditional expression of n components, for condition coverage, 2\u207f test cases are required. Thus, for condition coverage, the number of test cases increases exponentially with the number of component conditions. Therefore, a condition coverage-based testing technique is practical only if n (the number of conditions) is small.<\/p>\n

     <\/p>\n

    \n

    PATH COVERAGE<\/strong><\/p>\n<\/div>\n

    The path coverage-based testing strategy requires us to design test cases such that all linearly independent paths in the program are executed at least once. A linearly independent path can be defined in terms of the control flow graph (CFG) of a program.<\/p>\n

     <\/p>\n

    Control Flow Graph (CFG)<\/strong><\/p>\n

     <\/p>\n

    A control flow graph describes the sequence in which the different instructions of a program get executed. In other words, a control flow graph describes how the control flows through the program. In order to draw the control flow graph of a program, all the statements of a program must be numbered first. The different numbered statements serve as nodes of the control flow graph. An edge from one node to another node exists if the execution of the statement representing the first node can result in the transfer of control to the other node. The CFG for any program can be easily drawn by knowing how to represent the sequence, selection, and iteration type of statements in the CFG. After all, a program is made up from these types of statements.<\/p>\n

     <\/p>\n

    \n

    How To Draw Control Flow Graph?<\/strong><\/p>\n

     <\/p>\n

    Number all the statements of a program.<\/strong><\/p>\n

     <\/p>\n

    Numbered statements:<\/strong><\/p>\n

     <\/p>\n

    –\u00a0 Represent nodes of the control flow graph.<\/p>\n

     <\/p>\n

    An edge from one node to another node exists:<\/strong><\/p>\n

     <\/p>\n

    –\u00a0 If execution of the statement representing the first node can result in transfer of control to the other node.<\/p>\n

     <\/p>\n

    Example<\/strong><\/p>\n

     <\/p>\n

    int f1(int x,int y){<\/p>\n

     <\/p>\n

    while (x != y){<\/p>\n

     <\/p>\n

    if (x>y) then<\/p>\n

     <\/p>\n

    x=x-y;<\/p>\n

     <\/p>\n

    else y=y-x;<\/p>\n<\/div>\n

    }<\/span><\/p>\n

    \n

    return x;<\/p>\n

    }<\/p>\n<\/div>\n

    Example CFG<\/strong><\/p>\n

    \"\"<\/p>\n

     <\/p>\n

    \n

    A path through a program is a node and edge sequence from the starting node to a terminal node of the control flow graph of a program. There can be more than one terminal node in a program. Writing test cases to cover all the paths of a typical program is impractical. For this reason, the path-coverage testing does not require coverage of all paths but only coverage of linearly independent paths.<\/p>\n

     <\/p>\n

    Independent Path<\/strong><\/p>\n

     <\/p>\n

    A linearly independent path is any path through the program that introduces at least one new edge that is not included in any other linearly independent paths. If a path has one new node compared to all other linearly independent paths, then the path is also linearly independent. This is because, any path having a new node automatically implies that it has a new edge. Thus, a path that is sub path of another path is not considered to be a linearly independent path.<\/p>\n

     <\/p>\n

    McCabe’s Cyclomatic Metric<\/strong><\/p>\n

     <\/p>\n

    For more complicated programs it is not easy to determine the number of independent paths of the program. McCabe\u2019s cyclomatic complexity defines an upper bound for the number of linearly independent paths through a program. Also, the McCabe\u2019s cyclomatic complexity is very simple to compute. Thus, the McCabe\u2019s cyclomatic complexity metric provides a practical way of determining the maximum number of linearly independent paths in a program. Though the McCabe\u2019s metric does not directly identify the linearly independent paths, but it informs\u00a0approximately how many paths to look for. There are two different ways to compute the cyclomatic complexity. The answers computed by the three methods are guaranteed to agree.<\/span><\/p>\n<\/div>\n

    \u00a0 \u00a0 Method 1:<\/strong><\/p>\n

     <\/p>\n

    Given a control flow graph G of a program, the cyclomatic complexity V(G) can be computed as: V(G) = E \u2013 N + 2 where N is the number of nodes of the control flow graph and E is the number of edges in the control flow graph.<\/p>\n

     <\/p>\n

    For the CFG of example shown in fig.1, E=7 and N=6. Therefore, the cyclomatic complexity = 7-6+2 = 3.<\/p>\n

     <\/p>\n

    Method 2:<\/strong><\/p>\n

     <\/p>\n

    An alternative way of computing the cyclomatic complexity of a program from an inspection of its control flow graph is as follows: V(G) = Total number of bounded areas + 1 In the program\u2019s control flow graph G, any region enclosed by nodes and edges can be called as a bounded area. This is an easy way to determine the McCabe\u2019s cyclomatic complexity. But, what if the graph G is not planar, i.e. however you draw the graph, two or more edges intersect? Actually, it can be shown that structured programs always yield planar graphs. But, presence of GOTO\u2019s can easily add intersecting edges. Therefore, for non-structured programs, this way of computing the McCabe\u2019s cyclomatic complexity cannot be used. The number of bounded areas increases with the number of decision paths and loops. Therefore, the McCabe\u2019s metric provides a quantitative measure of testing difficulty and the ultimate reliability.<\/p>\n

     <\/p>\n

    For the CFG example shown in fig.1, from a visual examination of the CFG the number of bounded areas is 2. Therefore the cyclomatic complexity, computing with this method is also 2+1 = 3. This method provides a very easy way of computing the cyclomatic complexity of CFGs, just from a visual examination of the CFG. On the other hand, the other method of computing CFGs is more amenable to automation, i.e. it can be easily coded into a program which can be used to determine the cyclomatic complexities of arbitrary CFGs.<\/p>\n

    \n

    An upper bound:<\/strong><\/p>\n

     <\/p>\n

    –\u00a0 \u00a0For the number of linearly independent paths of a program<\/p>\n

     <\/p>\n

    Provides a practical way of determining:<\/strong><\/p>\n

     <\/p>\n

    –\u00a0 The maximum number of linearly independent paths in a program. In this example the cyclomatic complexity value is 3. Therefore, 3 test cases are sufficient to test this program.<\/p>\n<\/div>\n

     <\/p>\n

    MUTATION TESTING<\/strong><\/p>\n

     <\/p>\n

    In mutation testing, the software is first tested by using an initial test suite built up from the different white box testing strategies. After the initial testing is complete, mutation testing is taken up. The idea behind 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. These primitive changes can be alterations such as changing an arithmetic operator, changing the value of a constant, changing a data type, etc. A major disadvantage of the mutation-based testing approach is that it is computationally very expensive, since a large number of possible mutants can be generated. Since mutation testing generates a large number of mutants and requires us to check each mutant with the full test suite, it is not suitable for manual testing. Mutation testing should be used in conjunction of some testing tool which would run all the test cases automatically.<\/p>\n

     <\/p>\n

    CONCLUSION<\/strong><\/p>\n

      \n
    • \u00a0White Box Testing is performed to detect errors with respect to execution of complete program.<\/li>\n
    • \u00a0Statement coverage and condition coverage are useful to test all lines of the program.<\/li>\n
    • Path coverage tests all possible paths in the program execution.<\/li>\n
    • Cyclomatic Complexity is useful for finding the paths.<\/li>\n<\/ul>\n

      \"\"<\/p>\n","protected":false},"author":4,"menu_order":9,"template":"","meta":{"pb_show_title":"on","pb_short_title":"","pb_subtitle":"","pb_authors":[],"pb_section_license":""},"chapter-type":[],"contributor":[],"license":[],"class_list":["post-102","chapter","type-chapter","status-publish","hentry"],"part":3,"_links":{"self":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/pressbooks\/v2\/chapters\/102","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/wp\/v2\/users\/4"}],"version-history":[{"count":3,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/pressbooks\/v2\/chapters\/102\/revisions"}],"predecessor-version":[{"id":107,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/pressbooks\/v2\/chapters\/102\/revisions\/107"}],"part":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/pressbooks\/v2\/parts\/3"}],"metadata":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/pressbooks\/v2\/chapters\/102\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/wp\/v2\/media?parent=102"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/pressbooks\/v2\/chapter-type?post=102"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/wp\/v2\/contributor?post=102"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp9\/wp-json\/wp\/v2\/license?post=102"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}