It's not necessarily important to test for all possible values for an individual method. As in the example of gold standard tests, you certainly don't want to run the application with all possible values in order to write tests for each of the possibilities. It is far more important to test for every path of execution.

If a method is small enough and its potential outcomes limited in scope, it should be quite trivial to write a handful of tests to cover all potential scenarios. Take the following method as an example:

public int GetPercent(int current, int maximum)
{
  if (maximum == 0)
  {
    throw new DivideByZeroException();
  }

  return (int) ((double) current / maximum * 100);
}

What are the potential paths through this method? What tests might you write to ensure adequate coverage?

First, you might consider writing a test in the case that the maximum input parameter is equal to 0. This should cover the DivideByZeroException in this scenario.

Next, you might write a test where the current parameter is 0, ensuring that the result of this method is always zero, assuming maximum is non-zero.  

Finally, you would want to write one or more tests to validate that the algorithm above is indeed calculating the percentage correctly, based on inputs.

At this point, it may be tempting to add tests for things like negative values or to check the rounding that C# is doing, but remember that we are working with legacy code and, as far as the business is concerned, this code is working as is. You don't have a record of the business requirements that spawned this code, so it would be unnecessary, and possibly irresponsible, to test more than what this code is telling you. So, if you believe the code is flawed in that it doesn't cover certain business criteria, or that it could produce incorrect values, discuss these things with your business and make a determination together. Any change to the code would have to be through either a bug or new work.