testing - 测试用例的粗略估计

Question

我很好奇其他与我相似的网站有多少测试用例。这是您使用业务工作流网站进行的基本CRUD。 3个用户角色，几个输入页面，几个搜索页面，一个业务规则引擎等。也许有5万行.NET代码（工作流和持久性总共）。具有大约10个主表和大约100个支持表（查找，日志等）的数据库。输入数据的主要用户界面很大，大约有100个数据字段，多个网格，大约5个动作/提交类型按钮。

我知道这是模糊的，我只是希望获得数量级的数字。我也在考虑基本的测试用例，而不是代码覆盖类型的用例。但是就像我告诉您我们有25个测试用例一样，我敢肯定您会说“ WAY”还不够。所以我只是在寻找球场的数字。

TIA

Answer 1

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

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

您应该进行适当的单元测试，以确保正确触发域对象和业务规则。您应该进行测试以确保您的查询正确执行（这是一个比较困难的测试）。

您甚至可能希望为通过软件的路径提供测试用例。换句话说，单击此处，获取此页面，单击此处，编辑字段，保存页面，返回......这种类型最困难，因为通常会记录测试，并且在页面更改时必须重新记录（即：添加或删除了一个字段）。

一般来说，更多的是覆盖范围而不是测试数量。您希望您的测试涵盖尽可能多的应用程序功能。请注意，我没有说可能。您可以用测试用例覆盖整个应用程序（100％），但是对于每一个小的更改，错误修复等，您都必须重新编码这些测试。对于成熟的应用程序，这是更理想的。对于较新的应用程序，您不希望这样困扰您的开发人员和质量检查团队，因为他们将花费过多的时间来修复/更改单元测试...



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

对于我们的小组，我们倾向于进行大量的单元测试。但是，对于测试通过系统的路径，我们仅在特定区域进入“维护”类型的模式后才记录这些路径。这意味着我们预计该区域在相当长的一段时间内不会有太大变化，而路径测试只是确保没有人抬高它。



更新：这里的评论使我想到以下几点：

再进一步：让我们看一小段代码：

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");

那只是代码块的一个测试用例，而实际上没有其他需要。

这说明了什么：对于初学者，两行代码可能会导致我们需要1到4个测试用例。您提到5万行...使用该逻辑，您将需要50,000至200,000个测试用例...

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

因此，假设有5种情况：这使我们进入20行代码= 1种情况。计算出5万行可能导致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种情况可能足以完全覆盖，这取决于测试的复杂性；否则可能需要数千。因此，最好基于代码覆盖率。您正在测试百分之几的代码和分支逻辑？