3 ms·

None of the above methods are used for testing. You use boundary testing, branch testing, equivalence partitioning etc. Random data is not a good method of test

• jakevn 8y ago
  Except for the fact that it is exactly the method that has been used to discover a large number of critical bugs in the most popular OSS projects (including SQLite): http://lcamtuf.coredump.cx/afl/ http://lcamtuf.coredump.cx/afl/
  • Frizi 8y ago
    Fuzzing isn't really practical if all you do is just generate a totally random bit stream for input. There are many much more clever and robust strategies to hit as many edge cases as possible. Check AFL[1] for some details on generating smart random input files. You can also combine that with pretty advanced dynamic execution analysis to fuzz against unknown processor instruction sets, like in sandsifter[2]. [1]: http://lcamtuf.coredump.cx/afl/ http://lcamtuf.coredump.cx/afl/ [2]: https://github.com/xoreaxeaxeax/sandsifter https://github.com/xoreaxeaxeax/sandsifter
    • tptacek 8y ago
      On the contrary, for years, the most prolific fuzzers basically did just generate random bitstreams, and that technique will still find vulnerabilities in all the memory-unsafe software that hasn't been fished out by those same dumb fuzzers.
    • deleted 8y ago
      [deleted]
• paulie_a 8y ago
  Sorry, I strongly disagree. Random data with a few static arguments is an incredibly great way to test. Adding in some chaos finds bugs. "why did that test fail after 100 times...ohhhh" I try to only use random data when possible, less and smaller tests to write with a proper setup. End result: more bugs found. Random data is a great method of testing.