INFO1110 Lecture Notes - Lecture 7: White-Box Testing, Black-Box Testing, Software Design
24 Jul 2018
School
Department
Course
Professor
WEEKS 7 , 9B
Testing and
the software design process
Testing
• Untested software is unreliable. Testing increases the reliability of software.
• For critical software systems, testing is more significant than the code itself.
• Don’t rely on documentation.
• Compliation ≠ correctness.
• To test, we need to inspect contents of memory.
• Should also make mental model of the code.
• Need to test if computed values = expected values.
• Tests should be automated so they can be repeated.
Tracing
Going through code line by line and doing a desk check.
Testing
Given an input, check if the output matches the expected output.
Oracles
An oracle is some external “thing” that we can ask for the right answer.
We don’t always have an oracle, but when we do, we can test if our code’s answer is the same as the
orcale’s.
Test-driven development
A method of software development in which the tests for a given function are written first before
any coding is done. Lets you think about
• What the normal functionality should be
• What should happen given a bad input
Types of testing
Black box testing
The program is treated as a “black box” where you can’t see what it does exactly/what the code is.
All you’re concerned about is the input and the output.
• Anyone can do this, even non-programmers
White box testing
Can see what the code is and what the program does.
• Allows us to know what different kinds of input there are and all the different execution
paths.
Testing by printing
Printing a running log of what’s going on.
• The testing is part of the code, which isn’t ideal.
• Print statements have to be removed for deployment.
Regression testing
Every time changes are made to the code, re-run all previous tests.
This makes sure code that used to work still works.
Unit testing
Testing individual “units” or sections of code, usually specific functions.
Bad inputs, corner and edge cases, code coverage
Code should be able to handle bad inputs, e.g. negative number given to log function, -1 as array
index.
Edge case
One dimension of a problem is at an extreme, e.g. load on a bridge is max.
Corner case
Multiple dimensions of a problem are at extremes, e.g. max load & max wind on bridge.
Code coverage
The proportion of lines of code that has been tested.
Execution paths
A route through the flow of the program. e.g. A basic if/else statement has two execution paths.
Assertions, pre- and post-conditions
An assertion is a condition/Boolean expression written at some point in a program.
The program asserts what the program state should be at a certain point.
Assertions are designed to stop execution if the program state is unexpected.
import random
x = random.randrange(0, 5)
if x < 2:
x = 2
# at this point in the code, x is expected to be at least value 2
# in other words, it should not be less than 2
if x < 2:
# stop everything! something is seriously wrong
# more specifically, x should be in the range [2, 5)
Here, we assert that x >= 2.
Assertions in Python
Python handles assertions as exceptions, using the assert keyword.
def get_percentage( value, largest_value ):
return value / largest_value
percent = get_percentage( 13, 71 )
assert percent >= 0 and percent <= 1
Preconditions and postconditions
are assertions placed before and after some piece of code, respectively.
# Pre : x >= 0
y = math.sqrt(x)
# Post: y >= 0
If precondition is True => postcondition is True
Document Summary
W e e k s 7 , 9 b. Should also make mental model of the code. Going through code line by line and doing a desk check. Given an input, check if the output matches the expected output. An oracle is some external thing that we can ask for the right answer. We don"t always have an oracle, but when we do, we can test if our code"s answer is the same as the orcale"s. A method of software development in which the tests for a given function are written first before any coding is done. Lets you think about: what the normal functionality should be, what should happen given a bad input. The program is treated as a black box where you can"t see what it does exactly/what the code is. All you"re concerned about is the input and the output: anyone can do this, even non-programmers.
