Java-Testing

• Terminology
  • Error
    • do something incorrectly
      • by omission疏忽，遗漏；省略；冗长
      • by commission委任
  • Fault
    • the appearance/form/manifestation(表示) of an error
      • exp
        • wrong requirement of project
        • wrong in design
        • wrong in code
      • often called bug
  • Failure
    • inability of the system to do what required
      • one fault -> many failure
      • may cause by poor testing
• Process
  • Validation
    • process increase confidence
    • technique
      • mathematical analysis
      • informal reasoning: done by other than developer
      • testing: execute to find where program fail
  • Debugging
    • process determine why program fail
  • Defensive Programming
    • process of write code to avoid bug and failure also increase validation
• Test case
  • set of input value
  • set of precondition
  • set of except output
• Test driver
  • create and check all test case and report any failure
  • executed after each time system change(input/code)
    • called regression testing
      • as comprehensive as possible
      • place test inside main function of specific test function/test class
      • keep rerun and check if it is still right
        • output must be easy to check
      • can read input from file
  • add test case whenever new situation added
  • exhaustive testing is impossible
• Level of Testing
  • Unit test: test on one component
  • Integration test: test a combine of many unit(class/component)
  • System test: test of whole system
• Approaches to Testing
  • human testing
    • people read code/document
    • applicable to all stage of development
    • not done by developer/done by developer after a period of time
    • done before system execute
    • structured work
      • developer lead a team go through each part of system been studied
      • all people try to develop faults
  • black box
    • test only input/output, ignore actual code
    • base on specification of what program should do
      • specific in precond, postcond, and contracts
      • need a precise specification what program should do
    • should written before code
    • techniques
      • outcome testing
        • be sure all path is invoked at least once to sure have right outcome
        • test the unit which change outcome when condition/input change, make sure get all possible outcome
        • test any specific case
        • aliasing: same object supplied for more than one argument
        • test all error situations
      • boundary-value testing
        • input of max, min, out-of-boundary,just inside boundary,specific value, min+1, max -1
        • for robust testing, try min-1,max+1
      • equivalence-class testing
        • test-case is designed to cover each path of program at least once
  • white box
    • test based on code
  • Object-oriented test
    • test particularity suited to system implement on an OO language
  • bottom-up testing
    • first test do not use other function
    • repeatedly, all function can only use part been fully tested
    • until whole system been tested
    • adv
      • develop working and tested subsystem
      • test all low-level modules
      • not need stubs
  • Top-down testing
    • do unit test of a function may be hard
    • do general testing
    • use stubs
      • a module simulates the real module
        • have same interface(all methods) of real object
        • for a accessor method, it return a constant
        • for mutator, it put a constant
        • use for check reasonableness of argument pass by user
        • check state of system to ensure its reasonable
    • first make system-level module and stub for each module
    • do system-level test
      • use stub test top-level module
    • repeat until all stub have been implemented
      • select a stub
      • fully implement the stub, develop a stub for each module
      • test stub just implemented with it using the new stubs for parts of it use
    • adv
      • difficult task of integration done early，and can also use interface in design stub to test module easily
      • one module used each time
      • early test of whole system and capacity, although output may be wrong
      • may use less test driver, although developer must test module in an context of its excepted use(must test non-excepted use)
  • choose test base development
    • use bottom-down for well-understanded program
    • use top-down for not clear program