Page 204 - DCAP405_SOFTWARE_ENGINEERING
P. 204

Unit 12: Testing Tactics




          exercised at least once; exercise all the logical decisions based on their true and false sides; (3)  Notes
          executing all loops at their boundaries and within them; and exercise internal data structures to
          ensure their validity.
          The reason of conducting white-box testing largely depends upon the nature of defects in software:
               Logic errors and incorrect assumptions are inversely proportional to the probability that
               a program path will be executed.
               We often believe that a logical path is not likely to be executed when, in fact, it may be
               executed on a regular basis.

               Typographical errors are random.
          Contrary to black-box testing, software is viewed as a white-box, or glass-box in white-box
          testing, as the structure and flow of the software under test are visible to the tester. Testing plans
          are made according to the details of the software implementation, such as programming
          language, logic, and styles. Test cases are derived from the program structure. White-box testing
          is also called glass-box testing, logic-driven testing or design-based testing.




              Task   Analyze why white box testing is known as glass box testing?
          There are many techniques available in white-box testing, because the problem of intractability
          is eased by specific knowledge and attention on the structure of the software under test. The
          intention of exhausting some aspect of the software is still strong in white-box testing, and some
          degree of exhaustion can be achieved, such as executing each line of code at least once (statement
          coverage), traverse every branch statements (branch coverage), or cover all the possible
          combinations of true and false condition predicates (Multiple condition coverage).

          Control-flow testing, loop testing, and data-flow testing, all maps the corresponding flow
          structure of the software into a directed graph. Test cases are carefully selected based on the
          criterion that all the nodes or paths are covered or traversed at least once. By doing so we may
          discover unnecessary “dead” code — code that is of no use, or never get executed at all, which
          can not be discovered by functional testing.
          In mutation testing, the original program code is perturbed and many mutated programs are
          created, each contains one fault. Each faulty version of the program is called a mutant. Test data
          are selected based on the effectiveness of failing the mutants. The more mutants a test case can
          kill, the better the test case is considered. The problem with mutation testing is that it is too
          computationally expensive to use. The boundary between black-box approach and white-box
          approach is not clear-cut. Many testing strategies mentioned above, may not be safely classified
          into black-box testing or white-box testing. It is also true for transaction-flow testing, syntax
          testing, finite-state testing, and many other testing strategies not discussed in this text. One
          reason is that all the above techniques will need some knowledge of the specification of the
          software under test. Another reason is that the idea of specification itself is broad — it may
          contain any requirement including the structure, programming language, and programming
          style as part of the specification content.
          We may be reluctant to consider random testing as a testing technique. The test case selection is
          simple and straightforward: they are randomly chosen. Some very subtle errors can be discovered
          with low cost. And it is also not inferior in coverage than other carefully designed testing
          techniques. One can also obtain reliability estimate using random testing results based on
          operational profiles.






                                           LOVELY PROFESSIONAL UNIVERSITY                                   197
   199   200   201   202   203   204   205   206   207   208   209