Since I explicitly stated “Using only the characters ‘A’ – ‘Z’…for a filename with an 8-letter filename and a 3-letter extension…” then you are not making an assumption. I intentionally limited the initial domain space as an introductory example using information I thought most readers would be familiar with (and I assumed readers would tacitly understand the number of characters and filename/extension lengths is far greater on modern operating systems). The problem space is actually much larger when taking into consideration variable filename and extension lengths, and the Unicode character repertoire as explained above and in the article.

So, within these constraints I used 268 + 263 because the base filename and the filename extension are 2 separate components and are handled differently by the Windows operating system file system. (Note that I also explicitly stated the testing would be conducted on a “Windows platform.”)

If for some reason we suspected there is interaction or no distinction between the filename component and the extension component (as on a Unix platform) then we would have to test each unique 8-letter filename with each unique 3-letter extension which would equal 2611.

However, since I stated the test environment is Windows, our in-depth system knowledge of the Windows OS file system tells us the extension is handled as a separate namespace or component from the base filename component. (For example, we cannot save a filename as CON.txt, but we can save a filename as myFile.CON.) Thus, we know that the base filename component and the extension component of the filename are independent, so testing all combinations on a Windows OS would result in approximately 3,670,135,659,905,624 redundant tests (if we could do exhaustive testing).

One could argue that with nominal valid data we could combine the 17576 (263) unique 3-character extension combinations with combinations of the 8 character base filename components to effectively reduce the overall number of tests.

However, I choose to separate testing the extensions and test each extension combination as a unique component independent of the base filename component. So, by using a nominal (known good) base filename component, we would simply add the additonal 17576 tests for each unique 3-letter extension combination. (Thus, 268 + 263.)

(But, I can understand how someone could misconstrue my statement “…the total number of possible character combinations…” when taken out of context from the rest of the paragraph, and that sentence could have been worded more precisely to stand on its own.)

ADDENDUM:

(Of course, the math experts will immediately realize that 268 + 263 does not equal 208,827,099,728. It actually equals 208,827,082,152. It seems that somebody’s fingers got a little happy with the M+ button on the calculator when running the initial numbers.

But, the purpose of the article is to examine the use and value of intelligent random test data in testing; not to debate or over-analyze the number of filename combinations on Windows or Unix platforms. So, I hope the readers understand the point that the number of combinations is quite large (+/- 17576) and utilizing intelligent random data (for positive or negative testing) in conjunction with ‘real-world’ and known problematic static data is a good way to add variablity to a test and expand coverage of potential possibilities since we know we cannot test all probable combinations for a given platform.)

Thursday, May 31, 2007 5:24 AM by I.M.Testy

As I believe you are, I’m assuming that the filenames must be exactly eight alpha uppercase characters, and the extension must be exactly three uppercase alpha characters. That would be 3,670,344,486,987,776 combinations, not 208,827,099,728.

—Michael B.

Thursday, May 31, 2007 12:30 AM by Michael A Bolton