2.3 Flashcards
1
Q
input validation
A
checking data input by the user meets criteria
2
Q
types of input validation
A
- type check, e.g. integer, real, string
- range check, e.g. blank inputs
- presence check, e.g. reject blank inputs
- format check, e.g. postcode
- length check, e.g. password
3
Q
advantages of input validation
A
- a programmer can make their program more robust, user friendly
4
Q
types errors that can occur in code
A
anticipation misuse
communication error
printer error
disks error
5
Q
anticipating misuse
A
- e.g. dividing a number by 0
- the ALU cannot compute said division
- a programmer should always check that a variable is not 0 before attempting a division
6
Q
communication error
A
- online systems require connections to host servers
- if this connection is dropped, unable to be established or the server is overloaded, it can cause the program to crash or hang when loading data
7
Q
printer error
A
- if a program outputs a hardcopy, the printer may run out of ink or jam
- the programmer should not assume that an output to a printer was successful and always have options to reprint reports o receipts
8
Q
disk errors
A
- programs that read and write to files need to handle many types of exceptions including:
the file/folder not being found
the disk being out of space
the data in the file being corrupt
the end of the file being reached
9
Q
authentication
A
- e.g using passwords to access systems
10
Q
dangers of not encrypting of data files and how to protect against it
A
- online bots can submit data automatically to online forms
- this can be protected against using software such as recaptcha that verifies if the user is human
11
Q
how to maintain code
A
- use comments to separate code
- use comments to explain parts of code
- indentation of code
- use procedures and functions
12
Q
reasons for testing code
A
- to ensure there are no errors in code
- check that the program has good performance
- ensure that unauthorised access is prevented
- check the program meets the requirements
13
Q
iterative testing
A
- each new module is tested as it is written
- program branches are checked for functionality
- checking new modules do not introduce new errors in existing code
14
Q
final testing
A
- testing that all modules work together
- testing the program produces the requires results with normal, boundary, invalid and erroneous data
- checking the program meets the requirements with real data
15
Q
syntax error
A
the rules of the language have been broken
16
Q
types of data test inputs
A
normal inputs
boundary inputs
invalid inputs
erroneous inputs
17
Q
normal inputs
A
- data which should be accepted by a program without causing errors
18
Q
boundary inputs
A
- data of the correct type which is on the edge of accepted validation boundaries
19
Q
invalid inputs
A
- data of the correct type but outside accepted validation checks
20
Q
erroneous inputs
A
- data of the incorrect type which should be rejected by a computer system
21
Q
ways to make an algorithm more robust
A
- writing code which anticipates a range of possible inputs
- those inputs could be invalid data or erroneous
- making sure “bad” data does not crash the program
- making sure prompts to the user are descriptive and helpful
