单元测试覆盖策略，测试质量问题

Question

我们公司正在努力通过在自动化单元测试中实施最低功能覆盖来提高软件质量。这已经是一个很好的起点，至少可以编写一些测试并使其自动化（尽管最好选择分支或决策覆盖）。

我主要担心的是在本政策投入使用后将要编写的测试结果。我经常看到这样的规则会导致大量的空测试（即没有断言）或某些维护噩梦般的集成测试。我发现以下SO问题接近主题，但这些问题更多地集中在覆盖百分比上：

Pitfalls of code coverage

What is a reasonable code coverage % for unit tests (and why)?

相反，我想得到帮助或见解，我们如何避免可怕的测试质量。所以这里有几个最糟糕的单元测试no-nos以及我已经想到的避免它们的内容：

1）无效测试

• 测试代码的代码审查
• 当我们使用测试框架时，断言是通过使用FW宏完成的。也许我们可以编写一些工具来计算测试中每类方法调用的断言比率。不知道，什么是足够好的比例。

2）整合测试

• 再次审核
• 也许是一些代码分析工具来检查测试代码的依赖关系 生产代码。测试班应该 有很少的 依赖于其他类（除了 对于正在测试中的那个） 经过测试的系统。

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

TIA，lutku

Answer 1

我已经完成了这项工作，帮助将公司的自动化测试从散点图/补丁变为高质量的大部分用途。

我发现尝试应用指标作为质量的主要驱动因素忽略了这一点。首先，这是一个人的问题。你无法让某人毫无理由地相信某些东西，就像你无法在没有支持的情况下神奇地使他们擅长某事一样。

简短而困难的答案是，为了提高测试质量，您需要将测试代码视为一等公民。人们不会在自动化测试方面做得很好，除非他们可以在其上出售并获得提高技能的支持。很多人都围绕着这个问题，但事实上，自动化测试很难做得很好，很多开发人员都不会“理解”或接受它是一种学习的技能;更糟糕的是，许多人会默默地挣扎，拒绝寻求帮助。

未能证明其好处导致测试乏善可陈，这些测试反馈给开发人员，使他们认为测试没用，并且没有发现错误。如果开发人员将测试视为一件苦差事并将其打入电话，那么他们已经处于一种无用的心态 - 它变成了一种自我实现的预言和彻底的苦差事。我从经验中知道，除了编写代码然后编写所有测试以达到神奇的覆盖目标之外，几乎没有什么比这更糟的了。到那个时候，不仅代码不可测，而且它类似于在周日晚上完成你所有的学校作业 - 这没什么好玩的。

您需要了解为什么单元测试可以提供帮助，知道什么是正确/正确/可理解/可维护/等等。单元测试看起来像。您可以通过教育，演示，结对编程，代码审查等来实现这一目标。如果您只是设置一个硬限制并告诉人们您希望他们满足它，他们可能会反感它然后游戏系统。注意：这不是一件容易的事！让可疑开发人员看到其中的价值并开始编写非疯狂测试需要花费大量时间。没有单一的“啊哈”时刻你可以依靠。已经进行的研究表明，自动化测试可以成为一种有价值的开发工具，但很多开发人员都是教条主义者。有些人永远不会想到这个想法。

我发现结对编程效果很好。找到一个可以轻松测试的隔离组件，或者用它们编写一些测试。完成编写测试的过程，使它们通过，重构测试和生产代码，以消除问题并使其更具可读性。随着时间的推移，建立他们的技能，向他们展示测试工具箱中最常用的技术。随着时间的推移，尝试各种技术，例如使用良好的命名实践，命名的consts，工厂方法，测试数据构建器，BDD样式“fixture作为上下文”。通过在修复错误之前编写失败的测试，向他们展示如何证明存在错误。强调创造良好测试的最重要原则！

最终的目标应该是所有代码团队都会就某些经验法则达成一致，例如“要注销，所有故事都必须经过充分测试并通过代码审查”。如果自动化测试对于100％罚款的特定工作（例如原型）没有价值/可行性，但它应该是例外，而不是规则。

拥有尊重的代码导致谁将与他们的团队合作才能实现这一目标至关重要。如果您无法从所有潜在客户那里购买，那么您就遇到了一个重大问题。

您可以使用NDepend（或您选择的语言的变体）等代码指标工具来扩充您的方法，该工具提供的功能包括列出没有良好测试覆盖率的最复杂/最常用的代码，或者缺少覆盖范围的区域签到之间变化最大。

祝你好运。

Answer 2

获得良好测试的最佳方法是练习测试驱动开发，这意味着测试FIRST。它分解为几个步骤：

1. 编写足够的测试以使其失败
2. 编写足够的生产代码以使测试通过
3. 3重复，并且你去的折射器

当然这是一个巨大的简化，TDD是一个很大的主题，但是没有它，我还没有看到很好的快速易维护测试。另一个关键是开发人员需要想要这样做，他们需要了解它如何使他们的生活更轻松，以及如何让他们在以后更改代码。如果开发人员没有兴趣开始测试，或者他们不知道如何编写测试（按照SOLID和FIRST原则管理依赖关系）那么你施加的规则可能并不重要。

Answer 3

有一个名为CRAP的指标，它将复杂性分析与覆盖率

结合起来

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

基本上，每个函数都有一个得分，即如果函数变得复杂或者没有覆盖，函数会变得更糟糕。这意味着您无法通过测试get / set方法来降低分数 - 您必须查看复杂的函数。您可以将它们分解（重构）或测试它们以获得覆盖。

该视频解释了为什么它是游戏的硬度量标准。

它对Null测试没有帮助，但它将有助于将测试集中在从中获得更多信息的地方。

Answer 4

是的，这是一个非常难的问题（另请参阅博文avoid false-positives vs. false-negatives。

在上面讨论的技术之上，有mutation-testing，您可以在其中检查测试套件的质量。在维基页面的一些参考资料中，您可以看到一些提示如何帮助自己使用现有框架的自定义扩展。我曾经试过Jester，这很好但也很慢，不幸的是这个项目目前看起来并不那么活跃......