{"id":279,"date":"2018-07-25T06:05:41","date_gmt":"2018-07-25T06:05:41","guid":{"rendered":"http:\/\/csp8.epgpbooks.inflibnet.ac.in\/?post_type=chapter&p=279"},"modified":"2018-08-08T05:52:00","modified_gmt":"2018-08-08T05:52:00","slug":"white-box-testing-ii","status":"publish","type":"chapter","link":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/chapter\/white-box-testing-ii\/","title":{"rendered":"White Box Testing II"},"content":{"raw":"
\r\n\r\n \r\n

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

White box is a testing methodology to test the internal structures and working of software. White box testing also know as structural testing is testing based on analysis of internal logic (design, code, etc.).<\/p>\r\n \r\n

LEARNING OBJECTIVES\u00a0<\/strong><\/p>\r\n \r\n

\u2022 To focus on Program structures, Program internal logic and data structures, Program internal behaviors and states.<\/p>\r\n

\u2022 To focus on internal program structure and discover all internal program errors.<\/p>\r\n \r\n

Example Paths\u00a0<\/strong><\/p>\r\n \r\n

The following example shows the flow graph and the paths through the nodes, the example shows that the paths P3 and P4 are the same but they have different start and endpoints.<\/p>\r\n\r\n<\/div>\r\n

\"\"<\/p>\r\n\r\n

\r\n\r\n \r\n\r\nIn the example, the paths that form cycles are identified, where P4, P8, P9 does not form\u00a0cycles<\/span>.<\/strong>\r\n\r\n<\/div>\r\n
\r\n\r\n\"\"\r\n\r\n \r\n\r\nMODIFIED CYCLOMATIC COMPLEXITY MEASURES\u00a0<\/strong>\r\n\r\n \r\n\r\nGiven p <\/em>connected components of a graph:\r\n\r\n\r\n\r\n\r\n
\u25e6<\/td>\r\nV(G) = e \u2013 n + 2p<\/td>\r\n(1)<\/td>\r\n<\/tr>\r\n
\u25e6<\/td>\r\nVLI(G) = e \u2013 n + p + 1<\/td>\r\n(2)<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n \r\n

Eq. (2) is known as linearly-independent <\/em>cyclomatic complexity. VLI does not change when program is modularized into p <\/em>modules. A number of industry studies have indicated that the higher V(G), the higher the probability or errors.<\/p>\r\n \r\n\r\n\"\"\r\n\r\n<\/div>\r\n \r\n

The following example shows computation of the cyclomatic complexity measures where modularization \u00a0does \u00a0not \u00a0increase \u00a0complexity. \u00a0This \u00a0is \u00a0known \u00a0as\u00a0 \u00a0intuitive\u00a0 \u00a0expectation where modularization should not increase complexity.<\/span><\/p>\r\n\r\n

\r\n\r\n\"\"\r\n\r\n<\/div>\r\n \r\n\r\nSTATEMENT COVERAGE\u00a0<\/strong>\r\n
\r\n\r\n \r\n

Statement Coverage requires that each statement will have been executed at least once. It is the simplest form of logic coverage and also known as Node Coverage. The given example shows the minimum number of test cases required to achieve statement coverage for the given program segment.<\/p>\r\n\r\n<\/div>\r\n\"\"\r\n\r\n \r\n

Another example to determine the complexity, where the given block code is:<\/span><\/p>\r\n\r\n

\r\n\r\n \r\n\r\npublic void howComplex() {\r\n\r\nint i=20;\r\n\r\nwhile (i<10) {\r\n\r\n \r\n\r\nSystem.out.printf(\"i is %d\", i);\r\n\r\nif (i%2 == 0) {\r\n\r\nSystem.out.println(\"even\");\r\n\r\n \r\n\r\n} else { System.out.println(\"odd\");\r\n\r\n}}}\r\n\r\n \r\n\r\nThe graph flow for the given block of code is given as follows, the complexity is given as follows;\r\n\r\n \r\n

V (G) = 2 enclosed area + 1 = 3\u00a0<\/strong><\/p>\r\n \r\n\r\n\"\"\r\n\r\n \r\n\r\nBRANCH COVERAGE\u00a0<\/strong>\r\n\r\n \r\n

Branch Coverage requires that each branch will have been traversed, and that every program entry point will have been taken, at least once. It is also known as Edge Coverage. Branch coverage ensures that every program entry point will have been taken, at least once. Every branch is traversed to ensure that each branch is validated and does not exhibit any abnormal functionalities.<\/p>\r\n\r\n<\/div>\r\n \r\n

Relationship between Statement and Branch Coverage:\u00a0<\/span><\/strong><\/p>\r\n\r\n

\r\n\r\n \r\n

Statement Coverage subsumes Branch Coverage (\u201cstatement => branch\u201d). <\/strong>If a program has \"dead (i.e., unreachable) code\", then \"statement coverage\" is unachievable. We would need to modify the program in order to bring the dead code back to \u201clife\u201d. The bottom line is that we will always assume the nominal case of \u201cno dead code\" unless explicitly stated otherwise. Under this assumption, Branch Coverage does indeed subsume Statement Coverage.<\/p>\r\n \r\n\r\n \r\n\r\nCONDITION COVERAGE\u00a0<\/strong>\r\n\r\n \r\n\r\nA branch predicate may have more than one condition. The given example shows condition coverage.\r\n\r\n \r\n\r\ninput(X,Y)\r\n\r\n \r\n\r\nif (Y<=0) or (X=0) then\r\n\r\nY := -Y\r\n\r\nend_if\r\n\r\n \r\n\r\nwhile (Y>0) and (not EOF) do\r\n\r\ninput(X)\r\n\r\nY := Y-1\r\n\r\n \r\n\r\nend_while\r\n\r\n \r\n\r\nCondition Coverage requires that each condition will have been true at least once and false at least once. For example:\r\n\r\n \r\n\r\nif A <\/strong>or B <\/strong>then s1\r\n\r\nelse\r\n\r\ns2 end_if_then_else\r\n\r\n \r\n\r\n\"\"\r\n\r\n<\/div>\r\n \r\n

Branch\/Condition Coverage requires that both Branch AND Condition Coverage will have been achieved. Therefore, Branch\/Condition Coverage subsumes both Branch Coverage and Condition Coverage.<\/span><\/p>\r\n\r\n

\r\n\r\n \r\n\r\nSummary of White-Box Coverage Relationships\u00a0<\/strong>\r\n\r\n \r\n\r\nThe following figure depicts the white box coverage relationships:\r\n\r\n \r\n\r\n\"\"\r\n\r\nTESTING STRATEGIES\u00a0<\/strong>\r\n\r\n \r\n

Many unanswered questions about white box and black box testing. E.g. who does the testing? Which techniques should we use and when? There are no universal strategies, just principles that have been useful in practice. E.g. the notions of unit testing and integration testing.<\/p>\r\n \r\n\r\nBasic Principles\u00a0<\/strong>\r\n

    \r\n \t
  • Testing starts at the component level and works \u201coutwards\u201d. Unit testing, integration testing and system testing.<\/li>\r\n \t
  • Different testing techniques are appropriate at different scopes.<\/li>\r\n \t
  • Testing is conducted by developers and\/or by a specialized group of testers.<\/li>\r\n \t
  • Testing is different from debugging. Debugging follows successful testing<\/li>\r\n<\/ul>\r\n<\/div>\r\n \r\n

    Scope and Focus<\/strong><\/p>\r\n\r\n

      \r\n \t
    • Unit testing<\/strong>\r\n
        \r\n \t
      • Scope: individual com<\/li>\r\n \t
      • Focus: component corre<\/li>\r\n \t
      • Black-box and white-box techniques.<\/li>\r\n<\/ul>\r\n<\/li>\r\n \t
      • Integration testing<\/strong>\r\n
          \r\n \t
        • Scope: set of interacting com<\/li>\r\n \t
        • Focus: correctness of component interac<\/li>\r\n \t
        • Mostly black-box, some white-box<\/li>\r\n<\/ul>\r\n<\/li>\r\n \t
        • System testing<\/strong>\r\n
            \r\n \t
          • Scope: entire system.<\/li>\r\n \t
          • Focus: overall system<\/li>\r\n \t
          • Only black-box techniques.<\/li>\r\n<\/ul>\r\n<\/li>\r\n<\/ul>\r\n \r\n

            TEST-FIRST PROGRAMMING<\/strong><\/p>\r\n \r\n

            Modern practices emphasize the importance of testing during development. \u00a0Testing during development reduces risks, ensures consistency and saves development costs<\/p>\r\n \r\n

            Example: <\/strong>Test-first programming.<\/p>\r\n \r\n

            The basic idea before you start writing any code is first write the tests for this code. Write a little test code, write the corresponding unit code, make sure it passes the tests, and then repeat.<\/p>\r\n \r\n

            Advantages of Test-First Programming<\/strong><\/p>\r\n\r\n

              \r\n \t
            • Developers do not \u201cskip\u201d unit testing.<\/li>\r\n \t
            • Satisfaction for the programmer, the feeling of accomplishment when the tests pass.<\/li>\r\n \t
            • Helps clarify interface and behavior before programming. To write tests for something, first you need to understand it well.<\/li>\r\n \t
            • Software evolution.<\/li>\r\n \t
            • After changing existing code, rerun the tests to gain confidence. (Regression testing).<\/li>\r\n<\/ul>\r\n \r\n\r\nWeb Links<\/strong>\r\n
                \r\n \t
              • softwaretestingfundamentals.com\/white-box-testing\/<\/li>\r\n \t
              • www.softwaretestinghelp.com\/white-box-testing-techniques-with-example\/<\/li>\r\n \t
              • Www.softwaretestingclass.com\/white-box-testing\/<\/li>\r\n<\/ul>\r\n \r\n\r\nSupporting & Reference Materials<\/strong>\r\n
                  \r\n \t
                • Roger S. Pressman, \u201cSoftware Engineering: A Practitioner\u2019s Approach\u201d, Fifth Edition, McGraw Hill, 2001.<\/li>\r\n \t
                • Pankaj Jalote, \u201cAn Integrated Approach to Software Engineering\u201d, Second Edition, Narosa Publications, 2005.<\/li>\r\n \t
                • Ian Sommerville, \u201cSoftware Engineering\u201d, Tenth Edition, Pearson Education, 2017.<\/li>\r\n<\/ul>","rendered":"
                  \n

                   <\/p>\n

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

                   <\/p>\n

                  White box is a testing methodology to test the internal structures and working of software. White box testing also know as structural testing is testing based on analysis of internal logic (design, code, etc.).<\/p>\n

                   <\/p>\n

                  LEARNING OBJECTIVES\u00a0<\/strong><\/p>\n

                   <\/p>\n

                  \u2022 To focus on Program structures, Program internal logic and data structures, Program internal behaviors and states.<\/p>\n

                  \u2022 To focus on internal program structure and discover all internal program errors.<\/p>\n

                   <\/p>\n

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

                   <\/p>\n

                  The following example shows the flow graph and the paths through the nodes, the example shows that the paths P3 and P4 are the same but they have different start and endpoints.<\/p>\n<\/div>\n

                  \"\"<\/p>\n

                  \n

                   <\/p>\n

                  In the example, the paths that form cycles are identified, where P4, P8, P9 does not form\u00a0cycles<\/span>.<\/strong><\/p>\n<\/div>\n

                  \n

                  \"\"<\/p>\n

                   <\/p>\n

                  MODIFIED CYCLOMATIC COMPLEXITY MEASURES\u00a0<\/strong><\/p>\n

                   <\/p>\n

                  Given p <\/em>connected components of a graph:<\/p>\n\n\n\n\n
                  \u25e6<\/td>\nV(G) = e \u2013 n + 2p<\/td>\n(1)<\/td>\n<\/tr>\n
                  \u25e6<\/td>\nVLI(G) = e \u2013 n + p + 1<\/td>\n(2)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

                   <\/p>\n

                  Eq. (2) is known as linearly-independent <\/em>cyclomatic complexity. VLI does not change when program is modularized into p <\/em>modules. A number of industry studies have indicated that the higher V(G), the higher the probability or errors.<\/p>\n

                   <\/p>\n

                  \"\"<\/p>\n<\/div>\n

                   <\/p>\n

                  The following example shows computation of the cyclomatic complexity measures where modularization \u00a0does \u00a0not \u00a0increase \u00a0complexity. \u00a0This \u00a0is \u00a0known \u00a0as\u00a0 \u00a0intuitive\u00a0 \u00a0expectation where modularization should not increase complexity.<\/span><\/p>\n

                  \n

                  \"\"<\/p>\n<\/div>\n

                   <\/p>\n

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

                  \n

                   <\/p>\n

                  Statement Coverage requires that each statement will have been executed at least once. It is the simplest form of logic coverage and also known as Node Coverage. The given example shows the minimum number of test cases required to achieve statement coverage for the given program segment.<\/p>\n<\/div>\n

                  \"\"<\/p>\n

                   <\/p>\n

                  Another example to determine the complexity, where the given block code is:<\/span><\/p>\n

                  \n

                   <\/p>\n

                  public void howComplex() {<\/p>\n

                  int i=20;<\/p>\n

                  while (i<10) {<\/p>\n

                   <\/p>\n

                  System.out.printf(“i is %d”, i);<\/p>\n

                  if (i%2 == 0) {<\/p>\n

                  System.out.println(“even”);<\/p>\n

                   <\/p>\n

                  } else { System.out.println(“odd”);<\/p>\n

                  }}}<\/p>\n

                   <\/p>\n

                  The graph flow for the given block of code is given as follows, the complexity is given as follows;<\/p>\n

                   <\/p>\n

                  V (G) = 2 enclosed area + 1 = 3\u00a0<\/strong><\/p>\n

                   <\/p>\n

                  \"\"<\/p>\n

                   <\/p>\n

                  BRANCH COVERAGE\u00a0<\/strong><\/p>\n

                   <\/p>\n

                  Branch Coverage requires that each branch will have been traversed, and that every program entry point will have been taken, at least once. It is also known as Edge Coverage. Branch coverage ensures that every program entry point will have been taken, at least once. Every branch is traversed to ensure that each branch is validated and does not exhibit any abnormal functionalities.<\/p>\n<\/div>\n

                   <\/p>\n

                  Relationship between Statement and Branch Coverage:\u00a0<\/span><\/strong><\/p>\n

                  \n

                   <\/p>\n

                  Statement Coverage subsumes Branch Coverage (\u201cstatement => branch\u201d). <\/strong>If a program has “dead (i.e., unreachable) code”, then “statement coverage” is unachievable. We would need to modify the program in order to bring the dead code back to \u201clife\u201d. The bottom line is that we will always assume the nominal case of \u201cno dead code” unless explicitly stated otherwise. Under this assumption, Branch Coverage does indeed subsume Statement Coverage.<\/p>\n

                   <\/p>\n

                   <\/p>\n

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

                   <\/p>\n

                  A branch predicate may have more than one condition. The given example shows condition coverage.<\/p>\n

                   <\/p>\n

                  input(X,Y)<\/p>\n

                   <\/p>\n

                  if (Y<=0) or (X=0) then<\/p>\n

                  Y := -Y<\/p>\n

                  end_if<\/p>\n

                   <\/p>\n

                  while (Y>0) and (not EOF) do<\/p>\n

                  input(X)<\/p>\n

                  Y := Y-1<\/p>\n

                   <\/p>\n

                  end_while<\/p>\n

                   <\/p>\n

                  Condition Coverage requires that each condition will have been true at least once and false at least once. For example:<\/p>\n

                   <\/p>\n

                  if A <\/strong>or B <\/strong>then s1<\/p>\n

                  else<\/p>\n

                  s2 end_if_then_else<\/p>\n

                   <\/p>\n

                  \"\"<\/p>\n<\/div>\n

                   <\/p>\n

                  Branch\/Condition Coverage requires that both Branch AND Condition Coverage will have been achieved. Therefore, Branch\/Condition Coverage subsumes both Branch Coverage and Condition Coverage.<\/span><\/p>\n

                  \n

                   <\/p>\n

                  Summary of White-Box Coverage Relationships\u00a0<\/strong><\/p>\n

                   <\/p>\n

                  The following figure depicts the white box coverage relationships:<\/p>\n

                   <\/p>\n

                  \"\"<\/p>\n

                  TESTING STRATEGIES\u00a0<\/strong><\/p>\n

                   <\/p>\n

                  Many unanswered questions about white box and black box testing. E.g. who does the testing? Which techniques should we use and when? There are no universal strategies, just principles that have been useful in practice. E.g. the notions of unit testing and integration testing.<\/p>\n

                   <\/p>\n

                  Basic Principles\u00a0<\/strong><\/p>\n

                    \n
                  • Testing starts at the component level and works \u201coutwards\u201d. Unit testing, integration testing and system testing.<\/li>\n
                  • Different testing techniques are appropriate at different scopes.<\/li>\n
                  • Testing is conducted by developers and\/or by a specialized group of testers.<\/li>\n
                  • Testing is different from debugging. Debugging follows successful testing<\/li>\n<\/ul>\n<\/div>\n

                     <\/p>\n

                    Scope and Focus<\/strong><\/p>\n

                      \n
                    • Unit testing<\/strong>\n
                        \n
                      • Scope: individual com<\/li>\n
                      • Focus: component corre<\/li>\n
                      • Black-box and white-box techniques.<\/li>\n<\/ul>\n<\/li>\n
                      • Integration testing<\/strong>\n
                          \n
                        • Scope: set of interacting com<\/li>\n
                        • Focus: correctness of component interac<\/li>\n
                        • Mostly black-box, some white-box<\/li>\n<\/ul>\n<\/li>\n
                        • System testing<\/strong>\n
                            \n
                          • Scope: entire system.<\/li>\n
                          • Focus: overall system<\/li>\n
                          • Only black-box techniques.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

                             <\/p>\n

                            TEST-FIRST PROGRAMMING<\/strong><\/p>\n

                             <\/p>\n

                            Modern practices emphasize the importance of testing during development. \u00a0Testing during development reduces risks, ensures consistency and saves development costs<\/p>\n

                             <\/p>\n

                            Example: <\/strong>Test-first programming.<\/p>\n

                             <\/p>\n

                            The basic idea before you start writing any code is first write the tests for this code. Write a little test code, write the corresponding unit code, make sure it passes the tests, and then repeat.<\/p>\n

                             <\/p>\n

                            Advantages of Test-First Programming<\/strong><\/p>\n

                              \n
                            • Developers do not \u201cskip\u201d unit testing.<\/li>\n
                            • Satisfaction for the programmer, the feeling of accomplishment when the tests pass.<\/li>\n
                            • Helps clarify interface and behavior before programming. To write tests for something, first you need to understand it well.<\/li>\n
                            • Software evolution.<\/li>\n
                            • After changing existing code, rerun the tests to gain confidence. (Regression testing).<\/li>\n<\/ul>\n

                               <\/p>\n

                              Web Links<\/strong><\/p>\n

                                \n
                              • softwaretestingfundamentals.com\/white-box-testing\/<\/li>\n
                              • www.softwaretestinghelp.com\/white-box-testing-techniques-with-example\/<\/li>\n
                              • Www.softwaretestingclass.com\/white-box-testing\/<\/li>\n<\/ul>\n

                                 <\/p>\n

                                Supporting & Reference Materials<\/strong><\/p>\n

                                  \n
                                • Roger S. Pressman, \u201cSoftware Engineering: A Practitioner\u2019s Approach\u201d, Fifth Edition, McGraw Hill, 2001.<\/li>\n
                                • Pankaj Jalote, \u201cAn Integrated Approach to Software Engineering\u201d, Second Edition, Narosa Publications, 2005.<\/li>\n
                                • Ian Sommerville, \u201cSoftware Engineering\u201d, Tenth Edition, Pearson Education, 2017.<\/li>\n<\/ul>\n","protected":false},"author":4,"menu_order":28,"template":"","meta":{"_acf_changed":false,"pb_show_title":"on","pb_short_title":"","pb_subtitle":"","pb_authors":["dr-r-baskaran"],"pb_section_license":""},"chapter-type":[],"contributor":[58],"license":[],"class_list":["post-279","chapter","type-chapter","status-publish","hentry","contributor-dr-r-baskaran"],"part":3,"_links":{"self":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters\/279","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/users\/4"}],"version-history":[{"count":6,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters\/279\/revisions"}],"predecessor-version":[{"id":412,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters\/279\/revisions\/412"}],"part":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/parts\/3"}],"metadata":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters\/279\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/media?parent=279"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapter-type?post=279"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/contributor?post=279"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/license?post=279"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}