First, you notice that the stress test magically gave us the test in which our main solution and alternative solution differed very quickly. But that's not always the case.
 Often, the cases when there are equal numbers are some kinds of corner cases.
 So, when you want to do stress testing and you cannot find quickly a test on which your main solution and alternative solution differ, try to generate tests in a more focused subspace of full possible tests.For example,if you are working with graphs, try generating a disconnected graph,a full graph, a bipartite graph.

 Another important point is that if you found a test in which your solutions differ,don't hurry to debug something. First try to generate the smallest and easiest test on which your solutions differ. This will simplify your debugging a lot.

 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 some manual 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.