Question

我们有一个已有10年历史的项目，其中包含超过一千万行的Java代码。现在，由于某些原因，组织决定为旧代码编写JUnit测试用例。我们正在使用Mockito JUnit测试用例。作为此更改的一部分，我们必须估算工时。估计现有代码非常困难，此外，我还是该项目的新手。只是想知道是否有任何经验法则可以根据代码行数进行估算。

Answer 1

我不能给您一个现实的估计，但是我可以给您一个下限的估计，它有望-表明不应完成手头的任务。要使行覆盖率达到80％以上，您将需要大约与生产代码一样多的手工测试代码行。因此，这是10 mio LOTC。拥有20年TDD经验的人，我认为我一天没有写超过500个LOC的代码（实际上，大多数日子少于50行）。因此，下限是10000000/500 = 20000天，或者100个人只写了一年的测试就什么也不做。

听起来可笑吗？因为它是。要使这种规模的系统进入合理的质量状态，需要采取不同的方法。您可能想阅读有关处理和替换旧系统的策略。现在无法对所有（或大多数）代码进行测试。

Answer 2

根据我的个人经验，要达到的覆盖率与编写适当的测试所需的工作量与以这种方式编写代码所需的工作量相关联，即覆盖率等于编写测试的工作量与编写测试所需的工作量之比。全面的开发工作。

c = t / (t + e)

哪里

t是开发测试所需的精力，
e开发代码和
t + e =总开发工作量（测试+代码）
c报道。

例如：

要实现0％的覆盖率，显然需要总开发工作量的0％
对于20％的覆盖率，编写测试需要您全部开发工作的20％
对于50％的覆盖率，编写测试需要您全部开发工作的50％
对于80％的覆盖率，编写测试需要您全部开发工作的80％

我想，你明白了。根据经验，较高的值（-> 100％）可能会有些不精确，并且实际上取决于开发人员编写可测试代码和进行健壮测试的经验。它进一步基于这样的假设和观察，即工作量与覆盖范围不是线性的-对于难以测试的案例，较高的覆盖范围需要付出额外的精力，而对于测试而言，非平凡的测试代码（尤其是设置）需要更多的测试代码。该公式的优点在于，仅使用相关指标（工作量，覆盖范围）即可轻松理解和计算，但它不是科学方法，只是一种快速估算方法。

对于旧代码（可能不太容易测试），希望您知道已经为之付出的努力，您可以估算所需的努力以实现目标覆盖范围。< / p>

所以基于花费的精力和目标覆盖率进行估算的公式为

t = e*c / (1-c)

因此，如果您已经花费了1000人日（PD），则需要再增加1000人日以达到50％的覆盖率。或500个PD占33％，或250个PD占20％。或4000个PD，占80％。

与Johannes的下界估计相比：

假设：500个LoC / PDs-> 10mio LOC = 20.000个PDs
约翰内斯下界估计：
- 20.000 PD表示80％
我的估计（上限）：
- 20.000 PD for 50％
- 80.000 PD（80％）（请记住，代码可能无法很好地测试）

真相可能介于两者之间。

我们是否有任何经验法则来估计JUnit测试用例的工时

2 个答案: