单元测试覆盖策略，测试质量关注点

Question

我们公司正试图通过对自动化单元测试实施最低限度的功能覆盖来提高软件质量。这已经是一个很好的起点，可以至少编写一些测试并实现自动化(尽管最好是使用分支或决策覆盖)。

我主要关注的是在这项政策实施后将要进行的测试的结果。我经常看到这样的规则导致大量的空测试(即没有断言)或某种维护噩梦式的集成测试。我发现下面的问题非常接近这个主题，但这些问题更多地集中在覆盖率上：

代码覆盖的缺陷

什么是单元测试的合理代码覆盖率%(以及为什么)？

相反，我想得到帮助或洞察，我们如何才能避免可怕的质量测试。因此，这里有几个最糟糕的单元测试no-nos，我已经想到了如何避免它们：

1)零测试

• 测试代码的代码评审
• 由于我们使用测试框架，断言是通过使用FW宏来完成的。也许我们可以编写一些工具来计算被测试类的每个方法调用的断言率。还不知道什么才是好的比率。

2)集成测试

• 再一次回顾
• 也许是一些代码分析工具来检查测试代码对产品代码的依赖性。测试类应该很少依赖于被测试系统的其他类(被测试的类除外)。

有很多团队，我并不完全相信团队内部审查在所有情况下都是足够的。因此，我更感兴趣的是自动化质量保证的方法。

蒂亚河

Answer 1

我已经经历过这些，帮助公司进行自动化测试，从散乱/零碎到在很大程度上具有更高的质量。

我发现试图将度量作为质量的主要驱动因素并没有达到目的。首先也是最重要的，这是一个人的问题。你不能无缘无故地让某人相信某事，就像你不能神奇地让他们在没有支持的情况下做好事情一样。

简单而困难的答案是，要提高测试质量，您需要将测试代码视为一流公民。人们不会很好地进行自动化测试，除非他们能够被出售，并得到支持，以提高他们的技能。许多人回避这个问题，但事实是自动化测试是难做的，许多开发人员不会“得到”它或接受它是一种需要学习的技能；更糟糕的是，许多开发人员会默默挣扎，拒绝寻求帮助。

如果不能证明它的好处，就会导致测试缺乏光泽，这种测试会反馈给开发人员，使他们认为测试是无用的，并且没有发现任何bug。如果开发人员把测试看作是一项杂务，并将其作为一项任务，那么他们就已经有了一种思维方式，即它是无用的--它变成了一个自我实现的预言和一个完全的苦差事。我从经验中知道，没有什么比编写代码更糟糕的了，然后编写所有的测试来达到一个神奇的覆盖目标。到那个时候，不仅代码是无法测试的，而且就像在周日晚上做所有的学校作业一样--这一点也不好玩。

您需要了解为什么单元测试可以帮助您，一个好的/正确的/可理解的/可维护的/等等单元测试是什么样子的。您可以通过教育、演示文稿、对对编程、代码评审等方式来做到这一点。如果你只是设定了一个严格的限制，并告诉人们你希望他们满足它，他们可能会憎恨它，然后游戏的系统。注意:这不是一件容易的事情！让可疑的开发人员看到其中的价值并开始编写非疯狂的测试需要花费大量时间。没有一个‘啊哈’的时刻，你可以指望。已经做了一些研究，证明自动化测试可以是一个很有价值的开发工具，但是很多开发人员都是教条的。有些人永远不会想到这个主意。

我发现配对编程很好用。找到一个可以很容易测试的独立组件，或者用它们编写一些测试。完成编写测试、通过测试、重构测试和生成代码的过程，以消除问题并提高它们的可读性。随着时间的推移，培养他们的技能，从测试工具箱中向他们展示最常见的技术。随着时间的推移，尝试各种技术，如使用良好的命名实践，命名为consts，工厂方法，测试数据构建器，BDD风格的‘夹具作为上下文’。在修复错误之前，向他们展示如何通过编写失败的测试来证明bug的存在。强调最重要的原则，创造良好的测试！

最终的目标应该是所有的代码团队在一些经验规则上达成一致，比如“要获得批准，所有的故事都必须经过充分的测试并通过代码评审”。如果自动化测试对于给定的工作(例如原型)来说是不有价值的/不可行的，那么这是100%的好，但它应该是例外，而不是规则。

有了受人尊敬的代码领导，他们将与他们的团队一起工作以实现这一点，这是至关重要的。如果你不能从所有的线索中买到东西，那么你就有了一个大问题。

您可以使用代码度量工具(如NDepend (或您所选择的语言的变体)来扩展您的方法，它提供了一些特性，比如列出最复杂/使用过的代码，这些代码没有很好的测试覆盖率，或者在检查之间变化最大的区域。

祝好运。

Answer 2

获得好的测试的最好方法是实践测试驱动程序开发，这意味着首先进行测试。它分解为几个步骤：

1. 只写足够的测试失败
2. 编写足够的生产代码以使测试通过。
3. 重复3次，然后再进行折射

当然，这是一个巨大的简化，而TDD是一个很大的课题，但是我还没有看到好的、快速的、易于维护的测试。另一个关键是开发人员需要这样做，他们需要理解它如何使他们的生活变得更容易，它如何释放他们以后更改代码。如果开发人员不愿意开始测试，或者他们不知道如何编写测试(按照坚实的基本原则管理依赖关系)，那么您强加的规则可能并不重要。

Answer 3

有一种叫做with的度量，它把复杂性分析和覆盖率结合起来

http://blog.businessofsoftware.org/2007/09/alberto-savoia-.html

基本上，每个函数都有一个分数，说明如果函数是复杂的或者没有覆盖范围，那么它们的情况会变得更糟。这意味着你不能通过测试get/set方法来降低你的分数--你必须看看复杂的函数。您可以将它们分解(重构)，也可以测试它们以获得覆盖率。

这段视频解释了为什么这是一个难以衡量的游戏。

它不会对Null测试有所帮助，但它将有助于将测试的重点放在您从其中获得更多信息的地方。