测试用例的粗略估计

Question

我很好奇其他人有多少测试用例来测试类似于我的站点。它是业务工作流程网站的基本CRUD。3个用户角色，几个输入页面，几个搜索页面，一个业务规则引擎，等等。大约50k行.NET代码(工作流和持久性)。包含大约10个主表和大约100个支持表(查找、日志等)的数据库。用于输入数据的主UI相当大，大约有100个数据字段，多个网格，大约5个操作/提交类型的按钮。

我知道这是模糊的，我只希望得到数量级的数字。我也在考虑基本的测试用例，而不是代码覆盖类型的用例。但是，如果我告诉你我们有25个测试用例，我相信你会说“远远不够”。所以我只是在找大概的数字。

提亚

Answer 1

我会有尽可能多的测试用例，以确保对系统的高度信任。

表、规则、代码行等的数量实际上并不重要。

您应该有适当的单元测试来确保您的域对象和业务规则被正确触发。您应该有测试来确保您的查询正确执行(这是一个较难的测试)。

您甚至可能希望为通过软件的路径提供测试用例。换句话说，单击此处，获取此页面，单击此处，编辑字段，保存页面，返回...这种类型是最困难的，因为测试通常被记录下来，当页面发生变化时(即:添加或删除字段)，必须重新记录测试。

一般来说，它更多的是关于覆盖率而不是测试数量。您希望您的测试尽可能多地覆盖应用程序的功能性。请注意，我并没有说可能。你可以用测试用例覆盖整个应用程序(100%)，但对于每一个小的变化，错误修复等，你都必须对这些测试进行重新编码。对于一个成熟的应用程序来说，这是更需要的。对于较新的应用程序，您不希望以这种方式束缚您的开发人员和QA团队，因为他们将花费过多的时间来修复/更改单元测试。

对于任何系统，您都可以轻松地花费与系统本身一样多的时间来开发自动化测试。在某些情况下，甚至更多。

对于我们的团队，我们倾向于有很多单元测试。然而，对于通过系统的测试路径，我们只在特定区域进入“维护”类型的模式时才记录这些路径。这意味着我们预计在很长一段时间内该区域几乎没有变化，路径测试只是为了确保没有人把它顶起来。

更新:这里的评论将我带到了以下内容：

更进一步:让我们来看一小段代码：

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表示边界检查。这实际上是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个测试用例。你提到了50k行...使用该逻辑，您将需要50,000到200,000个测试用例...

当然，生活很少会如此简单。在你拥有的50k行代码中，将会有很大的代码块，它们的输入非常有限。例如，抵押贷款利息计算器可能采用3个参数，并返回1个值( APR)。代码本身可能会运行100行左右(已经有一段时间了，请与我一起工作)。测试用例的数量将由边缘用例决定，确保您正确处理四舍五入。

因此，假设它是5种情况:这使我们得到20行代码=1种情况。计算出您的50k行可能会导致2500个测试用例。显然比我们上面预期的要小得多。

最后，我将在混合中加入另一条皱纹。有些测试系统可以处理来自数据文件的输入和断言。考虑到我们的第一个参数，我们可以有一个数据文件，对于我们想要测试的每个参数组合都有一行。在这个场景中，我们只需要一个测试用例就可以覆盖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个，但现实是大多数方法很少是独立的，完全有可能通过显式测试其他方法来隐式测试许多方法；因此不需要它们自己的单独测试。

这让我想到了这一点:如果不完全了解您的代码库，就不可能确定正确的测试用例数量。根据测试的复杂性，UI级别的5个案例可能足以覆盖完整的覆盖范围；或者可能需要数千个案例。因此，以代码覆盖率为基础要好得多。您正在测试的代码和分支逻辑的百分比是多少？

Answer 2

如果你问汽车推销员一辆车的粗略价格，他会给我这个价格，我不会在那里买车，因为他忘了问我一些重要的问题。你想要什么样的车？你想在车里加哪些额外的东西？等。

测试用例的数量也是如此……如果招聘经理问我这个问题，我可能会给他以下答案。

#测试用例=介于# requirements *2和#requirements*无限之间(一些需求可能导致大量的可能性)

我还想说，根据我的经验，这个数字实际上应该是#Requirements*5 (这是我在初始阶段使用的数字，对于具有新的、更改的和省略的功能的项目)

其中，根据我进行此估计的阶段，必须采用以下误差：

初始化阶段:误差余量=400%...测试阶段:误差= 10%

当您开始测试阶段时，详细的需求/规范可用，需求的波动性稳定，需求的蠕变几乎为零，等等。

到那时，我也能给出更好的估计。