Page 186 - DCAP405_SOFTWARE_ENGINEERING
P. 186

Unit 11: Testing Strategies




          Good testing provides measures for all relevant factors. The importance of any particular factor  Notes
          varies from application to application. Any system where human lives are at stake must place
          extreme emphasis on reliability and integrity. In the typical business system usability and
          maintainability are the key factors, while for a one-time scientific program neither may be
          significant. Our testing, to be fully effective, must be geared to measuring each relevant factor
          and thus forcing quality to become tangible and visible.
          Tests with the purpose of validating the product works are named clean tests, or positive tests.
          The drawbacks are that it can only validate that the software works for the specified test cases.
          A finite number of tests can not validate that the software works for all situations. On the
          contrary, only one failed test is sufficient enough to show that the software does not work. Dirty
          tests, or negative tests, refer to the tests aiming at breaking the software, or showing that it does
          not work.




              Task  “A piece of software must have sufficient exception handling capabilities to survive
            a significant level of dirty tests.“ What have you understood from this statement explain
            with an example.
          A testable design is a design that can be easily validated, falsified and maintained. Because
          testing is a rigorous effort and requires significant time and cost, design for testability is also an
          important design rule for software development.

          11.1.3 History of Software Testing

          The separation of debugging from testing was initially introduced by Glenford J. Myers in 1979.
          Although his attention was on breakage testing (“a successful test is one that finds a bug”), it
          illustrated the desire of the software engineering community to separate fundamental
          development activities, such as debugging, from that of verification. Dr. Dave Gelperin and
          Dr. William C. Hetzel classified in 1988 the phases and goals in software testing in the following
          stages:
          Until  1956 - Debugging oriented
                 1957-1978 - Demonstration oriented
                 1979-1982 - Destruction oriented

                 1983-1987 - Evaluation oriented
                 1988-2000 - Prevention oriented

          Definition

          Testing is not a technique for building quality systems; rather, it is a technique that is used
          because we recognize that we have failed to build a fault free system. Testing assists in its repair
          by identifying where the program fails to meet its specification. We will broaden the usual
          definition of testing that typically refers only to the testing of code. The expanded definition
          includes the testing of the many types of models, requirements, analysis, architectural and
          detailed design, that are constructed in the early development phases. These models may be
          represented in an executable format in a CASE tool such as BetterStateÅ or they may require a
          form of symbolic execution or inspection. My justification for classifying these activities as
          testing is that the inputs to one of these executions will be much more specific than the inputs to
          a typical review process.





                                           LOVELY PROFESSIONAL UNIVERSITY                                   179
   181   182   183   184   185   186   187   188   189   190   191