Once
source code has been gen, s/w must be listed to
uncover (and correct) as many errors as possible
before delivery to the customer. The goal is to
design a set of test cases that have a high likelihood
of finding the errors. S/w testing technique give
systematic guidance for designing lists that (i)
exercise the internal
logic of s/w components (white
Box) (ii) exercise
the ip and op domains
of the prgm to uncover errors
in function, behavior, performance etc. In both
clases, the intent is to find the max. No. of
errors with main effort and tire.
Test
should the traceable to customer requirements.
Test planning should begin as soon as the requirement
model is complete.
Smaller programming errors contribute to many
more no of errors in s/w. So we must isolate the
problem component and then test it thoroughly.
Testing should begin in the small and then progress
lowered listing in the large.
Exhaustive testing is not possible. But we must
adequately cover prgm logic and ensure that all
in the component level design have been exercised.
GOOD
TEST
Good test has a high probability of finding an
error. For this, the tester must understand the
s/w and attempt to dev. a mental picture of how
the s/w might fail.
A good test is not redundant. Every test should
have different purpose. The testing time and resources
are limited. Hence there is no point in conducting
a test that has the same purpose as another test.
If there are a of lists with same intent, the
one that has the highest likelihood of finding
a whole class of errors should be used.
It is is recommended that each test should be
exe separately rather than containing a series
of lists into one list case.
Home
Test
should the traceable to customer requirements.