• comparison of the solution with the design specifications
• generating relevant test data for complex solutions
• comparison of actual with expected output
• levels of testing
– module
test that each module and subroutine functions correctly
use of drivers
– program
test that the overall program (including incorporated modules and subroutines) functions correctly
– system
test that the overall system (including all programs in the suite) functions correctly, including the interfaces between programs
acceptance testing
• the use of live test data to ensure that the testing environment accurately reflects the expected environment in which the new system will operate
– large file sizes
– mix of transaction types
– response times
– volume of data (load testing)
– effect of the new system on the existing systems in the environment into which it will be installed
Students learn to:
• differentiate between systems and program test data
• test their solution with the test data created at the design stage, comparing actual with expected output
• use drivers and/or stubs to test specific modules and subroutines before the rest of the code is developed
• recognise the importance of module testing before the module or subroutine is incorporated into the larger solution
• recognise that while an individual program or module may have been successfully tested, when it is incorporated into a larger system, problems may become apparent
https://github.com/AuroraCollegeSDD/12SDD_Course_Information_v2/wiki/9.2.4-Testing-and-evaluating-of-software-solutions#testing-the-software-solution
Students learn about:
• comparison of the solution with the design specifications • generating relevant test data for complex solutions • comparison of actual with expected output • levels of testing – module
Students learn to:
• differentiate between systems and program test data • test their solution with the test data created at the design stage, comparing actual with expected output • use drivers and/or stubs to test specific modules and subroutines before the rest of the code is developed • recognise the importance of module testing before the module or subroutine is incorporated into the larger solution • recognise that while an individual program or module may have been successfully tested, when it is incorporated into a larger system, problems may become apparent