> Any part of your software that consumes data across a trust boundary is a perfect candidate for fuzzing.<p>Sure, but one thing I don't understand is why fuzzing is not used more often for testing basically any pure function (whose output depends only on its input, and which has no side effects, or whose side effects are easy enough to rollback during fuzzing).<p>This is the method: take multiple distinct implementations of the same function/algorithm and give them all the same data. Usually, you'd just be checking for them crashing or tripping up some sanitizer; but now you can check if each implementation's <i>output</i> matches the outputs of all the other implementations, and crash if any of the outputs doesn't match (can be accomplished with <i>__builtin_trap();</i> in C/C++). The fuzzer will register this crash like any other failure, and then you know you have a bug, and with which input the bug manifests.<p>> Current fuzzing tools (open source or otherwise), aren’t very developer friendly, often forcing users to learn completely new testing paradigms, work with low-level structures they don’t understand, and significantly modify their application to get any results at all.<p>This list of issues seems sort of manufactured, and I doubt this FuzzBuzz product can improve the situation, as the article doesn't give any information on what the product actually is.<p>> Fuzzbuzz uses automation and intelligence to make fuzz testing as developer friendly as possible [...]<p>Advertising a product without saying anything about it is off-putting to me. I know it works sometimes, but I think that's usually when you're "big" already, like Coca Cola.
I wrote a rudimentary fuzzer at work for the sole purpose of generating core dumps. It worked so well that I got a stern talking to about not helping them release the software.
At simplest and most straight forward level fuzz testing is pretty simple to get started with. Collect some input(API calls, files, etc.), pass it to fuzzer(for example radamsa[0]), throw it at program and observe...<p>Ofc, depending on system collecting input and sending it to system might be bit more complicated. Hardest part is often the observing and finding that an error happens.<p>Not that this gets you full coverage, for more complex things like protocols something custom that takes lot more effort is probably needed.<p>[0] <a href="https://gitlab.com/akihe/radamsa" rel="nofollow">https://gitlab.com/akihe/radamsa</a>
Nice article. In a way you could think of the following as "concurrency fuzzing":
[0]: <a href="https://news.ycombinator.com/item?id=26718273" rel="nofollow">https://news.ycombinator.com/item?id=26718273</a>