Testing

Testing

purpose - looking for possible presence of errors
VALIDATION- does the system do what the users want?
1. concerns the software product
2. Dynamic testing
VERFICIATION - are we following the design process?
1. Ensure componenet or system is working to its spec
2. Doesnt ensure correctness
3. Uses static and dynamic
Types of testing
1. Modelling
2. Module integration and acceptance (validation) testing
3. static
  1. modelling
    1. investigate behaviour of an appropriate system model
    2. applied in the early stges of SDLC
    3. example tools - UML
  2. reviews
  3. inspection
    1. step by step reading of software checked against 'check-list'
    2. techniques
      1. Boundary value analysis (BVA)
        to remove software errors occuring at parameter limits or boundaries
      2. Control flow analysis
        to detect poor and potentially incorrect program structures
      3. Program code analysis
      4. trace table
        trace through program statements
      5. symoblic execustion
        input variables of a program are assigned symbolic values rather than literal values
        to show the agreement between source code and its spec
      6. McCabe cyclomatic complexity
        software metric that provides quantitative measure of the logical complexity of a program
  4. walkthroughs
    1. review of deliverables/products at the end of a life cycle stage
    2. scrum meetings
      1. short daily meetings for discussions
  5. scenario (use case) testing
    1. generally black box
  6. control flow testing
4. dynamic
  1. the program under test must be executable
  2. the test case - the input data to run the program/ the expected output
  3. The observation - the aspects of behaviour/means of observation
  4. the analysis of results - the correctness of behaviour / adequacy
  5. Black box dynamic testing techniques
    1. Functional testing
      1. specific test cases defined to test each aspect using a BB approach
    2. Boundary value
      1. tests performated at extremes of each input and output range
    3. Equivalence partitioning
      1. group sets of input and output ranges that can be treated in the same way
    4. performance testing
      1. examines the system behaviour in terms of resource utilisation.
    5. random testing
      1. functional or structural testing of random sample of tests or input vectors
    6. error seeding
      1. introduce error, as a check on the testing process
    7. error guessing
      1. predict error conditions where test cases based on possible operations/situations
  6. White box dynamic testing
    1. Statement coverage
      1. aim - to create enough tests to ensure every statement is executed at least once
    2. decision coverage
      1. aim - generate tests to execute each decision statement branch and module exit path
    3. structural analysis (every control path)
      1. tests the complete program's structure. Attempts to exercise every entry to exit control path
    4. data value analysis
      1. indentify numerical problems: entry of incorrect data type, overflow etc
Levels of testing
1. Blackbox testing
  1. - Test against the system functional spec
  2. Can reveal errors in design
  3. Generally less complex and costly
  4. test coverage related to req and exceptions tested. related to behabiour hot code structure
  5. used to confirm external spec
2. White box testing
  1. Considers the internal code structure
  2. can be complex or impractical for some programs
  3. has limited capability in detecting req and design errors
  4. Performs test adequacy, eg. by code path coverage
3. Coverage
4. Test adequacy
  1. Non functional req describing how thourough tests should be
  2. complete testing usually impossible
  3. used to specify
    1. when to stop testing
    2. a measure of testing
    3. how to generate test values
      1. spec based - black box
      2. program based - white box
    4. measure testing progress
  4. Techniques
    1. test coverage measurement. eg. lines, branch or path
    2. Fault seeding
    3. Scenario testing
Basis of testing is the TEST PLAN
1. details of the part of system being tested , objectives of testing
2. general testing strategy
3. hardware and software dependencies
4. date, location and individuals undertaking the testing
5. for each test include
  1. details and purpose of test
  2. Test data input and expected output
  3. How the test data is prepared and submitted to the system
  4. How the outputs are to be captured
  5. How the results will be analysed
6. the test plan forms an integral part of the SLC design process
7. Record of testing
8. doc layout
  1. intro - summary from req spec
  2. reqs identification - taken from req spec. identifies what to be tested
  3. test plan / procedures.
  4. test results
  5. traceability matric - relate each req scenario to the test result evidence
Testability Principles
1. Operability
  1. The better it works, the more efficiently it can be tested
2. observability
  1. what you see it what you test
3. controlability
  1. the better we can control the software the more testing can be automated
4. Decomposability
  1. by controlling the scope of testing. can more quickly isolate problems
5. simplicity
  1. the less there is to test the more quick itll be done
6. stability
  1. the fewer the changes the fewer disruptions to testing
7. understandability
  1. the more info we have the smarter we will test

Next up

Description

Resource summary

Similar

	Created by emma.stew almost 11 years ago