Don't expect stress testing to be a silver bullet.
For example, it probably won't find out that your main solution is too slow
because your alternative solution will probably be even slower,
some brute force solution.
And you will have to generate only small random tests to compare them.
In other cases, integer overflow.
Even if you generate random tests with big numbers,
both of your solutions could potentially have integer overflow problems.
And then you will not notice that your main solution has them in the stress test.
So first, test for those cases, and then apply stress testing.
However, if you've done manual tests, integer overflow testing, and max test, and
then apply stress testing, you're almost guaranteed to have success with it.
Because the authors of the problem do basically the same when they
make the test sets for you.
They make some manual tests, they make tests with big numbers for
integer flow, they make big tests for checking time limit, and
then they generate some random tests and maybe some focused random tests.
But that's all.
So, you will probably find all the traps they've set up for you with just testing.
In conclusion, know that it is very important to write programs that work on
all of the allowed test cases, not just on most of the allowed test cases.
In practice, if you write programs with bugs that only rarely reveal themselves,
still some of your users will encounter those bugs, and
their experience will deteriorate significantly.
Also, sometimes in the start of a project, you want to test some hypothesis and
you write some code to check it.
Then you get some results and base your decisions on that result.
Only to later learn that you had a bug in the code and
all your decisions were wrong.
That's why we've prepared thorough test suites to check all the aspects of your problems.
And here, stress testing will be very helpful when your solution fails on some
test and you don't even know what is the test on which your program fails.
We hide the tests on purpose.
In real life, you often also won't know what are the exact conditions
under which your program fails.
But now, you are fully prepared to test your programs, debug them, and fix them.