SOFTWARE TESTING STRATEGIES SUBMITTED TO:- SUBMITTED BY:- MR. RAKESH KUMAR ALPANA (171401) ASTT. PROFESSOR ME MODULAR(CSE) COMPUTER SCIENCE & ENGG. E-MAIL:-anshubhaskar93@gmail.com NITTTR CHANDIGARH
CONTENTS •Introduction •A strategic approach to testing •Test strategies for conventional software •Test strategies for object-oriented software •Difference between conventional and object- oriented software testing •Reference
Introduction • A strategy for software testing integrates the design of software test cases into a well-planned series of steps that result in successful development of the software. • The strategy provides a road map that describes the steps to be taken, when, and how much effort, time, and resources will be required.
• The strategy incorporates test planning, test case design, test execution, and test result collection and evaluation. • The strategy provides guidance for the practitioner and a set of milestones for the manager .Because of time pressures, progress must be measurable and problems must surface as early as possible.
A STRATEGIC APPROACH TO TESTING • To perform effective testing, a software team should conduct effective formal technical reviews. • Testing begins at the component level and work outward toward the integration of the entire computer based system. • Different testing techniques are appropriate at different points in time. • Testing is conducted by the developer of the software and (for large projects) by an independent test group. • Testing and debugging are different activities, but debugging must be accommodated in any testing strategy.
SOFTWARE TESTING STRATEGY • Unit testing – Concentrates on each component/function of the software as implemented in the source code • Integration testing – Focuses on the design and construction of the software architecture • Validation testing – Requirements are validated against the constructed software • System testing – The software and other system elements are tested as a whole
TESTING STRATEGY
TEST STRATEGIES FOR CONVENTIONAL SOFTWARE (1) Unit Testing • Focuses testing on the function or software module • Concentrates on the internal processing logic and data structures • Is simplified when a module is designed with high cohesion • Reduces the number of test cases • Allows errors to be more easily predicted and uncovered • Concentrates on critical modules and those with high cyclomatic complexity when testing resources are limited
TARGETS FOR UNIT TEST CASES • Module interface • Ensure that information flows properly into and out of the module • Local data structures • Ensure that data stored temporarily maintains its integrity during all steps in an algorithm execution • Boundary conditions • Ensure that the module operates properly at boundary values established to limit or restrict processing • Independent paths (basis paths) • Paths are exercised to ensure that all statements in a module have been executed at least once • Error handling paths • Ensure that the algorithms respond correctly to specific error
DRIVERS AND STUBS FOR UNIT TESTING • Driver • A simple main program that accepts test case data, passes such data to the component being tested, and prints the returned results • Stubs • Serve to replace modules that are subordinate to (called by) the component to be tested • It uses the module’s exact interface, may do minimal data manipulation, provides verification of entry, and returns control to the module undergoing testing • Drivers and stubs both represent overhead • Both must be written but don’t constitute part of the installed software product
(2) Integration Testing • Defined as a systematic technique for constructing the software architecture • At the same time integration is occurring, conduct tests to uncover errors associated with interfaces • Objective is to take unit tested modules and build a program structure based on the prescribed design • Two Approaches • Non-incremental Integration Testing • Incremental Integration Testing
NON-INCREMENTAL INTEGRATION TESTING • Commonly called the “Big Bang” approach • All components are combined in advance • The entire program is tested as a whole • Chaos results • Many seemingly-unrelated errors are encountered • Correction is difficult because isolation of causes is complicated • Once a set of errors are corrected, more errors occur, and testing appears to enter an endless loop
INCREMENTAL INTEGRATION TESTING • Three kinds • Top-down integration • Bottom-up integration • Sandwich integration • The program is constructed and tested in small increments. • Errors are easier to isolate and correct. • Interfaces are more likely to be tested completely. • A systematic test approach is applied.
OBJECT-ORIENTED TESTING STRATEGIES (1) Unit Testing • Smallest testable unit is the encapsulated class or object • Test each operation as part of a class hierarchy because its class hierarchy defines its context of use • Driven by class operations and state behavior, not algorithmic detail and data flow across module interface • Approach: Test each method (and constructor) within a class Test the state behavior (attributes) of the class between methods
CONTD… • Complete test coverage of a class involves Testing all operations Setting and interrogating all object attributes Exercising the object in all possible state . • Test sequences are designed to ensure that relevant operations are exercised . • State of the class is examined to determine if errors exist .
CONTD… • How is class testing different from conventional testing? • Conventional testing focuses on input- process-output, whereas class testing focuses on each method, then designing sequences of methods to exercise states of a class. • But white-box testing can still be applied .
CONTD… (2) Integration Testing • OO does not have a hierarchical control structure so conventional top- down and bottom-up integration tests have little meaning . • Focuses on groups of classes that collaborate in some manner. • Integration of operations one at a time into a class is often meaningless Because of direct and indirect interaction of components .
CONTD… • Thread-based testing Testing/integrate the set of classes required to respond to one input or event • Cluster testing Groups of collaborating classes are tested for interaction errors • Regression testing is important as each thread, cluster or subsystem is added to the system
CONTD… (3)Validation Testing • Are we building the right product? • Validation succeeds when software functions in a manner that can be reasonably expected by the customer. • Focuses on visible user actions and user recognizable outputs • Validation tests are based on the use-case scenarios, the object behavior model, and the event flow diagram
CONTD… • Apply: • Use-case scenarios from the software requirements spec • Black-box testing to create a deficiency list • Acceptance tests through alpha (at developer’s site) and beta (at customer’s site) testing with actual customers
CONTD… • Software may be part of a larger system. • This often leads to “finger pointing” by other system dev teams Finger pointing defence: • 1. Design error-handling paths that test external information • 2. Conduct a series of tests that simulate bad data • 3. Record the results of tests to use as evidence
CONTD… (4)System Testing • Types of System Testing: • Recovery testing: how well and quickly does the system recover from faults. • Security testing: verify that protection mechanisms built into the system will protect from unauthorized access (hackers, disgruntled employees, fraudsters). • Stress testing: place abnormal load on the system . • Performance testing: investigate the run-time performance within the context of an integrated system .
DIFFERENCE BETWEEN CONVENTIONAL AND OBJECT ORIENTED TESTING Conventional testing • Conventional testing is the traditional approach to testing mostly done when water fall life cycle is used for development. • Conventional testing focuses more on decomposition and functional approaches. Object oriented testing • Object oriented testing is used when object oriented analysis and design is used for developing enterprise software. • Object oriented testing, uses composition.
Conventional testing • The three levels of testing (system, integration, unit) used in conventional testing. • Traditional development follows a sequential approach. • Needs to large duration sometimes to development the large projects. • Uses common processes likes: analysis, design, implementation, and testing Object oriented testing • not clearly defined when it comes to object oriented testing. • OO development uses incremental approach. • Need to more time than Traditional approach and leads that to more cost. • Uses UML notations likes: use case, class diagram, communication diagram, development diagram and sequence diagram.
REFERENCES • Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw- Hill)
Software Testing Strategies

