我将拥有尽可能多的测试用例，以确保对系统的高度信任。
表格、规则、代码行等的数量实际上并不重要。
您应该进行适当的单元测试，以确保您的域对象和业务规则正确触发。您应该进行测试以确保您的查询正确执行（这是一个更难的）。
您甚至可能希望拥有通过软件的路径的测试用例。换句话说，点击这里，获取这个页面，点击那里，编辑一个字段，保存页面，返回......这种类型是最困难的，因为测试通常是记录并且在页面更改时必须重新记录（即: 添加或删除字段）。
一般来说，覆盖率比测试次数更多。您希望您的测试涵盖尽可能多的应用程序功能可行。请注意，我没有说可能。您可以使用测试用例覆盖整个应用程序（100%），但是对于每一个小的更改、错误修复等，您都必须重新编码这些测试。这是一个成熟的应用程序更需要的。对于较新的应用程序，您不希望以这种方式束缚您的开发人员和 QA 团队，因为他们会花费大量时间修复/更改单元测试...
对于任何系统，您都可以轻松地花费与开发系统本身一样多的时间来开发自动化测试。在某些情况下，甚至更多。
对于我们的团队，我们倾向于进行大量的单元测试。然而，为了测试通过系统的路径，我们仅在特定区域进入“维护”类型模式时才记录这些路径。这意味着我们预计该领域在很长一段时间内几乎不会发生变化，而路径测试只是为了确保没有人顶起它。
更新：这里的 cmets 将我带到了以下内容：
再进一步：让我们检查一小段代码：
Int32 AddNumbers(Int32 a, Int32 b) {
return a+b;
}
从表面上看，您只需一次测试即可逃脱：
Int32 result = AddNumbers(1,2);
Assert.Equals(result, 3);
但是，这可能还不够。如果你这样做会发生什么：
Int32 result = AddNumbers(Int32.MaxValue, 1);
Assert.Equals(result, (Int32.MaxValue+1));
现在我们失败了。这是另一个：
Int32 result = AddNumbers(Int32.MinValue, -1);
Assert.Equals(result, (Int32.MinValue-1));
所以，我们有一个非常简单的方法，至少需要 3 次测试。初始看它是否可以给出任何结果，然后 2 进行边界检查。基本上是两行代码（方法定义和一行计算）的 3 次测试。
随着您的代码变得越来越复杂，事情变得非常危险：
Decimal DivideThis(Decimal a, Decimal b) {
result = Decimal.Divide(a,b);
}
这个微小的变化引入了另一个超出范围的异常条件：DivideByZero。所以现在我们最多需要 2 行代码进行 4 次测试。
现在，让我们稍微简化一下：
String AppendData(String data, String toAppend) {
return String.Format("{0}{1}", data, toAppend);
}
我们这里的测试用例是：
String result = AppendData("Hello", "World");
Assert.Equals(result, "HelloWorld");
这只是代码块的一个测试用例，不需要其他的。
这告诉我们什么：对于初学者来说，2 行代码可能会导致我们需要 1 到 4 个测试用例。您提到了 50,000 行...使用该逻辑，您将需要 50,000 到 200,000 个测试用例...
当然，生活很少如此简单。在你拥有的 50k 行代码中，将有大量输入非常有限的代码块。例如，抵押贷款利息计算器可能采用 3 个参数，并返回 1 个值（APR）。代码本身可能会运行 100 行左右（已经有一段时间了，请与我一起工作）。测试用例的数量将由边缘用例确定，以确保正确处理舍入。
所以，假设它是 5 个案例：这使我们得到 20 行代码 = 1 个案例。计算出 50k 行可能会产生 2,500 个测试用例。显然比我们上面预期的要小得多。
最后，我要再添一个皱纹。一些测试系统可以处理来自数据文件的输入和断言。考虑到我们的第一个，我们可以有一个数据文件，其中包含我们要测试的每个参数组合的一行。在这种情况下，我们只需要 1 个测试用例即可涵盖 3 个（或更多..）可能的条件。
测试用例可能看起来像（伪代码）：
read input file.
parse expected result, parameter 1, parameter 2
run method
assert method result = parsed result
repeat for each line of the file
借助该功能，我们可以将每个场景减少到 1 个测试用例。我会说每个方法 1 个，但现实情况是大多数方法很少是独立的，并且完全有可能通过对其他方法的显式测试来隐式测试许多方法；因此不需要他们自己的单独测试。
这使我想到：如果不完全了解您的代码库，就不可能确定正确的测试用例数量。根据测试的复杂性，5 个 UI 级别的案例可能足以完全覆盖；或者可能需要数千个。因此，最好将其基于代码覆盖率。您正在测试多少百分比的代码和分支逻辑？