Contact at or 8097636691/9323040215
Responsive Ads Here

Saturday, 3 February 2018

Carving and Replaying Differential Unit Test Cases from System Test Cases(2009)

Carving and Replaying Differential Unit 

Test Cases from System Test Cases(2009)

In this project, developing effective suites of unit test cases presents a number of challenges. Specifications of unit behavior are usually informal and are often incomplete or ambiguous, leading to the development of overly general or incorrect unit tests. Furthermore, such specifications may evolve independently of implementations requiring additional maintenance of unit tests even if implementations remain unchanged. Testers may find it difficult to imagine sets of unit input values that exercise the full range of unit behavior and thereby fail to exercise the different ways in which the unit will be used as a part of a system. Unit test cases are focused and efficient. System tests are effective at exercising complex usage patterns. Differential unit tests (DUTs) are a hybrid of unit and system tests that exploits their strengths. They are generated by carving the system components, while executing a system test case that influence the behavior of the target unit and then reassembling those components so that the unit can be exercised as it was by the system test. In this project, we show that DUTs retain some of the advantages of unit tests, can be automatically generated, and have the potential for revealing faults related to intricate system executions. We present a framework for carving and replaying DUTs that accounts for a wide variety of strategies and trade-offs, we implement an automated instance of the framework with several techniques to mitigate test cost and enhance flexibility and robustness, and we empirically assess the efficacy of carving and replaying DUTs on three software artifacts.
Existing System
  • ·        In the existing system, SOFTWARE engineers develop unit test cases to validate individual program units (e.g., methods, classes, and packages) before they are integrated into the whole system.
  • ·        By focusing on an isolated unit, unit tests are not constrained or influenced by other parts of the system in exercising the target unit. Software engineers also develop system tests, usually based on documents that are available for most software systems that describe the system’s functionality from the user’s perspective, for example, requirement documents and user’s manuals.
  • ·        This makes system tests appropriate for determining the readiness of a system for release or its acceptability to customers.
  • Disadvantage:
  • ·        While system tests are an essential component of all practical software validation methods, they do have several disadvantages. They can be expensive to execute; for large systems, days or weeks, and considerable human effort may be needed for running a thorough suite of system tests.
  • ·        Even very thorough system testing may fail to exercise the full range of behavior implemented by a system’s particular units; thus, system testing cannot be viewed as an effective replacement for unit testing
Proposed System:
  • ·        In the proposed system, DUTs are created from system tests by capturing components of the exercised system that may influence the behavior of the targeted unit and that reflect the results of executing the unit; we term this carving because it involves extracting the relevant parts of the program state corresponding to the components exercised by a system test.
  • ·        Those components are automatically assembled into a test harness that establishes the prestate of the unit that was encountered during system test execution.
  • ·        From that state, the unit is replayed and the resulting state is queried to determine if there are differences with the recorded unit post state. 
  • ·        We compare the cost and effectiveness of system tests and carved unit tests.
  • ·         The results indicate that carved test cases can be as effective as system test cases in terms of fault detection, but much more efficient in the presence of localized changes.
  • ·         A framework for automatically carving and replaying DUTs that accounts for a   wide variety of implementation strategies with different trade-offs.
System Requirements:
Hardware requirements
 Processor                     PENTIUM IV
     RAM                           256 MB
     Hard Disk                   80 GB
     Mouse                         Logitech Serial Mouse
     Keyboard                    Standard 104 Enhanced Keyboard

Software requirements
     Language                      Java, J2EE

  • Designing the Framework.      
  • Instantiation of the framework
  • Evaluating the framework
Modules descriptions:
Designing the Framework:
A framework for test carving and replay:
  1. Identify a program state from which to initiate testing,
      2.   establish that program state,
      3.   execute the unit from that state, and
      4.  judge the correctness of the resulting state.
Improving CR with Projections:     
          We focus CR testing on a single method by defining projections on carved  prestates that preserve information related to the unit under test and are likely to provide significant reduction in prestate size.
Instantiation of the framework:   
System Architecture  
        The carving activity starts with the Carver class which takes four inputs: the    program name, the target method(s) m within the program, the system test case stx inputs, and the reduction and filtering options.
Clustering projection.:
       The clustering projection  attempts to identify a set of similar UTs,DUTxcallee;1;DUTx!callee;2; . . . , that result from the repeatedinvocation of callee from within the same DUT, DUTxcaller,of method caller.
Evaluating the framework:
RQ1: Efficiency: We first focus on the efficiency of the carving process. Although our infrastructure completely automates carving, this process does consume time and storage so it is important to assess its efficiency as it might impact its adoption and scalability.
    RQ2: Fault detection effectiveness. Most of the test suites carved from S-selection, (with k _ 1), C-selection mayref ,and C-selection-touched detected as many faults as the S-retest-all technique. This indicates that a DUT test suite can be as effective as a system test suite at detecting faults, even when using aggressive projections.

No comments:

Post a Comment