Software Testing Strategies

  • 1.
    SOFTWARE TESTING STRATEGIES SUBMITTEDTO:- SUBMITTED BY:- MR. RAKESH KUMAR ALPANA (171401) ASTT. PROFESSOR ME MODULAR(CSE) COMPUTER SCIENCE & ENGG. E-MAIL:-anshubhaskar93@gmail.com NITTTR CHANDIGARH
  • 2.
    CONTENTS •Introduction •A strategic approachto testing •Test strategies for conventional software •Test strategies for object-oriented software •Difference between conventional and object- oriented software testing •Reference
  • 3.
    Introduction • A strategyfor software testing integrates the design of software test cases into a well-planned series of steps that result in successful development of the software. • The strategy provides a road map that describes the steps to be taken, when, and how much effort, time, and resources will be required.
  • 4.
    • The strategyincorporates test planning, test case design, test execution, and test result collection and evaluation. • The strategy provides guidance for the practitioner and a set of milestones for the manager .Because of time pressures, progress must be measurable and problems must surface as early as possible.
  • 5.
    A STRATEGIC APPROACHTO TESTING • To perform effective testing, a software team should conduct effective formal technical reviews. • Testing begins at the component level and work outward toward the integration of the entire computer based system. • Different testing techniques are appropriate at different points in time. • Testing is conducted by the developer of the software and (for large projects) by an independent test group. • Testing and debugging are different activities, but debugging must be accommodated in any testing strategy.
  • 6.
    SOFTWARE TESTING STRATEGY •Unit testing – Concentrates on each component/function of the software as implemented in the source code • Integration testing – Focuses on the design and construction of the software architecture • Validation testing – Requirements are validated against the constructed software • System testing – The software and other system elements are tested as a whole
  • 7.
  • 8.
    TEST STRATEGIES FORCONVENTIONAL SOFTWARE (1) Unit Testing • Focuses testing on the function or software module • Concentrates on the internal processing logic and data structures • Is simplified when a module is designed with high cohesion • Reduces the number of test cases • Allows errors to be more easily predicted and uncovered • Concentrates on critical modules and those with high cyclomatic complexity when testing resources are limited
  • 9.
    TARGETS FOR UNITTEST CASES • Module interface • Ensure that information flows properly into and out of the module • Local data structures • Ensure that data stored temporarily maintains its integrity during all steps in an algorithm execution • Boundary conditions • Ensure that the module operates properly at boundary values established to limit or restrict processing • Independent paths (basis paths) • Paths are exercised to ensure that all statements in a module have been executed at least once • Error handling paths • Ensure that the algorithms respond correctly to specific error
  • 11.
    DRIVERS AND STUBSFOR UNIT TESTING • Driver • A simple main program that accepts test case data, passes such data to the component being tested, and prints the returned results • Stubs • Serve to replace modules that are subordinate to (called by) the component to be tested • It uses the module’s exact interface, may do minimal data manipulation, provides verification of entry, and returns control to the module undergoing testing • Drivers and stubs both represent overhead • Both must be written but don’t constitute part of the installed software product
  • 12.
    (2) Integration Testing •Defined as a systematic technique for constructing the software architecture • At the same time integration is occurring, conduct tests to uncover errors associated with interfaces • Objective is to take unit tested modules and build a program structure based on the prescribed design • Two Approaches • Non-incremental Integration Testing • Incremental Integration Testing
  • 13.
    NON-INCREMENTAL INTEGRATION TESTING • Commonlycalled the “Big Bang” approach • All components are combined in advance • The entire program is tested as a whole • Chaos results • Many seemingly-unrelated errors are encountered • Correction is difficult because isolation of causes is complicated • Once a set of errors are corrected, more errors occur, and testing appears to enter an endless loop
  • 14.
    INCREMENTAL INTEGRATION TESTING • Threekinds • Top-down integration • Bottom-up integration • Sandwich integration • The program is constructed and tested in small increments. • Errors are easier to isolate and correct. • Interfaces are more likely to be tested completely. • A systematic test approach is applied.
  • 15.
    OBJECT-ORIENTED TESTING STRATEGIES (1) UnitTesting • Smallest testable unit is the encapsulated class or object • Test each operation as part of a class hierarchy because its class hierarchy defines its context of use • Driven by class operations and state behavior, not algorithmic detail and data flow across module interface • Approach: Test each method (and constructor) within a class Test the state behavior (attributes) of the class between methods
  • 16.
    CONTD… • Complete testcoverage of a class involves Testing all operations Setting and interrogating all object attributes Exercising the object in all possible state . • Test sequences are designed to ensure that relevant operations are exercised . • State of the class is examined to determine if errors exist .
  • 17.
    CONTD… • How isclass testing different from conventional testing? • Conventional testing focuses on input- process-output, whereas class testing focuses on each method, then designing sequences of methods to exercise states of a class. • But white-box testing can still be applied .
  • 18.
    CONTD… (2) Integration Testing •OO does not have a hierarchical control structure so conventional top- down and bottom-up integration tests have little meaning . • Focuses on groups of classes that collaborate in some manner. • Integration of operations one at a time into a class is often meaningless Because of direct and indirect interaction of components .
  • 19.
    CONTD… • Thread-based testingTesting/integrate the set of classes required to respond to one input or event • Cluster testing Groups of collaborating classes are tested for interaction errors • Regression testing is important as each thread, cluster or subsystem is added to the system
  • 20.
    CONTD… (3)Validation Testing • Arewe building the right product? • Validation succeeds when software functions in a manner that can be reasonably expected by the customer. • Focuses on visible user actions and user recognizable outputs • Validation tests are based on the use-case scenarios, the object behavior model, and the event flow diagram
  • 21.
    CONTD… • Apply: • Use-casescenarios from the software requirements spec • Black-box testing to create a deficiency list • Acceptance tests through alpha (at developer’s site) and beta (at customer’s site) testing with actual customers
  • 22.
    CONTD… • Software maybe part of a larger system. • This often leads to “finger pointing” by other system dev teams Finger pointing defence: • 1. Design error-handling paths that test external information • 2. Conduct a series of tests that simulate bad data • 3. Record the results of tests to use as evidence
  • 23.
    CONTD… (4)System Testing • Typesof System Testing: • Recovery testing: how well and quickly does the system recover from faults. • Security testing: verify that protection mechanisms built into the system will protect from unauthorized access (hackers, disgruntled employees, fraudsters). • Stress testing: place abnormal load on the system . • Performance testing: investigate the run-time performance within the context of an integrated system .
  • 24.
    DIFFERENCE BETWEEN CONVENTIONALAND OBJECT ORIENTED TESTING Conventional testing • Conventional testing is the traditional approach to testing mostly done when water fall life cycle is used for development. • Conventional testing focuses more on decomposition and functional approaches. Object oriented testing • Object oriented testing is used when object oriented analysis and design is used for developing enterprise software. • Object oriented testing, uses composition.
  • 25.
    Conventional testing • Thethree levels of testing (system, integration, unit) used in conventional testing. • Traditional development follows a sequential approach. • Needs to large duration sometimes to development the large projects. • Uses common processes likes: analysis, design, implementation, and testing Object oriented testing • not clearly defined when it comes to object oriented testing. • OO development uses incremental approach. • Need to more time than Traditional approach and leads that to more cost. • Uses UML notations likes: use case, class diagram, communication diagram, development diagram and sequence diagram.
  • 26.
    REFERENCES • Pressman, R.Software Engineering: A Practitioner’s Approach. McGraw- Hill)