用于导入 NUnit 结果的数据库？
我有大量的 NUnit 测试； 我需要将给定运行的结果导入数据库，然后描述结果集的特征并将其呈现给用户（测试失败的电子邮件，检查结果的 Web 演示）。 我还需要跟踪一段时间内的多次运行（用于报告一段时间内的故障率等）。
XML 将是 nunit-console 生成的 XML。 我想以最少的麻烦将 XML 导入到某个数据库中，然后可以使用该数据库来保存和呈现结果。 我们将有许多自定义类别，我们也需要能够对它们进行排序。
有谁知道可以处理导入此类数据的数据库模式，并且可以根据我们的个人需求进行自定义？ 这类问题似乎应该是常见的，因此应该存在一个通用的解决方案，但我似乎找不到一个。 如果有人以前实施过这样的解决方案，也将不胜感激。
I have a large set of NUnit tests; I need to import the results from a given run into a database, then characterize the set of results and present them to the users (email for test failures, web presentation for examining results). I need to be tracking multiple runs over time, as well (for reporting failure rates over time, etc.).
The XML will be the XML generated by nunit-console. I would like to import the XML with a minimum of fuss into some database that can then be used to persist and present results. We will have a number of custom categories that we will need to be able to sort across, as well.
Does anyone know of a database schema that can handle importing this type of data that can be customized to our individual needs? This type of problem seems like it should be common, and so a common solution should exist for it, but I can't seem to find one. If anyone has implemented such a solution before, advice would be appreciated as well.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
在我看来，您实际上正在寻找一个构建服务器，例如 CruiseControl.NET 或 TeamCity。
让构建服务器运行测试，它会告诉人们失败的原因以及失败的原因。
我推荐 TeamCity，因为它的设置要容易几个数量级。
It sounds to me like you're actually after a build server such as CruiseControl.NET or TeamCity.
Get the build server to run the tests, and it does the job of telling people what failed, and why.
I recommend TeamCity as it's several orders of magnitude easier to set up.
我来这里是为了解决同样的问题。 我们目前倾向于编写 XSLT 将 XML 结果转换为插入语句。 然后通过命令行 SQL 解释器运行插入语句的结果文件。 理想情况下，我宁愿有一个 NUnit 插件/扩展来为我处理所有这些。 不幸的是我没能找到一个。
I am here looking to solve the same issue. We are currently leaning toward writing an XSLT to transform the XML results into insert statements. Then run the resulting file of insert statements through a command line SQL interpreter. Ideally, I would rather have an NUnit add-in/extention that handles all this for me. Unfortunately I have not been able to find one.
为了构建 IainMH 的答案，您可能需要看看将 Trac 与 BITTEN 结合使用，它是一个开源项目构建系统，可以运行 n 单元测试并报告结果。 我目前使用它来实现该功能。
To build off IainMH's answer you may want to take a look at using Trac with BITTEN, it is an open source build system, that can run n-unit tests and report the results. I currently use it for that exact functionality.
使用 MS SQL 时，您可以将所有 XML 导入到 [xml] 数据类型的公共列。 在此基础上，可以执行 xpath、搜索和转换。
When using MS SQL, you can import all XMLs to a common column of [xml] datatype. Upon this, xpaths, searching and transformations can be performed.
如果您手头拮据，CruiseControl 或 TeamCity 的另一个替代方案是 Atlassians Bamboo。 我非常喜欢他们的软件，因为它易于使用，而且他们有优惠，可以花 10 美元买到竹子。
Another Alternative to CruiseControl or TeamCity is Atlassians Bamboo if you're strapped for cash. I'm a huge fan of their software for it's ease of use and they have a deal on where you can get bamboo for 10 bucks.
我们希望避免这种情况，但我们已经从 NUnit 结果 XML 模式生成了一个数据库模式； 然而，它有点不足，因为 NUnit 做了一些（不准确且奇怪的）处理来确定一些关键统计数据（例如“忽略”与“未运行”）。
我们仍然希望找到一个不是完整 CIT 构建系统的模式/流程，它可以让我们自定义用于导入结果的数据库，但目前我们正在使用手动数据库，我们需要这样做进行大量定制以获得所需的报告。
We've hoped to avoid this, but we've generated a database schema from the NUnit result XML schema; it's a bit deficient, however, because NUnit does some (inaccurate and strange) processing to determine some of the critical statistics ("ignored" vs. "not run", for example).
We're still hoping to find a schema / process that is NOT a complete CIT build system which can allow us to customize a database for importing the results, but currently we're using a hand-rolled database which we'll need to do a lot of customizing on to get the desired reporting.
为什么需要将结果存入数据库？ 谁会使用它们？ 失败的次数不能太多。 如果是（反复），那么您的开发过程就是错误的。 修复流程。 消除浪费（精益原则之一），不要收集浪费。
采取更小的步骤（更短的迭代、持续构建），消除依赖性。
这种做法并不常见，因为存在此类问题的项目无法交付，而是被取消（最终）。
[编辑] Michael，在较长时间内跟踪 nunit 故障提供了零价值。 您需要一个简短的反馈循环。 立即解决问题。 如果你等到积累了很多问题，你就会被噪音淹没。
良好的问题跟踪是在正确的（尽可能高的抽象）级别上完成的。 绝对不是单元测试。
Why do you need to have the results in a database? Who is going to use them? The number of failures cannot be large. If it is (repeatedly) your development process is wrong. Fix the process. Eliminate waste (one of the lean principles), don't collect it.
Take smaller steps (shorter iterations, continuous build), eliminate dependencies.
This is is not commonly done, because projects that have these kind of problems don't deliver but get cancelled (eventually).
[edit] Michael, tracking nunit failures over a longer time provides zero value. You need a short feedback loop. Fix the problems now. If you wait till you have accumulated a lot of problems, you are going to be overwhelmed by the noise.
Good problem tracking is done at the right (highest possible abstraction) level. Definitely not unit test.