Help
Options
Didn't know it?
click below
click below
Knew it?
click below
click below
Don't Know
Remaining cards (0)
Know
retry
shuffle
restart
0:00
Embed Code - If you would like this activity on your web page, copy the script below and paste it into your web page.
Normal Size Small Size show me how
Normal Size Small Size show me how
Robust programs
2.4
| Term | Definition |
|---|---|
| Defensive design | Anticipating and counter-acting misuse of the program Writing maintainable code Testing the program |
| Robust vs reliable | Robust - to handle unexpected inputs and data without becoming malicious Reliable - to work as intended under multiple conditions |
| Input sanitation | To remove unwanted characters of input data Helpful to prevent SQL attacks |
| Input validation | To check if any data inputted meets a certain criteria If rejected, the user should be informed and asked to try again |
| Input validation checks | Type - the type of the input Range - if the data is inside an allowed range Presence - if the required data has been input Format - if the data fits a set format Length - if the number of characters entered is inside a permitted range |
| Authentication | To check if a user should have access to the system - normally with a username and password They should only be able to see the data relevant to them and no one else |
| Contingency planning | Providing helpful prompt messages and error-recovery routes Preventing access to certain parts of the system Using exception handling |
| Handling exceptions | Using “try…except…” if an exception is thrown into the try block, it will proceed into the except block. This way errors via exceptions can be caught and handled instead of crashing the program |
| Maintainability | Identifier names - easy to read Code structure - easy to read Using parameters instead of global variables - prevents subroutines from changing data Indentation - easy to read Comments - clarifications |
| Syntax errors | Errors in how the code is written - the translater will fail |
| Logic errors | Errors in the logic - the output would not be what’s expected |
| Runtime errors | Errors while the program is running - reduced with testing |
| Testing | To make sure the program can work under good conditions and with errors from bad data |
| Debugging | finding the cause of the bug and fixing it |
| Terminal testing | Testing at the end of development - to see how the software preforms |
| Iterative testing | Testing during development - where results are fed back into the development process |
| Test plan | Done before development, covers all success criteria and detailing what should be tested and what the results should be |
| Test data types | Valid data - correct and of the right format Extreme data - correct but on the edge of the valid range Invalid data - not within the acceptable range or is an invalid format Null data - no data is entered Erroneous data - the wrong data type |
Created by:
That cool NAMe
Popular Computers sets