0% found this document useful (0 votes)
58 views5 pages

Random Testing Hands On

Random testing cs362

Uploaded by

christran751
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
58 views5 pages

Random Testing Hands On

Random testing cs362

Uploaded by

christran751
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

Week 5 – Random Testing

For this document, you will need to fill out the information below. Ensure you have 5 triggering
numbers for each bug or you will receive zero points for the bug. Your theory must fit the 5
provided numbers to receive any points. To receive full points, your theory must match the
actual coded error, so you may need more than 5 data points for each bug to successfully
determine the causes. We have provided four specific aspects of test cases you will need to
correctly identify (prefix, length, checkbit status, and other).
 Bug 1
o Triggering credit card numbers (at least 5)
 974653455490046
 006073740607843
 666356458248023
 176497850103133
 219836376552161
o Theory that explains what triggered the bug
 Prefix: Must start with unknown prefixes (not starting with 4, 34, 37, 51–
55, or 2221–2720), but with 0’s, 1’s, 9’s, etc.
 Length: Must have 15 digits
 Checkbit status: invalid
 Other: For Bug 1, it seems that the function will incorrectly accept credit
cards with unknown prefixes (not starting with 4, 34, 37, 51–55, or 2221–
2720) for any length of 15 and has an invalid checksum. This
demonstrates that the function, for some reason, does not check for prefix
ranges and the Luhn checksum correctly, if the credit card number length
is 15.

 Bug 2
o Triggering credit card numbers (at least 5)
 4049336088587434
 4046316863306146
 4046556492629059
 4043819613502040
 4040565378217877
o Theory that explains what triggered the bug
 Prefix: Must start with 404
 Length: Must have 16 digits
 Checkbit status: valid
 Other: For Bug 2, it seems the function will incorrectly counts the prefix
404 as a valid Visa if both the length and Luhn checksum are valid. It
somehow considers 404 as a valid prefix for Visa, when it should just be a
4. In other words, number that starts with 404 – that has both a valid Visa
length of 16, and valid Luhn checksum will pass, but a card that starts
with just a 4 - will not (when it should also pass)
 Bug 3
o Triggering credit card numbers (at least 5)
 16553075301357
 45835347643311357
 3003937784601357
 3461283534411357
 4431253031873579
o Theory that explains what triggered the bug
 Prefix: Can start with any number. Can either be known prefixes 4, 34,
37, 51–55, or 2221–2720) or unknown (i.e., 0, 1, 8, etc) i.e., can start with
any number
 Length: Accept any card length with digits ranging from 14 to 17.
 Checkbit status: both valid and invalid
 Other: For Bug 3, it seems like the function does not strictly check
prefixes and Luhn checksum. Perhaps, it accepts any card number, as
long as it has a length between 14 and 17; regardless of whether the
number itself has a valid known card prefix or if it has a valid checksum or
not. In other words, if the number is within the range 14 through 17, then
it will incorrectly accept it as valid when it should not, even if the prefix
and/or Luhn checksum is invalid.
 Bug 4
o Triggering credit card numbers (at least 5)
 340264713282734
 821097996434182
 489765409231848
 533756298783153
 22348041584802
o Theory that explains what triggered the bug
 Prefix: Can start with any number. Either start with a known prefixes (4,
34, 37, 51–55, or 2221–2720) or an unknown (i.e., 0, 1, 8, etc) i.e., can
start with any number
 Length: Must have 15 digits
 Checkbit status: both invalid and valid
 Other: Bug 4 probably occurred because the function seems to accept
any credit card number with length 15 as valid without also validating the
specific card type (i.e., prefix), nor does it check the Luhn checksum.
 Bug 5
o Triggering credit card numbers (at least 5)
 2708657749850119
 344286579346545
 4386573726542931
 5386578149548917
 2229286579327913
 377183093686573
o Theory that explains what triggered the bug
 Prefix: Must start with a known prefixes (4, 34, 37, 51–55, or 2221–2720)
Length: Must have 15 or 16 digits.
 Checkbit status: Must be valid.
 Other: It seems that all of the following (prefix, length, and Luhn
checksum) are valid for the cards that triggered Bug 5, i.e., a valid visa
prefix with correct length and valid Luhn checksum is somehow triggering
a bug. Perhaps Bug 5 is that these card numbers should have been
accepted, but somehow the bug is that they are incorrectly rejected. So,
the bug here is that these cards were wrongly rejected by the code.
 Bug 6
o Triggering credit card numbers (at least 5)
 5533471839752258
 2533459269314258
 4975998064458258
 349969366092258
 374247518212258
o Theory that explains what triggered the bug
 Prefix: Must start with a known prefix (4, 34, 37, 51–55, or 2221–2720)
Length: Must have 15 or 16 digits
 Checkbit status: valid
 Other: The function incorrectly rejected this card even though it should
have been accepted. The bug here is that it's probably rejecting cards
that meet all the correct criteria, i.e., reject a valid visa card that starts
with 4, has the exact length of 16, and has a valid Luhn checksum.
 Bug 7
o Triggering credit card numbers (at least 5)
 5302740369
 5542697574818
 46699181663211401881
 5368255849
 225797822565522997871
 26985336843145063
o Theory that explains what triggered the bug
 Prefix: Must either start with a valid Visa prefix (4) or a valid Master Card
prefix (51 - 55) or (2221 - 2720 )
 Length: no specific length triggers bug
 Checkbit status: valid
 Other: The function is incorrectly accepting card numbers that do not
match any valid prefix-length pair. Probably because the function seems
to be accepting numbers with either prefix from Visa or Mastercard prefix
that has a passing Luhn checksum, but does not seem to be validating
the length to see if it matches. For example, a card number like
225797822565522997871 starts with a valid Master Card prefix, but has
21 digits, when it should only be 16 digits. Also it is important to note that
none of the AMEX prefix seems to be presented in the bug, probably
indicating that the function is somehow correctly enforcing length for
AMEX (15 digits), but not for Visa or MasterCard
 Bug 8
o Triggering credit card numbers (at least 5)
 0128266886640584
 2445389449832260
 3445129889287900
 4740438668355216
 5990818778161568
 7120571221704606
o Theory that explains what triggered the bug
 Prefix: Can start with any number. Can either be known prefixes 4, 34,
37, 51–55, or 2221–2720) or unknown (i.e., 0, 1, 8, etc), i.e., can start
with any number
 Length: Must have 16 digits
 Checkbit status: both valid and invalid
 Other: Bug 8 seems to occur because the function is probably accepting
any card with length exactly 16 as valid, without also checking to see if it
matches any known prefix or if the Luhn checksum is valid. For example,
looking at 7120571221704606, the number 7 does not belong to any
known prefix, and its Luhn checksum is invalid. But it seems to have
triggered a bug, so that suggests that maybe the function is incorrectly
accepting that number as a valid credit card.

You might also like