Lets not shave a yak. It sounds as though you want to understand and get into fuzzing.
Sulley and Peach are fuzzers that have extensive capabilities that should help you. Also, writing your own fuzzer should help understanding the actual fuzzing process.
Here is a resource for a bunch of different fuzzers.
Ultimately, common sense aids in the fuzzing process. If the binary accepts files (and you're fuzzing file formats) on linux, having your testcases generated on the fly on a ramdisk helps. On windows you need specialized ramdisk software, of which SoftPerfect Ramdisk looks the be the most efficient. Ramdisks minimize disk I/O, so it speeds up fuzzing and lessens the wear&tear to your HDD.
Also, you need to take into account what the specification says, then disregard it with the utmost abandon! 010Editor helps as it is a hexeditor that has can parse known file formats.
For instance, you need to take into account your platform's integer limits, whether windows or linux. Also, most source code has its own defined integer limits, so where does it differ from the platform (u)int limits? Also, some software parses strings. Does it accept null bytes? In which situations? If you're black-box fuzzing (no source available) what happens if you pass a (u)int that is equal to the platform limits defined?
If you start fuzzing from scratch (like I did) you'll be that much closer to more effectively finding bugs than your peers.