You certainly could write a procedural-generated test harness, where you generate a graph of user actions, then send them to the system. I've done that before

You certainly could write a procedural-generated test harness, where you generate a graph of user actions, then send them to the system. I've done that before for integration testing of user-generated event pathways. But my main concern was for accuracy and load testing, so at the end of the test, I would query the database and check the report against what the test case sent. The problem with this approach is that it results in "wobbly" tests, that is, tests that fail non-deterministically. These are really annoying and will quickly cause developers to ignore test failures. So I don't like them as part of a standard testing suite. It sounds like you may want to put more boundaries in your application. Rather than testing out all possible combinations, reduce the available combinations and test their enforcement. I think you're best starting point is to place hard limits on input and test up to those limits. For example, define the maximum length of inputs, allowable character sets, numeric ranges, etc, then write test cases to ensure those limitations are enforced. It's difficult to know what the next step would be without knowing your tech stack or your goal. Why do you want test various permutations of user input? Is there some cause for concern if a user performs Action B, then Action A instead of the predefined Action A, then Action B? If that's the case, you should encode these paths into your software and have test cases to check them. It sounds to me like you're looking for a magic bullet to get comprehensive testing without writing comprehensive tests. That's not really possible. You have to test what's important, then rely on logical implication for the rest. Sprinkle in good logging and error handling for the inevitable hiccup, and monitor the logs for improvements.