Hrm. Maybe I was mistaken… I thought fuzzing referred to altering a set of test cases regardless of random versus predicted. I am unsure if my concept would work 100 % but I was thinking more of a deliberate prioritized set of changes rather than random changes.
Why, you might ask? That’s a good question. 
To help facilitate the reproducibility factor. Without being able to reproduce the issue, it gets harder to troubleshoot. Of course things like logs, output, etc. help; but nothing seems to help more than reproducing so that one could just step through the code to the troubled point. Random makes it harder to track down.
Come to think of it, you could put in an AI or at least a metric system to try to understand the risk areas better by placing some sort of weight system in the lines/steps that caused issues.
Then you could see which area of code being touched would be risky via data.
Hrm. Not sure if it’s better on pen/paper than written down or if it is feasible.
hi,
The leading commercial, multi-protocol fuzzers use a combination of predicted versus random. Plus they will keep track of exactly which combination produced an unwanted result. I am most familiar with beSTORM (full disclosure – i work for Beyond Security) and can say with certainty that it will log faults along with the string that produced it, then continue testing for as long as you have time to let it run. The string is then available to QA and developers to confirm the weakness and then test repairs. Other commercial fuzzers may do this too.
Whoa. Cool, I wasn’t aware of that. I guess I need to read up on this now. Thanks for the info!