2.3 Producing robust programs Flashcards
Methods of anticipating misuse
-input validation
-division by 0
-communication error
-printer and other peripheral errors
-disk errors
Anticipating misuse - input validation
-checking data input by the user meets specific criteria/ rules before processing
-makes the program more robust, user friendly, prevents further errors occurring later in the algorithm
-does checks:
type - correct data (integer, real, string)
range - correct range (1-2)
presence - data has been entered
format - correct format (dd.mm.yyyy)
length - correct number of characters (pw)
Anticipating misuse - division by 0
-ALU cannot compute a division by 0 - could crash a program
-a programmer should always check that a variable is not zero before attempting a division by it
Anticipating misuse - communication error
-if connection is dropped, potentially causes a program to crash when loading/ saving data
-programmer should enable ways for the user to cancel requests
Anticipating misuse - printer & other peripheral errors
-if a program outputs a hardcopy, the printer may run out of paper, ink, have a jam
-programmer should not assume that the output to a printer was successful and always have options to reprint
Anticipating misuse - disk errors
-Programs that read and write files need to handle many exceptions
-file/ folder not found
-disk out of space
-data in the file is corrupt
-the end of the file being reached
-robust programs will handle all these situations by checking files and data before attempting to use them for further processing
Anticipating misuse - authentication
-Usernames passwords to access systems
-recovering a password requires clicking on a link within the email that is sent to the registered address
-encryption
-reCAPTCHA
Anticipating misuse - maintainability
-use comments - explains purpose of the program, unusual approaches that were necessary, visually divide sections of a program
-indentation
-follow naming conventions -descriptive variable names
-use of subprograms -structure the code
Purpose of testing
-to ensure there are no errors in the code
-To check that the program has an acceptable performance and usability.
-To ensure that unauthorised access is prevented.
-To check the program meets the requirements.
-Iterative testing, final/ terminal testing, syntax error, logic error
Testing - iterative testing
-Each new module is tested as it is written.
-Program branches are checked for functionality.
-Checking new modules so new errors are not introduced to existing code.
-Tests to ensure the program handles erroneous data and exceptional situations.
Testing - final/ terminal testing
-Testing that all modules work together (integration testing)
-Testing the program produces the require results with normal, boundary, invalid and erroneous data.
-Checking the program meet the requirements with real data.
-A beta test may find more errors.
Testing - syntax error
-The rules of the language have been broken.
-The program will not run (compiled languages).
-Syntax errors can happen because:
-Variables are not declared or initialised before use.
-Incompatibility of variables types e.g. total = “A” (total declared as an integer)
-Using assignments incorrectly e.g. 2+2 = x
-Keywords misspelt e.g. prnt(“Enter choice: ”)
Testing - logic error
-The program runs but does not give expected output.
-Logic errors can happen because:
-Conditions and arithmetic operations are wrong.
-Sequence of commands is wrong.
-Division by zero.
-Exceptions e.g. file not found.
Types of suitable test data inputs
-normal inputs
-boundary inputs
-invalid inputs
-erroneous inputs
Suitable test data - normal inputs
Data which should be accepted by a program without causing errors.
