计数断言

Question

最近，我收到了管理层的请求，要求创建关于软件测试运行的断言数量的报告。他们希望这样做，这样他们就可以知道人们是否在编写测试。我的倾向是告诉他们“不，你不能拥有它，因为你不需要它”，但这似乎不能满足他们。

部分问题在于，我们的团队正在编写包含大量断言的长测试用例，他们想说他们已经测试了一些新特性，因为他们在现有的测试用例中添加了更多的断言。

因此，我的问题是:是否有人拥有一些好的、权威的(尽可能多的)、资源、文章或书籍，甚至可以描述如何将测试分成测试用例或--为什么计数断言是错误的？

我的意思是，计算每个测试的断言或断言，以衡量人们是否正确，测试与每次测试中的代码行数一样有用。但他们就是不买。我试着用谷歌搜索，但问题是没有人费心计算断言，所以我不能说“这就是为什么这是一个坏主意”。

Answer 1

在软件管理中做出愚蠢决策的想象力是没有限制的，用测试计算assertions??...the问题通常是质量问题，而不是数量问题。

如果您想要一个受人尊敬的引用，Gerard模式可能是最受尊敬的一个，它的建议之一是“验证每个测试的一个条件”(http://books.google.es/books?id=-izOiCEIABQC&lpg=PT111&ots=YIeYejY-mx&dq=meszaros%20one%20assertion%20per%20test&hl=es&pg=PT110#v=onepage&q=condition&f=false)。

但是..。如果问题是人们增加了“新的测试场景”，用“更多的断言”来扩展现有的测试，而不是编写新的测试，那么你的公司最好能买到大量的meszaros书籍(例如kent beck TDD，以及在测试指导下的面向对象的增长)，并雇佣一些专家在迟到之前提供培训和指导。

Answer 2

也许敏捷宣言说得最好：

围绕有进取心的个人建立项目。给他们所需的环境和支持，并相信他们能完成任务。

如果你试图通过度量来运行一个项目，你最终会得到你所测量的东西，例如，很多没有真正测试正确事物的断言。

或者从更一般的管理角度来看：http://hbr.org/2010/06/column-you-are-what-you-measure/ar/1

Answer 3

由Steve McConnel完成的“代码”涵盖了代码和测试质量方面，包括与您的案例相关的度量标准。

衡量标准应能刺激人们所希望的行为。理想的行为，在你的例子中，是写更好的测试。所以，试着向你的经理解释，计算断言与你的行为无关。事实上，这可能会导致不良行为，在这里的另一个答案提到。

我同意敏捷宣言的观点。然而，它可以成功地应用在健康的环境中。我观察到一些工程师拒绝编写单元测试的案例，因为他们认为没有这些测试他们是“成功的”。在这种情况下，不管你有多信任他们来完成工作。指标改变行为。它们产生无偏见的数据，以便做出更好的决策。它们是有用的，但如果它们是正确的指标的话。

祝好运!