Please enable JavaScript.

Coggle requires JavaScript to display documents.

Test design techniques, dropped image link, dropped image link - Coggle…

- - - - needs to have input values
      - need to be detailed
    - - look at the test basis in order to see what could be tested
      - can be identified for test data as well as for test inputs and test outcomes
    - - represent the most important types of data
    - - The document that describes the steps to be taken in running a set of tests (and specifies the executable order of the tests)
    - - Like as test procedure
      - describe the instructions to a test execution tool
    - - Test conditions should be able to be linked back to their sources in the test basis
      - be either horizontal through all the test documentation for a given test level
      - Why is traceability important?
    - - what scenarios will be tested
      - how often will be tested
      - how will be tested
  - - - be a system requirement, a technical specification, the code itself (for structural testing), or a business process.
      - includes whatever the tests are based on
      - based on an experienced user's knowledge of the system
    - - identify as many as we can
      - start being selective about which ones to take forward to develop in more detail
      - combine into test cases
    - - select a good set of tests from the total number
        of all possible tests for a given system
      - Different techniques offer different ways of looking at the software under test
  - - - have no documentation at all
      - notes kept by individual testers
    - - have extensive documentation which is well controlled
      - expect the documented detail of the tests
- - - - The coverage measures for specification-based techniques would apply at whichever test level the technique has been used
      - Coverage can be measured at componenttesting level, integration-testing level or at system- or acceptance-testing levels
        
        At component level, measure coverage of the code is working as intended, before integration happens with previously tested code
        
        At system or acceptance level, the coverage items may be requirements, menu options, screens, or typical business transactions
        
        At integration level, we could measure coverage of interfaces or specific interactions that have been tested
    - - Identify whether or not each of those things has been tested by some test
      - Measures in some specific way the amount of testing performed by a set of tests
      - Drawback: measures coverage of what has been written, cannot say anything about the software that has not been written
      - -
        
        Number of coverage items exercised Coverage = ------------------------------- x 100% Total number of coverage items
        
        coverage item is whatever we have been able to count and seewhether a test has exercised or used this item
        
        measure only one dimension of a multi-dimensional concept.
        
        100% coverage does not mean 100% tested!
    - - Additional test cases can be designed with the aim of exercising some or all of the structural elements not yet reached
      - New tests are then run through the instrumented code and a new coverage measure is calculated.
      - Repeated until the required coverage
        measure is achieved
    - - inserting instrumentation
        
        3.Instrument the code
        
        4.Run the tests for which coverage measurement is required.
        
        5.Using the output from the instrumentation, determine the percentage of elements or items exercised.
        
        Count the structural elements or items.
        
        Decide on the structural element to be used, i.e. the coverage items to be counted.
      - Requires tool support(For most practical purposes)
  - - - Advantages
        
        Verify what the written source code is expected to execute and not to
        
        Applied directly to the object code and requires no source code handling.
      - Defect:
        
        Includes only the "true" conditions of the source code.
        +don't care with logical operators
  - - - Check every possible path or branch in the code under test.
        
        Advantages:
        
        +It includes both true and false conditions that are unlikely to be called for the statement
        
        +Make sure all branches are tested
        
        Defect
        
        Omits branches in Boolean expressions that occur due to short-circuit operators
  - - - Advantages:
        
        The check range is high as it includes all statements and branches in the code
      - Defect
        
        Sometimes paths cannot be performed due to the data relationship
        
        waste of time
- - - - Static testing techniques can be used to 'test' anything
    - - Tool-supported type of static testing
  - - - Structure-Based(White-Box)
        
        Decision
        
        Statement
        
        Condition
        
        Multiple Condition
      - Speccification-Based
        (Black-Box)
        
        Equavalence Partitioning
        
        Boundary Value
        
        Decision Tables
        
        State transition
        
        Usecase testing
      - Experience-Based
        
        Error Guessing
        
        Exploratory Testing
    - - Technical Review
      - Walkthoughs
      - Inspection
      - Informal Reviews
      - Static Analysis
        
        Data Flow
        
        Control Flow
  - - - Non-Funtional
        
        Concerned with examining how well the system does something, rather than what it does
        
        include performance, usability, portability, maintainability, etc
      - Funtional
        
        Concerned with what the system does, its features or functions
  - - - Since they require knowledge of how the software is implemented, that is, how it works