• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Test Levels & Techniques
 

Test Levels & Techniques

on

  • 8,459 views

 

Statistics

Views

Total Views
8,459
Views on SlideShare
8,448
Embed Views
11

Actions

Likes
2
Downloads
449
Comments
0

2 Embeds 11

http://www.slideshare.net 7
http://www.scoop.it 4

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Test Levels & Techniques Test Levels & Techniques Presentation Transcript

    • Static Testing
      • Static testing refers to testing that takes place without Execution - examining and reviewing it.
      • Dynamic Testing
      • Dynamic testing is what you would normally think of testing - executing and using the software.
    • Dynamic Testing
      • Techniques used are determined by the type of testing that must be conducted
        • Functional
        • Structural
    • Functional Testing
      • Structure of the program is not considered.
      • Test cases are decided based on the requirements or specification of the program or module
      • Hence it is often called as “Black Box Testing”.
    • Structural Testing
      • Concerned with testing ,the implementation of the program.
      • Focus on the internal structure of the program.
      • The intent of structural testing is not to exercise all the different input or output condition but to exercise the different programming structures and data structures in the program.
      • Phases of software testing:
        • Unit Testing
        • Integration/Build Testing
        • Validation/Functional Testing
        • System Testing
        • Acceptance Testing
      Testing Levels
    • Unit Testing
      • Test each module individually.
      • Follows a white box testing (Logic of the program)
    • Integration testing
      • Integrate two or more module.i.e. communicate between the modules.
      • Follow a white box testing (Testing the code)
    • Integration Testing - Overview
    • System Testing
      • Confirms that the system as a whole delivers the functionality originally required.
      • Follows the black box testing.
    • System Testing - Goals
      • Incorrect or missing feature
      • Performance errors
      • Security errors
      • User interface errors
      • Configuration and compatibility
      • Compliance to required standards
    • System Testing - Overview
    • System Testing - Overview
      • System Tests:
        • Define test procedures and instructions
        • Review test plans
        • Execute test plans
        • Record results
    • System Testing - Strategy
      • Developing System Tests
        • stress tests
        • security tests
        • recovery tests
        • performance tests
    • User Acceptance Testing (UAT)
      • Building the confidence of the client and users is the role of the acceptance test phase.
      • It is depend on the business scenario.
      • Those functions required by the customer to demonstrate sufficient functionality and reliability to warrant acceptance.
    • V-Model Unit Integration System UAT LLD HLD SRS Business scenario
    • Software Testing
    • Testing Techniques
      • White Box
      • Black Box
      • Incremental
      • Thread
    • White Box Testing
    • White Box Testing - Internal
      • Purpose of Unit Tests:
        • Test all loops
        • Test Basis paths
        • Test conditional statements
        • Test data structures
        • * develop unit tests after the design portion of the Build Definition Spec. is completed.
    • White Box Testing - Internal
    • White Box Testing Techniques
      • Statement coverage – execute all statements at least once.
      • Decision coverage - execute each decision direction at least once.
      • Condition coverage – execute each decision with all possible outcomes at least once
    • White Box Testing Techniques
      • Loop Testing:
        • Simple Loops
        • Nested Loops
        • Concatenated Loops
        • Unstructured Loops
    • Black Box Testing
    • Black Box Testing - External
      • Black Box Testing verifies that the requirements have been met.
        • How is functional validity tested
        • How is system behavior and performance tested.
        • What classes of input will make good test cases?
        • Is the system particularly sensitive to certain input values?
        • How are the boundaries of a data class isolated?
        • What data rates and data volume can the system tolerate?
        • What effect will specific combinations of data have on system operation?
    • Black Box Testing - External
      • Black Box Tests look for:
        • incorrect or missing functions
        • interface errors
        • errors in external database access
        • behavior or performance errors
    • Black Box Testing Techniques
        • * Equivalence Partitioning
        • * Boundary Analysis
        • * Error Guessing
    • Equivalence Partitioning
      • A subset of data that is representative of a larger class
      • For example, a program which edits credit limits within a given range ($10,000 - $15,000 would have 3 equivalence classes:
        • Less than $10,000 (invalid)
        • Between $10,000 and $15,000 (valid)
        • Greater than $15,000 (invalid)
    • Boundary Analysis
      • A technique that consists of developing test cases and data that focus on the input and output boundaries of a given function
    • Boundary Analysis continued...
      • In the same credit limit example, boundary analysis would test:
        • Low boundary plus or minus one ($9,999 and $10,001)
        • On the boundary ($10,000 and $15,000)
        • Upper boundary plus or minus one ($14,999 and $15,001)
    • Error Guessing
      • Based on the theory that test cases can be developed based on experience of the Test Engineer
      • For example, in an example where one of the inputs is the date, a test engineer might try February 29,2000 or 9/9/99
    • Incremental Testing
      • A disciplined method of testing the interfaces between unit-tested programs as well as between system components
      • Incremental Testing Types
      • - Top-down
      • - Bottom-up
    • Top-Down
      • Begins testing from the top of the module hierarchy and works down to the bottom using interim stubs to simulate lower interfacing modules or programs
    • Bottom-Up
      • Begins testing from the bottom of the hierarchy and works up to the top
      • Bottom-up testing requires the development of driver modules which provide the test input, call the module or program being testing, and display test output
      • A technique, often used during early integration testing
      • Demonstrates key functional capabilities by testing a string of units that accomplish a specific function in the application
      Thread Testing
    • Illustrates various techniques used throughout the test stages