Question

我很好奇有多少测试用例对于类似我的网站而言。这是您与业务工作流程网站的基本CRUD。 3个用户角色，几个输入页面，几个搜索页面，一个业务规则引擎等。可能有50k行.NET代码（工作流和持久性）。 DB有大约10个主表加上大约100个支持表（查找，日志等）。用于输入数据的主要UI非常大，大约有100个数据字段，多个网格，大约5个操作/提交类型按钮。

我知道这是模糊的，我只希望有数量级的数字。我也在考虑基本的测试用例，而不是代码覆盖类型的情况。但就像我告诉你我们有25个测试用例一样，我确信你会说方式不够。所以我只是在找球场数据。

TIA

Answer 1

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

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

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

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

一般来说，它更多地是关于 coverage 而不是测试次数。您希望测试覆盖尽可能多的应用程序功能可行。请注意，我没有说可能。您可以使用测试用例覆盖整个应用程序（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行可能会导致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，但实际情况是，大多数方法很少是独立的，并且完全有可能通过对其他人的显式测试来隐式测试许多方法;因此不需要他们自己的个人测试。

这使我明白了：如果不完全理解您的代码库，就无法确定正确的数字测试用例。根据测试的复杂程度，处于UI级别的5个案例可能足以完全覆盖;或者它可能需要数千。因此，基于代码覆盖率更好。您正在测试的代码和分支逻辑的百分比是多少？

Answer 2

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

测试案例的数量相同......如果招聘经理会问我这个问题，我可能会给他以下答案。

#test cases =介于＃要求* 2和＃要求*无限（某些要求可能导致各种可能性）

我也会说根据我的经验，数字实际上是＃要求* 5（我在初始阶段使用的数字，对于具有新功能，更改功能和省略功能的项目）

根据我进行此估算的阶段，必须采取以下误差幅度：

启动阶段：错误边距= 400％ ... 测试阶段：误差范围= 10％

当您开始测试阶段时，可以获得详细的要求/规格，稳定要求的挥发性，要求的蠕变几乎为零等。

那时我也可以给出更好的估计......

测试用例的粗略估计

2 个答案: