this is the second in a series of short
videos on problem solving with
programming this one we talk about errors and
testing while we're developing programs to solve problems and this is
important to think about this early in our our
process to solve these problems
because understanding the types of errors that can occur and how we're
going to test our program can help us develop better programs
so again this is just a quick review we
spoke last time about the types of
errors that can occur and
syntax syntactic errors or syntax errors
are found by the compiler
and again those are errors where you didn't follow the grammar rules of the
programming language just like
in an english class you don't maybe
didn't follow the grammar rules
and those are found by the compiler or
interpreter for the programming language with
usually error messages that are fairly descriptive on what syntax error you
made second type of errors are semantic
errors which are logic or formula
errors and those you will see we can
help identify using the test tables that
we developed today and also using a
debugger which we will also talk about
today so those are problems where your your
program is actually running it's giving some sort of output
but maybe it's not giving the correct output
finally thematic errors these are the
more difficult ones these are where you solve a problem you've tested it
but it actually is not solving the correct problem so you made some
incorrect assumptions when you first
started and you
even though your design and testing
followed with a program that worked it wasn't the right program
so we'll see how do we avoid these
thematic errors
we can if we review our test tables that
we're going to talk about today and our input process output design from
last week if you review that design and
testing with the user
whoever asked you to solve the problem
then you can identify
and make sure you're solving the right problem to start with instead of wasting
the time to do the program the
programming is hard but usually the
design and test tables are a little easier and you can review those with
your user so that's how we avoid thematic errors
so again with testing what we want to
make sure we do is we're going to write
the test plan before we write the
program
so when we start with doing the design
first of all our input process
output we're going to follow that up with a test plan which is going to test
various valid input cases and
the expected output for each one of those input cases
and so we you know for any problem
there's an infinite usually an infinite
number of inputs we can't test all of
them but we want to test at least one piece
of input for each condition
or implied output for the problem
and so we'll see an example we'll see
what that means so you know we want to kind of be careful
to make sure we test
the different possible options for the
different types of output for the problem
so here's an example we want to write a
program that's going to calculate the
average of three test scores
and then display a message whether the student's passing or failing
so failing is below 60 is passing
uh less than 70 but must be greater than
60 and marg oh so that's called marginal
passing between 60 and 70．
so we're gonna just display a message of
the below 60
that they're failing if they're between
60 and 70 marginal passing if it's above 70 no
error no message is displayed at all so
there's the problem so now again we talk about the inputs
we have three test scores that's the
only input
and then what we want to do is average
those so that's the calculation that's
the process part we're going to average those three test scores
and then the output is depending on that
average we're either going to output
failing if that average is below 60．
marginal passing if it's between 60 and
70 and if it's 70 or above there's actually
no no message display this doesn't
specifically ask for anything
so we can we do the input process output
it's also a good idea to talk about how we're going to test this
so first of all let's think about those inputs again the inputs are three test
scores test scores should be between zero and a
hundred test scores don't have to be whole
numbers you can actually have a you know 98 and a half is a test score
if the teacher grades with half so
they're real numbers between 0 and 100 that's
the valid test scores
so i want to figure out what might be some good ideas to test
for valid test scores between 0 and 100．
so again we look at the problem and see oh look there's
specific outputs for less than 60
and then between 60 and 70 and then
between 70 and 100 there should be no
output so that's kind of the three possible
outputs that are that the problem could
describe so we'll make sure we try a passing
student whose average is over 70．
a marginally passing student who's
average is between 60 and 70
and a failing student whose average is less than 60． so we're trying to three
possible things
sometimes it's good to test ones exactly right on the boundary so if we look back
at the problem
below 60 is failing so if they get
actually a 60 average that's actually marginal passing
and also less than 70 is marginal
passing actual equal to 70 is passing so
we should probably test those boundary
conditions too so that's how you can
kind of see you want to test all those different possible
valid inputs we also list here just for
uh kind of completion you know one
invalid data where we have you know an invalid
test score you know that's the kind of the end of
the test plan is we can list some
examples where invalid data and make sure our problem
handles the invalid data also and
for invalid data usually the program
will respond with you know something explaining that the
data is invalid we won't do any calculation
so again you can see we tested each of
the three valid ranges greater than 70
60 to 70 less than 60 it's also a good
idea to test those boundary conditions
actual equal to 60 and actually equal to
70 and we can also make sure we somehow
write down what are invalid inputs
now debugging is something that's going to help us with
semantic errors so by writing the test
table we can check to make sure our
program's working correctly and then if it's not working correctly
we use something called a debugger
to help us kind of step through statement by statement
and see what might be causing those
errors compared to our test table
so the the types of errors that might
occur we have some sort of conversion errors or
maybe we have calculation is incorrect
or maybe we're uh then we're not
displaying to the right number decimal places something like that
now what a debugger helps us do is it's
uh this is almost all programming languages
provided they allow you to set
break points so what that is when you
run your program instead of it just
running to completion it will stop at the break point and kind
of be in a suspended state
it's still running but it's waiting and
you can while it's waiting you can examine the current contents of
variables and determine if so far
everything's working correct you can kind of go step by step line by line and verify
that the calculations are correct as you go
you know i expect the output from this
statement to be this is that working
and with the break point set and
examining the variables on that statement
the values of those variables you can
see if it's working
debuggers also provide idea of stepping
which is when it hits the break point
again it stops and you can view things
but then you can also tell it let's just
run one more statement and then let me
check again so it runs one more statement and it stops again
and you can examine variables and then
you can step another statement
or you can just say continue all the way to the end of the program
so that's the idea of a debugger we'll see actually that in in class with the
specific environment that we're using
now one more thing i want to go back to the test plan again so you know again
this was the test plan we wrote for this problem
one good thing about a test plan is you
can actually use it again later what if someone later says oh
i'm changing my my cutoffs i want to
i want to have a special message if
someone's 95 or above
i want to tell them they're doing really well in the class so i'm adding
additional information to this problem
i want a new message if their average is
95 or above well good i can still reuse this test
table
to and add test cases for that 95 and
above and then when i change the program to
handle that additional
logic i have to still run through all
these test cases again to make sure i didn't mess up any of the
old logic so the test table is not just
used once the test plan
it's used once when you first develop
and you can reuse it again after you might potentially make some
changes to your program