导入 NUnit 结果的数据库？

Question

我有一套大量的NUnit测试数据；我需要将给定运行的结果导入到数据库中，然后对结果进行表征并向用户呈现（电子邮件用于测试失败，Web演示用于检查结果）。 我还需要跟踪多个运行时间（以报告故障率等）。

XML将是由nunit-console生成的XML。 我希望能够将XML最少地导入到某些数据库中，然后可以用于持久化和呈现结果。 我们将拥有许多自定义类别，我们需要能够在这些类别之间进行排序。

是否有人知道可以处理导入此类型数据并可根据我们个人需求进行自定义的数据库模式？ 这种问题似乎很常见，因此应该存在通用解决方案，但我似乎找不到一个。 如果有人之前实现过这样的解决方案，也会很感激得到建议。

- Paul Sonier

---

如果您的客户/利益相关者正在使用nunit结果来断言您的功能（规格）已经完成，那么您应该考虑行为驱动开发。这些框架提供易于阅读的结果格式。http://en.wikipedia.org/wiki/Behavior_Driven_Development - mxmissile

Answer 1

我觉得你实际上需要的是一个构建服务器，比如CruiseControl.NET或者TeamCity。

让构建服务器运行测试，它会告诉人们哪些测试失败了以及失败原因。

我推荐使用TeamCity，因为它的设置要容易得多。

- Iain Holder

---

构建服务器涉及很多方面。它可能是正确的答案，但并不总是比直接使用结果更好或更明显。我们没有足够的预算购买TeamCity（尽管我认为我正在说服我的老板），而CruiseControl.Net在我们目前的构建中不适用。我对只使用NUnit和数据库的解决方案感兴趣。 - Pat O

为什么您没有预算使用免费软件？TeamCity Professional是完全免费的。 - David M

TeamCity对于小团队开展相对简单的项目是免费的（就像啤酒一样）。但我们不符合这种情况。 - Pat O

Answer 2

我在这里希望解决相同的问题。我们目前倾向于编写XSLT将XML结果转换为插入语句。然后通过命令行SQL解释器运行插入语句的结果文件。理想情况下，我更愿意拥有一个处理所有这些的NUnit插件/扩展。不幸的是，我还没有找到一个。

- Pat O

Answer 3

延续IainMH的回答，您可能想要查看使用Trac和BITTEN，它是一个开源构建系统，可以运行n-unit测试并报告结果。我目前正是用它来实现这个功能。

- Didius

Answer 4

在使用 MS SQL 时，您可以将所有 XML 导入到 [xml] 数据类型的公共列中。在此基础上，可以执行 xpaths、搜索和转换操作。

- František Žiačik

Answer 5

如果你的经费紧张，另一个替代CruiseControl或TeamCity的选择是Atlassians Bamboo。我非常喜欢他们的软件，因为它易于使用，并且他们有一项交易，可以让你以10美元的价格获得Bamboo。

- dcbarans

Answer 6

我们本来希望避免这种情况，但我们已经从NUnit结果XML模式生成了一个数据库模式；然而，它有点不足，因为NUnit对一些关键统计数据（例如“忽略”与“未运行”）进行了一些（不准确和奇怪的）处理。

我们仍然希望找到一个不是完整的CIT构建系统的模式/流程，可以让我们定制导入结果的数据库，但目前我们正在使用一个手动编写的数据库，我们需要对其进行大量定制才能获得所需的报告。

- Paul Sonier

---

你愿意分享一下你目前的进展吗？我会回来考虑将其作为 NUnit 的补充并亲自接手。 - Pat O

Answer 7

你为什么需要将结果存储在数据库中？谁会使用它们？失败的数量不能太多。如果是（反复出现），那么你的开发流程就有问题了。修复这个流程。消除浪费（精益原则之一），不要收集它。

采取更小的步骤（更短的迭代，持续构建），消除依赖关系。

这通常不被执行，因为存在这些问题的项目无法交付，最终被取消。

[编辑] Michael，长时间跟踪nunit故障不提供任何价值。你需要一个短的反馈循环。立即解决问题。如果你等到积累了很多问题，你将被噪音淹没。

良好的问题跟踪是在正确的（尽可能高的）抽象级别上完成的。绝对不是单元测试。

- Stephan Eggermont

---

追踪失败情况（以及何时以及多久）是识别问题根本原因的关键。如果没有它，您将浪费时间尝试解决错误的流程问题。我会说，良好的问题跟踪对于精益开发过程至关重要。 - Michael Anderson

迈克尔，没错。我们正在使用一个遗留的代码库，测试集非常不足；我们有一些测试（数量很大，但是覆盖率不够），这些测试结果存在一定程度的不一致性。跟踪这些不一致性，在长时间（数月）内对我们的优先级排序非常重要。 - Paul Sonier

虽然我原则上同意，但在我们的情况下，即使分析一天的故障也可以提供大量的见解。我们测试软件与硬件的交互方式。如果故障仅发生在彩色传感器上，则这给了我们一个在哪里寻找问题的想法。如果它仅在高分辨率黑白传感器上发生，则我们将寻找其他地方。我们的传感器有十几个属性可能（或可能不）很重要。在XML中分析结果是不切实际的。我正在尝试消除浪费。 - Pat O

除了分析单个测试运行的结果外，分析一段时间内的结果也非常有价值。如果我们可以查看过去六个月所有构建的结果，我们可能会发现在查看单个构建时不那么明显的趋势。当接近发布时，单元测试是否更容易失败？在有大量新功能的冲刺开始时，它们是否更容易失败？仔细分析数据可以学到很多东西。永远不要低估信息的力量。 :-) - Pat O