3.2.6 - Testing and Running a Solution

AndrewZV
Mind Map by , created over 5 years ago

A Level Computing (F452) Mind Map on 3.2.6 - Testing and Running a Solution, created by AndrewZV on 04/02/2014.

33
1
0
Tags
AndrewZV
Created by AndrewZV over 5 years ago
Computing Hardware - CPU and Memory
ollietablet123
computer systems and programming quiz
Molly Batch
CPU and Memory
LunaLovegood
CHEMISTRY C1 6
x_clairey_x
med chem 2 final exam
lola_smily
A level Computing Quiz
Zacchaeus Snape
Computer Systems
lisawinkler10
Computer science quiz
Ryan Barton
OCR gcse computer science
Jodie Awthinre
Computing
Ben Leader
3.2.6 - Testing and Running a Solution
1 Errors
1.1 Syntax
1.1.1 Occurs when a statement has been written that breaks the rules of that programming language.
1.1.2 Common Syntax Errors:
1.1.2.1 Missing or extra punctuation.
1.1.2.2 Not enough arguments.
1.1.2.3 Missing part of a multi-line statement.
1.1.2.4 Using unrecognised identifiers.
1.1.2.5 Type mismatch.
1.2 Logical
1.2.1 Occurs because of a mistake in the algorithm that results in the program doing something other than what's expected to do.
1.2.2 Don't usually produce error messages.
1.2.2.1 Discovered because the computer is producing unexpected results.
1.2.3 Other common causes are:
1.2.3.1 Instructions in the wrong order.
1.2.3.2 Incorrect conditions for IF statements or Loops.
1.3 Run-time
1.3.1 Occurs due to an unexpected situation with the data being processed.
1.3.1.1 The program would otherwise work normally.
1.3.1.2 Generally occur when the computer attempts impossible arithmetic operations.
1.3.2 Other common causes are:
1.3.2.1 Overflow error
1.3.2.1.1 Uses a variable to store a value to large for it.
1.3.2.2 Stack overflow error
1.3.2.2.1 Program runs out of stack space to store operations.
1.3.2.3 Library error
1.3.2.3.1 Referring to an external library that does not exist.
1.3.3 Exception Handling
1.3.3.1 Handles errors that are unavoidable.
1.3.3.1.1 Reading from a file that has been deleted.
1.3.3.1.2 Dividing by zero.
2 Types of Testing
2.1 White Box
2.1.1 Tests the algorithm to make sure it functions as intended.
2.1.2 Focused on testing every path of execution through a program.
2.1.3 Path of execution is noted, so it can be compared with other runs.
2.2 Black Box
2.2.1 Inputs and Outputs
2.2.1.1 Not how the program works.
2.2.1.2 Test every possible input.
2.2.1.2.1 Are the results expected?
2.2.2 Three types of input data to consider:
2.2.2.1 Valid Data
2.2.2.1.1 Data you would expect to be input.
2.2.2.2 Invalid Data
2.2.2.2.1 Data which would generate an error message.
2.2.2.3 Borderline Data
2.2.2.3.1 Testing data at the boundaries between both cases.
2.3 Alpha and Beta
2.3.1 Carried out when the software is nearly complete.
2.3.2 Applies to commercial software being developed for external users.
2.3.3 Difference resides in the stages and the tester.
2.3.3.1 Alpha
2.3.3.1.1 Limited to be tested by internal employees and friends/family of the company.
2.3.3.1.2 Very early version of the software.
2.3.3.1.2.1 Normally full of bugs.
2.3.3.2 Beta
2.3.3.2.1 Opened up to a wider audience.
2.3.3.2.2 Almost in a finished state.
2.3.3.2.2.1 Normally test things such as load balancing.
2.4 Acceptance
2.4.1 Demonstrates to the end user that the software works correctly.
2.4.1.1 All desired features have been implemented.
2.4.2 Takes place after all development and testing is complete.
2.4.2.1 The software is ready to be handed to the end user.
2.4.3 Software is tested against all requirements.
2.4.3.1 Until the user accepts the software is what is originally requested.
3 Running Solutions
3.1 Dry Runs
3.1.1 Used to locate the cause and location of an error.
3.1.1.1 You go through the code manually executing and recording each line of code.
3.1.2 Use a trace table to keep track of all the variables.
3.2 Debugging Tools
3.2.1 Translator Diagnostics
3.2.1.1 Messages generated by the translator, while it's translating the source code into object code.
3.2.1.2 Often includes warnings where there might be a logic error.
3.2.2 Break Points and Stepping
3.2.2.1 Breakpoints mark lines of code, requesting the program stops running when it gets to that line.
3.2.3 Variable Checks
3.2.3.1 Programmer can request variables to be checked at any time in the program.
3.2.3.1.1 This allows the programmer to compare the value to what it should be at that time.
3.3 Installation Routine
3.3.1 Installing the program.
3.3.2 The routine does the following:
3.3.2.1 1. Checks if there is enough space.
3.3.2.2 2. Program copied to destination folder.
3.3.2.2.1 Data files are copied with it.
3.3.2.3 3. Library files are copied and registered.
3.3.2.4 4. Executable file will create shortcut.
3.3.2.5 5. Allow user to configure and customise installation.
3.3.2.6 6. Configuration saved in system registry.

Media attachments